簡介： 2021年7月2日，阿里云用戶組（AUG）第一次線下活動在濟南召開。阿里云云原生資深專家李國強結(jié)合自身微服務(wù)領(lǐng)域經(jīng)驗，現(xiàn)場跟數(shù)十家山東企業(yè)分享了云原生的代表技術(shù)之一“微服務(wù)”的演進和應(yīng)用實踐。本文根據(jù)作者的現(xiàn)場演講整理而成。

2021年7月2日，阿里云用戶組（AUG）第一次線下活動在濟南召開。阿里云云原生資深專家李國強結(jié)合自身微服務(wù)領(lǐng)域經(jīng)驗，現(xiàn)場跟數(shù)十家山東企業(yè)分享了云原生的代表技術(shù)之一“微服務(wù)”的演進和應(yīng)用實踐。本文根據(jù)作者的現(xiàn)場演講整理而成。

背景

在企業(yè)內(nèi)部分為運維或開發(fā)，但最終所有做的事情都是為了解決業(yè)務(wù)的問題。如果你做一件事情，只有技術(shù)目標而沒有業(yè)務(wù)目標，失敗是很常見的。

什么樣的業(yè)務(wù)訴求會驅(qū)動一個企業(yè)去考慮微服務(wù)呢？

隨著架構(gòu)的演進，當你的業(yè)務(wù)越來越復(fù)雜，組件越來越多，對于每個業(yè)務(wù)組件的獨立性要求或者技術(shù)棧的異構(gòu)成本越來越高的時候，就會需要去考慮微服務(wù)。換言之，如果這個業(yè)務(wù)是一個比較平穩(wěn)、沒有什么大的挑戰(zhàn)，其實不需要去做微服務(wù)的改造。

各企業(yè)需要結(jié)合自己的業(yè)務(wù)去進行分析是否真的需求微服務(wù)。很多企業(yè)可能為了溝通，或者架構(gòu)師、CTO有自己的訴求，想要這個技術(shù)領(lǐng)先去做微服務(wù)，最終慘淡收場，其實這種案例是非常多的。微服務(wù)的適用性一定是從一個業(yè)務(wù)驅(qū)動的這個角度考慮的，需要考慮的是業(yè)務(wù)的復(fù)雜程度。

比較單體和微服務(wù)之間的一個區(qū)別，什么情況下需要它，和復(fù)雜程度是非常相關(guān)的。當你的一個業(yè)務(wù)的復(fù)雜程度比較低，處于單體時代的時候，前端后端數(shù)據(jù)庫都是一體的，需要進行變更時，一個數(shù)據(jù)包上去，所有的這個業(yè)務(wù)都上去了。并且，當你的業(yè)務(wù)足夠簡單的時候，單體效率一定是最高的。

業(yè)務(wù)不斷往前演進，復(fù)雜度越來越高的時候，單方面的發(fā)布可能會影響到別人。比如我有一個數(shù)據(jù)包，里邊對應(yīng)一個模塊，在這個模塊上線的時候，需要去考慮別的模塊怎么上線。業(yè)務(wù)流量進行擴縮容的時候，需要對整個業(yè)務(wù)進行溝通，而不是對單個模塊進行溝通，你會發(fā)現(xiàn)資源浪費會很高。這個時候就會到一些拐點，不管是你的發(fā)版或者是你的資源利用率都會出現(xiàn)一些問題，生產(chǎn)效率開始降低。單體應(yīng)用架構(gòu)的效率出現(xiàn)的拐點就是客戶考慮是否需要微服務(wù)架構(gòu)的一個時間點。

微服務(wù)的應(yīng)用架構(gòu)

1、應(yīng)用架構(gòu)的演進歷程

微服務(wù)最早的時候其實還是單品為主。現(xiàn)在的微服務(wù)對主流的一些技術(shù)框架，像 Java 體系的四分之二的 Double 類，其他語言都沒有放置。但實際上其他語言都有非常多的微服務(wù)框架可以選擇，像 PDP 等都會有一些。

之前云棲大會做過一次統(tǒng)計，賬號體系在整個后端開發(fā)中的地位，50%的投票是 Java 后端開發(fā)。但現(xiàn)在企業(yè)越來越多元化，之前 Java 占統(tǒng)治的地位已經(jīng)發(fā)生了變化。規(guī)模略大的公司基本上都是多元體系，里面有很多種，不同業(yè)務(wù)線的訴求不一樣，可能有的業(yè)務(wù)線是 Java；有些業(yè)務(wù)偏前端框架，會用 PAP、PYTHON；還有就是企業(yè)的并購，也會帶來很多元的體系。

