總結自己對微服務架構整體的一個淺層次認知，主要包括以下9個方面認知。

 

一．微服務

①什麼是微服務？

微服務就是一些協同工作的小而自治的服務，稱之為分散式系統，是SOA（面向服務的架構）架構的一種實現方法。

單個服務多小合適？應該考慮這些因素：服務越小，服務架構的優點和缺點也就越明顯。使用的服務越小，獨立性帶來的好處越多，但是管理大量的微服務也會越複雜。

單個服務的自治性特點。一個服務就是一個獨立的實體。每一個服務暴露出API,服務之間以網路為媒介通過這些API呼叫進行通訊。從而加強了服務之間的隔離性，避免緊耦合。

②微服務帶來的好處？

(1)技術異構性。

不同的服務使用最適合該服務的技術。如果系統中的某一部分需要做效能提升，可以使用效能更好的技術棧重構該服務。如系統中不同的服務可以使用不同的資料庫儲存技術。微服務可以幫助我們更快地採用新技術，並降低風險。

(2)彈性。

彈性工程學的一個關鍵概念是壁艙。如果系統中一個元件不可用了，但並沒有導致級聯故障，那麼系統的其他部分還可以正常執行。服務的邊界就是一個很顯然的壁艙。微服務可以很好的處理服務不可用和功能降級問題。微服務以網路為媒介進行RPC通訊，網路會是瓶頸問題。

(3)易擴充。

微服務架構相比單系統來說更易擴充。

(4)易部署。

微服務部署風險低，效率高。

(5)易管理。

微服務架構，更易實現團隊自治，開發效率更高，維護成本更低。

(6)可重用。

微服務架構，對於獨立的服務，可實現可重用，易於組合的目的。

(7)易重構。

開發團隊在必要的時候可以輕易實現對單個服務的重構或重寫，或刪除不再使用的服務。

③相關術語。

（1）SOA（Service-Oriented Architecture,面向服務的架構）。實施SOA通常要考慮:通訊協議的選擇，第三方中介軟體的選擇，服務粒度的劃分等。

（2）OSGI(Open Source Gateway Initiative,開放服務閘道器協議)。OSGI是一種模組分解技術，強調模組生命週期管理，允許在一個程式內部進行模組劃分，建立出相對隔離的模組避免耦合。Java9已加入這個特性。但不推薦這麼做。

二.建模微服務

①好的微服務特點？

(1)鬆耦合

服務之間鬆耦合，要求能夠做到能夠修改及部署單個服務而不需要修改系統的其它服務。一個鬆耦合的服務應該儘可能少的知道與之協作的服務的資訊。否則服務之間過度通訊會導致緊耦合。

(2)高內聚

把相關的行為聚集在一起，把不相關的行為放在別處。達到這樣的目的，當需要修改某個行為時，最好只對一個服務進行修改，而不需修改其它服務，達到快速釋出，降低風險，快速交付。所以找到問題的邊界，確定劃分服務的粒度是關鍵。

②建模微服務

建模微服務，應該以服務所提供的功能為出發點，進行微服務的建模。

三．整合服務

微服務，每一個單獨的服務所提供的功能相對單一，但每一個服務的的功能實現可能要整合其它服務的功能。整合是微服務架構中一種常用的手段。

①服務之間的通訊方式-同步/非同步

（1）同步

使用同步通訊，發起一個遠端服務呼叫之後，呼叫方會阻塞自己並等待整個遠端呼叫過程的完成，才可以返回。

同步呼叫，基於“請求/響應”的模式。客戶端發起一個請求，然後等待響應。

編排的架構風格，即採用同步呼叫，“請求/響應”模式，可以清楚知道每一步的響應結果，卻會導致系統臃腫，響應耗時，耦合度高。

（2）非同步

使用非同步通訊，呼叫方不需要等待遠端呼叫過程的完成，就可以返回。

非同步呼叫，基於“事件釋出”的模式。客戶端不是發起請求，而只是釋出一個“事件”，並不知道誰會對此事件作出響應。

協同的架構風格，即採用非同步呼叫，“事件釋出”模式，可降低系統耦合度，響應更快速；但需要額外的工作對對業務流程做跨服務監控。

②同步通訊實現技術-RPC/REST

RPC(Remote Procedure Call)遠端過程呼叫；

REST(Representational State Transfer)表述性狀態轉移。

（1）RPC

遠端呼叫，允許你進行一個本地呼叫，但事實上結果是由某個遠端伺服器產生的。遠端呼叫的協議種類繁多，如Java RMI，Thrift,Protocol buffers等是使用二進位制作為訊息的傳輸格式；SOAP使用XML作為訊息的傳輸格式。

