背景
微服务架构中，单个大应用被拆分成多个自成体系的小系统，小系统的服务通常是通过提供RestFul Api风格的接口供其他应用调用。
每个小系统通常有限流、安全校验、监控、日志、熔断等功能模块，随着小系统的增多，负责请求响应处理的公共模块的提出势在必行。在众多解决方案中，服务网关脱颖而出。
定义
服务网关 = 路由转发 + 过滤器
服务网关：出现在系统边界上集中式的强管控服务,可看成企业应用级防火墙。
路由转发：集中接收外界请求，转发到不同的后端微服务。
过滤器：在服务网关中完成一系列的横切功能，比如限流、安全校验、监控、日志。
比对
过滤器特性中的横切功能，可按如下三种方式实现：
- 每个小系统单独实现一遍
- 提出到公共服务，所有小系统依赖这个jar包
- 提出到网关服务
第一种，缺点明显，代码冗余，单独维护，具体实现可能不一致。尤其在小系统众多的情况，坚决不可使用这种方式。
第二种，相比第一种，代码虽然不会冗余，但是每个小系统均引入了公共jar包，使得最终的jar包无故增大，在docker部署的场景中，jar包越小越好。而且，后续升级维护公共jar包比较困难，公共服务越多，升级就越困难，若升级公共jar包，各个小系统要想使用最新功能，则均要重新打包，构建，部署。
第三种网关服务，所有逻辑均写在网关服务的过滤器中,各个后端小系统无需公共网关的实现，不引入jar包则不会增加最终jar包大小。如果网关服务升级，仅升级自身即可，各后端小系统无需升级部署。缺点是请求多了一层转发，实际网关服务部署为高可用高并发，可忽略延迟问题。
实践
将各小系统的横切功能提出到网关服务中，根据请求的来源、路径、参数决定路由分发策略。
分发策略可配置，网关服务支持热更。
网关服务可看成RestFul接口服务，集群部署，可用Redis做缓存。