关于网关看了很多资料，也有项目实践，但始终很困惑，请点播一二
从我收集的资料来看，微服务网关一般有如下作用：路由/流控，鉴权，协议转换，服务聚合/编排，监控，日志，熔断，限流...
我现在的架构，前面nginx只做路由，下游接“不同大业务块的网关”，这个网关简单理解就是人工编码的应用，未采用zuul，kong一类开源组件，做以上所有工作，我一直觉得以上设计和其他文章中对网关的定义差异很大，仿佛他们的网关能通过一个统一框架实现所有事情，除了聚合/编排
我的疑问是，能不能说鉴权算不算一种业务逻辑？因为有的鉴权比较复杂，聚合和编排是否更涉及到了业务逻辑？如果整个系统只有在用户-系统的边界有一/几个网关，如果其中包含了大量的鉴权和聚合/编排，那就太臃肿了？既然网关的功能这么复杂，现在的主流框架主要还是解决性能和路由的问题，那还要他们干什么呢？随便一个高效的web框架不是也可以么？（只考虑7层）
那在我们设计系统中，在思考“网关到底要承载哪些功能”时，什么样的参数是要重点考虑的呢？有什
建议极客时间的所有课程增加定期答疑的环节

我这边的Gateway设计包含了权限验证，协议路由，防刷等功能，这里的观点在服务间都是tcp长连接的应用场景下是比较合适的【游戏业务，需要有一些服务端主动推送给客户端的高实时性需求】。
协议路由这块我是用一个配置来规划每个协议应该发往哪里，发送的路由规则也是可配置的，Gateway后端的服务之间的通讯都是通过Gateway转发，通过一套内部协议进行转发，服务间的调用相当于调用一个sendToServer(serverid, msg, ...)。
个人认为这样的好处是简化了业务服务的处理，只需要关注Gateway，而不需要知道其他服务的更详细的信息，完全屏蔽了其他服务的部署情况。且简化了网络结构，如果后面的服务直接需要互联那么这个只有一两层的树状结构就会变成网状结构，他们之间的异常处理，重连等等就会变得复杂难以维护。
如果是基于http的微服务，那我认为通过注册中心获取服务，然后直接调用也是可以的，但经过Gateway去做这件事情可以有更大的控制力。