如何有效提升團隊的微服務落地能力？

2018-01-08 15:35:41 原文來自微信公眾號：Docker　點擊量：評論 (0)

微服務體系的發(fā)展并不是一蹴而就的，經過了2014年前后的低潮期，微服務概念頂層的泡沫逐漸褪去，那些真正能夠在企業(yè)落地的實踐在一輪又

微服務體系的發(fā)展并不是一蹴而就的，經過了2014年前后的低潮期，微服務概念頂層的泡沫逐漸褪去，那些真正能夠在企業(yè)落地的實踐在一輪又一輪的大浪淘沙后被甄別、沉淀。這篇文章希望討論一些在團隊中實行微服務架構時值得考慮的『增值項目』，它們中的一些看起來已經是理所應當的，而另一些似乎和微服務并沒有必然的關聯，但許多經驗能夠證明這些項目都是保障微服務系統(tǒng)長期運作并最大化發(fā)揮其Scale Out能力值得投入的高附加值實踐。

持續(xù)交付

對于微服務的成功實施，團隊持續(xù)交付能力是至關重要的衡量指標。在由上百個服務組成的復雜系統(tǒng)中，如果所有服務都按照人為指定發(fā)布周期進行整體交付，很容易出現由于細小的失誤導致大面積線上故障。

持續(xù)交付實踐要求每個獨立服務都具有完備的交付流水線，在流水線的末端隨時能提供當時最新的可工作、可交付的產品。持續(xù)交付通常會配合自動化的測試和部署手段，從而減少功能代碼提交到上線的端到端時間。這就使得每個獨立服務能按照各自不同的節(jié)奏進行發(fā)布，并且將自己的發(fā)布狀態(tài)可視化出來。

采用盡可能精簡且穩(wěn)定的分支策略也是使得持續(xù)交付流程能夠順利實施的關鍵，我們提倡使用單主干的分支策略（Trunk Based Development）。在單主干的開發(fā)方式中，除了一個用于持續(xù)開發(fā)和集成的『主干分支』（通常即Master分支）和一系列依據發(fā)布周期創(chuàng)建的發(fā)布分支以外，應該避免創(chuàng)建其他的Long-lived分支。如果有多個功能需要開發(fā)，則推薦采用特性開關（Feature Toggle）的方法來控制它們的發(fā)布時機。當然，單主干策略是允許存在短生命周期特性分支的（短于一周），有時這些小分支甚至無需提交到遠程倉庫中。下面這是一幅經典的單主干分支策略示意圖。

A1HKVXsfHNkyprpUfYBDjMuzVibBRibhMFW2r7tP39bVtrMwTMyyDXoibZ2iaJ9laOyiajDJXSGibTRw5tq93QG2XExQ

值得指出的是，在劃分得當的微服務系統(tǒng)中，同一個服務需要同時進行開發(fā)的特性通常不會多于兩到三個（否則應該考慮這個服務是否承擔了過多的職責）。因此即使在不需要特性開關和其他額外開發(fā)工作量的情況下，已經可以比較好的實現每個功能點的獨立發(fā)布和測試，這反向說明了微服務架構對于持續(xù)交付的實施也是十分友好的。

除了嚴格的單主干，一種常見的變式是多主干策略，典型的是一個開發(fā)分支加幾個固定的發(fā)布分支，通常用于無需維護多個發(fā)布版本的SaaS服務交付。這種模式的優(yōu)點是能夠將發(fā)布流水線目標環(huán)境和分支顯示的關聯起來，例如『Develop分支』對應集成環(huán)境，『Release分支』對應驗收環(huán)境和正式環(huán)境。下圖展示了一組與此模式下的持續(xù)交付流水線。

A1HKVXsfHNkyprpUfYBDjMuzVibBRibhMFzR6IB3uHRQszscpXhkZCxEFdvwibAreCOXpPF7ic213XFIHsuOeeyHZg

保持每個服務高頻率的集成和交付，會使得有故障的功能在很短的反饋周期內被發(fā)現，在快速迭代發(fā)布的前提下做到整個系統(tǒng)發(fā)布井然有序。這樣的氛圍不僅有利于改善代碼的質量，而且能夠提高開發(fā)士氣，頻繁的發(fā)布上線也有利于增強團隊對產品的榮譽感和自信心。

全功能團隊

全功能團隊是DevOps運動所倡導的一種產品團隊組織結構，通過將不同角色的業(yè)務和技術成員納入到團隊，組成具備端到端交付和運營能力的完整單元。

