本文由 網易雲 釋出

作為容器叢集管理技術競爭的大贏家，Kubernetes 已經和微服務緊密聯絡，採用 Kubernetes 的企業往往都開始了微服務架構的探索。然而不同企業不同階段的微服務實踐面臨的問題千差萬別，註定要在技術路線上產生分叉。如何選擇適合自己的技術，是每一個踐行微服務團隊面臨的第一個問題。

網易雲是 Kubernetes 的第一批重度使用者，在不同業務場景下解決了很多挑戰，在本文中，網易雲首席解決方案架構師劉超梳理了基於 Kubernetes 構建微服務體系的進階之路。

微服務化的必要性

一個產品的發展，通常可分為冷啟動階段、高速增長階段和成熟階段。

產品冷啟動階段，需求是以最簡單的架構驗證業務。以網易考拉海購（以下簡稱 “考拉”）為例，最初的架構設計目標就是快速啟動，驗證產品方向，該架構包括線上、快取、線下和管理服務四個方面，即一般電商平臺加上跨境電商必備的進銷存系統，採用了 Oracle 資料庫、OpenStack 管理的虛擬機器（VM），並沒有諸如高併發之類的考慮。

產品高速增長階段，業務規模逐漸擴大，產品複雜度也隨著增加，企業需要解決快速迭代、高可靠和高可用等問題，一個自然的選擇是服務化的拆分，把一個單體架構拆分成一些較小的模組，並遵循康威定律，用 5-9 個小團隊來適應架構的變化。仍以考拉為例，考拉在高速增長階段也慢慢演化出各種新的模組，比如單獨的支付模組、貨倉模組、第三方商家模組、推送模組等，並基於 Dubbo 框架打造服務發現功能來支援各模組之間的相互呼叫。

服務化主要解決了變更的問題。在整個架構演進的過程中，各個模組都面臨爆炸性的增長，比如海淘、自營、第三方商家的供應鏈，Web、APP、H5 的呈現，限時購、秒殺、預售的活動頁，以及倉庫與物流系統、支付系統的對接等，緊耦合則牽一髮而動全身，工程臃腫，影響迭代速度，分別獨立上線更有利於適應業務發展的需求。考拉在高速增長階段首先按照主頁、活動頁、優惠券、支付等維度縱向拆分，之後又不斷演進成為 100 多個相互關聯的模組，變更頻率由每天 2 次增長到每天 1000 多次，產品質量提升 52%。

容器化的優勢與挑戰

拆分成大量小模組之後，虛擬機器與服務化架構的配合就出現了很多新的挑戰，於是有了容器化的需求。

劉超解釋說，拆分之前首先要解決“合”的問題，即需要保證功能還是原來的功能，程式碼質量還是原來的程式碼質量，不會引入新的 bug。他認為，微服務化需要從一開始就要做好持續整合，而容器是很好的持續整合工具，完成從程式碼提交到自動測試、自動釋出的工作。容器化會帶來開發流程的變化，把環境交付過程從運維人員提前到開發人員手上。

在架構複雜的情況下，比如 100 多個模組，再加上各種副本，所有環境都由一個運維團隊來完成，不僅工作量繁重，而且還容易出錯，但這是使用虛擬機器的模式。而如果寫一個 Dockerflie 放到程式碼倉庫，由開發人員來考慮開發完成之後應用部署的配置環境、許可權等問題，包括測試環境的部署、聯調環境的部署、生產環境的部署，問題就很好解決了。這就是容器化帶來的流程變化。

然而，這種轉變涉及到開發人員是否願意學習容器技術。劉超推薦的解決辦法，是使用映象分層的形式，即最內部的環境包括作業系統及系統工具的映象由運維人員來做，中間層環境的映象由核心開發人員完成，普通開發人員只需把 jar 或者 war 扔到相應的路徑下即可，這就極大降低企業組織容器化的障礙。

場景一：Kubernetes + Docker + VM + Host Network

第一種場景，就是用 Kubernetes 管理虛擬機器，容器的網路、儲存會面臨各種各樣的選型。企業如果對容器的網路、儲存瞭解不足，可以把容器當成一個持續整合的工具，把一個容器嵌入到一個虛擬機器裡面，相當於用容器映象代替指令碼部署。這種做法需要解決兩個問題：一是 IP 保持的問題，二是盤保持的問題。因為原先採用虛擬機器的時候，是基於有狀態的設計，認為 IP、Volume 都是保持不變的。當容器僅僅作為持續整合的工具，團隊的這個習慣可能改不了。

