微服務敏捷開發模式探索與實踐

1 What篇：理解微服務架構及其關鍵特征

1.1 什么是微服務架構，其關鍵特征是什么？基層組織與流程如何進行相應調整以適應微服務架構？

1.2 微服務實踐來自Amazon、NetFlix、eBay等互聯網公司，但概念則是由ThoughtWorks的首席科學家Martin Fowler總結提出，原始描述如下：

微服務的特征可總結為四個字：小、獨、輕、松。通過對四個特征的分析可以發現，微服務跟傳統單體式應用（Monolithic）、傳統SOA架構之間是有明顯區別的。

對于“小”這一要求，也許有人持不同看法。為什么一定要小或微呢？也就是說“大拆小”能帶來什么好處？互聯網提倡“大系統小做”，目的是為了降低海量系統的復雜度，分而治之，通過系統各個小服務的敏捷實現整個系統的敏捷，即所謂“大象也能跳舞”。那么多小算小？Amazon提出以2-Pizza的團隊規模來衡量微服務大小是否合適。一方面是為了讓各小團隊聚焦做好自己的功能單元、盡量重用已有服務能力、不盲目擴大本服務的范圍，另一方面也是認為由8~12人負責一個可獨立交付單元、管理上是最高效的。反之，傳統以大兵團模式投入幾十上百人開發一個耦合在一起的大服務，需要大量的溝通、協調與配合，很可能會成為交付的瓶頸、影響整體上線節奏。總而言之，“小”只是手段，“敏捷”才是目的。

關于“獨”，要求每個微服務都是單獨的進程，這種方式相比傳統架構下的模塊、組件、插件等而言，邊界更加清晰。前者是進程間的調用關系，只能依賴技術無關的服務接口；而后者一般是進程內代碼API間的調用關系，技術實現上是相互鎖定的。高內聚、松耦合的軟件設計原則大家都清楚，往往一開始也是按此進行設計和實現的，但向前演進幾個版本之后可能就變得血肉模糊或架構看護成本巨高，就是因為傳統架構下較難維持清晰的邊界。

對于“松”耦合，首先是軟件系統架構的解耦，即每個微服務可獨立編譯（無二進制接口依賴）、獨立部署（無部署順序依賴）、獨立運行（無啟動順序依賴）…，同時也要相應地進行基層研發組織的解耦（從大兵團到2-Pizza Team）、以及面向微服務生命周期的研發流程解耦（從串行到并行）。核心目的是兩點：1）微服務自治，讓每個微服務成為可獨立開發、構建、驗證、部署和擴展的最小單元；2）全流程自助Self-service，每個開發者可以自助式開發、構建、驗證、部署及監控自己的微服務。盡可能給以微服務為單元的交付件、組織、流程松綁，只有松綁才能快，這是微服務敏捷開發模式的核心理念。

2 Why篇：向微服務架構轉型的意義

2.1 為什么微服務模式開發、驗證、上線速度更快？

在傳統模式下，軟件需要各個組件/模塊集成構建出一個完整版本之后才能統一安裝部署、構造測試數據與環境、啟動驗證。這個過程涉及大兵團協同作戰，相當于造航母，未全部調測好之前不敢下水、一下水就沉，單個開發者很難獨立去調測軟件修改的效果，必須等到BBIT/TR4A集成好的版本出來后大家一起去驗證，驗證發現問題刷新后還得等新版本再次集成出來并構造好環境之后才能回歸驗證，周而復始多輪版本才能穩定下來，這個過程無疑是低效的。

而微服務模式下，相當于造動車，雖然各節車廂提供的能力各不相同（如車頭控制方向、餐車僅供就餐、有座位/臥鋪車廂之分等），但每節動車自帶動力、可以獨立跑（自治的概念），只要保證每節動車之間的接口不變、就很容易集成，而合起來就是功能完整而強大的動車組，相當于眾多微服務集成后的軟件系統。

為什么微服務模式開發、驗證、上線速度更快？如下圖所示，微服務管控平臺（生產裝備）及Stage環境（生產車間）是永久在線的，開發者可以全流程自助式完成開發、構建及驗證，不需要依賴和等待別人，可以隨時隨地推送自己的微服務到Beta/Gamma進行集成驗證或類生產驗證，相當于原來等到BBIT/TR4A/TR5/TR6才能驗證的內容現在一天內就可以進行多次驗證。因此也就不難理解，為什么傳統架構及開發流程下版本發布以“月/季度/半年”為發布周期，而微服務模式下能做到以“天/小時”為上線周期。

各Stage環境的定位如下：

Alpha——針對單個服務的自驗環境，可以對接Beta環境進行驗證；

eta環境——定位于快速集成驗證，部署最新、最全的微服務版本；

amma環境——定位于面向不同客戶場景的精準驗證，是根據典型組網及部署方案搭建的類生產環境，僅部署客戶場景使用到的服務。

3 How篇：如何實施微服務開發模式

