BigPipe和微前端

時間 2020-02-03

標籤 bigpipe 前端简体版

原文原文鏈接

你可能據說過 BigPipe，這是一個十多年前的技術，而 BigPipe 一般都會跟「性能優化」同時被提起。微前端也是一個很早被提出的技術，可是最近幾年纔開始比較流行。而目前微前端可以解決的最大的問題恐怕就是遺留系統改造。咱們能夠將新技術構造的系統和舊技術構造的系統完美融合到一塊兒，彼此構建，發佈，運行等不受干擾。那麼 BigPipe 究竟和微前端有什麼關係呢，我爲何要把這兩個放到一塊兒來看？css

回答這個問題以前，咱們先來看下什麼是 BigPipe，以及什麼是微前端。html

BigPipe

BigPipe 最先上 FaceBook 用來提高自家網站性能的一個祕密武器。其核心思想在於將頁面分紅若干小的構件，咱們稱之爲 pagelet。每個構件之間並行執行。前端

那麼 BigPipe 作了什麼？和傳統方式有什麼不一樣呢？咱們知道瀏覽器處理咱們的 HTML 文檔以及其中包含的 CSS，JS 等資源的時候是從上到下串行執行的。若是咱們把瀏覽器處理的過程劃分爲若干階段（stage），那麼這些階段之間有着明顯的時間前後關係。那麼咱們能不能將其並行化，從而減小時間呢？這就是 BigPipe 的基本思想。web

話很少說，咱們經過一段代碼來幫助你們理解,好比你的項目首頁是 home.html，大概這樣子：express

<!DOCTYPE html>
<html>
  <head>
    <script>
      window.BigPipe = {
        render(selector, content) {
          document.querySelector(selector).innerHTML = content;
        }
      };
    </script>
  </head>
  <body>
    <div id="pagelet1"></div>
    <div id="pagelet2"></div>
    <div id="pagelet3"></div>
  </body>
</html>

瀏覽器首先加載過來就是一個佔位元素，這部分沒有 JS 和 CSS，只有 HTML 部分，所以會很快。segmentfault

以後咱們慢慢填充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('<script>BigPipe.render("#pagelet1","hello");</script>', 1000)
  const p2 = wirteChunk('<script>BigPipe.render("#pagelet2","word");</script>', 2000)
  const p3 = wirteChunk('<script>BigPipe.render("#pagelet3","!");</script>', 3000)

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

});

app.listen(3000);

從這裏咱們能夠看出，BigPipe 不是框架，不是新技術。咱們只須要按照這樣作就好了。這對於頁面能夠細分爲多個塊，塊之間關聯不大的場景很是有用。若是仍是不太明白，能夠看下這篇文章 -bigpipe-pipelining-web-pages-for-high-performance安全

說完了 BigPipe，咱們再來看一下微前端。性能優化

微前端

和後端微服務相似，「微前端是一種架構風格，其中衆多獨立交付的前端應用組合成一個大型總體。」

若是你想作微前端，必定要可以回答出這 10 個問題。

微應用的註冊、異步加載和生命週期管理；
微應用之間、主從之間的消息機制；
微應用之間的安全隔離措施；
微應用的框架無關、版本無關；
微應用之間、主從之間的公共依賴的庫、業務邏輯(utils)以及版本怎麼管理；
微應用獨立調試、和主應用聯調的方式，快速定位報錯（發射問題）；
微應用的發佈流程；
微應用打包優化問題；
微應用專有云場景的出包方案；
漸進式升級：用微應用方案平滑重構老項目。

這裏有一篇文檔，區別與別的微前端文章的點在於其更加靠近規範層面，而不是結合本身的業務場景作的探索。這篇文章來自於阿里團隊。

文章地址： https://mp.weixin.qq.com/s/rY...

還有一篇文章也不錯，一併推薦給你們 - 大前端時代下的微前端架構：實現增量升級、代碼解耦、獨立部署

微前端中有一個重要的須要解決的問題是子系統之間的路由。而咱們的 BigPipe 若是被看成一個個子應用的，那不就是微前端中的一個點麼？BigPipe 也好，微前端也好，都是一種概念，一種指導思想。微前端是不限於技術棧的，你可使用傳統的 ssr，也可使用 csr，也可使用現代 csr + ssr 等，框架也能夠五花八門。如何將這些系統組合起來，而且可以有條不紊地進行合做完成一個完整的應用？這是微前端所研究和要解決的問題。

對於微前端，咱們隔離各個應用的方式有幾種：

iframe
相似 bigpipe 這種客戶端異步加載技術
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 常見的一個功能「合併請求」在這裏扮演了什麼樣的角色？你們能夠本身想一下。當你不斷從不一樣角度思考問題，會發現不少東西都有關聯。每個技術背後每每都會落到幾個基本的原理上。瞭解技術初始產生背後解決的問題對於掌握一個技術來講很是重要。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。