微服務是當前軟件開發領域的技術熱點。不過，隨著云原生技術的推廣以及大量微服務的落地，反微服務的聲音越來越響亮。特別是今年 Istio 1.5 版本發布，其控制面由原來的多個微服務組件合并成了一個單體應用，極大地簡化了架構以及部署運維的復雜性，獲得了一致好評，社區中對微服務模式質疑的聲音也接連不斷。

那么，微服務到底能給業務帶來哪些好處呢？在云原生時代又該如何更合理地落地微服務呢？

架構沒有好壞優劣之分，只有適合與不適合。但將微服務架構與單體架構進行比較，就會發現微服務具有以下優點：

首先，微服務獨立運行，以進程方式隔離，能夠有效控制故障范圍，讓架構更可靠。

其次，微服務架構因為故障被有效隔離，整體可用性更高，降低了單點故障對整體的影響。

再者，微服務粒度更小，架構演進的影響面也更小，不需要大規模重構，只需調整個別微服務就行。

然后，微服務架構可以實現以服務為粒度，通過接口共享重用，可重用性更高。接著，微服務架構能夠根據服務對資源的要求以服務為粒度進行擴展，可擴展性更靈活。最后，服務拆分后，各個服務可以獨立并行開發、測試、部署，交付效率大幅提升，產品更新換代速度加快，用戶體驗也更好。

圖片

1. 團隊調整

團隊需要重新組建，要以服務作為核心，按照業務領域來劃分全功能團隊，同時對原有的研發流程和決策機制進行改變。比如，要倡導敏捷文化、做到快速迭代，進行更多的自動化測試，并且加強代碼審查（Code Review）等工作。此外，微服務框架能夠對分布式場景下的一些常用能力（如負載均衡、容錯、遠程通信等能力）進行封裝和抽象，這樣開發人員就可以快速開發出高質量的服務了。所以，在采用微服務之前，應該先進行微服務架構的選型、學習和試用工作，使整個團隊儲備一定的微服務相關知識。

2. 基礎設施建設

基礎設施即代碼，它能通過編程來管理虛擬機或容器，無需手動配置和更新各個硬件，這讓基礎設施富有彈性，能夠快速、高效且準確地進行重復性操作。開發人員利用同一套代碼或配置，就能部署并管理數量眾多的物理機。

此外，當服務數量增多、交付頻繁時，故障次數可能大幅增加，所以需要構建全面的監控體系來發現故障并及時處理。在生產環境出現問題時，還需對故障進行分級，評估影響范圍，再分配給相應負責人。

微服務架構的一大優勢是快速交付，這既體現在服務粒度更小，也體現在整個流程更加快速。因此需要打造基于自動化的工具鏈，以流水線交付的方式將整個 DevOps 流程串聯起來。這樣一來，小團隊就可以基于服務進行獨立的開發、測試、部署和運維。這兩點并非采用微服務模式的充分必要條件，但如果能夠滿足，微服務化的過程會更加順利，后續的維護和迭代也會很輕松，而不是困難重重。

另外需要注意，微服務應該隨著業務的發展逐步拆分。幾乎所有成功的微服務架構都是從龐大的單體架構拆分而來，而幾乎所有一開始就構建微服務架構的案例，后續都遇到了很大的困難。面對新的業務和領域，我們在開始階段很難把業務梳理得非常清晰，往往是經過一段時間、經歷一些挫折后，業務內部的架構才逐漸清晰。從已有的模塊清晰的單體架構逐步劃分服務，比一開始就構建微服務要簡單得多。否則會有兩個弊端：一是第一版的交付時間會大大延遲，因為需要構建很多公共服務；二是服務很容易拆分不合理，嚴重影響整個調用流程的性能，甚至可能需要花費大量精力處理分布式事務，最后不得不把多個微服務重新整合成一個單體。

而且，只有當業務復雜度達到一定程度后，微服務架構消耗的成本才會體現出優勢。微服務設計應該遵循垂直劃分優先原則，這樣可以讓團隊自上而下地關注業務實現，做到端到端負責，避免因跨服務多次調用而產生的性能和溝通成本。

圖片

1. 選擇合適的時機

在實際落地過程中，若想享受到微服務帶來的好處，就需要做好一些前期準備工作。例如，組織架構和團隊文化要與云原生的節奏相適應，要足夠敏捷且足夠自主；要構建全功能團隊，將產品、UI、前后端研發、測試等角色配備齊全；要提前打造自動化的流水線，實現一鍵構建、發布、部署以及快速擴縮容等功能；服務也要提前進行容器化部署改造，因為服務容器化更有利于在云原生場景下集成其他功能組件。當上述準備工作全部完成，并且業務也逐漸發展到一定規模、急需進行拆分的時候，就應該當機立斷地進行微服務拆分和架構設計了。

2. 選擇合適的微服務框架

現在主流的微服務框架主要分為兩類：侵入式與非侵入式。

主流的侵入式框架包括 Spring Cloud、Dubbo、brpc 等，這些框架的功能特色各有不同，在不同場景中均有應用，大部分架構師對它們都比較熟悉，其社區和文檔的成熟度也都較高。雖然像 Spring Cloud 這樣的傳統侵入式微服務框架存在版本碎片化嚴重、升級成本高等問題，但總體而言，它們已經能夠滿足絕大部分服務治理的需求。

現在大部分人更關注非侵入式框架的選型，也就是近幾年興起的服務網格技術。2017 年，隨著 Linkerd 的傳入，Service Mesh 被翻譯成服務網格，并開始進入國內社區的視野。部分大公司也同步自研了適合公司內部應用場景和依賴的服務網格框架，以此助力內部服務的快速迭代與發展。

而 Istio 作為一個開源的 Service Mesh 框架，一經推出就備受關注，成為各大廠商和開發者追捧的對象。很多人認為，Istio 會成為繼 Kubernetes 之后又一個明星級產品。有了 Istio，基本上不再需要其他微服務框架，也無需自己去實現服務治理等功能。只要把網絡層委托給 Istio，它就能完成這一系列工作。簡單來說，Istio 是一個提供服務治理能力的服務網格。

此外，Istio 還具備完善的可觀察性方面的能力，包括對所有網格控制下的流量進行自動化度量、日志記錄和追蹤。換句話說，選擇了 Istio，單體應用無需進行任何改造就能輕松接入微服務，享受云原生的各項好處。

3. 借助云廠商產品快速進行云原生與微服務落地

之所以提及云廠商，是因為大多數中小型公司或者傳統行業都被單體應用和傳統微服務框架的種種弊端所困擾，迫切需要進行云原生和微服務的改造。然而，它們缺乏足夠的人力和技術來維護一套具備齊全功能的云原生底座和基礎架構服務。以 Istio 框架為例，它的版本更新頻繁，控制面和數據面在提供強大功能的同時，其代碼實現也相當復雜。當出現異常時，很多工程師往往難以定位問題所在。而云廠商提供了一整套云原生應用編排和微服務管理的解決方案，所有技術都實現了產品化，方便使用且易于查看效果，還能避免或者快速解決運行期間可能遇到的各類問題。從一定程度上來說，這既提高了服務效率，又大幅降低了各種成本，能夠讓人快速且充分地享受到云原生的好處。

總的來說，任何軟件或者架構都有其優缺點，不存在十全十美的事物。當大家在考慮是否要落地微服務時，需要思考和權衡的是：當前的軟件和系統是否滿足微服務化改造的前提條件，微服務化改造后所帶來的收益是否大于損失、好處是否多于弊端，團隊在各個方面是否做好了準備。如果還沒有準備好，那么不妨再等等，畢竟單體架構也有其自身的優勢。