微服务理论API + BFF 不再为兼容和适配烦恼

Posted 2021-08-21 守夜人爱吃兔子

对于微服务，常见的架构模型就是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这种高可用的软件，基本不会挂，挂了重启即可，限流、负载等逻辑用模块实现，方便部署。 这一层完全和业务无关。

总结

当耦合性太高的时候，就加一层，作为缓冲。 当合并有单点的时候，就分开。当分开有不能统一的时候，就合并。

尽量让专门的人做专门的事情。减少业务对技术的耦合。

 我知道大家一定有很久都没有注意到基础这个点了，平时的工作应该也很少涉及到这些底层知识吧，但是这些东西很重要。如果是想要跳槽加薪或者是应对即将到来的面试，这些都是不可忽视的知识。在这一点里，需要重视的点有：

• Java基础篇： 基础语法+集合+异常+反射+IO+TCP+多线程
• Java web篇： mysql数据库+JDBC+Servlet
• 三大框架篇： Spring+SpringMVC+MyBatis+商城实战项目
• SpringBoot+SpringCloud分布式开发篇： 微服务入门+实战
• 项目经验篇： 秒杀系统设计+SpringBoot商城实战

Java 学习资料，包含了 Java 工程师必学的四大开源框架–MyBatis、Spring、Spring MVC、Spring Boot，视频资料、大厂面试题等，需要的同学可以点击这里免费领取。

Java基础篇

三大框架篇

微服务入门+实战篇

项目经验篇（秒杀+SpringBoot实战）

以上整套学习资料均免费分享，需要的小伙伴，点击下方的蓝色字体可以获取，欢迎来白嫖哈~

点击这里的蓝色字体可以直接获取