引言：上篇文章介紹了微服務和單體架構的區(qū)別、微服務的設計、消息、服務間通信、數據去中心化，本篇會繼續(xù)深入微服務，介紹其它特性。

治理去中心化

通常“治理”的意思是構建方案，并且迫使人們通過努力達到組織的目標。SOA治理指導開發(fā)者開發(fā)可重用的服務，以及隨著時間推移，服務應該怎么被設計和開發(fā)。治理建立了服務提供者和消費者之間對于服務的協(xié)定，告訴消費者能從服務提供獲取到什么樣的支持。

SOA中有兩種常見的治理：

• 設計時的治理-定義和控制服務的創(chuàng)建、設計和服務策略的實施。
• 運行時的治理-確保執(zhí)行過程的策略。

那么微服務中的治理是什么意思呢?

在微服務架構中，不同的微服務之間相互獨立，并且基于不同的平臺和技術。因此，沒有必要為服務的設計和開發(fā)定義一個通用的標準。

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

• 微服務架構，在設計時不需要集中考慮治理。
• 每個微服務可以有獨立的設計、執(zhí)行決策。
• 微服務架構著重培養(yǎng)通用/可重用的服務。
• 運行時的治理，比如安全級別保證(SLA)，限制，監(jiān)控，安全和服務發(fā)現，可以在API網關層處理。

服務注冊和發(fā)現

微服務架構下，有大量的微服務需要處理。由于微服務的快速和敏捷研發(fā)，他們的位置可能會動態(tài)變化。因此在運行時需要能夠發(fā)現服務所在的位置，服務發(fā)現可以解決這個問題。

服務注冊

注冊中心有微服務的實例和位置信息，微服務在啟動時向注冊中心注冊自己的信息，關閉時注銷。其它使用者能夠通過注冊中心找到可用的微服務和相關信息。

服務發(fā)現

為了能找到可用的服務和他們的位置信息，需要服務發(fā)現機制。有兩種發(fā)現機制，客戶端發(fā)現和服務端發(fā)現。

客戶端發(fā)現 - 客戶端或者API網關通過查詢服務注冊中心或者服務的位置信息。

 

圖9：客戶端發(fā)現

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

服務端發(fā)現 - 客戶端/API網關把請求發(fā)送到已知位置信息的組件(比如負載均衡器)。組件去訪問注冊中心，找到微服務的位置信息。

 

圖10：服務端發(fā)現

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

部署

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

• 能夠獨立于其他微服務發(fā)布或者取消發(fā)布
• 微服務可以水平擴展(某一個服務比其他的請求量大)
• 快速構建和發(fā)布
• 微服務之間的功能不相互影響

Docker(一個運行在linux上并且開源的應用，能夠協(xié)助開發(fā)和運維把應用運行在容器中)能夠快速部署微服務，包括關鍵幾點：

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

相對于傳統(tǒng)的虛擬機模式，利用docker容器，構建、發(fā)布、啟動微服務將會變得十分快捷。

通過Kubernetes能夠進一步擴展Docker的能力，能夠從單個linux主機擴展到linux集群，支持多主機，管理容器位置，服務發(fā)現，多實例。都是微服務需求的重要特性。因此，利用Kubernetes管理微服務和容器的發(fā)布，是一個非常有力的方案。

 

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

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

安全

在實際運行環(huán)境中，微服務的安全也非常重要。我們先看下單體架構下安全是如何實現的。

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

我們能直接把這種處理方式應用在微服務架構中嗎?答案是可以的，需要買個微服務都實現一個安全組件從資源中心獲取對應的用戶信息，實現安全控制。這是比較初級的處理方式。可以嘗試采用一些標準的API方式，比如OAuth2和OpenID。深入研究之前，可以先概括下這兩種安全協(xié)議以及如何使用。

OAuth2-是一個訪問委托協(xié)議。需要獲得權限的客戶端，向授權服務申請一個訪問令牌。訪問令牌沒有任何關于用戶/客戶端的信息，僅僅是一個給授權服務器使用的用戶引用信息。因此，這個“引用的令牌”也沒有安全問題。

OpenID類似于OAuth，不過除了訪問令牌以外，授權服務器還會頒發(fā)一個ID令牌，包含用戶信息。通常由授權服務器以JWT(JSON Web Token)的方式實現。通過這種方式確保客戶和服務器端的互信。JWT令牌是一種“有內容的令牌”，包含用戶的身份信息，在公共環(huán)境中使用不安全。

