微服務實戰：從架構到發佈2

治理去中心化

 

一般「治理」的意思是構建方案，而且迫令人們經過努力達到組織的目標。SOA治理指導開發者開發可重用的服務，以及隨着時間推移，服務應該怎麼被設計和開發。治理創建了服務提供者和消費者之間對於服務的協定，告訴消費者能從服務提供獲取到什麼樣的支持。

 

SOA中有兩種常見的治理：

 

• 設計時的治理-定義和控制服務的建立、設計和服務策略的實施。
• 運行時的治理-確保執行過程的策略。

 

那麼微服務中的治理是什麼意思呢？

 

 

在微服務架構中，不一樣的微服務之間相互獨立，而且基於不一樣的平臺和技術。所以，沒有必要爲服務的設計和開發定義一個通用的標準。

 

 

總結微服務的治理去中心化以下：

 

• 微服務架構，在設計時不須要集中考慮治理。
• 每一個微服務能夠有獨立的設計、執行決策。
• 微服務架構着重培養通用/可重用的服務。
• 運行時的治理，好比安全級別保證（SLA），限制，監控，安全和服務發現，能夠在API網關層處理。

服務註冊和發現

 

微服務架構下，有大量的微服務須要處理。因爲微服務的快速和敏捷研發，他們的位置可能會動態變化。所以在運行時須要可以發現服務所在的位置，服務發現能夠解決這個問題。

服務註冊

 

註冊中心有微服務的實例和位置信息，微服務在啓動時向註冊中心註冊本身的信息，關閉時註銷。其它使用者可以經過註冊中心找到可用的微服務和相關信息。

服務發現

 

爲了能找到可用的服務和他們的位置信息，須要服務發現機制。有兩種發現機制，客戶端發現和服務端發現。

 

客戶端發現 – 客戶端或者API網關經過查詢服務註冊中心或者服務的位置信息。

 

圖9：客戶端發現

 

客戶端/API網關必須調用服務註冊中心組件，實現服務發現的邏輯。

 

服務端發現 – 客戶端/API網關把請求發送到已知位置信息的組件（好比負載均衡器）。組件去訪問註冊中心，找到微服務的位置信息。

 

圖10：服務端發現

 

相似Kubernetes（ http://kubernetes.io/v1.1/docs/user-guide/services.html ）這種微服務部署解決方案，就提供了服務器端的自動發現機制。

部署

 

微服務的部署方式也特別重要，如下是關鍵：

 

• 可以獨立於其餘微服務發佈或者取消發佈
• 微服務能夠水平擴展（某一個服務比其餘的請求量大）
• 快速構建和發佈
• 微服務之間的功能不相互影響

 

Docker（一個運行在linux上而且開源的應用，可以協助開發和運維把應用運行在容器中）可以快速部署微服務，包括關鍵幾點：

 

• 把微服務打包成Docker鏡像
• 啓動容器實例
• 改變實例的數量達到擴容需求

 

相對於傳統的虛擬機模式，利用docker容器，構建、發佈、啓動微服務將會變得十分快捷。

 

經過Kubernetes可以進一步擴展Docker的能力，可以從單個linux主機擴展到linux集羣，支持多主機，管理容器位置，服務發現，多實例。都是微服務需求的重要特性。所以，利用Kubernetes管理微服務和容器的發佈，是一個很是有力的方案。

 

圖11：構建和部署服務的容器

 

圖11，展現了零售應用的微服務部署。每一個服務都在獨立的容器中，每一個主機有兩個容器，經過kubernetes能夠隨意調整容器的數量。

安全

 

在實際運行環境中，微服務的安全也很是重要。咱們先看下單體架構下安全是如何實現的。

 

一個典型的單體應用，安全問題主要是「誰調用」，「調用者能作什麼」，「如何處理」。服務器接收到請求後，通常都在處理鏈條的最開始，經過安全組件來對請求的信息進行安全處理。

 

咱們能直接把這種處理方式應用在微服務架構中嗎？答案是能夠的，須要買個微服務都實現一個安全組件從資源中心獲取對應的用戶信息，實現安全控制。這是比較初級的處理方式。能夠嘗試採用一些標準的API方式，好比OAuth2和OpenID。深刻研究以前，能夠先歸納下這兩種安全協議以及如何使用。

 

