《詳解微服務實踐 從架構到部署》要點：
本文介紹了詳解微服務實踐 從架構到部署，希望對您有用。如果有疑問，可以聯系我們。

前言：

前段時間公司事情多,這篇長文寫了放、放了寫…耽擱了一些進度.各個自媒體的更新也慢了很多,這里給大家說句抱歉了.

現如今“微服務”遍地開花,已經成軟件架構領域最受歡迎的熱門話題之一.網上和書籍中都有很多關于微服務基礎和優勢的學習材料,但是我們可能會發現這東西在現實世界企業場景中似乎好像沒那么普及,真正能跑的微服務資源其實也不是很多,大多是停留在概念和摸索階段.

在這篇文章里,我打算講講微服務架構(MSA)的關鍵架構概念,以及如何在實踐中將這些架構原理應用起來.

前因：單片結構

企業應用,因為服務于眾多業務需求,因此會有些特定的軟件應用提供許多功能,而一般慣例是把這些功能都堆在單個單片應用中.例如,ERP,CRM和其他各種軟件系統被規劃構建為具有數百個功能的整體.這種帶坑應用一經部署,在往后的故障排除、擴展和升級場景中就是一場接一場的惡夢了.

面向服務架構(SOA)旨在通過引入“服務”的概念來克服以上的限制,“服務”是從應用程序提供的類似功能中提取出來的聚合和分組.因此,使用SOA,軟件應用程序就會被設計為“粗粒度”服務的組合.然而,SOA中服務的范圍非常廣泛,這又引出了復雜而龐大的服務與一大堆操作(功能)以及復雜無比的消息格式和標準(如WS *標準).

多數情況下,SOA中的服務彼此獨立,只不過它們與所有其他服務一起部署在相同的運行時間里(只需考慮將部署到同一個Tomcat實例中的多個Web應用).和單片軟件應用類似,這些服務通過積累各種功而具有隨時間推移的習慣.圖1是一個非常好的一個單片架構的例子,顯示了包括多個服務的零售軟件應用,所有這些服務都能部署到同一應用程序.

說了那么多,大家是不是有點不明所以?我總結了一些重點,以下就是基于單片架構的應用程序的一些特性歸納：

• 單片應用程序被設計、開發和部署為單個單元.
• 單片應用相對復雜,導致維護,升級和新特性困難重重.
• 難以用單片架構來實踐敏捷開發和交付方法.
• 想更新某部分,很可能要重新部署整個應用.
• 規模需求沖突的情況下,若想做單點擴展,要做好多倍資源甚至推倒重來的準備(例如,想給A服務更多CPU,B服務可能要重做,也可能要補兩三倍memory)
• 可靠性：一個不穩定的服務可以拖慢整個應用性能.
• 難創新：采用新技術和框架非常困難,因為所有的功能必須建立在均勻的技術/框架上.

單片架構的天然特性,直接給微服務架構的異軍突起帶來了絕佳的機會.

后果：微服務架構

微服務架構(MSA)的基礎是將單片應用作為一套小型和獨立服務來開發,這些服務都在自己的空間獨立開發、部署和運行.在微服務體系結構的大多數定義中,它普遍被解釋為將巨大的可用服務隔離成一套獨立服務的過程.不過我對這些有自己的理解,微服務的邏輯不僅是將整個大容量服務分為獨立服務,關鍵在于通過查看從整體提供的功能,我們就可以確定所需的業務能力.而這些業務能力可以具體實現為各自獨立的細粒度和自包含(微)服務.它們可能在一個技術堆棧上實現,每個服務都處理一個非常具體和有限的業務范圍.

因此,上面解釋的在線零售系統場景可以通過如圖2的微服務架構實現.通過微服務架構,零售軟件應用程序被規整為一套微服務.而且從圖2最底下一層可以看出,根據業務需求,還多了一個從原始服務組合中額外創建的一個微服務.換句話說,想跟進微服務,要有超大容量服務可能會分裂的準備,不過我相信相比于進步,這點麻煩值得付出.

