作者丨趙鈺瑩

簡單來說，微服務是將大型單體應用程序和服務拆分為數個甚至數十個微服務，可擴展單個組件而不是整個應用程序堆棧，從而滿足服務等級協議。然而，這個過程涉及很多問題需要解決，比如拆分原則、容量規劃、組件選擇、服務治理甚至人員配比等。本文，Pivotal 云平臺資深架構師劉凡將詳細講解從 Java 開發者轉型微服務這些年所做的思考。

根據維基百科的定義，微服務不是整體應用程序中的一個層。相反，微服務是一個獨立的業務功能，具有清晰的接口，并且可以通過內部組件實現分層架構。從戰略角度來看，微服務架構基本上遵循“做一件事，就要做得好” 的 Unix 哲學。為了應對傳統單體架構的缺陷，微服務架構被企業廣泛應用。然而，實踐之前有很多問題都需要提前考慮清楚，比如 Java 背景的開發者是否更有優勢？微服務、容器化、DevOps 和 CI/CD 之間的關系？如何合理進行微服務拆分、服務治理、容量規劃以及人員分配？

眾所周知，Pivotal 是云原生應用的提出者，并推出了 Pivotal Cloud Foundry 云原生應用平臺，目前最流行的微服務框架 Spring Boot 和 Spring Cloud 正是 Pivotal 的技術。本文，InfoQ 有幸對 Pivotal 云平臺資深架構師劉凡進行了獨家采訪，了解他在轉型微服務過程中所做的思考。

1如何理解微服務？

如果簡單總結微服務的概念，劉凡認為，微服務是一種架構模式，是業務領域組件模塊的集合。通過輕量級的通信方式和比較靈活的聚合方式，微服務組合在一起，借助持續集成、持續交付等工具實現獨立部署。

作為一名曾經的 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 之中。

2微服務實踐流程思考

在了解概念的基礎上，企業就可以考慮微服務的具體實施路徑。當然，并不存在通用的理想路徑，企業需要結合自身情況選擇最合適的方法。對于沒有歷史包袱(老舊系統)的企業，只需按照云原生實踐的相關方法論和工具，比如云原生十二要素進行改造即可。對于大型既有系統的微服務改造，劉凡推薦了可能的遷移路徑供企業參考：

• 第一階段：通過適當配置讓業務在云平臺順利運行；

• 第二階段：進行微服務拆分，通過特定實現技術和規則將單體應用拆分成更細粒度的服務，此時已經開始向云原生應用轉變；

• 第三階段：當微服務規模足夠大之后，需要考慮微服務的治理以及不同部門微服務之間的協調。

在這個過程中，企業還需要解決微服務容量規劃、服務聚合、服務治理、服務測試等問題。

在容量規劃層面，單體應用時代只需針對單個應用的訪問量和實際接口性能決定要不要擴容，拆分為微服務之后需要考慮每個服務的容量規劃。劉凡建議，整體需要基于服務類型、團隊規模和技術棧進行規劃。首先，不同的服務類型存在一些標準規則，比如大數據分析引擎可能需要遵循實時數據分析原則；其次，如果團隊規模在五到八人之間，微服務不建議拆分得太多，否則運維、管理、更新都很難安排出人手；最后，微服務應用達到一定規模之后就很難通過純手工的方式進行管理，需要云平臺和容器化技術的加入以幫助大容量微服務生命周期管理。

在服務聚合層面，主要涉及微服務的編排或者組合。在某些場景中，拆分后的微服務也需要彼此協作。劉凡表示，這種情況比較推薦常見的典型架構，比如通過 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 系統的架構等諸多方面綜合考慮，采用持續演進的方式進行微服務設計和開發。領域驅動設計只是指導開發者從業務角度設計一個比較合理的微服務架構，這個微服務架構是否能夠適合企業環境，還需要基于更多方面的因素，比如業務邏輯復雜性、團隊技術能力等。

3結束語

隨著越來越多企業和開發者持續演進其微服務架構，劉凡認為，微服務未來將向 FaaS/Serverless 方向發展，基于事件驅動的微服務的使用會越來越廣泛，因為平臺會不斷重塑，重塑之后可以幫助開發人員減少對于平臺的依賴性，更關注業務本身，微服務的粒度就會隨之變小，甚至成為一個函數，進而幫助開發者完成一些關鍵計算和邏輯問題。Pivotal 將在幫助企業進行數字化轉型的過程中更多做一些成熟、穩定的解決方案，持續推行基于云原生的方法論，基于客戶需求不斷進行方法論和最佳實踐的演進。

4嘉賓介紹

劉凡，Pivotal 云平臺資深架構師，主要負責架構和客戶解決方案應用，過往曾在不同的企業做過分布式系統，包括 J2EE 系統和企業級應用開發工作。

劉凡長期從事軟件研發和技術創新工作，曾先后就職于石化盈科、Adobe 中國研發中心、IBM 等大型國內外 IT 企業，從事軟件產品研發，系統架構設計，研發管理等工作。在十多年的軟件行業從業經歷中，積累了豐富的分布式系統架構設計、自動化平臺運維和系統穩定性調優等相關經驗。近期主要專注于微服務云原生應用的開發和設計，支持多個知名客戶企業進行數字化轉型，對敏捷開發和傳統巨石應用拆分以及往云上遷移擁有豐富的實戰經驗。

5名詞解析：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 更多的是通過自動化的方式，或者是自動化的交付工具鏈，幫助開發和運維人員更快速地從源代碼部署到相應云平臺。

點個在看少個 bug ?

總結

以上是生活随笔為你收集整理的java 搭建企业应用框架_溯源微服务开发体系：一位Java开发者的转型思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。