現在我們看下如何在網絡零售網站中應用這些協(xié)議保障微服務的安全。

 

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

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

• 所有的授權由授權服務器，通過OAuth和OpenID方式實現，確保用戶能訪問到正確的數據。
• 采用API網關方式，所有的客戶端請求有***入口。
• 客戶端通過授權服務器獲得訪問令牌，把令牌發(fā)送到API網關。
• 令牌在網關的處理 - API網關得到令牌后，發(fā)送到授權服務器獲得JWT。
• 網關把JWT和請求一起發(fā)送到微服務中。

JWT包含必要的用戶信息，如果每個微服務都能夠解析JWT，那么你的系統(tǒng)中每個服務都能處理身份相關的業(yè)務。在每個微服務中，可以有一個處理JWT的輕量級的組件。

事務

在微服務中怎么支持事務呢?事實上，跨多個微服務的分布式事務支持非常復雜，微服務的設計思路是盡量避免多個服務之間的事務操作。

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

最關鍵的事情是，基于單職責原則設計微服務，如果某個服務不能正常執(zhí)行某些操作，那么這個服務是有問題的。那么上游的操作，都需要在各自的微服務中執(zhí)行回滾操作。

容錯設計

微服務架構相比較單體的設計而言，引入了更多服務，在每個服務級別會增加發(fā)生錯誤的可能性。一個服務可能由于網絡問題、底層資源等各種問題導致失敗。某個服務的不可能不應該影響整個應用的崩潰。因此，微服務系統(tǒng)必須容錯，甚至自動回復，對客戶端無感知。

任何服務在任何時間都有可能出問題，監(jiān)控系統(tǒng)需要能夠發(fā)現問題，并且自動恢復。微服務環(huán)境下有不少常用的模式。

線路中斷

微服務中請求的失敗率達到一定程度后，系統(tǒng)中的監(jiān)控可以激活線路中斷。當正常請求的數量恢復到一定程度后，再關閉線路中斷的開關，使系統(tǒng)回復到正常狀態(tài)。

這個模式可以避免不必要的資源消耗，請求的處理延遲會導致超時，借此可以把監(jiān)控系統(tǒng)做的更完善。

防火墻

一個應用會有很多微服務租車，單個微服務的失敗不應該影響整個系統(tǒng)。防火墻模式強調服務直接的隔離性，微服務不會受到其它微服務失敗的影響。

處理超時

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

哪些情況下，如何使用這些模式呢?大多數情況，都應該在網關處理。當微服務不可用或者沒有回復時，網關能夠決定是否執(zhí)行線路中斷或者啟動超時機制。防火墻機制同樣重要，網關是所有請求的***入口，一個微服務的失敗不應該影響到其它微服務。網關也是獲得微服務狀態(tài)、監(jiān)控信息的中心。

微服務，企業(yè)集成，API管理

我們已經討論了微服務的架構和各種特性，以及如何應用在一個現代的IT系統(tǒng)中。同時也需要意識到，微服務不是解決所有問題的靈丹妙藥。盲目追求流行的技術概念并不能解決掉企業(yè)IT系統(tǒng)的問題。

微服務有很多優(yōu)勢，但是僅靠微服務不能解決企業(yè)IT中的所有問題。例如，微服務需要去除ESB，但是現實的IT系統(tǒng)中，大量的應用和服務是基于ESB而不是微服務。集成現有的系統(tǒng)，需要一些集成總線。實際情況是，微服務和其它企業(yè)架構并存。

微服務實戰(zhàn)：從架構到發(fā)布（一）

原文作者：Kasun Indrasiri，軟件架構師，WSO2

原文鏈接：https://dzone.com/articles/microservices-in-practice-1

翻譯自MaxLeap團隊_云服務研發(fā)成員：Frank Qin

關于MaxLeap

MaxLeap移動云服務平臺為企業(yè)提供一站式的移動研發(fā)和運營云服務，幫助企業(yè)快速研發(fā)和上線移動應用，平臺提供數據云存儲，云引擎，支付管理，IM，數據分析和營銷自動化等服務。

官網鏈接：https://maxleap.cn