康威定律闡述了開發(fā)團隊的組織結構和其設計的產品結構之間具有的相似關系。許多的實踐結果也表明，將全功能團隊實踐應用在微服務產品中帶來的收益，要遠遠超過它在傳統(tǒng)模塊化開發(fā)的產品中所帶來的收益。這是因為微服務的架構中的所有服務真正具備獨立運行和獨立運營的能力，從本質上來說就是一個端到端的子業(yè)務產品。

這種架構和團隊的影響是雙向的。一方面，微服務的運營結構要求團隊具有高內聚的自主管理能力。另一方面，全功能團隊也為特定服務進行獨立技術選型提供了更靈活的發(fā)揮空間。服務與團隊通常是多對一的關系，每個團隊管理的是一組相互關聯緊密的服務群，并且可以在必要的情況下對服務進行進一步拆分。在實際的實踐中推薦采用例如接口網關（API Gateway）等方式對一組具有業(yè)務意義的服務接口進行聚合，從而保證局部服務結構變化不會直接影響服務的消費方的調用。

值得一說的是，在一些傳統(tǒng)企業(yè)內的IT部門劃分，往往已經按照職能分為開發(fā)團隊、運維團隊、運營團隊，甚至單獨的測試團隊。在這樣的企業(yè)中很難快速完成全功能團隊的轉變，因此在實施微服務架構過程中比較容易走偏。對于這種情況可以采用逐步演進的轉換方式，具體途徑主要有兩種。

第一種方式是進行項目試點。對于習慣了按功能分層、分塊的『實現接口開發(fā)』式的組織，即使勉強湊齊每個角色的人組在一起也難以成為真正具備端到端交付能力的團隊。因此與其做得徒有其表，不如找出項目中一些全局意識比較到位的成員，對特定的項目進行試點，然后逐步擴大，將這種端到端的責任和意識帶入到更多的項目中去。試點的項目應該是以實施現有系統(tǒng)的一個獨立業(yè)務功能點為目標，而不是開發(fā)與企業(yè)主線系統(tǒng)無關的短期產品，否則容易出現試點項目很成功，但項目結束便不了了之的結果。

第二種方式是先從分開發(fā)團隊入手，縱向劃分項目。這是對全功能團隊的一種妥協式的引入方式，即在開發(fā)團隊中首先改變系統(tǒng)架構橫向分層、局部分塊的開發(fā)模式，依據業(yè)務功能進行上至外部接口、下至業(yè)務數據的獨立服務拆分，但并不急于在開發(fā)團隊中引入諸如測試、運維、業(yè)務等角色的成員。這種項目劃分雖然在一定程度上為微服務架構執(zhí)行制造了條件，但從長遠來看，并不能為團隊進行自主的技術棧和基礎設施選型、以及業(yè)務數據的利用提供足夠的空間。

自動化運維

自動化運維是實施持續(xù)交付的必要前提，因此也可以說是采用微服務架構的必要前提。但這里所說的自動化運維，不僅僅包含持續(xù)交付所需的服務部署時『一鍵操作』能力，更重要的是運維基礎設施構建的自動化、以及服務災備、恢復的自動化。微服務架構最初受到追捧的一個原因是它靈活的『局部Scale Out』能力，以功能點為單元的擴展、收縮，這對于具有業(yè)務周期性的服務而言更加重要。但一些企業(yè)在自身基礎設施自動化不到位的情況下盲目實施微服務，期望通過其實現復雜架構的解構，結果在面對突發(fā)線上事故時出現雪崩式的連鎖反應，情急之下也只能手工恢復重建，耽誤大量時間。

實施自動化運維涉及的工具有很多，例如Ansible、SaltStack、Terraform，甚至Docker都可以看做是自動化運維的一部分。這當中大多數工具都提供有定義操作行為的領域DSL，它們通常是一些配置式語言或腳本語言，因此自動化運維也涉及到代碼的編寫。與開發(fā)項目代碼不同的地方在于，自動化運維的代碼大多不是長期運行的，很多代碼也許只在特定場景使用一次，然后就會非常長時間無人問津，直到某些緊急情況才會再次需要用到。此外，運維的代碼本身并不直接具有業(yè)務價值，這些因素導致它們往往沒有被很好的管理起來。

下面以采用Ansible或SaltStack這類通用自動化工具為例，介紹一些在實踐中需要注意的地方。

