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

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

• 用戶行為的變化：業(yè)務(wù)應(yīng)用的用戶訪問不可預(yù)估，突發(fā)性訪問增多，存在臨時熱點事件或大促期間等不可控業(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īng)，不同團(tuán)隊特別是外包團(tuán)隊使用不同的技術(shù)棧，無法統(tǒng)一管控。

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

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

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

微服務(wù)架構(gòu)怎么選？

Dubbo

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

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

Spring Cloud

Spring Cloud是基于Spring Boot的一整套實現(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)上比較熱門的實現(xiàn)方案，能夠和K8s深度結(jié)合，更快速、更便捷地實現(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過渡；但也正是因為技術(shù)比較新，企業(yè)自研需要一定的學(xué)習(xí)成本，打破傳統(tǒng)IT運維/開發(fā)壁壘，考慮引入專業(yè)的技術(shù)廠商則能夠完美地解決這一問題。

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

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

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

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

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

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

以上為當(dāng)前常見的微服務(wù)架構(gòu)，那么企業(yè)實際改造時應(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è)計？

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

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

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

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

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

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

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

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

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

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

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

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