引言：上篇文章介紹了微服務(wù)和單體架構(gòu)的區(qū)別、微服務(wù)的設(shè)計(jì)、消息、服務(wù)間通信、數(shù)據(jù)去中心化，本篇會(huì)繼續(xù)深入微服務(wù)，介紹其它特性。
治理去中心化
通常“治理”的意思是構(gòu)建方案，并且迫使人們通過努力達(dá)到組織的目標(biāo)。SOA治理指導(dǎo)開發(fā)者開發(fā)可重用的服務(wù)，以及隨著時(shí)間推移，服務(wù)應(yīng)該怎么被設(shè)計(jì)和開發(fā)。治理建立了服務(wù)提供者和消費(fèi)者之間對于服務(wù)的協(xié)定，告訴消費(fèi)者能從服務(wù)提供獲取到什么樣的支持。
SOA中有兩種常見的治理：
- 設(shè)計(jì)時(shí)的治理-定義和控制服務(wù)的創(chuàng)建、設(shè)計(jì)和服務(wù)策略的實(shí)施。
- 運(yùn)行時(shí)的治理-確保執(zhí)行過程的策略。
那么微服務(wù)中的治理是什么意思呢？
在微服務(wù)架構(gòu)中，不同的微服務(wù)之間相互獨(dú)立，并且基于不同的平臺(tái)和技術(shù)。因此，沒有必要為服務(wù)的設(shè)計(jì)和開發(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ù)注冊和發(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ù)注冊
注冊中心有微服務(wù)的實(shí)例和位置信息，微服務(wù)在啟動(dòng)時(shí)向注冊中心注冊自己的信息，關(guān)閉時(shí)注銷。其它使用者能夠通過注冊中心找到可用的微服務(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)通過查詢服務(wù)注冊中心或者服務(wù)的位置信息。
圖9 客戶端發(fā)現(xiàn)
客戶端/API網(wǎng)關(guān)必須調(diào)用服務(wù)注冊中心組件，實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)的邏輯。
服務(wù)端發(fā)現(xiàn) - 客戶端/API網(wǎng)關(guān)把請求發(fā)送到已知位置信息的組件(比如負(fù)載均衡器)。組件去訪問注冊中心，找到微服務(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ù)比其他的請求量大)
- 快速構(gòu)建和發(fā)布
- 微服務(wù)之間的功能不相互影響
Docker(一個(gè)運(yùn)行在linux上并且開源的應(yīng)用，能夠協(xié)助開發(fā)和運(yùn)維把應(yīng)用運(yùn)行在容器中)能夠快速部署微服務(wù)，包括關(guān)鍵幾點(diǎn)：
- 把微服務(wù)打包成Docker鏡像
- 啟動(dòng)容器實(shí)例
- 改變實(shí)例的數(shù)量達(dá)到擴(kuò)容需求
相對于傳統(tǒng)的虛擬機(jī)模式，利用docker容器，構(gòu)建、發(fā)布、啟動(dòng)微服務(wù)將會(huì)變得十分快捷。
通過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è)容器，通過kubernetes可以隨意調(diào)整容器的數(shù)量。
安全
在實(shí)際運(yùn)行環(huán)境中，微服務(wù)的安全也非常重要。我們先看下單體架構(gòu)下安全是如何實(shí)現(xiàn)的。
一個(gè)典型的單體應(yīng)用，安全問題主要是“誰調(diào)用”，“調(diào)用者能做什么”，“如何處理”。服務(wù)器接收到請求后，一般都在處理鏈條的最開始，通過安全組件來對請求的信息進(jìn)行安全處理。
我們能直接把這種處理方式應(yīng)用在微服務(wù)架構(gòu)中嗎？答案是可以的，需要買個(gè)微服務(wù)都實(shí)現(xiàn)一個(gè)安全組件從資源中心獲取對應(yīng)的用戶信息，實(shí)現(xiàn)安全控制。這是比較初級(jí)的處理方式�？梢試L試采用一些標(biāo)準(zhǔn)的API方式，比如OAuth2和OpenID。深入研究之前，可以先概括下這兩種安全協(xié)議以及如何使用。
OAuth2-是一個(gè)訪問委托協(xié)議。需要獲得權(quán)限的客戶端，向授權(quán)服務(wù)申請一個(gè)訪問令牌。訪問令牌沒有任何關(guān)于用戶/客戶端的信息，僅僅是一個(gè)給授權(quán)服務(wù)器使用的用戶引用信息。因此，這個(gè)“引用的令牌”也沒有安全問題。
OpenID類似于OAuth，不過除了訪問令牌以外，授權(quán)服務(wù)器還會(huì)頒發(fā)一個(gè)ID令牌，包含用戶信息。通常由授權(quán)服務(wù)器以JWT(JSON Web Token)的方式實(shí)現(xiàn)。通過這種方式確�？蛻艉头⻊�(wù)器端的互信。JWT令牌是一種“有內(nèi)容的令牌”，包含用戶的身份信息，在公共環(huán)境中使用不安全。
現(xiàn)在我們看下如何在網(wǎng)絡(luò)零售網(wǎng)站中應(yīng)用這些協(xié)議保障微服務(wù)的安全。
圖12 通過OAuth2和OpenID解決安全問題
圖12中所示，是實(shí)現(xiàn)微服務(wù)安全的關(guān)鍵幾步：
- 所有的授權(quán)由授權(quán)服務(wù)器，通過OAuth和OpenID方式實(shí)現(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包含必要的用戶信息，如果每個(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é)。某些場景下，必須要跨越服務(wù)支持分布式事務(wù)，可以在每個(gè)微服務(wù)內(nèi)部利用“組合操作”。
最關(guān)鍵的事情是，基于單職責(zé)原則設(shè)計(jì)微服務(wù)，如果某個(gè)服務(wù)不能正常執(zhí)行某些操作，那么這個(gè)服務(wù)是有問題的。那么上游的操作，都需要在各自的微服務(wù)中執(zhí)行回滾操作。
容錯(cuò)設(shè)計(jì)
微服務(wù)架構(gòu)相比較單體的設(shè)計(jì)而言，引入了更多服務(wù)，在每個(gè)服務(wù)級(jí)別會(huì)增加發(fā)生錯(cuò)誤的可能性。一個(gè)服務(wù)可能由于網(wǎng)絡(luò)問題、底層資源等各種問題導(dǎo)致失敗。某個(gè)服務(wù)的不可能不應(yīng)該影響整個(gè)應(yīng)用的崩潰。因此，微服務(wù)系統(tǒng)必須容錯(cuò)，甚至自動(dòng)回復(fù)，對客戶端無感知。
任何服務(wù)在任何時(shí)間都有可能出問題，監(jiān)控系統(tǒng)需要能夠發(fā)現(xiàn)問題，并且自動(dòng)恢復(fù)。微服務(wù)環(huán)境下有不少常用的模式。
線路中斷
微服務(wù)中請求的失敗率達(dá)到一定程度后，系統(tǒng)中的監(jiān)控可以激活線路中斷。當(dāng)正常請求的數(shù)量恢復(fù)到一定程度后，再關(guān)閉線路中斷的開關(guān)，使系統(tǒng)回復(fù)到正常狀態(tài)。
這個(gè)模式可以避免不必要的資源消耗，請求的處理延遲會(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ù)不可用或者沒有回復(fù)時(shí)，網(wǎng)關(guān)能夠決定是否執(zhí)行線路中斷或者啟動(dòng)超時(shí)機(jī)制。防火墻機(jī)制同樣重要，網(wǎng)關(guān)是所有請求的唯一入口，一個(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ù)不是解決所有問題的靈丹妙藥。盲目追求流行的技術(shù)概念并不能解決掉企業(yè)IT系統(tǒng)的問題。
微服務(wù)有很多優(yōu)勢，但是僅靠微服務(wù)不能解決企業(yè)IT中的所有問題。例如，微服務(wù)需要去除ESB，但是現(xiàn)實(shí)的IT系統(tǒng)中，大量的應(yīng)用和服務(wù)是基于ESB而不是微服務(wù)。集成現(xiàn)有的系統(tǒng)，需要一些集成總線。實(shí)際情況是，微服務(wù)和其它企業(yè)架構(gòu)并存。
核心關(guān)注：拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標(biāo)題：微服務(wù)實(shí)戰(zhàn)：從架構(gòu)到發(fā)布（二）
本文網(wǎng)址：http://www.ezxoed.cn/html/solutions/14019319972.html
相關(guān)文章
