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

治理去中心化

通常“治理”的意思是構(gòu)建方案，并且迫使人們通過(guò)努力達(dá)到組織的目標(biāo)。SOA治理指導(dǎo)開(kāi)發(fā)者開(kāi)發(fā)可重用的服務(wù)，以及隨著時(shí)間推移，服務(wù)應(yīng)該怎么被設(shè)計(jì)和開(kāi)發(fā)。治理建立了服務(wù)提供者和消費(fèi)者之間對(duì)于服務(wù)的協(xié)定，告訴消費(fèi)者能從服務(wù)提供獲取到什么樣的支持。

SOA中有兩種常見(jiàn)的治理：

• 設(shè)計(jì)時(shí)的治理-定義和控制服務(wù)的創(chuàng)建、設(shè)計(jì)和服務(wù)策略的實(shí)施。
• 運(yùn)行時(shí)的治理-確保執(zhí)行過(guò)程的策略。

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

在微服務(wù)架構(gòu)中，不同的微服務(wù)之間相互獨(dú)立，并且基于不同的平臺(tái)和技術(shù)。因此，沒(méi)有必要為服務(wù)的設(shè)計(jì)和開(kāi)發(fā)定義一個(gè)通用的標(biāo)準(zhǔn)。

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

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

服務(wù)注冊(cè)和發(fā)現(xiàn)

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

服務(wù)注冊(cè)

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

服務(wù)發(fā)現(xiàn)

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

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

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

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

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

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

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

部署

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

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

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

• 把微服務(wù)打包成Docker鏡像
• 啟動(dòng)容器實(shí)例
• 改變實(shí)例的數(shù)量達(dá)到擴(kuò)容需求

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

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

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

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

安全

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

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

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

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

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

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

圖12：通過(guò)OAuth2和OpenID解決安全問(wèn)題

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

• 所有的授權(quán)由授權(quán)服務(wù)器，通過(guò)OAuth和OpenID方式實(shí)現(xiàn)，確保用戶能訪問(wèn)到正確的數(shù)據(jù)。
• 采用API網(wǎng)關(guān)方式，所有的客戶端請(qǐng)求有***入口。
• 客戶端通過(guò)授權(quán)服務(wù)器獲得訪問(wèn)令牌，把令牌發(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和請(qǐng)求一起發(fā)送到微服務(wù)中。

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

事務(wù)

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

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

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

容錯(cuò)設(shè)計(jì)

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

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

線路中斷

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

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

防火墻

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

處理超時(shí)

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

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

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

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

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

微服務(wù)實(shí)戰(zhàn)：從架構(gòu)到發(fā)布（一）

原文作者：Kasun Indrasiri，軟件架構(gòu)師，WSO2

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

翻譯自MaxLeap團(tuán)隊(duì)_云服務(wù)研發(fā)成員：Frank Qin

關(guān)于MaxLeap

MaxLeap移動(dòng)云服務(wù)平臺(tái)為企業(yè)提供一站式的移動(dòng)研發(fā)和運(yùn)營(yíng)云服務(wù)，幫助企業(yè)快速研發(fā)和上線移動(dòng)應(yīng)用，平臺(tái)提供數(shù)據(jù)云存儲(chǔ)，云引擎，支付管理，IM，數(shù)據(jù)分析和營(yíng)銷自動(dòng)化等服務(wù)。

官網(wǎng)鏈接：https://maxleap.cn