微服务之API网关与服务网格比较 - Marino


在过去几年中，我们看到了云原生模式的兴起，这种模式映射到以容器形式运行的微服务。这些容器可能运行在一个普遍存在且广为人知的平台上，即Kubernetes，简称K8S。
 
什么是API？
API代表应用程序可编程接口。这意味着您有一个与应用程序部分交互的界面，以便您可以：

  • 检索要存储在某个存储库中的对象或数据
  • 收集应用程序子组件的指标，以了解应用程序的运行状况
  • 操纵应用程序的特定部分以执行特定操作
  • 利用应用程序为您的应用程序做一些事情
  • 开发并提供您自己的定制前端，以利用另一个应用程序作为后端

当您可以访问一个应用程序和它的较小部分时，您就可以灵活地利用所需的部分。如果您拥有该应用程序，微服务由于其解耦性质更容易更改。API网关有助于实现这种解耦。
  
什么是API网关？
API网关是一个系统，它接受对API资源或应用程序后端的传入请求。如果您熟悉网络网关或路由器，其概念类似于网关接受请求并指向目的地。API网关位于第7层，这意味着它可以感知第7层并监视HTTP等请求。作为网关，它必须为入站请求提供策略，以确保：
  • 经过身份验证的安全请求
  • 请求被适当地路由
  • 请求仅限于维持服务可用性（在大规模情况下）
  • 代理
  • 监测

  
什么是服务网格？
服务网格是一个旨在提供服务端点或微服务的系统，这是一种相互通信的安全方式。它也是一个系统，用于控制应用程序不同部分的入口和负载平衡。在这种方法中，数据平面分布在服务端点附近。然后，数据平面由控制平面指导和管理，以实施各种策略，这些策略用于：

流量管理：

  • 让我们把流量路线安排到预定的目的地
  • 让我们将流量路由到提供相同输出和结果的备用目的地
  • 让我们在延迟增加的情况下中断电路，绕过服务
  • 我们可以将工作负载分配到不同的环境，并且仍然可以到达这些环境
  • 让我们继续部署不同版本的应用程序并获得反馈（金丝雀、蓝绿色部署）

安全：

  • 让我们用MTL加密可信端点的通信
  • 让我们阻止不必要或非法的请求

可观测性：

  • 服务发现
  • 我们能看到什么？
  • 当我们看到出现问题时，会采取哪些自动化步骤来解决？
  • 我们能追踪端点，看看哪里出了问题吗？

对于Kubernetes，我们遵循一种侧车模式，其中部署了一个辅助侧车容器，它是服务网格的数据平面。该pod的主应用程序容器将通过Service Mesh数据平面容器发送其流量，该容器由Service Mesh控制平面pod/容器控制，这些pod/容器通常位于不同名称空间的同一集群中。
服务网格可以扩展到直接负载平衡器和DNS，这样应用程序就可以跨多个提供商分布。
我还必须提到let，它代表延迟、错误、流量和饱和，ServiceMesh希望观察并采取行动。
  
API网格和服务网格图：
此图的目的是说明请求者、API网关和/或服务网格与微服务之间高层的各种流量。


两者产品比较：


 
它们有何不同？
API网关作为一个系统，需要确定入站请求是否合法并指向预期目的地。使用API网关将应用程序的端点公开给其他应用程序的其他部分使用。另一方面，尽管提供了入口点，但ServiceMesh更关注于建立、保护和监控点对点通信。这听起来像一个VPN。
 
它们有什么相似之处？
两者的相似之处在于，它们控制着通往预定目的地的流量。它们都可以识别流量可能是什么，以及流量中包含的内容。根据这些细节，API网关和服务网格可以破译可能发生的情况。最重要的是，两者都在第7层运行。
 
两者可以协同使用吗？
是的，虽然可能存在一些重叠，但每个重叠的目的都是从请求的角度控制和操纵流量。在未来，我怀疑您将开始看到API管理和网关与服务网格相结合的组合产品，以捕获南北和东西交通流和模式。这可能是为了避免“泳道”的完全混乱和冲突，同时提供一体化体验。
 
我们的目标是解决什么？
我们的目标是解决服务端点之间的连接问题，同时保护应用程序API的入口点。这使我们能够更好地解耦微服务，提供更好的生命周期操作，并使用新代码和功能不断迭代应用程序。这两种技术都可以防止消费者注意到任何停机、停机或可用性问题。
一个很好的例子是Uber或UberEats，它们都使用谷歌地图API，但将通过API网关实现，主要是因为希望“rate-limit”，而不是地图API成本过高。
利用服务网格的一个例子是，客户机正在考虑将容器化工作负载从一个云提供商移动到另一个云提供商。迁移是一个技巧，需要通过三件事来处理：

  • 同一应用程序的新部署
  • 引导流量的负载平衡器（来自服务网格的方向）
  • 域名服务器

通过服务网格实现这三个目标，应用程序可以无缝迁移。还有，因为Kubernetes 不在乎。同样的方法也可以用于应用程序新版本的Canary部署，其中一部分流量请求被定向到该新版本，而大多数请求则转到旧版本。这同样适用于蓝绿色部署。这同样适用于这些Docker化工作负载的高可用性和灾难恢复。也许，我们正在从部署应用程序迁移到一组虚拟机，而服务网格可以为我们提供便利。

 
如何开始？
API Gateway:


服务网格Service Mesh

 
结论
虽然API网关和服务网格已经存在了一段时间，但我注意到这些技术有了很大的提升。原因有很多，但最常见的是：

  • 利用微服务模式
  • 保护微服务
  • 缩放它们
  • 观察它们
  • 与他们互动
  • 操纵它们
  • 在不影响请求者的情况下修改它们
  • 分发

在不久的将来，我们可能会看到通过企业产品将两者合并。我们甚至可以看到ServiceMesh如何保护用户端点，这可能会重新定义我们处理VPN解决方案和最终用户连接的方式。