作者圍繞其這些年在OpenStack、Kubernetes、Microservice、DevOps、Cloud Foundry、ELK等云計(jì)算相關(guān)領(lǐng)域及技術(shù)的實(shí)踐，從微服務(wù)和DevOps兩方面著手，旨在為兩者的落地提供一個(gè)快速可行路徑。針對(duì)這“說(shuō)說(shuō)還可以，一深入討論就吵架”的熱點(diǎn)概念，詳解了在產(chǎn)品研發(fā)過(guò)程中的思考與實(shí)踐，通過(guò)多維度的架構(gòu)與技術(shù)剖析，與大家深入溝通云計(jì)算的企業(yè)級(jí)落地思路。本文是從作者這些年的經(jīng)歷與實(shí)踐出發(fā)的總結(jié)，也歡迎感興趣的同學(xué)參與交流、保持溝通與學(xué)習(xí)。（備注：作者微信二維碼詳見(jiàn)文末）。

（一）服務(wù)與DevOps的認(rèn)識(shí)

現(xiàn)在見(jiàn)客戶就會(huì)聊微服務(wù)、聊DevOps、聊容器，但這種熱點(diǎn)概念，真的是“簡(jiǎn)單聊聊可以，一深入就吵架”，比如以前誰(shuí)問(wèn)我傳統(tǒng)應(yīng)用該怎么拆分，我還會(huì)說(shuō)一堆，現(xiàn)在基本上對(duì)于這種開(kāi)放型問(wèn)題都不敢回答了，怕“沒(méi)朋友”。

我簡(jiǎn)單說(shuō)說(shuō)我對(duì)微服務(wù)和DevOps的認(rèn)知吧：

第一個(gè)就不說(shuō)了，第二個(gè)垂直架構(gòu)，典型的比如SSH框架，幫大家考慮了模塊化、MVC等，但并沒(méi)有考慮服務(wù)化。

第三個(gè)是分布式架構(gòu)，以SOA為代表的這類技術(shù)已經(jīng)熱了很多年，也很成熟，也是目前很多企業(yè)架構(gòu)的主體支撐。

而第四個(gè)以微服務(wù)架構(gòu)為支撐的技術(shù)雖然在一些先進(jìn)企業(yè)或互聯(lián)網(wǎng)公司已經(jīng)運(yùn)用，但從生態(tài)上來(lái)看，還有很長(zhǎng)一段時(shí)間要走，其更強(qiáng)調(diào)在DDD下的業(yè)務(wù)服務(wù)自治性及原子性。

“DevOps”通常指的是新興的專業(yè)化運(yùn)動(dòng)，這種運(yùn)動(dòng)提倡開(kāi)發(fā)和IT運(yùn)維之間的高度協(xié)同，從而在完成高頻率部署的同時(shí)，提高生產(chǎn)環(huán)境的可靠性、穩(wěn)定性、彈性和安全性。

其概念也特別多，簡(jiǎn)單瀏覽下就可以了：DevOps運(yùn)動(dòng)的起源通常被放在2009年前后，伴隨著許多運(yùn)動(dòng)的相輔相成和相互促進(jìn)——效率研討會(huì)運(yùn)動(dòng)，特別是由JohnAllspaw和Paul Hammond展示的開(kāi)創(chuàng)性的“一天10次部署”，基礎(chǔ)設(shè)施即代碼”運(yùn)動(dòng)(Mark Burgess和LukeKanies)，“敏捷基礎(chǔ)設(shè)施運(yùn)動(dòng)”(Andrew Shafer)，“敏捷系系統(tǒng)管理(PatrickDeBois)，“精益創(chuàng)業(yè)”運(yùn)動(dòng)（EricRies），JezHumble的持續(xù)集成和發(fā)布運(yùn)動(dòng)，以及Amazon的“平臺(tái)即服務(wù)運(yùn)動(dòng)”等這些運(yùn)動(dòng)的相輔相成和相互促進(jìn)而發(fā)展起來(lái)的。

那云計(jì)算、微服務(wù)、容器這些概念或能力之間到底是什么關(guān)系呢？其實(shí)這個(gè)主要看大家的方向了，結(jié)合我所面臨的客戶以及IT現(xiàn)狀，我的理解是這樣的：

