「分布式系統前沿技術」專題 | 微服務架構何去何從?

分布式技術的發展，深刻地改變了我們編程的模式和思考軟體的模式。值 2019 歲末，PingCAP 聯合 InfoQ 共同策劃出品「分布式系統前沿技術 」專題， 邀請眾多技術團隊共同參與，一起探索這個古老領域的新生機。本文出自轉轉首席架構師孫玄。

微服務架構模式經過 5 年多的發展，在各行各業如火如荼地應用和實踐。如何在企業中優雅地設計微服務架構？是企業面對的一個重要問題。本文將講述微服務架構 1.0 設計與實踐以及面臨問題和破局，最後講述微服務架構 2.0 設計與實踐等方面，嘗試去回答這個難題。

2014 年馬丁福勒提出了微服務架構設計模式，微服務架構最核心的設計有二點（如圖 1 綠框所示）：第一，把單體服務拆分成一系列小服務；第二，拆分後的這些小服務是去中心化的，即每個服務都可以使用不同的程式語言，也可以使用不同的資料庫和緩存存儲數據。

圖 1 微服務架構模式

第一個問題是服務如何拆分的問題。架構拆分沒有新鮮事，即不同領域的架構設計在道（哲學）的層面都是相通的。

我們來思考一下公司資料庫集群遇到讀寫和存儲的性能問題時，是如何解決的？假如公司電商業務包含用戶、商品以及交易等數據，每種數據使用一張單獨的表存儲，這些數據放在一個資料庫（DB4Global）中。隨著請求量的增加和數據存儲量的增加，單獨的 DB4Global 資料庫會遇到性能瓶頸。為了解決資料庫的性能問題，需要對 DB4Global 庫拆分，首先對 DB4Global 庫按照業務領域進行垂直拆分，拆分為多個獨立的用戶庫（DB4User）、商品庫（DB4Info）、交易庫（DB4Trade）等；其次為了進一步提升資料庫的性能，再次根據功能對每個表進行水平方向的拆分，例如用戶表 10 億記錄，主鍵為用戶 UID。Partition Key 選擇為 UID，按照 UID % 128 水平拆分。

架構設計之道是相通的，微服務拆分同樣遵循業務領域的垂直拆分以及功能的水平拆分。繼續以電商業務為例，首先按照業務領域的垂直拆分，分為用戶微服務、商品微服務、搜索微服務、推薦微服務、交易微服務等。

繼續思考一個問題，在垂直方向僅僅按照業務領域進行拆分是否滿足所有的業務場景？答案是否定的。例如用戶服務分為用戶註冊（寫請求）和用戶登陸（讀請求）等。寫請求的重要性往往是大於讀請求，在網際網路大流量下，讀寫比例 10:1，甚至更高的情況下，大量的讀往往會直接影響寫。為了避免大量的讀對寫請求的幹擾，需要對服務進行讀寫分離，即用戶註冊為一個微服務，用戶登陸為一個微服務。此時按照 API 的細粒度繼續進行垂直方向的拆分。

在水平方向，按照請求的功能拆分，即對一個請求的生命周期繼續進行拆分。請求從用戶端發出，首先接受到請求的是網關服務，網關服務對請求進行請求鑑權、通用參數檢查、協議轉換以及路由轉發等。接下來業務邏輯服務對請求進行業務邏輯的編排處理（比如微信發送消息，需要進行好友關係檢查、對消息內容進行風控檢查、進行消息的存儲和推送等）。對業務數據進行存儲和查詢就需要數據訪問服務，數據訪問服務提供了基本的 CRUD 原子操作，並負責海量數據的 Sharding（分庫分表）以及屏蔽底層存儲的差異性等功能。最後是數據持久化和緩存服務，比如可以採用 NewSQL TiDB 以及 Redis Cluster 等。

通過以上的拆分，普適的微服務架構如圖 2 所示。

