API 网关和服务网格：打开应用程序现代化的大门

本文要点

• 通过将应用程序与所运行的底层基础设施解耦来实现应用程序的现代化，可以实现创新(将工作负载转移到云计算或外部基于机器学习的服务)、降低成本并提高安全性。

• 容器技术和编排框架（如 Kubernetes）将应用程序与计算结构解耦，但也需要在网络基础设施上对它们进行解耦。

• API 网关通过将来自最终用户和第三方的请求动态路由到各种内部应用程序，而不管这些请求部署在数据中心的哪个位置，可以将应用程序与外部消费者解耦。

• 服务网格通过提供位置透明性、通过动态路由内部服务到服务的请求（无论它们暴露在网络上何处），将应用程序与内部消费者解耦。

• Ambassador API 网关和 Consul 服务网格都由 Envoy 代理提供支持，可用于从终端用户路由到部署在裸机、虚拟机和 Kubernetes 上的服务。这种技术的组合提供了一种增量迁移应用程序的方法，并可以提供端到端加密通信(TLS)和增强的可观察性。

软件系统现代化的核心目标之一是将应用程序与它们运行所在的底层基础设施解耦。这可以带来很多好处，包括：促进创新，例如，利用机器学习和“大数据”服务转移工作负载；通过更有效地分配资源或托管应用程序来降低成本；以及通过使用更适当的抽象或更有效地升级和组件补丁来提高安全性。使用容器和编制框架（如Kubernetes）可以将应用程序的部署和执行与底层硬件解耦。然而，并不是每个应用程序都可以迁移到这种类型的平台上，即使可以，通常组织也希望这是一个渐进的过程。因此，需要更高的抽象层来将流量路由与网络基础设施解耦：在边缘计算，则通过入口或 API 网关；在数据中心，则通过服务网格。

过去几个月在 Datawire 时，我们与 HashiCorp 团队进行了密切地合作，于最近发布了Ambassador API网关和 Consul 服务网格的集成。这两种技术的结合使应用程序的流量路由能够完成与底层部署和网络基础设施解耦。使用Envoy代理的功能，这两种技术都提供了从边缘服务器到服务的动态路由，以及跨裸金属、虚拟机和 Kubernetes 的服务到服务的动态路由。集成还支持端到端 TLS，并增加了对其他跨功能需求的支持。

应用程序现代化：解耦基础设施和应用程序

许多组织将“应用程序现代化”计划作为更大规模数字转型计划的一部分，正在实施该计划。这方面的目标分多个方面，但通常侧重于通过功能模块化和与云机器学习和大数据服务的集成增强创新能力，提高安全性，降低成本，以及在基础设施级别实现额外的可观察性和弹性特性。应用程序现代化工作常常伴随着向高基数的现代体系结构模式的转变，这些模式力求松散耦合，比如微服务和功能即服务(FaaS)，并采用“DevOps”或责任共担的方式来开展工作。

应用程序现代化的一个关键技术性目标是将应用程序、服务和功能与底层基础设施解耦。云供应商正在推广实现此目的的几种方法：

• AWS Outposts 通过安装完全由 AWS 管理的定制硬件，将 AWS 服务和运维模型带到用户现有的数据中心。

• Azure Stack 是 Azure 服务的一个扩展，它使用户能够在 Azure 云和他们自己的本地硬件上保持一致地构建和运行混合应用程序。

• 谷歌Anthos通过基于软件的抽象层和相关控制层将核心 GCP 服务扩展到用户的基础设施或另一个云上。

其他项目，如 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