从微前端聊聊架构演进

就目前来看，微前端已经不是一个新话题了。随着愈来愈多的公司的深刻研究，当前也提出了不少的解决方案。不过本文不是想要来介绍微前端，更想介绍项目如何一步步到达微前端架构的实际需求。

固然，也不排除有些项目在初期就须要微前端这样的架构，不过我一直相信，任何架构模式都是根据实际需求来构建的。为何不少大公司投入那么多的精力去作这样一件事，更多的也是由于他们真正须要这样一种架构，甚至达到了不用会影响业务开发的可能。不过对于大部分企业，不太须要关注这一点。

事实上，不管是什么架构形式,都是为了项目可以更快的进行开发。 因此不可贵出，ETC 原则 (Easier To Change ，易于修改) 贯穿始终。

对于 ToC 端应用而言，可能生存期只有 2，3 年就会结束或者重写。可是对于 ToB 端应用基本上是公司不关门以前都会持续开发和使用下去。固然不少 ToC 端应用提供的更可能是服务而不是业务，他们更多的关注重点放在服务上而并不是业务范畴。

单项目应用

对于后端开发而言，都是由单体应用开始的，可是对于前端开发，所谓单体应用的说法并不合适，因此我在这里把它叫作单项目应用。

对于一个刚刚开始的创业公司，是没有足够的人力储备以及代码实践。此时咱们要作的就是利用脚手架开启项目进行开发。咱们须要作的是作好代码规范，把代码写好。更多的考虑前端组件化与服务分离。

依赖注入

若是不考虑项目中基于业务的各类依赖库以及其中的设计模式，那么依赖注入必然是打造一个易于修改与扩展的项目不可或缺的设计模式。控制反转和依赖注入能够参考 控制反转和依赖注入的理解(通俗易懂)。

但很惋惜，在众多的前端框架中仅仅只有 Angular 内置该功能，且仅有 Angular 有服务类(独立文件)的概念(不一样框架关注点不一样)。能够经过 Angular 中的依赖注入 进行学习。事实上，在开发较为复杂的业务时，对拉取以及处理数据的代码做为独立文件是不错的处理方式。这样其实也符合 react 和 vue 只作界面渲染层的需求，把功能服务提取出来，这样界面端框架切换就不太会影响服务的提供，就像公司在今年年中计划升级 vue3 这类的大的框架接口改动，出错的可能也会减小。

以小程序请求服务为依赖诸如的例子，开始时候咱们注入了本身开发的请求类服务。后面发现了能够自带登录管理的网络请求组件 weRequest (若是你有此需求，也能够看看我以前写的 从 weRequest登录态管理来聊聊业务代码 这篇博客)。此时，咱们要替换以前的请求服务，只须要对 weRequest 再包装一层，提供与以前服务相等的接口就不须要大幅度修改与业务相关的代码，这样修改基本上也不会出现 bug。诸如此类还有缓存服务等，只要接口不变，究竟存储在 sessionStorage 仍是内存,又或者 LRU (Least recently used) 仍是 LFU (Least frequently used),这只取决于服务是如何提供的。

我的认为若是想要开发一个持续迭代的应用，必定要在 ETC 上下足了功夫。创业公司更是如此。不然，若是在开发中须要增长一个新的需求或者修改当前需求，却发现当前的服务难以使用乃至于须要重写整个服务，这个在业务开发中是没法接受的。同时，初创公司的需求修改是最为常见的。不过，过分设计也是程序员的通病。

多项目分离

随着项目的慢慢变大，虽然咱们能够依靠 Webpack 按需加载，但项目的编译与构建时间却不断增加。同时遇到某一个局部 bug 也须要全量编译与发布。项目在开发阶段遇到了巨大的阻力。

组件与服务提取

分离出不易变化的共通代码，独立做为项目发布与部署是可行的方法。就像咱们会使用 Webpack externals 来导入外部依赖同样，咱们把项目中不易变化的代码分离出去。就像咱们会使用开源库来协助开发同样，不可避免的会由于自身需求与开源库不相符合，同时又由于业务需求没那么通用因此不适合提炼出来，只能本身修改。包括不少的服务以及组件。我这里叫作业务型组件。由于这一类基于业务从基础组件中开发出来，但在稳定后改动性也不大。

