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