所以,鋪墊了那么多,現在我們深入了解微服務的關鍵架構原理,這里重要的是最好帶著實踐的思路來思考問題.

設計微服務：大小,范圍和功能

通過Microservices Architecture可以從頭開始構建軟件應用或改造現有應用程序/服務…無論是哪種方法,正確判定Microservices的大小,范圍和功能,都至關重要.我感覺,這可能是在Microservices Architecture實踐最初(對的,“最初”這個詞用的沒錯)最難的事了.

現在聊聊關于微服務的規模、范圍和功能的關鍵實踐問題和對一些坊間誤解的辟謠.

1. 代碼行數/團隊規模都是坑B指標：這里先引入一個概念,雙披薩團隊,有興趣的可以去深入了解.根據實施代碼或團隊規模,有幾個討論決定了Microservices的大小.然而,這些被認為是非常不切實際和糟糕的指標,即便我們仍然可以使用較少的代碼/雙比薩團隊做規模開發,但這種思路完全違反了微服務架構主體.
2. ‘Micro’有點誤導性的詞語：大多數開發人員傾向于認為他們應盡可能的減少服務,這是一個天然的誤解.
3. 在SOA上下文中,服務通常被實現為具有數十個操作/功能的單片全局.所以,像SOA這樣的服務就算命名為微服務,不會給你帶來微服務架構的好處.

那么那么我們應該如何在微服務架構中正確設計服務?

微服務設計指南

1. 單一責任原則(SRP)：為微服務提供有限和重點突出的業務范圍,有助于我們滿足開發和提供服務的敏捷性.
2. 在微服務的設計階段,我們應該找到各服務的邊界,并將其與業務能力(也稱為域驅動設計中的有界環境 )保持一致.
3. 微服務設計要確保敏捷/獨立開發和部署服務的絲滑穩定.
4. 我們的重點應該放在微服務的范圍上,而不是使服務更”小”.服務的大小應該是指所需的范圍大小,以促進給定的業務能力.
5. 與SOA中的服務不同,給定的微服務應該具有很少的操作/功能和簡單的消息格式.
6. 隨著時間的推移,首先開始具有相對廣泛的服務邊界,重構到較小的服務界限(基于業務需求),這是一個很好的做法.

在我們的零售用例中,整體功能分為四個不同的微服務,即“庫存”,“會計”,“運輸”和“存儲”.他們正在解決一個有限但重點突出的業務范圍,使每個服務彼此完全脫鉤,并確保開發和部署中的敏捷性.

微服務中的消息傳遞

在單片應用中,使用函數調用或語言級方法調用不同處理器/組件的業務功能.在SOA中,這種轉移趨向于更為松散耦合的Web服務級別消息傳遞,主要基于不同協議(如HTTP,JMS)之上的SOAP.而具有數十種操作和復雜消息模式的Web服務是Web服務普及的關鍵阻力.對于Microservices架構,它需要簡單而輕量的消息傳遞機制就行.

同步消息 – REST,Thrift

對于同步消息傳遞(客戶端期望從服務及時得到響應并等待到達),在微服務體系結構中,REST是主流標配,因為它提供了基于資源API風格的HTTP請求響應實現的簡單消息傳遞方式.因此,大多數微服務實現都使用HTTP以及基于資源API的風格(每個功能都以資源和在這些資源之上執行的操作來表示).

另外,Thrift (可以在其中為微服務定義接口定義)可以作為REST / HTTP同步消息傳遞的替代方法.

異步消息 – AMQP,STOMP,MQTT

對于某些需要使用異步消息傳遞技術(客戶端不期望立即響應或根本不接受響應)的微服務場景.多看看諸如AMQP, STOMP或MQTT之類的異步消息協議就好了.

消息格式 –?JSON,XML,Thrift,ProtoBuf,Avro

