使用单个终结点将请求路由到多个服务。 如果希望在单个终结点上公开多个服务,并根据请求路由到适当的服务,则此模式非常有用。
客户端需要使用多个服务时,为每个服务设置单独的终结点并让客户端管理每个终结点是具有挑战性的。 例如,一个电子商务应用程序可以提供搜索、评价、购物车、结账和订单历史记录等服务。 每个服务都有一个客户端必须与之交互的不同 API,客户端必须了解每个终结点,以便连接到服务。 如果一个 API 发生变化,那么客户端也必须更新。 如果将一个服务重构为两个或多个单独的服务,则必须在服务和客户端中更改代码。
在一组应用程序、服务或部署前放置网关。 使用应用层 7 路由将请求路由到相应实例。
使用此模式,客户端应用程序只需了解单个终结点并与之通信。 如果服务进行合并或分解,客户端不一定需要更新。 它可以继续向网关发出请求,只有路由会更改。
使用网关,还可以从客户端提取后端服务,保持客户端调用的简单性,同时在网关后的后端服务中启用更改。 客户端调用可以被路由到任何需要处理预期的客户端行为的服务,无需更改客户端即可在网关后面添加、拆分和重组服务。
这种模式允许管理向用户推出更新的方式,可以帮助进行部署。 部署了新版本的服务后,它可以与现有版本并行部署。 通过路由,可以控制向客户端提供哪种版本的服务,能够灵活地使用各种发布策略,无论是递增、并行还是完整的推出更新都可以。 通过在网关上进行配置更改可以快速还原部署新服务后发现的任何问题,不会影响客户端。
在以下情况下使用此模式:
当存在某个简单应用程序仅使用一两个服务时,此模式可能不适用。
使用 Nginx 作为路由器,以下为服务器的一个简单示例配置文件,将驻留在不同虚拟目录上的应用程序的请求路由到后端不同的计算机。
server {
listen 80;
server_name domain.com;
location /app1 {
proxy_pass http://10.0.3.10:80;
}
location /app2 {
proxy_pass http://10.0.3.20:80;
}
location /app3 {
proxy_pass http://10.0.3.30:80;
}
}