在才云我实践了前端微服务化，解决了部分问题，又引入了更多问题。

反思：为什么要微服务化

在才云的场景下，推行前端微服务化的原因有三点：可组装，模块化，独立的开发流程。

可组装是指，产品功能模块可以随时增减，达到灵活交付的目的。模块化是开发者追求可长期维护的软件产品的目标之一。独立的开发流程是指一个功能模块可以单独地开发测试和部署，达到快速迭代的目的。

微服务化是这三点诉求的充分条件，并不是必要条件。微服务化可能并不是唯一解，也不一定是最优解。

repo 管理问题

拆分太多前端 repo 后面临三大问题：

1. PR 提交多

一个修改常常需要提交代码到多个 repo，这在模块边界还有些模块化的前期尤为明显。目前情况下，i18n 文件和 graphql schema 需要提交到“中心 repo”，业务代码提交到“业务 repo”。

2. oem 分支多

多个 repo 会带来多个 oem 分支。对于二次开发来说，管理多个 repo 的分支就是一个很大的挑战，稍不注意就会出现 PR 漏提或错提的错误。

学习成本

现在微服务化已成为产品开发的“必修课”。不学习则无从下手，理不清模块是如何加载的，api 是如何路由的。由于前端微服务并没有通用的方法，对现有产品实施微服务化也不太可能套用“通用方法”，导致“必修课”的知识的可迁移性较低。可能会让新同学提不起干劲学习，甚至被复杂的逻辑“劝退”。

开发复杂性

初期模块解耦不彻底，开发一些模块可能需要启动相关联的模块，操作过程比较麻烦，占用资源也比较多。

由于没有采用业界广泛提倡的“技术无关，框架无关”理念，我们针对产品特性实现了适用于 React 的微服务化方案，产生了“技术基座” —— 公共库依赖。基座包含的内容可以有微前端基础库、核心库版本（React 和 apollo-client 等）、状态管理方案等。每个模块的技术自由度非常有限，只能接收框架注入的公共库版本，不能随意选择。

总结和展望

• repo 的管理方式可以优化，可以参考 monorepo；
• 可以将方案往通用化上演进，优化学习成本；
• 利用 graphql 作为统一 api 网关，降低模块之间的 api 依赖
• 出于性能的考虑，技术基座会长期存在。