【導讀】[開始]
總結自己對微服務架構整體的一個淺層次認知，主要包括以下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原則。
服務註冊與發現：採用成熟的開源套件構建友好的服務註冊與發現。
拓展閱讀：http://mp.weixin.qq.com/s/dmPhaERxkDlC2lbzgJIMgg