點擊上方“朱小廝的博客”，選擇“設(shè)為星標(biāo)”

后臺回復(fù)”加群“加入公眾號專屬技術(shù)群

微服務(wù)架構(gòu)模式經(jīng)過 5 年多的發(fā)展，在各行各業(yè)如火如荼地應(yīng)用和實踐。如何在企業(yè)中優(yōu)雅地設(shè)計微服務(wù)架構(gòu)？是企業(yè)面對的一個重要問題。本文將講述微服務(wù)架構(gòu) 1.0 設(shè)計與實踐以及面臨問題和破局，最后講述微服務(wù)架構(gòu) 2.0 設(shè)計與實踐等方面，嘗試去回答這個難題。

微服務(wù)架構(gòu) 1.0 設(shè)計與實踐

微服務(wù)架構(gòu)定義

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

圖 1 微服務(wù)架構(gòu)模式

微服務(wù)架構(gòu)拆分設(shè)計實踐

第一個問題是服務(wù)如何拆分的問題。架構(gòu)拆分沒有新鮮事，即不同領(lǐng)域的架構(gòu)設(shè)計在道（哲學(xué)）的層面都是相通的。

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

架構(gòu)設(shè)計之道是相通的，微服務(wù)拆分同樣遵循業(yè)務(wù)領(lǐng)域的垂直拆分以及功能的水平拆分。繼續(xù)以電商業(yè)務(wù)為例，首先按照業(yè)務(wù)領(lǐng)域的垂直拆分，分為用戶微服務(wù)、商品微服務(wù)、搜索微服務(wù)、推薦微服務(wù)、交易微服務(wù)等。

繼續(xù)思考一個問題，在垂直方向僅僅按照業(yè)務(wù)領(lǐng)域進行拆分是否滿足所有的業(yè)務(wù)場景？答案是否定的。例如用戶服務(wù)分為用戶注冊（寫請求）和用戶登陸（讀請求）等。寫請求的重要性往往是大于讀請求，在互聯(lián)網(wǎng)大流量下，讀寫比例 10:1，甚至更高的情況下，大量的讀往往會直接影響寫。為了避免大量的讀對寫請求的干擾，需要對服務(wù)進行讀寫分離，即用戶注冊為一個微服務(wù)，用戶登陸為一個微服務(wù)。此時按照 API 的細粒度繼續(xù)進行垂直方向的拆分。

在水平方向，按照請求的功能拆分，即對一個請求的生命周期繼續(xù)進行拆分。請求從用戶端發(fā)出，首先接受到請求的是網(wǎng)關(guān)服務(wù)，網(wǎng)關(guān)服務(wù)對請求進行請求鑒權(quán)、通用參數(shù)檢查、協(xié)議轉(zhuǎn)換以及路由轉(zhuǎn)發(fā)等。接下來業(yè)務(wù)邏輯服務(wù)對請求進行業(yè)務(wù)邏輯的編排處理（比如微信發(fā)送消息，需要進行好友關(guān)系檢查、對消息內(nèi)容進行風(fēng)控檢查、進行消息的存儲和推送等）。對業(yè)務(wù)數(shù)據(jù)進行存儲和查詢就需要數(shù)據(jù)訪問服務(wù)，數(shù)據(jù)訪問服務(wù)提供了基本的 CRUD 原子操作，并負責(zé)海量數(shù)據(jù)的 Sharding（分庫分表）以及屏蔽底層存儲的差異性等功能。最后是數(shù)據(jù)持久化和緩存服務(wù)，比如可以采用 NewSQL TiDB 以及 Redis Cluster 等。

通過以上的拆分，普適的微服務(wù)架構(gòu)如圖 2 所示。

圖 2 普適的微服務(wù)架構(gòu)

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

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

微服務(wù)架構(gòu) 1.0 面臨問題以及破局

在微服務(wù)架構(gòu) 1.0 中每個服務(wù)包含了服務(wù)自身的功能設(shè)計以及服務(wù)治理的功能設(shè)計，他們耦合在一起，這些服務(wù)治理的功能和服務(wù)自身功能沒有關(guān)系，業(yè)務(wù)方也不需要關(guān)注。使得微服務(wù) 1.0 架構(gòu)不再是銀彈，存在以下幾個方面的問題：

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

圖 3 業(yè)務(wù)服務(wù)迭代速度慢

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

圖 4 服務(wù)治理組件升級困難

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

圖 5 多套服務(wù)治理組件

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

微服務(wù)架構(gòu) 2.0 設(shè)計與實踐

Serive Mesh 定義

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

圖 6 Service Mesh 定義

Service Mesh 是一個基礎(chǔ)設(shè)施層，用于處理服務(wù)間交互。云原生應(yīng)用有著復(fù)雜的服務(wù)拓撲，Service Mesh 負責(zé)在這些拓撲中實現(xiàn)請求的可靠傳遞。在線上實踐中，Service Mesh 通常實現(xiàn)為一組輕量級的網(wǎng)絡(luò)代理（Sidecar 邊車），它們與應(yīng)用程序部署在一起，并且對應(yīng)用程序透明。

微服務(wù)架構(gòu) 2.0 破局

圖 7 Service Mesh 架構(gòu)

