架构设计导论

BFF 微服务-前端与中台的解耦合

企业级业务流程往往是多个微服务一起协作完成的,每个单一职责的微服务就像积木块,它

们只完成自己特定的功能。那如何组织这些微服务,完成企业级业务编排和协同呢?你可以在微服务和前端应用之间,增加一层 BFF 微服务(Backend for Frontends)。

BFF主要职责是处理微服务之间的服务组合和编排,微服务内的应用服务也是处理服务的组合和编排,那这二者有什么差异呢?

BFF 位于中台微服务之上,主要职责是微服务之间的服务协调;应用服务主要处理微服务内

的服务组合和编排。在设计时我们应尽可能地将可复用的服务能力往下层沉淀,在实现能力

复用的同时,还可以避免跨中心的服务调用。BFF 像齿轮一样,来适配前端应用与微服务之间的步调。它通过 Façade 服务适配不同的前端,通过服务组合和编排,组织和协调微服务。BFF 微服务可根据需求和流程变化,与前端应用版本协同发布,避免中台微服务为适配前端需求的变化,而频繁地修改和发布版本,从而保证微服务核心领域逻辑的稳定。如果你的 BFF 做得足够强大,它就是一个集成了不同中台微服务能力、面向多渠道应用的业务能力平台。

分布式事务还是事件驱动机制?

分布式架构下,原来单体的内部调用,会变成分布式调用。如果一个操作涉及多个微服务的

数据修改,就会产生数据一致性的问题。数据一致性有强一致性和最终一致性两种,它们实

现方案不一样,实施代价也不一样。

对于实时性要求高的强一致性业务场景,你可以采用分布式事务,但分布式事务有性能代

价,在设计时我们需平衡考虑业务拆分、数据一致性、性能和实现的复杂度,尽量避免分布

式事务的产生。

领域事件驱动的异步方式是分布式架构常用的设计方法,它可以解决非实时场景的数据最终

一致性问题。基于消息中间件的领域事件发布和订阅,可以很好地解耦微服务。通过削峰填

谷,可以减轻数据库实时访问压力,提高业务吞吐量和处理能力。你还可以通过事件驱动实

现读写分离,提高数据库访问性能。对最终一致性的场景,我建议你采用领域事件驱动的设

计方法。

多中心多活的设计

分布式架构的高可用主要通过多活设计来实现,多中心多活是一个非常复杂的工程,下面我

主要列出以下几个关键的设计。

1. 选择合适的分布式数据库。数据库应该支持多数据中心部署,满足数据多副本以及数据

底层复制和同步技术要求,以及数据恢复的时效性要求。

2. 单元化架构设计。将若干个应用组成的业务单元作为部署的基本单位,实现同城和异地

多活部署,以及跨中心弹性扩容。各单元业务功能自包含,所有业务流程都可在本单元完

成;任意单元的数据在多个数据中心有副本,不会因故障而造成数据丢失;任何单元故障不

影响其它同类单元的正常运行。单元化设计时我们要尽量避免跨数据中心和单元的调用。

单元化架构一般运用于大型saas企业中。

3. 访问路由。访问路由包括接入层、应用层和数据层的路由,确保前端访问能够按照路由

准确到达数据中心和业务单元,准确写入或获取业务数据所在的数据库。

4. 全局配置数据管理。实现各数据中心全局配置数据的统一管理,每个数据中心全局配置

数据实时同步,保证数据的一致性

你可能感兴趣的:(架构设计,架构)