微服務架構的設計模式

前不久，Java Code Geeks發表了一篇文章，分析單體應用與微服務的優缺點。近日，該網站又發表了一篇文章，提供了六種微服務架構的設計模式。

聚合器微服務設計模式

這是一種最常用也最簡單的設計模式，如下圖所示：

聚合器呼叫多個服務實現應用程式所需的功能。它可以是一個簡單的Web頁面，將檢索到的資料進行處理展示。它也可以是一個更高層次的組合微服務，對檢索到的資料增加業務邏輯後進一步釋出成一個新的微服務，這符合DRY原則。另外，每個服務都有自己的快取和資料庫。如果聚合器是一個組合服務，那麼它也有自己的快取和資料庫。聚合器可以沿X軸和Z軸獨立擴充套件。

代理微服務設計模式

這是聚合器模式的一個變種，如下圖所示：

在這種情況下，客戶端並不聚合資料，但會根據業務需求的差別呼叫不同的微服務。代理可以僅僅委派請求，也可以進行資料轉換工作。

鏈式微服務設計模式

這種模式在接收到請求後會產生一個經過合併的響應，如下圖所示：

在這種情況下，服務A接收到請求後會與服務B進行通訊，類似地，服務B會同服務C進行通訊。所有服務都使用同步訊息傳遞。在整個鏈式呼叫完成之前，客戶端會一直阻塞。因此，服務呼叫鏈不宜過長，以免客戶端長時間等待。

分支微服務設計模式

這種模式是聚合器模式的擴充套件，允許同時呼叫兩個微服務鏈，如下圖所示：

資料共享微服務設計模式

自治是微服務的設計原則之一，就是說微服務是全棧式服務。但在重構現有的“單體應用（monolithic application）”時，SQL資料庫反規範化可能會導致資料重複和不一致。因此，在單體應用到微服務架構的過渡階段，可以使用這種設計模式，如下圖所示：

在這種情況下，部分微服務可能會共享快取和資料庫儲存。不過，這隻有在兩個服務之間存在強耦合關係時才可以。對於基於微服務的新建應用程式而言，這是一種反模式。

非同步訊息傳遞微服務設計模式

雖然REST設計模式非常流行，但它是同步的，會造成阻塞。因此部分基於微服務的架構可能會選擇使用訊息佇列代替REST請求/響應，如下圖所示：

實施微服務，我們需要哪些基礎框架？

微服務(MicroServices)架構是當前網際網路業界的一個技術熱點，圈裡有不少同行朋友當前有計劃在各自公司開展微服務化體系建設，他們都有相同的疑問：一個微服務架構有哪些技術關注點(technical concerns)？需要哪些基礎框架或元件來支援微服務架構？這些框架或元件該如何選型？筆者之前在兩家大型網際網路公司參與和主導過大型服務化體系和框架建設，同時在這塊也投入了很多時間去學習和研究，有一些經驗和學習心得，可以和大家一起分享。

服務註冊、發現、負載均衡和健康檢查

和單塊(Monolithic)架構不同，微服務架構是由一系列職責單一的細粒度服務構成的分散式網狀結構，服務之間通過輕量機制進行通訊，這時候必然引入一個服務註冊發現問題，也就是說服務提供方要註冊通告服務地址，服務的呼叫方要能發現目標服務，同時服務提供方一般以叢集方式提供服務，也就引入了負載均衡和健康檢查問題。根據負載均衡LB所在位置的不同，目前主要的服務註冊、發現和負載均衡方案有三種：

第一種是集中式LB方案，如下圖Fig 1，在服務消費者和服務提供者之間有一個獨立的LB，LB通常是專門的硬體裝置如F5，或者基於軟體如LVS，HAproxy等實現。LB上有所有服務的地址對映表，通常由運維配置註冊，當服務消費方呼叫某個目標服務時，它向LB發起請求，由LB以某種策略（比如Round-Robin）做負載均衡後將請求轉發到目標服務。LB一般具備健康檢查能力，能自動摘除不健康的服務例項。服務消費方如何發現LB呢？通常的做法是通過DNS，運維人員為服務配置一個DNS域名，這個域名指向LB。

