摘要：此文已由作者劉超授權(quán)網(wǎng)易云社區(qū)發(fā)布。五更加適合微服務(wù)和的設(shè)計(jì)好了，說(shuō)了本身，接下來(lái)說(shuō)說(shuō)的理念設(shè)計(jì)，為什么這么適合微服務(wù)。相關(guān)閱讀為什么天然適合微服務(wù)為什么天然適合微服務(wù)為什么天然適合微服務(wù)文章來(lái)源網(wǎng)易云社區(qū)

此文已由作者劉超授權(quán)網(wǎng)易云社區(qū)發(fā)布。

歡迎訪(fǎng)問(wèn)網(wǎng)易云社區(qū)，了解更多網(wǎng)易技術(shù)產(chǎn)品運(yùn)營(yíng)經(jīng)驗(yàn)

四、Kubernetes 本身就是微服務(wù)架構(gòu)

基于上面這十個(gè)設(shè)計(jì)要點(diǎn)，我們?cè)倩貋?lái)看 Kubernetes，會(huì)發(fā)現(xiàn)越看越順眼。

首先 Kubernetes 本身就是微服務(wù)的架構(gòu)，雖然看起來(lái)復(fù)雜，但是容易定制化，容易橫向擴(kuò)展。

如圖黑色的部分是 Kubernetes 原生的部分，而藍(lán)色的部分是網(wǎng)易云為了支撐大規(guī)模高并發(fā)應(yīng)用而做的定制化部分。

Kubernetes 的 API Server 更像網(wǎng)關(guān)，提供統(tǒng)一的鑒權(quán)和訪(fǎng)問(wèn)接口。

眾所周知，Kubernetes 的租戶(hù)管理相對(duì)比較弱，尤其是對(duì)于公有云場(chǎng)景，復(fù)雜的租戶(hù)關(guān)系的管理，我們只要定制化 API Server，對(duì)接 Keystone，就可以管理復(fù)雜的租戶(hù)關(guān)系，而不用管其他的組件。

在 Kubernetes 中幾乎所有的組件都是無(wú)狀態(tài)化的，狀態(tài)都保存在統(tǒng)一的 etcd 里面，這使得擴(kuò)展性非常好，組件之間異步完成自己的任務(wù)，將結(jié)果放在 etcd 里面，互相不耦合。

例如圖中 pod 的創(chuàng)建過(guò)程，客戶(hù)端的創(chuàng)建僅僅是在 etcd 中生成一個(gè)記錄，而其他的組件監(jiān)聽(tīng)到這個(gè)事件后，也相應(yīng)異步的做自己的事情，并將處理的結(jié)果同樣放在 etcd 中，同樣并不是哪一個(gè)組件遠(yuǎn)程調(diào)用 kubelet，命令它進(jìn)行容器的創(chuàng)建，而是發(fā)現(xiàn) etcd 中，pod 被綁定到了自己這里，方才拉起。

為了在公有云中實(shí)現(xiàn)租戶(hù)的隔離性，我們的策略是不同的租戶(hù)，不共享節(jié)點(diǎn)，這就需要 Kubernetes 對(duì)于 IaaS 層有所感知，因而需要實(shí)現(xiàn)自己的 Controller，Kubernetes 的設(shè)計(jì)使得我們可以獨(dú)立創(chuàng)建自己的 Controller，而不是直接改代碼。

API-Server 作為接入層，是有自己的緩存機(jī)制的，防止所有的請(qǐng)求壓力直接到后端數(shù)據(jù)庫(kù)上。但是當(dāng)仍然無(wú)法承載高并發(fā)請(qǐng)求時(shí)，瓶頸依然在后端的 etcd 存儲(chǔ)上，這和電商應(yīng)用一摸一樣。當(dāng)然能夠想到的方式也是對(duì) etcd 進(jìn)行分庫(kù)分表，不同的租戶(hù)保存在不同的 etcd 集群中。

有了 API Server 做 API 網(wǎng)關(guān)，后端的服務(wù)進(jìn)行定制化，對(duì)于 client 和 kubelet 是透明的。

如圖是定制化的容器創(chuàng)建流程，由于大促和非大促期間，節(jié)點(diǎn)的數(shù)目相差比較大，因而不能采用事先全部創(chuàng)建好節(jié)點(diǎn)的方式，這樣會(huì)造成資源的浪費(fèi)，因而中間添加了網(wǎng)易云自己的模塊 Controller 和 IaaS 的管理層，使得當(dāng)創(chuàng)建容器資源不足的時(shí)候，動(dòng)態(tài)調(diào)用 IaaS 的接口，動(dòng)態(tài)的創(chuàng)建資源。這一切對(duì)于客戶(hù)端和 kubelet 無(wú)感知。