1. 云基礎(chǔ)平臺(tái)作為底層支撐，既可以是Docker、Unikernel這樣的容器技術(shù)，也可以像vmware或OpenStack這樣以VM為管理單元的方式，旨在為上層提供有SLA能力的資源池管理與調(diào)度；

2. DevOps作為一層可選平臺(tái)，以流程自動(dòng)化、工具自動(dòng)化為主要手段，通過(guò)長(zhǎng)期的積累與優(yōu)化，為最終業(yè)務(wù)交付提供更敏捷、更數(shù)字化的能力；

3. 歷史系統(tǒng)與微服務(wù)在企業(yè)會(huì)長(zhǎng)時(shí)間并存（BiModal），不要試圖一步到位，我所經(jīng)歷的企業(yè)客戶中，都是從部分外圍應(yīng)用開(kāi)始試點(diǎn)，甚至是先拆應(yīng)用、再拆數(shù)據(jù)這樣循序漸進(jìn)的。

（二）平臺(tái)級(jí)的實(shí)踐與支撐

先和大家說(shuō)說(shuō)我們的平臺(tái)具體在做什么：

這個(gè)定位（非市場(chǎng)定位）講起來(lái)比較拗口，“用微服務(wù)架構(gòu)，做云計(jì)算DevOps平臺(tái)，支撐上層微服務(wù)的全生命周期管理”。

這里有個(gè)雞生蛋、蛋生雞的問(wèn)題，那我們還是通過(guò)制定微服務(wù)的規(guī)范以及一部分配套工具，基于這些開(kāi)發(fā)了第一版DevOps云平臺(tái)，將其作為后續(xù)版本的生產(chǎn)線使用。過(guò)程中對(duì)康威定律又有了進(jìn)一步認(rèn)識(shí)，尤其是運(yùn)用在異地協(xié)作和技術(shù)選型上，團(tuán)隊(duì)能力、異地松耦合是必須考慮的維度。

先將平臺(tái)用到的一些技術(shù)棧列出來(lái)：

圖中標(biāo)紅的是目前我們已使用的，相信大家不難看出來(lái)：

1. 我們主要是走的容器云這條線（當(dāng)然傳統(tǒng)的也是支持的），以Kubernetes為容器管理與調(diào)度的框架，結(jié)合Flannel網(wǎng)絡(luò)、Ceph存儲(chǔ)形成底層基礎(chǔ)支撐

2. 微服務(wù)方面使用SpringBoot作為載體，引入了Netflix的部分框架支撐微服務(wù)調(diào)用、配置

3. 在全生命周期中，還支持了文檔、Mock、自動(dòng)化測(cè)試的能力，以便微服務(wù)架構(gòu)下的快速交付

4. 在監(jiān)控方面采用Journald采集，F(xiàn)luentd作為server、同時(shí)通過(guò)索引及時(shí)序庫(kù)支撐數(shù)據(jù)分析及展現(xiàn)

這里有三個(gè)想法與大家共勉：

1. 架構(gòu)師的角色轉(zhuǎn)變，從原來(lái)的技術(shù)貨架的搭建（加法）到現(xiàn)在海量技術(shù)中選擇最合適的（減法），對(duì)能力的要求更高

2. 個(gè)人全棧已經(jīng)不再多見(jiàn)，而團(tuán)隊(duì)全棧卻越來(lái)越重要，學(xué)習(xí)型組織將是未來(lái)衡量團(tuán)隊(duì)能力的一大標(biāo)準(zhǔn)

3. 框架能力的陽(yáng)性與陰性，同樣是結(jié)合現(xiàn)在海量技術(shù)來(lái)看，測(cè)試是必不可少的，但業(yè)務(wù)場(chǎng)景的多變往往會(huì)造成數(shù)據(jù)的片面性，比如Flannel的UDP和Vxlan模式（就像體育賽場(chǎng)上一樣，陽(yáng)性不好，但偽陰性就更糟糕了）

接著分別從微服務(wù)和DevOps方面來(lái)看看我們的一些關(guān)鍵設(shè)計(jì)和想法，先說(shuō)說(shuō)微服務(wù)架構(gòu)：

