一 微服務之間的通用設計模式：
1.讀者容錯模式
消費者對提供者返回的內容進行兼容，消費者處理提供者返回的消息的過程中，對消息進行過濾，只提取自己需要的聶榮，對多餘或未知的內容丟棄，而不是強行拋出異常或錯誤信息。
2.契約模式
服務契約分爲：提供者契約、消費者契約、消費者驅動契約
提供者契約：最常用的契約模式，以提供者爲中心，提供者提供什麼功能和消息格式，消費者無條件的遵守這些約定，不論消費者實際需要多少功能。
消費者契約：對某個消費者的需求進行精確描述，消費者確定需要提供者提供哪部分功能或者數據。
消費者驅動契約：服務提供者向其所有消費者承諾遵守的約束，有消費協商確定需求的功能或者數據並告知提供者，提供者保證始終堅守約定的契約。
3.數據共享模式
在實踐的過程中，有些方案的設計使用緩存或者數據庫作爲兩個微服務的紐帶，起一個微服務的結果存入緩存或者數據庫，下一個微服務從緩存或數據庫中讀取數據繼續處理。
這種模式用如下明顯缺點：
1.使微服務之間的交互除了接口契約，還存在這數據存儲的契約（存儲類型，數據結構）。
2.上游的數據結構發生變化，可能導致下游的處理邏輯出現問題。
3.多個服務共享一個資源服務，對資源服務的運維難以劃清職責和界限。
4.跨機房獨立部署，需要考慮服務和資源的路由情況，跨機房獨立部署很難實現進而難以實現服務的自治。
二 微服務的分解和組合模式
使用微服務架構劃分服務和團隊是微服務架構實施的第一步，良好的劃分和拆分使系統達到鬆耦合和高內聚的效果，人後通過微服務的靈活組裝可以滿足上層的各種各樣的業務處理需求。
微服務的設計中通常用領域的動詞和名詞來劃分微服務。
1.服務代理模式
根據業務需求選擇調用後端的某個服務，在返回給前端之前代理對後端服務輸出進行加工，也可以直接吧後端服務的返回結果返回給前端。
2.服務聚合模式
根據業務需要以一定的順序調用依賴的多個微服務，對依賴的微服務返回的數據進行組合、加工和轉換，最後以一定的形式返回給使用方。
沒個被依賴的服務都用自己的緩存和數據庫，聚合服務本身也可以有自己的數據存儲，包括緩存和數據庫，也可以是簡單的聚合，不持久化任何數據。
3.服務串聯模式
服務串聯模式類似於一個工作流，上層的服務負責接收請求和響應使用方，接到請求和繼續與下層服務交互，最後底層的結果向上逐級處理以後返回給使用方。
服務串聯模式之間的調用通常使用同步的RESTful風格的遠程調用實現，同步調用在串聯服務沒有完成並返回之前，所有服務都會阻塞和等待，一個請求會佔用一個線程來處理，因此在這種模式下不建議服務的層級太多。
4.服務分支模式
服務分支模式是服務代理模式、服務聚合模式和服務串聯模式相結合的產物。
分支服務可以擁有自己的數據庫存儲，調用多個後端的服務或者服務串聯鏈，然後將結果進行組合處理再返回給客戶端。分支服務也可以使用代理模式，簡單地調用後端的某個服務或者服務鏈，然後將返回的數據直接返回給使用方。
5.服務異步消息模式
同步調用模式在調用過程中會阻塞線程，如果服務提供方遲遲沒有返回，則消費方會一直阻塞，在嚴重情況下會撐滿服務的線程池，出現雪崩效應。因此在構建服務架構系統的時候，梳理出核心系統的最小化服務集合，將這些核心的系統服務使用同步調用，和其它核心鏈路以外的服務可以使用異步消息隊列進行異步化。
6.服務共享數據模式
服務共享數據模式其實是反模式。之前的去數據共享模式，由於去掉數據共享，所以服務之間通過定義的接口進行交互和通信。但在如下的特殊場景下仍然需要考慮數據共享模式。
1.單元化架構
一些平臺由於對性能要求比較高，採用微服務將服務拆分，通過網絡服務進行通信，儘管網絡通信的帶寬已經很寬，但還是會有性能方面的損耗，在這種情況下可以讓不同的微服務共享一些資源，如：緩存、數據庫等，甚至可以將這些服務部署到一臺物理機中，最大限度地減少網絡通信帶來的性能損耗。
2.遺留的整體服務
對於歷史上遺留下來的單體服務，在重構微服務的過程中，發現單體服務依賴的數據庫表耦合在一起，對其拆分涉及反規範化的處理，可能會造成數據一致性問題，在沒有對其完全理解和有把握的前提下，會選擇保持現狀，讓不同的微服務暫時共享數據存儲。