微服務架構通過業務垂直拆分以及水平的功能拆分，服務演化成更小的顆粒度，各服務之間相互解耦，每個服務都可以快速迭代和持續交付，從而在公司層面能夠達到降本增效的終極目標。但是服務粒度越細，服務之間的交互就會越來越多，更多的交互會使得服務之間的治理更複雜。服務之間的治理包括服務間的註冊、通信、路由、負載均衡、重試、限流、降級、熔斷、鏈路跟蹤等。

微服務架構技術選型，包括微服務本身的研發框架以及服務治理框架。目前研發框架主流的 RPC 有兩類：一種是 RPC Over TCP，典型代表是 Apache Dubbo；另外一種是 RPC Over HTTP，典型代表是 Spring Cloud。企業根據團隊的研發基因二者選一即可。在服務治理方面包含了服務註冊、服務配置、服務熔斷、服務監控等方面，服務註冊本質是 AP 的模型，可以選用 Nacos，服務配置可以選用 CTrip Apollo，服務熔斷可以選用 Netflix Hystrix 組件，服務監控可以選用 Open-Falcon 等配套框架。

在微服務架構 1.0 中每個服務包含了服務自身的功能設計以及服務治理的功能設計，他們耦合在一起，這些服務治理的功能和服務自身功能沒有關係，業務方也不需要關注。使得微服務 1.0 架構不再是銀彈，存在以下幾個方面的問題：

第一，每一個業務服務為了和其他業務服務交互，都必須關注和引入服務間服務治理組件，使得業務服務迭代速度變慢，如圖 3 所示。

第二，服務治理組件和服務自身功能耦合在一個進程內，使得服務治理組件的升級強依賴於業務服務自身，造成基礎設施研發團隊的交付能力和交付速度大大降低。如圖 4 所示，服務降級功能從 V1 升級到 V2，需要業務服務更換服務降級功能的組件，重新打包編譯和發布。

第三，前文提到馬丁福勒對微服務架構的期望是每個服務都可以使用業務團隊熟悉的語言來編寫，但是在服務自身和服務治理耦合在一起的情況下，每個語言都需要一套完整的服務治理組件，必然造成公司研發投入成本增大，ROI 不高。如圖 5 所示，Java 語言編寫的應用程式A和應用程式 C 交互，就需要一套完整的 Java 語言服務治理組件，同樣，世界上最好語言編寫的應用程式 B 和應用程式 C 交互，就需要一套完成的 PHP 語言服務治理組件。

那麼造成這些問題的本質原因在於服務自身功能和服務治理功能的物理耦合，把服務治理功能完全解耦出來，變成一個獨立的服務治理進程，從而以上三個問題得以徹底解決。

微服務架構 1.0 繼續演進，就變成了微服務架構 2.0，即 Service Mesh 架構（Service Mesh）。Servie Mesh 架構最早由開發 Linkerd 的 Buoyant 公司提出，並在內部使用。2016 年 09 月 29 日第一次公開使用，2017 年初進入國內技術社區視野。Service Mesh 到底是什麼？我們來看看 Linerd 公司 CEO Willian Morgan 對 Service Mesh 的定義如圖 6 所示：

Service Mesh 是一個基礎設施層，用於處理服務間交互。雲原生應用有著複雜的服務拓撲，Service Mesh 負責在這些拓撲中實現請求的可靠傳遞。在線上實踐中，Service Mesh 通常實現為一組輕量級的網絡代理（Sidecar 邊車），它們與應用程式部署在一起，並且對應用程式透明。

如圖 7 所示，應用程式 A 和應用程式 B 交互，請求調用關係如下：應用程式 A 調用本地的 Sidecar A，Sidecar A 在通過網絡交互調用遠端的 Sidecar B，再由 Sidecar B 把請求傳遞給應用程式 B。請求回應關係也是類似：應用程式 B 調用 Sidecar B，Sidecar B 在通過網絡交互調用遠端的 Sidecar A，再由 Sidecar A 把請求回應傳遞給應用程式 A。通過把服務治理功能從服務自身中物理剝離出來，下沉形成獨立的進程，從而物理解耦。
在這樣的架構模式下，業務應用程式再也不需要關注服務治理的功能，服務治理的功能升級也不要依賴於服務自身，從而能夠讓業務迭代更快速和高效。同時由於服務治理功能變成一個獨立的進程，只需要使用一種語言打造即可，業務服務自身可以選擇業務團隊擅長的語言進行編寫，從而能夠真正達到馬丁福勒對微服務的期望。我們再深入分析下協議，在通信協議方面，業務應用程式和 Sidecar 的通信可以基於 TCP 長連接，也可以基於 HTTP 1.0 或者 2.0 的長連接（思考下：是否一定要使用長連接？），Sidecar 間的通信協議沒有特殊要求；在數據傳輸協議方面，可以是 JSON／XML 等跨語言的文本協議，也可以選擇 Protobuffers／MessagePack 等跨語言的二進位協議。