多元數(shù)據(jù)的解法就是用一個多種的維度方案或是用新的技術(shù)形式，再往后就是容器化，微服務(wù)帶來的很多問題是通過容器來解決的。包括微服務(wù)器，有些人可能直接放棄不用了。負責人看到 Double 這個體系，直接用 K8sS Service 去做它的這個運行的暴露單元，好處是和語言無關(guān)，什么樣的體系里面都可以是一個 K8s Service。但在用了微服務(wù)后暴露出來的問題會比較多，我們需要對這么多的業(yè)務(wù)組件進行治理。

K8s 本身是不強的，就是為了要進一步解決這個問題，引入了更多的網(wǎng)格技術(shù)。去年開始越來越多的企業(yè)開始做網(wǎng)格網(wǎng)絡(luò)，這里面就包括用 Service Mesh 這個服務(wù)網(wǎng)解決跨語言的調(diào)研和服務(wù)治理。還有一個更新的叫做 Dapr 的技術(shù)解決供應(yīng)鏈依賴問題。

可以發(fā)現(xiàn)，應(yīng)用架構(gòu)的演進是一個業(yè)務(wù)不斷地提出問題，然后產(chǎn)出新框架，新的框架又可能會引入新的問題，不斷推動著技術(shù)的運行過程。

阿里應(yīng)用架構(gòu)演進

整個阿里巴巴內(nèi)部是完全走過一遍上述流程的，因為業(yè)務(wù)的快速增長，對技術(shù)團隊也在不斷地進行挑戰(zhàn)。PHP 是世界上最好最早的語言，淘寶商城其實就是用的 PHP。但是后來業(yè)務(wù)發(fā)展，淘寶的體量越來越快后，不但不能夠支撐這個業(yè)務(wù)，PHP 本身的擴展能力也撐不住了。

2009 年，阿里先做了分布式業(yè)務(wù)。阿里正式地從單體變成了分布式業(yè)務(wù)，那時候體量已經(jīng)比較大，還沒有雙十一，但已經(jīng)促成了阿里內(nèi)部去做自己的分布式框架。除了會有分布式的服務(wù)框架，還有一些分布式的數(shù)據(jù)庫和分布式的相應(yīng)規(guī)定，在內(nèi)部稱為三輛馬車，這也是從單體變成分布式框架時，必須要解決的三件事。

到 2011 年時，阿里開始探索容器化，先做了 T4 項目，是對于容器化的技術(shù)實現(xiàn)，最后變成 Pouch 的容器化的實現(xiàn)，它也是符合容器標準的容器化的實現(xiàn)。這體現(xiàn)出針對微服務(wù)后帶來的運維挑戰(zhàn)，容器是一個非常好的解決方案。

再往后到 2013 年，整個 Oracle 包括小型機在阿里下線，全部變成自己的開源的技術(shù)棧。2015 年開始，阿里全面擁抱云原生技術(shù)，包括容器技術(shù)的對外開放等業(yè)務(wù)，整個體系逐步深化。2016 年到 2019 年間，阿里做了云原生上云，包含已經(jīng)全面擁抱的 K8s 體系，以及微服務(wù)的改造、治理等。

到現(xiàn)在這段時間，我們做的事情是圖上畫的最后一個階段：基于網(wǎng)格進一步對服務(wù)點的支持，多語言越來越常見。阿里有很多業(yè)務(wù)是從外部合并進來的，阿里原來的整套技術(shù)戰(zhàn)略全部都是 Java，對外部合并進來的用戶非常不友好，因為他們不可能全部配好重啟，不得不去適配 Java。所以，近來我們在做的事情就是基于網(wǎng)格的新一代微服務(wù)架構(gòu)做演進，會有一些技術(shù)讓微服務(wù)的框架本身對于多元的支持變得更好，包括治理也可以去解耦，這也是成本較高的一個原因。

2、Apache Dubbo 3.0

