老师，示例代码能否独立分开，比如用分支、tag之类的方式，现在获取的最新网关代码中还有helthcheck, skywalking的代码，与视频的代码状态并不一致，运行起来行为也不一致。 对像我这样的小白来说，这些干扰代码带来了不小的困难

如果是BFF, 那网关和聚合服务是否可以放在一个项目中更合适？

肖老师，有几个问题想沟通一下： 1、在“专用网关模式”中，如果有聚合服务的需求，所创建的聚合服务应该是基于现有的微服务来进行拼装，这里的微服务是否也可以不按照rpc的形式来进行交互，依然按照json格式来处理呢？ 2、另外如果网关面对某一个单独的微服务，一般情况下都是经过dto处理过的json数据。如果要加一个聚合服务，那聚合服务应该有另外一套dto的数据体现要求了，按这个思路的话，微服务所提供的就不能返回dto的数据，而是尽量全面的数据。 假如没有聚合服务，只有微服务，目前我的做法是将dal,bll,webapi直接做为一个进程内来处理，最终以json格式暴露出api。如果也想让微服务向聚合服务提供资源的话，那只能从业务逻辑层进行rpc封装，对webapi的项目进行解耦，让dto转换在webapi项目中做转换了。这部分不知道你们是按照什么样的方式来设计的，需要老师解惑一下。 3、第三个问题可能会受第2个问题不明朗的影响，但也提一下，由于聚合服务是将多个微服务进行组装的服务，随着需求变更或项目发展，微服务可能会有一些变化，此时聚合服务也会受到相应影响，在生产中，聚合服务是如何得到更好的把控呢？

感觉把聚合放在网关并不合适，聚合服务主要是对诸多微服务接口的统一请求并整合数据给前端，如果放在网关，首先网关会比较乱，各种业务都有，非常难维护，特别不同团队共享网关时，另外网关主要还是做限流、熔断、日志、认证等相关基础工作不应该和业务挂钩！

精简实用

老师 BFF 和网关区别不大，那为什么还要有俩个概念？

请教老师，本地测试，发现访问网关是会重定向的，比如，5003，输入地址后会重定向到5001的地址，ocelot版本16，教程中并没有发生重定向，这是为什么？多谢

使用新版本的Ocelot 16.xx 配置文件写法跟14.xx版本有出入