容器、服務網格和 API 網關：從邊緣開始
原文：https://devops.com/containers-service-mesh-and-api-gateways-it-starts-at-the-edge/
譯者：崔秀龍
Docker 和 Kubernetes 為代表的容器技術炙手可熱，熟知這一技術領域的用戶，一定都知道下一個熱點：Service Mesh，它承諾將微服務之間的內部網路通信均一化，並解決一系列監控、故障隔離等通用非功能性需求。底層的代理伺服器技術是 Service Mesh 的立身之本，這種技術在 Service Mesh 之外，還能以 API 網關的形式在邊緣為業務系統提供一系列的增強。
雖說 Service Mesh 的爆發之勢讓人誤以為羅馬是一日建成的，事實上，在這一熱點浮出水面之前，包括 Verizon、eBday 以及 Facebook 在內的很多組織已經在應用後來被我們稱之為 Service Mesh 的技術了。這些早期應用 Service Mesh 的組織之一就是 Lyft，這是一家年收入超過十億美元的美國網約車巨頭。Lyft 還是開源軟體 Envoy Proxy 的誕生地，Envoy 在 Service Mesh 世界中舉足輕重，Kubernetes 原生的 Istio 控制面 和 Ambassador API 網關 也都建築在 Lyft 的基礎之上。
SOA 網路的煩惱
Matt Klein 是 Envoy Proxy 的作者之一，他去年的一次談話中說到，SOA（面向服務的架構）和微服務網路是「混亂的龐然大物」。身處其中的每個應用都輸出了不同的統計和日誌，整個服務堆棧如何處理請求生成響應的過程也是無法跟蹤的，在這樣的情況下進行 Debug 的巨大難度也就可以想像了。同時對類似負載均衡器、緩存以及網路拓撲這樣的基礎設施組件的監控能力也是很有限的。
他覺得：「這很痛苦，我認為多數公司都贊同 SOA（微服務）是個可見趨勢，在這一趨勢的踐行過程中會收穫很多，但是其中也滿是痛苦。主要的痛苦來源就是 Debug」。
對於大規模組織來說，分散式 Web 應用的可靠性和高可用支持是一個核心挑戰。這種挑戰的應對方式中，普遍包含包含重試、超時、頻率控制和熔斷等功能邏輯的各種實現。很多系統，不論開源與否，都會使用鎖定特定語言（甚至鎖定框架）的形式來實現這種方案，這就意味著開發人員也同時被進行鎖定。Klein 和他在 Lyft 的團隊認為，一定有更好的辦法。最終 Envoy 項目誕生了。
外部干預：邊緣代理的優勢
2016 年 9 月 以開源形式發布了 Envoy Proxy，Klein 和 Lyft 工程師團隊一夕成名，但這並非一蹴而就，Lyft 架構從最初的混合 SOA 架構起步，花費了四年，突破層層險阻升級為服務網格治理之下的微服務體系。2017 年的微服務實踐者虛擬峰會上，Klein 講述了向服務網格進行技術遷移的過程中面對基本需求和相關挑戰，及其商業價值。
Klein 的第一次艱苦取勝是「從邊緣代理開始」的。微服務為基礎的 Web 應用需要在邊緣提供反向代理，一方面可以防止暴露內部業務服務介面（會違反松耦合原則），另一方面，暴露大量服務也意味著大量的獨立 URI 以及 RPC 端點，這會消耗大量的運維資源。現存的雲所提供的邊緣代理伺服器或者網關都不很好，不同產品呈現給工程師的是不同的、易混淆的工作界面。Klein 倡議在邊緣實現一個現代化的代理服務，在其中提供改進的監控、負載均衡以及動態路由能力，以此來產生商業價值。工程師團隊理解和掌握了邊緣代理的運維之後，就可以向內部團隊進行推廣，最終形成內部的服務網格了。
邊緣進化：從代理到 API 網關
AppDirect 是一個端到端提供雲端產品和服務管理的商業平台，預計年收入 5000 萬美元。在 AppDirect 最近的博客 Evolution of the AppDirect Kubernetes Network Infrastructure 中，他們著重介紹了和 Lyft 類似的經歷。雲技術和 Kubernetes 之類的編排平台帶來的不只是有規模、彈性之類的好處，還因為與生俱來的易變和動態特性，提出了新的挑戰：微服務構建的商業功能如何合適的在公共端點上提供服務？
AppDirect 工程師團隊採用了一種可靠的方法來應對挑戰，首先把配置的核心部分（例如暴露的服務埠）靜態化，然後在每個應用之前部署負載均衡器。接下來的迭代就是使用 HashiCorp 的分散式鍵值庫 Consul 結合支持熱重載的 HAProxy 反向代理來提供更好的動態管理能力。團隊的終極目標是用更豐富功能的 API 網關來提供更豐富的功能。
文中說到：「API 網關的目標是在不變更已公開 API 的訪問性的情況下（這種不經變更的可訪問性也包含了舊有的 URL 以及友商的定製域名等），通過注入和替換的方式逐個實現轉換過程。」
在對一系列的開源和商業產品進行評估之後，AppDirect 團隊選擇了構建在 Envoy proxy 之上的 Kubernetes 原生的 Ambassador API 網關產品：
「構建於我們了解和喜愛的 Kubernetes API 之上的 Ambassador，是一個輕量、穩定以及沒有外部資料庫依賴的產品。Ambassador 很獨特，使用 Kubernetes 對象標註功能來定義路由配置（也就是以此實現 Envoy 數據面的控制平面）」——團隊博客如是說。
雖然 AppDirect 還沒有完全實現內部通信的網格化，但是已經感受到了 Envoy Proxy 這樣的技術所帶來的好處，更學到了在產品中應用這些技術的能力。
星火燎原
服務網格技術的實現和遷移過程才剛剛開始，但是已經可以肯定，這一技術彌合了 Kubernetes 這樣的現代容器化平台中應用之間的鴻溝。服務網格帶來的，包括頻率控制、斷路器以及監控性等在內的所有好處，都可以從服務邊緣開始享用。如果想要對這一技術進行進一步的探索和學習，在系統邊緣開始，農村包圍城市是一種行之有效的策略。這種策略無需全面部署，就能迅速的在監控、彈性等方面展示出特有的商業價值。
活動預告
TAG:ServiceMesher |