將微服務理念擴展到前端開發
前言
在 ThoughtWorks 正式發布的最新一期技術雷達當中，「微前端（Micro Fontends）」已經進入到試驗階段，而試驗環所列出的技術是我們認為值得去追求的。理解如何建立這種能力對你所在的組織十分重要，現在就可以嘗試在一個低風險的項目上試點和實踐這項技術，幫助你真正了解這門技術。
摘自最新一期技術雷達：
我們已經從引入微服務架構中獲得了明顯的好處，微服務架構可以讓團隊裁剪出獨立部署的交付物以及可維護的服務。不幸的是，我們還看到許多團隊在後端服務之上創建了前端單體——一個單一、龐大和雜亂無緒的瀏覽器應用。我們首選的（經過驗證的）方法是將基於瀏覽器的代碼拆分成微前端。在這種方法中，Web 應用程序被分解為多個特性，每個特性都由不同的前後端團隊擁有。這確保每個特性都獨立於其他特性開發，測試和部署。這樣可以使用多種技術來重新組合特性——有時候是頁面，有時候是組件——最終整合成一個內聚的用戶體驗。
文章大綱：
微前端的緣由：單體應用與微服務架構
微前端的定義 - 將微服務理念擴展到前端開發
微前端的緣由：單體應用與微服務架構
在傳統的軟體開發當中，大多數軟體都是單體式應用架構。在瞬息萬變的商業時代背景下，企業必須學會適應這個時代的不確定性。快速試驗、快速失敗、更快地推出新產品以及有效改進當前產品，從而為客戶提供有意義的數字體驗。
而單體應用這種軟體架構對於企業來說有一個致命缺點——會致使企業對於市場的響應速度變慢。企業決策者在一年內需要做的決策數量非常有限，由於存在依賴關係，其響應周期往往會變得非常漫長。每當開發或升級產品，都需要在一系列體量龐大的相關服務中同時增加新功能，這就需要所有利益相關方共同努力，以同步方式進行變更。
微服務架構帶來了哪些好處？
假設服務邊界已經被正確地定義為可獨立運行的業務領域，並確保在微服務設計中遵循諸多最佳實踐。那麼至少會在以下幾個方面獲得顯而易見的好處：
每個微服務是孤立、獨立的「模塊」，它們共同為更高的邏輯目的服務。微服務之間通過契約彼此溝通，每個服務都負責特定的功能。這使得每個服務都能夠保持簡單、簡潔和可測試性。
在這一基礎上微服務架構允許企業更自發地採取更深遠的業務決策，因為每個微服務都是獨立運作的，而且每一個管理團隊可以很好地控制該服務的變更。
那麼前端的現狀呢？ —— 臃腫的前端
（圖片來自：http://t.cn/R8biudo）
在前端，往往由一個前端團隊創建並維護一個 Web 應用程序，使用 REST API 從後端服務獲取數據。這樣的做法能夠提供優秀的用戶體驗，但會導致單頁面應用（SPA）不能很好地擴展和部署。在一個大公司里，單前端團隊可能成為一個發展瓶頸。隨著時間的推移，由一個獨立團隊所開發的前端層往往會越來越難以維護。特別是一個特性豐富、功能強大的前端 Web 應用程序，卻位於後端微服務架構之上時。隨著業務的發展，前端會變得越來越臃腫，一個項目可能會有 90％ 的前端代碼，卻只有非常薄的後端，這種情況在 Serverless 架構的背景下還會愈演愈烈。
微前端的定義 - 將微服務理念擴展到前端開發
微前端（Micro Frontends）這個術語其實就是微服務的衍生物。將微服務理念擴展到前端開發，同時構建多個完全自治、松耦合的 App 模塊（服務），其中每個 App 模塊只負責特定的 UI 元素和功能。
如果我們看到微服務提供給後端的好處，就可以更進一步將這些好處應用到前端。與此同時，在設計微服務的時候，就可以考慮不僅要完成後端邏輯，而且還要完成前端的視覺部分。而微前端與微服務的許多要求也是一致的：監控、日誌、HealthCheck、Analytics 等等。
微前端的核心思想
Be Technology Agnostic：每個團隊都應該能夠選擇並升級他們的技術棧，而不必與其他團隊協調。自定義元素（後面會具體提到）是隱藏實現細節的好方法，同時為其他人提供公共介面。
※phantomJs之殤，chrome-headless之生
TAG:思特沃克 |