《基于微服務(wù)的Real DevOps實(shí)踐》要點(diǎn)：
本文介紹了基于微服務(wù)的Real DevOps實(shí)踐，希望對您有用。如果有疑問，可以聯(lián)系我們。

錘子兩年前登陸墨爾本時,完全是DevOps小白.面試REA的時候,被問到什么是Continuous Delivery(持續(xù)交付),錘子誠懇地表示“不知道”.面試官不依不饒,“不知道不要緊,你想想怎么樣才能做到Continuous Delivery?” 錘子回顧了一下自己維護(hù)項(xiàng)目時的噩夢,斟酌著用詞說：“這需要好多自動化的工具支持,怎么測試,怎么接入不同的網(wǎng)絡(luò),怎么部署不同的環(huán)境,還有數(shù)據(jù)庫的data migration和回滾,個頂個的都是痛點(diǎn).”

之前錘子所做過的系統(tǒng)都是Monolith(單體)架構(gòu),所以,每次需要重啟生產(chǎn)環(huán)境時,真得一而再,再而三地確認(rèn).所以當(dāng)REA的同事給我講解我們的微服務(wù)架構(gòu),和怎么做Continuous Delivery時,我問：“那最壞的情況就是重啟系統(tǒng)了?”這個同事說：“不,重啟系統(tǒng)是正常情況.”由此,錘子開始慢慢了解REA強(qiáng)大的DevOps.

微服務(wù)和DevOps

在介紹REA的DevOps之前,還是簡單說說我們使用的微服務(wù)架構(gòu).

微服務(wù)有時被人詬病違背了DRY原則,但是Monolith架構(gòu)下各種服務(wù)間的強(qiáng)耦合對于擴(kuò)展部署都很痛苦,所以Don’t repeat yourself 誠然不錯,微服務(wù)架構(gòu)下,定義好邊界之后(APIs),每個微服務(wù)獨(dú)立存在,獨(dú)立部署且可擴(kuò)展,即使有一些簡單的復(fù)制粘貼,其帶來的靈活性也是Monolith架構(gòu)不具備的.

在REA內(nèi)部,為了保證某種程度的一致性,我們的微服務(wù)都需要遵循12 Factor：

• 基準(zhǔn)代碼： 一份基準(zhǔn)代碼,多份部署.
• 依賴： 顯式聲明依賴關(guān)系.
• 配置： 在環(huán)境中存儲配置.
• 后端服務(wù)： 把后端服務(wù)當(dāng)作附加資源.
• 構(gòu)建,發(fā)布,運(yùn)行： 嚴(yán)格分離構(gòu)建和運(yùn)行.
• 進(jìn)程： 以一個或多個無狀態(tài)進(jìn)程運(yùn)行應(yīng)用.
• 端口綁定： 通過端口綁定提供服務(wù).
• 并發(fā)： 通過進(jìn)程模型進(jìn)行擴(kuò)展.
• 易處理： 快速啟動和優(yōu)雅終止可最大化健壯性.
• 開發(fā)環(huán)境與線上環(huán)境等價： 盡可能的保持開發(fā),預(yù)發(fā)布,線上環(huán)境相同.
• 日志： 把日志當(dāng)作事件流.
• 管理進(jìn)程： 后臺管理任務(wù)當(dāng)作一次性進(jìn)程運(yùn)行.

不過不管微服務(wù)設(shè)計得如何精良,當(dāng)一個“小而美”的團(tuán)隊(5-6名開發(fā)人員)需要同時開發(fā)維護(hù)生產(chǎn)環(huán)境中10個以上的微服務(wù)時,服務(wù)運(yùn)行和管理上的額外復(fù)雜性使得全自動構(gòu)建和部署變得不可或缺,更進(jìn)一步,最好使用Continuous Delivery來解決這些問題,而DevOps為真正的Continuous Delivery提供了必要的支持.

