微服務(wù)化的不同階段 Kubernetes 的不同玩法

時(shí)間：2022-08-11 16:51:01 | 來(lái)源：網(wǎng)站運(yùn)營(yíng)

時(shí)間：2022-08-11 16:51:01 來(lái)源：網(wǎng)站運(yùn)營(yíng)

本文由網(wǎng)易云 發(fā)布




作為容器集群管理技術(shù)競(jìng)爭(zhēng)的大贏家，Kubernetes已經(jīng)和微服務(wù)緊密聯(lián)系，采用Kubernetes的企業(yè)往往都開(kāi)始了微服務(wù)架構(gòu)的探索。然而不同企業(yè)不同階段的微服務(wù)實(shí)踐面臨的問(wèn)題千差萬(wàn)別，注定要在技術(shù)路線上產(chǎn)生分叉。如何選擇適合自己的技術(shù)，是每一個(gè)踐行微服務(wù)的團(tuán)隊(duì)面臨的第一個(gè)問(wèn)題。網(wǎng)易云是Kubernetes的第一批重度用戶，在不同業(yè)務(wù)場(chǎng)景下解決了很多挑戰(zhàn)，在本文中，網(wǎng)易云首席解決方案架構(gòu)師劉超梳理了基于Kubernetes構(gòu)建微服務(wù)體系的進(jìn)階之路。

高速增長(zhǎng)階段，微服務(wù)化的必要性

一個(gè)產(chǎn)品的發(fā)展，通?？煞譃槔鋯?dòng)階段、高速增長(zhǎng)階段和成熟階段。

產(chǎn)品冷啟動(dòng)階段，需求是以最簡(jiǎn)單的架構(gòu)驗(yàn)證業(yè)務(wù)。以網(wǎng)易考拉海購(gòu)（以下簡(jiǎn)稱“網(wǎng)易考拉”）為例，最初的架構(gòu)設(shè)計(jì)目標(biāo)就是快速啟動(dòng)，驗(yàn)證產(chǎn)品方向，該架構(gòu)包括在線、緩存、線下和管理服務(wù)四個(gè)方面，即一般電商平臺(tái)加上跨境電商必備的進(jìn)銷(xiāo)存系統(tǒng)，采用了Oracle數(shù)據(jù)庫(kù)、OpenStack管理的虛擬機(jī)（VM），并沒(méi)有諸如高并發(fā)之類(lèi)的考慮。

產(chǎn)品高速增長(zhǎng)階段，業(yè)務(wù)規(guī)模逐漸擴(kuò)大，產(chǎn)品復(fù)雜度也隨著增加，企業(yè)需要解決快速迭代、高可靠和高可用等問(wèn)題，一個(gè)自然的選擇是服務(wù)化的拆分，把一個(gè)單體架構(gòu)拆分成一些較小的模塊，并遵循康威定律，用5-9個(gè)小團(tuán)隊(duì)來(lái)適應(yīng)架構(gòu)的變化。仍以網(wǎng)易考拉為例，網(wǎng)易考拉在高速增長(zhǎng)階段也慢慢演化出各種新的模塊，比如單獨(dú)的支付模塊、貨倉(cāng)模塊、第三方商家模塊、推送模塊等，并基于Dubbo框架打造服務(wù)發(fā)現(xiàn)功能來(lái)支持各模塊之間的相互調(diào)用。

服務(wù)化主要解決了變更的問(wèn)題。在整個(gè)架構(gòu)演進(jìn)的過(guò)程中，各個(gè)模塊都面臨爆炸性的增長(zhǎng)，比如海淘、自營(yíng)、第三方商家的供應(yīng)鏈，Web、APP、H5的呈現(xiàn)，限時(shí)購(gòu)、秒殺、預(yù)售的活動(dòng)頁(yè)，以及倉(cāng)庫(kù)與物流系統(tǒng)、支付系統(tǒng)的對(duì)接等，緊耦合則牽一發(fā)而動(dòng)全身，工程臃腫，影響迭代速度，分別獨(dú)立上線更有利于適應(yīng)業(yè)務(wù)發(fā)展的需求。網(wǎng)易考拉在高速增長(zhǎng)階段首先按照主頁(yè)、活動(dòng)頁(yè)、優(yōu)惠券、支付等維度縱向拆分，之后又不斷演進(jìn)成為100多個(gè)相互關(guān)聯(lián)的模塊，變更頻率由每天2次增長(zhǎng)到每天1000多次，產(chǎn)品質(zhì)量提升52%。