決定微服務最適合的消息格式是另一個關鍵因素.傳統單片應用使用二進制格式(習慣了,表示還好不算復雜)；基于SOA / Web服務的應用使用基于復雜消息格式(SOAP)和模式(xsd)的文本消息.而在大多數基于微服務器的應用中,簡單基于文本的消息格式即可,如JSON和XML,反正就是基于HTTP資源API風格跑起來.在我們需要二進制消息格式的情況下(文本消息在某些用例中可能會變冗長),微服務可以利用二進制消息格式,如Thrift,ProtoBuf或Avro…

服務合同 – 定義服務接口 – Swagger, RAML, Thrift IDL

若你把業務能力實現為服務,就需要定義和發布服務合同.傳統單片應用幾乎找不到這樣的功能來定義應用的業務功能.在SOA/Web服務的世界里,WSDL用于定義服務合同.不過眾所周知,WSDL不是用于定義微服務合同的理想解決方案,因為WSDL非常復雜且與SOAP緊密耦合.

由于我們在REST架構風格之上構建微服務器,所以我們可以使用相同的REST API定義技術來定義微服務器的合同.因此,微服務更多情況下用標準的REST API定義語言(如Swagger和RAML) 來定義服務契約.

對于不基于HTTP/REST(如Thrift)的其他微服務實現,可以用協議級別的“接口定義語言(IDL)”(如Thrift IDL).

集成微服務(Inter-service / process communication)

在微服務架構中,軟件應用程序被構建為一套獨立的服務.因此,為了實現業務用例,需要在不同的微服務/流程之間建立通信結構.這就是為什么微服務之間的服務間/過程通信至關重要的原因.

在SOA實現中,服務之間的服務間通信通過企業服務總線(ESB)來實現,大部分業務邏輯都位于中間層(消息路由,轉換和業務流程)中.然而,微服務架構促進消除中央消息總線/ESB,并將“智能”或業務邏輯移至服務和客戶端(稱為“智能端點”).

由于微服務使用諸如HTTP,JSON等標準協議,因此在微服務之間的通信中,與不同協議集成的要求是最小的.Microservice通信中的另一種替代方法是使用輕量級的消息總線或網關,它們有最小的路由功能,并且僅用作在網關上實現業務邏輯的“dumb pipe”.基于這些風格,在微服務架構中不可避免的出現了幾種通信模式.

點到點風格 – 直接調用服務

以點對點的形式,消息路由邏輯的整體跑在每個端點之上,服務可以直接通信.這里每個微服務器都暴露一個REST API,一個給定的微服務器或外部客戶端可以通過對應的REST API調用另一個微服務器.

顯然,這個模型適用于相對簡單的基于微服務的應用.隨著服務數量增加,復雜就會壓倒一切的源頭.傳統SOA實現中使用ESB也是相同的原因,不過是為了擺脫混亂的點對點集成鏈接.總結微服務通信中點對點風格的缺點：

1. 須在每個微服務級別實現終端用戶認證,限制,監控等非功能性要求.
2. 由于不可避免的復制一些常用功能,每個微服務實現可能會變得復雜.
3. 服務和客戶端之間的所有通信都無法控制(哪怕只是監控,跟蹤或過濾).
4. 通常直接溝通風格被認為是用于大規模微服務實現的微服務反向模式.

特征說完,總結：對于復雜的微服務用例,可以考慮輕量級的中央消息總線,而不是點對點連接或中心ESB,思路是為微服務提供一個抽象層,并可用于實現各種非功能的能力,這種風格被稱為API網關風格,往下看.

API網關樣式

API網關風格背后的關鍵思想是使用輕量級消息網關作為所有客戶端/消費者的主要入口點,并在Gateway級別實現常見的非功能需求.通常,API網關允許通過REST/HTTP使用受管API.

因此,在這里,我們可以將通過API-GW實現作為微服務的業務功能公開為管理API.Microservices架構和API管理的組合,這個算是最佳選擇了.

在我們的零售業務場景中,如圖5,所有的微服務都通過API-GW公開,這是所有客戶端的單個入口點.總結下API-GW風格優勢：

