其他部分

第 5 章　微前端技术实现

横向拆分与纵向拆分的区别

都是根据业务领域进行拆分，只是纵向拆分更多是一个页面就是一个微前端，同时只激活一个微前端，而横向拆分稍微复杂，一个页面里面可能包含多个微前端。

纵向拆分更适合身份认证和目录这两个业务需求，而横向拆分更适合账户管理子域，满足其服务多个子域的业务需求。

Module Federation 入门

• host：在运行时加载共享库、微前端或组件的容器。
• remote：我们要在本地加载的 JavaScript 代码包。

在本书的案例中，host 代表了 App shell，remote 代表其中的一个微前端。

host 负责在运行时加载一些 JavaScript 捆绑包；remote 代表任何类型的 JavaScript 捆绑包，比如共享库、微前端，甚至是组件

共享可以是双向的，remote 与 host 可以共享部分或整个捆绑包。但是，使用双向共享会很快让架构变得复杂。最好的方法是单向共享，这样 host 就不会与 remote 共享任何内容，调试会更加容易，同时可以降低子域向 host 泄露的风险，从而避免 host 和 remote 之间的设计耦合。

因为 Module Federation 是一个 webpack 插件，所以我们可以使用 webpack 的其他功能进行代码优化

第 6 章　构建和部署微前端

自动化策略的重要性。

微服务增强了业务架构的灵活性和可伸缩性，使业务能够根据基础架构的流量对 API 进行横向扩展，并且不同于单体架构的单一方案，我们可以根据业务的特点选择不同的实现方式。尽管微服务具有上述的强大功能，但这些实现方式需要大量的重复性操作进行构建和部署，从而增加了基础架构管理的复杂度。因此，任何使用微服务的公司都必须在持续集成（continuous integration，CI）或持续部署（continuous deployment，CD）上投入大量的时间和精力。

测试策略

但是，当测试用例不得不覆盖别的团队业务时，就会有一定的难度

横向拆分也有一定的问题，它会引发谁来负责对最终效果进行端到端测试的问题

灰度发布

在灰度发布中，我们不会在测试通过后将所有流量切换到新版本。相反，我们会逐步将流量引到新版本。我们监控新版本的实时指标，当错误率增加或用户访问量降低时，我们会相应地减少流量

微前端的数量过多可能会导致瓶颈，因为要匹配所有内容就需要在客户端加载一个很大的配置表。所以，我们为客户端提供了一个针对特定URL 所需的配置系统，提供的配置包括发布和测试不同的组合逻辑、使用 API 或负载均衡控制流量以便在新老版本之间切换。

绞杀者模式

绞杀者模式来源于这样一种想法：通过发布应用的部分功能为企业和用户不断提供增量价值，而不是等待全量功能准备就绪再做发布。

当用户请求微前端实现的页面时，路由切换到微前端的方式提供服务。当应用的某个区域尚未准备好时，路由会将用户重定向到之前的平台。

在绞杀者模式中，微前端与原有应用并存，这样不用等到整个应用开发完成，我们就可以为用户和公司创造即时价值

可观察性

过去几年，前端生态中出现了许多监控工具，比如 Sentry、New Relic 或 LogRocket，这些工具允许我们在遇到问题时记录用户行为。

第 7 章　案例分析：微前端自动化流水线

项目中的自动化策略由 6 个关键部分组成：

• 版本控制；
• 流水线初始化；
• 代码质量审查；
• 构建；
• 构建后检查；
• 部署。

第 8 章　微前端的后端模式

服务字典：

服务字典是一个供客户端调用的服务列表，它主要是在单体应用或模块化单体应用中开发 API 层时使用。服务字典避免了在持续集成过程中创建并注入共享库、环境变量或配置，也避免了在前端代码库中硬编码所有服务接入点的地址。