微服務中的常見設計模式

軟體開發者對“四人幫”的《設計模式》一書應該都很熟悉，微服務中也會有一些常見的模式：

部署模式

• 多服務共享主機／虛機
  
• 單服務部署單一主機／虛機
  
• 單服務部署單一容器（Docker）
  
• 無服務部署（serverless），例如AWS Lambda
  
• 使用服務部署平臺 （Kubernetes，Docker Swarm，Mesos， AWS ECS）
  

不同的部署方式各有優缺點，重點推薦使用容器編排系統的服務部署平臺，能夠提供各種靈活的部署方案。

橫向關注點

微服務的開發過程中常常會花很多時間來處理一些各個服務都會遇到的問題，例如

• 如何管理配置資訊，例如使用者名稱和口令，伺服器的網路地址，等等
• 日誌管理
• 健康檢查
• 業務度量資料（Metrics）的收集和分析
• 分佈服務的追蹤

這裡推薦使用一個穩定的微服務框架來處理這些問題，例如基於Java的spring boot，基於Golang的Micro等

API閘道器 

API閘道器類似服務代理，所有的客戶端都通過API閘道器提供的統一服務API來消費服務內容。

下面是幾個開源的API Gateway

服務發現

服務發現是指API閘道器或者客戶端如何獲得微服務的地址，主要有以下幾種發現方式：

• 客戶端發現
  
• 伺服器端發現
  
  這種方案中的Router可以併入API閘道器，客戶端直接和閘道器通訊。

兩種方案需要用到服務註冊，，區別在於是否把服務註冊直接暴露給客戶端使用。常見的提供服務發現的註冊開源解決方案有：

斷路器

當微服務系統中的某個服務出現問題的時候，或者網路出現時延的時候，呼叫客戶端會被阻塞，導致大量的呼叫佔用大量的資源。這時候需要引入類似斷路器效果的代理，當出現不健康的服務的時候，斷路器會返回出錯，阻止更多的客戶端掉用，直至服務的健康狀態恢復。

資料管理

在設計微服務的時候要考慮是否每一個服務擁有自己的資料庫或者是共享資料庫

• 每個服務擁有自己的資料庫
• 共享資料庫

這兩種方式各有優缺點：

• 獨立資料庫使得各個服務完全解耦合，並且可以根據需要選用不同種類的資料庫，但是沒有辦法或者很難在服務之間共享資料
• 共享資料庫能簡化維護和技術棧，但是資料庫成為所有服務的依賴，系統更多的耦合，帶來了不靈活，沒有辦法根據業務需要選擇不同的資料庫種類。

微服務中的反模式

相對於《設計模式》，《反模式》一書可能知道的相對少一點，其實同樣的道理，反模式歸納總結了一些常見的容易犯的設計問題，那麼，微服務中有哪些反模式呢？

聚合混亂
軟體設計的一個主要思想“高內聚，低耦合”同樣適用於微服務，隨著系統的發展，應該避免某一個服務變的一場龐大，或者服務之間不必要的過多依賴。

不認真對待自動化
持續整合和交付和微服務相輔相成，自動化的測試，整合，交付和部署是微服務成敗的關鍵。一個自動化成都不高的微服務是很難成功的。

層級的軟體架構
在設計微服務的時候，應該儘可能避免分層的架構，服務之間更多應該是流式呼叫。例如為所有的服務提供一個數據接入層的資料服務，似乎不是一個好的選擇，因為這樣的化就使得所有的服務依賴該資料服務。微服務更多應該基於業務來設計，每個服務應該自包含。

以下的架構雖然是一種層級架構，但也是可以採用的，條件是不同的服務不應該共享資料。

依賴客戶籤核
當服務有不同的客戶渠道來消費的時候，不應該依賴客戶的籤核，自動化的測試應該覆蓋所有的使用場景。

手工化的配置管理
應該儘量避免手工化地配置管理，實現自動化

避免版本管理
在微服務中，如果你的系統只有一個版本，那麼這肯定是有問題的。前向相容是一個需要支援的目標，也就是說不同的客戶端版本不應該收到服務升級的影響。這也就意味這API一旦釋出，就不應該有不相容的修改。

為每一個服務建立閘道器
這個就不用多說了，看著就很傻

參考

• http://microservices.io/patterns/microservices.html
• https://www.infoq.com/articles/seven-uservices-antipatterns