軟體開發者對「四人幫」的《設計模式》一書應該都很熟悉，微服務中也會有一些常見的模式：
如何部署服務是微服務中的乙個重要問題，微服務的部署方式非常靈活，有以下的不同選項可供選擇 （參考
不同的部署方式各有優缺點，重點推薦使用容器編排系統的服務部署平台，能夠提供各種靈活的部署方案。
微服務的開發過程中常常會花很多時間來處理一些各個服務都會遇到的問題，例如
這裡推薦使用乙個穩定的微服務框架來處理這些問題，例如基於j**a的spring boot，基於golang的micro等
api閘道器類似服務**，所有的客戶端都通過api閘道器提供的統一服務api來消費服務內容。
下面是幾個開源的api gateway
兩種方案需要用到服務註冊，，區別在於是否把服務註冊直接暴露給客戶端使用。常見的提供服務發現的註冊開源解決方案有：
當微服務系統中的某個服務出現問題的時候，或者網路出現時延的時候，呼叫客戶端會被阻塞，導致大量的呼叫占用大量的資源。這時候需要引入類似斷路器效果的**，當出現不健康的服務的時候，斷路器會返回出錯，阻止更多的客戶端掉用，直至服務的健康狀態恢復。
netflix的hystrix提供了類似的服務
在設計微服務的時候要考慮是否每乙個服務擁有自己的資料庫或者是共享資料庫
這兩種方式各有優缺點：
相對於《設計模式》，《反模式》一書可能知道的相對少一點，其實同樣的道理，反模式歸納總結了一些常見的容易犯的設計問題，那麼，微服務中有哪些反模式呢？
聚合混亂
軟體設計的乙個主要思想「高內聚，低耦合」同樣適用於微服務，隨著系統的發展，應該避免某乙個服務變的一場龐大，或者服務之間不必要的過多依賴。
不認真對待自動化
持續整合和交付和微服務相輔相成，自動化的測試，整合，交付和部署是微服務成敗的關鍵。乙個自動化程度不高的微服務是很難成功的。
層級的軟體架構
在設計微服務的時候，應該盡可能避免分層的架構，服務之間更多應該是流式呼叫。例如為所有的服務提供乙個資料接入層的資料服務，似乎不是乙個好的選擇，因為這樣的化就使得所有的服務依賴該資料服務。微服務更多應該基於業務來設計，每個服務應該自包含。
以下的架構雖然是一種層級架構，但也是可以採用的，條件是不同的服務不應該共享資料。
依賴客戶簽核
當服務有不同的客戶渠道來消費的時候，不應該依賴客戶的簽核，自動化的測試應該覆蓋所有的使用場景。
手工化的配置管理
應該盡量避免手工化地配置管理，實現自動化
避免版本管理
在微服務中，如果你的系統只有乙個版本，那麼這肯定是有問題的。前向相容是乙個需要支援的目標，也就是說不同的客戶端版本不應該收到服務公升級的影響。這也就意味這api一旦發布，就不應該有不相容的修改。
為每乙個服務建立閘道器
這個就不用多說了，看著就很傻
微服務 服務發現模式
服務發現有三個角色，服務提供者 服務消費者和服務中介。服務中介 聯絡服務提供者和服務消費者的橋梁。服務提供者 將自己提供的服務位址註冊到服務中介。服務消費者 從服務中介那裡查詢自己想要的服務的位址，然後享受這個服務。服務中介提供多個服務，每個服務對應多個服務提供者 服務1 4把當前自己的網路位置註冊...
微服務之saga模式
你已經使用 database ber service 模式。每個service擁有自己的database。一些業務事務會跨越多個service，所以你需要來確保data consistency。例如，假設你正在構建乙個電子商務 這個 的使用者的會有乙個最大欠款限制，應用程式必須確保乙個新訂單不能超過...
微服務的基本容災模式
微服務的基本容災模式 1.主動超時 呼叫依賴的時候設定好超時時間，出問題的時候主動超時，最簡單有效的處理方式。2.限流 限制最大併發數，限制訪問數量。好比長假期間高速公里的限流。3.熔斷 錯誤達到閾值時，類似保險絲熔斷。如果後端系統出現大規模延時，需要暫時的熔斷保護後端系統。一般熔斷不是所有都拒絕，...