那DevOps究竟是什么?DevOps就是更好的優(yōu)化開發(fā)(DEV)、測試(QA)、運(yùn)維(OPS)的流程,開發(fā)運(yùn)維一體化,通過高度自動化工具與流程來使得軟件構(gòu)建、測試、發(fā)布更加快捷、頻繁和可靠.

下面這張圖(圖片來源什么是 DevOps?)就是DevOps的日常.

既然DevOps不是新工具,不是新團(tuán)隊,不是新角色,也不是大量知識,而且DevOps的偉大實(shí)踐來自于許多不同的領(lǐng)域,并且在IT組織內(nèi)執(zhí)行,為了提升IT的性能,那下面就讓錘子講講REA的DevOps實(shí)踐,首先自然從最貼近我們程序猿的全工具鏈開始.

REA DevOps全工具鏈

REA實(shí)際使用到的全工具鏈包括：

• 代碼倉庫：github企業(yè)版.
• 構(gòu)建和部署工具：Buildkite和Jenkins,還有一些老的項(xiàng)目依然在使用Bamboo.
• 容器平臺：微服務(wù)用Docker進(jìn)行打包,Docker的引入讓公司內(nèi)部微服務(wù)的部署流程一致化.
• 環(huán)境：目前絕大部分的service部署在AWS(Amazon Web Services)中,開發(fā)環(huán)境和測試環(huán)境使用同一套IAM,生產(chǎn)環(huán)境使用另一套IAM,三套環(huán)境通過Virtual Private Cloud (VPC)的設(shè)置進(jìn)行隔離.不同部門的不同的組在IAM下?lián)碛胁煌巧驮L問權(quán)限.部署采用AWS Cloudformation服務(wù),避免手動創(chuàng)建和更新使用到的AWS的業(yè)務(wù).
• 日志管理：splunk.Docker已經(jīng)提供對Splunk的支持,所有微服務(wù)的日志都能夠通過Splunk Agent發(fā)送到集中的Splunk服務(wù)器.集中式的日志管理方式,方便程序猿們進(jìn)行trouble shooting,而且完全避免了登陸到不同的機(jī)器收集log的窘境.
• 監(jiān)控：建立分層的監(jiān)控體系.使用NewRelic用來監(jiān)控網(wǎng)絡(luò)、設(shè)備和應(yīng)用的性能；使用AWS Cloudwatch監(jiān)控AWS的服務(wù),比如某個SQS對應(yīng)的dead-letter queue里是不是收到了消息,或者AWS Lamda執(zhí)行是不是有錯誤等；Nagios提供服務(wù)可用性監(jiān)控.可以直接使用REA內(nèi)部的rea-health-check庫,提供心跳API供Nagios的主動模式使用；也可以通過設(shè)置接收相應(yīng)的消息格式,使用Nagios被動模式監(jiān)控微服務(wù).不管哪種模式下發(fā)現(xiàn)問題,Nagios馬上會產(chǎn)生告警發(fā)送到PagerDuty.
• 告警：PagerDuty.前面提到的監(jiān)控工具都可以發(fā)出告警,這些告警會通過PagerDuty用郵件,Slack,電話和短信的方式通知給當(dāng)時的值日人員.PageDuty雖然是全天24小時運(yùn)行,也只有極少部分高優(yōu)先級的告警才會在非工作時間發(fā)出.還有一個告警的來源是Zendesk Ticket,這種信息通常直接來自于客戶.就我們組而言,基本上都是一些數(shù)據(jù)錯誤,需要個別修正.
• 協(xié)同工作：Leankit.

工具鏈看起來并不復(fù)雜,那么有了工具鏈,所有的問題就迎刃而解了嗎?答案自然是否定的.

怎么樣自動化所有流程?怎樣為REA超過40個組管理AWS的賬號?怎么為AWS里的測試環(huán)境和生產(chǎn)環(huán)境配置VPC?怎樣把微服務(wù)部署到不同的環(huán)境?監(jiān)控的策略怎么樣實(shí)施,怎么樣在不同的組之間協(xié)調(diào)?所有的幾百個微服務(wù),一旦某些微服務(wù)除了問題怎么辦等等.這些都需要工具鏈切切實(shí)實(shí)的落地.