首先是運維腳本應該通過Git或SVN這樣的版本管理工具進行歸類和管理。通常來說，推薦將特定服務部署的Ansible或SaltStack YAML腳本文件與服務本身的代碼放在同一個代碼倉庫中，方便開發(fā)人員在必要時候快速的修改它。然后將基礎設施管理的YAML腳本文件放在單獨的代碼倉庫，方便復用和查找。但這樣可能帶來的問題是，在實際使用時可能會需要同時獲取兩個代碼倉庫的腳本以獲得完整的部署功能，因此如果使用的其他配套工具對多倉庫支持不佳，也可以將所有運維腳本在同一個倉庫管理。

其次，應該在持續(xù)交付流水線上使用服務部署的自動化工具，從而實現快速的交付上線。在條件允許的情況下，還應該在流水線上直接配備自動化的災備恢復任務入口，以及定期的對這些恢復腳本進行測試和演練。

最后，雖然我們鼓勵每個團隊使用適合自身業(yè)務的技術棧進行開發(fā)，但對于運維工具的選擇通常讓同一個產品的各服務采用統(tǒng)一技術棧比較合適（例如不要混用Ansible和SaltStack的腳本）。這個建議主要考慮到運維工作可能會有較多跨團隊協作，以及故障恢復場景下的快速救災操作，統(tǒng)一的技術棧能為運維人員節(jié)約掉工具切換的時間。

服務高可用

由于微服務系統(tǒng)中存在著眾多跨服務調用，任何一個服務都不能假設自己可以隨意的停機一段時間而不對系統(tǒng)的整體功能造成影響。但在現實情況中，正常的服務升級或意外的故障都有可能造成服務短暫或長時間的中斷，這種中斷輕則引起局部功能不可用，重則導致連鎖反應造成重大事故。這些都是在架構設計時候就應該予以考慮的問題。應對這兩類情況的方法分別是對服務采用高可用的部署方式，和進行不離線的部署。實現服務高可用的方法有很多，常見的有：L7負載均衡、DNS負載均衡、服務發(fā)現、同步/異步消息隊列等。

L7負載均衡即在OSI網絡模型應用層進行的軟件負載均衡，例如Nginx和HAProxy都屬于這類。這些L7負載均衡通常帶有后端服務檢查的能力，會自動屏蔽掉不可用的后端服務，從而在一部分服務出現故障時候，請求仍然能被正常運行的后端服務接收。

DNS負載均衡是利用了DNS服務可以為同一個域名配置多個解析地址，且配置多個地址后，每次解析域名時輪詢著將配置的地址返回給請求方，這個特性稱為DNS輪詢。實際上DNS輪詢僅僅是一種特殊的負載均衡技術，本身并不具有檢測服務狀態(tài)、提供后端服務高可用的功能。但一些新出現的開源DNS產品，例如SkyDNS和Consul將DNS服務與服務發(fā)現技術進行了結合，具有自動移除不可訪問的解析地址的功能，這使得DNS負載均衡也可以被用于實現服務的高可用了。

服務發(fā)現是一種基于注冊和查詢服務信息的鍵值數據庫服務。提供服務的一方將自己的名稱和IP地址注冊到服務發(fā)現的服務端，使用服務的一方則通過服務發(fā)現的服務端進行查詢，然后將實際請求發(fā)送給查詢到的目標IP地址。服務發(fā)現的服務端會負責檢測每個注冊服務的運行狀態(tài)，及時移除出現故障的服務，并在每次收到查詢時從符合名稱的服務中任意返回一個作為結果。

消息隊列則是一種采用中間媒介解耦服務提供者和消費者的方法。服務之間通過發(fā)布和訂閱消息進行交互，所有的消息通過隊列進行分發(fā)和中轉。這種結構使得消息隊列本身成為所有數據通信的瓶頸，與微服務的去中心化思想相悖，因此并不推薦在大型微服務系統(tǒng)中采用。

不離線部署

不離線部署是確保服務隨時能發(fā)布的必要措施，也是微服務架構團隊需要關注的一種能力。在實際應用中，除了一些天生支持不離線部署的技術棧，如Erlang，多數的服務是原生不支持熱升級的。對于這些服務，通常來說可根據服務『是否能遞進式升級』和『是否具有長任務』的特性，分成三種類型：『不能遞進升級的服務』，『能遞進升級、無長任務的服務』，以及『能遞進升級、有長任務的服務』，分別采用不同策略進行。這里先介紹一下服務的『遞進式升級』和『具有長任務』。

遞進式升級（Rolling Update）是指將集群中的服務劃成多個分組，每次只升級其中的一個分組，然后依次進行，直到所有服務都升級完成的過程。采用遞進式升級會使得集群中的服務有一段時間同時存在新舊兩個版本。