如圖 7 所示，應(yīng)用程序 A 和應(yīng)用程序 B 交互，請求調(diào)用關(guān)系如下：應(yīng)用程序 A 調(diào)用本地的 Sidecar A，Sidecar A 在通過網(wǎng)絡(luò)交互調(diào)用遠端的 Sidecar B，再由 Sidecar B 把請求傳遞給應(yīng)用程序 B。請求回應(yīng)關(guān)系也是類似：應(yīng)用程序 B 調(diào)用 Sidecar B，Sidecar B 在通過網(wǎng)絡(luò)交互調(diào)用遠端的 Sidecar A，再由 Sidecar A 把請求回應(yīng)傳遞給應(yīng)用程序 A。通過把服務(wù)治理功能從服務(wù)自身中物理剝離出來，下沉形成獨立的進程，從而物理解耦。

在這樣的架構(gòu)模式下，業(yè)務(wù)應(yīng)用程序再也不需要關(guān)注服務(wù)治理的功能，服務(wù)治理的功能升級也不要依賴于服務(wù)自身，從而能夠讓業(yè)務(wù)迭代更快速和高效。同時由于服務(wù)治理功能變成一個獨立的進程，只需要使用一種語言打造即可，業(yè)務(wù)服務(wù)自身可以選擇業(yè)務(wù)團隊擅長的語言進行編寫，從而能夠真正達到馬丁福勒對微服務(wù)的期望。

我們再深入分析下協(xié)議，在通信協(xié)議方面，業(yè)務(wù)應(yīng)用程序和 Sidecar 的通信可以基于 TCP 長連接，也可以基于 HTTP 1.0 或者 2.0 的長連接（思考下：是否一定要使用長連接？），Sidecar 間的通信協(xié)議沒有特殊要求；在數(shù)據(jù)傳輸協(xié)議方面，可以是 JSON／XML 等跨語言的文本協(xié)議，也可以選擇 Protobuffers／MessagePack 等跨語言的二進制協(xié)議。

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

微服務(wù)架構(gòu) 2.0 實踐

按照新的微服務(wù)架構(gòu) 2.0 打造，微服務(wù)架構(gòu) 1.0 的升級演變?nèi)鐖D 8 所示：

圖 8 微服務(wù)架構(gòu) 2.0

Service Mesh 架構(gòu)框架方面，業(yè)內(nèi)陸續(xù)開源了不少的優(yōu)秀框架，Istio 是集大成者，由 Google、IBM、Lyft 等三家公司聯(lián)合打造，并已經(jīng)開源，社區(qū)版本也已經(jīng)發(fā)展到 V1.4.2。IstioService Mesh 邏輯上分為數(shù)據(jù)面板（執(zhí)行者）和控制面板（指揮者），數(shù)據(jù)面板由一組智能代理（Envoy）組成，代理部署為 Sidecar，調(diào)解和控制微服務(wù)之間所有的網(wǎng)絡(luò)通信。控制面板負責(zé)管理和配置代理來路由流量，以及在運行時執(zhí)行策略。如圖 9 所示，控制面板（Pilot、Mixer、Citadel）加數(shù)據(jù)面板（Envoy Proxy）即是服務(wù)治理功能，svcA 和 svcB 是業(yè)務(wù)服務(wù)自身。

圖 9 Istio 架構(gòu)

未來展望

與純粹的微服務(wù)架構(gòu)相比，Service Mesh 又向前邁了一步。它最大的優(yōu)勢是解耦應(yīng)用業(yè)務(wù)，企業(yè)能夠徹底從業(yè)務(wù)角度考慮問題，同時還可以與容器編排部署平臺的集成，成為企業(yè)級應(yīng)用編排部署和服務(wù)治理的標(biāo)準(zhǔn)形態(tài)。

但是企業(yè)想要全面切換到 Service Mesh 并不是一件易事，還有一段路需要走。以 Istio 為例，如果要切換，會面臨以下問題：

第一，老服務(wù)切換到 Istio 的過程中，由于歷史服務(wù)使用的框架不同，如何保證老服務(wù)的平穩(wěn)遷移以及新老服務(wù)如何無縫交互，是企業(yè)面臨的第一個難題；

第二，切換到 Istio 后，由于通信鏈路會變長，必將增加請求的響應(yīng)延遲，對請求響應(yīng)延遲極其敏感的業(yè)務(wù)場景，比如量化交易等場景，增加的請求相應(yīng)延遲對業(yè)務(wù)來說是致命的，如何進一步優(yōu)化處理；

第三，Istio 的 Mixer 功能存在單點瓶頸問題，那么對高并發(fā)的業(yè)務(wù)場景如何突破，是公司需要考慮和解決的問題；

第四，切換到 Istio，將會增加基礎(chǔ)設(shè)施團隊的運維成本，并且遇到業(yè)務(wù)問題，定位問題涉及到業(yè)務(wù)研發(fā)團隊和基礎(chǔ)設(shè)施研發(fā)團隊頻繁溝通交互，自然成本也會相應(yīng)增加。

想知道更多？掃描下面的二維碼關(guān)注我

【精彩推薦】

• 滴滴為啥值3600億，看看它的數(shù)據(jù)中臺就知道了

• 這次終于不再為iptables范迷糊

• 工行分布式數(shù)據(jù)庫選項與大規(guī)模容器化實踐

• 為什么RedisCluster會設(shè)計成16384個槽呢？
  

朕已閱?

總結(jié)

以上是生活随笔為你收集整理的微服务架构何去何从？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。