undefined这种应用在字节跳动随处可见。由于字节跳动有大量的业务线，每个业务线都会产生大量的中台系统，而且还在呈指数级增长。以字节跳动的电商业务为例。对于电商运营的日常工作，其实和研发的日常工作是一样的。它围绕着：商品、商家、品牌、风控、营销等，那么电商运营最高效的电商运营是什么？在系统方面，由于整个系统涉及面广，在实际研发过程中，难免会根据功能或业务需求，垂直划分成更小的子系统。开发者体验，反而在一定程度上降低了用户体验。新的架构模式能否既保护开发者体验，又提升用户体验？传统Web应用的优缺点这里简单分析一下传统Web应用在开发大型应用、涉及多研发团队协作时遇到的一些困难。以上述案例中的“电商运营平台”为例，对于电商运营来说，商品、商家、品牌等都是电商运营平台能力的一部分，而不是独立岛屿。如果采用传统的前端研发模式进行开发，那么此时的项目设计策略有两种：将平台中的多个系统放在同一个代码仓库中进行维护，使用SPA（Single-pageApplication）单-页面应用模型，将系统划分为多个仓库维护，所有平台的入口聚合在首页，采用MPA（Multi-pageApplication）多页面应用模式。如果在同一个项目中使用多个系统进行维护：优点：局部更新性能更好，无缝用户体验提前预加载用户下一页内容统一权限控制，统一开放API开发能力更好的代码复用，基础库复用统一运维管理能力不同系统可以很好的互通SPA应用的独特优缺点：代码权限控制问题项目建设时间长需要发布相互阻断代码提交混乱，分支混乱技术系统要求不能同时灰显多个产品功能代码回滚相互影响错误监控无法细粒度日常开发中研发：代码构建半小时以上，发布需求时被需求阻塞，灰度无法本地升级，回滚时影响其他业务项目遭遇rs的问题，不能快速引入新的技术系统来提高生产力，而项目的迭代和维护对于研发同学来说无疑是一场噩梦。虽然降低了开发体验，但如果整体项目的代码拆分和懒加载控制得当，平台的用户体验实际上会得到提升。这一切都得益于SPA应用带来的优势，SPA应用跳转页面变化时不需要刷新整个页面，路由变化时只更新部分，让用户没有体验MPA应用切换时整个页面刷新带来的抖动，由于页面不刷新时间资源的特性，可以极大程度的复用页面，减少切换页面带来的性能损失，以及用户不会察觉到他正在使用不同的平台。如果利用拆分到多个仓库维护的优势，可以在项目维度拆分代码，解决权限控制问题，只构建本项目的代码。施工速度快，可以使用不同的技术体系。维护同一个仓库时不存在提交混淆和分支混淆。函数灰度等问题互不影响。弱势用户在使用时体验碎片化，会在不同平台之间跳转，无法达到SPA应用带来的用户体验。很难按照业务维度来划分多个系统。同样的灰度策略很难。重复加载公共包的基础库。不同系统之间无法直接通信。公共部分只能针对每个系统独立实现。同样运维通知难。在一定程度上提高了开发体验，但降低了用户体验。研发在日常开发工作中需要使用大量平台，但日常研发工作需要跳转到不同平台，整体用户体验较差。体验差的原因在于，整体“研发中心”这样一个产品，通过项目维度进行拆分，让每个产品都是一个独立的孤岛，系统之间的跳转就是传统意义上的MPA。需要重新加载整个页面的资源，除了性能远不如SPA应用，应用之间没有直接通信，进一步增强了用户在使用产品时的碎片感。背景和意义总结通过以上两个场景和案例，我们其实可以发现，当Web应用逐渐取代传统PC软件的时候，大型的Web应用在面对高复杂度和涉及大量用户的情况下，并不能同时保证DX和UX。团队成员。.传统的分而治之策略已经无法应对现代Web应用的复杂性，于是衍生出一种新的微前端架构模式，与后端微服务相同。它同样延续了分而治之的设计模式，但是它使用了一种新的方法来实现。上一节微前端解决方案总结了微前端出现的背景和意义，了解了两个传统Web应用SPA（Single-pageApplication）和MPA（Multi-pageApplication）的发展历程涉及人员和项目范围广泛。一种既能兼具SPA和MPA架构优点又能同时提升DX（开发者体验）和UX（用户体验）的新架构怎么样？理想情况下，期望一个复杂的单体应用可以根据功能或业务需求垂直划分成更小的子系统，并实现以下能力：子系统之间的开发和发布可以在空间上完成隔离子系统可以使用不同的技术系统.子系统之间可以完成基础库的代码复用。可以快速完成子系统之间的通信需求。子系统之间的需求迭代不会相互阻塞。子应用程序可以增量升级。子系统可以走向相同的灰色版本。该控件提供了一个集中的子系统权限来控制用户体验。整个系统是一个单一的产品，而不是彼此的孤岛。项目监控可以细化到子系统。基于以上理想情况，如何从头设计一个新的架构来解决现代Web应用在面对企业级系统时遇到的困境。