容器化的優(yōu)勢(shì)與挑戰(zhàn)

拆分成大量小模塊之后，虛擬機(jī)與服務(wù)化架構(gòu)的配合就出現(xiàn)了很多新的挑戰(zhàn)，于是有了容器化的需求。

劉超解釋說(shuō)，拆分之前首先要解決“合”的問(wèn)題，即需要保證功能還是原來(lái)的功能，代碼質(zhì)量還是原來(lái)的代碼質(zhì)量，不會(huì)引入新的bug。他認(rèn)為，微服務(wù)化需要從一開(kāi)始就要做好持續(xù)集成，而容器是很好的持續(xù)集成的工具，完成從代碼提交到自動(dòng)測(cè)試、自動(dòng)發(fā)布的工作。容器化會(huì)帶來(lái)開(kāi)發(fā)流程的變化，把環(huán)境交付過(guò)程從運(yùn)維人員提前到開(kāi)發(fā)人員手上。

在架構(gòu)復(fù)雜的情況下，比如100多個(gè)模塊，再加上各種副本，所有環(huán)境都由一個(gè)運(yùn)維團(tuán)隊(duì)來(lái)完成，不僅工作量繁重，而且還容易出錯(cuò)，但這是使用虛擬機(jī)的模式。而如果寫(xiě)一個(gè)Dockerflie放到代碼倉(cāng)庫(kù)，由開(kāi)發(fā)人員來(lái)考慮開(kāi)發(fā)完成之后應(yīng)用部署的配置環(huán)境、權(quán)限等問(wèn)題，包括測(cè)試環(huán)境的部署、聯(lián)調(diào)環(huán)境的部署、生產(chǎn)環(huán)境的部署，問(wèn)題就很好解決了。這就是容器化帶來(lái)的流程變化。

然而，這種轉(zhuǎn)變涉及到開(kāi)發(fā)人員是否愿意學(xué)習(xí)容器技術(shù)。劉超推薦的解決辦法，是使用鏡像分層的形式，即最內(nèi)部的環(huán)境包括操作系統(tǒng)及系統(tǒng)工具的鏡像由運(yùn)維人員來(lái)做，中間層環(huán)境的鏡像由核心開(kāi)發(fā)人員完成，普通開(kāi)發(fā)人員只需把jar或者war扔到相應(yīng)的路徑下即可，這就極大降低企業(yè)組織容器化的障礙。

場(chǎng)景一：Kubernetes + Docker + VM + Host Network

第一種場(chǎng)景，就是用Kubernetes管理虛擬機(jī)，容器的網(wǎng)絡(luò)、存儲(chǔ)會(huì)面臨各種各樣的選型。企業(yè)如果對(duì)容器的網(wǎng)絡(luò)、存儲(chǔ)了解不足，可以把容器當(dāng)成一個(gè)持續(xù)集成的工具，把一個(gè)容器嵌入到一個(gè)虛擬機(jī)里面，相當(dāng)于用容器鏡像代替腳本部署。這種做法需要解決兩個(gè)問(wèn)題：一是IP保持的問(wèn)題，二是盤(pán)保持的問(wèn)題。因?yàn)樵炔捎锰摂M機(jī)的時(shí)候，是基于有狀態(tài)的設(shè)計(jì)，認(rèn)為IP、Volume都是保持不變的。當(dāng)容器僅僅作為持續(xù)集成的工具，團(tuán)隊(duì)的這個(gè)習(xí)慣可能改不了。

一個(gè)方案是自己實(shí)現(xiàn)一個(gè)有狀態(tài)容器的方式，實(shí)現(xiàn)IP的保持，當(dāng)一個(gè)節(jié)點(diǎn)掛了，重新啟動(dòng)的虛擬機(jī)和容器仍然可以使用原先分配的IP，二是把Docker容器的鏡像一層層地Mount到外面的Volume里面，當(dāng)一個(gè)節(jié)點(diǎn)掛了，Docker所有的鏡像和Volume其實(shí)還掛載在外面的Ceph上，數(shù)據(jù)并未丟失。這和使用VM很相似，既可以Docker化支持微服務(wù)化，也不需要改變用戶習(xí)慣。使用Kubernetes壓力相對(duì)比較大的團(tuán)隊(duì)，可以通過(guò)這種方式切入。

場(chǎng)景二：Kubernetes + Docker + PM + Bridge Network

