口述/作者：
姜江，新東方信息管理部平臺架構(gòu)負責人
陳博暄，新東方信息管理部高級運維工程師
編輯：
Rancher Labs
新東方信息管理部平臺架構(gòu)負責人 姜江
新東方信息管理部高級運維工程師 陳博暄
2017年，新東方開始了利用容器化手段將中間件業(yè)務服務化的探索，基于Rancher 1.6使用ES；2019年，新東方再次開始了擴大了中間件的業(yè)務服務化，基于Kubernetes使用Kafka、ES和Redis。利用容器化手段將中間件服務化，有效提升了運維團隊的工作效率，極大地縮短了軟件開發(fā)流程。本文將分享新東方在中間件服務化上的嘗試。
從幼兒園、小學、中學、大學和出國留學，新東方幾乎涉及了每一個教育領域。我們的教育產(chǎn)品線非常長，也非常復雜。那么，這么長的教育線，我們是用怎樣的IT能力進行支持的呢？——新東方云。
我們目前有16個云數(shù)據(jù)中心，包括自建、租用IDC，我們還通過云聯(lián)網(wǎng)直接連接了阿里云和騰訊云，最終形成了一套橫跨多個云提供商的混合云架構(gòu)。新東方的云體系很特別，你可以在里面看到一些相對傳統(tǒng)的部分，比如SQL Server、windows和柜面服務程序。但也有比較新潮的東西，比如TiDB、容器、微服務等等。除此之外，還能找到視頻雙師、互動直播等偏互聯(lián)網(wǎng)應用的部分。一個企業(yè)的IT架構(gòu)和一個企業(yè)的業(yè)務階段是密切相關的。新東方和萬千從傳統(tǒng)業(yè)務走向互聯(lián)網(wǎng)+的企業(yè)一樣，正處于數(shù)字化轉(zhuǎn)型的關鍵階段。
接下來我們來談一談新東方的容器化之路。新東方做容器也很多年了。2016年，新東方嘗試了基于Docker Swarm的一些商業(yè)方案方案，不是很理想。2017年正是容器編排架構(gòu)風云變換的一年，我們選擇了Rancher的Cattle引擎開始了容器化的自主建設，同時也在觀望業(yè)界動向。到了2018年，新東方的容器建設再次進化，最終全面轉(zhuǎn)向了K8S。
那么在新東方是怎么看待K8S的呢？我們認為K8S是介于PaaS和IaaS層之間的中間層，對下層的IaaS層和上層的PaaS層都制定了接口和規(guī)范。但是并不關心功能實現(xiàn)。而我們要做一套完整的容器云，只有K8S是遠遠不夠的，還需要引入其他開源組件進行補充。
從上圖可以發(fā)現(xiàn)，我們利用各種開源組補充K8S生態(tài)，組合成目前的新東方的容器云平臺。
我們的運行時組件基于Docker，Host主機操作系統(tǒng)選擇的是Ubuntu，K8S網(wǎng)絡組件用的是Canal，同時采用Mellanox網(wǎng)卡加速技術。Rancher 2.0作為我們的k8s管理平臺，提供多租戶管理、可視化、權限對接AD域等重要功能，幫助我們避免了大量的后臺集成整合工作，為我們節(jié)約了人力的同時提供了一套穩(wěn)定的圖形化管理平臺。
下面介紹一下我們的K8S實踐， 從上圖可以看到，我們完全基于原生社區(qū)版本的K8S。通過kubeadm工具和nginx stream負載均衡部署成一個三節(jié)點HA架構(gòu)。
集群關鍵組件運行在host網(wǎng)絡模式。這樣可以減少網(wǎng)絡上的資源消耗，獲得更好地性能，比如Ingress組件，通過Flannel構(gòu)建overlay容器網(wǎng)絡，運行上層應用。
使用容器肯定需要涉及到鏡像管理。新東方是早期Harbor的用戶，我們從1.2版本就開始用Harbor，后端存儲對接ceph對象存儲。目前，我們在嘗試鏡像分發(fā)的功能，使用的是阿里云開源的Dragonfly。它可以將南北向的下載流量轉(zhuǎn)換為東西向，使鏡像在node之間復制成為可能。當集群規(guī)模非常大的時候，減緩拉取鏡像對Harbor服務器造成的壓力負載。
在這里，我們使用的是Ubuntu的Maas，它是個裸機管理平臺，可以將沒有操作系統(tǒng)的物理機，按照模板裝成指定的標準物理機。我們再結(jié)合Ansible playbook初始化物理節(jié)點，將它變成我們想要的物理機節(jié)點，加入到集群里邊。
從上圖中可以看到，通過加載TiDB的role把標準物理機變成TiDB的節(jié)點，通過K8S的role把標準物理機變成K8S節(jié)點，我們會在每一種role里將Osquery和Filebeat推到物理機上，它們可以收集物理機的機器信息，推送到CMDB進行資產(chǎn)管理。
我們的CI/CD是基于業(yè)務來區(qū)分的，有一部分我們直接對接新東方自己的Jenkins，另一部分業(yè)務直接對接Rancher Pipeline功能來實現(xiàn)CI/CD。
集群監(jiān)控方面，我們現(xiàn)在用的是開源社區(qū)Prometheus的Operator。一開始我們用的是原生的Prometheus，但是原生的Prometheus在配置告警發(fā)現(xiàn)和告警規(guī)則上特別麻煩。
引用了Operator以后，Operator幫我們簡化了配置的過程，比較好用，推薦大家使用。
值得一提的是，Rancher 2.2版本之后的集群監(jiān)控都是基于Prometheus Operator，大家感興趣的話，可以回去下一個新版本的Rancher體驗一下。
我們的日志是針對兩個級別來設置的。業(yè)務日志通過sidecar的方式運行filebeat，把數(shù)據(jù)收集到kafka集群里面，再由logstash消費到ES，可以減輕ES的壓力負載。
另一方面是集群層面，集群層面的日志通過Rancher 2.2提供日志收集功能，用fluentd收集到ES集群當中。
我們一共有五套集群，一個是跑線上業(yè)務的，生產(chǎn)和測試兩套；一個是Platform1集群,跑中間件類應用，比如ES、Redis、Kafka，也是分生產(chǎn)和測試兩套；還有一個是測試集群，它是測試功能的，K8S集群升級迭代、測試新的組件、測試新的功能都是在這個集群上完成的。
可能細心的朋友發(fā)現(xiàn)我們的集群是1.14.1版本的，版本非常新，為什么？因為Kubernetes 1.14有一個非常重要的功能，叫l(wèi)ocal PV，目前已經(jīng)GA，我們非?？粗羞@個功能，因此將集群一路升級到1.14。
目前，業(yè)務應用主要是兩個方面：
為什么要將中間件服務化？
我舉個例子做個比較: 比如我啟動一個業(yè)務的虛機，4C8G比較常見，起10個就是40C 80G。作為對比, 40C80G是否能啟動一個elasticsearch的節(jié)點呢? 40C 80G啟動一個es節(jié)點是很緊張的。實際生產(chǎn)中, 一個高吞吐的ES節(jié)點一般需要100G以上的內(nèi)存。從這個例子我們就可以體會到中間件類負載的單體資源消費非常的大。
另外，中間件在項目中應用非常廣，隨便一個應用，肯定會使用Redis、MQ等組件。隨便一個組件單獨部署就要占用占多臺虛機。各個項目又都希望自己能有個小灶，希望自己能獨占一個環(huán)境。而小灶對資源的耗費就更多，加上中間件不可避免的各種版本、各種配置不一樣，我們需要雇傭非常多的人來維護中間件，這就是一個很大的問題。
當然，如果整個公司一共也就有十來個項目的話，完全使用虛機也可以。但是新東方現(xiàn)在有三四百個項目，中間件消耗了相當大的資源。如果全部用虛機資源的話，成本還是很高的。
那我們怎么解決這個問題呢？我們祭出三箭：容器化、自動化、服務化。
容器化最好理解，剛才提到了雜七雜八的各種配置，通通用容器來統(tǒng)一，你必須按我的標準來。直接將容器部署到物理機，以獲得更好的性能和彈性。
容器化的下一步是自動化，自動化更精確地說其實是代碼化。就是將基礎設施代碼化，以代碼上線迭代的方式管理基礎設施。我們使用Helm和Ansible來實現(xiàn)代碼化和自動化。
逐漸地將小灶合并成大鍋飯，削峰填谷，也避免了資源的浪費。每個公司多少多有一些超級VIP的項目. 這種業(yè)務就變成了大鍋飯里面單獨的小灶。同樣是大鍋飯的機制，但我單獨為你提供資源隔離、權限隔離。
在服務化之前，我們對運維人員更多的理解是項目的勞務輸出。每天都很忙，但也看不到做太多成果。服務化之后，我們將勞務輸出轉(zhuǎn)變?yōu)閷Ψ掌脚_的建設，賦能一線人員，讓二線人員做更有意義的事。
我們的實踐：ELK/ESElastic公司有個產(chǎn)品叫做ECE，是業(yè)內(nèi)第一個容器化管理ES的平臺，ECE基于K8S的1.7(也可能是1.8)實現(xiàn)。通過容器的方式、用物理機為用戶提供各個版本的ES實例。但是它也存一些局限性：只能管ES，其他的中間件管不了。
這對我們啟發(fā)很大，我們就想能不能用Rancher+Docker的方式，模仿制作一個我們自己服務平臺。于是誕生了我們的第一版平臺，來使用Rancher 1.6管理ELK。
上圖就是我們的ELK集群，它是橫跨Rancher 1.6和k8s和混合體，目前處于向k8s遷移的中間狀態(tài)。
ELK的編排方式我們有兩個版本：UAT環(huán)境的編排和生產(chǎn)編排。在UAT環(huán)境我們采用rook(ceph)的方案， ES節(jié)點用Statefulset方式啟動。這種方案的好處是萬一哪個節(jié)點掛了，存儲計算完全分離，你想漂移到哪里就可以漂移到哪里。
我們的生產(chǎn)環(huán)境會比較不一樣，我們將每個ES節(jié)點都做成一個deployment，我們不讓它漂移，用Taint和label將deployment限定在某一主機上。POD的存儲不再使用RBD，直接寫入本地磁盤hostpath, 網(wǎng)絡使用host網(wǎng)絡獲取最好的性能。
如果掛了怎么辦呢？掛了就等待就地復活，機器掛了就地重啟，換盤或者換硬件。如果還不能復活怎么辦呢？我們有個機器的管理，機器干掉，直接從池里面重新拉一臺新機器出來，上線，利用ES的復制功能把數(shù)據(jù)復制過去。
大家可能會很奇怪，你們怎么搞兩套方案，而且生產(chǎn)編排還那么丑？
我們認為簡約架構(gòu)才是最美架構(gòu)，中間環(huán)節(jié)的組件越少，故障點也越少，也就越可靠。本地磁盤的性能要優(yōu)于RBD，本地網(wǎng)絡要優(yōu)于K8s網(wǎng)絡棧。最重要的是：我們編排的這些中間件應用，實際上全部都是分布式的(或者內(nèi)置HA架構(gòu))，他們都有內(nèi)置的副本機制，我們完全不用考慮在K8S這一層做保護機制。
我們也實驗對比過這兩種方案，如果節(jié)點掛掉，本地重啟的時間要遠低于漂移的時間，RBD有時候還會出現(xiàn)漂移不過去的問題。物理節(jié)完全掛掉的幾率還是很小的。所以我們最終在線上環(huán)境選擇了稍微保守一點的方案。
我們的實踐：Redis我們現(xiàn)在的Redis主要是哨兵的方案，同樣采用deployment限定到特定節(jié)點的方式編排。我們的Redis不做任何持久化，純作為cache使用。這就會帶來一個問題：假如master掛了，那么K8S就會馬上重啟，這個重啟時間是一定小于哨兵發(fā)現(xiàn)它掛了的時間。它起來之后還是master，是個空空的master，隨后剩下的slave中的數(shù)據(jù)也會全部丟掉，這是不可接受的。
我們先前也做了很多調(diào)研，參考攜程的做法, 在容器啟動的時候用Supervisord來啟動Redis，即使POD中的Redis掛掉也不會馬上重啟POD，從而給哨兵充分的時間進行主從切換，然后再通過人工干預的方式恢復集群。
在Redis的優(yōu)化上，我們?yōu)槊總€Redis實例綁定CPU。我們知道 Redis進程會受到CPU上下文切換或者網(wǎng)卡軟中斷的影響。因此我們在Redis實例所在node上做了一些限制，并打上了taint。我們把操作系統(tǒng)所需要的進程全部要綁到前N個CPU上，空出來后面的CPU用來跑Redis。在啟動Redis 的時候會將進程和CPU一一對應，獲得更佳的性能。
我們的實踐：Kafka眾所周知，Kafka是一種高吞吐量的分布式發(fā)布訂閱消息，對比其他中間件，具有吞吐量高、數(shù)據(jù)可持久化、分布式架構(gòu)等特點。
那么，新東方是怎樣使用Kafka的？對Kafka集群有什么特殊的要求呢？
我們按照業(yè)務應用場景來分組，會劃分為三類：第一類是使用Kafka作為交易類系統(tǒng)的消息隊列；第二類是使用Kafka作為業(yè)務日志的中間件；第三類是Kafka作為交易類系統(tǒng)的消息隊列。
如果想滿足這三類應用場景，我們的Kafka就必須滿足安全要求。比如不能明文傳輸交易數(shù)據(jù)，所以一定要進行安全加密。
下面，我們來講解一下Kafka原生的安全加密，我們是怎么做的？又是如何選擇的？
除了金融行業(yè)以外，其他行業(yè)使用Kafka一般不會使用它們的安全協(xié)議。在不使用安全協(xié)議情況下，Kafka集群的性能非常好，但是它明顯不符合新東方對Kafka集群的要求，所以我們開啟了數(shù)據(jù)加密。
我們使用Kafka原生支持，通過SSL對Kafka進行信道加密，使明文傳輸變成密文傳輸，通過SASL進行用戶驗證，通過ACL控制它的用戶權限。
我們簡單看一下兩種SASL用戶認證的區(qū)別。SASL_PLAIN是將用戶名密碼以明文的方式寫在jaas文件里面，然后將jaas文件以啟動參數(shù)的形式加載到Kafka進程里面，這樣Kafka的client端訪問服務器的時候會帶著jaas文件去認證，就啟動了用戶認證。
SASL_GASSAPI是基于Kerberos KDC網(wǎng)絡安全協(xié)議，熟悉AD域的朋友肯定了解kerberos，AD域也用到了Kerberos網(wǎng)絡安全協(xié)議，客戶端直接請求KDC服務器和KDC服務器交互，實現(xiàn)用戶認證。
兩種方法各有利弊，最終新東方選擇的是第一個SASL_PLAIN的方式，原因很簡單，這樣我們可以避免單獨維護KDC服務，減少運維部署成本。但是這種方法有一個問題，因為Kafka用戶名和密碼都是通過這個進程加載進去的，你想改文件比如添加用戶、修改用戶密碼，那你就必須重啟Kafka集群。
重啟Kafka集群勢必對業(yè)務造成影響，這是不能接受的。因此我們采用變通的方法, 按照權限分組，總共在jaas文件里面預先設置了150個用戶，管理員為項目分配不同的用戶.這樣就避免了增加項目重啟集群的尷尬。
如上圖, 我們在Kafka集群上我們開放了兩個端口，一個是帶用戶認證并且?guī)SL加密的端口，另一個是沒有SSL加密,只啟用了用戶認證的SASL_PLAIN端口。連接Kafka的客戶端根據(jù)自己的需求選擇端口進行訪問。
說完架構(gòu)，我們來說說kafka的編排。我們kafka和zk集群都通過host網(wǎng)絡部署，數(shù)據(jù)卷通過hostpath方式落到本地物理機，以獲取更好地性能。
Kafka和zk都是單個deployment部署，固定在節(jié)點上，即使出現(xiàn)問題我們也讓他在原機器上重新啟動，不讓容器隨意遷移。
監(jiān)控方面采用exporter+Prometheus方案，運行在overlay的容器網(wǎng)絡。
我們的實踐：服務化平臺以kafka為例, ansible 會根據(jù)環(huán)境生成helm chart , 像SSL證書，預埋用戶配置等是由ansible按照用戶輸入進行生成，生成的結(jié)果插入到helm chart中，隨后helm根據(jù)chart創(chuàng)建對應實例。
以下是我們平臺1.0 Demo的一些截圖。
這是集群管理，部署到不同的集群上會有不同集群的入口維護它的狀態(tài)。
上面展示的是申請服務的步驟。整個步驟非常簡單，選中集群和想要的版本就可以了。
在這個管理界面，你可以看到你的IP、訪問入口、你的實例使用的端口（端口是平臺自動分配的）。如果是SSL連接，你還可以得到你的證書，可以在頁面上直接下載。我們后期還會將集群的日志都接入到平臺中。
我們的后臺還是挺復雜的。后臺使用ansible 的AWX平臺。這里可以看到創(chuàng)建一個集群其實需要很多的輸入項，只不過這些輸入項我們在前臺界面中就直接幫用戶生成出來了。
這是部署出來的完整的Kafka集群，有Zookeeper，有Kafka，有監(jiān)控用的exporter等。我們?yōu)槊總€集群都配置了一個kafka Manager，這是一套圖形化的管理控制臺，你可以直接在manager中管理kafka。
監(jiān)控報警是必不可少的，我們基于Prometheus Operator做了一些預置的報警規(guī)則。比如topic是否有延遲。當集群生成后，Operator會自動發(fā)現(xiàn)你的端點，也就是我們剛看的exporter，operator發(fā)現(xiàn)端點后就開始自動加入報警，完全不需要人工接入。
我們?yōu)槊總€項目生成了可視化面板，需要監(jiān)控的時候可以直接登錄Grafana查看。
上圖是簡單的壓測結(jié)果。512K的Message，SSL+ACL的配置五分區(qū)三副本，約為100萬消息每秒, 配置是五個16C 140G內(nèi)存的容器，SSD硬盤。我們發(fā)現(xiàn)隨著Message體積變大，性能也會隨之下降。
服務化平臺路線展望2020財年開始，新東方計劃將Redis、ES這些服務也全部服務化，并將這些暴露出來的API最終整合到云門戶里，給集團內(nèi)的用戶或者是第三方系統(tǒng)調(diào)用。
另外一個不得不提的就是Operator，上周Elastic又發(fā)布了一個新項目叫ECK，ECK就是ES的官方Operator。
通過Operator，你只需要簡單地輸入CRD，Operator就會自動生成你需要的集群。
我們認為基于Helm的方式，雖然能極大地簡化Yaml的工作，但它還不是終點，我們相信這個終點是Operator。
編者按：
本文是根據(jù)新東方姜江和陳博暄在Rancher于2019年6月20日在北京舉辦的第三屆企業(yè)容器創(chuàng)新大會（Enterprise Container Innovation Conference，簡稱ECIC）上的演講整理而成。本屆ECIC規(guī)模宏大，全天共設置了17場主題演講，吸引了近千名容器技術愛好者參加，超過10000名觀眾在線觀看。您可在Rancher公眾號中閱讀更多大會演講實錄的文章。
重慶分公司
重慶分公司
