容器、服務網格和API閘道器：它始於邊緣

SOA網路狀態

Envoy Proxy的創造者之一Matt Klein在在去年的一次演講中，認為除錯很困難或者幾乎不可能，每個應用程式都有不同的統計資訊和日誌記錄，無法跟蹤整個請求/響應的服務呼叫路徑。基礎架構元件（如託管負載平衡器，快取和網路拓撲）的可見性(可管理性)也很有限。


“這很痛苦，”他說。“我認為大多數公司和大多陣列織都知道SOA（微服務）是未來，但除錯是困難的。“

保持分散式網路應用程式的可靠性和高可用性是大型公司的核心挑戰。具有挑戰性的方案通常包括重試邏輯的實現、超時、速率限制和斷路等。許多定製的或開源解決方案都使用了特定語言（甚至可能是特定於框架的）解決方案，這意味著工程師無意中將自己鎖定在“基本上永遠”的技術堆疊中(banq注，大概指的是Spring Cloud)。Klein和他在Lyft的團隊認為必須有更好的方法。最終，Envoy代理專案被認為是更好的方式。(banq注：Istio/Envoy與Spring cloud是互補關係？)

在微容器外部工作：邊緣代理的好處

雖然Envoy Proxy專案的開源版本使得Klein和Lyft工程團隊在2016年9月看起來像是一夜之間取得成功，但現實情況是，這一過程在微服務和服務網路系統之間充滿了挑戰。在最近一次關於2017年微服務實踐者虛擬峰會的演講中，Klein談到了從面向技術轉向服務網狀網路拓撲的商業價值和相關挑戰。

Klein第一個珍貴建議是“從邊緣代理開始”。基於微服務的Web應用程式需要邊緣反向代理以避免內部業務服務介面的暴露（因為這會違反松耦合的原則），也避免透過獨立的URI或RPC端點暴露每項服務的高運營開銷。現有的雲產品在這個邊緣代理或閘道器領域“不太友好”，或者作為潛在令人困惑的不同產品呈現給工程師。相反，Klein建議在邊緣開始實施現代代理技術，這會提供了改進的可觀察性、負載平衡和動態路由的等業務價值。

邊緣的演變：從代理到API閘道器

AppDirect是用於管理基於雲的產品，並估計有5000萬$年收入的端到端的電子商務平臺，實現了類似Lyft方式，他們在最近的一篇部落格強調，為了透過微服務的組合實現提供的業務功能，在暴露公共端點方面充滿了挑戰。


AppDirect工程團隊採取了一系列措施來解決這些挑戰：首先將配置的核心部分設定為靜態（例如暴露的服務埠）並將負載平衡器放置在每個應用程式的前端。他們的第二次迭代使用HashiCorp的Consul分散式金鑰/值儲存和HAProxy反向代理來支援更多動態，該代理支援在執行時更改配置的“熱重新載入”。然而，最終團隊熱衷於利用功能更加全面的API閘道器提供的更豐富的功能。

“我們使用API閘道器的目標是讓暴露的公共API不可接觸但是可訪問，這樣可透過”注入“逐個替換舊的元件，逐步發展壯大。” 。


在評估了一系列開源和商業產品之後，AppDirect團隊部署了基於Envoy代理構建的Kubernetes的API閘道器：


“完全依賴於Kubernetes原生API - 我們瞭解並且喜歡 - Ambassador是輕量級，無狀態的，並且不使用外部資料儲存。Ambassador專門利用Kubernetes註釋來驅動主動路由配置（即它是Envoy資料皮膚的控制皮膚），“該小組在部落格文章中指出。


雖然AppDirect尚未完全實施內部通訊的服務網格，但該公司已經瞭解Envoy代理等技術的好處，並且至關重要的是，如何在生產環境中處理這種部署。

讓所有人都感覺到它

在雲應用實施和遷移中採用服務網格技術才剛剛開始，但已經有可能確定該技術填補了當前技術與現代基於容器的應用程式平臺（如Kubernetes）的差距。服務網格的所有優點（如速率限制，斷路和可觀察性）也可以在系統邊緣獲得並利用。如果你想探索和了解這項技術，從系統的邊緣開始並努力工作可能是一種有效的策略。這也可以使該技術比試圖徹底解決問題更早顯示價值，例如提高可觀察性和彈性。

Containers, Service Mesh and API Gateways: It Star