• 能夠在現有微服務的網關級別提供所需的抽象.例如,API網關可以為每個客戶端提供不同的API,而不是提一個所有類型的API.
• 網關級、輕量級消息路由/轉換.
• 非功能性功能(如安全性,監控和調節)的應用能如臂指使.
• API-GW模式讓非功能性要求在Gateway級別實現,微服務得以瘦身.

比較推薦API-GW,我沒具體了解過,但這個應該也是應用最廣泛的模式.

Message Broker風格

微服務還可以和異步消息的場景集成,比如隊列或主題的單向請求以及訂閱.給定的微服務可以做消息生成,并且它可以異步地將消息發送到隊列或主題.那么消費的微服務器可以消耗來自隊列或主題的消息.這種風格將消息生成與消息消費分離,中間消息代理緩沖直到消費處理.

消費/生產之間的通信基于異步消息標準(例如AMQP,MQTT等)的消息代理來實現.

分散式數據管理

單片架構中,應用將數據存儲在單個和集中的數據庫中,以實現應用的各種功能/功能.

在微服務體系結構中,功能分散在多個微服務器中,如果我們使用相同的集中式數據庫,那么微服務器將不再彼此獨立(例如,如果數據庫模式已經從給定的微服務器發生變化).因此,每個微服務器都必須擁有自己的數據庫.

以下是在微服務架構中實施分散數據管理的關鍵方面：

• 每個微服務器都可以有一個私有數據庫來保存實現從其提供的業務功能所需的數據.
• 給定的微服務器只能訪問專用私有數據庫,而不能訪問其他微服務器的數據庫.
• 某些業務場景中,可能單個事務需要更新多個數據庫.在這種情況,其他微服務器的數據庫應僅通過其服務API進行更新,而非直接訪問.

非集中式數據管理提供完全解耦的微服務器,以及選擇不同數據管理技術(SQL或NoSQL等,按需分配,可能不同數據庫管理系統)的自由.再者對于涉及多個微服務的復雜事務用例,事務行為必須使用從每個服務提供的API來實現,并且邏輯位于客戶端或中間(GW)級別.

權力下放的治理思維

微服務架構傾向于分散治理.一般來說,SOA治理指導了可重用服務的開發,建立如何設計和開發服務以及這些服務隨時間的變化.它確定了服務提供商和這些服務的消費者之間的協議,告訴消費者他們期望什么以及提供者有義務提供什么.在SOA治理中,共有兩種類型的治理：

• 設計時治理 – 定義和控制服務策略的服務創建,設計和實施；
• 運行時管理 – 執行期間執行服務策略的能力；

那么,微服務環境中的治理究竟怎么理解?在微服務架構中,微服務通過各種技術和平臺構建為完全獨立和解耦服務.因此,不需要為服務設計和開發定義一個共同的標準.總結下微服務的權力下放治理能力：

• 在微服務架構中,管理不需要集中設計.
• 微服務器可以因地制宜,決定其設計和實現.
• 微服務架構促進了共享/可重用服務的共享.
• 一些運行時管理方面,如SLA,節流,監控,常見安全要求和服務發現可以在API-GW級別實現.

服務注冊和服務發現

在微服務架構中,需要處理的微服務器數量相當高.而且,由于微服務的快速和敏捷的開發/部署性質,他們的位置一般來說也會動態變化.因此,你需要在運行時間內找到微服務器的位置.解決此問題的方法是使用Service Registry.

服務注冊表

服務注冊表保存微服務實例及其位置.Microservice實例在啟動時注冊到服務注冊表,并在關機時注銷.消費者可以通過服務注冊表找到可用的微服務及其位置.

服務發現

要找到可用的微服務及其位置,我們要一個服務發現機制.有兩種類型的服務發現機制,客戶端發現和服務器端發現,來看看這些服務發現機制各原理如何.

客戶端發現：?

在這種方法中,客戶端或API-GW通過查詢服務注冊表來獲取服務實例的位置.