當(dāng)然微服務(wù)架構(gòu)中重要的不僅僅是上述的5個(gè)能力：

1. 服務(wù)的隔離與互通

2. 伸縮與漂移

3. 升級(jí)與回退

4. 熔斷與降級(jí)

5. 服務(wù)注冊(cè)與發(fā)現(xiàn)

上圖亦可理解為是核心概念模型，面向的問(wèn)題是這樣的：

• 有些企業(yè)會(huì)考慮生產(chǎn)上VM，開(kāi)發(fā)測(cè)試上容器；

• 有些企業(yè)需要開(kāi)發(fā)測(cè)試預(yù)發(fā)上線四套環(huán)境，有些只要兩套：

• 有些企業(yè)環(huán)境間要求完全隔離，有些只要邏輯隔離；

• 有些企業(yè)要求對(duì)接下層資源池，有些則完全沒(méi)有資源池的概念；

• …...

那概念模型上我們?cè)趺崔k？上圖的核心是業(yè)務(wù)運(yùn)行及namespace的設(shè)計(jì)，下層無(wú)論資源有沒(méi)有池化，都需要加一層Namespace的管理，這個(gè)管理有很多目標(biāo)，比如隔離，再比如池化。

然后緊接著是pod，這個(gè)概念參考了Kubernetes，在微服務(wù)運(yùn)行時(shí)，一直強(qiáng)調(diào)一個(gè)業(yè)務(wù)的獨(dú)立性，比如一個(gè)業(yè)務(wù)，其應(yīng)用及數(shù)據(jù)庫(kù)是綁定的，且與其他業(yè)務(wù)隔離。那我們認(rèn)為這種就是一個(gè)pod（豌豆莢），體現(xiàn)的是一個(gè)獨(dú)立業(yè)務(wù)（微服務(wù)）。

一個(gè)pod無(wú)論內(nèi)部如何，一般是跑在一臺(tái)宿主機(jī)的，業(yè)務(wù)內(nèi)部盡量本地調(diào)用，pod可以包括多個(gè)進(jìn)程，也可以包含多個(gè)容器，也就是上圖的pod與process的關(guān)系。

從可靠性及性能考慮，pod必須是集群的，所以一個(gè)pod可以有多個(gè)副本，也就是上圖的pod與replication的關(guān)系。

最終業(yè)務(wù)要能對(duì)外提供能力，類似一個(gè)集群對(duì)外的統(tǒng)一發(fā)布地址，也就是上圖的service的概念，service是外部的訪問(wèn)入口，并擁有一定的負(fù)載均衡能力。

下圖是運(yùn)行時(shí)的調(diào)用過(guò)程示意：

互通要求的是“可達(dá)、快速可達(dá)、安全并快速可達(dá)”。一個(gè)微服務(wù)內(nèi)部可采用本地方式，而微服務(wù)之間采用service地址（無(wú)論內(nèi)部怎么漂移伸縮，對(duì)外地址不變），對(duì)于公網(wǎng)上的調(diào)用，采用宿主機(jī)端口映射出去是個(gè)可選方式，當(dāng)然要結(jié)合底層硬件基礎(chǔ)設(shè)施本身的外網(wǎng)能力，比如阿里還有EIP之類

微服務(wù)的伸縮與漂移，需要與監(jiān)控能力結(jié)合，監(jiān)控結(jié)果判斷則運(yùn)用的是萬(wàn)年不變公式：

以漂移為例子，漂移有很多觸發(fā)器，有因?yàn)楣收系模谢趦?yōu)化考慮的，比如像優(yōu)化漂移這種，就要求定義很多維度，包括資源均衡維度、宿主機(jī)特性維度、標(biāo)簽配置變更維度等，需結(jié)合多維打分對(duì)微服務(wù)進(jìn)行合理調(diào)度。

那對(duì)于伸縮漂移所依賴的能力上，著重考慮下述兩點(diǎn)：

1. 存儲(chǔ)能力，存儲(chǔ)可從服務(wù)狀態(tài)特征考慮，一般來(lái)說(shuō)，有狀態(tài)服務(wù)采用共享存儲(chǔ)，無(wú)狀態(tài)服務(wù)采用非共享或者不適用存儲(chǔ)。