為了解決超過(guò) 3 萬(wàn)個(gè)節(jié)點(diǎn)的規(guī)模問(wèn)題，網(wǎng)易云需要對(duì)各個(gè)模塊進(jìn)行優(yōu)化，由于每個(gè)子模塊僅僅完成自己的功能，Scheduler 只管調(diào)度，Proxy 只管轉(zhuǎn)發(fā)，而非耦合在一起，因而每個(gè)組件都可以進(jìn)行獨(dú)立的優(yōu)化，這符合微服務(wù)中的獨(dú)立功能，獨(dú)立優(yōu)化，互不影響。而且 Kubernetes 的所有組件都是 Go 開(kāi)發(fā)的，更加容易一些。所以 Kubernetes 上手慢，但是一旦需要定制化，會(huì)發(fā)現(xiàn)更加容易。

五、Kubernetes 更加適合微服務(wù)和 DevOps 的設(shè)計(jì)

好了，說(shuō)了 K8S 本身，接下來(lái)說(shuō)說(shuō) K8S 的理念設(shè)計(jì)，為什么這么適合微服務(wù)。

前面微服務(wù)設(shè)計(jì)的十大模式，其中一個(gè)就是區(qū)分無(wú)狀態(tài)和有狀態(tài)，在 K8S 中，無(wú)狀態(tài)對(duì)應(yīng) deployment，有狀態(tài)對(duì)應(yīng) StatefulSet。

deployment 主要通過(guò)副本數(shù)，解決橫向擴(kuò)展的問(wèn)題。

而 StatefulSet 通過(guò)一致的網(wǎng)絡(luò) ID，一致的存儲(chǔ)，順序的升級(jí)，擴(kuò)展，回滾等機(jī)制，保證有狀態(tài)應(yīng)用，很好地利用自己的高可用機(jī)制。因?yàn)榇蠖鄶?shù)集群的高可用機(jī)制，都是可以容忍一個(gè)節(jié)點(diǎn)暫時(shí)掛掉的，但是不能容忍大多數(shù)節(jié)點(diǎn)同時(shí)掛掉。而且高可用機(jī)制雖然可以保證一個(gè)節(jié)點(diǎn)掛掉后回來(lái)，有一定的修復(fù)機(jī)制，但是需要知道剛才掛掉的到底是哪個(gè)節(jié)點(diǎn)，StatefulSet 的機(jī)制可以讓容器里面的腳本有足夠的信息，處理這些情況，實(shí)現(xiàn)哪怕是有狀態(tài)，也能盡快修復(fù)。

在微服務(wù)中，比較推薦使用云平臺(tái)的 PaaS，例如數(shù)據(jù)庫(kù)，消息總線(xiàn)，緩存等。但是配置也是非常復(fù)雜的，因?yàn)椴煌沫h(huán)境需要連接不同的 PaaS 服務(wù)。

K8S 里面的 headless service 是可以很好地解決這個(gè)問(wèn)題的，只要給外部服務(wù)創(chuàng)建一個(gè) headless service，指向相應(yīng)的 PaaS 服務(wù)，并且將服務(wù)名配置到應(yīng)用中。由于生產(chǎn)和測(cè)試環(huán)境分成 Namespace，雖然配置了相同的服務(wù)名，但是不會(huì)錯(cuò)誤訪(fǎng)問(wèn)，簡(jiǎn)化了配置。

微服務(wù)少不了服務(wù)發(fā)現(xiàn)，除了應(yīng)用層可以使用 SpringCloud 或者 Dubbo 進(jìn)行服務(wù)發(fā)現(xiàn)，在容器平臺(tái)層當(dāng)然是用 Service了，可以實(shí)現(xiàn)負(fù)載均衡，自修復(fù)，自動(dòng)關(guān)聯(lián)。

服務(wù)編排，本來(lái) K8S 就是編排的標(biāo)準(zhǔn)，可以將 yml 文件放到代碼倉(cāng)庫(kù)中進(jìn)行管理，而通過(guò) deployment 的副本數(shù)，可以實(shí)現(xiàn)彈性伸縮。

對(duì)于配置中心，K8S 提供了 configMap，可以在容器啟動(dòng)的時(shí)候，將配置注入到環(huán)境變量或者 Volume 里面。但是唯一的缺點(diǎn)是，注入到環(huán)境變量中的配置不能動(dòng)態(tài)改變了，好在 Volume 里面的可以，只要容器中的進(jìn)程有 reload 機(jī)制，就可以實(shí)現(xiàn)配置的動(dòng)態(tài)下發(fā)了。

