-微服務架構
微服務是一種分佈式架構風格。它具有多種優點，例如：
. 可以提高可擴展性。
. 開發團隊可以獨立工作並變得更加敏捷。
. 服務的獨立性提高了代碼的可重用性。
. 系統的整體架構可以與組織結構保持一致。
但是，由於分佈式架構的性質，微服務的可用性、可管理性和監控可能需要更多的開銷。可擴展性和可用性的概念經常被混淆。可伸縮性是關於服務可以服務多少客戶端，而可用性是客戶端可以可靠和及時地訪問服務的程度。
服務或系統可以採用不同的可擴展性策略，例如，縱向擴展或橫向擴展。擴展策略可能不會提高可用性。橫向擴展策略在不同程度上有助於提高可用性，例如，沒有心跳檢查的基於 DNS 的循環負載均衡器呈現的可用性程度低於檢查服務健康狀態的基於集群的負載均衡器。
以下是 NIST SP 800-204 的摘錄：
微服務的優勢
. 對於大型應用程序，將應用程序拆分為鬆散耦合的組件可以實現分配給每個組件的開發團隊之間的獨立性。然後，每個團隊都可以通過選擇自己的開發平台、工具、語言、中間件和硬件來優化，基於它們對正在開發的組件的適用性。
. 每個組件都可以獨立縮放。資源的有針對性的分配導致資源的最大利用。
. 如果組件具有 HTTP RESTful 接口，只要接口保持不變，就可以在不中斷應用程序整體功能的情況下更改實現。
. 每個組件中涉及的代碼庫相對較小，使開發團隊能夠更快地生成更新，並為應用程序提供響應業務流程或市場條件變化的敏捷性。
. 組件之間的鬆散耦合能夠抑制微服務的中斷，從而將影響限制在該服務上，而不會對其他組件或應用程序的其他部分產生多米諾骨牌效應。
. 當組件使用異步事件處理機制鏈接在一起時，組件中斷的影響是暫時的，因為所需的功能將在組件再次開始運行時自動執行，從而保持業務流程的整體完整性。
. 通過將服務定義與業務能力對齊（或通過基於業務流程或能力的整體應用程序功能的分解邏輯），基於微服務的系統的整體架構與組織結構保持一致。當與組織單位相關的業務流程發生變化並因此需要修改和部署相關服務時，這促進了敏捷響應。
. 微服務的獨立功能特性促進了跨應用程序的代碼更好的可重用性。
. 必須監控多個組件（微服務）而不是單個應用程序。需要一個中央控制台來獲取每個組件的狀態和應用程序的整體狀態。因此，必須創建具有分佈式監控和集中查看功能的基礎設施。
. 多個組件的存在會造成可用性問題，因為任何組件都可能隨時停止運行。
. 一個組件可能必須為某些客戶端調用另一個組件的最新版本，並為另一組客戶端調用同一組件的先前版本（即版本管理）。
. 運行集成測試更加困難，因為需要一個測試環境，其中所有組件都必須工作並相互通信。
. 當基於微服務的應用程序內的交互設計為 API 調用時，必須實現安全 API 管理所需的所有必要流程。
. 微服務架構可以分解縱深防禦的做法。許多架構都有一個運行在 DMZ 中的 Web 服務器，預計會受到威脅，然後是 Web 服務器與之通信的後端服務，最後是後端服務與之通信的數據庫。後端服務可以充當暴露的 Web 服務器和數據庫中的敏感數據之間更堅固的層。微服務架構往往會破壞這一點，現在 Web 服務器和後端服務被分解為微服務，可能比以前的模型暴露得更多。這會導致調用者和敏感數據之間的保護層更少。因此，安全地設計和實現微服務本身以及服務網格或API 網關部署模型。
參考
. NIST SP 800-204
資料來源： Wentz Wu QOTD-20210822
PS:此文章經過作者同意刊登 並且授權可以翻譯成中文