2. 監(jiān)控能力，點(diǎn)線面結(jié)合的監(jiān)控，需注意對(duì)Metrics的正確使用，以及全局流水號(hào)等規(guī)范約束。

微服務(wù)的升級(jí)與回退：

1. 發(fā)布要原子化，可編排，每個(gè)企業(yè)在流程上都會(huì)有所區(qū)別，只有在完全原子化的情況下，才能保證平臺(tái)的快速實(shí)施

2. 標(biāo)簽設(shè)計(jì)，讓每個(gè)動(dòng)作、每個(gè)狀態(tài)、每個(gè)資源都可以標(biāo)識(shí)；標(biāo)簽設(shè)計(jì)不僅僅用于部署，我覺(jué)得在任何產(chǎn)品中都有借鑒意義

3. 狀態(tài)設(shè)計(jì)，部署是原子化的操作，而內(nèi)部的狀態(tài)設(shè)計(jì)同樣重要，比如可結(jié)合狀態(tài)做掛起、喚醒等諸多操作

4. 版本規(guī)范，這個(gè)不僅僅是版本號(hào)的規(guī)范，還包括版本升級(jí)規(guī)范、配置規(guī)范等，不過(guò)微服務(wù)架構(gòu)下，建議全量升級(jí)與回退

5. 路由能力，微服務(wù)這種快速迭代發(fā)布，伴隨試錯(cuò)試對(duì)，快速變更，灰度等，對(duì)流量的出入動(dòng)態(tài)性要求很高

而對(duì)于我們來(lái)說(shuō)，使用了rollingupdate機(jī)制來(lái)進(jìn)行升級(jí)和回退（包括灰度），大家可參考Kubernetes的機(jī)制，一種基于標(biāo)簽和Replication的實(shí)現(xiàn)方法。對(duì)于升級(jí)回退、灰度中，最復(fù)雜的莫過(guò)于數(shù)據(jù)庫(kù)以及前端負(fù)載的處理問(wèn)題：

1. 數(shù)據(jù)庫(kù)簡(jiǎn)單的做法就是類似傳統(tǒng)行業(yè)，尤其像銀行等，只增不減的方式

2. 前端負(fù)載問(wèn)題要結(jié)合業(yè)務(wù)來(lái)實(shí)現(xiàn)，很多企業(yè)會(huì)在Apigateway中考慮，當(dāng)然不同行業(yè)稍有區(qū)別，比如在電力行業(yè)，IBM給規(guī)劃的API基線也有這個(gè)能力

微服務(wù)的熔斷與降級(jí)，當(dāng)然熔斷與降級(jí)并不是一個(gè)概念，只是很多時(shí)候會(huì)一起實(shí)現(xiàn)了：

• 熔斷是指上游服務(wù)在調(diào)用下游服務(wù)時(shí)，因下游服務(wù)的種種問(wèn)題，對(duì)調(diào)用鏈智能處理的手段

• 降級(jí)是指整體資源瓶頸時(shí)，一般業(yè)務(wù)暫停（優(yōu)先保證核心業(yè)務(wù)）的一種處理手段

舉例：熔斷器實(shí)現(xiàn)方式，設(shè)計(jì)參考了一般都使用的三態(tài)設(shè)計(jì)，默認(rèn)關(guān)閉態(tài)，調(diào)用出錯(cuò)率到一定程度半開(kāi)，半開(kāi)時(shí)，允許一部分流量繼續(xù)調(diào)用下游微服務(wù)，如果一定時(shí)間還是出錯(cuò)（這個(gè)時(shí)間可結(jié)合MTTR設(shè)置），就將熔斷器置為全開(kāi)態(tài)，同樣設(shè)置一定的時(shí)間后再嘗試調(diào)用；

現(xiàn)在在熔斷和降級(jí)這塊實(shí)現(xiàn)的比較好的包括netflix的Hystrix，還有motan，大家都可嘗試，我們Hystrix測(cè)試過(guò)，目前使用了motan，僅從能力上對(duì)比，Hystrix無(wú)疑更強(qiáng)大。前段時(shí)間樂(lè)視受攻擊，差不多每秒200G流量，最終能撐下來(lái)?yè)?jù)說(shuō)主要功勞和這個(gè)有關(guān)系。

