网关和 BFF（Backend for Frontend）是微服务架构中的两个重要的角色。我们先看一个公司的构架演进历史。（携程进化历程）
第一阶段这种调用直接用ngnix直接暴露，是有一定问题的。
第二阶段暴露的还有无限APP端还有聚合裁剪+逻辑适配的问题，就是说需要同时调用多个后端的接口，结果进行聚合，要显示产品分类和细节，就必须要调用2次接口，不能一次完成。裁剪针对的是页面窗口的大小，手机和平板显示的不同就需要去除一些东西。还有消息格式的适配，有xml、json各种。
bff是前端人员开发的后端服务。代理适配。bff架构有自己的优点，也有缺点。
针对上述bff的缺点，演变出来网关和bff集群。
网关是解耦拆分的关键。这种跨横切面的功能的抽离，使得bff的开发也可以分业务流水线，提供效率。
最后的一个架构，逐渐废弃了nginx这种不可编辑的反向代理的功能（这部分跟网关重叠），全部由可编程的网关代替。
总结
1、网关也是微服务吗？
网关是构建微服务基础设施的一个核心组件，网关部署以后也可以说对外提供服务(反向路由，安全认证，日志监控等)，它属于技术基础服务，但不属于业务服务。
2、网关 、openresty或者kong、Nginx之间的关系？
kong可以认为是专门针对API网关场景的升级版的Nginx，openresty是对Nginx的一种扩展，kong其实也是基于openrest扩展的。Nginx历史悠久，成熟稳定，应用场景丰富。这些产品总体是互补的，不能简单理解为替代关系。Openresty/kong都属于可编程网关。
3、服务分层具体是怎么理解的？
服务分层一般按照职能划分：微服务层：提供基础业务和技术服务；BFF:聚合裁剪适配服务，面向各种端用户体验(PC, mobile, 第三方接入等)；网关层：负责反向路由，安全，监控等跨横切面功能。
实际每一层和具体协议没有严格对应关系，微服务可以用rpc，也可以http/rest，BFF和网关也可以支持rpc或者http/rest。当然，微服务用dubbo rpc框架，BFF转成http/rest，网关再暴露http，也是一种架构方式。
4、BFF 现在流行的说法是FaaS，网关可以由是 servless 方式实现，弱化 devOps？
BFF有很多玩法，之前看到过用动态脚本(可在运行时上传动态运行)做BFF，也有尝试用GraphQL做BFF，FaaS/serless做BFF还没有怎么听说，可能是一种新的尝试，anyway，BFF目标是帮助前端快速迭代。
5、是不是应该在bff与微服务层之间再加一个网关层?如何发现服务？
BFF层可以直接调微服务，走基于注册中心的服务发现即可。如果在BFF和微服务之间再加一层网关(或者nginx反向代理)，相当于集中式负载均衡+反向路由，也不是不可以，只是性能损耗会变大，而且维护成本会变高。
比较典型的微服务分层方式：外部client -> 网关GW -> BFF -> Microservices。GW如何发现BFF？BFF如何发现Microservices？这个可以借助注册中心，例如Eureka。如果在k8s环境中，可以不需要注册中心，因为k8s平台本身就支持服务发现。
BFF是聚合服务层，是介于后台基础服务和外部端设备之间的一层，也能算中台的一部分，但只能算偏前端的一小部分。
6、使用nginx作为服务入口，后端微服务为什么还需要很多域名呢，如果只暴露Nginx的ip，那么内部服务也不会暴露在公网上？
在v2版本中，nginx可以只暴露统一ip和域名，然后根据请求path或者参数再转发到后台服务，这样nginx就相当于是一个网关。但再互联网研发早期，很多公司没有把nginx当网关用，运维通常规定所有对外暴露服务必须独立申请公网域名。
