採用新技術，更多不是因為先進，而是因為它能解決痛點。
過去，我一直有一個疑惑，人們是否真的需要微服務，是否真的需要微前端。畢竟，沒有銀彈。當人們考慮是否採用一種新的架構，除了考慮它帶來好處之外，仍然也考量著存在的大量的風險和技術挑戰。
前端遺留系統遷移
自微前端框架 Mooa 及對應的《微前端的那些事兒》釋出的兩個多月以來，我陸陸續續地接收到一些微前端架構的一些諮詢。過程中，我發現了一件很有趣的事：解決遺留系統，才是人們採用微前端方案最重要的原因。
這些諮詢裡，開發人員所遇到的情況，與我之前遇到的情形並相似，我的場景是：設計一個新的前端架構。他們開始考慮前端微服務化，是因為遺留系統的存在。
過去那些使用 Backbone.js、Angular.js、Vue.js 1 等等框架所編寫的單頁面應用，已經線上上穩定地執行著，也沒有新的功能。對於這樣的應用來說，我們也沒有理由浪費時間和精力重寫舊的應用。這裡的那些使用舊的、不再使用的技術棧編寫的應用，可以稱為遺留系統。而，這些應用又需要結合到新應用中使用。我遇到的較多的情況是：舊的應用使用的是 Angular.js 編寫，而新的應用開始採用 Angular 2+。這對於業務穩定的團隊來說，是極為常見的技術棧。
在即不重寫原有系統的基礎之下，又可以抽出人力來開發新的業務。其不僅僅對於業務人員來說， 是一個相當吸引力的特性；對於技術人員來說，不重寫舊的業務，同時還能做一些技術上的挑戰，也是一件相當有挑戰的事情。
後端解耦，前端聚合
而前端微服務的一個賣點也在這裡，去相容不同型別的前端框架。這讓我又聯想到微服務的好處，及許多專案落地微服務的原因：
在初期，後臺微服務的一個很大的賣點在於，可以使用不同的技術棧來開發後臺應用。但是，事實上，採用微服務架構的組織和機構，一般都是中大型規模的。相較於中小型，對於框架和語言的選型要求比較嚴格，如在內部限定了框架，限制了語言。因此，在充分使用不同的技術棧來發揮微服務的優勢這一點上，幾乎是很少出現的。在這些大型組織機構裡，採用微服務的原因主要還是在於，使用微服務架構來解耦服務間依賴。
而在前端微服務化上，則是恰恰與之相反的，人們更想要的結果是聚合，尤其是那些 To B（to Bussiness）的應用。
在這兩三年裡，移動應用出現了一種趨勢，使用者不想裝那麼多應用了。而往往一家大的商業公司，會提供一系列的應用。這些應用也從某種程度上，反應了這家公司的組織架構。然而，在使用者的眼裡他們就是一家公司，他們就只應該有一個產品。相似的，這種趨勢也在桌面 Web 出現。聚合成為了一個技術趨勢，體現在前端的聚合就是微服務化架構。
相容遺留系統
那麼，在這個時候，我們就需要使用新的技術、新的架構，來容納、相容這些舊的應用。而前端微服務化，正好是契合人們想要的這個賣點唄了。
你說呢？