今天中午遛弯的时候，又思考起了网关应该承担的功能，这里记录一下。
思考的主要问题是：
网关应该具备哪些功能呢？或者说：哪些功能应该放到网关里面？哪些功能不能放到网关里面？
我的理解是，网关除了要具有最基本的『路由转发』功能外，还要能够进行『认证鉴权』，但这个『认证鉴权』功能不是在网关里面实现的，而是由另一个『认证鉴权』的模块实现并提供 RPC 接口，然后网关调用该『认证鉴权』的接口来进行认证鉴权。
另外，网关还应该具有『限流』的功能，可以针对被网关代理的不同系统/服务/接口等不同维度进行限流。
总结一下的话，网关要至少要具备三种功能：
- 路由转发
- 认证鉴权
- 限流
根据我在不同公司的工作经历，有很多技术负责人想要把『认证鉴权』的实现放到网关里面，我认为这是不合理的。『认证鉴权』本来就是一个业务边界非常清晰的功能模块，不应该放到网关里面实现。一旦放进网关里面实现，网关就会涉及到很多业务功能，就必然会有频繁的业务功能开发/迭代/Bug修复/ 和服务器重启等等，也就必然就会导致网关的稳定性收到影响。
网关应该是轻量级的，和业务轻关联的，网关系统应该是很稳定的（很少重启）。
关于限流
可以针对整个下游服务进行限流，也可以针对某个接口或接口集进行限流。
网关选型
现在市面上网关产品很多，比如 Kong、Zuul、SpringCloud Gateway、还有一些国产网关比如 shenyu 等，那么具体应该采用哪种网关呢？这个不能一概而论，而是要结合自己公司的业务和技术栈综合考虑，综合来看，主要要考虑以下几点：
- 该网关是否开源？其核心技术是什么？是否需要二次开发，二次开发的成本如何？是否容易定制？可维护性如何？出了问题是否容易排查定位和修复？
- 该网关的部署方式？是否支持私有化部署？
- 该网关支持哪些限流方式？是否支持扩展？
- 该网关是否内置监控功能？是否需要单独开发？
- 该网关是否支持自定义插件？
- 该网关的社区活跃度如何？官网文档是否完善？成熟度如何？
