序
本文主要通过虚拟一个公司的业务发展，来观看微服务网关和BFF的演化
v1版本的soa服务
在2010年左右有个叫highShop的电商互联网公司成立了，他有一定的业务规模，内部已经完成了单体应用拆分，soa服务化，采用的是浏览器–>nginx–>服务端web应用–>soa服务，这样的架构帮助highShop公司度过一段时期。
时间转眼来到2012年，智能手机发展越来越快，无线应用开始起风，为了能够尽快上线自己公司的原生app无线应用，开始也想和浏览器一样的方式，让app通过nginx直接去调用soa服务，经过架构评审，这个架构是存在问题的。所存在的问题：
一: 无线app和内部接口服务强耦合，耦合包括域名耦合和接口耦合，任何一方的变化都可能对另一边产生影响
二：每个暴露的服务都需要提供新的域名
三：内部服务直接暴露在外网非常的不安全
四：无线app段需要开发大量的聚合裁剪和适配逻辑（比如手机和pad屏幕大小的不同，还有比如消息格式的转化，老的服务只返回xml不返回json）
v2引入无线BFF
BFF就是为前端开发的后端服务，就是为了针对前面所说问题做的一个代理适配服务，可以进行聚合裁剪和逻辑适配，向无线端提供友好和格式统一的api，方便无线设备接入和访问后端服务。优点包括
一：无线app和内部服务不再强耦合，引入BFF这层间接，可以使两边都变得独立些，无线app只需要知道无线BFF提供的统一接口和域名，不需要知道内部微服务复杂的域名和细节
二：只需要一个无线BFF域名，开销小
三：内部微服务躲在无线BFF后面，不会暴露在公网上，会更加安全
四：聚合裁剪和适配逻辑可以在BFF上统一实现，可以实现app端大大的瘦身
v2版本在app上线早期确实取得了一定的成功，但是随着业务规模和开发团队的日益扩大，v2版本渐渐也暴露出了一些问题，比如：
一：单块无线BFF堆砌了大量的业务线逻辑，变得越来越臃肿，升级维护也变得越来越困难。
二：单线BFF和多团队之间出现了不匹配
三：随着时间推移，代码变得越来越复杂，技术债越来越多，开发效率不断下降
四：单线BFF集群出现宕机的话会引起整个无线应用不可用
V3 引入新的角色—网关
首先针对不同的团队业务，引入不同的BFF，在nginx和多个无线BFF中间引入网关，这个网关专门负责跨横切面功能，网关所做的事情包括：路由，认证，监控，限流熔断，防爬虫等等。这样BFF开发人员就可以只需要开发交付相关的实际业务即可。
V4 较完善的微服务架构
随着业务的不断发展，highShop公司需要做一个开放平台给第三方开发者接入，h5技术兴起的单页web应用（比如微信分享）也如火如荼，此时就需要更多的网关来拆分这些业务。并且nginx其实和网关的功能有重合，并且网关是可编程的，所以可以用网关直接代替nginx，每一个网关指向一个BFF，由BFF再去访问微服务。
最终的架构就是：
端用户–》网关–》BFF–》微服务
以上就是一个常规公司业务在发展的过程中网关和BFF的演化，所以通常来说，网关和BFF都是架构演化的产物，当然我们需要根据企业的实际业务需要灵活的设计分层微服务架构，没有最好的架构，只有最合适的架构！