保證了通信協議和數據傳輸協議的跨語言，不同語言的應用程式就可以無縫地和 Sidecar 進行交與。在應用程式和對應的 Sidecar 部署層面，需要部署在同機（可以是同一臺物理機／虛擬機，也可以是同一個 Pod），思考下，如果部署在不同的機器上，就會又引入服務通信交互的問題，那麼就會變成無解的難題：為了解決通信交互的問題，又引入新的通信交互的問題。

按照新的微服務架構 2.0 打造，微服務架構 1.0 的升級演變如圖 8 所示：

Service Mesh 架構框架方面，業內陸續開源了不少的優秀框架，Istio 是集大成者，由 Google、IBM、Lyft 等三家公司聯合打造，並已經開源，社區版本也已經發展到 V1.4.2。IstioService Mesh 邏輯上分為數據面板（執行者）和控制面板（指揮者），數據面板由一組智能代理（Envoy）組成，代理部署為 Sidecar，調解和控制微服務之間所有的網絡通信。控制面板負責管理和配置代理來路由流量，以及在運行時執行策略。如圖 9 所示，控制面板（Pilot、Mixer、Citadel）加數據面板（Envoy Proxy）即是服務治理功能，svcA 和 svcB 是業務服務自身。

圖 9 Istio 架構

與純粹的微服務架構相比，Service Mesh 又向前邁了一步。它最大的優勢是解耦應用業務，企業能夠徹底從業務角度考慮問題，同時還可以與容器編排部署平臺的集成，成為企業級應用編排部署和服務治理的標準形態。但是企業想要全面切換到 Service Mesh 並不是一件易事，還有一段路需要走。以 Istio 為例，如果要切換，會面臨以下問題：第一，老服務切換到 Istio 的過程中，由於歷史服務使用的框架不同，如何保證老服務的平穩遷移以及新老服務如何無縫交互，是企業面臨的第一個難題；第二，切換到 Istio 後，由於通信鏈路會變長，必將增加請求的響應延遲，對請求響應延遲極其敏感的業務場景，比如量化交易等場景，增加的請求相應延遲對業務來說是致命的，如何進一步優化處理；第三，Istio 的 Mixer 功能存在單點瓶頸問題，那麼對高並發的業務場景如何突破，是公司需要考慮和解決的問題；第四，切換到 Istio，將會增加基礎設施團隊的運維成本，並且遇到業務問題，定位問題涉及到業務研發團隊和基礎設施研發團隊頻繁溝通交互，自然成本也會相應增加。

作者介紹：孫玄，畢業於浙江大學，現任轉轉公司首席架構師，技術委員會主席，大中後臺技術負責人（交易平臺、基礎服務、智能客服、基礎架構、智能運維、資料庫、安全、IT等方向）；前 58 集團技術委員會主席，高級系統架構師；前百度資深研發工程師；「架構之美」 〔beautyArch〕微信公眾號作者；擅長系統架構設計，大數據，運維、機器學習、技術管理等領域；代表公司多次在業界頂級技術大會 CIO 峰會、Artificial Intelligence Conference、A2M、QCon、ArchSummit、SACC、SDCC、CCTC、DTCC、Top100、Strata + Hadoop World、WOT、GITC、GIAC、TID 等發表演講，並為《程式設計師》雜誌撰稿 2 篇。

本文是「分布式系統前沿技術」專題文章，目前該專題在持續更新中，歡迎大家保持關注👇