前端微服务设计

Posted 2023-04-03

参考技术A

近些年，前端发展呈百家争鸣式发展，框架层出不穷，版本更是迭代不穷，难免会出现前端项目技术栈不统一、所用框架版本不统一的情况。
如若某些项目，没有新的功能加入，又能线上稳定运行，但其技术栈却用的是 vue1.0，为了将其结合到新应用中去而对其重构，成本会很高。然而，微服务可以帮我们解决这个问题。
在既不重写原有系统的基础之下，又可以抽出人力来开发新的业务。其不仅仅对于业务人员来说是一个相当吸引力的特性，对于技术人员来说，不重写旧的业务，能在一些新技术上做挑战，也是一件很有意思的事情。
除此之外，在这两三年里，移动应用出现了一种趋势，用户不想装那么多应用。而往往一家大的商业公司，会提供一系列的应用。这些应用也从某种程度上，反应了这家公司的组织架构。然而，在用户的眼里他们就是一家公司，他们就只应该有一个产品。相似的，这种趋势也在桌面 Web 出现。聚合成为了一个技术趋势，体现在前端的聚合就是微服务化架构。

理想的前端微服务化，应该是符合如下几个特点：

路由分发式微前端，即通过设置路由，将不同的业务分发到不同的、独立前端应用上。其通常可以通过 HTTP 服务器的反向代理来实现，又或者是应用框架自带的路由来解决。

就当前而言，通过路由分发式的微前端架构应该是采用最多、最易采用的 “微前端” 方案。但是这种方式看上去更像是多个前端应用的聚合，即我们只是将这些不同的前端应用拼凑到一起，使他们看起来像是一个完整的整体。但是，它们并不是一个完整的整体，每次用户从 A 应用到 B 应用的时候，往往需要刷新一下页面。
通常可通过 nginx 配置反向代理，来进行路由分发，从而实现前端微服务。

它适用于以下场景：

iframe 可以创建一个全新的独立的宿主环境，这意味着我们的前端应用之间可以相互独立运行。

采用 iframe 有几个重要的前提：

即何时加载、卸载应用，如何监听应用事件等。

不论是基于 Web Components 的 Angular，或者是 VirtualDOM 的 React 等，现有的前端框架都离不开基本的 html 元素 DOM。

那么，我们只需要：

第一个问题，创建 DOM 是一个容易解决的问题。而第二个问题，则一点儿不容易，特别是移除 DOM 和相应应用的监听。当我们拥有一个不同的技术栈时，我们就需要有针对性设计出一套这样的逻辑。现有的框架有single-spa、qiankun、mooa等

常见的方式有：

其次，采用这种方式还有一个限制，那就是：规范！ 规范！ 规范！。在采用这种方案时，我们需要：

Web Components 组件可以拥有自己独立的 Scripts 和 Styles，以及对应的用于单独部署组件的域名。然而它并没有想象中的那么美好，要直接使用纯 Web Components 来构建前端应用的难度有：

现有的微前端框架有single-spa、qiankun、mooa。其均是在前端框架之上设计通讯、加载机制来实现的。

架构设计导论

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

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

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

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

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

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

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

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

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

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

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

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

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

式事务的产生。

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

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

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

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

计方法。

多中心多活的设计

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

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

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

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

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

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

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

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

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

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

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

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

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