摘要：本文是網(wǎng)易容器云平臺(tái)的微服務(wù)化實(shí)踐系列文章的第一篇。網(wǎng)易容器云平臺(tái)的前身是網(wǎng)易應(yīng)用自動(dòng)部署平臺(tái)，它能夠利用云提供的基礎(chǔ)設(shè)施，實(shí)現(xiàn)包括構(gòu)建和部署一體化在內(nèi)的整個(gè)應(yīng)用生命周期管理。目前網(wǎng)易云容器服務(wù)團(tuán)隊(duì)以的方式管理著微服務(wù)，每周構(gòu)建部署次數(shù)。

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

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

摘要：網(wǎng)易云容器平臺(tái)期望能給實(shí)施了微服務(wù)架構(gòu)的團(tuán)隊(duì)提供完整的解決方案和閉環(huán)的用戶體驗(yàn)，為此從 2016 年開(kāi)始，我們?nèi)萜鞣?wù)團(tuán)隊(duì)內(nèi)部率先開(kāi)始進(jìn)行 dogfooding 實(shí)踐，看看容器云平臺(tái)能不能支撐得起容器服務(wù)本身的微服務(wù)架構(gòu)，這是一次很有趣的嘗試。

一旦決定做微服務(wù)架構(gòu)，有很多現(xiàn)實(shí)問(wèn)題擺在面前，比如技術(shù)選型、業(yè)務(wù)拆分問(wèn)題、高可用、服務(wù)通信、服務(wù)發(fā)現(xiàn)和治理、集群容錯(cuò)、配置管理、數(shù)據(jù)一致性問(wèn)題、康威定律、分布式調(diào)用跟蹤、CI/CD、微服務(wù)測(cè)試，以及調(diào)度和部署等等，這并非一些簡(jiǎn)單招數(shù)能夠化解。實(shí)踐微服務(wù)架構(gòu)的方式有千萬(wàn)種，我們探索并實(shí)踐了其中的一種可能性，希望可以給大家一個(gè)參考。本文是《網(wǎng)易容器云平臺(tái)的微服務(wù)化實(shí)踐》系列文章的第一篇。

Docker 容器技術(shù)已經(jīng)過(guò)了最早的喧囂期，逐漸在各大公司和技術(shù)團(tuán)隊(duì)中應(yīng)用。盡管以今天來(lái)看，大家從觀念上已經(jīng)逐漸認(rèn)可 “將鏡像定義為應(yīng)用交付標(biāo)準(zhǔn)，將容器作為應(yīng)用運(yùn)行的標(biāo)準(zhǔn)環(huán)境” 的觀點(diǎn)，但還是有相當(dāng)一部分人在迷惑容器技術(shù)作為一個(gè)標(biāo)準(zhǔn)，應(yīng)該怎么落地，怎樣才能大規(guī)模線上應(yīng)用，怎么玩才能真正解放生產(chǎn)力，促進(jìn)軟件交付效率和質(zhì)量？答案其實(shí)在應(yīng)用的架構(gòu)當(dāng)中。

微服務(wù)架構(gòu)不是因 Docker 容器技術(shù)而生，但確實(shí)是因容器技術(shù)而火。容器技術(shù)提供了一致性的分發(fā)手段和運(yùn)行環(huán)境，使得只有微服務(wù)化后的應(yīng)用架構(gòu)，才能配合容器發(fā)揮其最大價(jià)值。而微服務(wù)化架構(gòu)引入了很大的復(fù)雜性，只有應(yīng)用容器化以及規(guī)?；娜萜骶幣排c調(diào)度才能避免運(yùn)維效率下降。容器技術(shù)和微服務(wù)化架構(gòu)之間本是一種相輔相成的互補(bǔ)關(guān)系。