Fig 1, 集中式LB方案

集中式LB方案實現簡單，在LB上也容易做集中式的訪問控制，這一方案目前還是業界主流。集中式LB的主要問題是單點問題，所有服務呼叫流量都經過LB，當服務數量和呼叫量大的時候，LB容易成為瓶頸，且一旦LB發生故障對整個系統的影響是災難性的。另外，LB在服務消費方和服務提供方之間增加了一跳(hop)，有一定效能開銷。

第二種是程序內LB方案，針對集中式LB的不足，程序內LB方案將LB的功能以庫的形式整合到服務消費方程序裡頭，該方案也被稱為軟負載(Soft Load Balancing)或者客戶端負載方案，下圖Fig 2展示了這種方案的工作原理。這一方案需要一個服務登錄檔(Service Registry)配合支援服務自注冊和自發現，服務提供方啟動時，首先將服務地址註冊到服務登錄檔（同時定期報心跳到服務登錄檔以表明服務的存活狀態，相當於健康檢查），服務消費方要訪問某個服務時，它通過內建的LB元件向服務登錄檔查詢（同時快取並定期重新整理）目標服務地址列表，然後以某種負載均衡策略選擇一個目標服務地址，最後向目標服務發起請求。這一方案對服務登錄檔的可用性(Availability)要求很高，一般採用能滿足高可用分散式一致的元件（例如Zookeeper, Consul, Etcd等）來實現。

Fig 2, 程序內LB方案

程序內LB方案是一種分散式方案，LB和服務發現能力被分散到每一個服務消費者的程序內部，同時服務消費方和服務提供方之間是直接呼叫，沒有額外開銷，效能比較好。但是，該方案以客戶庫(Client Library)的方式整合到服務呼叫方程序裡頭，如果企業內有多種不同的語言棧，就要配合開發多種不同的客戶端，有一定的研發和維護成本。另外，一旦客戶端跟隨服務呼叫方釋出到生產環境中，後續如果要對客戶庫進行升級，勢必要求服務呼叫方修改程式碼並重新發布，所以該方案的升級推廣有不小的阻力。

程序內LB的案例是Netflix的開源服務框架，對應的元件分別是：Eureka服務登錄檔，Karyon服務端框架支援服務自注冊和健康檢查，Ribbon客戶端框架支援服務自發現和軟路由。另外，阿里開源的服務框架Dubbo也是採用類似機制。

第三種是主機獨立LB程序方案，該方案是針對第二種方案的不足而提出的一種折中方案，原理和第二種方案基本類似，不同之處是，他將LB和服務發現功能從程序內移出來，變成主機上的一個獨立程序，主機上的一個或者多個服務要訪問目標服務時，他們都通過同一主機上的獨立LB程序做服務發現和負載均衡，見下圖Fig 3。

Fig 3 主機獨立LB程序方案

該方案也是一種分散式方案，沒有單點問題，一個LB程序掛了隻影響該主機上的服務呼叫方，服務呼叫方和LB之間是程序內呼叫，效能好，同時，該方案還簡化了服務呼叫方，不需要為不同語言開發客戶庫，LB的升級不需要服務呼叫方改程式碼。該方案的不足是部署較複雜，環節多，出錯除錯排查問題不方便。

該方案的典型案例是Airbnb的SmartStack服務發現框架，對應元件分別是：Zookeeper作為服務登錄檔，Nerve獨立程序負責服務註冊和健康檢查，Synapse/HAproxy獨立程序負責服務發現和負載均衡。Google最新推出的基於容器的PaaS平臺Kubernetes，其內部服務發現採用類似的機制。

服務前端路由

微服務除了內部相互之間呼叫和通訊之外，最終要以某種方式暴露出去，才能讓外界系統（例如客戶的瀏覽器、移動裝置等等）訪問到，這就涉及服務的前端路由，對應的元件是服務閘道器(Service Gateway)，見圖Fig 4，閘道器是連線企業內部和外部系統的一道門，有如下關鍵作用：