一個方案是自己實現一個有狀態容器的方式，實現 IP 的保持，當一個節點掛了，重新啟動的虛擬機器和容器仍然可以使用原先分配的 IP，二是把 Docker 容器的映象一層層地 Mount 到外面的 Volume 裡面，當一個節點掛了，Docker 所有的映象和 Volume 其實還掛載在外面的 Ceph 上，資料並未丟失。這和使用 VM 很相似，既可以 Docker 化支援微服務化，也不需要改變使用者習慣。使用 Kubernetes 壓力相對比較大的團隊，可以通過這種方式切入。

場景二：Kubernetes + Docker + PM + Bridge Network

第二種場景，企業沒有使用虛擬機器，有一部分應用部署在物理機（PM）上，同時想把一部分應用遷移到容器裡。此時，不管物理機是否巢狀虛擬機器，直接建立一個 Bridge Network，把物理網絡卡也打進去，當 Docker 的網絡卡和 Bridge 連起來的時候，整個網路就是平的，容器和容器旁邊的物理機都使用同一個指定的網段。網路打平之後，使用 Dubbo 的團隊也可以比較順暢地把一部分物理機上部署的應用逐漸遷移到容器裡，而如果沒有 Bridge Network，中間過負載均衡（LB）或者 NAT 時會很彆扭，因為 Kubernetes 層的維護人員通常很難勸說 Dubbo 層開發人員改變應用開發的方式。

使用 Bridge Network，Kubernetes 網路配置很簡單，使用 CNI 的方式即可。如果有定製化以適應應用層的需求，可以參考 Docker run 的手動配置方式，開發自己的 CNI 外掛。大致流程是先建立網橋（如果不存在），獲取 Namespace，配置 veth pair 並放到 Namespace 裡，然後獲取 IP 地址，獲取網路和路由。

場景三：Kubernetes + Docker + PM + SR-IOV Network

Bridge 的方式，能夠滿足一般的 Java 應用部署的需求，但一些需要更高效能的應用，需要高吞吐量、高併發、高 PPS，比如電商大促情況下的快取，這時候可以採用 SR-IOV 代替 Bridge 來解決問題，頻寬比較大但 PPS 上不去（大包或大量小包）的情況，SR-IOV 都可以解決，但是需要購買 SR-IOV 網絡卡，成本比較高。

高可用設計要點

無狀態：做好持續整合之後，第一件事情應該是把應用分為有狀態（Stateful）和無狀態（Stateless）兩個部分，並且使大部分應用是無狀態的，這樣可以更好地適應彈性伸縮。即便 Kubernetes 已經可以支援有狀態應用的部署，劉超還是建議在應用層儘量實現無狀態，使得有狀態應用聚集在少數的叢集裡面。有狀態最重要的是資料庫和快取，通常記憶體資料放在快取，需要持久化的資料放在資料庫裡。

分散式資料庫：資料庫的高可用，網易雲採用的是 DDB（分散式資料庫）方案，基於 MySQL 的多臺主備及負載均衡做分庫分表，網易雲 RDS 基於自己的 MySQL 核心優化，能夠實現主備切換不丟資料，能夠很好地支援容器化，有狀態容器掛掉之後，重新啟動一個容器，只要做好前序重置和冪等，就不會有業務問題。所以網易雲 RDS 的主備切換也從虛擬機器向容器過渡。

快取：高併發應用需要每一層都有快取，把客戶需求儘可能地攔在前面，吞吐量就大很多。但快取不像資料庫一樣有持久化機制，其高可用、跨機房就需要做雙寫，因為快取保持在記憶體中，掛了就沒有了，修復難度很大。其他的元件，比如 ZooKeeper、Kafka、訊息佇列、HBase，都有各自的高可用機制。所以，一個發展中的應用應當被分成很顯著的兩個部分，一部分是無狀態的，另一部分有狀態的就放到本身具有高可用機制的元件裡面。

成熟階段架構

產品成熟階段要解決的問題，主要是如何通過服務治理、系統運維自動化提升可靠性和可用性，如何高效完成大專案的複雜協作，如何梳理功能、深化使用者體驗。以正在進行全面服務化的考拉為例，2017 年雙 11 期間其工程數量相對平時增加了 20 多倍，應用、儲存叢集規模膨脹了 5 倍，挑戰之大不必多說。劉超對成熟階段架構設計強調了兩點：

