如何選擇微服務架構

宿俊艾

本篇文章將帶您系統了解關于企業級微服務治理與開發的關鍵概念及選型指南，希望能為您的企業級現代化應用建設提供啟發。

微服務是應用現代化趨勢下的必然選擇

隨著數字經濟的不斷發展，企業面臨著更加多樣化、敏捷化的新時代IT需求。

用戶行為的變化：業務應用的用戶訪問不可預估，突發性訪問增多，存在臨時熱點事件或大促期間等不可控業務高峰期。

業務模式的變化：所有業務訪問都是通過互聯網渠道，包括Web、手機App、微信小程序等。

業務系統開發的變化：應用再也不像以前半年或一年進行規劃，隨時會有需求變化，兩周一個迭代成為常態。業務應用交付周期短，質量要求高。

運維模式的變化：要求全天候值守，在線升級和快速響應，不同團隊特別是外包團隊使用不同的技術棧，無法統一管控。

因此，評估一家企業是否需要采用微服務架構，往往考察這五大關鍵條件：數據量和業務復雜度、團隊規模、應對業務流量變化、是否有足夠的容錯容災，以及功能重復度和差錯成本。

在日益激烈的數字化競爭下，企業必須更快地擁抱市場變化、隨時響應新的用戶需求，比對手更迅速地將產品推向市場。

微服務作為加速企業提升敏捷創新能力的重要抓手，能夠幫助企業快速實現獨立更新和部署應用，快速應對市場變化，逐漸成為企業加速應用現代化的必然選擇。那么，微服務架構要怎么選擇？

Dubbo

Dubbo是比較早期的一款微服務架構，可以使得應用通過高性能的RPC實現服務的輸出和輸入功能，和Spring框架無縫集成。

優點是RPC長連接+NIO，性能更高，但協議的局限性，會限制生態發展和兼容性。

Spring Cloud

Spring Cloud是基于Spring Boot的一整套實現微服務的框架，提供了微服務開發所需的配置管理、服務發現、斷路器、智能路由、微代理、控制總線等組件。Spring Cloud包含了非常多的子框架，Spring Cloud Netflix是其中一套框架，由Netflix開發后來又并入Spring Cloud大家庭，它主要提供的模塊包括：服務發現、斷路器和監控、智能路由、客戶端負載均衡等。

Spring Cloud擁有更成熟的Spring社區生態，更多成熟的企業應用案例，但也存在一定不足，比如跨語言平臺問題、微服務治理對代碼侵入性較強。

Istio

Istio是當前Service Mesh形態上比較熱門的實現方案，能夠和K8s深度結合，更快速、更便捷地實現服務治理。Istio提供了一種簡單的方法，來創建一個提供負載均衡、服務間認證、監控等的服務網絡，且不需要對服務代碼進行任何更改。通過在整個環境中部署專門的Sidecar代理服務，來攔截微服務間的所有網絡通信，整個配置和管理通過Istio的控制面板來做。

作為新一代的微服務架構，它的微服務治理與開發徹底解耦，適應場景更廣泛，很多企業都正在逐步從Spring Cloud向Service Mesh過渡；但也正是因為技術比較新，企業自研需要一定的學習成本，打破傳統IT運維/開發壁壘，考慮引入專業的技術廠商則能夠完美地解決這一問題。

當用戶向Kubernetes提交一份新的配置，首先會觸發Galley注冊在Kubernetes中的網（Webhook），網鉤會檢查配置是否合法。

若配置無法通過校驗，則Kubernetes將拒絕用戶提交的配置，并給出相應的錯誤信息。

當配置通過校驗后，通過Kubernetes的通知機制，Galley得到配置變更信息。

Galley將變更的配置/服務信息轉換為MCP的格式通過MCP協議推送給Pilot。

最后一步，Pilot通過xDS協議向數據平面推送變更的配置。

以上為當前常見的微服務架構，那么企業實際改造時應該怎么做呢？我們建議：

不同類型的應用均可以通過微服務能力進化到現代化應用；

需要為傳統應用提供一條穩妥的轉型路徑；

需要為Spring Cloud應用提供一條貼合云原生的、無需大規模適配的轉型路徑。

微服務架構如何設計

首先從微服務的定義來看，微服務是一起合作的獨立小服務單元，可以同步異步調用，也可以獨立拆分、獨立部署、獨立升級，后端中間件、存儲資源、數據庫等也是獨立的，最佳實踐是每個微服務都有自己的數據庫，真正意義上實現微服務應用解耦。

接下來從微服務的必備基礎理論，也是企業進行微服務所需遵循的一大原則康威定律網鉤：

組織形式等同系統設計。設計系統的組織，其產生的設計等同于組織之內、組織之間的溝通結構。

第一定律：組織溝通方式會通過系統設計表達出來。

人與人的溝通非常復雜，一個人的溝通精力是有限的，所以當問題太復雜需要很多人解決的時候，我們需要做拆分組織來達成對溝通效率的管理。在團隊內部進行頻繁的、細粒度的溝通。對于團隊外部，定義好接口和契約，只進行粗粒度的溝通。這樣可以降低溝通成本，同時也符合高內聚、低耦合原則。

第二定律：時間再多一件事情也不可能做的完美，但總有時間做完一件事情。

復雜的系統需要通過容錯彈性的方式持續優化，不要指望一個大而全的設計或架構，好的架構和設計都是慢慢迭代出來的。因此企業需要擁抱變化，解決當下，先完成一個一個小目標。

第三定律：線型系統和線型組織架構間有潛在的異質同態特性（There is a homomorphism from the linear graph of a system to the linear graph of its design organization）。

你想要什么樣的系統，就搭建什么樣的團隊，反之亦然。

第四定律：大的系統組織總是比小系統更傾向于分解。

一個大的組織因為溝通成本/管理問題，總會被拆分成一個個小團隊。

具體來說，企業在進行微服務架構改造時，可以遵循以下標準：

分布式服務組成的系統；

按照業務而不是技術來劃分組織；

做有生命的產品而不是項目；

去中心化；

自動化運維（DevOps）；

容錯；

快速演化。

同時還要根據企業的自身組織架構情況和業務情況進行針對性規劃設計。