長任務指是接收到請求后需要花費幾秒、甚至幾小時才能執(zhí)行完的任務，例如一些涉及大量計算或需要遠程同步調用的事務。具有長任務的服務都有『運行中』和『空閑』這樣的運行狀態(tài)。當服務處于『運行中』的時候，中斷它可能導致意外的結果。一般來說在Linux中停止服務的流程是先向服務發(fā)送一個TERM信號，使其正常結束，若是信號發(fā)送幾秒后，服務仍然在運行，才會發(fā)送KILL信號將它強行終止。處理短任務的服務通常可以在接收到TERM信號后及時停止，因此不存在這種風險。這里應該將『無長任務的服務』與『無狀態(tài)的服務』加以區(qū)分，后者指的是服務對每次請求的處理，不依賴于其他請求。即服務處理一次請求所需的全部信息，要么都包含在這個請求里，要么可以從外部獲取到（比如說數據庫），服務器本身不存儲任何信息。通常來說，微服務架構中的服務一定是無狀態(tài)的，但不一定是無長任務的。

如果服務不能采用遞進式的升級，不論其是否具有長任務，藍綠部署都是一種十分推薦的部署方式。藍綠部署的做法是同時準備一組線上運行的服務器，以及一組用于下次部署的服務器，兩組服務器具有相同的數量和配置。執(zhí)行部署時，先將新的服務部署到沒有放到線上運行的那組服務器上，等到部署全部完成，直接將負載均衡的流量導向到剛剛這組服務器上，從而使得兩組服務器的角色互換。下一次進行部署的時候，則換用另外一組服務器執(zhí)行部署，然后將負載均衡切換回來。這個過程如下圖所示：

A1HKVXsfHNkyprpUfYBDjMuzVibBRibhMFZckm2iaRzpEVMjjhqPc2UrXZEOSfy5wFstEgz7kBAGYs9iaVHBicgb9aw

藍綠部署的優(yōu)點在于新舊服務的切換是瞬間完成的，并且當流量切換到另一組服務器上之后，原先的那組服務器可以繼續(xù)運行，這樣即使上面有未完成的任務也不會被強行中斷，如果升級后的版本發(fā)現了比較嚴重的問題，也可以快速的切換回原先的版本。而它的缺點也十分明顯，那就是會占用比實際需要多一倍的服務器作為下次部署的備用機器。

一些前端服務可能會屬于這類情況，我們也許不希望在升級的過程中，一部分用戶看到是新的頁面，另一部分看到還是舊的頁面。另外對于Nginx這類負載均衡工具，后端服務的健康檢查并非是實時生效的，有可能出現服務已經離線，但請求仍然被分發(fā)到這個主機的情況，因此采用負載均衡作為高可用方案的服務，藍綠部署也是比較可取的方式。

如果服務的數量比較多，并且允許同時存在兩個運行的版本，那么采用遞進式升級方式則會更加節(jié)省資源。以每次升級一個節(jié)點的遞進方式為例，當升級開始后，我們首先停止所有服務節(jié)點中的任意一個，將它進行升級，然后讓它重新加入集群，接著從剩下的服務節(jié)點從再任意選擇一個，直到最后一個服務也被升級完成。這個過程不需要增加額外的服務器資源，只要待升級的服務具有兩個以上的節(jié)點，就不會對服務的整體功能造成中斷。遞進式升級的過程如下圖所示：

A1HKVXsfHNkyprpUfYBDjMuzVibBRibhMFzNcvcgVCC2oFF79ianyshfuiaMV8jBHwTHlNibEgjWrerq1BUuoJ2TU0w

顯然如果服務本身是不能被隨時停止的，那么這種簡單的遞進升級就不能很好的滿足了。此時我們需要對服務的調度進行干涉，以采用服務發(fā)現的高可用方式為例，下圖展示了一種『帶狀態(tài)檢查的遞進式升級』策略進行服務部署。

A1HKVXsfHNkyprpUfYBDjMuzVibBRibhMFibjPnwSgWot2VmKLYGlH9fQwcHZ1BlabyGLWbbPC7xmGgqic2kbxFwCQ

這種升級方法具有普通遞進式升級的相似優(yōu)勢，但在集群中有個別服務執(zhí)行任務時間很長，始終處于『運行中』狀態(tài)的情況下，將使得升級過程阻塞，大大的延長服務部署的時間。事實上，長任務的服務通常都可以被改造成為批處理式的服務（Batch-Task Service），批處理式服務的升級只需要直接將服務執(zhí)行文件替換，從根本上簡化了升級難度。