OAuth2-是一個訪問委託協議。須要得到權限的客戶端，向受權服務申請一個訪問令牌。訪問令牌沒有任何關於用戶/客戶端的信息，僅僅是一個給受權服務器使用的用戶引用信息。所以，這個「引用的令牌」也沒有安全問題。

 

OpenID相似於OAuth，不過除了訪問令牌之外，受權服務器還會頒發一個ID令牌，包含用戶信息。一般由受權服務器以JWT（JSON Web Token）的方式實現。經過這種方式確保客戶和服務器端的互信。JWT令牌是一種「有內容的令牌」，包含用戶的身份信息，在公共環境中使用不安全。

 

如今咱們看下如何在網絡零售網站中應用這些協議保障微服務的安全。

 

圖12：經過OAuth2和OpenID解決安全問題

 

圖12中所示，是實現微服務安全的關鍵幾步：

 

• 全部的受權由受權服務器，經過OAuth和OpenID方式實現，確保用戶能訪問到正確的數據。
• 採用API網關方式，全部的客戶端請求有惟一入口。
• 客戶端經過受權服務器得到訪問令牌，把令牌發送到API網關。
• 令牌在網關的處理 – API網關獲得令牌後，發送到受權服務器得到JWT。
• 網關把JWT和請求一塊兒發送到微服務中。

 

JWT包含必要的用戶信息，若是每一個微服務都可以解析JWT，那麼你的系統中每一個服務都能處理身份相關的業務。在每一個微服務中，能夠有一個處理JWT的輕量級的組件。

事務

 

在微服務中怎麼支持事務呢？事實上，跨多個微服務的分佈式事務支持很是複雜，微服務的設計思路是儘可能避免多個服務之間的事務操做。

 

解決辦法是微服務的設計須要遵循功能自包含和單職責原則。跨越多個微服務支持分佈式事務在微服務架構中不是一個好的設計思路，一般須要從新劃定微服務的職責。某些場景下，必需要跨越服務支持分佈式事務，能夠在每一個微服務內部利用「組合操做」。

 

最關鍵的事情是，基於單職責原則設計微服務，若是某個服務不能正常執行某些操做，那麼這個服務是有問題的。那麼上游的操做，都須要在各自的微服務中執行回滾操做。

 

容錯設計

 

微服務架構相比較單體的設計而言，引入了更多服務，在每一個服務級別會增長髮生錯誤的可能性。一個服務可能因爲網絡問題、底層資源等各類問題致使失敗。某個服務的不可能不該該影響整個應用的崩潰。所以，微服務系統必須容錯，甚至自動回覆，對客戶端無感知。

 

任何服務在任什麼時候間都有可能出問題，監控系統須要可以發現問題，而且自動恢復。微服務環境下有很多經常使用的模式。

 

線路中斷

 

微服務中請求的失敗率達到必定程度後，系統中的監控能夠激活線路中斷。當正常請求的數量恢復到必定程度後，再關閉線路中斷的開關，使系統回覆到正常狀態。

 

這個模式能夠避免沒必要要的資源消耗，請求的處理延遲會致使超時，藉此能夠把監控系統作的更完善。

防火牆

 

 一個應用會有不少微服務租車，單個微服務的失敗不該該影響整個系統。防火牆模式強調服務直接的隔離性，微服務不會受到其它微服務失敗的影響。

處理超時

 

超時機制是在肯定不會再有應答的狀況下，主動放棄等待微服務的響應。這種超時應該是可配置的。

 

哪些狀況下，如何使用這些模式呢？大多數狀況，都應該在網關處理。當微服務不可用或者沒有回覆時，網關可以決定是否執行線路中斷或者啓動超時機制。防火牆機制一樣重要，網關是全部請求的惟一入口，一個微服務的失敗不該該影響到其它微服務。網關也是得到微服務狀態、監控信息的中心。

微服務，企業集成，API管理

 

咱們已經討論了微服務的架構和各類特性，以及如何應用在一個現代的IT系統中。同時也須要意識到，微服務不是解決全部問題的靈丹妙藥。盲目追求流行的技術概念並不能解決掉企業IT系統的問題。

 

微服務有不少優點，可是僅靠微服務不能解決企業IT中的全部問題。例如，微服務須要去除ESB，可是現實的IT系統中，大量的應用和服務是基於ESB而不是微服務。集成現有的系統，須要一些集成總線。實際狀況是，微服務和其它企業架構並存。