Dubbo 3.0 在 6 月底已經(jīng)發(fā)布了最新版，這其實是一個很坎坷的項目。2008 年的時候Dubbo 在內(nèi)部正式發(fā)布，2011 年正式開源。以前，Dubbo 和 HMPK 在阿里內(nèi)部都有，但阿里希望技術(shù)上是統(tǒng)一的，不希望有兩套技術(shù)，兩邊不互通。這是兩個技術(shù)棧，所以進行了一次 PK，Apache Dubbo 勝出，所以阿里內(nèi)部目前全是 Apache Dubbo。現(xiàn)在這也是國內(nèi)最火的 Apache 框架。中間有段時間，阿里內(nèi)部投入比較少。到 2017 年時，我們中間件團隊再次去做商業(yè)化，重啟整個 Dubbo 開源，才讓 Apache 從完整的一個項目到前幾天時完成了發(fā)布。

這個項目是非常活躍的，現(xiàn)在的貢獻和使用率都非常高。Dubbo 3.0 里其實做了很多事去擁抱最新的一些理念，比如對 Service Mesh 的支持，它的協(xié)議也和 GRP 做了更好的兼容，做了一系列全新的服務(wù)發(fā)現(xiàn)模式。現(xiàn)在國內(nèi)用得比較多的還是 2.7、2.6 的版本，3.0 發(fā)布之后，很多企業(yè)一旦用起來都比較喜歡。當時還沒發(fā)布時，社區(qū)里就有一個用戶在拿 3.0 開始測試了。

3、Spring Cloud Alibaba

另一個不得不夸獎的是 Cloud 體系，它和 Java 的微服務(wù)這兩個體系目前還是最流行的。Spring Cloud 體系的優(yōu)點是組件非常豐富。Dubbo 這兩年在從 IPC 框架往主流服務(wù)器去引擎，而 Spring Cloud 誕生之初就是要把微服務(wù)數(shù)據(jù)相關(guān)部門支持起來。

隨后，阿里巴巴做了 Spring Cloud Alibaba，阿里開源一系列的中間件，包括 Double 注冊中心、配置中心、限流交易規(guī)律以及事務(wù)，去幫助用戶解決剛才講到的微服體系中各種各樣的問題。

微服務(wù)是一整個體系，而不僅僅是簡單的調(diào)用框架。微服務(wù)在大家使用的落地過程中碰到的問題，阿里非常重視。它把其中一些重要的點進行開源，同時通過與阿里云結(jié)合做 SDK 的分裝，把這兩部分合在一起。主要目的之一是幫助用戶去使用 Spring Cloud 體系，另一個目的是幫助用戶在阿里云上更好地運行 Spring Cloud。所以，這是阿里巴巴的 Cloud。

大部分的用戶知道的 Nacos、Sentinel 等中間件，實際上和云的一些產(chǎn)品間有非常好的基礎(chǔ)。我們也會和其他公司去聯(lián)合開發(fā)，不斷地演進項目。因為在阿里，我們會認為開源和商業(yè)化是同樣重要的，一個團隊既需要承擔開源項目，也需要承擔商業(yè)化的服務(wù)。

微服務(wù)不是免費的午餐

1、微服務(wù)會帶來復(fù)雜度的提升

微服務(wù)不是免費的，它會帶來很大的復(fù)雜度提升，包括服務(wù)框架的選型、注冊中心的穩(wěn)定性等。當一個客戶足夠大的時候，他會面臨一個很大的問題，就是注冊中心的穩(wěn)定性可能會成為一個業(yè)務(wù)的瓶頸，包括應(yīng)用的監(jiān)控、統(tǒng)一的配置管理、任務(wù)調(diào)度等一系列的東西都會成微服務(wù)落地過程中需要考慮的問題。

在這個過程中，對整個企業(yè)挑戰(zhàn)還是比較大的，不是每個企業(yè)都有能力去把整個微服務(wù)的開發(fā)組件全部自己運維起來。這一大堆組件如果全部靠自己運維起來，要求還是比較高的。所以，在里面更多地是希望企業(yè)更關(guān)注業(yè)務(wù)的一些相對偏運維的事情，云廠商才可能通過用其他方式進行解決，或者是如果企業(yè)足夠強大，也可以去通過開源自建的方式去解決。

2、軟件架構(gòu)訴求與基礎(chǔ)設(shè)施能力間存在“步調(diào)差 ”

剛才講到 Spring Cloud、 Dubbo 挺好用，但實際上也存在問題，即 SDK 的升級會變得非常困難，因為這個升級對業(yè)務(wù)沒有任何價值，業(yè)務(wù)方不愿意去配合。很多時候都是系統(tǒng)來說 2.6 有 bug，需要升一下 2.7 版本。這個時候就需要推動業(yè)務(wù)方去做，因為他把 SDK 引用進去了，引了之后如果有 bug 或者做一個增強，都需要在 SDK 做，這時業(yè)務(wù)方往往是不愿意的。在阿里內(nèi)部這個問題也同樣存在。

