微服務設計

1.微服務

1.1 什麼是微服務

1.1.1 很小，專注于做好一件事  

        單一職責原則的理念。

1.1.2 自治性

        一個微服務就是一個獨立的實體，它可以獨立地部署在PAAS上，也可以作為一個作業系統程序存在。服務暴露出API，服務間通過API通信。

1.2 主要好處

1.2.1 技術異構性 

        可以用不同的技術棧來實作不同服務。

1.2.2 彈性

        降低整個服務不可用的問題。

1.2.3 擴充

        當存在性能問題時，可以隻對需要擴充的服務進行擴充，把部分不需要擴充的服務運作在更小的、性能稍差的硬體上。

1.2.4 簡化部署

        更改程式時，隻需重新部署一個小服務，便于復原和不影響整體功能。

1.2.5 與組織結構相比對

        小團隊模式更高效。

1.2.6 可組合型

        在微服務架構中，系統會開放很多接口供外部使用。當情況發生改變時，可以使用不同的方式建構應用，而整體化應用程式隻能提供一個非常粗粒度的接口供外部使用。

1.2.7 對可替代性的優化

        重構、删除服務時友善。

1.3 面向服務的架構

        SOA（面向服務的結構）是一種設計方法，其中包含多個服務，而服務之間通過配合最終會提供一系列功能。一個服務通常以獨立的形式存在于作業系統程序中。服務之間通過網絡調用，而非程序内調用的方式進行通信。

2.如何模組化服務

2.1 什麼樣的服務是好服務

2.1 松耦合

        能夠獨立修改及部署單個服務而不需要修改系統的其他部分。

2.2 高内聚

        把相關的行為放在一個服務裡

2.2 逐漸劃分

        先考慮比較大的、粗粒度的，然後當發現合适的縫隙後，再進一步劃分。

3.內建   

3.1 尋找理想的內建技術

• 避免破壞性修改
• 保證API的技術無關性
• 使你的服務易于消費方使用
• 隐藏内部實作細節

3.2 為使用者建立接口

3.3 共享資料庫

        使用資料庫內建會使高内聚和低耦合失效，外部系統能檢視内部實作細節并綁定。

3.4 同步與異步

        同步——請求/響應

        異步——基于事件

3.5 編排與協同

        編排——依賴于某個中心大腦，“上帝”，很容易知道異常

        協同——異步訂閱，消除耦合，但需要監控系統

        請求/響應方式可以考慮RPC（Remote Procedure Call，遠端過程調用）、REST（REpresentational State Transfer，表述性狀态轉移）。

3.6 RPC       

• 技術的耦合
• 隐藏遠端調用的複雜性，會花大量時間對負荷進行封裝和解封裝
• 網絡不可靠
• 脆弱性，一處更改伺服器和用戶端都要改

3.7 REST

        資源、消費者

3.8 版本管理

        版本共存，v1、v2，允許平滑過渡。

4.分解單塊系統

4.1 資料庫

4.1.1 打破外鍵關系

        調用API來通路資料，而不是直接通路資料庫。

4.1.2 共享靜态資料

        放入配置檔案或代碼，比如國家代碼。

4.1.3 共享資料

        通過API來查資料

4.1.4 共享表

        拆分表

5.規模化微服務

5.1 故障無處不在

        網絡、硬體不可靠

5.2 功能降級

        某個服務不可用時，不要影響整個系統。