你们对网关的技术选型是怎么考虑的？能对比一下各种网关技术的优劣吗？
网关的核心功能
(1)动态路由：新开发某个服务，动态把请求路径和服务的映射关系热加载到网关里去；服务增减机器，网关自动热感知
(2)灰度发布
(3)授权认证
(4)性能监控：每个API接口的耗时、成功率、QPS
(5)系统日志
(6)数据缓存
(7)限流熔断
几种技术选型：
Kong、Zuul、Nginx+Lua（OpenResty）、自研网关
Kong：Nginx里面的一个基于lua写的模块，实现了网关的功能 Zuul：Spring Cloud来玩儿微服务技术架构，Zuul
Nginx+Lua（OpenResty）：课程目录里面，有一个文档，课程免费学习，亿级流量系统架构的课程，详细讲解了Nginx+Lua的开发，基于lua自己写类似Kong的网关。
Zuul：基于Java开发，核心网关功能都比较简单，但是比如灰度发布、限流、动态路由之类的，很多都要自己做二次开发。
高并发能力不强，部署到一些机器上去，还要基于Tomcat来部署，Spring Boot用Tomcat把网关系统跑起来；
Java语言开发，可以直接把控源码，可以做二次开发封装各种需要的功能。
自研网关：自己来写类似Zuul的网关，基于Servlet、Netty来做网关，实现上述所有的功能。
说说生产环境下，你们是怎么实现网关对服务的动态路由的？
方案1：数据库。
如果映射关系写死，每次路由关系更改，就需要重启网关，影响会非常大，因此需要实现网关动态的更新路由关系。 可以使用第三方组件保存路由关系，然后在网关里面通过定时任务去定时刷新组件中保存的路由信息。 因此就可以基于mqsql去做路由关系的保存，然后通过后台管理系统去操作db，再由网关去定时查询db更新路由表，实现动态效果。
Nginx（Kong、Nginx+Lua）：Nginx抗高并发的能力很强，少数几台机器部署一下，就可以抗很高的并发，精通Nginx源码，很难，c语言，很难说从Nginx内核层面去做一些二次开发和源码定制。
方案2：Config配置。
将 Spring Cloud Zuul 的路由信息，配置在 Config Server 的 env.yml 中，将网关服务注册为 Config Client，从 Config Server 获取路由信息。
微服务架构的系统中，我们通常会使用轻量级的消息代理来构建一个共用的消息主题让系统中所有微服务实例都连接上来，由于该主题中产生的消息会被所有实例监听和消费，所以我们称它为消息总线。
在总线上的各个实例都可以方便地广播一些需要让其他连接在该主题上的实例都知道的消息，例如配置信息的变更或者其他一些管理操作等。Bus 就是 Spring Cloud 中的消息总线。
其他方案，Apollo, Redis等。
如果网关需要抗每秒10万的高并发访问，你应该怎么对网关进行生产优化？
Zuul网关部署的是什么配置的机器，部署32核64G，对网关路由转发的请求，每秒抗个小几万请求是不成问题的，几台Zuul网关机器。
每秒是1万请求，8核16G的机器部署Zuul网关，5台机器就够了。
你们是如何基于网关实现灰度发布的？说说你们的灰度发布方案？
通过网关(Zuul, ZuulFilter)的发布开关，把少量流量导入到一两台部署了新版本的服务器上，进行测试，这个就叫灰度发布。
开发流程：
1. 准备一个数据库和一个表（也可以用Apollo配置中心、Redis、ZooKeeper，其实都可以），放一个灰度发布启用表，存入具体uri以及是否灰度发布的一些信息，然后搞一张映射表。
2. 启动1个线程每隔多少时间就去刷新灰度发布表的数据写到ConcurrentHashMap里面。 接着搞一个filter继承ZuulFilter，重写里面几个函数，其中shouldFilter根据返回值去判断执不执行run。 因此再should里面遍历map去看这次请求是否有开启灰度发布，如果有就执行run里面的逻辑，就自定义一些分发逻辑，这里用的时通过version去判断和分发。
灰度发布流程：
首先通过后台系统更改灰度发布标识，后台线程更新了map后，就会去执行根据version分发的策略，将少部分流量分发到new的服务上，然后监控和对应的后台，如果没问题，就更改为current，全线上线，最后将灰度发布表示改回来。
说说你们一个服务从开发到上线，服务注册、网关路由、服务调用的流程？
生产环境，微服务生产实践：
开发了一个新的服务，线上部署，配合网关动态路由的功能，在网关里配置一下路径和新服务的映射关系，此时请求过来直接就可以走到新的服务里去。
对已有服务进行迭代和开发，新版本，灰度发布，新版本部署少数几台机器，通过一个界面，开启这个服务的灰度发布，此时zuul filter启用，按照你的规则，把少量的流量打入到新版本部署的机器上去。
观察一下少量流量在新版本的机器上运行是否正常。
版本改成current，全量机器部署，关闭灰度发布功能，网关就会把流量均匀分发给那个服务了。
参考资料：
21天互联网Java进阶面试训练营（分布式篇） -- 中华石杉