如何向客户端公开REST微服务？

Question

我们将rest单点分解为微服务，我们遇到了以下问题

让我们假设如下

• 项目是asp.net mvc，托管在iis上。
• 项目托管在专用服务器(而不是云)上。
• monolith rest api定义了urls，如www.domain.com/order/www.domain.com/ as /等等。

当将monolith拆分到microservice时，理想的情况是我们最终会

ms1 -> www.domain.com/orders/
ms2 -> www.domain.com/tickets/

由于微服务通常与资源不相关，这可能会变得混乱，例如，一个微服务可以服务于一个以上的资源，或者一个以上的微服务可以服务于资源。

fe.
www.domain.com/tickets/ (ms1)
www.domain.com/tickets/reports (ms2)

or
www.domain.com/tickets (ms1)
www.domain.com/orders (ms1)

解决这个问题的办法是什么？

• 使用IIS重写将资源与微服务fe匹配。请通过iis重写获得www.domain.com/iis/5，电话：-> ticketsms.domain.com/iis/5
• 使用API网关将请求路由到适当的微服务端点fe。通过API网关获得www.domain.com/ to /5，电话：-> ticketsms.domain.com/to/5

因此，基本上，主要目标是拥有完整的rest，如

GET www.domain.com/tickets/5
GET www.domain.com/orders/5
POST www.domain.com/orders/
GET www.domain.com/invoices/100

等

那么，iis重写和api网关是这里仅有的两个选项吗？是否应该直接向客户公开微服务，或者是否应该将微服务公开到trought网关。在这种情况下，API网关是否过火了？

Answer 1

API网关无疑增加了价值--您将实现分割为更小的单元(微服务)--它允许您将API接口作为一个单元集中管理、监视和管理，与实现分开。

暴露单个微服务终结点可能不容易管理-例如，您需要将访问控制策略分别应用于每个微服务终结点。