为何微前端开始在流行——Web 应用的聚合

采用新技术，更多不是由于先进，而是由于它能解决痛点。

过去，我一直有一个疑惑，人们是否真的须要微服务，是否真的须要微前端。毕竟，没有银弹。当人们考虑是否采用一种新的架构，除了考虑它带来好处以外，仍然也考量着存在的大量的风险和技术挑战。

前端遗留系统迁移

自微前端框架 Mooa 及对应的《微前端的那些事儿》发布的两个多月以来，我陆陆续续地接收到一些微前端架构的一些咨询。过程当中，我发现了一件颇有趣的事：解决遗留系统，才是人们采用微前端方案最重要的缘由。

这些咨询里，开发人员所遇到的状况，与我以前遇到的情形并类似，个人场景是：设计一个新的前端架构。他们开始考虑前端微服务化，是由于遗留系统的存在。

过去那些使用 Backbone.js、Angular.js、Vue.js 1 等等框架所编写的单页面应用，已经在线上稳定地运行着，也没有新的功能。对于这样的应用来讲，咱们也没有理由浪费时间和精力重写旧的应用。这里的那些使用旧的、再也不使用的技术栈编写的应用，能够称为遗留系统。而，这些应用又须要结合到新应用中使用。我遇到的较多的状况是：旧的应用使用的是 Angular.js 编写，而新的应用开始采用 Angular 2+。这对于业务稳定的团队来讲，是极为常见的技术栈。

在即不重写原有系统的基础之下，又能够抽出人力来开发新的业务。其不单单对于业务人员来讲， 是一个至关吸引力的特性；对于技术人员来讲，不重写旧的业务，同时还能作一些技术上的挑战，也是一件至关有挑战的事情。

后端解耦，前端聚合

而前端微服务的一个卖点也在这里，去兼容不一样类型的前端框架。这让我又联想到微服务的好处，及许多项目落地微服务的缘由：

在初期，后台微服务的一个很大的卖点在于，可使用不一样的技术栈来开发后台应用。可是，事实上，采用微服务架构的组织和机构，通常都是中大型规模的。相较于中小型，对于框架和语言的选型要求比较严格，如在内部限定了框架，限制了语言。所以，在充分使用不一样的技术栈来发挥微服务的优点这一点上，几乎是不多出现的。在这些大型组织机构里，采用微服务的缘由主要仍是在于，使用微服务架构来解耦服务间依赖。

而在前端微服务化上，则是偏偏与之相反的，人们更想要的结果是聚合，尤为是那些 To B（to Bussiness）的应用。

在这两三年里，移动应用出现了一种趋势，用户不想装那么多应用了。而每每一家大的商业公司，会提供一系列的应用。这些应用也从某种程度上，反应了这家公司的组织架构。然而，在用户的眼里他们就是一家公司，他们就只应该有一个产品。类似的，这种趋势也在桌面 Web 出现。聚合成为了一个技术趋势，体如今前端的聚合就是微服务化架构。

兼容遗留系统

那么，在这个时候，咱们就须要使用新的技术、新的架构，来容纳、兼容这些旧的应用。而前端微服务化，正好是契合人们想要的这个卖点呗了。

你说呢？