這里客戶端/API-GW必須通過調用Service-Registry組件來實現服務發現邏輯.

服務器端發現：

通過這種方法,客戶機/API-GW將請求發送到在眾所周知的位置運行的組件(如負載平衡器).該組件調用服務注冊表并確定微服務器的絕對位置.

Kubernetes等微服務部署解決方案提供了服務端發現機制,自媒體里鏈接不能發就算了.

部署

在微服務架構方面,微服務的部署同樣起著至關重要的作用,關鍵要求如下：

• 能夠獨立于其他微服務部署/部署.
• 必須能在每個微服務級別做擴展(給定的服務可能比其他服務獲得更多的流量).
• 快速構建和部署.
• 一個微服務的故障不得影響任何其他服務.

Docker提供了一種很好的方式來部署滿足上述要求的微服務器,所涉及的關鍵步驟如下：

• 將微服務作為(Docker)容器鏡像打包.
• 將每個服務實例部署為容器.
• 基于更改容器實例的數量來進行縮放.
• 構建,部署和啟動微服務將會快得多,因為我們使用Docker容器(這比常規VM快得多)

Kubernetes通過允許將一組Linux容器作為單個系統進行管理,在多個主機上管理和運行Docker容器,提供容器的共同位置,服務發現和復制控制,從而擴展Docker功能.其實大多數這些功能在微服務環境中也很重要,因此使用Kubernetes(在Docker上面)用于微服務部署已經成為一種非常強大的方法,特別是對于大規模微服務部署.

圖11,顯示了零售應用的微服務部署概述.每個微服務實例被部署為容器,每個主機有兩個容器.同時可隨意更改在給定主機上運行的容器數.

安全

現實很骨感,無論是不是微服務都應當得到安全方面的保護.在進入微服務安全性篇章之前,我們先快速過一下如何在單片應用層面實現安全.

• 在典型的單片應用程序中,安全性是關于發現“誰是呼叫者”,“呼叫者可以做什么”,以及“我們如何傳播該信息”.
• 這通常在位于請求處理鏈的開始處的公共安全組件中實現,該組件使用底層用戶存儲庫(或用戶存儲)填充所需的信息.

那么,我們可以直接將這種模式轉化為微服務架構嗎?是的,但是這需要在每個微服務級別實現安全組件,該級別正在與集中式/共享用戶存儲庫進行通信,并檢索所需的信息.這是解決Microservices安全問題的一種非常乏味的方法.

還有,劃重點,我們可以利用廣泛使用的API-Security標準(如OAuth2和OpenID Connect)來找到我們的Microservices安全問題的更好的解決方案.在深入了解之前,我來總結下這些標準.

• OAuth2 – 是訪問委派協議.客戶端使用授權服務器進行身份驗證,并獲取稱為“訪問令牌”的不透明令牌.Access令牌具有關于用戶/客戶端的零信息.它僅引用只能由授權服務器檢索的用戶信息.因此,這被稱為“副參考令牌”,即使在公共網絡/互聯網中也可以安全地使用該令牌.
• OpenID Connect的行為與OAuth類似,但是除了訪問令牌之外,授權服務器還會發出一個包含用戶信息的ID令牌.這通常由JWT(JSON Web令牌)實現,并由授權服務器簽名.因此,可以確保授權服務器與客戶端之間的信任.因此,JWT令牌被稱為“副值令牌”,因為它包含用戶的信息,顯然不能在內部網絡之外使用它.

現在,讓我們看看我們如何使用這些標準來保護我們零售業的微觀服務.

如圖12,這些是實現微服務安全性的關鍵步驟：