實際上這涉及到一個比較大的話題，即業(yè)務(wù)開發(fā)人員和基礎(chǔ)設(shè)施的運維人員的邊界在哪。SDK 這件事情到底屬于業(yè)務(wù)人員還是屬于基礎(chǔ)知識，這個問題問起來很抽象，是大家的一個責任邊界的問題。業(yè)務(wù)開發(fā)人員認為 SDK 是運維測試的，因為我只要接口，剩下更新、治理、工程上和業(yè)務(wù)開發(fā)沒關(guān)系。運維人員又不得不讓研發(fā)人員去配合業(yè)務(wù)研發(fā)，這是模糊的邊界，必然會發(fā)生沖突。

所以從云的角度或從計算的角度出發(fā)，我們在探討所謂的軟件架構(gòu)速度和基礎(chǔ)設(shè)施能力豐富度的問題時，能不能把業(yè)務(wù)和完成業(yè)務(wù)沒有那么相關(guān)的所有能力都下降到基礎(chǔ)設(shè)施的運維團隊，這是一直在思考的一個問題。在演練中經(jīng)歷過幾代：

• 第一代是云計算。它把基礎(chǔ)設(shè)施的這個東西從業(yè)務(wù)側(cè)翻下來，業(yè)務(wù)人員就不需要再去關(guān)心基礎(chǔ)資源。

• 第二個是容器和推廣安全。運維這件事情變得更簡單后，開發(fā)人員就不會關(guān)心這一層了，但是 SDK 侵入這件事對于業(yè)務(wù)開發(fā)員來講，就是一個侵略。

• 剝離的問題也是在 Service Mesh 這個技術(shù)上來做的。它把所有運行態(tài)的治理能力、流量管理能力全部從用戶側(cè)、開發(fā)測的 SDK 過濾出來，而不再需要去做 SDK 的生產(chǎn)。這個也就意味著用了 Service Mesh 之后，用戶是不需要做語言綁定，也就解決了剛才說的那個模糊地帶很難解決的問題。這個可能對于現(xiàn)在在用 Spring Cloud 的企業(yè)都可以考慮，這個東西會不會成為替代掉現(xiàn)在任何一個單語言的微服務(wù)框架技術(shù)。

• 再往后講其實還有一種依賴。比如當你需要一個中間件時，你一定要去做選型，這需要業(yè)務(wù)開發(fā)人員的配合。單獨的一個理念就是我能讓你把這個中間件下沉到基礎(chǔ)設(shè)施。到這時所有的業(yè)務(wù)開發(fā)人員真的只需要關(guān)心業(yè)務(wù)代碼，所有的這些基礎(chǔ)設(shè)施就全部下載下來，是不斷地去讓基礎(chǔ)設(shè)施能力更加豐富，來滿足上層業(yè)務(wù)這樣一個自主發(fā)展趨勢。

3、Service Mesh的剝離了服務(wù)和流量治理能力

Service Mesh 就是服務(wù)治理、流量治理框架。在原有的設(shè)計里，它屬于業(yè)務(wù)的一部分，上面是業(yè)務(wù)代碼，下面是這些能力。Service Mesh 能做的最重要的一件事，就是把這些能力剝離到 Istio 里來，業(yè)務(wù)帶中就是純業(yè)務(wù)功能，邊界很清晰，服務(wù)治理、流量治理框架由運維團隊來服務(wù)。

上層所有的語言和下層所有的基礎(chǔ)設(shè)施，通過一層層統(tǒng)一的接口進行抽象。不管用 Rock MQ 還是 Rabbit MQ，對上層業(yè)務(wù)是無感的，它會給上層業(yè)務(wù)一個統(tǒng)一抽象的 API ，而且是 HTTP 或者 gRPC 這樣的一個企業(yè)的 API 。開發(fā)人員不再關(guān)心底下到底是什么，進一步地讓開發(fā)人員和下面進行解耦。

目標理想架構(gòu)

最后真正理想的框架是什么樣的呢？開發(fā)人員和業(yè)務(wù)人員邊界到底在哪呢？我們畫了一個理想的框架。