第二種場(chǎng)景，企業(yè)沒(méi)有使用虛擬機(jī)，有一部分應(yīng)用部署在PM上（注：本文中PM特指物理機(jī)），同時(shí)想把一部分應(yīng)用遷移到容器里。此時(shí)，不管物理機(jī)是否嵌套虛擬機(jī)，直接創(chuàng)建一個(gè)Bridge Network，把物理網(wǎng)卡也打進(jìn)去，當(dāng)Docker的網(wǎng)卡和Bridge連起來(lái)的時(shí)候，整個(gè)網(wǎng)絡(luò)就是平的，容器和容器旁邊的物理機(jī)都使用同一個(gè)指定的網(wǎng)段。網(wǎng)絡(luò)打平之后，使用Dubbo的團(tuán)隊(duì)也可以比較順暢地把一部分物理機(jī)上部署的應(yīng)用逐漸遷移到容器里，而如果沒(méi)有Bridge
Network，中間過(guò)負(fù)載均衡（LB）或者NAT時(shí)會(huì)很別扭，因?yàn)镵ubernetes層的維護(hù)人員通常很難勸說(shuō)Dubbo層開(kāi)發(fā)人員改變應(yīng)用開(kāi)發(fā)的方式。

使用Bridge
Network，Kubernetes網(wǎng)絡(luò)配置很簡(jiǎn)單，使用CNI的方式即可。如果有定制化以適應(yīng)應(yīng)用層的需求，可以參考Docker run的手動(dòng)配置方式，開(kāi)發(fā)自己的CNI插件。大致流程是先創(chuàng)建網(wǎng)橋（如果不存在），獲取Namespace，配置veth pair并放到Namespace里，然后獲取IP地址，獲取網(wǎng)絡(luò)和路由。

場(chǎng)景三：Kubernetes + Docker + PM + SR-IOV Network

Bridge的方式，能夠滿足一般的Java應(yīng)用部署的需求，但一些需要更高性能的應(yīng)用，需要高吞吐量、高并發(fā)、高PPS，比如電商大促情況下的緩存，這時(shí)候可以采用SR-IOV代替Bridge來(lái)解決問(wèn)題，帶寬比較大但PPS上不去（大包或大量小包）的情況，SR-IOV都可以解決，但是需要購(gòu)買(mǎi)SR-IOV網(wǎng)卡，成本比較高。

高可用設(shè)計(jì)要點(diǎn)

無(wú)狀態(tài)。做好持續(xù)集成之后，第一件事情應(yīng)該是把應(yīng)用分為有狀態(tài)（Stateful）和無(wú)狀態(tài)（Stateless）兩個(gè)部分，并且使大部分應(yīng)用是無(wú)狀態(tài)的，這樣可以更好地適應(yīng)彈性伸縮。即便Kubernetes已經(jīng)可以支持有狀態(tài)應(yīng)用的部署，劉超還是建議在應(yīng)用層盡量實(shí)現(xiàn)無(wú)狀態(tài)，使得有狀態(tài)應(yīng)用聚集在少數(shù)的集群里面。有狀態(tài)最重要的是數(shù)據(jù)庫(kù)和緩存，通常內(nèi)存數(shù)據(jù)放在緩存，需要持久化的數(shù)據(jù)放在數(shù)據(jù)庫(kù)里。

分布式數(shù)據(jù)庫(kù)。數(shù)據(jù)庫(kù)的高可用，網(wǎng)易云采用的是DDB（分布式數(shù)據(jù)庫(kù)）方案，基于MySQL的多臺(tái)主備及負(fù)載均衡做分庫(kù)分表，網(wǎng)易云RDS基于自己的MySQL內(nèi)核優(yōu)化，能夠?qū)崿F(xiàn)主備切換不丟數(shù)據(jù)，能夠很好地支持容器化，有狀態(tài)容器掛掉之后，重新啟動(dòng)一個(gè)容器，只要做好前序重置和冪等，就不會(huì)有業(yè)務(wù)問(wèn)題。所以網(wǎng)易云RDS的主備切換也從虛擬機(jī)向容器過(guò)渡。

