时间戳

首页 > 解决方案 > 关于eShopOnContainers api网关路由前缀的问题

c# - 关于eShopOnContainers api网关路由前缀的问题

问题描述

有一个名为eShopOnContainer的项目，它是一个 .NET 微服务示例参考应用程序，由 Microsoft 提供支持，基于简化的微服务架构和 Docker 容器。

他们使用Envoy作为 API Gateway 上的反向代理，您可以在此处查看更多信息。Envoy 配置有以下规则：

这个应用程序有一本电子书，解释了许多决策，有一个部分讨论了这个主题：为什么考虑 API 网关而不是直接的客户端到微服务通信，这是原因之一：

耦合：没有 API 网关模式，客户端应用程序与内部微服务耦合。客户端应用程序需要知道应用程序的多个区域在微服务中是如何分解的。在发展和重构内部微服务时，这些操作会影响维护，因为它们会由于客户端应用程序直接引用内部微服务而导致客户端应用程序发生重大更改。客户端应用程序需要经常更新，使解决方案更难发展。

所以我在想，在路由上使用前缀会产生一个问题：“客户端应用程序需要知道应用程序的多个区域是如何在微服务中分解的”，对吗？那么它是一种反模式吗？

标签： c#.netmicroservicesapi-gateway

解决方案

无论是微服务架构还是单体架构，这句话始终是正确的

客户端应用程序需要知道应用程序的多个区域在微服务中是如何分解的

对于典型的单体应用程序，您必须在应用程序业务逻辑中配置应用程序路由，使用路由前缀或路由区域

现在，通过 api 网关和微服务架构，您将实现以下几件事

  • 您的应用程序只公开一小部分 API
  • 路由将在网络基础层（host/a/api/...路由到a-service）中配置，通常与多个中间件结合使用（例如：从原始 url 中去除 /a/ 前缀、ip 白名单、审计、authn & authz 等）
  • 通过大量付费和免费工具提高可观察性
  • 该服务可以很容易地更换/交换
  • 具有蓝/绿和/或金丝雀部署的复杂路由，可能具有自动流量测试和服务推广
  • 和更多....

推荐阅读