微服務架構怎麼選？

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

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

　　隨著數字經濟的不斷髮展，企業面臨著更加多樣化、敏捷化的新時代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）。

　　容錯。

　　快速演化。

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