1. 服務反向路由，閘道器要負責將外部請求反向路由到內部具體的微服務，這樣雖然企業內部是複雜的分散式微服務結構，但是外部系統從閘道器上看到的就像是一個統一的完整服務，閘道器遮蔽了後臺服務的複雜性，同時也遮蔽了後臺服務的升級和變化。
2. 安全認證和防爬蟲，所有外部請求必須經過閘道器，閘道器可以集中對訪問進行安全控制，比如使用者認證和授權，同時還可以分析訪問模式實現防爬蟲功能，閘道器是連線企業內外系統的安全之門。
3. 限流和容錯，在流量高峰期，閘道器可以限制流量，保護後臺系統不被大流量沖垮，在內部系統出現故障時，閘道器可以集中做容錯，保持外部良好的使用者體驗。
4. 監控，閘道器可以集中監控訪問量，呼叫延遲，錯誤計數和訪問模式，為後端的效能優化或者擴容提供資料支援。
5. 日誌，閘道器可以收集所有的訪問日誌，進入後臺系統做進一步分析。

Fig 4, 服務閘道器

除以上基本能力外，閘道器還可以實現線上引流，線上壓測，線上除錯(Surgical debugging)，金絲雀測試(Canary Testing)，資料中心雙活(Active-Active HA)等高階功能。

閘道器通常工作在7層，有一定的計算邏輯，一般以叢集方式部署，前置LB進行負載均衡。

開源的閘道器元件有Netflix的Zuul，特點是動態可熱部署的過濾器(filter)機制，其它如HAproxy，Nginx等都可以擴充套件作為閘道器使用。

在介紹過服務登錄檔和閘道器等元件之後，我們可以通過一個簡化的微服務架構圖(Fig 5)來更加直觀地展示整個微服務體系內的服務註冊發現和路由機制，該圖假定採用程序內LB服務發現和負載均衡機制。在下圖Fig 5的微服務架構中，服務簡化為兩層，後端通用服務（也稱中間層服務Middle Tier Service）和前端服務（也稱邊緣服務Edge Service，前端服務的作用是對後端服務做必要的聚合和裁剪後暴露給外部不同的裝置，如PC，Pad或者Phone）。後端服務啟動時會將地址資訊註冊到服務登錄檔，前端服務通過查詢服務登錄檔就可以發現然後呼叫後端服務；前端服務啟動時也會將地址資訊註冊到服務登錄檔，這樣閘道器通過查詢服務登錄檔就可以將請求路由到目標前端服務，這樣整個微服務體系的服務自注冊自發現和軟路由就通過服務登錄檔和閘道器串聯起來了。如果以面向物件設計模式的視角來看，閘道器類似Proxy代理或者Façade門面模式，而服務登錄檔和服務自注冊自發現類似IoC依賴注入模式，微服務可以理解為基於閘道器代理和登錄檔IoC構建的分散式系統。

Fig 5, 簡化的微服務架構圖

服務容錯

當企業微服務化以後，服務之間會有錯綜複雜的依賴關係，例如，一個前端請求一般會依賴於多個後端服務，技術上稱為1 -> N扇出(見圖Fig 6)。在實際生產環境中，服務往往不是百分百可靠，服務可能會出錯或者產生延遲，如果一個應用不能對其依賴的故障進行容錯和隔離，那麼該應用本身就處在被拖垮的風險中。在一個高流量的網站中，某個單一後端一旦發生延遲，可能在數秒內導致所有應用資源(執行緒，佇列等)被耗盡，造成所謂的雪崩效應(Cascading Failure，見圖Fig 7)，嚴重時可致整個網站癱瘓。

Fig 6, 服務依賴

Fig 7, 高峰期單個服務延遲致雪崩效應

經過多年的探索和實踐，業界在分散式服務容錯一塊探索出了一套有效的容錯模式和最佳實踐，主要包括：

