基础框架选型

1.增量改写

增量改写，即将系统拆分为多个独立模块或应用。当我们决定对应用进行重写的时候，只需要重写其中的一部分，其他功能仍然是正常运行的。而那些需要新功能的部分，又可以运行在新的应用之上。直到有一天，我们重写完所有的模块，系统相当于重写完成了。这种模式，又称为绞杀者模式，它可以在满足系统演进的情况下实现如下目标：
◎　大幅度减少对于业务的影响，降低了风险。
◎　可以随时停止重写，而不影响用户使用。
◎ 用户、客户可以随时看到网站的变化，带来更多的价值。◎　为开发人员带来更多的自由和乐趣。
◎　每个模块重写时，只关心相关部分的业务，而非所有的业务。
当然，这种方式拥有这么多优点而没有被采用，主要是因为实现起来有难度。该拆分方式仍依赖于微架构。对于后端来说，往往是使用BFF作为防腐层。对于前端来说，如果想采用这种模式，需要使用微前端架构来拆分现有的前端应用。
◎　设计全新的路由分发机制。
◎ 使用新技术编写某一部分应用。
◎　将路由指向新的前端应用，剩下的部分仍然指向旧的应用。
◎　不断添加新功能、重写模块，直至完成重写。
从增量改写相关的内容来看，它结合了重搭架构和重写两部分内容，也因此在设计上需要更多的精力。在它是一种依赖于路由分发式的微服务架构，系统切分出一个部分，并编写完成一个新的模块，便将路由指向新的应用。相应的旧的模块，也就可以不维护了，直到有一天，我们完成了系统的重写。

缺点：

1. 每次点击新模块，其实就是打开一个新页面，给用户体验不友好
2. 作为后台系统，常见都有公共头部，侧边栏，内容区域，打开新页面，其实像公共部分都是重写一般
3. 组件跟公共样式，方法函数也是在做重复copy的过程
4. 如果有需要交互频繁的模块，对于这种方式，要么使用url? 传参 或者 使用 浏览器本地缓存localStorage，sessionStorage和cookie
5. …

   2.微前端

   更多查看： https://leyaoyao.yuque.com/gegw6g/hvnpwf/ovy2wm

框架出现都是为了解决业务上实现不了或者在技术上遇到瓶颈的

如果业务满足微前端改造的，个人觉得直接上手微前端

在微前端这块，开发过类似云产品的项目

下图就是项目产品模块

中间那块，旧框架angular 部分

3.技术选型

对于该使用哪种技术作为产品的接入方案，在选型上我们应该考量到以下几点：
从产品角度，需要考虑迭代情况以及使用场景。
从接入成本，需要看看接入这项技术所带来的成本，比如团队的技术储备，是否有相关人力，比如客户端来支持，遇到问题依靠现有人力和生态是否能 hold 住；
从研发效率，怎么实现最大化的代码复用，以及建设相关的开发调试工具链，提高开发效率，是应该考虑的问题之一；
从性能体验，保证上线后项目用户体验满意