「本文已参与好文召集令活动，点击查看：后端、大前端双赛道投稿，2万元奖池等你挑战！」
对于微服务，常见的架构模型就是API网关+服务。
- API网关实现鉴权、负载均衡、中间件等公共入口逻辑。
- 服务实现具体的业务功能。
那么，API网关设计中又有什么坑呢？
1.0版本
直接将服务穿透到外网。 API层只是套了壳，加了鉴权、中间件而已。具体返回值由服务定。
- 客户端到微服务直接通信，强耦合。根本不敢重构，一改结构客户端就崩了。
- 需要多次请求，客户端聚合数据，工作量巨大，延迟高。
- 如果一个页面由多个服务组成，比如商品、优惠券、相关推荐、评价。客户端要请求多个接口，命名规则还不一样。
- 有的接口成功，有的接口失败，需要客户端自己做降级。
- 协议不利于统一，各个部门间有差异，需要客户端端来兼容。
- 面向“端”的API适配，耦合到了内部服务。
- 每个服务都要为不同的设备做适配代码。
- 多终端兼容逻辑复杂，每个服务都需要处理。
- 统一逻辑无法收敛，比如安全认证、限流。
这样就导致了客户端、服务端都累得要死，谁都不讨好。
2.0版本
架构就是一层加一层。
添加了一个BFF层，backend for forntend，专门做适配。
针对页面提供接口，比如商品页面，就一个接口，然后BFF层去调用多个服务，在这里做降级，比如优惠券服务没有返回就不显示就完了。
客户端只用和BFF层沟通，什么适配、协议、兼容、定制都是这一层来做。客户端感觉很爽。
服务端也只用提供基础数据，不用关心业务逻辑，不用管适配，返回的接口是什么结构。服务端也很爽。
BFF层只做了数据裁剪，兼容之类的逻辑，轻不轻松？也很轻松。
问题：
- BFF单点了。也就是所有的流量都会到这一层， 如果有流量洪峰或者代码有bug，全盘宕机。
3.0版本
将BFF根据业务拆分，比如查看商品一个，订单页面一个。这样一个挂不会影响全局。
问题
- 很多跨横切面逻辑，比如安全认证，日志监控，限流熔断等。随着时间的推移，代码变得越来越复杂，技术债越堆越多。
有没有发现：
分久必合、合久必分。 分开了就有不能统一的地方，合并了就会单点故障。
4.0版本
将通用逻辑做到了API网关层，BFF层专注于业务逻辑。
API层采用Nginx这种高可用的软件，基本不会挂，挂了重启即可，限流、负载等逻辑用模块实现，方便部署。 这一层完全和业务无关。
总结
当耦合性太高的时候，就加一层，作为缓冲。 当合并有单点的时候，就分开。当分开有不能统一的时候，就合并。
尽量让专门的人做专门的事情。减少业务对技术的耦合。
