微服務操做模型

這裏並非介紹微服務概念，如須要了解微服務，能夠閱讀Fowler-Microservices文章。本博客假定咱們已開始使用微服務解耦單體應用，用來提高可部署性和可擴展性。

當咱們在系統範圍內部署大量的微服務時，一個新的挑戰產生了，單體應用部署時不會發生。這篇文章將針對這些新的挑戰，在系統範圍內部署大量微服務時定義一套操做模型（operations model）。

這篇文章分爲以下幾個部分：

1. 前提條件；
2. 擴展；
3. 問題；
4. 須要的組件；
5. 參考模型；
6. 下一步；

 

1. 前提條件

當在系統範圍內須要部署大量微服務時，須要什麼條件呢？

根據Flower的文章，以下是咱們想要獲得的：

 (Source:http://martinfowler.com/articles/microservices.html)

 

然而，在開始發佈大量微服務替換單體應用以前，咱們須要實現以下這些前置條件：

• 目標架構；
• 持續交付工具；
• 合適的組件結構；

下面簡要描述每個前置條件。

1.1   目標架構

首先，咱們須要分區微服務。例如，咱們能夠垂直分解微服務。

• 核心服務（Core services）-處理業務數據的持久化和實施業務邏輯和其餘規則；
• 組合服務（Composite services）-組合服務指編排一組核心服務實現一個特定任務，或者從一組核心服務中聚合信息；
• API services – 向外暴露功能，例如容許第三方使用底層功能建立新的應用；

 

也能夠水平上應用領域驅動分解。以下是一個目標架構：

備註：這僅僅是一個範例目標架構，你可使用徹底不一樣的架構。核心時在開始部署微服務以前，須要有簡歷一個目標架構。不然，你最終的架構有可能像一團麪條同樣，甚至比現有的單體應用更加糟糕。

 

1.2 持續交付

咱們假定已經有了一套可持續交付的發佈工具，以便咱們能夠高效地反覆發佈微服務。

 

(Source: http://www.infoq.com/minibooks/emag-devops-toolchain)

 

1.3合適的組織

最後，咱們須要採用合適的組織結構，避免和Conway法則相沖突。Conway法則以下：

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

 

(Source: http://martinfowler.com/articles/microservices.html)

 

2. 擴展

接下來是本文關注的要點：

當咱們分解單體應用，並使用大量的微服務替換時，在系統範圍內會發生什麼呢？

(1)   大量的部署單元

將產生須要的小的微服務，而不是以前的一個大的單體應用，這將須要管理和跟蹤大量的部署單元。

(2)   微服務將同時暴露和調用服務

在系統範圍內，大部分的微服務彼此是互相鏈接的。

(3)   一些微服務暴露外部API

這些微服務將負責包含其餘的微服務不容許外部訪問。

(4)   系統根據動態

新的微服務部署，替換老的服務。現有的微服務新增實例，知足增加的負荷。這意味着微服務將比之前更高的頻率增長和下線。

(5)   平均故障時間(MTBF)將降低

在系統範圍內，故障發生頻率將更頻繁。軟件組件將不時發生問題。大量部署的微服務將比以前部署的單體應用出現問題的可能更高。

 

3. 問題

微服務模型將致使一些重要的運行時相關的問題：

(1)   微服務如何配置以及是否正確？

針對少許的應用程序，處理配置不是主要的問題，如使用配置文件或者在數據庫中的配置表。在大量的微服務部署到大量的服務器上時，這一配置訪問將變得很是複雜。這將致使大量的小的配置文件或者數據配置表遍及整個系統，使得難以高效可靠地維護。

(2)   什麼微服務部署了，部署在哪裏了？

在只有少許服務部署時，管理部署的主機和端口仍是比較簡單的。可是當有大量的微服務部署時，這些服務或多或少須要持續變動，如手工維護將變得很是麻煩。

(3)   如何維護路由信息？

在動態系統範圍中，服務消費方也是一個挑戰。尤爲是路由表或者消費配置文件，須要手工更新。在微服務不斷新增新的主機/端口時，將沒有時間手工維護。交付時間將會延長，而且手工維護出錯的風險也會增長。

(4)   如何防止失敗鏈？

因爲微服務之間是相互鏈接的，須要關注系統範圍內的失敗鏈。例如，一個被其餘衆多微服務依賴的微服務失敗了，其餘依賴的微服務也可能開始失敗。若是沒有合適處理，大量微服務將受到這個單一失敗的微服務所影響，致使一個脆弱的系統。

(5)   如何驗證全部的微服務已上線且在運行中？

跟蹤少許應用的運行狀態是比較簡單的，可是如何驗證全部的微服務是健康的，且準備好接收請求？

(6)   如何跟蹤服務之間的消息？

如何應對組織開始接到關於一些流程執行失敗？什麼微服務到致使這一問題的根本緣由？例如，訂單12345卡住了，咱們如何知道是由於微服務A沒法訪問，仍是由於微服務B在發送一個訂單確認消息以前，須要手工批准。

(7)   如何確保僅僅API服務暴露給外部？

例如咱們如何避免外部未受權的請求，對內部微服務的訪問？

(8)   如何保證API服務的安全？

這不是針對微服務的特定問題，可是保護對外暴露的微服務仍然是很是重要的。

 

4. 須要的組件

爲了解決上述的一些問題，新的操做和管理功能是必須的。針對上述問題，建議的解決方案包括以下組件：

(1)   中心配置服務Central Configuration Server

咱們須要一箇中心配置管理，而不是針對每個部署單元（微服務）有一個本地配置。此外，咱們還需一個配置API，微服務用來獲取配置信息。

(2)   服務發現服務 Service Discovery Server

咱們須要服務發現功能，微服務在啓動時，經過API本身註冊，而不是手工跟蹤微服務部署的主機和端口。

(3)   動態路由和負載均衡 Dynamic Routing and Load Balancer

基於服務發現功能，路由組件使用discovery API 查詢請求的微服務部署在哪裏；在被請求的服務部署了多個實例的狀況下，負載均衡組件能夠決定路由請求到特定的實例。

(4)   電路斷路器 Circuit Breaker

爲了不失敗鏈問題，咱們須要養分Circuit Breaker模式，詳細信息能夠參考 Fowler-Circuit Breaker的文章。

(5)   監控 Monitoring

基於電路斷路器，咱們能夠監控微服務的狀態，同時收集運行時統計數據，獲知服務的健康狀態和當前使用率。這些信息能夠收集並顯示在dashboard上，並針對配置閾值設置自動報警。

(6)   中心日誌分析 Centralized Log Analysis

爲了跟蹤消息，並檢測微服務什麼時候故障，咱們須要一箇中心日誌分析功能，能夠訪問服務器並收集每個微服務的log文件。日誌分析功能保存log信息在中心數據庫中，並提供了查詢和dashboard功能。備註：爲了查找相關的消息，全部微服務須要在log消息中使用相關的id，這點很重要。

(7)   邊緣服務 Edge Server

爲了對外部暴露API 服務，並阻止對內部微服務的未受權訪問，咱們須要一個邊緣服務（Edge Server），全部外部的訪問都通過邊緣服務器。基於前面的服務發現組件，邊緣服務器能夠重用動態路由和負載均衡功能。邊緣服務器做爲一個動態和有效的反向代理，在內部系統更新時，沒必要手動更新。

(8)   OAuth 2.0保護的API

建議OAuth 2.0 標準保護暴露的API服務。應用OAuth 2.0 有以下效果：

1/一個新組建做爲OAuth Authorization Server；

2/API服務做爲OAuth Resource Server；

3/外部API消費方做爲OAuth Clients；

4/邊緣服務器（Edge Server）做爲OAuth Token Relay；

（4.1）做爲OAuth Resource Server；

（4.2）將外部請求中的OAuth Access Tokens傳遞給API 服務；

備註：OAuth 2.0 標準可能經過OpenID Connect標準來補充完善，提供更好的受權功能。

 

5. 參考模型

總而言之，微服務須要一套包含上述支持服務的基礎設施，微服務使用它們的API來交互。下圖描繪了這一基礎設施：

 

備註：爲了減小上圖中交互的複雜度，微服務和支持服務的交互並無畫出來。

 

6. 下一步

在接下來的文章中，咱們將描述和演示如何實現上述建議的參考模型。

 

英文原文連接：

An operations model for Microservices