1. 電路熔斷器模式(Circuit Breaker Patten), 該模式的原理類似於家裡的電路熔斷器，如果家裡的電路發生短路，熔斷器能夠主動熔斷電路，以避免災難性損失。在分散式系統中應用電路熔斷器模式後，當目標服務慢或者大量超時，呼叫方能夠主動熔斷，以防止服務被進一步拖垮；如果情況又好轉了，電路又能自動恢復，這就是所謂的彈性容錯，系統有自恢復能力。下圖Fig 8是一個典型的具備彈性恢復能力的電路保護器狀態圖，正常狀態下，電路處於關閉狀態(Closed)，如果呼叫持續出錯或者超時，電路被開啟進入熔斷狀態(Open)，後續一段時間內的所有呼叫都會被拒絕(Fail Fast)，一段時間以後，保護器會嘗試進入半熔斷狀態(Half-Open)，允許少量請求進來嘗試，如果呼叫仍然失敗，則回到熔斷狀態，如果呼叫成功，則回到電路閉合狀態。

   

   Fig 8, 彈性電路保護狀態圖

2. 艙壁隔離模式(Bulkhead Isolation Pattern)，顧名思義，該模式像艙壁一樣對資源或失敗單元進行隔離，如果一個船艙破了進水，只損失一個船艙，其它船艙可以不受影響 。執行緒隔離(Thread Isolation)就是艙壁隔離模式的一個例子，假定一個應用程式A呼叫了Svc1/Svc2/Svc3三個服務，且部署A的容器一共有120個工作執行緒，採用執行緒隔離機制，可以給對Svc1/Svc2/Svc3的呼叫各分配40個執行緒，當Svc2慢了，給Svc2分配的40個執行緒因慢而阻塞並最終耗盡，執行緒隔離可以保證給Svc1/Svc3分配的80個執行緒可以不受影響，如果沒有這種隔離機制，當Svc2慢的時候，120個工作執行緒會很快全部被對Svc2的呼叫吃光，整個應用程式會全部慢下來。
3. 限流(Rate Limiting/Load Shedder)，服務總有容量限制，沒有限流機制的服務很容易在突發流量(秒殺，雙十一)時被沖垮。限流通常指對服務限定併發訪問量，比如單位時間只允許100個併發呼叫，對超過這個限制的請求要拒絕並回退。
4. 回退(fallback)，在熔斷或者限流發生的時候，應用程式的後續處理邏輯是什麼？回退是系統的彈性恢復能力，常見的處理策略有，直接丟擲異常，也稱快速失敗(Fail Fast)，也可以返回空值或預設值，還可以返回備份資料，如果主服務熔斷了，可以從備份服務獲取資料。

Netflix將上述容錯模式和最佳實踐整合到一個稱為Hystrix的開源元件中，凡是需要容錯的依賴點(服務，快取，資料庫訪問等)，開發人員只需要將呼叫封裝在Hystrix Command裡頭，則相關呼叫就自動置於Hystrix的彈性容錯保護之下。Hystrix元件已經在Netflix經過多年運維驗證，是Netflix微服務平臺穩定性和彈性的基石，正逐漸被社群接受為標準容錯元件。

服務框架

微服務化以後，為了讓業務開發人員專注於業務邏輯實現，避免冗餘和重複勞動，規範研發提升效率，必然要將一些公共關注點推到框架層面。服務框架(Fig 9)主要封裝公共關注點邏輯，包括：

Fig 9, 服務框架