• 將身份驗證保留到OAuth和OpenID Connect服務器(授權服務器),以便microservices成功提供訪問權限,因為有人有權使用數據.
• 使用API-GW樣式,其中所有客戶端請求都有一個入口.
• 客戶端連接到授權服務器并獲取訪問令牌(按引用令牌).然后將訪問令牌與請求一起發送到API-GW.
• 網關上的令牌翻譯：API-GW提取訪問令牌,并將其發送到授權服務器以通過值令牌來檢索JWT.
• GW將該JWT與請求一起傳遞到微服務層.
• JWT包含有助于存儲用戶會話等的必要信息.如果每個服務都可以了解JSON – Web令牌,那么已經分發了你的身份機制,那你就被允許在整個系統中傳輸身份.
• 在每個微服務層,我們可以有一個處理JWT的組件,這是一個非常簡單的實現.

交易

微服務中的交易支持如何?其實,支持跨多個微服務的分布式事務是一個非常復雜的任務.

微服務架構本身鼓勵服務之間的無事務協調.這個想法是給定的服務是完全獨立,基于單一的責任原則.跨多個微服務器分布式事務的需要通常是微服務體系結構設計缺陷的癥狀,通常可以通過重構微服務器的范圍進行整理.

然而,如果強制性要求跨多個服務進行分布式交易,則可以通過在每個微服務級別引入“補償操作”來實現這種情況.關鍵思想是,給定的微服務是基于單一責任原則,如果給定的微服務器未能執行給定的操作,那么我們可以認為這是整個微服務的失敗.

設計失敗

Microservice架構引入了一系列分散的服務,與單片設計相比,增加了在每個服務級別發生故障的可能性.由于網絡問題,基礎資源不可用,給定的微服務可能會失敗.不可用或無響應的微服務器不應玩砸了整個基于微服務器的應用.因此,微服務應該有容錯余地,能夠在可能的情況下恢復,客戶端也必須妥善處理.

此外,由于服務可能隨時失敗,因此能夠快速檢測(實時監控)故障,并盡可能自動恢復服務(故障自愈)很重要.

在微服務玩家的眼里,處理錯誤有幾種常用模式.

斷路器?

當你對微服務器進行外部呼叫,就可以在每次調用時配置故障監視器組件,并且當故障達到某個閾值時該組件將停止對服務的任何進一步調用(跳閘電路).在打開狀態(可以配置)的一定數量的請求后,將電路更換回關閉狀態.
這種模式對于避免不必要的資源消耗,由于超時引起的請求延遲是非常有用,也讓我們有機會更積極的監控系統(基于活動的開路狀態).

隔板?

基于微服務器的應用的一部分的故障不應影響其他應用,隔板模式是關于隔離應用的不同部分,以便應用的某個部分的服務失敗不會影響任何其他服務.

超時?

超時是一種主觀加入的合理機制,當你認為結果無法返回,則允許停止響應.

模式這里叨叨完.那么,我們在哪里和如何使用這些模式與微服務?大多數情況下這些模式都適用于Gateway級別,這意味著當微服務不可用或沒有響應時,在網關級別,我們可以決定是否使用斷路器或超時模式將請求發送到微服務.此外,在Gateway級別實現諸如隔板之類模式也很重要,因為它是所有客戶端請求的單個入口點,也因此發送服務中的故障不應影響其他微服務器的調用.

另外,Gateway可以作為中心點,我們可以通過Gateway調用每個微服務來獲取每個微服務器的狀態和監視.

微服務,企業集成,API管理和遐(瞎)想

們專門研究過微服務架構的各種特點,以及如何在現代企業IT環境中實現它們.但是,我們應該記住,微服務不是靈丹妙藥.流行語概念的盲目適應不會解決“真實”企業IT問題.

它微服務是有很多優勢,我們也應該充分利用.但是我們還必須記住,解決所有企業IT問題與微服務之間聯系不一定就是強相關.例如,Microservices架構促進消除ESB作為中央總線,但是當涉及到現實世界的IT時,現在有很多不是基于Microservices的應用程序/服務.所以,整合是避不開的解決思路,要做集成.

所以,理想情況下,Microservices和其他企業架構概念(如Integration)的混合方法將更為現實.以后再聊了,這個能寫的太多. 希望這能讓你更清楚地了解如何在企業中使用Microservices.

文章來自微信公眾號：DevOps研究院

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/2360.html