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

隨著數字經濟的不斷發展，企業面臨著更加多樣化、敏捷化的新時代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運維/開發壁壘，考慮引入專業的技術廠商則能夠完美地解決這一問題。

上圖為Istio的基本運行原理：

當用戶向 Kubernetes 提交一份新的配置，首先會觸發 galley 注冊在 kubernetes 中的webhook，webhook 會檢查配置是否合法，如圖中的步驟1。

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

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

Galley 將變更的配置/服務信息轉換為 MCP 的格式通過 MCP 協議推送給pilot，如圖步驟4。

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

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

• 不同類型的應用均可以通過微服務能力進化到現代化應用。
• 需要為傳統應用提供一條穩妥的轉型路徑
• 需要為SpringCloud應用提供一條貼合云原生的、無需大規模適配的轉型路徑。

微服務架構如何設計？

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

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

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

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

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

第二定律：There is never enough time to do something right, but there is always enough time to do it over（時間再多一件事情也不可能做的完美，但總有時間做完一件事情）。

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

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

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

第四定律：The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems（大的系統組織總是比小系統更傾向于分解）。

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

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

• 分布式服務組成的系統。
• 按照業務而不是技術來劃分組織。
• 做有生命的產品而不是項目。
• 去中心化。
• 自動化運維（DevOps）。
• 容錯。
• 快速演化。

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