微服務架構模式經過5年多的發(fā)展，在各行各業(yè)如火如荼地應用和實踐。如何在企業(yè)中優(yōu)雅地設計微服務架構?是企業(yè)面對的一個重要問題。本文將講述微服務架構1.0設計與實踐以及面臨問題和破局，最后講述微服務架構2.0設計與實踐等方面，嘗試去回答這個難題。
微服務架構1.0設計與實踐
1.1 微服務架構定義
2014年馬丁福勒提出了微服務架構設計模式，微服務架構最核心的設計有二點(如圖1 綠框所示)：第一，把單體服務拆分成一系列小服務;第二，拆分后的這些小服務是去中心化的，即每個服務都可以使用不同的編程語言，也可以使用不同的數據庫和緩存存儲數據。
圖1 微服務架構模式
1.2 微服務架構拆分設計實踐
第一個問題是服務如何拆分的問題。架構拆分沒有新鮮事，即不同領域的架構設計在道(哲學)的層面都是相通的。
我們來思考一下公司數據庫集群遇到讀寫和存儲的性能問題時，是如何解決的?假如公司電商業(yè)務包含用戶、商品以及交易等數據，每種數據使用一張單獨的表存儲，這些數據放在一個數據庫(DB4Global)中。隨著請求量的增加和數據存儲量的增加，單獨的DB4Global數據庫會遇到性能瓶頸。為了解決數據庫的性能問題，需要對DB4Global庫拆分，首先對DB4Global庫按照業(yè)務領域進行垂直拆分，拆分為多個獨立的用戶庫(DB4User)、商品庫(DB4Info)、交易庫(DB4Trade)等;其次為了進一步提升數據庫的性能，再次根據功能對每個表進行水平方向的拆分，例如用戶表10億記錄，主鍵為用戶UID。Partition Key選擇為UID，按照UID % 128 水平拆分。
架構設計之道是相通的，微服務拆分同樣遵循業(yè)務領域的垂直拆分以及功能的水平拆分。繼續(xù)以電商業(yè)務為例，首先按照業(yè)務領域的垂直拆分，分為用戶微服務、商品微服務、搜索微服務、推薦微服務、交易微服務等等。
繼續(xù)思考一個問題，在垂直方向僅僅按照業(yè)務領域進行拆分是否滿足所有的業(yè)務場景?答案是否定的。例如用戶服務分為用戶注冊(寫請求)和用戶登陸(讀請求)等。寫請求的重要性往往是大于讀請求，在互聯網大流量下，讀寫比例10:1，甚至更高的情況下，大量的讀往往會直接影響寫。為了避免大量的讀對寫請求的干擾，需要對服務進行讀寫分離，即用戶注冊為一個微服務，用戶登陸為一個微服務。此時按照API的細粒度繼續(xù)進行垂直方向的拆分。
在水平方向，按照請求的功能拆分，即對一個請求的生命周期繼續(xù)進行拆分。請求從用戶端發(fā)出，首先接受到請求的是網關服務，網關服務對請求進行請求鑒權、通用參數檢查、協(xié)議轉換以及路由轉發(fā)等。接下來業(yè)務邏輯服務對請求進行業(yè)務邏輯的編排處理(比如微信發(fā)送消息，需要進行好友關系檢查、對消息內容進行風控檢查、進行消息的存儲和推送等)。對業(yè)務數據進行存儲和查詢就需要數據訪問服務，數據訪問服務提供了基本的CRUD原子操作，并負責海量數據的Sharding(分庫分表)以及屏蔽底層存儲的差異性等功能。最后是數據持久化和緩存服務，比如可以采用NewSQL TiDB以及Redis Cluster等。
通過以上的拆分，普適的微服務架構如圖2所示。
圖2 普適的微服務架構
微服務架構通過業(yè)務垂直拆分以及水平的功能拆分，服務演化成更小的顆粒度，各服務之間相互解耦，每個服務都可以快速迭代和持續(xù)交付，從而在公司層面能夠達到降本增效的終極目標。但是服務粒度越細，服務之間的交互就會越來越多，更多的交互會使得服務之間的治理更復雜。服務之間的治理包括服務間的注冊、通信、路由、負載均衡、重試、限流、降級、熔斷、鏈路跟蹤等。
微服務架構技術選型，包括微服務本身的研發(fā)框架以及服務治理框架。目前研發(fā)框架主流的RPC有兩類：一種是RPC Over TCP，典型代表是Apache Dubbo;另外一種是RPC Over HTTP，典型代表是Spring Cloud。企業(yè)根據團隊的研發(fā)基因二者選一即可。在服務治理方面包含了服務注冊、服務配置、服務熔斷、服務監(jiān)控等方面，服務注冊本質是AP的模型，可以選用Nacos，服務配置可以選用CTrip Apollo，服務熔斷可以選用Netflix Hystrix組件，服務監(jiān)控可以選用Open-Falcon等配套框架。
1.3 微服務架構1.0面臨問題以及破局
在微服務架構1.0中每個服務包含了服務自身的功能設計以及服務治理的功能設計，他們耦合在一起，這些服務治理的功能和服務自身功能沒有關系，業(yè)務方也不需要關注。使得微服務1.0架構不再是銀彈，存在以下幾個方面的問題：
第一，每一個業(yè)務服務為了和其他業(yè)務服務交互，都必須關注和引入服務間服務治理組件，使得業(yè)務服務迭代速度變慢，如圖3所示。
圖3 業(yè)務服務迭代速度慢
第二，服務治理組件和服務自身功能耦合在一個進程內，使得服務治理組件的升級強依賴于業(yè)務服務自身，造成基礎設施研發(fā)團隊的交付能力和交付速度大大降低。如圖4所示，服務降級功能從V1升級到V2，需要業(yè)務服務更換服務降級功能的組件，重新打包編譯和發(fā)布。
圖4 服務治理組件升級困難
第三，如[1]所示，馬丁福勒對微服務架構的期望是每個服務都可以使用業(yè)務團隊熟悉的語言來編寫，但是在服務自身和服務治理耦合在一起的情況下，每個語言都需要一套完整的服務治理組件，必然造成公司研發(fā)投入成本增大，ROI不高。如圖5所示，Java語言編寫的應用程序A和應用程序C交互，就需要一套完整的Java語言服務治理組件，同樣，世界上最好語言編寫的應用程序B和應用程序C交互，就需要一套完成的PHP語言服務治理組件。
圖5 多套服務治理組件
那么造成這些問題的本質原因在于服務自身功能和服務治理功能的物理耦合，把服務治理功能完全解耦出來，變成一個獨立的服務治理進程，從而以上三個問題得以徹底解決。
微服務架構2.0設計與實踐
2.1 Serive Mesh定義
微服務架構1.0繼續(xù)演進，就變成了微服務架構2.0，即Service Mesh架構(Service Mesh)。Servie Mesh架構最早由開發(fā)Linkerd的Buoyant公司提出，并在內部使用。2016年09月29日第一次公開使用，2017年初進入國內技術社區(qū)視野。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。通過把服務治理功能從服務自身中物理剝離出來，下沉形成獨立的進程，從而物理解耦。
在這樣的架構模式下，業(yè)務應用程序再也不需要關注服務治理的功能，服務治理的功能升級也不要依賴于服務自身，從而能夠讓業(yè)務迭代更快速和高效。同時由于服務治理功能變成一個獨立的進程，只需要使用一種語言打造即可，業(yè)務服務自身可以選擇業(yè)務團隊擅長的語言進行編寫，從而能夠真正達到馬丁福勒對微服務的期望。
我們再深入分析下協(xié)議，在通信協(xié)議方面，業(yè)務應用程序和Sidecar的通信可以基于TCP長連接，也可以基于HTTP 1.0或者2.0的長連接(思考下：是否一定要使用長連接?)，Sidecar間的通信協(xié)議沒有特殊要求;在數據傳輸協(xié)議方面，可以是JSON/XML等跨語言的文本協(xié)議，也可以選擇Protobuffers/MessagePack等跨語言的二進制協(xié)議。
保證了通信協(xié)議和數據傳輸協(xié)議的跨語言，不同語言的應用程序就可以無縫地和Sidecar進行交互。在應用程序和對應的Sidecar部署層面，需要部署在同機(可以是同一臺物理機/虛擬機，也可以是同一個Pod)，思考下，如果部署在不同的機器上，就會又引入服務通信交互的問題，那么就會變成無解的難題：為了解決通信交互的問題，又引入新的通信交互的問題。
2.3 微服務架構2.0實踐
按照新的微服務架構2.0打造，微服務架構1.0的升級演變如圖8所示：
圖 8 微服務架構2.0
Service Mesh架構框架方面，業(yè)內陸續(xù)開源了不少的優(yōu)秀框架，Istio是集大成者，由Google、IBM、Lyft等三家公司聯合打造，并已經開源，社區(qū)版本也已經發(fā)展到V1.4.2。IstioService Mesh邏輯上分為數據面板(執(zhí)行者)和控制面板(指揮者)，數據面板由一組智能代理(Envoy)組成，代理部署為Sidecar，調解和控制微服務之間所有的網絡通信�？刂泼姘遑撠煿芾砗团渲么韥砺酚闪髁浚约霸谶\行時執(zhí)行策略。如圖9所示，控制面板(Pilot、Mixer、Citadel)加數據面板(Envoy Proxy)即是服務治理功能，svcA和svcB是業(yè)務服務自身。
圖 9 Istio架構
未來展望
與純粹的微服務架構相比，Service Mesh又向前邁了一步。它最大的優(yōu)勢是解耦應用業(yè)務，企業(yè)能夠徹底從業(yè)務角度考慮問題，同時還可以與容器編排部署平臺的集成，成為企業(yè)級應用編排部署和服務治理的標準形態(tài)。
但是企業(yè)想要全面切換到Service Mesh并不是一件易事，還有一段路需要走。以Istio為例，如果要切換，會面臨以下問題：
老服務切換到Istio的過程中，由于歷史服務使用的框架不同，如何保證老服務的平穩(wěn)遷移以及新老服務如何無縫交互，是企業(yè)面臨的第一個難題;
切換到Istio后，由于通信鏈路會變長，必將增加請求的響應延遲，對請求響應延遲極其敏感的業(yè)務場景，比如量化交易等場景，增加的請求相應延遲對業(yè)務來說是致命的，如何進一步優(yōu)化處理;
Istio的Mixer功能存在單點瓶頸問題，那么對高并發(fā)的業(yè)務場景如何突破，是公司需要考慮和解決的問題;
切換到Istio，將會增加基礎設施團隊的運維成本，并且遇到業(yè)務問題，定位問題涉及到業(yè)務研發(fā)團隊和基礎設施研發(fā)團隊頻繁溝通交互，自然成本也會相應增加。
第三，Istio的Mixer功能存在單點瓶頸問題，那么對高并發(fā)的業(yè)務場景如何突破，是公司需要考慮和解決的問題;
第四，切換到Istio，將會增加基礎設施團隊的運維成本，并且遇到業(yè)務問題，定位問題涉及到業(yè)務研發(fā)團隊和基礎設施研發(fā)團隊頻繁溝通交互，自然成本也會相應增加。
作者簡介：孫玄，畢業(yè)于浙江大學，現任奈學教育科技公司創(chuàng)始人兼CEO，前轉轉公司首席架構師，技術委員會主席，大中后臺技術負責人(交易平臺、基礎服務、智能客服、基礎架構、智能運維、數據庫、安全、IT等方向);前58集團技術委員會主席，高級系統(tǒng)架構師;前百度資深研發(fā)工程師;“架構之美” 〔beautyArch〕微信公眾號作者;擅長系統(tǒng)架構設計，大數據，運維、機器學習、技術管理等領域;代表公司多次在業(yè)界頂級技術大會CIO峰會、Artificial Intelligence Conference、A2M、QCon、ArchSummit、SACC、SDCC、CCTC、DTCC、Top100、Strata + Hadoop World、WOT、GITC、GIAC、TID等發(fā)表演講，并為《程序員》雜志撰稿 2 篇。
