BigPipe和微前端

你可能听说过 BigPipe，这是一个十多年前的技术，而 BigPipe 通常都会跟“性能优化”同时被提起。微前端也是一个很早被提出的技术，但是最近几年才开始比较流行。而目前微前端能够解决的最大的问题恐怕就是遗留系统改造。我们可以将新技术构造的系统和旧技术构造的系统完美融合到一起，彼此构建，发布，运行等不受干扰。 那么 BigPipe 究竟和微前端有什么关系呢，我为什么要把这两个放到一起来看？

回答这个问题之前，我们先来看下什么是 BigPipe，以及什么是微前端。

BigPipe

BigPipe 最早上 FaceBook 用来提升自家网站性能的一个秘密武器。其核心思想在于将页面分成若干小的构件，我们称之为 pagelet。每一个构件之间并行执行。

那么 BigPipe 做了什么？和传统方式有什么不同呢？我们知道浏览器处理我们的 HTML 文档以及其中包含的 CSS，JS 等资源的时候是从上到下串行执行的。如果我们把浏览器处理的过程划分为若干阶段（stage），那么这些阶段之间有着明显的时间先后关系。那么我们能不能将其并行化，从而减少时间呢？这就是 BigPipe 的基本思想。

话不多说，我们通过一段代码来帮助大家理解,比如你的项目首页是 home.html，大概这样子：

浏览器首先加载过来就是一个占位元素，这部分没有 JS 和 CSS，只有 HTML 部分，因此会很快。

之后我们慢慢填充pagelet1,pagelet2, pagelet3,在用户看来，就是一种“渐进式渲染”的效果。

服务端代码大概是：

const app = require('express')();
const fs = require('fs');

// 模拟真实场景
function wirteChunk(content, delay, res) {
    return new Promise(r => {
        setTimeout(function() {
            res.write(content);
        delay);
    })
}

app.get('/', function (req, res) {
  // 为了简化代码，直接同步读。 强烈不建议生产环境这么做！
  res.write(fs.readFileSync(__dirname   "/home.html").toString());

  const p1 = wirteChunk('', 1000)
  const p2 = wirteChunk('', 2000)
  const p3 = wirteChunk('', 3000)

  Promise.all([p1, p2, p3]).then(res.end)

});

app.listen(3000);

从这里我们可以看出，BigPipe 不是框架，不是新技术。我们只需要按照这样做就行了。 这对于页面可以细分为多个块，块之间关联不大的场景非常有用。如果还是不太明白，可以看下这篇文章 -bigpipe-pipelining-web-pages-for-high-performance

说完了 BigPipe，我们再来看一下微前端。

微前端

和后端微服务类似，“微前端是一种架构风格，其中众多独立交付的前端应用组合成一个大型整体。”

如果你想做微前端，一定要能够回答出这 10 个问题。

1. 微应用的注册、异步加载和生命周期管理；
2. 微应用之间、主从之间的消息机制；
3. 微应用之间的安全隔离措施；
4. 微应用的框架无关、版本无关；
5. 微应用之间、主从之间的公共依赖的库、业务逻辑(utils)以及版本怎么管理；
6. 微应用独立调试、和主应用联调的方式，快速定位报错（发射问题）；
7. 微应用的发布流程；
8. 微应用打包优化问题；
9. 微应用专有云场景的出包方案；
10. 渐进式升级：用微应用方案平滑重构老项目。

这里有一篇文档，区别与别的微前端文章的点在于其更加靠近规范层面，而不是结合自己的业务场景做的探索。这篇文章来自于阿里团队。

文章地址： https://mp.weixin.qq.com/s/rYNsKPhw2zR84-4K62gliw

还有一篇文章也不错，一并推荐给大家 - 大前端时代下的微前端架构：实现增量升级、代码解耦、独立部署

微前端中有一个重要的需要解决的问题是子系统之间的路由。而我们的 BigPipe 如果被当作一个个子应用的，那不就是微前端中的一个点么？BigPipe 也好，微前端也好，都是一种概念，一种指导思想。微前端是不限于技术栈的， 你可以使用传统的 ssr，也可以使用 csr，也可以使用现代 csr ssr 等，框架也可以五花八门。 如何将这些系统组合起来，并且能够有条不紊地进行合作完成一个完整的应用？这是微前端所研究和要解决的问题。

对于微前端，我们隔离各个应用的方式有几种：

1. iframe
2. 类似 bigpipe 这种客户端异步加载技术
3. web-components

不管采用哪种方式，我们的大体逻辑都是：

• 先加载主框架
• 异步加载各个子应用

只不过加载子应用，我们可以通过 iframe 去加载，也可以使用 web-component 去加载，也可以使用类似 bigpipe 的方式分段并行加载。我们甚至可以将这几者进行结合使用。而 iframe 和 web-compoents 顺带解决了诸如 js 和 css 等隔离的作用，而 bigPipe 只是对资源加载的一个有效控制，其本身并没有什么特殊含义，更不要说诸如 js 和 css 等隔离作用了。

事物关联

当前端有了 Nodejs 之后，我们发现可以做的事情变多了，除了 BigPipe，我们又去做 ssr，又要做 graphql，还要做微前端，海报服务，AI 等等。当你从大的视角看的时候，会发现这些技术或多或少都有交集，比如我刚才提到的 ssr。 我们知道 ssr 中有一点就是我们先返回给用户一个有内容的 html，这个 html 在服务端生成，由于在服务端生成，因此只有样式，没有绑定事件，所以后续我们需要在客户端合成事件。 如果将上面 BigPipe 的代码拿过来看的话，会发现我们的 html markup 可以看作服务端渲染内容（可以是直接写死的，也可以是服务端动态生成的）。之后我们输出后续 pagelet 的 JS 代码到前端，前端继续去执行。基于 BigPipe 我们甚至可以控制页面优先级显示。我们再继续去看的话， BFF 常见的一个功能“合并请求”在这里扮演了什么样的角色？大家可以自己想一下。当你不断从不同角度思考问题，会发现很多东西都有关联。每一个技术背后往往都会落到几个基本的原理上。了解技术初始产生背后解决的问题对于掌握一个技术来说非常重要。