網(wǎng)易容器云平臺(tái)的前身是網(wǎng)易應(yīng)用自動(dòng)部署平臺(tái) (OMAD)，它能夠利用 IaaS 云提供的基礎(chǔ)設(shè)施，實(shí)現(xiàn)包括構(gòu)建和部署一體化在內(nèi)的整個(gè)應(yīng)用生命周期管理。2014 年，以 Docker 為代表的容器技術(shù)進(jìn)入大眾視野，我們驚喜地發(fā)現(xiàn)，容器技術(shù)是自動(dòng)部署平臺(tái)從工具型應(yīng)用進(jìn)化為平臺(tái)型應(yīng)用過(guò)程中最重要的一塊拼圖。原本用戶需要初始化主機(jī)，然后借助自動(dòng)部署平臺(tái)完成應(yīng)用的構(gòu)建和部署。引入容器技術(shù)之后，用戶從功能開(kāi)發(fā)到測(cè)試到一鍵部署上線，整個(gè)應(yīng)用交付過(guò)程中不用關(guān)心主機(jī)初始化、主機(jī)間通信、實(shí)例調(diào)度等一系列應(yīng)用之外的問(wèn)題。這簡(jiǎn)直是信仰 DevOps 的人的福音。

我們從 2015 年開(kāi)始探索容器技術(shù)的最佳實(shí)踐方式，從當(dāng)初 “胖容器” 與容器集群的產(chǎn)品形態(tài)，到后來(lái)關(guān)于有狀態(tài)和無(wú)狀態(tài)服務(wù)的定義，以及如今的新計(jì)算與高性能計(jì)算，我們一直在思考并豐富著容器技術(shù)的應(yīng)用場(chǎng)景。無(wú)論產(chǎn)品形態(tài)如何調(diào)整，容器云平臺(tái)的核心概念一直是 “微服務(wù)”，通過(guò)微服務(wù)這一抽象提供高性能的容器集群管理方案，支持彈性伸縮、垂直擴(kuò)容、灰度升級(jí)、服務(wù)發(fā)現(xiàn)、服務(wù)編排、錯(cuò)誤恢復(fù)、性能監(jiān)測(cè)等功能，滿足用戶提升應(yīng)用交付效率和快速響應(yīng)業(yè)務(wù)變化的需求。網(wǎng)易云容器平臺(tái)期望能給實(shí)施了微服務(wù)架構(gòu)的團(tuán)隊(duì)提供完整的解決方案和閉環(huán)的用戶體驗(yàn)，為此從 2016 年開(kāi)始，我們?nèi)萜鞣?wù)團(tuán)隊(duì)內(nèi)部率先開(kāi)始進(jìn)行 dogfooding 實(shí)踐，一方面檢驗(yàn)容器云平臺(tái)能不能支撐得起容器服務(wù)本身的微服務(wù)架構(gòu)，另一方面通過(guò)微服務(wù)化實(shí)踐經(jīng)驗(yàn)反哺容器云平臺(tái)產(chǎn)品設(shè)計(jì)，這是一次很有趣的嘗試，也是我們分享容器云平臺(tái)微服務(wù)化架構(gòu)實(shí)踐的初衷。

在談容器服務(wù)的微服務(wù)架構(gòu)實(shí)踐之前，有必要先把網(wǎng)易云容器服務(wù)大致做個(gè)介紹。目前網(wǎng)易云容器服務(wù)團(tuán)隊(duì)以 DevOps 的方式管理著30+微服務(wù)，每周構(gòu)建部署次數(shù) 400+。網(wǎng)易云容器服務(wù)架構(gòu)從邏輯上看由 4 個(gè)層次組成，從下到上分別是基礎(chǔ)設(shè)施層、Docker 容器引擎層、Kubernetes （以下簡(jiǎn)稱 K8S）容器編排層、DevOps 和自動(dòng)化工具層：

容器云平臺(tái)整體業(yè)務(wù)架構(gòu)如下：

拋開(kāi)容器服務(wù)具體業(yè)務(wù)不談，僅從業(yè)務(wù)特征來(lái)說(shuō)，可以分成以下多種類型（括號(hào)內(nèi)為舉例的微服務(wù)）：

