一文看懂微服務背後的技術演進與應用實踐

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

背景

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

什麼樣的業務訴求會驅動一個企業去考慮微服務呢？

隨著架構的演進，當你的業務越來越複雜，元件越來越多，對於每個業務元件的獨立性要求或者技術棧的異構成本越來越高的時候，就會需要去考慮微服務。換言之，如果這個業務是一個比較平穩、沒有什麼大的挑戰，其實不需要去做微服務的改造。

各企業需要結合自己的業務去進行分析是否真的需求微服務。

很多企業可能為了溝通，或者架構師、CTO有自己的訴求，想要這個技術領先去做微服務，最終慘淡收場，其實這種案例是非常多的。微服務的適用性一定是從一個業務驅動的這個角度考慮的，需要考慮的是業務的複雜程度。

比較單體和微服務之間的一個區別，什麼情況下需要它，和複雜程度是非常相關的。當你的一個業務的複雜程度比較低，處於單體時代的時候，前端後端資料庫都是一體的，需要進行變更時，一個數據包上去，所有的這個業務都上去了。並且，當你的業務足夠簡單的時候，單體效率一定是最高的。

業務不斷往前演進，複雜度越來越高的時候，單方面的釋出可能會影響到別人。比如我有一個數據包，裡邊對應一個模組，在這個模組上線的時候，需要去考慮別的模組怎麼上線。業務流量進行擴縮容的時候，需要對整個業務進行溝通，而不是對單個模組進行溝通，你會發現資源浪費會很高。這個時候就會到一些拐點，不管是你的發版或者是你的資源利用率都會出現一些問題，生產效率開始降低。單體應用架構的效率出現的拐點就是客戶考慮是否需要微服務架構的一個時間點。

微服務的應用架構

1、應用架構的演進歷程

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

之前雲棲大會做過一次統計，賬號體系在整個後端開發中的地位，50%的投票是 Java 後端開發。但現在企業越來越多元化，之前 Java 佔統治的地位已經發生了變化。規模略大的公司基本上都是多元體系，裡面有很多種，不同業務線的訴求不一樣，可能有的業務線是 Java；有些業務偏前端框架，會用 PAP、PYTHON；還有就是企業的併購，也會帶來很多元的體系。

多元資料的解法就是用一個多種的維度方案或是用新的技術形式，再往後就是容器化，微服務帶來的很多問題是透過容器來解決的。包括微伺服器，有些人可能直接放棄不用了。負責人看到 Double 這個體系，直接用 K8sS Service 去做它的這個執行的暴露單元，好處是和語言無關，什麼樣的體系裡面都可以是一個 K8s Service。但在用了微服務後暴露出來的問題會比較多，我們需要對這麼多的業務元件進行治理。

K8s 本身是不強的，就是為了要進一步解決這個問題，引入了更多的網格技術。去年開始越來越多的企業開始做網格網路，這裡面就包括用 Service Mesh 這個服務網解決跨語言的調研和服務治理。還有一個更新的叫做 Dapr 的技術解決供應鏈依賴問題。

可以發現，應用架構的演進是一個業務不斷地提出問題，然後產出新框架，新的框架又可能會引入新的問題，不斷推動著技術的執行過程。

阿里應用架構演進

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

2009 年，阿里先做了分散式業務。阿里正式地從單體變成了分散式業務，那時候體量已經比較大，還沒有雙十一，但已經促成了阿里內部去做自己的分散式框架。除了會有分散式的服務框架，還有一些分散式的資料庫和分散式的相應規定，在內部稱為三輛馬車，這也是從單體變成分散式框架時，必須要解決的三件事。

到 2011 年時，阿里開始探索容器化，先做了 T4 專案，是對於容器化的技術實現，最後變成 Pouch 的容器化的實現，它也是符合容器標準的容器化的實現。這體現出針對微服務後帶來的運維挑戰，容器是一個非常好的解決方案。

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

到現在這段時間，我們做的事情是圖上畫的最後一個階段：基於網格進一步對服務點的支援，多語言越來越常見。阿里有很多業務是從外部合併進來的，阿里原來的整套技術戰略全部都是 Java，對外部合併進來的使用者非常不友好，因為他們不可能全部配好重啟，不得不去適配 Java。所以，近來我們在做的事情就是基於網格的新一代微服務架構做演進，會有一些技術讓微服務的框架本身對於多元的支援變得更好，包括治理也可以去解耦，這也是成本較高的一個原因。