緩存。高并發(fā)應(yīng)用需要每一層都有緩存，把客戶需求盡可能地?cái)r在前面，吞吐量就大很多。但緩存不像數(shù)據(jù)庫(kù)一樣有持久化機(jī)制，其高可用、跨機(jī)房就需要做雙寫(xiě)，因?yàn)榫彺姹３衷趦?nèi)存中，掛了就沒(méi)有了，修復(fù)難度很大。其他的組件，比如ZooKeeper、Kafka、消息隊(duì)列、HBase，都有各自的高可用機(jī)制。所以，一個(gè)發(fā)展中的應(yīng)用應(yīng)當(dāng)被分成很顯著的兩個(gè)部分，一部分是無(wú)狀態(tài)的，另一部分有狀態(tài)的就放到本身具有高可用機(jī)制的組件里面。

成熟階段架構(gòu)

產(chǎn)品成熟階段要解決的問(wèn)題，主要是如何通過(guò)服務(wù)治理、系統(tǒng)運(yùn)維自動(dòng)化提升可靠性和可用性，如何高效完成大項(xiàng)目的復(fù)雜協(xié)作，如何梳理功能、深化用戶體驗(yàn)。以正在進(jìn)行全面服務(wù)化的網(wǎng)易考拉為例，2017年雙11期間其工程數(shù)量相對(duì)平時(shí)增加了20多倍，應(yīng)用、存儲(chǔ)集群規(guī)模膨脹了5倍，挑戰(zhàn)之大不必多說(shuō)。劉超對(duì)成熟階段架構(gòu)設(shè)計(jì)強(qiáng)調(diào)了兩點(diǎn)：

不可變基礎(chǔ)設(shè)施：使用Kubernetes容器技術(shù)不能沿襲虛擬機(jī)時(shí)代的操作方式，而是應(yīng)當(dāng)采用不可變基礎(chǔ)設(shè)施，即所有的改變，都應(yīng)該在Git的改變里面有所體現(xiàn)，修改環(huán)境就是修改Dockerfile，修改配置文件也是代碼層次的改變，整個(gè)環(huán)境的部署，當(dāng)代碼merge的時(shí)候，會(huì)觸發(fā)通過(guò)容器自動(dòng)部署的腳本，這能很好地保持環(huán)境的一致性。大規(guī)模節(jié)點(diǎn)下，如果是手動(dòng)部署，出錯(cuò)很容易，排查卻很難。所以，不可變基礎(chǔ)設(shè)施非常重要。

IaC（基礎(chǔ)設(shè)施即代碼）部署與擴(kuò)容：網(wǎng)易云在Kubernetes的編排之外封裝了另一個(gè)編排，也是在倉(cāng)庫(kù)里面維護(hù)的，任何的修改，比如要升級(jí)5個(gè)應(yīng)用，這5個(gè)應(yīng)用的版本號(hào)都在這里面都配置好，代碼commit之后就觸發(fā)自動(dòng)部署，如果發(fā)現(xiàn)問(wèn)題，很容易回滾，只需把代碼revert回來(lái)，后續(xù)流程會(huì)自動(dòng)觸發(fā)。如果依賴于寫(xiě)Yaml文件來(lái)做，頻繁升級(jí)且版本號(hào)控制不好時(shí)，就很容易回滾失誤。

場(chǎng)景四：Kubernetes+Docker+PM+Overlay Network

成熟階段通常使用Kubernetes+Docker+PM+Overlay Network的模式，企業(yè)一旦開(kāi)始用Overlay Network，基本上都會(huì)使用物理機(jī)，否則使用虛擬機(jī)會(huì)出現(xiàn)兩層Overlay。這時(shí)候Flannel、Calico、Romana或者Weave等很多的選型都可以，F(xiàn)lannel的性能已經(jīng)越來(lái)越好。

場(chǎng)景五：Kubernetes和IaaS層深度融合

網(wǎng)易云的方式，是Kubernetes與IaaS深度融合實(shí)現(xiàn)動(dòng)態(tài)擴(kuò)展資源，目前集群調(diào)度規(guī)模支持30000+節(jié)點(diǎn)。這個(gè)規(guī)模下，首先要解決的是動(dòng)態(tài)資源創(chuàng)建優(yōu)化，這樣才符合資源精細(xì)利用、成本最優(yōu)化的設(shè)計(jì)。同時(shí)，不論虛擬機(jī)的創(chuàng)建還是容器的創(chuàng)建，對(duì)應(yīng)用都是透明的，也就是說(shuō)，應(yīng)用只需要明確一個(gè)模塊要變成3個(gè)節(jié)點(diǎn)還是5個(gè)節(jié)點(diǎn)，不需要管Docker是不是要變成多少個(gè)節(jié)點(diǎn)、這些節(jié)點(diǎn)要放在哪里、虛擬機(jī)和物理機(jī)是否有資源之類(lèi)的問(wèn)題，后續(xù)的動(dòng)作都是聯(lián)動(dòng)的。