RPC會花費時間對傳輸資訊進行封裝和解封裝，網路通訊耗時也是需要考慮的因素；通訊雙方對使用的資料模型依賴較重，資料型別會直接被序列化和反序列化，導致不再使用的欄位無法被安全刪除。

RPC可以幫助你生成客戶端樁程式碼，可以支援高階的序列化和反序列化機制，以及更加靈活的通訊協議。

（2）REST

REST是受Web啟發產生的，能夠使客戶端和服務端對資料模型的依賴弱化，更加靈活。

REST風格多用Http協議，資料傳輸格式靈活，JSON,XML及二進位制格式都可以。

③非同步通訊實現技術-MQ

非同步通訊，基於“事件釋出”機制。耦合度低，伸縮性好；但程式設計的複雜性更高，常用的成熟技術手段是採用“訊息佇列”實現。

④整合微服務考慮要素

（1）服務的響應延時

（2）服務不可用，合理安全的功能降級

四．分解單個系統

分解單個臃腫的系統，使其拆分成多個微服務。

①分離資料庫

建議先分離資料庫結構，再分離服務。

②慎重處理分散式事務

把單個系統拆分為多個微服務，可能會產生分散式事務。分散式事務橫跨多個系統，執行在不同系統的不同程式中。分散式事務通常通過重試和補償機制來達到最終的一致性。

五．部署

①CI(Continuous Integration)持續整合。

CI能夠保證新提交的程式碼與已有的程式碼進行整合，從而讓所有人保持同步。通過CI能夠從已部署的構建物回溯到響應的程式碼。把CI構建和每個微服務對映起來，每個服務獨立於其它服務進行獨立部署。

②CD(Continuous Delivery)持續交付。

CD能夠檢查每次提交是否達到了部署到生產環境的要求，並持續的把這些資訊反饋，它會把每次提交當成候選釋出版本來對待。

③實施藍/綠部署

藍綠部署時，我們會部署兩份軟體，只有一份接受真正的請求。如把新新版本的服務用於接受請求，並保留舊版本一段時間，確保發生錯誤時，能夠快速恢復到舊的版本。

④金絲雀釋出

金絲雀釋出是指通過將部分生產流量引流到新部署的系統，來驗證系統是否按預期執行。金絲雀釋出與藍綠部署的不同之處在於，新舊版本共存時間更長，而且經常會調整流量。

六．測試

①單元測試

單元測試，通常用來測試函式和方法呼叫。TDD(Test-Driven Design)測試驅動開發，就屬於單元測試。

②服務測試

服務測試，是針對暴露的服務功能進行測試。一個服務測試只測試其中一個單獨服務功能。

七．監控

微服務會增加生產系統監控的複雜性。監控的的手段是：監控單個服務，然後聚合起來看整體。

如，對每一個微服務進行埋點日誌，然後聚合日誌資訊做整體分析；如對每一臺執行的機器利用輔助監控工具，統計的cpu,記憶體等資源使用佔比等資訊。

八．安全

①身份驗證和授權

身份驗證和授權一種實現手段是，使用某種形式的SSO(Single Sign-On)單點登入解決方案。當請求試圖訪問一個資源，它會被定向到一個身份提供者哪裡進行身份驗證。這個身份提供者要求它提供使用者名稱和密碼，或是使用雙重身份驗證。當身份提供者確認請求已通過身份驗證，它會發訊息給服務提供者，讓服務提供者決定是否允許訪問資源。

如常用的SAML和OpenID Connect等解決方案提供了這方面的能力。

②HTTP(S)基本身份驗證

③攜帶金鑰形式的驗證

④資料加密傳輸，如採用AES對稱加密演算法加密傳輸

⑤深度防禦，如防火牆機制，網路隔離等手段

九．微服架構指導思想

①4個設計原則

（1）AKF拆分原則（指“負載均衡”，“資料分割槽”，拆分為微服務）

（2）前後端分離

（3）無狀態服務

（4）Restful通訊風格

②一些實踐指導思想

斷路器思想：當呼叫的服務失敗率(或由於超時導致，或由於服務不可用導致)達到設定閾值，啟動快速失敗，當恢復健康後，再重新呼叫。

冪等：錯誤重試，考慮冪等，如果操作是冪等的，我們對其呼叫多次，不必擔心會有不利影響。

資料庫的架構：讀寫分離，主從備份。

合理快取策略：合理快取，提升效能，災備故障。

CAP架構原則：如分散式事務要滿足CAP原則。

服務註冊與發現：採用成熟的開源套件構建友好的服務註冊與發現。

想了解可以私信我哦！

1 SpringBoot+ 高併發訊息處理 EDM?專案 實戰

2 SpringBoot ELK?分散式 資料分析

3 Netty?高 併發 UTS?專案實戰

4 SpringCloud?微服務+NoSQL+ 負載均衡平臺設計

瞭解更多