本文要點
-
通過將應用程序與所運行的底層基礎設施解耦來實現應用程序的現代化，可以實現創新(將工作負載轉移到雲計算或外部基於機器學習的服務)、降低成本並提高安全性。
-
容器技術和編排框架（如Kubernetes）將應用程序與計算結構解耦，但也需要在網絡基礎設施上對它們進行解耦。
-
API網關通過將來自最終用戶和第三方的請求動態路由到各種內部應用程序，而不管這些請求部署在數據中心的哪個位置，可以將應用程序與外部消費者解耦。
-
服務網格通過提供位置透明性、通過動態路由內部服務到服務的請求（無論它們暴露在網絡上何處），將應用程序與內部消費者解耦。
-
Ambassador API網關和Consul 服務網格都由Envoy代理提供支持，可用於從終端用戶路由到部署在裸機、虛擬機和Kubernetes上的服務。這種技術的組合提供了一種增量遷移應用程序的方法，並可以提供端到端加密通信(TLS)和增強的可觀察性。
軟件系統現代化的核心目標之一是將應用程序與它們運行所在的底層基礎設施解耦。這可以帶來很多好處，包括：促進創新，例如，利用機器學習和“大數據”服務轉移工作負載；通過更有效地分配資源或託管應用程序來降低成本；以及通過使用更適當的抽象或更有效地升級和組件補丁來提高安全性。使用容器和編制框架（如Kubernetes）可以將應用程序的部署和執行與底層硬件解耦。然而，並不是每個應用程序都可以遷移到這種類型的平臺上，即使可以，通常組織也希望這是一個漸進的過程。因此，需要更高的抽象層來將流量路由與網絡基礎設施解耦：在邊緣計算，則通過入口或API網關；在數據中心，則通過服務網格。
過去幾個月在Datawire時，我們與HashiCorp團隊進行了密切地合作，於最近發佈了Ambassador API網關和 Consul 服務網格的集成。這兩種技術的結合使應用程序的流量路由能夠完成與底層部署和網絡基礎設施解耦。使用Envoy代理的功能，這兩種技術都提供了從邊緣服務器到服務的動態路由，以及跨裸金屬、虛擬機和Kubernetes的服務到服務的動態路由。集成還支持端到端TLS，並增加了對其他跨功能需求的支持。
應用程序現代化：解耦基礎設施和應用程序
許多組織將“應用程序現代化”計劃作爲更大規模數字轉型計劃的一部分，正在實施該計劃。這方面的目標分多個方面，但通常側重於通過功能模塊化和與雲機器學習和大數據服務的集成增強創新能力，提高安全性，降低成本，以及在基礎設施級別實現額外的可觀察性和彈性特性。應用程序現代化工作常常伴隨着向高基數的現代體系結構模式的轉變，這些模式力求鬆散耦合，比如微服務和功能即服務(FaaS)，並採用“DevOps”或責任共擔的方式來開展工作。
應用程序現代化的一個關鍵技術性目標是將應用程序、服務和功能與底層基礎設施解耦。雲供應商正在推廣實現此目的的幾種方法：
-
Azure Stack 是Azure服務的一個擴展，它使用戶能夠在Azure雲和他們自己的本地硬件上保持一致地構建和運行混合應用程序。
其他項目，如Ambassador、Consul、Istio和Linkerd等，旨在構建與現有的雲無關的、基於容器的部署抽象，並在網絡上提供更高的抽象層，以支持應用程序和基礎設施的解耦。Docker使容器作爲部署單元的用法流行開來，谷歌認識到大多數應用程序都是以一系列容器來部署的，並將其命名爲Kubernetes中的“pod”。在這裏，容器共享一個網絡和文件系統命名空間，提供日誌記錄或度量採集的通用容器可以與應用程序組合在一起。在pods中部署的業務功能通過“服務”抽象公開，該抽象提供名稱和網絡端點。使用這種抽象可以將部署和發佈分離開來。可以在任何給定時間部署服務的多個版本，並且可以通過有選擇性地將流量路由到後端pod(例如，“影子”流量或“金絲雀發佈”)來測試或發佈功能。這種動態路由通常通過代理來實現，包括邊緣代理(“邊緣代理”或“API網關”)和服務之間的代理（服務間代理，統稱爲“服務網格”）。
對於許多組織來說，最大的挑戰之一是在不影響最終用戶和內部開發和運營團隊的情況下實現應用程序和基礎設施的解耦。鑑於典型的企業IT資產中基礎設施和應用程序的多樣性（想想大型機、裸金屬、虛擬機、容器、商用現成方案、第三方應用程序、SaaS、內部微服務等等），一個關鍵目標就是建立一個清晰的路徑，使遺留應用程序可以增量現代化或遷移到新的基礎設施上，如Kubernetes和雲服務。
不受干擾的現代化和遷移：API網關和服務網格的角色
開源Envoy 代理已經席捲全球的現代基礎設施，有個很好的理由能解釋它：這個代理出生在“雲本地”和關注七層(應用程序)協議的時代，因此，可以非常有效且高效地應對所有現代基礎設施的特點和相關的開發人員/運維人員用例。像 Lyft、eBay、Pinterest、Yelp和Groupon這樣的終端用戶組織，連同所有主要的雲供應商，正在使用邊緣端的Envoy和服務到服務來實現服務發現、路由和可觀察性。至關重要的是，他們經常使用Envoy在舊的大型機和基於虛擬機的應用程序與更現代的基於容器的服務之間架起溝通的橋樑。
雖然數據層（網絡代理實現本身）非常強大，但是控制層（可配置和觀察代理）的學習曲線確實也很陡峭。因此，出現了一些額外的開源項目，以簡化開發人員使用Envoy的體驗。Datawire的Ambassador API網關是一個由環境驅動的邊緣代理，當用於管理入口或“南-北”流量時，它提供了一個簡化的控制層來配置Envoy。HashiCorp的Envoy服務網格是一個用於服務到服務通信或“東-西”流量的控制層，它支持在其可插拔代理配置範圍內的Envoy。
使用這兩項技術的主要原因是，它們使應用程序能夠在任何地方運行，同時保持可用性，並能連接外部和內部用戶：
-
API網關將應用程序的組成和位置與外部消費者解耦。API網關動態地將來自最終用戶、移動應用程序和第三方的外部請求路由到各種內部應用程序，而不管它們部署在何處。
-
服務網格通過提供位置透明性將應用程序與內部消費者解耦。服務網格動態地將內部服務到服務的請求路由到各種應用程序，而不管它們部署在哪裏。
Ambassador和Consul：路由到虛擬機、容器等
Consul的典型部署包括多個Consul服務器(提供高可用性)和在每個節點上的Consul代理。Consul充當整個數據中心的配置“真相之源”，跟蹤可用的服務和配置、端點，併爲TLS加密存儲祕密內容。通過使用Consul進行服務發現，Ambassador能夠從面向用戶的端點或類似類REST API路由到數據中心中的任何Consul服務，無論是運行在裸機、虛擬機還是Kubernetes上。Consul還可以透明地通過Envoy代理路由服務到服務的流量(使用服務“邊車”模式)，這確保了端到端流量完全受TLS保護。
Ambassador作爲應用程序和服務的共同入口點，爲南-北通信流量提供交叉功能，例如用戶身份驗證、速率限制、API管理和TLS終止。Consul充當服務網格，使服務名稱的定義能夠提供位置透明性，策略即代碼可以以聲明的方式指定已定義的橫切安全性關注點，比如網絡“分段”。具有防火牆規則或IP表的服務到服務的通信安全在動態設置中不可伸縮，因此服務分割是一種通過服務標識(而不是依賴於特定於網絡的屬性)來保護服務的新方法；爲了使用服務名稱定義訪問策略，應避免使用複雜的基於主機的安全組和網絡訪問控制表。
入門指南
Ambassador使用的一種基於Kubernetes註釋的聲明式配置格式。因此，要使用Consul進行服務發現，首先要將Consul 註冊爲一個解析器，方法是在Kubernetes服務中放一段註釋：
apiVersion: ambassador/v1
kind: ConsulResolver
name: consul
address: consul-server
datacenter: dc3
現在可以使用標準的基於註釋的配置格式將Ambassador配置爲路由到任何服務。所有Ambassador 功能都得到了充分的支持，如gRPC、超時，以及可配置的負載平衡。下面的例子演示了/foo/和在Consul中註冊的foo服務的代理(“foo-proxy”)之間的映射：
apiVersion: ambassador/v1
kind: Mapping
prefix: /foo/
service: foo-proxy
timeout_ms: 5000
resolver: consul-server
tls: consul-tls-cert
load_balancer:
policy: round_robin
雖然tls屬性是可選的，但是它定義了Ambassador 用於與Consul服務代理通信的tls上下文。Ambassador通過ConsulAPI自動同步TLS證書。爲保證所有的流量是安全的，服務本身應該配置爲只接受來自於Consul服務代理的流量，例如，通過配置一個Kuberntes pod內的服務綁定到本地網絡地址，或通過配置底層虛擬機只接受該代理正在監聽的端口的入站通信。
在數據中心部署Ambassador 和Consul還有幾個額外的好處。在邊緣計算中使用諸如Envoy之類的七層感知代理意味着像HTTP/2和gRPC之類的現代協議將得到適當的負載平衡（爲什麼四層負載平衡器在這種情況下不適用呢，大家就此進行了充分地討論，如有興趣請閱讀文章“我們在Geckoboard推出了Envoy ”）。Consul還提供了在構建分佈式系統時會用到的其他原語，比如鍵值存儲（它還包括監視條目的能力）、分佈式鎖和健康檢查，並且它還支持多個開箱即用的數據中心。
相關技術
IBM、谷歌和其他一些組織和個人創建了Istio項目，爲Envoy提供一個簡化的控制層，主要用於服務間通信。該項目後來添加了一個用於管理入口的“網關”概念，這一概念仍在演進之中。目前Istio只支持在Kubernetes上部署，但是更多的平臺支持已經有了規劃。Buoyant 已經創建了Linkerd服務網格，雖然主要集中於管理東-西流量，但也提供了與流行的南-北代理的集成。Kong API gateway團隊也有一個由NGINX支持的早期服務網格解決方案。
小心“大爆炸”服務網格的推出
我在Datawire工作的時候，與幾個組織進行了交談，他們已經嘗試了在組織範圍內推出服務網格。網絡運維可以說是軟件交付中最後堡壘之一，它仍然相對集中，即使採用了雲計算和軟件定義網絡(SDN)，有時這導致人們認爲任何網絡技術都必須進行集中管理。通常，在部署服務網格時，這種方法的效果並不好。在大型企業中，會協調所有工程師將所有應用程序集中到一個網格中，這似乎並不合理。相反，採用增量的方法似乎更實用，我認爲這應該從邊緣計算開始。一旦組織能夠將外部公開的應用程序和產品的配置和發佈去中心化，並學習如何利用現代代理提供的功能，就取得了一個理想的開端，可以繼續針對內部服務逐步推出服務網格。
推出服務網格的第一次迭代通常側重於路由。正如我在上文中Ambassador 和Consul的配置中所演示的，一旦有了現代邊緣代理，就可以有選擇地將流量路由遷移到現有的Consul註冊服務，而不管它們部署在何處或是如何部署的。一旦路由完成，您就可以在每個服務旁邊添加Consul代理，並安全地（使用TLS）將流量從邊緣服務器路由到每個服務端點。在數據中心中，完全可以混合使用實現TLS的服務和一些純文本。其目標通常是確保所有通信的安全，並且使用Ambassador和Consul的組合，逐步推出從終端用戶到服務的通信的端到端加密是完全有可能的。
總結
在本文中，我討論了將應用程序與基礎設施的解耦作爲應用程序現代化計劃的一部分的動機。我研究瞭如何部署集成的API網關和服務網格，從而提供一個增量路徑，將流量從最終用戶路由到新服務和現有服務，而不管這些應用程序部署在何處。如果將應用程序遷移到較新的平臺，則應用程序用於將流量從邊緣服務器路由到服務或服務到服務的標識保持不變。此外，實現這種網關到網格的解決方案還有其他幾個好處，包括端到端流量加密和應用程序級網絡度量（包括全局和服務到服務）的可觀察性的改進。
有關Ambassador 和Consul集成的詳細信息可以在Ambassador 文檔中找到，在Consul文檔中可以找到一份指南。
關於作者
Daniel Bryant是Datawire的獨立技術顧問和產品架構師。他的技術專長集中於“DevOps”工具、雲/容器平臺和微服務實現。Daniel是Java的擁護者，併爲幾個開源項目做出了貢獻。他還爲InfoQ、O 'Reilly和TheNewStack撰寫文章，並定期出席OSCON、QCon和JavaOne等國際峯會。有充裕的空閒時間時，他喜歡跑步、閱讀和旅行。
查看英文原文：API Gateways and Service Meshes: Opening the Door to Application Modernisation