微服務(wù)的注冊(cè)與發(fā)現(xiàn)，解決微服務(wù)之間的調(diào)用、以及一定的客戶端和服務(wù)端集群的問(wèn)題。采用etcd作為分布式注冊(cè)中心，在服務(wù)啟動(dòng)和停止時(shí)實(shí)現(xiàn)注冊(cè)和注銷，運(yùn)行過(guò)程中，會(huì)定時(shí)同步服務(wù)的元信息（比如流量、健康性等），以便實(shí)現(xiàn)智能路由。

接著，我們來(lái)看看在DevOps實(shí)踐中的一些關(guān)鍵點(diǎn)：

四要素的提法和友商大同小異，包括組織、流程、技術(shù)、文化，下圖會(huì)將四要素進(jìn)行更細(xì)粒度的要素分解。

組織：包括全棧團(tuán)隊(duì)、自治團(tuán)隊(duì)等

流程：包括開(kāi)發(fā)、測(cè)試、集成、交付、度量等

技術(shù)：包括監(jiān)控、ChatOps等

文化：包括協(xié)作、學(xué)習(xí)等

實(shí)現(xiàn)企業(yè)級(jí)DevOps，有很多方式和著手點(diǎn)，比如最常用的就是從持續(xù)發(fā)布開(kāi)始。而我們更聚焦企業(yè)的全生命周期，所以在目前版本中（與上圖有少許不對(duì)應(yīng)），實(shí)現(xiàn)了基于微服務(wù)架構(gòu)的以下15個(gè)DevOps領(lǐng)域系統(tǒng)：

1. IAM：身份識(shí)別與訪問(wèn)管理，通過(guò)OAuth能力，一次登錄，全網(wǎng)通行

2. SPM：軟件產(chǎn)品管理，DevOps平臺(tái)的核心管理對(duì)象：產(chǎn)品。以產(chǎn)品維度為入口，管理包括產(chǎn)品的多版本，每個(gè)版本擁有多個(gè)組件，組件之間、組件與第三方產(chǎn)品之間的依賴關(guān)系等

3. SCM：軟件配置管理，主要是應(yīng)用配置的管理，在編譯打包時(shí)通過(guò)autoconfig技術(shù)，注入到最終部署包

4. SRM：軟件資源管理，資源，即上述產(chǎn)品的運(yùn)行實(shí)例，所以持續(xù)發(fā)布等都是有SRM發(fā)起

5. SEM：軟件環(huán)境管理，企業(yè)環(huán)境千差萬(wàn)別，SEM屏蔽了異構(gòu)環(huán)境的差異性，讓上游系統(tǒng)及業(yè)務(wù)能夠松耦合的運(yùn)行

6. QAF：質(zhì)量保證反饋，這個(gè)系統(tǒng)負(fù)責(zé)收集全生命周期的數(shù)據(jù)反饋，為后續(xù)優(yōu)化演進(jìn)提供重要依據(jù)

7. UMC：統(tǒng)一監(jiān)控中心，主要收集日志及資源運(yùn)行信息，通過(guò)計(jì)算分析，形成相關(guān)報(bào)表，同時(shí)與告警中心對(duì)接，風(fēng)險(xiǎn)異常準(zhǔn)實(shí)時(shí)提示

8. VCS：版本控制系統(tǒng)，默認(rèn)集成GIT

9. CI：持續(xù)集成系統(tǒng)，默認(rèn)集成Jenkins

10. BPR：二進(jìn)制倉(cāng)庫(kù)

11. DPR：可部署包（鏡像）倉(cāng)庫(kù)

12. PM：項(xiàng)目管理系統(tǒng)，可集成redmine或wiki，目前平臺(tái)是自己實(shí)現(xiàn)的

13. IM：團(tuán)隊(duì)間即時(shí)通訊系統(tǒng)

14. TM：租戶管理系統(tǒng)

