微服務操做模型

微服務操做模型

本文不是另一篇關於微服務介紹的文章，要看微服務介紹的經典文章直接戳後面Fowler的微服務。

而本文假設咱們已經開始使用微服務，用它來分解單體應用以提升部署效率和可擴展性。

隨着系統領域部署微服務數量劇增，就會出現新的挑戰，而這些挑戰在只部署一些單體應用的時候是沒有的。這篇文章咱們就聚焦這些新的挑戰，並給使用大量微服務部署的系統領域操做模型作個定義。

本文分爲以下幾部分:

• 先決條件
• 擴展
• 問題
• 必要組件
• 參考模型
• Next step

1. 先決條件

首先若是要在系統藍圖中使用大量微服務須要什麼條件?

根據Fowler微服務介紹，咱們要達到下面的目的:

然而，在咱們開始在咱們的系統藍圖鋪開大量微服務來取代咱們現有的單體應用以前，咱們須要知足一些先決條件(或者至少在某種程度下), 咱們須要:

• 目標架構
• 持續發佈連鎖工具
• 優化的組織結構

下面咱們分別看看這幾個條件。

1.1 目標架構

首先咱們須要一個如何分解咱們微服務的架構思想。例如咱們能夠將他們分解成下面幾個垂直層:

• 核心服務: 處理業務數據持久化以及應用業務規則和其餘邏輯的。
• 組裝服務: 組裝服務能夠協調多個核心服務執行普通任務，或者從一些核心服務中聚合信息。
• API服務: 給外部暴露一些可用的功能，例如，容許第三方發明創造性的應用程序，這些應用程序可使用系統藍圖裏的底層功能。

另外水平層面咱們能夠應用一些領域驅動分區。這樣目標架構有可能相似以下:

注意： 這只是一個目標架構的樣板，而你具體的架構可能徹底不一樣。這裏關鍵點在於， 在開始擴展部署微服務以前須要有一個目標架構。 不然看到的系統藍圖就像意大利麪條同樣, 望而止步，這樣的話比現有的單體應用的特色還要糟糕。

1.2 持續發佈

咱們也假設已經有一些的現成的持續部署工具鏈，所以咱們能夠進行有效的、重複的、高質量驅動的方式來開始微服務實現, 例如:

1.3 組織結構

最後, 咱們假設咱們已經採起咱們的組織結構來避免Conway法則引起的問題。 康威法則陳述以下。

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
任何設計系統的組織，必然會產生如下設計結果：即其結構就是該組織溝通結構的寫照。簡單來講： 產品必然是其組織溝通結構的縮影。

擴展(SCALING UP)

所以，本文接下來的焦點在於當咱們開始將一些單體應用分解並使用微服務替代它們的時候，在系統藍圖中會發生什麼?

• 大量部署的單元: 不少微服務代替一些大型的單體應用，固然會致使明顯數量的發佈單元須要管理和跟蹤。
• 微服務既暴露服務也消費服務: 這就致使系統領域中大多數微服務須要互相交互。
• 某些微服務會暴露外部API: 這些微服務會負責屏蔽其餘微服務免受外部訪問。
• 系統領域更加動態: 新微服務部署後，舊的須要替換或移除，原有微服務的新實例須要啓動來知足負載增長。 這就意味着服務比以前的來回訪問要更頻繁些。
• 平均故障間隔時間(MTBF)會下降, 例如系統領域的失敗發生的頻率仍是比較高的: 軟件組件有時會出錯。 對於有大量小的部署單元的系統來講，系統領域中的部分失敗的機率會增大，相對於只使用一些大的單體應用程序的機率來講。

問題

這樣會致使一些重要的以及在新運行環境中引起的新問題:

• 咱們全部的微服務如何配置以及這樣是否正確? 處理配置對於一些應用程序來講，不是主要問題， 例如，每一個應用程序在磁盤中的屬性文件或本身的數據庫中的配置表來存儲它本身的配置。在多個服務器爲大量微服務部署多個實例，這種方式中管理變得更加複雜。致使大量小的配置文件/表遍及系統領域，使得很難有效維護，也很難有很好的質量。
• 咱們部署了什麼微服務，以及微服務部署在哪裏? 使用一些簡單的應用程序來跟蹤服務暴露的主機和端口號很是簡單，由於這些量少而且改變的概率也不大。使用大量獨立部署的微服務，在系統領域來看或多或少會有一些不斷變化的狀況，若是手動來處理這些可能會致使很難維護。
• 如何讓路由信息保持不變？對於在動態系統領域中的服務消費者可能有挑戰。 具體來講若是所在路由表，例如反向代理或消費者配置文件須要手動更新。基本上來講沒有時間在或多或少處於不斷演化的微服務領域中手動編輯路由表來彈出新的host/port地址。交付時間太長，容易冒手工錯誤的風險，這樣會影響質量方面和/或無必要高的操做代價。
• 如何防止連鎖失敗? 既然微服務須要互相鏈接，須要特別注意系統領域中的連鎖失敗。例如，若是其餘一些微服務依賴的某個微服務失敗了，依賴的微服務也將失敗等等。若是處理不當，系統領域的大量部分都會由於單個失敗的微服務而受影響, 致使脆弱的系統領域。
• 如何驗證全部服務已啓動而且在運行中? 跟蹤少許應用的狀態相對容易，可是咱們如何驗證全部的微服務的健康以及準備接收請求?
• 如何跟蹤服務間的消息流? 若是支持組織開始抱怨一些失敗的處理怎麼辦? 如何找到相關的處理，例如，訂單號12345的處理被卡住，由於微服務A不可訪問或在微服務B能夠發送關於那個訂單的確認信息以前須要執行手工審批。
• 如何確保只有API服務是外部暴露的? 例如，如何避免來自外部到內部微服務的無受權訪問?
• 如何讓API服務安全? 不是關於微服務的新問題或特性問題，可是對於讓真正暴露外部的微服務安全來講依然很是重要。

必要組件

爲了解決這些問題的大部分，須要在沒必要要的系統景觀中加入必要操做和管理功能, 或者至少在必定程度上，當只操做幾個應用的時候。上述問題的建議解決方式包括下面的組件:

• 集中配置服務器: 代替每一個部署單元(例如微服務)的局部配置, 咱們須要集中化配置管理。 咱們也須要微服務能夠用於獲取配置信息的配置API。
• 服務發現服務器: 代替手工跟蹤當前發佈了什麼微服務，以及服務發現功能容許的host和port，經過API，微服務啓動時能夠自動註冊。
• 動態路由以及負載均衡: 給定的服務發現功能，路由組件可使用發現API來查找請求的微服務在哪裏部署以及負載均衡組件能夠決定將請求路由到哪一個實例，若是對於請求服務部署了多個實例的話。
• 斷路器: 爲了不連鎖失敗問題，咱們須要應用斷路器模式，要了解詳情能夠參考Release It!這本書或者Fowler的短路器文章。
• 監控: 鑑於咱們有就緒的斷路器，咱們能夠從它們身上開始監測它們的狀態以及蒐集運行時間統計來獲取系統領域以及當前使用的健康狀態。這些信息能夠收集並顯示在dashboard上，而且能夠經過配置的閥值來自動告警。
• 集中化日誌分析: 爲了可以跟蹤消息並監測它們什麼時候被卡住，咱們須要一個集中化日誌分析功能，它們能到達服務器而且蒐集每一個微服務產生的日誌文件。日誌分析功能將日誌信息保存在集中數據庫中，提供搜索和dashboard能力。 注意: 爲了可以查找相關消息，在日誌消息中使用相應的id對於全部微服務來講是很是重要的。
• 邊界服務器: 爲了對外暴露API並防止對內部微服務的未受權訪問，咱們須要一個邊際服務器，全部的外部流量都經過它。 邊際服務器能夠基於上面描述的服務發現組件來複用動態路由和負載均衡能力。邊際服務器將扮演一個動態的、活動的反向代理，每當內部系統領域改變的時候無需手工更新。

• OAuth 2.0保護的API: 爲了保護暴露的API服務，推薦使用OAuth 2.0標準。 將OAuth 2.0應用到建議的解決方案中:

  • 新組件能夠扮演OAuth受權服務器.
  • API服務將扮演OAuth資源服務器.
  • 外部API消費者將扮演OAuth客戶端.

  • 邊際服務器將扮演OAuth Token中繼，意思是:

    • 它將扮演OAuth資源服務器.
    • 它將傳遞來自外部請求帶來的OAuth Token給API服務.

注意: 隨着時間的推移，OAuth 2.0標準將最有可能與OpenID鏈接標準相補充，以提供改進的受權功能。

參考模型

總之，意味着微服務須要一系列上面描述的支持服務設施，微服務使用它們的API來交互。能夠經過下面的圖片可視化:

注意：爲了減小圖片中的複雜性，微服務和支持服務之間的交互是不可見的。

Next Step

在即將出現的博文中咱們會描述和演示建議的參考模型是如何實現的，能夠參考文章序列 - 構建微服務。

術語

• MTBF: 平均故障時間(Mean Time Between Failures).
• 連鎖失敗: chain of failures.

參考連接

• 微服務操做模型原文
• OAuth 2.0
• OpenID
• 專題首頁