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 這個技術去解決多元微服務。從這些業務價值的資料可以看出，比如更新疊代、異常排查、控制面資源成本都有了較大的優化。
以上就是關于微服務的演進和實踐分享，希望有帶給大家一些微服務的體系的梳理。