統(tǒng)一日志和監(jiān)控往往需要在 Node 上部署 Agent，來(lái)對(duì)日志和指標(biāo)進(jìn)行收集，當(dāng)然每個(gè) Node 上都有，daemonset 的設(shè)計(jì)，使得更容易實(shí)現(xiàn)。

當(dāng)然目前最最火的 Service Mesh，可以實(shí)現(xiàn)更加精細(xì)化的服務(wù)治理，進(jìn)行熔斷，路由，降級(jí)等策略。Service Mesh 的實(shí)現(xiàn)往往通過(guò) sidecar 的方式，攔截服務(wù)的流量，進(jìn)行治理。這也得力于 Pod 的理念，一個(gè) Pod 可以有多個(gè)容器，如果當(dāng)初的設(shè)計(jì)沒(méi)有 Pod，直接啟動(dòng)的就是容器，會(huì)非常的不方便。

所以 K8S 的各種設(shè)計(jì)，看起來(lái)非常冗余和復(fù)雜，入門(mén)門(mén)檻比較高，但是一旦想實(shí)現(xiàn)真正的微服務(wù)，K8S 可以給你各種可能的組合方式。實(shí)踐過(guò)微服務(wù)的人，往往會(huì)對(duì)這一點(diǎn)深有體會(huì)。

六、Kubernetes 常見(jiàn)的使用方式

下面我們來(lái)看一下，微服務(wù)化的不同階段，Kubernetes 的使用方式。

第一階段：使用公有云虛擬機(jī)

也即沒(méi)有微服務(wù)化的階段，基本上一個(gè)進(jìn)程就能搞定，兩個(gè)進(jìn)程做高可用，不需要使用容器，虛擬機(jī)就非常好。

第二階段：容器作為持續(xù)集成工具

當(dāng)微服務(wù)開(kāi)始拆分了，如何保證拆分后功能的一致性，需要持續(xù)集成作為保證，如前面的論述，容器是非常好的持續(xù)集成工具，是解決 CI/CD 中 D 的，所以一開(kāi)始用 host 網(wǎng)絡(luò)就可以，這樣可以保證部署方式和原來(lái)兼容。

如果想用私有云進(jìn)行部署，直接部署在物理機(jī)上，在性能要求沒(méi)有很高，但是又要和其他物理機(jī)很好的通信的情況下，可以用 bridge 打平網(wǎng)絡(luò)的方式比較好。通過(guò)創(chuàng)建網(wǎng)橋，將物理網(wǎng)卡，容器網(wǎng)卡都連接到一個(gè)網(wǎng)橋上，可以實(shí)現(xiàn)所有的容器和物理機(jī)在同樣的一個(gè)二層網(wǎng)絡(luò)里面。

如果性能要求比較高，例如要部署類(lèi)似緩存，則可以使用 sr-iov 網(wǎng)卡。

如果想實(shí)現(xiàn)租戶(hù)的簡(jiǎn)單隔離，則往往使用各種 Overlay 的網(wǎng)絡(luò)模式，這是最常用的部署方式。圖中的數(shù)據(jù)來(lái)自網(wǎng)絡(luò)。Flannel，Calico 都是非常好的網(wǎng)絡(luò)插件，雖然 Flannel 一開(kāi)始使用用戶(hù)態(tài)的模式性能不好，后來(lái)使用內(nèi)核態(tài)，性能大大改善，使用 gw 模式后，和 Calico 性能相當(dāng)。

網(wǎng)易云采用了 Kubernetes 和 IaaS 深度融合的方式，類(lèi)似 AWS 的 Fargate 的模式，一方面可以使得原來(lái)使用虛擬機(jī)的用戶(hù)平滑地遷移到容器，另一方面可以實(shí)現(xiàn)公有云的租戶(hù)隔離。

如圖是融合的網(wǎng)易云容器服務(wù)的架構(gòu)，這個(gè)管理 OpenStack 和 Kubernetes 的管理平臺(tái)，也是用的微服務(wù)架構(gòu)，有 API 網(wǎng)關(guān)，熔斷限流功能，拆分成不同的服務(wù)，部署在 K8S 上的，所以處處是微服務(wù)。

網(wǎng)易云輕舟微服務(wù)是圍繞應(yīng)用和微服務(wù)打造的一站式 PaaS 平臺(tái)，幫助用戶(hù)快速實(shí)現(xiàn)易接入、易運(yùn)維的微服務(wù)解決方案。

相關(guān)閱讀：為什么 kubernetes 天然適合微服務(wù) (1)

為什么 kubernetes 天然適合微服務(wù) （2）

為什么 kubernetes 天然適合微服務(wù) （3）

文章來(lái)源： 網(wǎng)易云社區(qū)