微服务,BFF,API gateway 学习笔记

一、微服务

微服务是什么?

微服务模式的一般设计见下图:

微服务,BFF,API gateway 学习笔记_第1张图片

如上图所示,把业务分块,做了垂直切分,切成一个个独立的系统,每个系统各自衍化,有自己的数据库、缓存等辅助系统,各个微服务共同完成整个系统功能。

对于单机数据库写请求量大量增加,导致数据库压力变大的问题,由于拆分成了多个子系统,系统的压力被分散了,而各个子系统都有自己的数据库实例,所以数据库的压力变小。

一个子系统A的数据库挂了,只是影响到系统A和使用系统A的那些功能,不会所有的功能不可用,从而解决一个数据库挂了,导致所有功能不可用的问题。各个子系统有自己独立的GIT代码库,不会相互影响, 对于业务代码越来越多,越来越难以维护的问题也因为拆分得到了解决

优点:相对高性能,可扩展性强,高可用,适合于中等以上规模公司架构。

缺点:复杂、度不好把握。指不仅需要一个能在高层把控大方向、大流程、总体技术的人,还需要能够针对各个子系统有针对性的开发。把握不好度或者滥用的话,这个模式适得其反!

微服务和分布式的区别

微服务和分布式都是拆分单体应用的产物,但微服务是架构设计方式,而分布式是系统部署方式。

简单来说,微服务是分布式应用,但分布式应用不一定是微服务。微服务重在解耦合,注重模块划分。分布式重在资源共享,并加快计算速度。

微服务需要面对的问题

Martin Fowler在他的《企业应用架构模式》中,就提到了分布式对象设计的第一原则:“设计分布式对象的第一个原则就是不要使用分布式对象”。因为分布式系统会给我们带来很大的挑战,让系统复杂度大幅增加的同时,我们还需要面对开发环境、测试、部署、运维、监控,一致性和事务等一系列的问题。

所以说,微服务架构虽然看起来非常美好,但对于这个模式来说,过度切分会适得其反,因此不能切分过细,实践中,一个较为可行的方法是:能不分就不分,除非有非常必要的理由!。

微服务,BFF,API gateway 学习笔记_第2张图片

那要如何应对呢?

为了追求生产力的最大化,一开始我们可以选择从一个单体架构开始,然后争取在微服务架构生产力超越单体架构的那个复杂度点切换到微服务架构上来,这样才能实现生产力的最大化。这就是Martin Fowler提出的单体应用优先原则(MonolithFirst),以单体架构开始,通过演进式设计逐渐重构到微服务架构。

二、 API gateway与BFF

API gateway是什么?

在微服务架构中,大型服务都被拆分成了独立的微服务,每个微服务通常会以RESTFUL API的形式对外提供服务。但是在UI方面,我们可能需要在一个页面上显示来自不同微服务的数据,此时就会需要一个统一的入口来进行API的调用。上图中我们可以看到,API Gateway就在此场景下充当了多个服务的大门,系统的统一入口。

在微服务的架构模式下,API Gateway是微服务架构中一个非常通用的模式,利用API Gateway可以解决调用方如何调用独立的微服务这个问题,API Gateway封装了系统的内部复杂结构,同时它还可能具有其他API管理/调用的通用功能,如认证,限流,流控等功能。

为什么需要API Gateway

不采用API Gateway的微服务部署模式存在的问题:

对于API的限流,安全等控制,需要每个微服务去自己实现,增加了微服务的复杂性,同时也违反了微服务设计的单一职责原则。

客户端与众多微服务交互,协议不统一,有些协议是对客户端不友好的。

数据不统一,可能在一个操作中,需要多个微服务的数据组装起来,才是我们一次请求想要的数据。

微服务,BFF,API gateway 学习笔记_第3张图片

 

通过上图可以看到,API Gateway做为系统统一入口,实现了对各个微服务间的整合,同时又做到了对客户端友好,屏蔽系统了复杂性和差异性。对比之前无API Gateway模式,API Gateway具有几个比较重要的优点:

  • 各个微服务先与 API gateway 交互,转换成客户端友好的 REST API。
  • 在 API gateway 中组装好数据再返回给客户端。
  • 在 API gateway 中修改 ip 与 port 客户端无感知,正常使用。
  • 采用多个 API gateway ,不同 API gateway 响应不同的数据给不同终端。
  • 在 API gateway 中统一鉴权,省去多余代码。

众多问题都迎刃而解,客户端对众多微服务是无感知的,帮助我们实现客户端的负载均衡策略。

BFF是什么?

BFF,即 Backend For Frontend(服务于前端的后端),也就是服务器设计 API 时会考虑前端的使用,并在服务端直接进行业务逻辑的处理,又称为用户体验适配器。BFF 只是一种逻辑分层,而非一种技术。

BFF 的出现为前端应用提供了一个对业务服务调用的聚合点,它屏蔽了复杂的服务调用链,让前端可以聚焦在所需要的数据上,而不用关注底层提供这些数据的服务。

微服务,BFF,API gateway 学习笔记_第4张图片

我自己在开始学习的时候总是分不清BFF和API gateway,因此有了下面的一小节:

BFF与API gateway的区别与联系

微服务,BFF,API gateway 学习笔记_第5张图片

  1. 在微服务架构中,BFF(Backend for Frontend)也称聚合层或者适配层,它主要承接一个适配角色:将内部复杂的微服务,适配成对各种不同用户体验(无线/Web/H5/第三方等)友好和统一的API。聚合裁剪适配是BFF的主要职责。
  2. 在微服务架构中,网关专注解决跨横切面逻辑,包括路由、安全、监控和限流熔断等。网关一方面是拆分解耦的利器,同时让开发人员可以专注业务逻辑的实现,达成架构上的关注分离。
  3. 端用户体验层->网关层->BFF层->微服务层,是现代微服务架构的典型分层方式,这个架构能够灵活应对业务需求的变化,是一种支持创新的演化式架构。
  4. 技术和业务都在不断变化,架构师要不断调整架构应对这些的变化,BFF和网关都是架构演化的产物

你可能感兴趣的:(后端,微服务)