宿俊艾

本篇文章將帶您系統(tǒng)了解關(guān)于企業(yè)級微服務(wù)治理與開發(fā)的關(guān)鍵概念及選型指南，希望能為您的企業(yè)級現(xiàn)代化應(yīng)用建設(shè)提供啟發(fā)。

微服務(wù)是應(yīng)用現(xiàn)代化趨勢下的必然選擇

隨著數(shù)字經(jīng)濟(jì)的不斷發(fā)展，企業(yè)面臨著更加多樣化、敏捷化的新時代IT需求。

用戶行為的變化：業(yè)務(wù)應(yīng)用的用戶訪問不可預(yù)估，突發(fā)性訪問增多，存在臨時熱點(diǎn)事件或大促期間等不可控業(yè)務(wù)高峰期。

業(yè)務(wù)模式的變化：所有業(yè)務(wù)訪問都是通過互聯(lián)網(wǎng)渠道，包括Web、手機(jī)App、微信小程序等。

業(yè)務(wù)系統(tǒng)開發(fā)的變化：應(yīng)用再也不像以前半年或一年進(jìn)行規(guī)劃，隨時會有需求變化，兩周一個迭代成為常態(tài)。業(yè)務(wù)應(yīng)用交付周期短，質(zhì)量要求高。

運(yùn)維模式的變化：要求全天候值守，在線升級和快速響應(yīng)，不同團(tuán)隊(duì)特別是外包團(tuán)隊(duì)使用不同的技術(shù)棧，無法統(tǒng)一管控。

因此，評估一家企業(yè)是否需要采用微服務(wù)架構(gòu)，往往考察這五大關(guān)鍵條件：數(shù)據(jù)量和業(yè)務(wù)復(fù)雜度、團(tuán)隊(duì)規(guī)模、應(yīng)對業(yè)務(wù)流量變化、是否有足夠的容錯容災(zāi)，以及功能重復(fù)度和差錯成本。

在日益激烈的數(shù)字化競爭下，企業(yè)必須更快地?fù)肀袌鲎兓?、隨時響應(yīng)新的用戶需求，比對手更迅速地將產(chǎn)品推向市場。

微服務(wù)作為加速企業(yè)提升敏捷創(chuàng)新能力的重要抓手，能夠幫助企業(yè)快速實(shí)現(xiàn)獨(dú)立更新和部署應(yīng)用，快速應(yīng)對市場變化，逐漸成為企業(yè)加速應(yīng)用現(xiàn)代化的必然選擇。那么，微服務(wù)架構(gòu)要怎么選擇？

Dubbo

Dubbo是比較早期的一款微服務(wù)架構(gòu)，可以使得應(yīng)用通過高性能的RPC實(shí)現(xiàn)服務(wù)的輸出和輸入功能，和Spring框架無縫集成。

優(yōu)點(diǎn)是RPC長連接+NIO，性能更高，但協(xié)議的局限性，會限制生態(tài)發(fā)展和兼容性。

Spring Cloud

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

Spring Cloud擁有更成熟的Spring社區(qū)生態(tài)，更多成熟的企業(yè)應(yīng)用案例，但也存在一定不足，比如跨語言平臺問題、微服務(wù)治理對代碼侵入性較強(qiáng)。

Istio

Istio是當(dāng)前Service Mesh形態(tài)上比較熱門的實(shí)現(xiàn)方案，能夠和K8s深度結(jié)合，更快速、更便捷地實(shí)現(xiàn)服務(wù)治理。Istio提供了一種簡單的方法，來創(chuàng)建一個提供負(fù)載均衡、服務(wù)間認(rèn)證、監(jiān)控等的服務(wù)網(wǎng)絡(luò)，且不需要對服務(wù)代碼進(jìn)行任何更改。通過在整個環(huán)境中部署專門的Sidecar代理服務(wù)，來攔截微服務(wù)間的所有網(wǎng)絡(luò)通信，整個配置和管理通過Istio的控制面板來做。

作為新一代的微服務(wù)架構(gòu)，它的微服務(wù)治理與開發(fā)徹底解耦，適應(yīng)場景更廣泛，很多企業(yè)都正在逐步從Spring Cloud向Service Mesh過渡；但也正是因?yàn)榧夹g(shù)比較新，企業(yè)自研需要一定的學(xué)習(xí)成本，打破傳統(tǒng)IT運(yùn)維/開發(fā)壁壘，考慮引入專業(yè)的技術(shù)廠商則能夠完美地解決這一問題。

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

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

當(dāng)配置通過校驗(yàn)后，通過Kubernetes的通知機(jī)制，Galley得到配置變更信息。

Galley將變更的配置/服務(wù)信息轉(zhuǎn)換為MCP的格式通過MCP協(xié)議推送給Pilot。

最后一步，Pilot通過xDS協(xié)議向數(shù)據(jù)平面推送變更的配置。

以上為當(dāng)前常見的微服務(wù)架構(gòu)，那么企業(yè)實(shí)際改造時應(yīng)該怎么做呢？我們建議：

不同類型的應(yīng)用均可以通過微服務(wù)能力進(jìn)化到現(xiàn)代化應(yīng)用；

需要為傳統(tǒng)應(yīng)用提供一條穩(wěn)妥的轉(zhuǎn)型路徑；

需要為Spring Cloud應(yīng)用提供一條貼合云原生的、無需大規(guī)模適配的轉(zhuǎn)型路徑。

微服務(wù)架構(gòu)如何設(shè)計

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

接下來從微服務(wù)的必備基礎(chǔ)理論，也是企業(yè)進(jìn)行微服務(wù)所需遵循的一大原則康威定律網(wǎng)鉤：

組織形式等同系統(tǒng)設(shè)計。設(shè)計系統(tǒng)的組織，其產(chǎn)生的設(shè)計等同于組織之內(nèi)、組織之間的溝通結(jié)構(gòu)。

第一定律：組織溝通方式會通過系統(tǒng)設(shè)計表達(dá)出來。

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

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

復(fù)雜的系統(tǒng)需要通過容錯彈性的方式持續(xù)優(yōu)化，不要指望一個大而全的設(shè)計或架構(gòu)，好的架構(gòu)和設(shè)計都是慢慢迭代出來的。因此企業(yè)需要擁抱變化，解決當(dāng)下，先完成一個一個小目標(biāo)。

第三定律：線型系統(tǒng)和線型組織架構(gòu)間有潛在的異質(zhì)同態(tài)特性（There is a homomorphism from the linear graph of a system to the linear graph of its design organization）。

你想要什么樣的系統(tǒng)，就搭建什么樣的團(tuán)隊(duì)，反之亦然。

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

一個大的組織因?yàn)闇贤ǔ杀?管理問題，總會被拆分成一個個小團(tuán)隊(duì)。

具體來說，企業(yè)在進(jìn)行微服務(wù)架構(gòu)改造時，可以遵循以下標(biāo)準(zhǔn)：

分布式服務(wù)組成的系統(tǒng)；

按照業(yè)務(wù)而不是技術(shù)來劃分組織；

做有生命的產(chǎn)品而不是項(xiàng)目；

去中心化；

自動化運(yùn)維（DevOps）；

容錯；

快速演化。

同時還要根據(jù)企業(yè)的自身組織架構(gòu)情況和業(yè)務(wù)情況進(jìn)行針對性規(guī)劃設(shè)計。