○ 面向終端用戶 （OpenAPI 服務(wù)網(wǎng)關(guān)）、面向服務(wù)（裸機(jī)服務(wù)）
○ 同步通信（用戶中心）、異步通信（構(gòu)建服務(wù)）
○ 數(shù)據(jù)強(qiáng)一致需求（etcd 同步服務(wù)）、最終一致需求（資源回收服務(wù)）
○ 吞吐量敏感型（日志服務(wù)）、延時(shí)敏感型（實(shí)時(shí)服務(wù)）
○ CPU 計(jì)算密集型（簽名認(rèn)證中心）、網(wǎng)絡(luò) IO 密集型（鏡像倉(cāng)庫(kù)）
○ 在線業(yè)務(wù)（Web 服務(wù)）、離線業(yè)務(wù)（鏡像檢查）
○ 批處理任務(wù)（計(jì)費(fèi)日志推送）、定時(shí)任務(wù)（分布式定時(shí)任務(wù)）
○ 長(zhǎng)連接（WebSocket 服務(wù)網(wǎng)關(guān)）、短連接（Hook 服務(wù)）
○ ……

一旦決定做微服務(wù)架構(gòu)，有很多現(xiàn)實(shí)問(wèn)題擺在面前，比如技術(shù)選型、業(yè)務(wù)拆分問(wèn)題、高可用、服務(wù)通信、服務(wù)發(fā)現(xiàn)和治理、集群容錯(cuò)、配置管理、數(shù)據(jù)一致性問(wèn)題、康威定律、分布式調(diào)用跟蹤、CI/CD、微服務(wù)測(cè)試，以及調(diào)度和部署等等……這并非一些簡(jiǎn)單招數(shù)能夠化解。

作為主要編程語(yǔ)言是 Java 的容器服務(wù)來(lái)說(shuō)，選擇 Spring Cloud 去搭配 K8S 是一個(gè)很自然的事情。Spring Cloud 和 K8S 都是很好的微服務(wù)開(kāi)發(fā)和運(yùn)行框架。從應(yīng)用的生命周期角度來(lái)看，K8S 覆蓋了更廣的范圍，特別像資源管理，應(yīng)用編排、部署與調(diào)度等，Spring Cloud 則對(duì)此無(wú)能為力。從功能上看，兩者存在一定程度的重疊，比如服務(wù)發(fā)現(xiàn)、負(fù)載均衡、配置管理、集群容錯(cuò)等方面，但兩者解決問(wèn)題的思路完全不同，Spring Cloud 面向的純粹是開(kāi)發(fā)者，開(kāi)發(fā)者需要從代碼級(jí)別考慮微服務(wù)架構(gòu)的方方面面，而 K8S 面向的是 DevOps 人員，提供的是通用解決方案，它試圖將微服務(wù)相關(guān)的問(wèn)題都在平臺(tái)層解決，對(duì)開(kāi)發(fā)者屏蔽復(fù)雜性。舉個(gè)簡(jiǎn)單的例子，關(guān)于服務(wù)發(fā)現(xiàn)，Spring Cloud 給出的是傳統(tǒng)的帶注冊(cè)中心 Eureka 的解決方案，需要開(kāi)發(fā)者維護(hù) Eureka 服務(wù)器的同時(shí)，改造服務(wù)調(diào)用方與服務(wù)提供方代碼以接入服務(wù)注冊(cè)中心，開(kāi)發(fā)者需關(guān)心基于 Eureka 實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)的所有細(xì)節(jié)。而 K8S 提供的是一種去中心化方案，抽象了服務(wù) （Service），通過(guò) DNS+ClusterIP+iptables 解決服務(wù)暴露和發(fā)現(xiàn)問(wèn)題，對(duì)服務(wù)提供方和服務(wù)調(diào)用方而言完全沒(méi)有侵入。

