在項(xiàng)目迭代的過程中骄瓣，不可避免需要”上線“荣恐。上線對應(yīng)著部署，或者重新部署累贤；部署對應(yīng)著修改；修改則意味著風(fēng)險(xiǎn)少漆。
目前有很多用于部署的技術(shù)臼膏，有的簡單，有的復(fù)雜示损；有的得停機(jī)渗磅，有的不需要停機(jī)即可完成部署。本文的目的就是將目前常用的布署方案做一個(gè)總結(jié)检访。
一始鱼、藍(lán)綠布署
Blue/Green Deployment（藍(lán)綠部署）
1、定義
藍(lán)綠部署是不停老版本脆贵，部署新版本然后進(jìn)行測試医清，確認(rèn)OK，將流量切到新版本卖氨，然后老版本同時(shí)也升級到新版本会烙。
1、特點(diǎn)
藍(lán)綠部署無需停機(jī)筒捺，并且風(fēng)險(xiǎn)較小柏腻。
2、布署過程
第一步系吭、部署版本1的應(yīng)用（一開始的狀態(tài)）
所有外部請求的流量都打到這個(gè)版本上五嫂。
[圖片上傳失敗...(image-c59a05-1520860748795)]
第二步、部署版本2的應(yīng)用
版本2的代碼與版本1不同(新功能肯尺、Bug修復(fù)等)沃缘。
第三步、將流量從版本1切換到版本2则吟。
[圖片上傳失敗...(image-4ce399-1520860748795)]
第四步孩灯、如版本2測試正常，就刪除版本1正在使用的資源（例如實(shí)例）逾滥，從此正式用版本2峰档。
3败匹、小結(jié)
從過程不難發(fā)現(xiàn)，在部署的過程中讥巡，我們的應(yīng)用始終在線掀亩。并且，新版本上線的過程中欢顷，并沒有修改老版本的任何內(nèi)容槽棍，在部署期間，老版本的狀態(tài)不受影響抬驴。這樣風(fēng)險(xiǎn)很小炼七，并且，只要老版本的資源不被刪除布持，理論上豌拙，我們可以在任何時(shí)間回滾到老版本。
4题暖、藍(lán)綠發(fā)布的注意事項(xiàng)
當(dāng)你切換到藍(lán)色環(huán)境時(shí)按傅，需要妥當(dāng)處理未完成的業(yè)務(wù)和新的業(yè)務(wù)。如果你的數(shù)據(jù)庫后端無法處理胧卤，會是一個(gè)比較麻煩的問題唯绍；
- 可能會出現(xiàn)需要同時(shí)處理“微服務(wù)架構(gòu)應(yīng)用”和“傳統(tǒng)架構(gòu)應(yīng)用”的情況，如果在藍(lán)綠部署中協(xié)調(diào)不好這兩者枝誊，還是有可能會導(dǎo)致服務(wù)停止况芒。
- 需要提前考慮數(shù)據(jù)庫與應(yīng)用部署同步遷移 /回滾的問題。
- 藍(lán)綠部署需要有基礎(chǔ)設(shè)施支持叶撒。
- 在非隔離基礎(chǔ)架構(gòu)（ VM 牛柒、 Docker 等）上執(zhí)行藍(lán)綠部署，藍(lán)色環(huán)境和綠色環(huán)境有被摧毀的風(fēng)險(xiǎn)痊乾。
二皮壁、Rolling update（滾動(dòng)發(fā)布）
1、滾動(dòng)發(fā)布定義
滾動(dòng)發(fā)布：一般是取出一個(gè)或者多個(gè)服務(wù)器停止服務(wù)哪审，執(zhí)行更新蛾魄，并重新將其投入使用。周而復(fù)始湿滓，直到集群中所有的實(shí)例都更新成新版本滴须。
2、特點(diǎn)
這種部署方式相對于藍(lán)綠部署叽奥，更加節(jié)約資源——它不需要運(yùn)行兩個(gè)集群扔水、兩倍的實(shí)例數(shù)。我們可以部分部署朝氓，例如每次只取出集群的20%進(jìn)行升級魔市。
這種方式也有很多缺點(diǎn)主届，例如：
(1) 沒有一個(gè)確定OK的環(huán)境。使用藍(lán)綠部署待德，我們能夠清晰地知道老版本是OK的君丁，而使用滾動(dòng)發(fā)布，我們無法確定将宪。
(2) 修改了現(xiàn)有的環(huán)境绘闷。
(3) 如果需要回滾，很困難较坛。舉個(gè)例子印蔗，在某一次發(fā)布中，我們需要更新100個(gè)實(shí)例丑勤，每次更新10個(gè)實(shí)例华嘹，每次部署需要5分鐘。當(dāng)滾動(dòng)發(fā)布到第80個(gè)實(shí)例時(shí)确封，發(fā)現(xiàn)了問題，需要回滾再菊，這個(gè)回滾卻是一個(gè)痛苦爪喘，并且漫長的過程。
(4) 有的時(shí)候纠拔，我們還可能對系統(tǒng)進(jìn)行動(dòng)態(tài)伸縮秉剑，如果部署期間，系統(tǒng)自動(dòng)擴(kuò)容/縮容了稠诲，我們還需判斷到底哪個(gè)節(jié)點(diǎn)使用的是哪個(gè)代碼侦鹏。盡管有一些自動(dòng)化的運(yùn)維工具，但是依然令人心驚膽戰(zhàn)臀叙。
(5) 因?yàn)槭侵鸩礁侣运敲次覀冊谏暇€代碼的時(shí)候，就會短暫出現(xiàn)新老版本不一致的情況劝萤，如果對上線要求較高的場景渊涝，那么就需要考慮如何做好兼容的問題。
三床嫌、灰度發(fā)布/金絲雀部署
1跨释、定義
灰度發(fā)布是指在黑與白之間，能夠平滑過渡的一種發(fā)布方式厌处。AB test就是一種灰度發(fā)布方式鳖谈，讓一部分用戶繼續(xù)用A，一部分用戶開始用B阔涉，如果用戶對B沒有什么反對意見缆娃，那么逐步擴(kuò)大范圍捷绒，把所有用戶都遷移到B上面來×淞担灰度發(fā)布可以保證整體系統(tǒng)的穩(wěn)定疙驾，在初始灰度的時(shí)候就可以發(fā)現(xiàn)、調(diào)整問題郭毕，以保證其影響度它碎，而我們平常所說的金絲雀部署也就是灰度發(fā)布的一種方式。
注釋：礦井中的金絲雀
17世紀(jì)显押，英國礦井工人發(fā)現(xiàn)扳肛，金絲雀對瓦斯這種氣體十分敏感〕吮空氣中哪怕有極其微量的瓦斯挖息，金絲雀也會停止歌唱；而當(dāng)瓦斯含量超過一定限度時(shí)兽肤，雖然魯鈍的人類毫無察覺套腹，金絲雀卻早已毒發(fā)身亡。當(dāng)時(shí)在采礦設(shè)備相對簡陋的條件下资铡，工人們每次下井都會帶上一只金絲雀作為“瓦斯檢測指標(biāo)”电禀，以便在危險(xiǎn)狀況下緊急撤離。
灰度發(fā)布結(jié)構(gòu)圖如下：
[圖片上傳失敗...(image-633932-1520860748795)]
2笤休、灰度發(fā)布／金絲雀發(fā)布由以下幾個(gè)步驟組成：
- 準(zhǔn)備好部署各個(gè)階段的工件尖飞，包括：構(gòu)建工件，測試腳本店雅，配置文件和部署清單文件政基。
- 從負(fù)載均衡列表中移除掉“金絲雀”服務(wù)器。
- 升級“金絲雀”應(yīng)用（排掉原有流量并進(jìn)行部署）闹啦。
- 對應(yīng)用進(jìn)行自動(dòng)化測試沮明。
- 將“金絲雀”服務(wù)器重新添加到負(fù)載均衡列表中（連通性和健康檢查）。
- 如果“金絲雀”在線使用測試成功窍奋，升級剩余的其他服務(wù)器珊擂。（否則就回滾）
除此之外灰度發(fā)布還可以設(shè)置路由權(quán)重，動(dòng)態(tài)調(diào)整不同的權(quán)重來進(jìn)行新老版本的驗(yàn)證费变。
參考文章
https://www.v2ex.com/t/344341
為什么選擇使用K8s摧扇？
在使用k8s之前，陌陌在應(yīng)用發(fā)布和運(yùn)行環(huán)境方面遇到的具體問題挚歧，如下：
- 應(yīng)用發(fā)布時(shí)間很長扛稽，主要是因?yàn)榘l(fā)布過程中需要做隔離、恢復(fù)等動(dòng)作滑负，還需要登錄查看實(shí)際狀態(tài)在张、日志用含。
- 當(dāng)遇到晚高峰情況這樣的突發(fā)狀況，需要緊急擴(kuò)容帮匾。這時(shí)業(yè)務(wù)方會申請機(jī)器啄骇，可新機(jī)需要進(jìn)行環(huán)境初始化、相關(guān)配置瘟斜，這樣導(dǎo)致效率非常低缸夹。
- 應(yīng)用運(yùn)行環(huán)境的軟件版本不一致，配置復(fù)雜螺句，維護(hù)成本比較高虽惭。
- 硬件資源利用率不足，總體成本比較高蛇尚。
針對以上遇到的問題芽唇，我們決定對架構(gòu)進(jìn)行改造，同時(shí)制定了一系列架構(gòu)改進(jìn)目標(biāo)取劫，如下：
- 提高服務(wù)可用性匆笤，可管理性∑仔埃可用性是當(dāng)某一臺機(jī)器出現(xiàn)宕機(jī)炮捧，會自動(dòng)切換到其他機(jī)器∠罕辏可管理性是在應(yīng)用需要擴(kuò)容時(shí)寓盗，自動(dòng)化去部署運(yùn)行環(huán)境灌砖、相關(guān)配置璧函。開發(fā)不需要再去考慮服務(wù)器的問題。
- 提高資源隔離性基显，實(shí)現(xiàn)服務(wù)混合部署蘸吓。
- 應(yīng)用級別的監(jiān)控，當(dāng)機(jī)器需要擴(kuò)容時(shí)撩幽，自動(dòng)排查是哪個(gè)應(yīng)用所致库继。
- 服務(wù)平滑遷移。
綜合這些問題和目標(biāo)窜醉，陌陌選擇使用 Kubernetes來管理 Docker 集群宪萄，當(dāng) Kubernetes 滿足不了需求時(shí)，可在部署平臺開發(fā)相應(yīng)的功能來滿足開發(fā)查看日志榨惰、監(jiān)控和報(bào)警等需求拜英，盡量避免登錄主機(jī)和容器。
陌陌容器管理平臺的架構(gòu)演進(jìn)
陌陌從2015年下半年開始對Docker進(jìn)行調(diào)研和實(shí)踐琅催，2016年初開始調(diào)研k8s居凶，嘗試架構(gòu)方面的改進(jìn)工作虫给，基于自研發(fā)布系統(tǒng)及K8s、OVS和Docker構(gòu)建容器管理平臺侠碧。實(shí)現(xiàn)了基于Docker集群的部署系統(tǒng)抹估，便于開發(fā)者便捷地部署自己的應(yīng)用程序。最終達(dá)到部署環(huán)境干凈一致弄兜，可重復(fù)部署药蜻、迅速擴(kuò)容和回滾。
如下圖挨队，是容器管理平臺的架構(gòu)圖：
容器管理平臺主要功能有集群管理和狀態(tài)展示谷暮、灰度發(fā)布和代碼回退、組件模板盛垦、應(yīng)用管理湿弦、鏡像倉庫和權(quán)限管理等。它采用前后端分離的架構(gòu)腾夯，前端使用 JS 渲染颊埃，后端使用 Python 提供 API。這樣開發(fā)者可以快速的進(jìn)行發(fā)布和回退操作蝶俱。
容器管理平臺在應(yīng)用發(fā)布流程班利，集群調(diào)度策略，k8s節(jié)點(diǎn)網(wǎng)絡(luò)架構(gòu)榨呆，阿里云支持罗标，基礎(chǔ)監(jiān)控指標(biāo)等方面進(jìn)行了優(yōu)化改進(jìn)。
應(yīng)用發(fā)布流程
陌陌之前老版本發(fā)布系統(tǒng)是串行的积蜻，需要單臺進(jìn)行替換闯割。如下圖，是新架構(gòu)下應(yīng)用的發(fā)布流程：
新的發(fā)布系統(tǒng)是用戶提交代碼后竿拆，在發(fā)布系統(tǒng)選擇要部署的commit宙拉，點(diǎn)擊構(gòu)建以后，系統(tǒng)會自動(dòng)編譯丙笋，打包成鏡像谢澈，推送鏡像倉庫。如果構(gòu)建成功御板，用戶點(diǎn)擊發(fā)布新版本的實(shí)例锥忿，灰度沒有問題，全量怠肋，下線老版本的實(shí)例敬鬓。回退時(shí)代碼不需要構(gòu)建，直接發(fā)布老版本實(shí)例列林。在某段時(shí)間內(nèi)瑞你，新老版本是同時(shí)存在的。
集群調(diào)度策略
陌陌的集群調(diào)度策略是為應(yīng)用配置默認(rèn)的location（集群標(biāo)簽）希痴，如果是線上應(yīng)用者甲，應(yīng)用需要申請location，部署到正式的集群（機(jī)房要求砌创，資源充足）虏缸。這里應(yīng)用都不能獨(dú)占集群，均采用的是混合部署的方式嫩实。
同一個(gè)集群下刽辙，分成不同組并組定義標(biāo)簽，應(yīng)用支持獨(dú)占機(jī)器甲献，同一個(gè)組之間的應(yīng)用實(shí)例可以隨意飄移宰缤。
IDC網(wǎng)絡(luò)節(jié)點(diǎn)
在IDC網(wǎng)絡(luò)節(jié)點(diǎn)構(gòu)建部分，陌陌使用的是全局IP地址晃洒，容器與容器之間慨灭、容器與主機(jī)之間都是互通的。這樣一來球及，通信可以不使用任何封裝等技術(shù)氧骤，相對來說比較高效且對現(xiàn)有網(wǎng)絡(luò)變動(dòng)影響小（僅需封裝trunk吃引，無其他協(xié)議筹陵，mtu等變化）。
如下圖镊尺，是IDC網(wǎng)絡(luò)節(jié)點(diǎn)架構(gòu)圖：
在這樣的架構(gòu)下朦佩，網(wǎng)絡(luò)部署和擴(kuò)展相對簡單，因?yàn)槊颗_機(jī)器的IP地址段是預(yù)先靜態(tài)配置的鹅心。
這里值得注意的是吕粗，服務(wù)器雙鏈路上聯(lián)纺荧，trunk上聯(lián)物理交換機(jī)需要合理避免二層環(huán)路旭愧。
這樣的方式存在的不足是，當(dāng)容器較多時(shí)宙暇，mac地址數(shù)量增多输枯，給物理交換機(jī)Mac地址表帶來壓力，廣播域擴(kuò)大就是需要嚴(yán)謹(jǐn)?shù)囊?guī)劃vlan 角色相關(guān)信息占贫。
阿里云支持
當(dāng)前桃熄，陌陌K8s master集群下節(jié)點(diǎn)包含IDC、阿里云及兩者混合三種方式型奥，如下圖：
阿里云采用的網(wǎng)絡(luò)模式是Host-gw瞳收，陌陌搭建了一條IDC與阿里云的VPC專線和VPC的虛擬路由進(jìn)行靜態(tài)配置碉京。無論是IDC節(jié)點(diǎn)，還是阿里云節(jié)點(diǎn)上的應(yīng)用都要適應(yīng)IP動(dòng)態(tài)變化螟深。
基礎(chǔ)監(jiān)控指標(biāo)
陌陌的監(jiān)控方案大多是基于Kublet cadvisor metrics接口去做的數(shù)據(jù)匯總谐宙。最初陌陌采用的方式是利用Python腳本，去調(diào)用接口界弧，在取到一些CPU內(nèi)存凡蜻、網(wǎng)絡(luò)、流量的數(shù)據(jù)垢箕，存入ES划栓，分析之后進(jìn)行展示。之后的報(bào)警系統(tǒng)条获，是利用Java應(yīng)用去調(diào)取Kublet cadvisor metrics接口忠荞，進(jìn)行數(shù)據(jù)的收集。
基礎(chǔ)監(jiān)控指標(biāo)主要有內(nèi)存(total,rss,cache)帅掘、流量(incoming,outgoing)钻洒、網(wǎng)絡(luò)packets(drop，error, total)等锄开。
應(yīng)用遷移
應(yīng)用遷移方面素标，陌陌做了很多適配工作，使得應(yīng)用不需要太多的改動(dòng)就可以無縫遷移萍悴。具體適配細(xì)節(jié)如下：
- 應(yīng)用適應(yīng)動(dòng)態(tài)ip變化头遭。
- 自定義構(gòu)建過程（build.sh）。
- 應(yīng)用使用不同的服務(wù)發(fā)現(xiàn)框架（nginx癣诱，rpc）（start.sh）计维。
- 應(yīng)用銷毀過程中做一些額外處理(stop.sh)。
在應(yīng)用遷移過程中撕予，也遇到了一些問題鲫惶，如Swap、cpu軟中斷優(yōu)化实抡、資源利用率欠母、Ip白名單、適用于內(nèi)網(wǎng)等問題吆寨。
當(dāng)前赏淌，陌陌的容器業(yè)務(wù)規(guī)模服務(wù)器約400臺、線上容器6000啄清、應(yīng)用700+六水。應(yīng)用的類型是java+php+node+python+tomcat。