固然，这里的话，能够采用的是单项目多程序包，相似于 lerna 这种模式，也能够采用多项目模式。固然，对于目前初创公司而言，不太可能有几个产品同时在开发，因此可能相似 lerna 解决方案会更好。可是若是能够提取几个产品的共通服务，却是能够做为公司的基础库来维护。由于不太容易改变，因此让两个开发人员在有需求的时候去维护也绰绰有余，毕竟不像开源项目那样，须要服务的是各类各样的公司，千奇百怪的需求。固然，提炼出来的业务必定要很是基础。由于比不提取共同代码更难接受的就是一有需求就要改动依赖库的代码。与业务紧密相关的组件或者服务仍是放在主项目中，以便于修改。

widget 开发

微件（Web Widget)，中文可译做：小部件、小工具、微件、挂件等，是一小块能够在任意一个基于HTML的网页上执行代码构成的小部件，它的表现形式多是视频、地图、新闻或小游戏等等。咱们在 ToC 应用常常会使用，例如在网页中插入百度地图，或者百度商桥(在线客服网页插件)等网页 wediget。

在持续工做与开发的过程当中，咱们有一些业务是与当前业务关系不是那么大，例如登录业务，不少时候，登录是独立于咱们当前业务以外的业务。例如像阿里不少登录都会有钉钉登录，支付宝登录等模式，把整个登录界面做为单独的项目而后用 iframe 进行登录业务开发。若是作的好的话，咱们多个产品就可使用同一个登录项目。这个对于小公司能够节省很多开发时间。

咱们在开发中遇到的报表等无强业务相关的代码均可以提出来做为单独项目进行开发。若是有需求的状况下，也能够开发浏览器插件来辅助业务开发。

多页面业务拆分

伴随着代码的进一步扩展，咱们开始基于不一样的业务来拆分咱们的项目。固然，事实上基于业务的多页面拆分并不意味真正的须要多个项目。在当前人手不够的状况下，不拆分为多个项目更好。固然此时各个单页面须要都须要加载共同的控制台头部(参考阿里云控制台)。固然，事实上，在单项目应用时期，咱们就能够按照多页面拆分。可是当前若是没有作过上述几个操做，项目的编译和构建在开发中将会是一个灾难。同时，咱们若是能够按照单页面拆分整个项目，就能够减小全局状态，减小各个业务间的全局状态也在必定程度上规避 bug。

能够看到，到达这一步，初创公司从零开发的产品可能已经开发了 2-3 年。若是当前的公司没有特别大的资金介入，可能在将来的几年内仍是以这种形态进行开发。

微前端

Techniques, strategies and recipes for building a modern web app with multiple teams that can ship features independently. -- Micro Frontends

上面是微前端的定义，首先第一个关键词就是多团队，多团队表明涉及的业务和人员有必定的基数，若是人员团队不够多，实在不必上微前端。同时，微前端不会限制技术栈。某些特定场景下可能特定的技术栈有更好的生态。

固然，我认为微前端的最大的做用就是在遗留系统中作增量升级。面对已经上线几年的老项目，咱们不可能一步到位就升级现有系统的技术栈。微前端是我已知实现渐进式重构的最好方案。

上述基于业务拆分虽然也能够解决状态隔离和独立开发部署等功能，可是因为须要加载同一个控制台头部，因此不能简单的作到各业务技术栈无关(能够作，可是目前须要双方协同)。不过我的目前也遇不到此类需求。

简而言之，微前端就是将大而恐怖的东西切成更小，更易于管理的部分，而后明确地代表它们之间的依赖性。各自团队的技术选择，代码库，发布流程都应该可以彼此独立地运行和扩展。无需过多的协调，让各个团队之间高内聚而低耦合。更自由灵活的使用 ETC 原则。

由于公司目前在创业阶段，没有微前端的需求。因此对微前端更多的是概念解读，而并不是落地实践。固然，对于需求微服务的团队来讲，实际上想要落地，仍是须要作很是多的工做的，我的也没有什么技术实践和经验，就再也不继续再写下去了。关于业界实践，你们能够看一看D2 中关于微前端专场的资料 d2forum 14th 与 视频，也能够关注 qiankun 和 alibabacloud-console-os。后面我也会多研究这两个开源库来提高本身。

鼓励一下

若是你以为这篇文章不错，但愿能够给与我一些鼓励，在个人 github 博客下帮忙 star 一下。
博客地址

参考资料

易于修改原则

micro-frontends

d2forum 14th

qiankun

alibabacloud-console-os