作者：李豔林
本文整理自阿里雲微服務負責人李豔林在 2023 雲棲《下一代軟件架構，如何構建微服務核心能力》的分享。
隨着數字化進程的加速，各種架構設計思想風起雲湧，進入百家爭鳴時代，微服務架構，雲原生架構，Serverless 架構，事件驅動架構，中臺架構，容災架構，到底哪種思潮代表未來呢？
架構趨勢
未來的架構趨勢是什麼呢？爲什麼說微服務架構是下一代軟件架構呢？
主流架構趨勢
每一種架構都有時代的挑戰和選擇，沒有最好的架構，只有更適合的架構。
WEB 1.0 時代，更多的是信息的呈現，系統相對簡單，早期一般購買物理機，採用經典的 LAMP 單體架構快速構建一個網站，業務複雜可以採用 MVP 思想進行分層化解。
WEB 2.0 時代，交互複雜，互聯網/移動互聯網蓬勃發展，互聯網充斥着快魚喫慢魚的故事，因此化解複雜系統的快速迭代的架構就是下一代架構。在基礎設施這層採用雲計算底座能夠快速交付資源，採用微服務架構充分提升研發效率，解決複雜系統的研發效率問題；採用中臺架構，解決複雜系統重複建設和基礎服務能力沉澱問題。
隨着線上、線下的加速融合，穩定性要求越來越高，因此高可用成爲每家企業必須重視的話題。如果在雲上，雲廠商會解決容災問題，如果自建 IDC，可以採用混合雲架構解決基礎設施容災問題；在應用架構層面，同城多活是解決應用容災的通用方案；在業務架構層面，異地多活是解決業務容災的最佳實踐。
隨着數字化加深，整個時代架構會逐漸右移動，可見微服務會是下一代軟件架構，會逐漸成爲時代的主角。
雲原生微服務
微服務架構在釋放研發效率同時導致運維成本上升，但是 K8s 徹底解決了運維問題，讓微服務邁過技術成熟度拐點，並且隨着雲原生架構加速演進，充分釋放雲的紅利。
微服務價值凸顯
下圖是展示單體和微服務架構選型的圖，橫座標代表系統複雜度，縱座標代表效率，綠色曲線代表單體應用，藍色曲線代表微服務；當系統複雜度（超過 10 個子系統或者人員）上升，採用微服務架構會比單體架構效率更高。
隨着 WEB 2.0 加速滲透，系統能力和複雜度逐漸上升，越來越多的企業達到這個拐點；再伴隨着開源和雲計算的推進，微服務成本從百萬級下降到千級，使用門檻大幅降低，導致拐點左移，目前市場上能看到，3 個子系統就開始採用微服務架構；隨着算力成本的不斷下降，人力成本的不斷上升，採用微服務架構的公司投入產出比會越來越高，加速企業創新和迭代速度。
微服務行業趨勢
微服務市場每年保持 18% 以上增長，可見其爆發力之強；Gartner 報告顯示，微服務進入穩步爬升初期，這意味着技術成熟、標準，加速滲透各行各業；CSDN 開發者報告則顯示，58% 用戶關注微服務架構，可見開發者將大規模越遷到微服務時代。
微服務挑戰 & 解法
雖然大家都知道微服務是下一代架構，但是對微服務的實施難點有所忌憚，對解法是否優雅有所懷疑，下面我將詳細介紹一下我們的思考。
微服務主要挑戰
從單體演進到微服務後，會大幅提升業務研發效率，但是也會帶來架構的複雜性，開發需要先解決 RPC 調用複雜問題，發佈解決變更有損可用性問題，出故障需要解決登陸很多機器解決纔可定位的問題，面對黑客需要解決安全問題。這就是微服務核心的四個挑戰，下面我們將逐步分享我們的解法。
微服務框架挑戰
微服務框架核心要解決的是，如何像單體一樣開發微服務應用，屏蔽分佈式系統複雜度和多語言差異。2011 年阿里開源 Dubbo 框架，由於簡單易用的優勢快速成爲國內首選，但是存在着序列化協議語言相關性高，多語言發展緩慢，重 SDK 模式、升級困難等問題。
爲了解決重 SDK 問題，我們引入了 Agent 的技術（Java 字節碼增強），儘可能把複雜的治理功能下沉到 Agent 中，大幅緩解 SDK 生命週期管理問題，但是依然沒有解決多語言問題。
爲了解決多語言問題，有兩個基本思路，一個是通過 Sidecar 技術，在網絡層通用解決一些流量治理問題，但這個思路會引入一個新的依賴，增加複雜度；另外一個思路是發展利於多語言實現的序列化協議，目前主要有 Http + Json 和 gRPC（基於 HTTP2.0）+ PB 兩個路徑。
我們基於第一性原理判斷，最終 RPC 調用類似 HTTP 調用，不應該引入一個 Sidecar 的複雜度，應該按照標準化和輕量化方向演進，因此我們 Dubbo 3.0 推出了 Triple 協議（基於 HTTP / gRPC），解決多語言問題，數據面控制面分離，客戶端輕量化。
微服務框架解法
微服務框架主要由三個部分組成，API 層，協議層，治理層；API 層主要解決簡單好用問題，Dubbo 的 API 非常適合 Java 開發者，但是早期參照 Java 寫的 Golang 版本不適合 Golang 開發者習慣，因此我們推出更適合 Golang 語言的微服務編程 API，並配套升級了官網、文檔、示例、腳手架，不斷降低複雜度；協議層推出 Triple 協議，解決跨語言調用問題，支持 OT 利於多語言鏈路追蹤；服務治理代碼佔 Dubbo 一半左右代碼，多語言實現難度大，因此我們做了數據面和控制面抽象，將 SDK 輕量化，支持部分治理下沉 Sidecar，方便多語言實現。
微服務可用性挑戰
實踐數據表明，系統變更會引入 70% 風險。如採用微服務後第一個遇到的是發佈流量損失，核心原因是節點下線通過註冊中心通知下游有延遲，上有系統不能及時摘除下線節點，導致調用異常；由於應用多，變更時間不同，依賴複雜，會導致變更產生的風險變多。
運行態會引入 10% 左右風險，比例雖小但是風險極大，這類風險主要有三類，一類是被上游系統突發流量和攻擊壓死，一類是被下游不靠譜依賴拖垮，一類是被運行機器抖動拖死；
因此微服務的可用性挑戰，主要解決這些問題。
微服務可用性解法
面對變更態最多的風險，我們核心的思路是可灰度、可觀測、可回滾； 通過灰度縮小爆炸半徑，觀測快速識別問題，回滾來快速解決問題；其中灰度技術要求最高，主要是因爲兩個原因，一個涉及全鏈路應用多、規則複雜。阿里內部全產品改造（Dubbo+Nacos/ RocketMQ / 任務調度 / 可觀測）所有核心業務升級，消耗大、時間久，不通用，因此我們後來推出 Agent 解決方案，無侵入解決服務治理的問題。
Dubbo 早期預置了一些治理規則 + Groovy 擴展機制，治理規則變化多總得升級，Groovy 不利於多語言實現且不好管控。因此需要在靈活性和複雜性之間做一個平衡，最後我們根據主流流量控制場景將配置模版化，數據面和控制面分離，來解決該問題。
微服務觀測挑戰
由於微服務系統業務複雜，依賴複雜，鏈路複雜，導致排查問題增大，尤其涉及多層調用問題排查。如果登陸到一臺臺機器查日誌，這個簡直是一個噩夢。
微服務觀測解法
微服務觀測目前方法論比較充分，通過 Metrics 定性大概是業務問題還是中間件問題，通過 Tracing 定量分析是哪個應用問題，通過 Logging 定位具體根因。OT 標準的出現，加速了技術迭代，解決複雜鏈路問題，大幅提升分析診斷效率。
微服務安全挑戰
爲了快速落地微服務，很多公司一個應用掛一個公網 SLB 來發布服務，這樣安全攻擊面非常大，也增加了管理證書負擔，應用內部都有自己的敏感數據，一不小心可能造成致命損失。
微服務安全解法
安全最好的做法就是統一入口，在入口建立安全防線，把風險拒之門外，把敏感數據存放到配置中心加密存儲，代碼、密文和密鑰分別存儲，杜絕核心數據泄漏。
微服務演進 & 實踐
上面詳細介紹了微服務當前的挑戰和解法，那面對未來微服務將如何演進，有哪些實踐呢？
微服務演進
未來微服務會沿着易用、標準化、語言無關、可擴展、可持續架構演進； 微服務框架解決易用性和多語言問題，控制面解決標準化和可擴展問題，可持續架構是從小到大可以持續演進，而不是第一天就搞一個巨複雜架構。小的時候可以 Dubbo+Nacos 快速開始，遇到安全問題上雲原生網關 Higress，遇到穩定性問題上服務治理，遇到一致性問題引入 Seata（啓動貢獻 Apache 社區），一步步持續生長。
微服務框架演進
對於 OPS 同學，掌握 K8s + Terraform 就可以高效的運維；面對開發者，我們通過 Spring-Cloud-Alibaba 幫助開發者解決微服務開發效率問題。未來，我們將擴大範圍，做開發者和阿里雲的鏈接，通過 Spring 註解快速使用阿里雲主流雲產品，大幅提升開發者效率。
服務治理演進
Istio 體系主要解決流量治理問題，抽象度高但是複雜，然而對於微服務，我們更多需要的是服務治理，因此我們會通過 OpenSerGo 來推動服務治理的規範和標準制定，簡化服務治理使用門檻。
網關演進
WEB 1.0 主要採用 SLB / ALB + ECS + 單體架構，支撐簡單的信息系統。
WEB 2.0 主要採用雲原生網關 + 容器 + 微服務架構，支撐複雜交互系統；從單體到微服務，SLB / 微服務網關彼此不能互通，從微服務到 ACK，微服務網關和 Ingress 網關彼此不能互通，導致在架構演進中會出現流量網關、微服務網關、安全網關多層疊羅漢現象，帶來運維和部署複雜度提升。因此，我們推出雲原生網關 Higress，將三層網關合一，基於 Ingress 標準整合微服務和安全網關能力，提供服務治理差異化競爭力，相比 Nginx 生態網關，Higress 採用 Envoy 內核，從規則、路由、證書、插件實現全部熱更新，避免鏈接抖動帶來的用戶中斷和體驗下降。
未來雲計算髮展有兩個主導力量，一個是 Serverless，把算力發揮到極致；一個是 AI，把數據挖掘到極致。
面對 Serverless 時代，網關需要突破自適應能力（流量來後端服務沒有拉起 Hold 流量，後端服務拉齊轉發下去），目前 MSE Higress + ASK / SAE 已經全部跑通，阿里雲 FC / SAE 會內置 Higress。
面對 AI 時代，網關需要雙向流傳輸性能和鏈接穩定性有很高要求，協議上需要支持 SSE/WebSocket 等雙向流協議，需要熱更新能力保證鏈接穩定，目前通義系列和 PAI 等開始集成 Higress。
微服務企業級實踐
阿里微服務體系通過 10+ 年的雙十一洪峯考驗，以及雲上成千上萬家企業的打磨，構建了默認安全、默認高可用的差異化競爭力。今年 MSE 4.0 全面 Serverless 化，推出了行業首個雲原生網關/註冊配置中心 Serverless 版本，從低運維到免運維，無需關心容量，無需關心版本升級，按量付費低於自建成本，真正做到像水電一樣使用微服務。
微服務高可用實踐
我們根據雙十一壓測場景，簡單介紹一下微服務高可用體系。首先，我們通過 PTS 模擬客戶壓測，在 MSE 雲原生網關入口做路由級流量防護，在應用側通過服務治理做服務級流量防護，通過 ARMS 做全鏈路觀測，通過指標驅動容器彈性伸縮，從而輕鬆應對流量洪峯。
微服務容災實踐
解決完單集羣高可用問題，我們需要解決多 AZ 容災問題，進一步提升微服務高可用體系。下面有兩個可用區，每個可用區有一個 K8s 集羣，通過 ACK One 輕鬆管理兩個集羣。面對入口流量我們有兩個選擇，一個選擇是一個網關集羣，聚合兩個 K8s 服務，可以通過網關靈活切換不同可用區容量；一個是選擇兩個網關集羣，通過上層 DNS 切換流量，這樣架構簡單，但是切流實時性無法保障。
微服務 Serverless 實踐
如果我們真的想像用水電一樣使用雲服務，未來 Serverless 一定是關鍵方向，讓用戶能夠聚焦業務開發，讓雲逐漸帶大家走到自動擋，自動駕駛時代。目前在雲上可以通過 SAE + MSE 體驗 Serverless 的優勢，加速推進 Serverless 進程，進一步釋放雲計算紅利。