微服務在公有云DevOps商業場景（自己開發自己運營）下，互聯網的實踐經驗已經證明是非常高效的。但這不是我司的主流商業模式，我們現階段仍然是以產品銷售為主，微服務是否能發揮威力呢？下面從流水線能力及運作流程角度，詳細闡述如何將微服務的敏捷基因融入產品化交付場景，相當于把互聯網的敏捷交付能力復制給運營商客戶（從1到N）。

3.1 微服務架構及流水線如何應用于產品化交付場景？

面向公有云服務發布場景：使用前述的微服務開發流水線能力（如下圖藍色部分），就能支持按微服務快速開發與上線。各微服務組遵從“You build it, you run it.”的原則，自行負責微服務在各Stage環境的部署升級、并保障其穩定運行。

面向產品化發布場景：在微服務流水線基礎上，需要擴展Pipeline工具能力、增加典型的產品化Gamma環境，以實現一鍵式制作產品化集成版本（如圖紅框部分）。

完整的產品化集成版本由松耦合的三部分組成：

1)管理面安裝包：通過重用管控平臺的部署服務能力構建管理面安裝包；

2)應用面安裝包：通過從產品化Gamma環境導出微服務構建應用面安裝包；

3)部署模板：結合客戶現網組網及部署方案設計部署模板，如單機部署、6節點分布式部署等。

補丁版本制作過程類似，通過導出Gamma及現網生產環境的微服務版本號列表進行差異比較，提取更新的微服務包制作補丁。

講到這里可能會有人提出兩個問題。

Q：為什么要基于Gamma環境不是基于Beta環境導出應用包？

A：主要基于Stage環境的定位及更新節奏考慮：

1) 看定位：如前所述兩者定位不同，Beta定位于快速集成，Gamma定位于精準測試，Gamma環境導出的版本才是經過客戶化場景驗證的，質量更符合要求；

2) 看節奏：Beta版本更新快，Gamma則保持與局點節奏一致；對于收編節奏比較慢的局點版本，可以跳過Beta、直接從Alpha推送到Gamma進行驗證，維持Gamma與客戶現網版本一致。Alpha與Gamma可以有多套，Beta盡量只搭建統一的一套。

Q：為什么不先制作安裝盤再進行Gamma驗證？有些問題需要通過安裝盤部署才能發現。

A：安裝盤部署階段引入的問題確實需要考慮，詳細解決辦法參見3.3小節。這里之所以先Gamma驗證再制作安裝盤，主要原因是：

1) 保留類似客戶生產環境的在線Gamma環境，而不是基于安裝盤臨時搭建、臨時構造測試環境，才能支持新特性或BugFix的快速開發、部署與驗證；

2) 基于持續在線穩定運行的Gamma環境反向制作安裝盤版本（快照式導出），該版本應用面運行態質量等同于當前的Gamma環境，版本問題明顯比傳統方式收斂更快。

跟宜家所謂的“體驗式營銷”類似，也許我們可將這種模式稱為“體驗式交付”。宜家搭建各好各個場景的家具組合環境供客戶體驗，就相當于讓客戶提前驗收不同場景下的搭配組合；客戶對于滿意的組合環境只需記下家具編號（快照）、提貨回家就能還原出跟宜家一樣的整套組合或局部組合，更易做到一步到位。

3.2 微服務并行開發模式與產品化IPD流程如何結合起來？

在公有云的服務化交付場景下，效率最高的方式是以各個微服務為中心的DevOps持續交付模式，即各微服務獨立開發、上線、運維保障。在產品化集成交付場景下，當前IPD仍然是我們的研發主流程。那么兩者如何結合，做到既不損失微服務并行開發的敏捷性，又能保證IPD下按合同交付滿足客戶要求的集成版本的嚴謹性？具體做法是：

1)各服務組按特定的開發節奏制定迭代計劃持續構建和發布微服務版本（各組節奏可以是異步的、不強求拉齊），即按服務化DevOps過程運作；

2)IPD項目立項之后，PM/SE要將項目交付目標、里程碑計劃等分解到各服務組，由各組將這些要求納入迭代計劃中（每三個月滾動刷新），然后按既定節奏在流水線上進行開發、驗證，迭代完成之后需將微服務包歸檔到軟件倉庫（備注：各組迭代出口前需將微服務版本推送到Gamma環境并驗證通過）；

3)最后由集成交付組基于流水線Pipeline工具一鍵式組裝穩定的產品化版本，通過集成驗證組測試之后對外發布。

我們對上述過程作一個形象的類比，幫助理解和記憶：將項目要求分解給各組的過程相當于“播種”，各微服務獨立開發、部署、驗證過程相當于“耕耘”，驗證充分之后發布穩定的微服務版本到軟件倉庫相當于“收割”，最后基于Pipeline流水線工具一鍵式生成產品化版本的過程則等同于“制作面包”。“耕耘”和“收割”過程由各組按微服務DevOps方式持續迭代交付、是最敏捷的（備注：除了公有云生產環境Ops，保障Beta/Gamma穩定運行也可以理解為窄義上的Ops），“播種”和“制作面包”的過程則是確保按IPD交付滿足客戶要求的集成版本、是最嚴謹的。

