後 Kubernetes 時代的微服務
原文鏈接：https://www.infoq.com/articles/microservices-post-kubernetes
作者：Bilgin Ibryam
英文校準：Daniel Bryant譯者：殷龍飛
關鍵要點
- 微服務架構仍然是分佈式系統最流行的架構風格。 但 Kubernetes 和雲原生運動已經大規模重新定義了應用程序設計和開發。
- 在雲原生平臺上，服務的可觀察性是不夠的。 更基本的先決條件是通過實施健康檢查，對信號做出反應，聲明資源消耗等，使微服務自動化。
- 在後 Kubernetes 時代，服務網格技術將完全取代使用庫來實現操作網絡問題（例如 Hystrix 斷路器）。
- 微服務現在必須通過從多個維度實現冪等性來設計用於“恢復”。
- 現代開發人員必須精通編程語言以實現業務功能，並且同樣精通雲本機技術以滿足非功能性基礎架構級別要求。
微服務炒作開始於一堆關於組織結構，團隊規模，服務規模，重寫和拋出服務而不是修復，避免單元測試等的極端想法。根據我的經驗，大多數這些想法被證明是錯誤的，而不是實用的，或者至少一般不適用。 如今，大多數剩餘的原則和實踐都是如此通用和鬆散地定義，以至於它們在未來許多年都會成立，而在實踐中卻沒有多大意義。
在 Kubernetes 誕生之前幾年被採用，微服務仍然是分佈式系統最流行的架構風格。 但 Kubernetes 和雲原生運動已經大規模重新定義了應用程序設計和開發的某些方面。 在本文中，我想質疑一些原始的微服務理念，並承認它們在後 Kubernetes 時代並不像以前那樣強大。
不僅可觀察，而且還有自動化服務
可觀察性從一開始就是微服務的基本原則。 雖然對於一般的分佈式系統來說它是正確的，但今天（特別是在 Kubernetes 上），它的很大一部分是平臺級別的開箱即用（例如進程運行狀況檢查，CPU 和內存消耗）。 最低要求是應用程序以 JSON 格式登錄控制檯。 從那時起，平臺可以跟蹤資源消耗，請求跟蹤，收集所有類型的指標，錯誤率等，而無需太多的服務級別開發工作。
在雲原生平臺上，可觀察性是不夠的。 更基本的先決條件是通過實施健康檢查，對信號做出反應，聲明資源消耗等使微服務自動化 。可以將幾乎任何應用程序放入容器中並運行它。 但是要創建一個容器化的應用程序，可以通過雲原生平臺自動化和協調編排，需要遵循一定的規則。 遵循這些 原則和模式 ，將確保生成的容器在大多數容器編排引擎中表現得像一個優秀的雲本地公民，允許以自動方式對它們進行調度，擴展和監視。
我們希望平臺不必觀察服務中發生的情況，而是希望平臺檢測異常情況並按照聲明進行協調。 無論是通過停止將流量引導到服務實例，重新啓動，向上和向下擴展，還是將服務移動到另一個健康的主機，重試失敗的請求或其他，這都無關緊要。 如果服務是自動化的，則所有糾正措施都會自動發生，我們只需要描述所需的狀態，而不是觀察和反應。 服務應該是可觀察的，但也可以在沒有人爲干預的情況下通過平臺進行整改。
智能平臺和智能服務，但有正確的責任
在從 SOA 轉向微服務世界的過程中， “智能端點和啞管”的概念是服務交互的另一個根本轉變。 在微服務領域，服務不依賴於集中式智能路由層的存在，而是依賴於擁有某些平臺級功能的智能端點。 這是通過在每個微服務中嵌入傳統 ESB 的一些功能並轉換到沒有業務邏輯元素的輕量級協議來實現的。
雖然這仍然是在不可靠的網絡層（使用 Hystrix 等庫 ） 實現服務交互的流行方式 ，但現在，在後 Kubernetes 時代，它已經完全被服務網格技術所取代 。 有趣的是，服務網格甚至比傳統的 ESB 更智能。 網格可以執行動態路由，服務發現，基於延遲的負載平衡，響應類型，指標和分佈式跟蹤，重試，超時，你能想到的這裏都有。
與 ESB 的不同之處在於，與服務網格不同的是，只有一個集中路由層，每個微服務通常都有自己的路由器 - 一個帶有附加中央管理層的代理邏輯的 sidecar 容器。 更重要的是，管道（平臺和服務網格）沒有任何業務邏輯; 他們完全專注於基礎架構問題，使服務專注於業務邏輯。 如圖所示，這代表了 ESB 和微服務學習的演變，以適應雲環境的動態和不可靠特性。
SOA vs MSA 與 CNA
查看服務的其他方面，我們注意到雲原生不僅影響端點和服務交互。 Kubernetes 平臺（包含所有其他技術）還負責資源管理，調度，部署，配置管理，擴展，服務交互等。而不是再次將其稱爲“智能代理和啞管”，我認爲它更好地描述作爲一個具有正確職責的智能平臺和智能服務。 這不僅僅是關於端點; 它是一個完整的平臺，可以自動化主要關注業務功能的服務的所有基礎架構方面。
不要設計失敗，設計恢復
在基礎架構和網絡本身不可靠的雲原生環境中運行的微服務必須針對故障進行設計。 毫無疑問。 但是平臺檢測到並處理了越來越多的故障，並且從微服務中捕獲故障的量較少。 相反，考慮通過從多個維度實現冪等性來設計您的恢復服務。
容器技術，容器協調器和服務網絡可以檢測並從許多故障中恢復：無限循環 - CPU 分配，內存泄漏和 OOM - 運行狀況檢查，磁盤佔用 - 配額，fork 炸彈 - 進程限制，批量處理和進程隔離 - 內存限制，延遲和基於響應的服務發現，重試，超時，自動擴展等等。更不用說，過渡到無服務器模型，服務只能在幾毫秒內處理一個請求，關注垃圾收集，線程池，資源泄漏也越來越不相關……
通過平臺處理所有這些以及更多內容，將您的服務視爲一個密封的黑盒子，它將多次啓動和停止 - 使服務能夠重新啓動。 您的服務將按比例放大和縮小倍數 - 通過使其無狀態，使其可以安全地進行擴展。 假設許多傳入請求最終會超時 - 使端點具有冪等性。 假設許多傳出請求將暫時失敗，平臺將爲您重試它們 - 確保您使用冪等服務。
爲了適合雲原生環境中的自動化，服務必須是：
- 冪等重啓（服務可以被殺死並多次啓動）。
- 冪等擴展/縮小（服務可以自動擴展到多個實例）。
- 冪等服務生產者（其他服務可能會重試調用）。
- 冪等服務使用者（服務或網狀網可以重試傳出調用）。
如果您執行上述操作一次或多次時服務的行爲始終相同，那麼平臺將能夠在沒有人爲干預的情況下從故障中恢復您的服務。
最後，請記住，平臺提供的所有恢復只是本地優化。 正如 Christian Posta 所說的那樣 ，分佈式系統中的應用程序安全性和正確性仍然是應用程序的責任。 整個業務流程範圍的思維模式（可能跨越多個服務）對於設計整體穩定的系統是必要的。
混合開發職責
越來越多的微服務原則被 Kubernetes 及其補充項目實施和提供。 因此，開發人員必須精通編程語言以實現業務功能，並且同樣精通雲本機技術以滿足非功能性基礎架構級別要求，同時完全實現功能。
業務需求和基礎架構（操作或跨功能需求或系統質量屬性）之間的界限總是模糊不清，並且不可能採取一個方面並期望其他人做另一個方面。 例如，如果在服務網格層中實現重試邏輯，則必須使服務中的業務邏輯或數據庫層使用的服務具有冪等性。 如果在服務網格級別使用超時，則必須同步服務中的服務使用者超時。 如果必須實現服務的重複執行，則必須配置 Kubernetes 作業以執行時間執行。
展望未來，一些服務功能將作爲業務邏輯在服務中實現，而其他服務功能則作爲平臺功能提供。 雖然使用正確的工具來完成正確的任務是一個很好的責任分離，但技術的激增極大地增加了整體的複雜性。 在業務邏輯方面實現簡單的服務需要很好地理解分佈式技術堆棧，因爲責任分散在每一層。
據 證實 是 Kubernetes 可以擴展到數千個節點，每秒事務莢數以百萬計的數萬人。 但它可以縮小嗎？ 您的應用程序大小，複雜性或關鍵性的閾值證明了引入“雲原生”複雜性的原因尚不清楚。
結論
有趣的是，微服務運動如何爲採用 Docker 和 Kubernetes 等容器技術提供瞭如此大的動力。 雖然最初是推動這些技術發展的微服務實踐，但現在 Kubernetes 定義了微服務架構的原則和實踐。
作爲最近的一個例子，我們距離接受函數模型作爲有效的微服務原語並不遠，而不是將其視爲納米服務的反模式。 我們並沒有充分質疑雲原生技術對於中小型案例的實用性和適用性，而是因爲興奮而有些不經意地跳了起來。
Kubernetes 擁有 ESB 和微服務的許多知識，因此，它是最終的分佈式系統平臺。 它是定義建築風格的技術，而不是相反的方式。 無論好壞，只有時間會顯示出來。
關於作者
Bilgin Ibryam （@bibryam）是 Red Hat 的首席架構師，提交者和 ASF 成員。 他是一名開源傳播者，博客作者，Camel Design Patterns和Kubernetes Patterns書籍的作者。 在他的日常工作中，Bilgin 喜歡指導，編碼和領導開發人員成功構建雲原生解決方案。 他目前的工作重點是應用程序集成，分佈式系統，消息傳遞，微服務，devops 和一般的雲原生挑戰。 你可以在 Twitter ， Linkedin 或他的 博客 上找到他 。