2、Apache Dubbo 3。0

Dubbo 3。0 在 6 月底已經發布了最新版，這其實是一個很坎坷的專案。2008 年的時候Dubbo 在內部正式釋出，2011 年正式開源。以前，Dubbo 和 HMPK 在阿里內部都有，但阿里希望技術上是統一的，不希望有兩套技術，兩邊不互通。這是兩個技術棧，所以進行了一次 PK，Apache Dubbo 勝出，所以阿里內部目前全是 Apache Dubbo。現在這也是國內最火的 Apache 框架。中間有段時間，阿里內部投入比較少。到 2017 年時，我們中介軟體團隊再次去做商業化，重啟整個 Dubbo 開源，才讓 Apache 從完整的一個專案到前幾天時完成了釋出。

這個專案是非常活躍的，現在的貢獻和使用率都非常高。Dubbo 3。0 裡其實做了很多事去擁抱最新的一些理念，比如對 Service Mesh 的支援，它的協議也和 GRP 做了更好的相容，做了一系列全新的服務發現模式。現在國內用得比較多的還是 2。7、2。6 的版本，3。0 釋出之後，很多企業一旦用起來都比較喜歡。當時還沒釋出時，社群裡就有一個使用者在拿 3。0 開始測試了。

3、Spring Cloud Alibaba

另一個不得不誇獎的是 Cloud 體系，它和 Java 的微服務這兩個體系目前還是最流行的。Spring Cloud 體系的優點是元件非常豐富。Dubbo 這兩年在從 IPC 框架往主流伺服器去引擎，而 Spring Cloud 誕生之初就是要把微服務資料相關部門支援起來。

隨後，阿里巴巴做了 Spring Cloud Alibaba，阿里開源一系列的中介軟體，包括 Double 註冊中心、配置中心、限流交易規律以及事務，去幫助使用者解決剛才講到的微服體系中各種各樣的問題。

微服務是一整個體系，而不僅僅是簡單的呼叫框架。微服務在大家使用的落地過程中碰到的問題，阿里非常重視。它把其中一些重要的點進行開源，同時透過與阿里雲結合做 SDK 的分裝，把這兩部分合在一起。主要目的之一是幫助使用者去使用 Spring Cloud 體系，另一個目的是幫助使用者在阿里雲上更好地執行 Spring Cloud。所以，這是阿里巴巴的 Cloud。

大部分的使用者知道的 Nacos、Sentinel 等中介軟體，實際上和雲的一些產品間有非常好的基礎。我們也會和其他公司去聯合開發，不斷地演進專案。因為在阿里，我們會認為開源和商業化是同樣重要的，一個團隊既需要承擔開源專案，也需要承擔商業化的服務。

微服務不是免費的午餐

1、微服務會帶來複雜度的提升

微服務不是免費的，它會帶來很大的複雜度提升，包括服務框架的選型、註冊中心的穩定性等。當一個客戶足夠大的時候，他會面臨一個很大的問題，就是註冊中心的穩定性可能會成為一個業務的瓶頸，包括應用的監控、統一的配置管理、任務排程等一系列的東西都會成微服務落地過程中需要考慮的問題。

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

2、軟體架構訴求與基礎設施能力間存在“步調差 ”

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

實際上這涉及到一個比較大的話題，即業務開發人員和基礎設施的運維人員的邊界在哪。SDK 這件事情到底屬於業務人員還是屬於基礎知識，這個問題問起來很抽象，是大家的一個責任邊界的問題。業務開發人員認為 SDK 是運維測試的，因為我只要介面，剩下更新、治理、工程上和業務開發沒關係。運維人員又不得不讓研發人員去配合業務研發，這是模糊的邊界，必然會發生衝突。

所以從雲的角度或從計算的角度出發，我們在探討所謂的軟體架構速度和基礎設施能力豐富度的問題時，能不能把業務和完成業務沒有那麼相關的所有能力都下降到基礎設施的運維團隊，這是一直在思考的一個問題。在演練中經歷過幾代：

第一代是雲計算。它把基礎設施的這個東西從業務側翻下來，業務人員就不需要再去關心基礎資源。

第二個是容器和推廣安全。運維這件事情變得更簡單後，開發人員就不會關心這一層了，但是 SDK 侵入這件事對於業務開發員來講，就是一個侵略。