對(duì)于技術(shù)選型，我們有自己的考量，優(yōu)先選擇更穩(wěn)定的方案，畢竟穩(wěn)定性是云計(jì)算的生命線。我們并不是 “K8S 原教旨主義者”，對(duì)于前面提到的微服務(wù)架構(gòu)的各要點(diǎn)，我們有選擇基于 K8S 實(shí)現(xiàn)，比如服務(wù)發(fā)現(xiàn)、負(fù)載均衡、高可用、集群容錯(cuò)、調(diào)度與部署等。有選擇使用 Spring Cloud 提供的方案，比如同步的服務(wù)間通信；也有結(jié)合兩者的優(yōu)勢(shì)共同實(shí)現(xiàn)，比如服務(wù)的故障隔離和熔斷；當(dāng)然，也有基于一些成熟的第三方方案和自研系統(tǒng)實(shí)現(xiàn)，比如配置管理、日志采集、分布式調(diào)用跟蹤、流控系統(tǒng)等。

我們利用 K8S 管理微服務(wù)帶來(lái)的最大改善體現(xiàn)在調(diào)度和部署效率上。以我們當(dāng)前的情況來(lái)看，不同的服務(wù)要求部署在不同的機(jī)房和集群（聯(lián)調(diào)環(huán)境、測(cè)試環(huán)境、預(yù)發(fā)布環(huán)境、生產(chǎn)環(huán)境等），有著不同需求的軟硬件配置（內(nèi)存、SSD、安全、海外訪問(wèn)加速等），這些需求已經(jīng)較難通過(guò)傳統(tǒng)的自動(dòng)化工具實(shí)現(xiàn)。K8S 通過(guò)對(duì) Node 主機(jī)進(jìn)行 Label 化管理，我們只要指定服務(wù)屬性 （Pod label），K8S 調(diào)度器根據(jù) Pod 和 Node Label 的匹配關(guān)系，自動(dòng)將服務(wù)部署到滿足需求的 Node 主機(jī)上，簡(jiǎn)單而高效。內(nèi)置滾動(dòng)升級(jí)策略，配合健康檢查 （liveness 和 readiness 探針）和 lifecycle hook 可以完成服務(wù)的不停服更新和回滾。此外，通過(guò)配置相關(guān)參數(shù)還可以實(shí)現(xiàn)服務(wù)的藍(lán)綠部署和金絲雀部署。集群容錯(cuò)方面，K8S 通過(guò)副本控制器維持服務(wù)副本數(shù) （replica），無(wú)論是服務(wù)實(shí)例故障（進(jìn)程異常退出、oom-killed 等）還是 Node 主機(jī)故障（系統(tǒng)故障、硬件故障、網(wǎng)絡(luò)故障等），服務(wù)副本數(shù)能夠始終保持在固定數(shù)量。

Docker 通過(guò)分層鏡像創(chuàng)造性地解決了應(yīng)用和運(yùn)行環(huán)境的一致性問(wèn)題，但是通常來(lái)講，不同環(huán)境下的服務(wù)的配置是不一樣的。配置的不同使得開(kāi)發(fā)環(huán)境構(gòu)建的鏡像無(wú)法直接在測(cè)試環(huán)境使用，QA 在測(cè)試環(huán)境驗(yàn)證過(guò)的鏡像無(wú)法直接部署到線上……導(dǎo)致每個(gè)環(huán)境的 Docker 鏡像都要重新構(gòu)建。解決這個(gè)問(wèn)題的思路無(wú)非是將配置信息提取出來(lái)，以環(huán)境變量的方式在 Docker 容器啟動(dòng)時(shí)注入，K8S 也給出了 ConfigMap 這樣的解決方案，但這種方式有一個(gè)問(wèn)題，配置信息變更后無(wú)法實(shí)時(shí)生效。我們采用的是使用 Disconf 統(tǒng)一配置中心解決。配置統(tǒng)一托管后，從開(kāi)發(fā)環(huán)境構(gòu)建的容器鏡像，可以直接提交到測(cè)試環(huán)境測(cè)試，QA 驗(yàn)證通過(guò)后，上到演練環(huán)境、預(yù)發(fā)布環(huán)境和生產(chǎn)環(huán)境。一方面避免了重復(fù)的應(yīng)用打包和 Docker 鏡像構(gòu)建，另一方面真正實(shí)現(xiàn)了線上線下應(yīng)用的一致性。