REA DevOps工具鏈的實(shí)施過程中,分層協(xié)作不但厘清不同部門的責(zé)任,也讓所有開發(fā)人員參與到Operation工作中,讓DevOps融入每個IT人員的日常.

REA DevOps的分層協(xié)作

REA DevOps不同層面的問題由不同的組負(fù)責(zé),如下圖.

不同的Squads(REA引入了Spotify模式)使用DevOps工具鏈來開發(fā)和維護(hù)自己的微服務(wù).詳情會在下面一節(jié)進(jìn)行介紹.

Delivery Engineering團(tuán)隊,顧名思義,就是為了讓程序猿們更快更好地發(fā)布應(yīng)用,主要職責(zé)是工具的開發(fā)和管理.包括創(chuàng)建Docker Registry,準(zhǔn)備好已經(jīng)安裝了必要庫的baked Docker image,有了這些基準(zhǔn)的Docker Images,開發(fā)團(tuán)隊在為自己的微服務(wù)構(gòu)建Docker Image的時可以有效節(jié)省時間,還能規(guī)避各種庫版本不一致的問題.Delivery Engineering還需要為不同部門配置Buildkite,Buildkite的Agents部署在AWS的EC2中,根據(jù)需要連接的環(huán)境,多個Agents分布在不同的VPC.

最值得一提的是Delivery Engineering開發(fā)的rea-shipper.

• rea-shipper實(shí)現(xiàn)了從構(gòu)建到部署的全自動,真正解決了最痛的那個點(diǎn).
• 為了保證Zero downtime,rea-shipper讀取微服務(wù)的cloudformation配置,采用immutable ASG(auto scaling group)deployment模式 進(jìn)行部署.
• rea-shipper自動將監(jiān)控和日志管理所需要的模塊也用Docker打包,在部署過程中與每個微服務(wù)的Docker Image整合,如下圖所示.這樣微服務(wù)開發(fā)人員只需要關(guān)注業(yè)務(wù)的開發(fā),無需擔(dān)心日志和監(jiān)控的問題.

以我們一個實(shí)際的service charge-central為例,登陸到EC2 instance之后,可以看到正在運(yùn)行的幾個container.

Global Infrastructure & Architecture 團(tuán)隊負(fù)責(zé)基礎(chǔ)設(shè)施建設(shè),管理維護(hù)并開發(fā)相應(yīng)的工具,包括網(wǎng)絡(luò)、數(shù)據(jù)中心、AWS賬號的管理、Splunk的集成等.比如,去年悉尼大雨,Amazon的機(jī)房被水淹了,澳洲大批網(wǎng)站受到影響,也包括我們公司的一小部分,當(dāng)時苦了GIA team的人了.

所以全工具鏈的配置和開發(fā)是Global Infrastructure & Architecture 和Delivery Engineering的職責(zé),而作為程序猿的錘子,則是工具鏈的使用者.下面就說說程序猿所參與的DevOps日常.

程序猿DevOps日常

1. Coding

前面提到過代碼庫使用github企業(yè)版,采用github flow.

微服務(wù)需要的部署腳本和AWS Cloudformation的信息,提供給不同監(jiān)控工具的接口,fried Docker image 定義等,也都是代碼的一部分,需要開發(fā)人員完成.

2. 構(gòu)建和部署

構(gòu)建和部署就以Buildkite為例子,這是一個微服務(wù)的buildkite腳本.

