簡單來說，微服務是將大型單體應用程序和服務拆分爲數個甚至數十個微服務，可擴展單個組件而不是整個應用程序堆棧，從而滿足服務等級協議。然而，這個過程涉及很多問題需要解決，比如拆分原則、容量規劃、組件選擇、服務治理甚至人員配比等。本文，Pivotal雲平臺資深架構師劉凡將詳細講解從Java開發者轉型微服務這些年所做的思考。
根據維基百科定義，微服務不是整體應用程序中的一個層。相反，微服務是一個獨立的業務功能，具有清晰的接口，並且可以通過內部組件實現分層架構。從戰略角度來看，微服務架構基本上遵循“做一件事，就要做得好” 的Unix哲學。爲了應對傳統單體架構的缺陷，微服務架構被企業廣泛應用。然而，實踐之前有很多問題都需要提前考慮清楚，比如Java背景的開發者是否更有優勢？微服務、容器化、DevOps和CI/CD之間的關係？如何合理進行微服務拆分、服務治理、容量規劃以及人員分配？
衆所周知，Pivotal是雲原生應用的提出者，並推出了 Pivotal Cloud Foundry 雲原生應用平臺，目前最流行的微服務框架Spring Boot和Spring Cloud正是Pivotal的技術。本文，InfoQ有幸對Pivotal雲平臺資深架構師劉凡進行了獨家採訪，瞭解他在轉型微服務過程中所做的思考。
如何理解微服務？
如果簡單總結微服務的概念，劉凡認爲，微服務是一種架構模式，是業務領域組件模塊的集合。通過輕量級的通信方式和比較靈活的聚合方式，微服務組合在一起，藉助持續集成、持續交付等工具實現獨立部署。
作爲一名曾經的Java開發者，劉凡的微服務之旅是從PiggyMetrics開始的。這是GitHub上一個不錯的開源項目，通過此項目學習使用Docker和Spring Cloud如何做分佈式微服務架構。他認爲，微服務架構並不與具體編程語言綁定。回顧整個轉型過程，從分佈式應用開發轉爲微服務架構屬於業務的自然發展驅動，當業務發展到一定階段，自然就出現上雲訴求，需要對應用架構進行更新換代。雖然Java不是微服務開發的唯一選擇，但這是大多數企業應用開發選用的編程語言（佔比達到80%以上），其本身的企業級應用生態也比較完善和成熟。目前很多主流微服務框架均基於Java實現，但這並不是強綁定的關係，企業實踐微服務更多是爲了解決業務層面的問題。那麼，當業務出現哪些問題或者發展到哪一階段是實踐微服務的最佳時間呢？
關於此，業內曾有專家提出過比較簡單的判斷方式：當單體應用同時進行開發的人數超過10人就證明是時候進行微服務拆分了。劉凡表示，10人以下的團隊人數是基於現代應用使用敏捷過程組建團隊比較合適的規模，但如何拆分應用以及相配套的團隊規模，仍然需要通過業務複雜度和團隊技術儲備來確定。另一方面，微服務並不能解決企業所有的IT系統問題，尤其是信息化程度較爲落後的企業可能得不到太多好處。“大部分企業都是基於業務驅動選擇微服務架構”，劉凡談到，這種驅動可以大致分爲兩類：一是應對業務的快速變化，企業需要構建快速響應業務需求的能力，發佈更多創新型雲原生應用來提升用戶體驗和響應市場變化，通過敏捷開發流程滿足客戶所需；二是既有系統的雲化改造，企業首先已經認可了雲平臺帶來的類似彈性、安全、可靠性等優勢。由於傳統單體應用的運維模式給企業帶來很多困擾和大量的成本花費，企業希望通過運維轉型來縮短髮布週期，降低投資風險，從而提高企業核心競爭力。微服務改造是實現這一切的前提。
具體來說，一旦單體應用被劃分爲多個小模塊，投資風險就會隨之降低，業務創新更易付諸實現。其次，微服務本身與容器、DevOps、CI/CD（持續集成/持續交付，文末附介紹）以及雲平臺並不是割裂的，這些因素都會影響企業應用系統的雲化改造。劉凡介紹，微服務和容器本身是兩種技術，但容器可以讓微服務更快交付（微服務容器化），並保證可重複的、一致的交付體驗；DevOps更多是強調流程和方法論，通過自動化的交付工具鏈實現CI/CD，縮小開發和運維之間的界限，當然這不等於讓開發做運維的工作，或者讓運維做開發的工作，只是讓雙方協作更爲通暢。
如上可見，這些概念本身是相互獨立的，但云原生（Cloud Native）的思想卻可以把他們概念聯繫在一起。早在2015年，Pivotal公司的Matt Stine寫了一本叫做遷移到雲原生應用架構的小冊子，其中探討了雲原生應用架構的幾個主要特徵：
- 十二因素應用程序：雲原生應用程序架構模式的集合
- 微服務：獨立部署的服務，只做一件事情
- 自助服務的敏捷基礎設施：快速，可重複和一致地提供應用環境和後臺服務的平臺
- 基於API的協作：發佈和版本化的API，允許在雲原生應用程序架構中的服務之間進行交互
- 抗壓性：根據壓力變強的系統
當然，這不代表所有的雲原生應用必須具備這些特徵，但這是Pivotal當時對雲原生應用最佳實踐的定義（隨後，CNCF進行了重新定義，但依舊包含這些技術要素），這就驗證了前文所述爲什麼企業應用上雲時會進行微服務改造，甚至容器化等，只有符合最佳實踐的應用纔可以達到更好的資源配置、更優的性能以及更快速、完美的交付運維體驗。
這樣看來，微服務實踐並不是僅與架構師相關。從開發視角來看，企業可以擁有更爲獨立的開發團隊，開發人員只需關注業務本身，維護很小的代碼倉庫即可，不需要像傳統單體應用那樣維護應用間的諸多依賴，尤其是解決上線過程的很多代碼衝突；從運維視角來看，微服務會用到敏捷開發，包括DevOps方法論和實踐，通過CI/CD、數據集成等工具提速交付過程，降低上線風險和壓力。
微服務框架
Spring Cloud和Spring Boot是目前最受開發者關注的兩大微服務框架，大部分開發者認爲這二者非常相像，做的事情也比較類似。在劉凡看來，Spring Boot更傾向於微服務的最終實現手段，而Spring Cloud則是微服務治理方案。從傳統的單體應用轉變爲微服務，這個過程會引發很多分佈式系統問題，比如微服務需要部署在不同機器上或容器中，以及彼此之間需要互相通信，錯誤機制，日誌的聚合，業務指標度量監控等，這些問題都可以利用Spring Cloud進行微服務動態運行時的管理，而業務邏輯的實現都在Spring Boot之中。
微服務實踐流程思考
在瞭解概念的基礎上，企業就可以考慮微服務的具體實施路徑。當然，並不存在通用的理想路徑，企業需要結合自身情況選擇最合適的方法。對於沒有歷史包袱（老舊系統）的企業，只需按照雲原生實踐的相關方法論和工具，比如雲原生十二要素進行改造即可。對於大型既有系統的微服務改造，劉凡推薦了可能的遷移路徑供企業參考：
- 第一階段：通過適當配置讓業務在雲平臺順利運行；
- 第二階段：進行微服務拆分，通過特定實現技術和規則將單體應用拆分成更細粒度的服務，此時已經開始向雲原生應用轉變；
- 第三階段：當微服務規模足夠大之後，需要考慮微服務的治理以及不同部門微服務之間的協調。
在這個過程中，企業還需要解決微服務容量規劃、服務聚合、服務治理、服務測試等問題。
在容量規劃層面，單體應用時代只需針對單個應用的訪問量和實際接口性能決定要不要擴容，拆分爲微服務之後需要考慮每個服務的容量規劃。劉凡建議，整體需要基於服務類型、團隊規模和技術棧進行規劃。首先，不同的服務類型存在一些標準規則，比如大數據分析引擎可能需要遵循實時數據分析原則；其次，如果團隊規模在五到八人之間，微服務不建議拆分得太多，否則運維、管理、更新都很難安排出人手；最後，微服務應用達到一定規模之後就很難通過純手工的方式進行管理，需要雲平臺和容器化技術的加入以幫助大容量微服務生命週期管理。
在服務聚合層面，主要涉及微服務的編排或者組合。在某些場景中，拆分後的微服務也需要彼此協作。劉凡表示，這種情況比較推薦常見的典型架構，比如通過API網關將微服務接口開放給客戶端，客戶端選擇需要調用的接口根據邏輯拼裝好數據，附加上相應的權限能力來訪問微服務。同時，也可以選用一些編排工具，比如Spring家族裏面的Spring Cloud Data Flow（文末附具體介紹），通過這樣的數據和流式編排工具完成微服務之間的組合或者聚合。
在服務治理層面，除了可以通過輕量級通訊協議將內部接口開放給外部系統外，業界目前比較流行的技術還包括Istio等。Istio是一種Service Mesh的技術，是一套無代碼傾入性的微服務治理且更符合運維人員習慣的解決方案，它使得微服務治理完全放到平臺層進而實現全面的DevOps成爲可能。雖然Istio目前還不太成熟，只發布到1.1版本。隨着越來越多的企業和用戶爲之貢獻，該技術會逐漸走向成熟並最終用於更大規模的生產環境。
在微服務測試層面，劉凡表示，軟件工程的質量保證是整個交付過程的重要衡量標準。因此，Pivotal推行測試驅動的實踐方法，通過單元測試覆蓋最基礎的業務領域功能；在微服務之間會採用API接口測試，基於API優先的雲原生要素，採用如Spring Cloud Contract的契約測試方法，或基於API文檔進行Mock測試。在交付階段，Pivotal還會進行端到端的測試，而此時需要搭建測試環境。在測試環境搭建和版本升級時，推薦使用迴歸測試的方法。相較於傳統應用的本地環境，微服務通常利用雲平臺自動化搭建測試環境，根據不同微服務的版本組合提交時會利用藍綠髮布、灰度發佈、A/B Testing等方式進行測試。
在這個過程中，劉凡認爲需要重點關注和比較困難的有兩點：一是業務與開發人員之間的理解和溝通，這是微服務設計和實踐難點。也就是說，開發人員一定要對業務領域和業務邏輯足夠清晰，纔可能準確、高效得拆分出衆多細粒度服務；二是CI/CD，做微服務一定要做CI/CD，雖然也有部分企業現在沒有做任何的CI/CD，僅使用手工的方式直接在機器上啓動很多微服務實例進程，然後手工運維。並不是說這種方式完全不可取，而是說，隨着微服務集羣規模的擴大，當達到一定程度後，如果不採用自動化的方式，整個運維工作量會指數級增長，等企業完成整個微服務轉型後，就會發現運維成本並沒有比傳統單體應用時代減少，甚至還增加了很多。因此，CI/CD是微服務落地非常好的實踐，然而CI/CD並不僅僅是引入像Jenkins或Concourse這樣的工具就可以達到，還需要企業整個流程甚至組織文化的轉型才能實現。
至於整個過程是否需要自建Kubernetes集羣或者選用自研組件。劉凡表示，微服務框架本身並未與任何平臺綁定，因此是否自建Kubernetes集羣並不是微服務要考慮的核心問題，只要能夠運行微服務即可。至於自研微服務框架，目前已經有很多企業通過Spring Cloud實現了自研，因爲微服務框架本身是一個開放生態，基於數據化需求可能會出現一些較好的自研方案，Spring Cloud並不與某一個雲平臺存在綁定關係。但是，自研其實更適合希望瞭解最新進展或者前人經驗的開發者，純粹因爲興趣愛好學習微服務框架還是可以的；而對於企業而言，因爲需要在生產環境運行，所以要考慮穩定性、安全性、可擴展性等問題，對開發團隊的要求也比較高，商用化軟件平臺可能是更好的選擇。
除了技術層面做好足夠的準備，團隊人員配置方面也需要準備好。儘管有非常好的基於領域驅動設計的微服務架構方法論，但團隊設計上還是需要考慮匹配開發人員、運維人員、利用自動化交付工具等團隊人員。一般情況下，如果一個敏捷團隊有5到8人，每個人管理2到3個微服務是比較合適的，但隨着微服務架構的演進發展，這也需要根據實際情況做出適當調整。
在實踐過程中，領域驅動設計（DDD）的思想也非常重要，劉凡在此基礎上進行了擴充，比較推薦基於業務邏輯、開發人員技術能力、團隊配置以及既有IT系統的架構等諸多方面綜合考慮，採用持續演進的方式進行微服務設計和開發。領域驅動設計只是指導開發者從業務角度設計一個比較合理的微服務架構，這個微服務架構是否能夠適合企業環境，還需要基於更多方面的因素，比如業務邏輯複雜性、團隊技術能力等。
結束語
隨着越來越多企業和開發者持續演進其微服務架構，劉凡認爲，微服務未來將向FaaS/Serverless方向發展，基於事件驅動的微服務的使用會越來越廣泛，因爲平臺會不斷重塑，重塑之後可以幫助開發人員減少對於平臺的依賴性，更關注業務本身，微服務的粒度就會隨之變小，甚至成爲一個函數，進而幫助開發者完成一些關鍵計算和邏輯問題。Pivotal將在幫助企業進行數字化轉型的過程中更多做一些成熟、穩定的解決方案，持續推行基於雲原生的方法論，基於客戶需求不斷進行方法論和最佳實踐的演進。
嘉賓介紹：
劉凡，Pivotal雲平臺資深架構師，主要負責架構和客戶解決方案應用，過往曾在不同的企業做過分佈式系統，包括J2EE系統和企業級應用開發工作。
劉凡長期從事軟件研發和技術創新工作，曾先後就職於石化盈科、Adobe中國研發中心、IBM等大型國內外IT企業，從事軟件產品研發，系統架構設計，研發管理等工作。在十多年的軟件行業從業經歷中，積累了豐富的分佈式系統架構設計、自動化平臺運維和系統穩定性調優等相關經驗。近期主要專注於微服務雲原生應用的開發和設計，支持多個知名客戶企業進行數字化轉型，對敏捷開發和傳統巨石應用拆分以及往雲上遷移擁有豐富的實戰經驗。
名詞解析：
Spring Cloud Data Flow
Spring Cloud Data Flow 是一款可自由組合的雲原生微服務 ， 用於收集、轉化、存儲和分析數據。Spring Cloud Data Flow 允許開發人員構建實時批處理應用程序，使用同樣簡單而強大 的模型作爲Spring Boot RESTful 微服務，並既能夠在本機或者像Pivotal Cloud Foundry，Kubernetes這樣的平臺上運行。有了 Spring Cloud Data Flow，開發人員可以繼續使用熟悉的 XD 工具 ， 如Java-DSL，xd-shell, admin-ui, flo和 rest-api 。與此同時 ， 全新再設計的體系結構提取所有的樣板配置 ， 用可靠的方式來策劃數據流處理和數據批處理流程 。 Spring Cloud Data Flow 管理器本身就是一個 Spring Boot 應用程序 。
CI/CD（持續集成/持續交付）
現代化應用比較推薦的交付鏈是從源代碼推送到源碼倉庫，打包之後就是通常所講的構建過程，構建之後會推送到二進制倉庫以保存不同版本的源代碼包，這些源代碼包通過交付鏈推送到不同環境中，可能是開發環境、測試環境或者生態環境，所有這些交付鏈上的環節如果都通過手工方式去做，當微服務數量非常龐大時，工作量就會非常大。CI/CD更多的是通過自動化的方式，或者是自動化的交付工具鏈，幫助開發和運維人員更快速地從源代碼部署到相應雲平臺。