15. MKT：云市場(chǎng)，平臺(tái)最終期望作為中間平臺(tái)，通過(guò)市場(chǎng)打通內(nèi)容提供者與最終用戶

這里對(duì)一些DevOps的關(guān)鍵系統(tǒng)協(xié)作方式做了一定描述，就不贅述了。

最終這個(gè)平臺(tái)同時(shí)支撐了公有云與私有云兩條線（8月發(fā)布第二版），其中公有云目前運(yùn)行于阿里云上，使用了阿里云的ECS、VPC、EIP等很少的服務(wù)種類；而私有云，目前也在一些企業(yè)開(kāi)始試點(diǎn)。

當(dāng)然，過(guò)程中，尤其是公有云上遇到了不少問(wèn)題，舉兩個(gè)例子：

1. 我們采用coreos系統(tǒng)作為宿主系統(tǒng)，阿里云的版本很低，只能自建升級(jí)服務(wù)器，但升級(jí)后網(wǎng)卡默認(rèn)沒(méi)有啟動(dòng)，且因?yàn)橐恍﹕ervice未啟動(dòng)問(wèn)題，導(dǎo)致無(wú)法快照。

2. 再比如安全組問(wèn)題，同一安全組的ECS完全不控制的方式，讓我們也忙活了很久。

（三）參考與總結(jié)

最后分享下我覺(jué)得比較好的一些可參考材料，并對(duì)分享做下總結(jié)：

這個(gè)不確定最初是不是Gartner提出的，旨在給DevOps從運(yùn)營(yíng)效率、服務(wù)、組織、客戶價(jià)值、業(yè)績(jī)維度評(píng)估，讓企業(yè)發(fā)現(xiàn)其需要改進(jìn)的一些點(diǎn)。

平臺(tái)品質(zhì)屬性，很多時(shí)候翻譯成質(zhì)量屬性，一種屬性分類的方法是把在運(yùn)行時(shí)可識(shí)別的特性與那些不可識(shí)別的特性區(qū)分開(kāi)），另一種方法是把對(duì)用戶很重要的可見(jiàn)特性與對(duì)開(kāi)發(fā)者和維護(hù)者很重要的不可見(jiàn)特性區(qū)分開(kāi)，和CAP類似，這些特性有些可疊加，有些則會(huì)相互制約，在產(chǎn)品設(shè)計(jì)時(shí)需清楚哪些是您最迫切的。

Heroku的12Factor，這些因素為系統(tǒng)的CloudNative目標(biāo)考慮，讓云上云下得到同樣的體驗(yàn)，這12因素不能簡(jiǎn)單的字面理解，要結(jié)合您現(xiàn)在的實(shí)際運(yùn)行來(lái)看，則會(huì)發(fā)現(xiàn)其獨(dú)到的地方，也不要想一蹴而就，只要時(shí)刻有這么根弦，在很多選擇前面看看這12因素是否有類似的可參考，比如當(dāng)時(shí)我們糾結(jié)了很久的，VCS是否使用TBD模式，其實(shí)這里面都可以找到相關(guān)答案。

谷歌的Borg，作為谷歌內(nèi)部的管理調(diào)度核心，支撐著谷歌上萬(wàn)臺(tái)機(jī)器及業(yè)務(wù)的運(yùn)行，這個(gè)雖然是不開(kāi)源的，但其設(shè)計(jì)思路和架構(gòu)是很容易被找到學(xué)習(xí)的。參考這個(gè)的原因是谷歌本身內(nèi)部就是容器與微服務(wù)架構(gòu)的生產(chǎn)運(yùn)用，是一個(gè)真正大規(guī)模的實(shí)踐參考。

掃描二維碼加入由作者主持的“普元云計(jì)算研發(fā)開(kāi)放群”，討論更多云計(jì)算、微服務(wù)、DevOps、容器相關(guān)內(nèi)容，加群暗號(hào)“DevOps”。

InfoQ陪伴技術(shù)人，

用優(yōu)質(zhì)的技術(shù)文章作長(zhǎng)情的告白。

技術(shù)提升世界的活交給你們了，

高效開(kāi)發(fā)運(yùn)維在這里給你們提供后勤補(bǔ)給。