為什麼微前端開始在流行——Web 應用的聚合

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

前端遺留系統遷移

自微前端架構

Mooa

及對應的《

微前端的那些事兒

》釋出的兩個多月以來，我陸陸續續地接收到一些微前端架構的一些咨詢。過程中，我發現了一件很有趣的事：解決遺留系統，才是人們采用微前端方案最重要的原因。

這些咨詢裡，開發人員所遇到的情況，與我之前遇到的情形并相似，我的場景是：設計一個新的前端架構。他們開始考慮前端微服務化，是因為遺留系統的存在。

過去那些使用 Backbone.js、Angular.js、Vue.js 1 等等架構所編寫的單頁面應用，已經線上上穩定地運作着，也沒有新的功能。對于這樣的應用來說，我們也沒有理由浪費時間和精力重寫舊的應用。這裡的那些使用舊的、不再使用的技術棧編寫的應用，可以稱為遺留系統。而，這些應用又需要結合到新應用中使用。我遇到的較多的情況是：舊的應用使用的是 Angular.js 編寫，而新的應用開始采用 Angular 2+。這對于業務穩定的團隊來說，是極為常見的技術棧。

在即不重寫原有系統的基礎之下，又可以抽出人力來開發新的業務。其不僅僅對于業務人員來說， 是一個相當吸引力的特性；對于技術人員來說，不重寫舊的業務，同時還能做一些技術上的挑戰，也是一件相當有挑戰的事情。

後端解耦，前端聚合

而前端微服務的一個賣點也在這裡，去相容不同類型的前端架構。這讓我又聯想到微服務的好處，及許多項目落地微服務的原因：

在初期，背景微服務的一個很大的賣點在于，可以使用不同的技術棧來開發背景應用。但是，事實上，采用微服務架構的組織和機構，一般都是中大型規模的。相較于中小型，對于架構和語言的選型要求比較嚴格，如在内部限定了架構，限制了語言。是以，在充分使用不同的技術棧來發揮微服務的優勢這一點上，幾乎是很少出現的。在這些大型組織機構裡，采用微服務的原因主要還是在于，使用微服務架構來解耦服務間依賴。

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

在這兩三年裡，移動應用出現了一種趨勢，使用者不想裝那麼多應用了。而往往一家大的商業公司，會提供一系列的應用。這些應用也從某種程度上，反應了這家公司的組織架構。然而，在使用者的眼裡他們就是一家公司，他們就隻應該有一個産品。相似的，這種趨勢也在桌面 Web 出現。聚合成為了一個技術趨勢，展現在前端的聚合就是微服務化架構。

相容遺留系統

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

你說呢？

原文釋出時間為：2018年06月12日

原文作者：Phodal

本文來源： 

掘金 https://juejin.im/entry/5b3a29f95188256228041f46

如需轉載請聯系原作者