不可變基礎設施：使用 Kubernetes 容器技術不能沿襲虛擬機器時代的操作方式，而是應當採用不可變基礎設施，即所有的改變，都應該在 Git 的改變裡面有所體現，修改環境就是修改 Dockerfile，修改配置檔案也是程式碼層次的改變，整個環境的部署，當代碼 merge 的時候，會觸發通過容器自動部署的指令碼，這能很好地保持環境的一致性。大規模節點下，如果是手動部署，出錯很容易，排查卻很難。所以，不可變基礎設施非常重要。

IaC（基礎設施即程式碼）部署與擴容：網易雲在 Kubernetes 的編排之外封裝了另一個編排，也是在倉庫裡面維護的，任何的修改，比如要升級 5 個應用，這 5 個應用的版本號都在這裡面都配置好，程式碼 commit 之後就觸發自動部署，如果發現問題，很容易回滾，只需把程式碼 revert 回來，後續流程會自動觸發。如果依賴於寫 Yaml 檔案來做，頻繁升級且版本號控制不好時，就很容易回滾失誤。

場景四：Kubernetes + Docker + PM + Overlay Network

成熟階段通常使用Kubernetes+Docker+PM+Overlay Network 的模式，企業一旦開始用 Overlay Network，基本上都會使用物理機，否則使用虛擬機器會出現兩層 Overlay。這時候 Flannel、Calico、Romana 或者 Weave 等很多的選型都可以，Flannel 的效能已經越來越好。

場景五：Kubernetes 和 IaaS 層深度融合

網易雲的方式，是 Kubernetes 與 IaaS 深度融合實現動態擴充套件資源，目前叢集排程規模支援 30000+ 節點。這個規模下，首先要解決的是動態資源建立優化，這樣才符合資源精細利用、成本最優化的設計。同時，不論虛擬機器的建立還是容器的建立，對應用都是透明的，也就是說，應用只需要明確一個模組要變成 3 個節點還是 5 個節點，不需要管 Docker 是不是要變成多少個節點、這些節點要放在哪裡、虛擬機器和物理機是否有資源之類的問題，後續的動作都是聯動的。

動態資源建立的實現，網易雲改造了 Kubernetes 建立流程，主要是監聽 Pod 建立的事件，由 Resource Controller 判斷有沒有足夠的 Volume 資源、Network 資源，Schedule 判斷有沒有足夠的 Node 資源，有則直接繫結，無則動態申請之後再繫結，然後由 Kubernetes 下發。新增資源的時候，只有應用層和機房兩層，機房只需要把物理機新增到 IaaS 層，不需要管上面是否有 Kubernetes，虛擬機器的建立全部是動態的，應用層只管應用層的事情，中間都是透明的。

其次是網路優化。網易雲大部分容器是執行在虛擬機器上的，同時也提供採用 SR-IOV 網絡卡的裸機容器，用於需要更高效能的快取、分散式資料庫等。大部分的應用可以橫向擴充套件，還是在 IaaS 裡面。但是網易雲希望容器裡面的網絡卡，讓最外層虛擬機器上的 OVS 也可以看到，即只有一層 Overlay，虛擬機器裡面有一個 Bridge，但如果不需要，也可以直接打到外面的 OVS 上，另外還有一個管理網路，跨租戶也是同一個 Kubernetes 來管理。只有一層 Overlay 意味著沒有二次的虛擬化，同時原來部署在虛擬機器裡面的應用遷移到容器中，虛擬機器和容器的網路都是通過 OVS 來管理，採用 Dubbo 做服務發現會非常平滑，這是針對業務層壓力的解決方案。其實 OpenStack 有一個 CNI 外掛，也採用了類似的做法，和 Neutron 聯動，把 VIF 打在外面的 OVS 上。

小結

本文結合網易雲服務內外部客戶的 Kubernetes 實踐經驗，總結了產品高速增長期和成熟期使用 Kubernetes 容器技術實現微服務架構的五種應用場景，針對不同的挑戰提出了易於執行的解決方案，並介紹了網易雲的獨門優化方法，希望對讀者有所啟發。

網易雲採用 Kubernetes + Docker 構建，設計思路是讓加速應用上雲。

瞭解 網易雲 ：