動(dòng)態(tài)資源創(chuàng)建的實(shí)現(xiàn)，網(wǎng)易云改造了Kubernetes創(chuàng)建流程，主要是監(jiān)聽(tīng)Pod創(chuàng)建的事件，由Resource Controller判斷有沒(méi)有足夠的Volume資源、Network資源，Schedule判斷有沒(méi)有足夠的Node資源，有則直接綁定，無(wú)則動(dòng)態(tài)申請(qǐng)之后再綁定，然后由Kubernetes下發(fā)。添加資源的時(shí)候，只有應(yīng)用層和機(jī)房?jī)蓪?，機(jī)房只需要把物理機(jī)添加到IaaS層，不需要管上面是否有Kubernetes，虛擬機(jī)的創(chuàng)建全部是動(dòng)態(tài)的，應(yīng)用層只管應(yīng)用層的事情，中間都是透明的。

其次是網(wǎng)絡(luò)優(yōu)化。網(wǎng)易云大部分容器是運(yùn)行在虛擬機(jī)上的，同時(shí)也提供采用SR-IOV網(wǎng)卡的裸機(jī)容器，用于需要更高性能的緩存、分布式數(shù)據(jù)庫(kù)等。大部分的應(yīng)用可以橫向擴(kuò)展，還是在IaaS里面。但是網(wǎng)易云希望容器里面的網(wǎng)卡，讓最外層虛擬機(jī)上的OVS也可以看到，即只有一層Overlay，虛擬機(jī)里面有一個(gè)Bridge，但如果不需要，也可以直接打到外面的OVS上，另外還有一個(gè)管理網(wǎng)絡(luò)，跨租戶也是同一個(gè)Kubernetes來(lái)管理。只有一層Overlay意味著沒(méi)有二次的虛擬化，同時(shí)原來(lái)部署在虛擬機(jī)里面的應(yīng)用遷移到容器中，虛擬機(jī)和容器的網(wǎng)絡(luò)都是通過(guò)OVS來(lái)管理，采用Dubbo做服務(wù)發(fā)現(xiàn)會(huì)非常平滑，這是針對(duì)業(yè)務(wù)層壓力的解決方案。其實(shí)OpenStack有一個(gè)CNI插件，也采用了類(lèi)似的做法，和Neutron聯(lián)動(dòng)，把VIF打在外面的OVS上。

小結(jié)

本文結(jié)合網(wǎng)易云服務(wù)內(nèi)外部客戶的Kubernetes實(shí)踐經(jīng)驗(yàn)，總結(jié)了產(chǎn)品高速增長(zhǎng)期和成熟期使用Kubernetes容器技術(shù)實(shí)現(xiàn)微服務(wù)架構(gòu)的五種應(yīng)用場(chǎng)景，針對(duì)不同的挑戰(zhàn)提出了易于執(zhí)行的解決方案，并介紹了網(wǎng)易云的獨(dú)門(mén)優(yōu)化方法，希望對(duì)讀者有所啟發(fā)。

網(wǎng)易云采用 Kubernetes + Docker 構(gòu)建，設(shè)計(jì)思路是讓加速應(yīng)用上云。




網(wǎng)易云計(jì)算基礎(chǔ)服務(wù)為您提供容器服務(wù)，歡迎點(diǎn)擊免費(fèi)試用。




延伸閱讀：

網(wǎng)易考拉海購(gòu)Dubbok框架優(yōu)化詳解

Kubernetes性能測(cè)試實(shí)踐

網(wǎng)易云：微服務(wù)化的數(shù)據(jù)庫(kù)設(shè)計(jì)與讀寫(xiě)分離

網(wǎng)易考拉海購(gòu)：電商高并發(fā)架構(gòu)設(shè)計(jì)的鐵律

微服務(wù)的接入層設(shè)計(jì)與動(dòng)靜資源隔離

微服務(wù)化的基石——持續(xù)集成

網(wǎng)易云基于 Kubernetes 的深度定制化實(shí)踐

網(wǎng)易云原生架構(gòu)實(shí)踐之服務(wù)治理




了解 網(wǎng)易云 ：

網(wǎng)易云官網(wǎng)：https://www.163yun.com/

新用戶大禮包：https://www.163yun.com/gift

網(wǎng)易云社區(qū)：https://sq.163yun.com/