Spring Cloud Hystrix 在我們的微服務(wù)治理中扮演了重要角色，我們對(duì)它做了二次開(kāi)發(fā)，提供更靈活的故障隔離、降級(jí)和熔斷策略，滿足 API 網(wǎng)關(guān)等服務(wù)的特殊業(yè)務(wù)需求。進(jìn)程內(nèi)的故障隔離僅是服務(wù)治理的一方面，另一方面，在一個(gè)應(yīng)用混部的主機(jī)上，應(yīng)用間應(yīng)該互相隔離，避免進(jìn)程間互搶資源，影響業(yè)務(wù) SLA。比如絕對(duì)要避免一個(gè)離線應(yīng)用失控占用了大量 CPU，使得同主機(jī)的在線應(yīng)用受影響。我們通過(guò) K8S 限制了容器運(yùn)行時(shí)的資源配額（以 CPU 和內(nèi)存限制為主），實(shí)現(xiàn)了進(jìn)程間的故障和異常隔離。K8S 提供的集群容錯(cuò)、高可用、進(jìn)程隔離，配合 Spring Cloud Hystrix 提供的故障隔離和熔斷，能夠很好地實(shí)踐 “Design for Failure” 設(shè)計(jì)哲學(xué)。

服務(wù)拆分的好壞直接影響了實(shí)施微服務(wù)架構(gòu)的收益大小。服務(wù)拆分的難點(diǎn)往往在于業(yè)務(wù)邊界不清晰、歷史遺留系統(tǒng)改造難、數(shù)據(jù)一致性問(wèn)題、康威定律等。從我們經(jīng)驗(yàn)來(lái)看，對(duì)于前兩個(gè)問(wèn)題解決思路是一樣的：1）只拆有確定邊界能獨(dú)立的業(yè)務(wù)。2）服務(wù)拆分本質(zhì)上是數(shù)據(jù)模型的拆分，上層應(yīng)用經(jīng)得起倒騰，底層數(shù)據(jù)模型經(jīng)不起倒騰。對(duì)于邊界模糊的業(yè)務(wù)，即使要拆，只拆應(yīng)用不拆數(shù)據(jù)庫(kù)。

以下是我們從主工程里平滑拆出用戶服務(wù)的示例步驟：

1.將用戶相關(guān)的 UserService、UserDAO 分離出主工程，加上 UserController、UserDTO 等，形成用戶服務(wù)，對(duì)外暴露 HTTP RESTful API。
2.將主工程用戶相關(guān)的 UserService 類替換成 UserFa?ade 類，采用 Spring Cloud Feign 的注解，調(diào)用用戶服務(wù) API。
3.主工程所有依賴 UserServce 接口的地方，改為依賴 UserFa?ade 接口，平滑過(guò)渡。

經(jīng)過(guò)以上三個(gè)步驟, 用戶服務(wù)獨(dú)立成一個(gè)微服務(wù)，而整個(gè)系統(tǒng)代碼的復(fù)雜性幾乎沒(méi)有增加。

