六種經常使用的微服務架構設計模式 建立微服務模式的基本最佳實踐（上篇）

​​在瞭解了六種經常使用的微服務架構設計模式，並從中選擇了對組織最有意義的模式以後，您可能以爲這就足夠了。可是，爲了讓整個體系正常運行，而且發揮微服務架構的功能，您的組織須要採用許多基本的最佳實踐。本文將爲您介紹這些最佳實踐：

1、抗脆弱軟件

抗脆弱軟件系統一般含有多個主控數據源，但其架構一般不會尋求惟一真實數據源的存在，也不會使用特定的一致性模型。更改數據的方法一般有不少種，這些方法可能會產生級聯影響，這些級聯影響很難去理解或響應。

針對抗脆弱軟件，重要的是要創建一種可預測性的意識，以便可以在高可擴展性基礎上運行復雜的基礎設施。確保您的軟件在面對全部可能的失敗狀況時都具備健壯性是相當重要的。您不能期望您的基礎設施是有容錯性的。

這將致使微服務開發者朝着鼓勵在普遍的系統故障面前不間斷操做的實踐前進。儘管「混沌工程」的概念（Netflix率先提出）已經存在了一段時間，但其關鍵的經驗教訓直到微服務的出現才被普遍採用。「抗脆弱性」是思惟方式和具體實踐的結合，其中一些關鍵的實踐包括如下7點：

1）12-factor應用原則是有用的，但不該該過分使用。例如Pivotal Cloud Foundry企業級PaaS平臺的體系結構最初就是基於這些原則構建的，可是在現實世界中，經歷了無數的可能性，以至於最近在一些極其極端的方面鬆懈了。儘管如此，12-factor應用原則中的大多數仍是適用於任何狀況的（例如，將日誌記錄爲事件流）。

2）使用智能默認值。若是配置文件或環境變量因爲某種緣由不可用，軟件應該使用合理的默認值初始化爲操做狀態。

3）管理工做目錄和臨時文件。當應用程序試圖寫入不存在的目錄或應用程序沒有訪問權限時，您必須修復多少次錯誤？若是應用程序須要訪問給定的文件或目錄時，請確保訪問它的代碼檢查訪問權限，並在須要時建立該文件。

4）避免競爭條件和協調啓動順序。一般，軟件在足夠簡單的狀況下，應該是能夠單獨啓動的，而後再去尋求與其餘組件聚合。現現在，許多應用程序都須要一個特定的啓動順序（例如，首先啓動數據庫，而後是應用服務器），而這並非必要的。在鏈接不可用的狀況下，不要出錯，不管如何都要啓動，並嘗試在備份超時的時候從新鏈接。

5）使引導程序穩健。你可能從這些項目中感覺到同一個目標。這個目標就是確保軟件組件能夠無錯誤地啓動（不管運行時環境如何），而且隨着時間的推移，尋求達到理想狀態。這種方法的好處是普遍而明顯的，可是基本的原則應該是，操做人員永遠不須要了解軟件的內部。

6）使用斷路器。這是一種模式。在微服務部署中，斷路器模式一般做爲高性能進程間通訊框架的一部分實現，如Hystrix或Finagle，這種模式能夠檢測故障並提供邏輯來防止故障再次發生。換句話說，該模式檢測一個錯誤條件，並阻止組件嘗試重試「註定出錯」的操做，直到錯誤條件解決爲止。

7）使用超時值。與使用智能默認值相似，任何外部通訊都應該包含超時值。若是在端到端方案中涉及到許多服務，則必須考慮超時「預算」。例如，調用鏈中第三個調用的超時值不該該與第一個調用的超時值相同或者更長，不然，您會讓組件在鏈條下游仍然在處理已經在邊緣上終止的調用。

2、HealthZ

微服務的一個常見模式是「healthZ」，或者換句話說，應用提供一個健康狀態檢查的端點（Spring Boot中的/health，/healthz做爲該模式的通用名稱）。此檢查應代表兩件事：

1）這個應用程序認爲它是健康的嗎？（「是」返回：200，「否」返回：5xx）。

2）它認爲目前的狀態會帶來什麼？它將返回一組基本信息（例如JSON），這組信息描述其內部依賴項的當前狀態。這些應該對操做員（而不是開發人員）是可讀的，而且是不言而喻的，例如「數據庫：正在鏈接」。

請注意，健康狀態和正確的操做狀態是不一樣的：在容器框架中，組件能夠正常運行，但尚未「準備好」爲流量提供服務（例如，數據庫還沒有鏈接），這是很常見的。HealthZ端點應該指出何時真的出了問題，而不是說有一個臨時的操做點。

3、「無限」（線性）擴展

微服務模式很是注重可伸縮性，一般會使用術語「無限」擴展。固然，這並不意味着真正的無限擴展。相反，它是一個概念的簡寫，這個概念對如何使用一個給定的軟件實現線性伸縮模型有一個清晰的理解。一般，這集中在擴展的硬限制上：數據存儲和狀態管理。對於微服務，這鼓勵開發人員考慮他們正在使用的數據和存儲模式，並尋找一種方法來執行支持高規模的任務。例如，高可擴展性的事務支持能夠經過使用最終一致的集羣存儲來實現，而不是依賴於RDBMS（RDBMS，即關係數據庫管理系統，Relational Database Management System）提供的事務邊界。通常來講，這是一個很好的實踐。雖然沒有必要過分考慮這一點，可是肯定存儲層的用途並確保使用「最適合這項工做的工具」是有價值的。

4、最小化依賴項

當您頻繁部署許多更改時，確保組件對外部系統的依賴性最小（例如，經過使用隊列進行通訊，而不是同步請求/響應模式），這一點很重要。雖然微服務模式使得這一點幾乎是強制性的，但通常來講，使每一個組件儘量自給自足是有用的。一樣，不要過分考慮這一點，但一個好的經驗法則是儘可能使部署的每一個單元都儘量獨立。

未完待續，其他四個最佳實踐將在下篇文章中進行分享，盡情關注。

未經贊成，本文禁止轉載或摘編。​​​​