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

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

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

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

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

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

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

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

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

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

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

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

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

式事务的产生。

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

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

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

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

计方法。

多中心多活的设计

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

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

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

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

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

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

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

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

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

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

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

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

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