這個流程里代碼檢查和單元測試自動化起來很容易,那么怎么做整合測試?REA基于Ian Robinson提出的用消費(fèi)者驅(qū)動的契約進(jìn)行面向服務(wù)開發(fā)的模式開發(fā)了 開源的Pact 測試框架,用輕量級的契約測試來代替厚重的集成測試.Pact在消費(fèi)端用單元測試的形式(更輕)來生成 pact 契約,服務(wù)端通過驗(yàn)證契約來保證兩者穩(wěn)定集成.一旦有一端契約未經(jīng)協(xié)商發(fā)生改變,那么Pact測試就會失敗.

構(gòu)建成功之后,會把微服務(wù)打包成Docker Image然后上傳到Docker Registry.我們會選擇在Delivery Engineering提供的基準(zhǔn)Docker Image之上來打包,這是一個微服務(wù)的Dockerfile的例子：

用這種方式,在buildkite上打包并上傳到Docker Registry的時間小于三分鐘.

部署時,腳本會調(diào)用rea-shipper.不同的環(huán)境下,Buildkite會選擇不同的Agent進(jìn)行部署：Test 環(huán)境的non-prod-corp:default和Prod環(huán)境的prod-corp:default.部署的時間通常10分鐘以內(nèi),下面是一個微服務(wù)部署到test(6分1秒)和prod(5分43秒)的時間,圖中能夠看到Cloudformation更新的步驟.

盡管是全自動的部署,考慮到生產(chǎn)環(huán)境的重要性,我們還是選擇謹(jǐn)慎地Block,需要某個開發(fā)人員手動觸發(fā).觸發(fā)的時間沒有特別的規(guī)定,只是在我們的kanban中,deploy是最后一步,這意味著只有真正部署到生產(chǎn)環(huán)境,這個卡片才算完成.如果部署過程中出現(xiàn)失敗,rea-shipper不會切換運(yùn)行中的ASG(Auto Scalling Group),業(yè)務(wù)并不會受到影響.如果部署的新版本發(fā)現(xiàn)bug需要緊急回滾,可以很容易地根據(jù)Docker Image的版本找到相應(yīng)的Image進(jìn)行部署.

3. 運(yùn)維

日常的運(yùn)維如下圖所示：

需要處理的問題一般有兩種：

• 直接源于客戶的問題,使用Zendesk Ticket.
• 源于生產(chǎn)環(huán)境的問題,比如PagerDuty告警.

我們Tribe有5個Squad,除了有超過30個microservice之外,還有跟不同系統(tǒng)的接口,如果不能組織好,開發(fā)人員每天必定會被各種問題打擾.所以如圖所示,Tribe級別有Dingo(工作時間)或者Owl(非工作時間)作為接口人,負(fù)責(zé)處理和分發(fā)問題到Squad級別的Squid.Dingo,Owl和Squid是團(tuán)隊的開發(fā)人員輪崗.

總結(jié)

本文介紹了REA DevOps的實(shí)踐,包括工具鏈,工具鏈的分層協(xié)作以及使用中的流程.再來對比一下Gene Kim的3個方法：流程,反饋和持續(xù)學(xué)習(xí),這3個方法是DevOps的主要部分,提供一種路標(biāo)來理解和執(zhí)行DevOps.錘子能夠看到的是在REA DevOps實(shí)踐中,每個開發(fā)人員都參與到流程的不斷優(yōu)化中,讓流程變得更順暢和快速；通過不同方式可視化監(jiān)控和反饋,以達(dá)到更快的反饋路徑；開放全代碼庫給所有開發(fā)人員,鼓勵程序猿持續(xù)學(xué)習(xí)和改進(jìn)等等.

以上種種,推薦閱讀我們公司同事的文章來更深入的了解REA的文化.Scaling On-Call: from 10 Ops to 100 Devs,講述了怎么從這樣的狀態(tài)：

到達(dá)下面的狀態(tài)：

這種變化并不是技術(shù)改進(jìn)帶來的,而是源于持續(xù)學(xué)習(xí)的企業(yè)文化.而這,正是DevOps最需要的.

原文作者：虎頭錘,2015年4月登陸澳洲之后,入職REA Group

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4262.html