數(shù)據(jù)一致性問(wèn)題在分布式系統(tǒng)中普遍存在，微服務(wù)架構(gòu)下會(huì)將問(wèn)題放大，這也從另一個(gè)角度說(shuō)明合理拆分業(yè)務(wù)的重要性。我們碰到的大部分?jǐn)?shù)據(jù)一致性場(chǎng)景都是可以接受最終一致的?！岸〞r(shí)任務(wù)重試+冪等” 是解決這類問(wèn)題的一把瑞士軍刀，為此我們開(kāi)發(fā)了一套獨(dú)立于具體業(yè)務(wù)的 “分布式定時(shí)任務(wù)+可靠事件” 處理框架，將任何需保證數(shù)據(jù)最終一致的操作定義為一種事件，比如用戶初始化、實(shí)例重建、資源回收、日志索引等業(yè)務(wù)場(chǎng)景。以用戶初始化為例，注冊(cè)一個(gè)用戶后，必須對(duì)其進(jìn)行初始化，初始化過(guò)程是一個(gè)耗時(shí)的異步操作，包含租戶初始化、網(wǎng)絡(luò)初始化、配額初始化等等，這需要協(xié)調(diào)不同的系統(tǒng)來(lái)完成。我們將初始化定義為一種 initTenant 事件，將 initTenant 事件及上下文存入可靠事件表，由分布式定時(shí)任務(wù)觸發(fā)事件執(zhí)行，執(zhí)行成功后，清除該事件記錄；如果執(zhí)行失敗，則定時(shí)任務(wù)系統(tǒng)會(huì)再次觸發(fā)執(zhí)行。對(duì)于某些實(shí)時(shí)性要求較高的場(chǎng)景，則可以先觸發(fā)一次事件處理，再將事件存入可靠事件表。對(duì)于每個(gè)事件處理器來(lái)說(shuō)，要在實(shí)現(xiàn)上確保支持冪等執(zhí)行，實(shí)現(xiàn)冪等執(zhí)行有多種方式，我們有用到布爾型狀態(tài)位，有用到 UUID 做去重處理，也有用到基于版本號(hào)做 CAS。這里不展開(kāi)說(shuō)了。

當(dāng)業(yè)務(wù)邊界與組織架構(gòu)沖突時(shí)，從我們的實(shí)踐經(jīng)驗(yàn)來(lái)看，寧愿選擇更加符合組織架構(gòu)的服務(wù)拆分邊界。這也是一種符合康威定律的做法?？低烧f(shuō)，系統(tǒng)架構(gòu)等同于組織的溝通結(jié)構(gòu)。組織架構(gòu)會(huì)在潛移默化中約束軟件系統(tǒng)架構(gòu)的形態(tài)。違背康威定律，非常容易出現(xiàn)系統(tǒng)設(shè)計(jì)盲區(qū)，出現(xiàn) “兩不管” 互相推脫的局面，我們?cè)趫F(tuán)隊(duì)間、團(tuán)隊(duì)內(nèi)都碰到過(guò)這種情況。
nbsp;
本文是《網(wǎng)易容器云平臺(tái)的微服務(wù)化實(shí)踐》系列文章的第一篇，介紹了容器技術(shù)和微服務(wù)架構(gòu)的關(guān)系，我們做容器云平臺(tái)的目的，以及簡(jiǎn)單介紹了網(wǎng)易云容器服務(wù)基于 Kubernetes 和 Spring Cloud 的微服務(wù)化實(shí)踐經(jīng)驗(yàn)。限于篇幅，有些微服務(wù)架構(gòu)要點(diǎn)并未展開(kāi)，比如服務(wù)通信、服務(wù)發(fā)現(xiàn)和治理、配置管理等話題；有些未提及，比如分布式調(diào)用跟蹤、CI/CD、微服務(wù)測(cè)試等話題，這些方面的實(shí)踐經(jīng)驗(yàn)會(huì)在后續(xù)的系列文章中再做分享。實(shí)踐微服務(wù)架構(gòu)的方式有千萬(wàn)種，我們探索并實(shí)踐了其中的一種可能性，希望可以給大家一個(gè)參考。

網(wǎng)易云計(jì)算基礎(chǔ)服務(wù)深度整合了 IaaS、PaaS 及容器技術(shù)，提供彈性計(jì)算、DevOps 工具鏈及微服務(wù)基礎(chǔ)設(shè)施等服務(wù)，幫助企業(yè)解決 IT、架構(gòu)及運(yùn)維等問(wèn)題，使企業(yè)更聚焦于業(yè)務(wù)，是新一代的云計(jì)算平臺(tái)，點(diǎn)擊可免費(fèi)試用。

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