随着业务场景日益复杂，我们经常采用微服务架构来进行松耦合，但由于系统和服务的细分，导致系统结构变得非常复杂，微服务网关作为分散在各个业务系统微服务的API聚合点和统一接入点，需要担负整个流量管控的职责，例如：

• 当我们需要应对日常十万+的并发在线长连接数等场景时该如何进行流量的接入
• 当流量进入我们服务时，经常会出现无效请求、恶意网络攻击等情况，此时我们应该在进入系统的第一时间就进行拒绝，防止带宽打满、服务负载急增等情况影响正常用户的使用
• 对于超高频、不常变但响应延时有较苛刻要求的数据视情况通过减少转发路径在网关层进行有效的缓存有时候能够极大的提升
• 随着我们分层架构的拆分，要进行通信必然会带来损耗，而对外如何接收请求，当流量进入网关后的内部流量流转又可以通过怎样的技巧使用适当的协议转化提升通信效率
• 在进行高并发系统设计时，为了防止大量的请求使服务器过载、网络攻击等情况导致服务不可用，我们需要在系统中增加限流以保证系统的可用性，并尽量在最前端进行流量的拦截

网关需要应对四要“既要 还要 也要 就要”的情况，在大规模系统中更加错综复杂，既需要A网关的高性能，又希望使用B网关的业务扩展性，既需要处理传统的南北向流量，还要考虑服务间的东西向流量。

因此在很多场景下为了满足我们的业务需求，我们还经常需要将网关进行拆分，通过流量网关和业务网关进行功能解耦。

1. 流量网关和业务网关

如果将网络请求比喻成一次银行服务，那么流量网关则扮演着大堂经理的角色，指引用户（Request）去需要的柜台（业务线）办理业务。业务网关则扮演着柜面服务员，通过柜面终端（业务服务组）满足用户的业务诉求。

如同上述Case，大堂经理（流量网关）执行着按业务线分流请求的职责，当然同时也会承担一些不区分业务的常规职责，比如盘问用户（WAF，Web Application Firewall），比如安排大家排队等待（业务线限流），甚至关闭柜面（业务线熔断）又或者是张贴告示（静态路由转发）。

而承接特定业务的柜面服务员会根据客户的业务诉求（业务功能路由），打开某个文件柜（业务缓存）又或者在终端提交一张表格（请求业务服务），同时如果终端处理速度缓慢还可以提示后续用户稍作等待（业务功能限流）。

两人相辅相成，共同完成了用户（Request）的传递（路由)。

那不同业务线的业务网关可以是一个么？这个答案需要结合背后业务线的复杂程度来回答。业务网关扮演的角色除了稳定承接的业务线流量，更好服务用户（Request）外，还担负着业务线话事人的角色。什么样的用户应该享受什么样的服务（鉴权），是与用户一问一答的形式还是一次询问多个需求统一回答（串行/并行分发）。

由于不同柜面服务员（业务网关）对不同业务的熟悉程度不一样（特定业务支持能力），所以通常为了更好的服务特定业务用户都会为业务线单独安排柜面服务员（业务网关），但如果业务线同质化特点比较多，并且同一柜面服务员也可以高效的处理，那么的确是可以安排承接多个业务线的服务，又或者安排多个业务能力相同的柜面服务员分别为不同业务线单独服务（单元化部署）。

业务网关也可以理解成一个接口数据聚合服务

2. 出口网关

我们在系统开发中，会依赖很多外部的第三方系统，典型的例子：第三方账户登录、使用第三方工具支付等等。我们可以在应用服务器和第三方系统之间，部署出口网关，在出口网关中，对调用外部的 API 做统一的认证、授权、审计以及访问控制。

原先，你会在拆分出来的支付服务中完成对于第三方支付接口所需要数据的加密、签名等操作，再调用第三方支付接口完成支付请求。现在，你把对数据的加密、签名的操作放在出口网关中，这样一来，支付服务只需要调用出口网关的统一支付接口就可以了。

3. 参考资料

https://mp.weixin.qq.com/s/pHj8SMyYJL9MU1FXxjDhRA