監(jiān)控告警

內存不足、磁盤耗盡、網絡中斷、服務失效，這些天災人禍隨時可能殃及產品的服務集群。很難想象，在一個龐大的微服務系統(tǒng)中，如果沒有合適的監(jiān)控和告警設施，服務的運營會變得多么混亂不堪。

對微服務系統(tǒng)進行監(jiān)控主要需要考慮兩個方面：基礎設施的監(jiān)控和應用服務的監(jiān)控。

基礎設施的監(jiān)控通常由部署在每個節(jié)點上的數據采集端、集中式的數據匯聚端、以及數據展示、數據分析和告警通知等部分組成。而監(jiān)控告警系統(tǒng)的實施中，還需要結合團隊的運維自動化能力，選擇合適的技術棧進行。開源的Promethus和InfluxDB都是值得考慮的工具。

應用服務的監(jiān)控通常需要依據具體的開發(fā)技術棧進行選擇，例如Java Spring Boot的服務可以用Spring Boot Admin、Nodejs的服務則可用node-monitor和pm2等，此外也有一些通用的開源工具，例如Monit。應用服務的監(jiān)控除了需要能夠比較好完成故障的告警外，一些監(jiān)控工具還能嘗試自動恢復故障服務的運行，這些措施都能有效的增加服務的可靠性。

容器化

容器是一種能夠加速促進團隊DevOps水平的虛擬化技術。它通過把服務和系統(tǒng)依賴全量打包的鏡像格式，將運行環(huán)境的設計提前到了開發(fā)階段，并且實現了開發(fā)、測試、線上環(huán)境的高度一致。由于容器屏蔽了不同服務運行時的差異性，使得基于這種方式進行服務的大規(guī)模部署和調度變得簡單。具體來說體現在以下幾個方面：首先是運行環(huán)境的隔離。在虛擬機時代，由于每個業(yè)務依賴的系統(tǒng)環(huán)境不同，服務器之間無法通用。各個業(yè)務都需要獨立管理服務運行環(huán)境，還往往造成多個服務同時運行的沖突，和各個運行環(huán)境不一致等問題。容器為每個服務提供隔離的運行環(huán)境，即使在同一個服務器上運行多種運行時相互有沖突的服務也不會出問題。

其次是精細的資源分配。通過虛擬機分配服務資源時，為了簡化管理，通常不論服務實際使用多少CPU和內存資源，都只能從固定的主機類型中挑選一種，按主機的個數計費。容器能夠很好的實現面向資源池的服務管理，各個服務可以根據并發(fā)進程數、CPU和內存用量等資源計費，實現更加精細的資源管理。

此外，容器還有利于資源的動態(tài)調整。過去企業(yè)里的服務器資源一般是按計劃分配的，有的部門為了避開繁瑣的資源申請流程，一次性申請大量資源囤積備用，造成浪費。容器的面向資源池特性，使得企業(yè)能夠將所有計算資源進行運行時動態(tài)調整，實現按計劃分配到按需分配的轉變。業(yè)務只需適應流量負載的變化。在負載高峰期快速增加資源，保證業(yè)務服務質量，在負載低峰期釋放資源給其它服務，提高集群資源利用率。

容器將部署、運行的方式和業(yè)務很好的進行了解耦，目前已經有許多成熟的基于容器設計的開源調度框架，例如SwarmKit、Kubernetes、Mesos、Rancher等。由于微服務架構天生具有集群的特性，采用這些框架能夠極大的簡化服務部署和運維的工作量。

小結

成功的實施微服務架構需要設計的不僅僅是架構本身，還有圍繞整個服務集群的所有基礎設施和團隊的自主性文化。從實踐的角度上說，本文所提到的這些方面也遠不是微服務所需要考慮的全部。還有很多沒有提到的實踐，同樣是值得采納的，只是它們相對而言并非那么要緊。比如灰度發(fā)布，在微服務體系中也具有很大的運用空間。

每一個精心設計的企業(yè)級架構背后，都蘊含了相當的復雜性，微服務亦是如此。優(yōu)秀的架構并不能讓軟件的復雜度憑空消失，而是通過更加合理的拆分和約束，使得軟件結構更加容易匹配業(yè)務、適應變化，從而在規(guī)?；耐瑫r保持高度的響應力。架構不是銀彈，離開了必要的實踐前提，空談微服務，猶如東施效顰，期望拆了服務就能為企業(yè)帶來受益，無疑于空中樓閣的笑話而已。