摘要：微服務(wù)架構(gòu)著重培養(yǎng)通用可重用的服務(wù)。服務(wù)注冊和發(fā)現(xiàn)微服務(wù)架構(gòu)下，有大量的微服務(wù)需要處理。網(wǎng)關(guān)也是獲得微服務(wù)狀態(tài)監(jiān)控信息的中心。實際情況是，微服務(wù)和其它企業(yè)架構(gòu)并存。

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

通?！爸卫怼钡囊馑际菢?gòu)建方案，并且迫使人們通過努力達到組織的目標。SOA治理指導(dǎo)開發(fā)者開發(fā)可重用的服務(wù)，以及隨著時間推移，服務(wù)應(yīng)該怎么被設(shè)計和開發(fā)。治理建立了服務(wù)提供者和消費者之間對于服務(wù)的協(xié)定，告訴消費者能從服務(wù)提供獲取到什么樣的支持。

SOA中有兩種常見的治理：

設(shè)計時的治理-定義和控制服務(wù)的創(chuàng)建、設(shè)計和服務(wù)策略的實施。

運行時的治理-確保執(zhí)行過程的策略。

那么微服務(wù)中的治理是什么意思呢？

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

總結(jié)微服務(wù)的治理去中心化如下：

微服務(wù)架構(gòu)，在設(shè)計時不需要集中考慮治理。

每個微服務(wù)可以有獨立的設(shè)計、執(zhí)行決策。

微服務(wù)架構(gòu)著重培養(yǎng)通用/可重用的服務(wù)。

運行時的治理，比如安全級別保證（SLA），限制，監(jiān)控，安全和服務(wù)發(fā)現(xiàn)，可以在API網(wǎng)關(guān)層處理。

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

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

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

客戶端發(fā)現(xiàn) - 客戶端或者API網(wǎng)關(guān)通過查詢服務(wù)注冊中心或者服務(wù)的位置信息。

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

客戶端/API網(wǎng)關(guān)必須調(diào)用服務(wù)注冊中心組件，實現(xiàn)服務(wù)發(fā)現(xiàn)的邏輯。

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

圖10：服務(wù)端發(fā)現(xiàn)

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

微服務(wù)的部署方式也特別重要，以下是關(guān)鍵：

能夠獨立于其他微服務(wù)發(fā)布或者取消發(fā)布

微服務(wù)可以水平擴展（某一個服務(wù)比其他的請求量大）

快速構(gòu)建和發(fā)布

微服務(wù)之間的功能不相互影響

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

把微服務(wù)打包成Docker鏡像

啟動容器實例

改變實例的數(shù)量達到擴容需求

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

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

圖11：構(gòu)建和部署服務(wù)的容器

圖11，展示了零售應(yīng)用的微服務(wù)部署。每個服務(wù)都在獨立的容器中，每個主機有兩個容器，通過kubernetes可以隨意調(diào)整容器的數(shù)量。

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

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

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

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

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

現(xiàn)在我們看下如何在網(wǎng)絡(luò)零售網(wǎng)站中應(yīng)用這些協(xié)議保障微服務(wù)的安全。

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

圖12中所示，是實現(xiàn)微服務(wù)安全的關(guān)鍵幾步：

所有的授權(quán)由授權(quán)服務(wù)器，通過OAuth和OpenID方式實現(xiàn)，確保用戶能訪問到正確的數(shù)據(jù)。

采用API網(wǎng)關(guān)方式，所有的客戶端請求有唯一入口。

客戶端通過授權(quán)服務(wù)器獲得訪問令牌，把令牌發(fā)送到API網(wǎng)關(guān)。

令牌在網(wǎng)關(guān)的處理 - API網(wǎng)關(guān)得到令牌后，發(fā)送到授權(quán)服務(wù)器獲得JWT。

網(wǎng)關(guān)把JWT和請求一起發(fā)送到微服務(wù)中。

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

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

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

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

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

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

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

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

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

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

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

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

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

原文作者：Kasun Indrasiri，軟件架構(gòu)師，WSO2
原文鏈接：https://dzone.com/articles/microservices-in-practice-1
翻譯自MaxLeap團隊_云服務(wù)研發(fā)成員：Frank Qin
關(guān)于MaxLeap
MaxLeap移動云服務(wù)平臺為企業(yè)提供一站式的移動研發(fā)和運營云服務(wù)，幫助企業(yè)快速研發(fā)和上線移動應(yīng)用，平臺提供數(shù)據(jù)云存儲，云引擎，支付管理，IM，數(shù)據(jù)分析和營銷自動化等服務(wù)。
官網(wǎng)鏈接：https://maxleap.cn