3.3 微服務開發流水線如何支撐版本火車進入高鐵時代（當天啟動當天發布）？

在流水線基礎能力ready、微服務模式與IPD項目關系理順之后，我們從微觀層面描述一次版本從啟動制作、驗證到發布的全過程。

1. 日常運作：集成驗證組每日定時巡檢Gamma環境，各組需保障好自己的服務在Gamma環境中穩定運行，巡檢發現的問題需及時解決；

2. 啟動前檢查：版本經理下發版本啟動制作的計劃之前，需確認當天的巡檢用例必須是全部通過的，這是啟動Gamma轉測的第一條紅線；

3. 鎖定Gamma環境：啟動Gamma環境轉測試前，由集成驗證組鎖定環境，各組不能隨意更新該環境的服務版本；

4. Gamma轉測試：集成驗證組通過自動化驗證及手工測試，驗收本次集成版本交付的需求，完成問題單回歸以及DFx測試等；如果Gamma驗證通過則繼續向下制作版本，若不通過則針對嚴重問題進行局部更新（僅向問題相關的服務組單獨開放權限）；

5. 制作發布包：產品集成交付組基于Pipeline工具自動化制作版本發布包，制作過程為：自動導出Gamma環境的微服務版本號列表，然后從軟件包倉庫中獲取微服務版本進行打包制作；（備注：如果是公有云微服務應用包發布場景，則直接發布此應用包即可，不涉及下面的安裝盤驗證環節，END）

6. 安裝盤自驗：對于產品化版本，基于Pipeline自動化執行安裝盤版本靜默安裝、Gamma環境與安裝環境比對、自動化冒煙測試等一系列動作，若不通過則針對嚴重問題進行局部更新（僅向問題相關的服務組單獨開放權限），通過則滿足安裝盤版本轉測入口的第二條紅線，交給集成驗證組對安裝盤進行測試；

7. 安裝盤轉測試：產品化安裝盤的測試重點是驗證Gamma環境下無法驗證的用例，包括產品手工安裝、安裝場景下的差異化用例、與安裝過程相關的重點問題單二次回歸等（備注：因為有些用例需要在安裝過程中手工輸入參數，Gamma在線環境下是驗證不了的，所以這個環節對于保障安裝盤質量非常重要）；安裝盤測試若發現嚴重問題進行局部更新（僅向問題相關的服務組單獨開放權限）；

8. 解鎖Gamma環境、發布版本：如果安裝盤轉測試通過則解鎖Gamma環境、發布版本，END。

在一個成熟運作的版本團隊中，整個過程有望控制在8小時以內（8H=Gamma驗證3H+產品集成及自動化驗證0.5H+安裝盤場景差異化驗證2.5H+預留局部更新2H），即版本火車真正進入了高鐵時代（當天啟動當天發布），這不正是我們孜孜以求的“互聯網水平”的敏捷交付能力嗎？

歸納起來，應用基于微服務架構及平臺實現敏捷交付的關鍵點在于：

1. 驗證環境永遠在線，可隨時隨地進行集成驗證與類生產驗證，真正的“環境零等待”；

2. 每日定時巡檢，保障基礎驗證環境穩定可用，在一個穩定的環境進行增量刷新，比較容易實現“缺陷快速定位和修復”；

3. 哪個環境發現的問題，就在哪個環境及時修復、并完成問題回歸，實時保障“代碼和環境高度健康”，版本想出就能出。

4. 基于一個已經充分驗證的類生產環境“快照式”導出版本，制作的版本“質量一步到位”。

4 總結：微服務開發模式的核心理念

實施微服務開發模式的過程中，最關鍵的是理解其核心理念：解耦，在線，自治，自助。

解耦：解耦是一切的基礎，所以微服務重點突出了一個“微”字。這里解耦的概念，不僅包括軟件架構上從單體應用到微服務的解耦，也包含基層開發組織由大兵團到2-Pizza Team的解耦、從開發到上線全流程并行化的解耦；

在線：微服務管控平臺和Stage環境要做到永久在線，方便開發者隨時隨地進行“自助式”集成驗證；這就要求各個微服務Owner保障好自己的服務無間斷地穩定運行，在升級時要么做到不中斷業務，要么選擇在無人訪問的晚上進行升級；

自治：每個微服務是獨立開發、部署、運行的最小單元，各服務只能以技術無關的服務接口方式對外提供能力，也只能通過服務接口調用其他服務提供的能力，這保證了每個微服務在技術實現上的獨立性，只要服務接口保持不變就可以獨立演進（因為單個微服務體量小，即使用新的語言、新的技術重寫一遍，工作量也可以接受，更容易享受新的技術成果）；

自助：各開發者在流水線上就能自行完成微服務全生命周期的活動（從創建、開發、編譯、驗證、部署、升級、上線到下線，從生到死），不依賴于其他組織與人員；尤其是集成與驗證活動的自助化，大大避免了傳統大版本模式下“齊步走、相互牽制”的問題。

轉載請注明出處：華為云博客 https://portal.hwclouds.com/blogs

微服務 敏捷開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。