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

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

• 用戶行為的變化：業(yè)務(wù)應(yīng)用的用戶訪問不可預(yù)估，突發(fā)性訪問增多，存在臨時(shí)熱點(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ī)劃，隨時(shí)會(huì)有需求變化，兩周一個(gè)迭代成為常態(tài)。業(yè)務(wù)應(yīng)用交付周期短，質(zhì)量要求高。
• 運(yùn)維模式的變化：要求全天候值守，在線升級(jí)和快速響應(yīng)，不同團(tuán)隊(duì)特別是外包團(tuán)隊(duì)使用不同的技術(shù)棧，無法統(tǒng)一管控。

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

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

微服務(wù)作為加速企業(yè)提升敏捷創(chuàng)新能力的重要抓手，能夠幫助企業(yè)快速實(shí)現(xiàn)獨(dú)立更新和部署應(yīng)用，快速應(yīng)對(duì)市場(chǎ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長(zhǎng)連接+NIO，性能更高；但協(xié)議的局限性，會(huì)限制生態(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)用案例；但也存在一定不足，比如跨語言平臺(tái)問題、微服務(wù)治理對(duì)代碼侵入性較強(qiáng)。

Istio

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

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

上圖為Istio的基本運(yùn)行原理：

當(dāng)用戶向 Kubernetes 提交一份新的配置，首先會(huì)觸發(fā) galley 注冊(cè)在 kubernetes 中的webhook，webhook 會(huì)檢查配置是否合法，如圖中的步驟1。

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

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

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

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

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

• 不同類型的應(yīng)用均可以通過微服務(wù)能力進(jìn)化到現(xiàn)代化應(yīng)用。
• 需要為傳統(tǒng)應(yīng)用提供一條穩(wěn)妥的轉(zhuǎn)型路徑
• 需要為SpringCloud應(yīng)用提供一條貼合云原生的、無需大規(guī)模適配的轉(zhuǎn)型路徑。

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

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

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

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

第一定律：Communication dictates design（組織溝通方式會(huì)通過系統(tǒng)設(shè)計(jì)表達(dá)出來）。

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

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

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

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

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

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

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

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

• 分布式服務(wù)組成的系統(tǒng)。
• 按照業(yè)務(wù)而不是技術(shù)來劃分組織。
• 做有生命的產(chǎn)品而不是項(xiàng)目。
• 去中心化。
• 自動(dòng)化運(yùn)維（DevOps）。
• 容錯(cuò)。
• 快速演化。

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