课件及源码地址

作者回复: 网关主要是请求路由转发，开销有一点，但是一般不是很大，我们观察生产一般网关损耗只有大约10ms左右；另外网关上需要做好限流熔断，防止后端慢服务影响网关。具体部署多少个zuul实例，要看你的访问量规模，我之前公司有部署上百个的，也有10~20个的，你需要自己评估，做好监控和容量规划。

作者回复: Base Service都是基础服务，例如电商网站的产品/分类/库存/购物车/支付/客服等等。基础服务一般不直接对外暴露，而是通过Edge Service聚合后间接对外暴露。Edge Service也称聚合服务，对基础服务进行适当聚合裁剪，适配各种不同的前端展示(Web/SPA/无线/第三方开放平台...），也就是聚合出适合不同前端展示的API视图(View)。

作者回复: 你好，你的问题很长很多，这里回复不全，建议参考我的文章《BFF和网关是如何演化出来》https://blog.csdn.net/yang75108/article/details/86987404，应该能够找到答案，如果还有疑问，可以直接在群里向我提问。

作者回复: zuul可以做细粒度权限控制，可开发定制过滤器filter，权限逻辑根据业务需求灵活定制实现。jwt带权限往后传可以，userid往后传再到集中服务验权也可以，两种架构风格，各有利弊。

作者回复: Zuul容量规划主要依赖测试环境的压测数据+生产环境监控数据，综合评估得到。刚开始可以根据压测数据预估一个容量(需要一些经验)，然后按照预估容量的x1.5或x2倍先到生产上去试，之后再根据生产监控数据再不断优化调整。完善的压测体系+监控体系+开发人员经验是要素。

作者回复: 能做和该不该它做是两码事，网关适合做反向路由，负载均衡，安全，监控，和限流熔断这些基础功能。 分布式事务一般和业务相关，建议不要耦合在网关上。分布式锁简单的采用DB锁或者复杂点的采用Zookeeper做，一般不要放在网关上。

作者回复: 我之前公司实践，Edge Service依赖Base Service走内部nginx代理，Edge Service之间或Base Service之间如有依然（网状结构有时也合理）也走内部nginx代理。内部服务（Edge或Base Service）对外暴露时才走zuul网关。当然，内部服务用rpc直连，不走内部nginx代理，也是可以，是另一种架构风格。

作者回复: 两种做法都可以，是两种架构风格，静态资源可以躲在网关zuul后面，这样就没有跨域问题；也可以前面加nginx，做动静分别转发，动态api转网关zuul，静态转资源服务器，这种方式需要考虑跨域问题。我们目前用第二种，但是在考虑简化采用第一种，但是zuul网关需要优化改造，改造成同时适合处理api和静态资源。

作者回复: 我只用过zuul，spring cloud gateway还没用，不好做建议，你需要自己调研测试。总体我认为zuul比较成熟，在netflix有大规模落地，但是同步模型（zuul2是异步），spring cloud gateway比较新，实际落地案例还不多，你用的话要实测下。