• 對上層來講的話，我們會期望不同的業(yè)務(wù)單元可以選擇不同的語言和框架。比如說有的是單體，有的是 Spring Cloud 或者 Dubbo，從調(diào)用層面來講，完全是互通的，可以接入 Service Mesh 的技術(shù)，或者現(xiàn)有的這個框架
• 對于中間的容器服務(wù)，會讓業(yè)務(wù)不再感知具體的中間件。
• 再往下是容器服務(wù)，作為整個位置的一個支撐。
• 右邊是它的支撐體系，如微服務(wù)會帶來一些復(fù)雜性，需要通過可觀測性監(jiān)控你的 Devops 的流程 CICD 或者安全性支撐。

這時候就可以讓你的業(yè)務(wù)開發(fā)人員用他喜歡的語言去開發(fā)他想的業(yè)務(wù)，而不再關(guān)心這些所有的基礎(chǔ)設(shè)施團隊需要去解決的問題，這其實也是從應(yīng)用框架或微服務(wù)上來講的最終目標。

微服務(wù)化實踐案例

1、微服務(wù)引擎（MSE）

我們?nèi)プ鑫⒎?wù)時會碰到一些問題，有一種解決方式是進行全國自建，這對于一些企業(yè)來說工作量比較大。阿里云會把其中一些共性的東西變成產(chǎn)品來提供。比如說你去搭建一個微服務(wù)，你需要配置功能、網(wǎng)關(guān)、治理能力，阿里云會用一個產(chǎn)品的形態(tài)直接給到你，不用自己建了。就好像我原來是自建的，現(xiàn)在是影響他啟動的數(shù)據(jù)不一樣，那對于你原來是自建的 Nacos，現(xiàn)在就是一個云產(chǎn)品的提供。

2、暢捷通

另外有一個案例，暢捷通是用友的一個全資子公司，這個客戶專門做小微企業(yè)的財務(wù)系統(tǒng)。它全面上到阿里云，把自己的財務(wù)系統(tǒng)全部變成 SaaS 化的模式交付。大家都知道傳統(tǒng)的財務(wù)系統(tǒng) ERP 等都是偏單體的架構(gòu)，暢捷通的整個財務(wù)系統(tǒng)也經(jīng)歷了從虛機到 K8s 的轉(zhuǎn)變。一開始，是從虛機跑了微服務(wù)，后來從虛機轉(zhuǎn)到了 K8s。整體來看，在云上的規(guī)模非常大，也服務(wù)了非常多的客戶。

從容器化到微服務(wù)這樣一個過程，它基本上也是這個難題，希望提升系統(tǒng)微服務(wù)治理能力和監(jiān)控能力，在新業(yè)務(wù)快速上線、頻繁的版本迭代中確保系統(tǒng)的穩(wěn)定健壯。它一開始用了阿里云的一些項目，后來想把它變成 Spring Cloud，現(xiàn)在是兩個結(jié)合在一起使用。

3、阿里云服務(wù)網(wǎng)格ASM

服務(wù)網(wǎng)格這個產(chǎn)品技術(shù)大概是在去年發(fā)布用于生產(chǎn)，但實際上真正在生產(chǎn)上落地的企業(yè)還在不斷地去嘗試。阿里云也一樣，通過一個產(chǎn)品去降低用戶使用 Service Mesh，因為 Mesh 這件事情對于很多企業(yè)來講只是個技術(shù)概念，企業(yè)要的是一種多元微服務(wù)的能力，而 ASM 服務(wù)網(wǎng)的產(chǎn)品會幫助用戶去做服務(wù)網(wǎng)的一個落地。

4、商米科技通過 Service Mesh 完成微服務(wù)化

上海的商品科技是做各種物聯(lián)網(wǎng)設(shè)備的，它碰到的問題是內(nèi)部技術(shù)框架和語言體系比較復(fù)雜，各種各樣的語言和服務(wù)都遇到了困難。它希望對這些業(yè)務(wù)能夠進行一個統(tǒng)一的流量管理，包括發(fā)布時的流量管理，所以它最終選擇用 Service Mesh 這個技術(shù)去解決多元微服務(wù)。從這些業(yè)務(wù)價值的數(shù)據(jù)可以看出，比如更新迭代、異常排查、控制面資源成本都有了較大的優(yōu)化。

以上就是關(guān)于微服務(wù)的演進和實踐分享，希望有帶給大家一些微服務(wù)的體系的梳理。

原文鏈接：https://developer.aliyun.com/article/793251?

版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔相應(yīng)法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的一文看懂微服务背后的技术演进与应用实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。