剝離的問題也是在 Service Mesh 這個技術上來做的。它把所有執行態的治理能力、流量管理能力全部從使用者側、開發測的 SDK 過濾出來，而不再需要去做 SDK 的生產。這個也就意味著用了 Service Mesh 之後，使用者是不需要做語言繫結，也就解決了剛才說的那個模糊地帶很難解決的問題。這個可能對於現在在用 Spring Cloud 的企業都可以考慮，這個東西會不會成為替代掉現在任何一個單語言的微服務框架技術。

再往後講其實還有一種依賴。比如當你需要一箇中間件時，你一定要去做選型，這需要業務開發人員的配合。單獨的一個理念就是我能讓你把這個中介軟體下沉到基礎設施。到這時所有的業務開發人員真的只需要關心業務程式碼，所有的這些基礎設施就全部下載下來，是不斷地去讓基礎設施能力更加豐富，來滿足上層業務這樣一個自主發展趨勢。

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

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

上層所有的語言和下層所有的基礎設施，透過一層層統一的介面進行抽象。不管用 Rock MQ 還是 Rabbit MQ，對上層業務是無感的，它會給上層業務一個統一抽象的 API ，而且是 HTTP 或者 gRPC 這樣的一個企業的 API 。開發人員不再關心底下到底是什麼，進一步地讓開發人員和下面進行解耦。

目標理想架構

最後真正理想的框架是什麼樣的呢？開發人員和業務人員邊界到底在哪呢？我們畫了一個理想的框架。

對上層來講的話，我們會期望不同的業務單元可以選擇不同的語言和框架。比如說有的是單體，有的是 Spring Cloud 或者 Dubbo，從呼叫層面來講，完全是互通的，可以接入 Service Mesh 的技術，或者現有的這個框架

對於中間的容器服務，會讓業務不再感知具體的中介軟體。

再往下是容器服務，作為整個位置的一個支撐。

右邊是它的支撐體系，如微服務會帶來一些複雜性，需要透過可觀測性監控你的 Devops 的流程 CICD 或者安全性支撐。

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

微服務化實踐案例

1、微服務引擎（MSE）

我們去做微服務時會碰到一些問題，有一種解決方式是進行全國自建，這對於一些企業來說工作量比較大。阿里雲會把其中一些共性的東西變成產品來提供。比如說你去搭建一個微服務，你需要配置功能、閘道器、治理能力，阿里雲會用一個產品的形態直接給到你，不用自己建了。就好像我原來是自建的，現在是影響他啟動的資料不一樣，那對於你原來是自建的 Nacos，現在就是一個雲產品的提供。

2、暢捷通

另外有一個案例，暢捷通是用友的一個全資子公司，這個客戶專門做小微企業的財務系統。它全面上到阿里雲，把自己的財務系統全部變成 SaaS 化的模式交付。大家都知道傳統的財務系統 ERP 等都是偏單體的架構，暢捷通的整個財務系統也經歷了從虛機到 K8s 的轉變。一開始，是從虛機跑了微服務，後來從虛機轉到了 K8s。整體來看，在雲上的規模非常大，也服務了非常多的客戶。

從容器化到微服務這樣一個過程，它基本上也是這個難題，希望提升系統微服務治理能力和監控能力，在新業務快速上線、頻繁的版本迭代中確保系統的穩定健壯。它一開始用了阿里雲的一些專案，後來想把它變成 Spring Cloud，現在是兩個結合在一起使用。

3、阿里雲服務網格ASM

服務網格這個產品技術大概是在去年釋出用於生產，但實際上真正在生產上落地的企業還在不斷地去嘗試。阿里雲也一樣，透過一個產品去降低使用者使用 Service Mesh，因為 Mesh 這件事情對於很多企業來講只是個技術概念，企業要的是一種多元微服務的能力，而 ASM 服務網的產品會幫助使用者去做服務網的一個落地。

4、商米科技透過 Service Mesh 完成微服務化

上海的商品科技是做各種物聯網裝置的，它碰到的問題是內部技術框架和語言體系比較複雜，各種各樣的語言和服務都遇到了困難。它希望對這些業務能夠進行一個統一的流量管理，包括髮布時的流量管理，所以它最終選擇用 Service Mesh 這個技術去解決多元微服務。從這些業務價值的資料可以看出，比如更新迭代、異常排查、控制面資源成本都有了較大的最佳化。

以上就是關於微服務的演進和實踐分享，希望有帶給大家一些微服務的體系的梳理。