1. 服務註冊、發現、負載均衡和健康檢查，假定採用程序內LB方案，那麼服務自注冊一般統一做在伺服器端框架中，健康檢查邏輯由具體業務服務定製，框架層提供呼叫健康檢查邏輯的機制，服務發現和負載均衡則整合在服務客戶端框架中。
2. 監控日誌，框架一方面要記錄重要的框架層日誌、metrics和呼叫鏈資料，還要將日誌、metrics等介面暴露出來，讓業務層能根據需要記錄業務日誌資料。在執行環境中，所有日誌資料一般集中落地到企業後臺日誌系統，做進一步分析和處理。
3. REST/RPC和序列化，框架層要支援將業務邏輯以HTTP/REST或者RPC方式暴露出來，HTTP/REST是當前主流API暴露方式，在效能要求高的場合則可採用Binary/RPC方式。針對當前多樣化的裝置型別(瀏覽器、普通PC、無線裝置等)，框架層要支援可定製的序列化機制，例如，對瀏覽器，框架支援輸出Ajax友好的JSON訊息格式，而對無線裝置上的Native App，框架支援輸出效能高的Binary訊息格式。
4. 配置，除了支援普通配置檔案方式的配置，框架層還可整合動態執行時配置，能夠在執行時針對不同環境動態調整服務的引數和配置。
5. 限流和容錯，框架整合限流容錯元件，能夠在執行時自動限流和容錯，保護服務，如果進一步和動態配置相結合，還可以實現動態限流和熔斷。
6. 管理介面，框架整合管理介面，一方面可以線上檢視框架和服務內部狀態，同時還可以動態調整內部狀態，對除錯、監控和管理能提供快速反饋。Spring Boot微框架的Actuator模組就是一個強大的管理介面。
7. 統一錯誤處理，對於框架層和服務的內部異常，如果框架層能夠統一處理並記錄日誌，對服務監控和快速問題定位有很大幫助。
8. 安全，安全和訪問控制邏輯可以在框架層統一進行封裝，可做成外掛形式，具體業務服務根據需要載入相關安全外掛。
9. 文件自動生成，文件的書寫和同步一直是一個痛點，框架層如果能支援文件的自動生成和同步，會給使用API的開發和測試人員帶來極大便利。Swagger是一種流行Restful API的文件方案。

當前業界比較成熟的微服務框架有Netflix的Karyon/Ribbon，Spring的Spring Boot/Cloud，阿里的Dubbo等。

執行期配置管理

服務一般有很多依賴配置，例如訪問資料庫有連線字串配置，連線池大小和連線超時配置，這些配置在不同環境(開發/測試/生產)一般不同，比如生產環境需要配連線池，而開發測試環境可能不配，另外有些引數配置在執行期可能還要動態調整，例如，執行時根據流量狀況動態調整限流和熔斷閥值。目前比較常見的做法是搭建一個執行時配置中心支援微服務的動態配置，簡化架構如下圖(Fig 10):

Fig 10, 服務配置中心

動態配置存放在集中的配置伺服器上，使用者通過管理介面配置和調整服務配置，具體服務通過定期拉(Scheduled Pull)的方式或者伺服器推(Server-side Push)的方式更新動態配置，拉方式比較可靠，但會有延遲同時有無效網路開銷(假設配置不常更新)，伺服器推方式能及時更新配置，但是實現較複雜，一般在服務和配置伺服器之間要建立長連線。配置中心還要解決配置的版本控制和審計問題，對於大規模服務化環境，配置中心還要考慮分散式和高可用問題。

配置中心比較成熟的開源方案有百度的Disconf，360的QConf，Spring的Cloud Config和阿里的Diamond等。

Netflix的微服務框架

Netflix是一家成功實踐微服務架構的網際網路公司，幾年前，Netflix就把它的幾乎整個微服務框架棧開源貢獻給了社群，這些框架和元件包括：

1. Eureka:　服務註冊發現框架
2. Zuul:　服務閘道器
3. Karyon:　服務端框架
4. Ribbon:　客戶端框架
5. Hystrix: 服務容錯元件
6. Archaius: 服務配置元件
7. Servo: Metrics元件
8. Blitz4j: 日誌元件

下圖Fig 11展示了基於這些元件構建的一個微服務框架體系，來自recipes-rss。

Fig 11, 基於Netflix開源元件的微服務框架

Netflix的開源框架元件已經在Netflix的大規模分散式微服務環境中經過多年的生產實戰驗證，正逐步被社群接受為構造微服務框架的標準組件。Pivotal去年推出的Spring Cloud開源產品，主要是基於對Netflix開源元件的進一步封裝，方便Spring開發人員構建微服務基礎框架。對於一些打算構建微服務框架體系的公司來說，充分利用或參考借鑑Netflix的開源微服務元件(或Spring Cloud)，在此基礎上進行必要的企業定製，無疑是通向微服務架構的捷徑。