随着服务网格的普及率达到前所未有的高度,是时候仔细考虑下服务网格可能会对你当前的架构产生什么样的影响。 你可能会认为必须完全重新设计你的环境,可能还没有准备好拥抱网格。 但实际上,你可以将服务网格集成到你当前的堆栈中工作。

在这里,网关可以发挥非常重要的作用。 本文将探讨如何在当前架构中使用网关的常见方法。 我将在这个例子中使用 Istio,因为这个开源网格中有着令人兴奋的新功能,使网关更加出色。

网关是什么?

Istio 将网关定义为 “在网格边缘运行的负载均衡器,接收传入或传出的 HTTP/TCP 连接”。 这个定义似乎已经过时了,因为用户应该在网格的边缘和内部使用网关。 现在,我们将网关定义为 一个负载均衡器,它将一个或一组 API 的内部内容从它所面对的微服务中抽象出来

新式网关

Istio 正在以极快的速度发展,其中一个备受关注的领域是网关设置和网络。 随着 Istio Operator 的推出,用户可以轻松地为工作负载配置任意数量的网关。 你可以 比以前更轻松地部署和配置轻量级负载均衡器。 由于新式网关相对较低的成本和更好的易用性,我们现在不仅可以在网格边缘,还可以在网格内部添加网关。

将大量网关部署到网格中是个不错的开始,但这只是第一部分。 在 Tetrate,我们希望这些网关易于访问和能被自动发现。 我们希望让团队能够轻松地在内部和外部共享其 API。 要做到这一点,网关需要易于识别,并且通常在集群或区域间可用。 有时网关甚至可能也需要在云间可用。

共享的入口网关

很多组织第一次采用 Kubernetes 时,都会接触到一个单一的入口解决方案 ——Nginx 入口控制器。 对于许多人来说,尽管他们 Kubernetes 经验逐渐成熟,这个单点入口基本上保持不变,以至于许多团队可能会依赖它。 有些人可能会迁移到 Istio 入口网关,但单点入口点仍然存在。 从管理的角度来看,这似乎是符合逻辑的,但随着越来越多的团队依赖它,它可能会成为一个单点故障。

相反的,我们建议为每个产品提供一个入口网关(由你自己定义)。 这消除了不应该共享故障域的组和产品之间的依赖性。 它还将故障与配置错误和升级隔离开来。 正如我们将在下面看到的那样,它还允许产品在为多集群产品做好准备时独立扩展。 在 Istio 的帮助下,将应用迁移到多个网关是非常简单的事,并且我们仍然可以从一个集中的位置进行管理网关。 我建议可以从这里入手,向着多集群架构改进。

单一入口网关

入口在被隔离的组和产品之间共享。 在下面的例子中,Payments 组和 Analytics 组共享一个集群和 Ingress 网关。 它们在两个不同的主机上监听 payments.my-company.io 和 analytics.my-company.io。

Single

多入口网关

将入口网关与其所代表的 API 和产品隔离开来。 我们决定将 Payments 网关添加到 Payments 命名空间中,它是整个产品的自包含部分。 因为 Analytics 产品涵盖了多个产品,我们决定将网关放在一个隔离的命名空间中,以便于在它们之间进行管理。

支付服务的扩展

好消息! 支付服务取得了巨大的成功,它亦在组织中比以往任何时候都重要。 你需要考虑更多的目标以扩展支付服务。 比如客户要求更多的功能、需要拆分微服务、需要考虑高可用性等等。 通过采用网关架构,你可以在不影响客户端的前提下更好地实现这些目标。

Separated

步骤 1: 添加网关

通过添加一个专注于产品的网关,你只需要为客户端创建一个单点入口就可以从底层微服务中抽象出 API。 现在,你可以随着需求的增加而扩展应用,并且不会影响到客户端。

实现方式:

  • 将网关添加到命名空间中。
  • 将内部客户端迁移到调用网关而非单个微服务。
  • 将外部客户端从共享的 Istio 入口网关迁移到 Payments 网关。
  • 保持 API 不变以免中断客户端活动。

Ingress gateway fronting the payments API.

优点:

  • 所有使用者都有自己的单点入口。
  • 可以在不影响客户端的情况下添加 / 编辑现有的微服务。
  • 可以实现断路、认证和授权。
  • 不再依赖共享的工作负载网关。

步骤 2: 拆分微服务

假定支付微服务责任过大, 你想把它拆分成两个较小的微服务(直接存款服务和信用卡服务)。 既然你已经将服务迁移到网关,只要还遵守 API 协议,拆分服务就会很容易。

Same ingress gateway with microservices split apart.

步骤 3: 实现高可用性

老板要求你在另一个可用区的集群中添加另一个 Payments API。 他们说你的 API 需要离消费者更近,并且高度可用。 这在网关架构下很容易实现。 使用 Istio 我们可以创建 ServiceEntry,它使得两个网关都可以被发现。 我们还可以使用 Istio DestinationRules 将流量本地保留到它发起的集群。

Copying of application gateway architecture to multiple clusters.

结论

网关是一种隐藏内部 API 并为你想要公开的功能共享单点入口的好方法。 使用 Istio 提供的网关可以让你快速有效地将网关部署到更靠近应用程序的位置。 它还允许您更有效地扩展架构,同时保持相同的外观和用户体验。

在 Tetrate,我们正在努力使这种网关架构更易于实施、管理和监控。 从添加多集群支持和路由到安全通信,我们正在自动化许多复杂的 Istio 配置,使客户不必担心这些问题。

如果想要了解更多,请点击以下链接:

Author(s)