建立一個分佈式微服務系統的優點是能夠應對承受故障發生以及彈性使用網絡資源，彈性的定義很簡單，如果傳統的monolith發生故障，裏面的一切就不能運行了，而微服務則是將其分離成很多小組件，每個組件微服務失敗故障不會影響其他。
爲了真正測試這種彈性情況，Netflix使用“chaos monkey” 或類似 “混沌chaos” 策略：引入擾動到系統中目地是爲了證明系統的彈性真的能面對失敗。
把大塊頭切分成更小的碎片可以給你彈性系統的品質，但是沒有一些超前想法則不行，我們將它們切分得越小，就更需要協調組合它們，或者它們依賴“下游downstream”服務數據, 函數等等. 如果這些下游服務失敗了，我們的服務怎麼辦？
承諾和錯誤反饋
承諾理論(Promise theory)首先由Mark Burgess引入， 是爲了描述IT系統彼此交互，系統之間或許並不如我們所希望那樣有預期行爲，一個服務提供發送內容需要做某事，但是也許它不是確定肯定做這個事情，這如同人與人之間交互一樣，我們可以將微服務看成是獨立的匿名代理，我們越尊重這種自主性，越需要了解這些系統自願打算提供一些的服務有時會無法實現。
在微服務架構中更加要注重這種承諾理論，如果交互服務中有一個不可用怎麼辦？有沒有回饋告訴我們？許多時候，這種反饋常常是被業務人員發現，解決方法無非是返回失敗響應，或選擇一個不同備份服務，總之，需要積極面對出乎意料的錯誤。
因此在微服務者，需要考慮多個服務調用時如果一個服務發生問題怎麼辦，解決這個問題方法引入：Apache Camel和Netflix Hystrix。
消費合約Consumer contracts
服務作爲內容提供者進行了承諾和錯誤反饋，那麼作爲服務的消費者怎麼辦？
服務方提供一個合約形式，比如是描述請求和預期響應的文檔或XML之類schema，消費者會確認這些文檔，按照服務者同意的這份合約實現自己內部的數據模型。消費者也許與服務交互，進行序列化或反序列化轉換，這時如果服務改變了合約，比如增加了新的字段內容，那麼消費者這種轉換過程就被迫中斷，因爲我們注重服務的自主性，因此這種情況出現肯定不好，我們需要將服務的變動不會對其他關係者造成脈衝擾動。
一個解決方案是基於“將保守留在服務發送方，將自由留在服務接受方”，我們只要做剛剛足夠的響應驗證，然後立即取出我們需要的數據，而不是試圖做完整的數據驗證。這意味着我們轉換邏輯足夠聰明到能在數據模型變化時也能工作。此外，如果我們能夠捕捉到消費者真正關心的部分，將這一信息循環反饋給服務提供商，以幫助他們理解服務消費者在他們改變服務時會導致什麼變化後果。這種方式稱爲消費驅動合約：Consumer Driven Contracts: A Service Evolution Pattern
Schema registries 能夠 幫助我們做到這點
冪等消費者
冪等消費者就是能夠在服務發生問題時，不斷重試，多次重試不會對業務狀態有任何影響，比如新增操作不是冪等，因爲多次新增操作後業務會多一些狀態。冪等消費者對應着冪等服務dempotent services.
以上三點建議可以幫助你建立彈性的微服務，雖然他們不是唯一需要考慮的設計原則。還有其他需要考慮的事情包括隔離、艙壁bulkhead模式、負載平衡、服務發現、apologies，最終一致性等等。