在瞭解了六種常用的微服務架構設計模式，並從中選擇了對組織最有意義的模式之後，您可能覺得這就足夠了。但是，爲了讓整個體系正常運行，並且發揮微服務架構的功能，您的組織需要採用許多基本的最佳實踐。本文將爲您介紹這些最佳實踐：
一、抗脆弱軟件
抗脆弱軟件系統通常含有多個主控數據源，但其架構通常不會尋求唯一真實數據源的存在，也不會使用特定的一致性模型。更改數據的方法通常有很多種，這些方法可能會產生級聯影響，這些級聯影響很難去理解或響應。
針對抗脆弱軟件，重要的是要建立一種可預測性的意識，以便能夠在高可擴展性基礎上運行復雜的基礎設施。確保您的軟件在面對所有可能的失敗情況時都具有健壯性是至關重要的。您不能指望您的基礎設施是有容錯性的。
這將導致微服務開發者朝着鼓勵在廣泛的系統故障面前不間斷操作的實踐前進。儘管“混沌工程”的概念（Netflix率先提出）已經存在了一段時間，但其關鍵的經驗教訓直到微服務的出現才被廣泛採用。“抗脆弱性”是思維方式和具體實踐的結合，其中一些關鍵的實踐包括以下7點：
1）12-factor應用原則是有用的，但不應該過度使用。例如Pivotal Cloud Foundry企業級PaaS平臺的體系結構最初就是基於這些原則構建的，但是在現實世界中，經歷了無數的可能性，以致於最近在一些極其極端的方面鬆懈了。儘管如此，12-factor應用原則中的大多數還是適用於任何情況的（例如，將日誌記錄爲事件流）。
2）使用智能默認值。如果配置文件或環境變量由於某種原因不可用，軟件應該使用合理的默認值初始化爲操作狀態。
3）管理工作目錄和臨時文件。當應用程序試圖寫入不存在的目錄或應用程序沒有訪問權限時，您必須修復多少次錯誤？如果應用程序需要訪問給定的文件或目錄時，請確保訪問它的代碼檢查訪問權限，並在需要時創建該文件。
4）避免競爭條件和協調啓動順序。通常，軟件在足夠簡單的情況下，應該是可以單獨啓動的，然後再去尋求與其他組件聚合。現如今，許多應用程序都需要一個特定的啓動順序（例如，首先啓動數據庫，然後是應用服務器），而這並不是必要的。在連接不可用的情況下，不要出錯，無論如何都要啓動，並嘗試在備份超時的時候重新連接。
5）使引導程序穩健。你可能從這些項目中感受到同一個目標。這個目標就是確保軟件組件可以無錯誤地啓動（無論運行時環境如何），並且隨着時間的推移，尋求達到理想狀態。這種方法的好處是廣泛而明顯的，但是基本的原則應該是，操作人員永遠不需要了解軟件的內部。
6）使用斷路器。這是一種模式。在微服務部署中，斷路器模式通常作爲高性能進程間通信框架的一部分實現，如Hystrix或Finagle，這種模式可以檢測故障並提供邏輯來防止故障再次發生。換句話說，該模式檢測一個錯誤條件，並阻止組件嘗試重試“註定出錯”的操作，直到錯誤條件解決爲止。
7）使用超時值。與使用智能默認值類似，任何外部通信都應該包含超時值。如果在端到端方案中涉及到許多服務，則必須考慮超時“預算”。例如，調用鏈中第三個調用的超時值不應該與第一個調用的超時值相同或者更長，否則，您會讓組件在鏈條下游仍然在處理已經在邊緣上終止的調用。
二、HealthZ
微服務的一個常見模式是“healthZ”，或者換句話說，應用提供一個健康狀態檢查的端點（Spring Boot中的/health，/healthz作爲該模式的通用名稱）。此檢查應表明兩件事：
1）這個應用程序認爲它是健康的嗎？（“是”返回：200，“否”返回：5xx）。
2）它認爲目前的狀態會帶來什麼？它將返回一組基本信息（例如JSON），這組信息描述其內部依賴項的當前狀態。這些應該對操作員（而不是開發人員）是可讀的，並且是不言而喻的，例如“數據庫：正在連接”。
請注意，健康狀態和正確的操作狀態是不同的：在容器框架中，組件可以正常運行，但還沒有“準備好”爲流量提供服務（例如，數據庫尚未連接），這是很常見的。HealthZ端點應該指出什麼時候真的出了問題，而不是說有一個臨時的操作點。
三、“無限”（線性）擴展
微服務模式非常注重可伸縮性，通常會使用術語“無限”擴展。當然，這並不意味着真正的無限擴展。相反，它是一個概念的簡寫，這個概念對如何使用一個給定的軟件實現線性伸縮模型有一個清晰的理解。通常，這集中在擴展的硬限制上：數據存儲和狀態管理。對於微服務，這鼓勵開發人員考慮他們正在使用的數據和存儲模式，並尋找一種方法來執行支持高規模的任務。例如，高可擴展性的事務支持可以通過使用最終一致的集羣存儲來實現，而不是依賴於RDBMS（RDBMS，即關係數據庫管理系統，Relational Database Management System）提供的事務邊界。一般來說，這是一個很好的實踐。雖然沒有必要過度考慮這一點，但是確定存儲層的用途並確保使用“最適合這項工作的工具”是有價值的。
四、最小化依賴項
當您頻繁部署許多更改時，確保組件對外部系統的依賴性最小（例如，通過使用隊列進行通信，而不是同步請求/響應模式），這一點很重要。雖然微服務模式使得這一點幾乎是強制性的，但一般來說，使每個組件儘可能自給自足是有用的。同樣，不要過度考慮這一點，但一個好的經驗法則是儘量使部署的每個單元都儘可能獨立。
未完待續，其餘四個最佳實踐將在下篇文章中進行分享，盡情關注。
未經同意，本文禁止轉載或摘編。