本篇文章将帶您系統了解關于企業級微服務治理與開發的關鍵概念及選型指南，希望能為您的企業級現代化應用建設提供啟發。
微服務是應用現代化趨勢下的必然選擇
随着數字經濟的不斷發展，企業面臨着更加多樣化、靈活化的新時代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的基本運作原理：
1、當使用者向 Kubernetes 送出一份新的配置，首先會觸發 galley 注冊在 kubernetes 中的webhook，webhook 會檢查配置是否合法，如圖中的步驟1。
2、若配置無法通過校驗，則 kubernetes将拒絕使用者送出的配置，并給出相應的錯誤資訊。如圖步驟2。
3、當配置通過校驗後，通過 kubernetes 的通知機制，galley得到配置變更資訊
4、Galley 将變更的配置/服務資訊轉換為 MCP 的格式通過 MCP 協定推送給pilot，如圖步驟4。
5、最後一步，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）。
· 容錯。
· 快速演化。
同時，根據企業的自身組織架構情況和業務情況進行針對性規劃設計。
如您有企業級微服務改造需求，歡迎聯系我們，共同探索應用現代化最佳實踐。
上一篇：企業應用現代化實用教程 | 如何快、準、狠地進行應用容器化改造？
下一篇：企業應用現代化實用教程 | IT架構師必讀的DevOps落地行動指南