作者 | 孫玄
前言
微服務架構模式經過5年多的發展，在各行各業如火如荼地應用和實踐。如何在企業中優雅地設計微服務架構？是企業面對的一個重要問題。本文將講述微服務架構1.0設計與實踐以及面臨問題和破局，最後講述微服務架構2.0設計與實踐等方面，嘗試去回答這個難題。
微服務架構1.0設計與實踐
1.1 微服務架構定義
2014年馬丁福勒提出了微服務架構設計模式，微服務架構最核心的設計有二點（如圖1 綠框所示）：第一，把單體服務拆分成一系列小服務；第二，拆分後的這些小服務是去中心化的，即每個服務都可以使用不同的編程語言，也可以使用不同的數據庫和緩存存儲數據。
圖1 微服務架構模式
1.2 微服務架構拆分設計實踐
第一個問題是服務如何拆分的問題。架構拆分沒有新鮮事，即不同領域的架構設計在道（哲學）的層面都是相通的。
我們來思考一下公司數據庫集群遇到讀寫和存儲的性能問題時，是如何解決的？假如公司電商業務包含用戶、商品以及交易等數據，每種數據使用一張單獨的表存儲，這些數據放在一個數據庫（DB4Global）中。隨著請求量的增加和數據存儲量的增加，單獨的DB4Global數據庫會遇到性能瓶頸。為了解決數據庫的性能問題，需要對DB4Global庫拆分，首先對DB4Global庫按照業務領域進行垂直拆分，拆分為多個獨立的用戶庫（DB4User）、商品庫（DB4Info）、交易庫（DB4Trade）等；其次為了進一步提升數據庫的性能，再次根據功能對每個表進行水平方向的拆分，例如用戶表10億記錄，主鍵為用戶UID。Partition Key選擇為UID，按照UID % 128 水平拆分。
架構設計之道是相通的，微服務拆分同樣遵循業務領域的垂直拆分以及功能的水平拆分。繼續以電商業務為例，首先按照業務領域的垂直拆分，分為用戶微服務、商品微服務、搜索微服務、推薦微服務、交易微服務等等。
繼續思考一個問題，在垂直方向僅僅按照業務領域進行拆分是否滿足所有的業務場景？答案是否定的。例如用戶服務分為用戶註冊（寫請求）和用戶登陸（讀請求）等。寫請求的重要性往往是大於讀請求，在互聯網大流量下，讀寫比例10:1，甚至更高的情況下，大量的讀往往會直接影響寫。為了避免大量的讀對寫請求的干擾，需要對服務進行讀寫分離，即用戶註冊為一個微服務，用戶登陸為一個微服務。此時按照API的細粒度繼續進行垂直方向的拆分。
在水平方向，按照請求的功能拆分，即對一個請求的生命週期繼續進行拆分。請求從用戶端發出，首先接受到請求的是網關服務，網關服務對請求進行請求鑑權、通用參數檢查、協議轉換以及路由轉發等。接下來業務邏輯服務對請求進行業務邏輯的編排處理（比如微信發送消息，需要進行好友關係檢查、對消息內容進行風控檢查、進行消息的存儲和推送等）。對業務數據進行存儲和查詢就需要數據訪問服務，數據訪問服務提供了基本的CRUD原子操作，並負責海量數據的Sharding（分庫分表）以及屏蔽底層存儲的差異性等功能。最後是數據持久化和緩存服務，比如可以採用NewSQL TiDB以及Redis Cluster等。
通過以上的拆分，普適的微服務架構如圖2所示。
圖2 普適的微服務架構
微服務架構通過業務垂直拆分以及水平的功能拆分，服務演化成更小的顆粒度，各服務之間相互解耦，每個服務都可以快速迭代和持續交付，從而在公司層面能夠達到降本增效的終極目標。但是服務粒度越細，服務之間的交互就會越來越多，更多的交互會使得服務之間的治理更復雜。服務之間的治理包括服務間的註冊、通信、路由、負載均衡、重試、限流、降級、熔斷、鏈路跟蹤等。
微服務架構技術選型，包括微服務本身的研發框架以及服務治理框架。目前研發框架主流的RPC有兩類：一種是RPC Over TCP，典型代表是Apache Dubbo；另外一種是RPC Over HTTP，典型代表是Spring Cloud。企業根據團隊的研發基因二者選一即可。在服務治理方面包含了服務註冊、服務配置、服務熔斷、服務監控等方面，服務註冊本質是AP的模型，可以選用Nacos，服務配置可以選用CTrip Apollo，服務熔斷可以選用Netflix Hystrix組件，服務監控可以選用Open-Falcon等配套框架。
1.3 微服務架構1.0面臨問題以及破局
在微服務架構1.0中每個服務包含了服務自身的功能設計以及服務治理的功能設計，他們耦合在一起，這些服務治理的功能和服務自身功能沒有關係，業務方也不需要關注。使得微服務1.0架構不再是銀彈，存在以下幾個方面的問題：
第一，每一個業務服務為了和其他業務服務交互，都必須關注和引入服務間服務治理組件，使得業務服務迭代速度變慢，如圖3所示。
圖3 業務服務迭代速度慢
第二，服務治理組件和服務自身功能耦合在一個進程內，使得服務治理組件的升級強依賴於業務服務自身，造成基礎設施研發團隊的交付能力和交付速度大大降低。如圖4所示，服務降級功能從V1升級到V2，需要業務服務更換服務降級功能的組件，重新打包編譯和發佈。
圖4 服務治理組件升級困難
第三，如[1]所示，馬丁福勒對微服務架構的期望是每個服務都可以使用業務團隊熟悉的語言來編寫，但是在服務自身和服務治理耦合在一起的情況下，每個語言都需要一套完整的服務治理組件，必然造成公司研發投入成本增大，ROI不高。如圖5所示，Java語言編寫的應用程序A和應用程序C交互，就需要一套完整的Java語言服務治理組件，同樣，世界上最好語言編寫的應用程序B和應用程序C交互，就需要一套完成的PHP語言服務治理組件。
圖5 多套服務治理組件
那麼造成這些問題的本質原因在於服務自身功能和服務治理功能的物理耦合，把服務治理功能完全解耦出來，變成一個獨立的服務治理進程，從而以上三個問題得以徹底解決。
微服務架構2.0設計與實踐
2.1 Serive Mesh定義
微服務架構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所示：
圖 6 Service Mesh定義
Service Mesh是一個基礎設施層，用於處理服務間交互。雲原生應用有著複雜的服務拓撲，Service Mesh負責在這些拓撲中實現請求的可靠傳遞。在線上實踐中，Service Mesh通常實現為一組輕量級的網絡代理（Sidecar邊車），它們與應用程序部署在一起，並且對應用程序透明。
2.2 微服務架構2.0破局
圖7 Service Mesh架構
如圖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.3 微服務架構2.0實踐
按照新的微服務架構2.0打造，微服務架構1.0的升級演變如圖8所示：
圖 8 微服務架構2.0
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，將會增加基礎設施團隊的運維成本，並且遇到業務問題，定位問題涉及到業務研發團隊和基礎設施研發團隊頻繁溝通交互，自然成本也會相應增加。
第三，Istio的Mixer功能存在單點瓶頸問題，那麼對高併發的業務場景如何突破，是公司需要考慮和解決的問題；
第四，切換到Istio，將會增加基礎設施團隊的運維成本，並且遇到業務問題，定位問題涉及到業務研發團隊和基礎設施研發團隊頻繁溝通交互，自然成本也會相應增加。
作者簡介：孫玄，畢業於浙江大學，現任奈學教育科技公司創始人兼CEO，前轉轉公司首席架構師，技術委員會主席，大中後臺技術負責人（交易平臺、基礎服務、智能客服、基礎架構、智能運維、數據庫、安全、IT等方向）；前58集團技術委員會主席，高級系統架構師；前百度資深研發工程師；“架構之美” 〔beautyArch〕微信公眾號作者；擅長系統架構設計，大數據，運維、機器學習、技術管理等領域；代表公司多次在業界頂級技術大會CIO峰會、Artificial Intelligence Conference、A2M、QCon、ArchSummit、SACC、SDCC、CCTC、DTCC、Top100、Strata + Hadoop World、WOT、GITC、GIAC、TID等發表演講，併為《程序員》雜誌撰稿 2 篇。
閱讀更多 CSDN雲計算 的文章
