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

Question

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

他们使用Envoy 作为 API Gateway 上的反向代理，您可以查看更多关于它的信息here。 Envoy 配置了以下规则：

• 前缀为“/c/”的路由转发到“/catalog-api/”（目录微服务）
• 前缀为“/o/”的路由转发到“/ordering-api/”（订单微服务）
• 前缀为“/b/”的路由转发到“/basket-api/”（篮子微服务）

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

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

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

Answer 1

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

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

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

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

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