爲何微前端開始在流行：後端解耦，前端聚合

採用新技術，更多不是由於先進，而是由於它能解決痛點。

過去，我一直有一個疑惑，人們是否真的須要微服務，是否真的須要微前端。畢竟，沒有銀彈。當人們考慮是否採用一種新的架構，除了考慮它帶來好處以外，仍然也考量着存在的大量的風險和技術挑戰。

前端遺留系統遷移

自微前端框架 Mooa 及對應的《微前端的那些事兒》發佈的兩個多月以來，我陸陸續續地接收到一些微前端架構的一些諮詢。過程當中，我發現了一件頗有趣的事：解決遺留系統，纔是人們採用微前端方案最重要的緣由。

這些諮詢裏，開發人員所遇到的狀況，與我以前遇到的情形並類似，個人場景是：設計一個新的前端架構。他們開始考慮前端微服務化，是由於遺留系統的存在。

過去那些使用 Backbone.js、Angular.js、Vue.js 1 等等框架所編寫的單頁面應用，已經在線上穩定地運行着，也沒有新的功能。對於這樣的應用來講，咱們也沒有理由浪費時間和精力重寫舊的應用。這裏的那些使用舊的、再也不使用的技術棧編寫的應用，能夠稱爲遺留系統。而，這些應用又須要結合到新應用中使用。我遇到的較多的狀況是：舊的應用使用的是 Angular.js 編寫，而新的應用開始採用 Angular 2+。這對於業務穩定的團隊來講，是極爲常見的技術棧。

在即不重寫原有系統的基礎之下，又能夠抽出人力來開發新的業務。其不單單對於業務人員來講， 是一個至關吸引力的特性；對於技術人員來講，不重寫舊的業務，同時還能作一些技術上的挑戰，也是一件至關有挑戰的事情。

後端解耦，前端聚合

而前端微服務的一個賣點也在這裏，去兼容不一樣類型的前端框架。這讓我又聯想到微服務的好處，及許多項目落地微服務的緣由：

在初期，後臺微服務的一個很大的賣點在於，可使用不一樣的技術棧來開發後臺應用。可是，事實上，採用微服務架構的組織和機構，通常都是中大型規模的。相較於中小型，對於框架和語言的選型要求比較嚴格，如在內部限定了框架，限制了語言。所以，在充分使用不一樣的技術棧來發揮微服務的優點這一點上，幾乎是不多出現的。在這些大型組織機構裏，採用微服務的緣由主要仍是在於，使用微服務架構來解耦服務間依賴。

而在前端微服務化上，則是偏偏與之相反的，人們更想要的結果是聚合，尤爲是那些 To B（to Bussiness）的應用。

在這兩三年裏，移動應用出現了一種趨勢，用戶不想裝那麼多應用了。而每每一家大的商業公司，會提供一系列的應用。這些應用也從某種程度上，反應了這家公司的組織架構。然而，在用戶的眼裏他們就是一家公司，他們就只應該有一個產品。類似的，這種趨勢也在桌面 Web 出現。聚合成爲了一個技術趨勢，體如今前端的聚合就是微服務化架構。

兼容遺留系統

那麼，在這個時候，咱們就須要使用新的技術、新的架構，來容納、兼容這些舊的應用。而前端微服務化，正好是契合人們想要的這個賣點唄了。

你說呢？