鑽石舞台

本文最初發表於 ITNEXT 的博客站點，經原作者 Manu Ustenko 授權由 InfoQ 中文站翻譯分享。

在本文中，我將會討論從創業公司到成熟公司過渡時期的可擴展性問題，分享我的想法，並介紹在我工作的組織中所使用的技術。

有很多文章都討論多可擴展性這個話題，但是我想要澄清在本文中，可擴展性的含義：

一個可擴展的應用應該具備很多的原則，但是我想要強調其中最重要的一條：關注點分離與架構設計。

在本文中，我將會基於團隊拓撲概念進行闡述，並且會按照功能將團隊分為四個組，分別是業務導向（stream-aligned）團隊、賦能（enablement）團隊、複雜子系統（complicated subsystem）團隊和平台（platform）團隊。

我們正生活在一個創業公司的時代中。每天都有新的創業公司開業或關閉，企業家們都在尋找新的機會，為我們的生活帶來新的商業模式。在這個過程中，我們不斷看到個人和公司的成長與失敗。

從技術角度來看，在公司生命周期的這個階段，公司中的技術規模比較小，易於維護，易於為業務帶來新的價值。在這個階段犯錯並不致命，可以很容易地解決。當然，這並不意味着最初的架構不重要，企業需要非常優秀的專家，他們可以在公司的早期階段做出正確的架構決策。在這個階段，一個或兩個開發小組（每個小組有 5 到 10 個成員）就足夠了。我認為如果在這個階段擁有更多的團隊將是組織方面的錯誤。

在公司的這個時代，從前端的角度來看，最佳方式使用較小的單體應用。它有很多的好處：

使代碼保持緊湊，易於開展工作

單體架構是很自然的選擇，易於實現

持續集成和部署都很簡單

我們不會過多地討論 IT 巨頭和成熟的公司。我們只需要知道，成熟的公司已經有了良好的業務、工作流程、行業基礎並且會有多個團隊專注其功能。

在這個階段，關鍵要素之一就是將功能性的任務分派給專門的團隊，每個團隊專注自己的功能，不允許任何團隊涵蓋多個功能。

隨着時間的推移，創業公司會達到一個沸點，前端應用開始變得不再靈活，無法與業務保持相同的速度。

在試圖交付新的功能以滿足業務需要時，每個交付周期都會延遲。技術團隊對業務的承諾經常落空，他們還沒有認識到環境已經發生了變化。團隊依然認為他們能夠如期交付某個新特性，但是卻一次又一次地失敗。

組織可以通過增加團隊或工程師的數量來滿足重要的需求。但令人遺憾的是，在很多情況下，將更多的人塞入到技術團隊中並不會帶來任何的價值。現在，應該改變流程了。

系統難以進行擴展的症狀包括：

在過渡期間，如果出現技術錯誤，其代價是非常高昂的。在這個階段，創業階段的錯誤會逐漸顯露出來。

為了讓業務繼續保持增長，組織中的技術領導層應該調整目前的狀態。流行的方案就是將單體架構遷移至微服務（後端技術）或微前端（前端技術）架構。

由於本文討論的是前端技術，所以我會繼續討論微前端，而不是微服務。同時，我也不會討論微前端架構是好是壞以及哪種微前端方式更好的問題，因為這方面已經有很多的文章和討論了。

相反，我會從可擴展性的角度來考慮微前端架構，以及它是如何解除企業在轉向多團隊模型時所面臨的障礙的。

一旦某個組織出現了我們上文所述的難以擴展的症狀，工程師就可以決定將系統從單體架構轉換成微前端架構。與此同時，它會給企業帶來一系列的收益。

微前端架構允許團隊將單體應用的代碼庫分割成更小塊的代碼。每個獨立微前端的源碼規模將小得多，並聚焦於應用中一小部分的功能。應用中的哪一部分要解耦成微前端，這應該由工程團隊決定。它可以是很大的內容（如頁面）也可以是很小的內容（如元素）。藉助新的代碼組織形式，新開發人員花更少的時間就能掌握代碼庫，並在短時間內就開始對代碼做出貢獻。

微前端的代碼庫應該是隔離的，這有助於業務導向團隊選擇自己的工作策略和流程。每個團隊對應用的一個垂直切片擁有全部的所有權，並且可以在其領域內進行專業化。他們不用擔心團隊之間的干擾，這減少了團隊之間的協調需求。微前端能夠讓應用按照團隊的結構進行組織，這遵循了康威定律。

具體樣例：

如果某個團隊想在單體架構中嘗試新的技術（新的狀態管理器、測試庫等），這個決定需要在所有從事該應用的團隊間取得一致。這很費時間，而且最終可能難以被一些團隊接受。如果團隊是獨立的，該團隊的工程師就可以決定要使用什麼技術。這個決定完全不涉及其他的團隊。

與微服務的方式相同，微前端要對它的部署負責。它讓業務導向團隊能夠獨立發布應用的某一部分。此時不用重新部署整個應用，每個團隊都可以只部署其中的小部分功能。這能夠讓團隊在發布的時候，不需要與其他團隊協調，也不需要適應全公司的發布周期。如果最後的部署出現問題，能夠很容易地回滾而不影響其他團隊的工作。將代碼庫分割成小塊，使得微前端的部署需要更短的時間。

採用微前端的原因之一就是實現垂直領域的所有權拆分。從整個公司掌握所有權的單體架構，轉變成多個團隊掌握所有權的微服務，這有助於公司在不同的團隊中擴大開發規模，促進後端所有權的拆分。每個業務導向團隊都擁有一個垂直方向的組件，他們從頭到尾負責該組件。

與大型應用相比，少量的代碼更易於測試覆蓋。這會促成整個系統中更好的測試覆蓋率，因為所有小部分的代碼都會被測試覆蓋到。

微前端的優勢之一就是不依賴於所選擇的技術和框架。它更容易找到專門的團隊來完成微前端的工作，允許使用其他的技術和框架取代不適用的技術和框架，也能夠以較小的技術風險測試新技術。

接下來，我將介紹微前端架構應該遵循的最重要的原則，以保持系統的可擴展性。要實現這一點，我們要引入兩個術語：

編排器（orchestrator） 是用來協調所有微前端的父應用。在理想的情況下，它不包含任何邏輯或業務功能，只作為一個操作者（operator）存在。

子微前端 是一個領域驅動的應用，涵蓋了應用中某一個特定的組成部分。

不管技術團隊具體使用哪種微前端的方式，為了保持系統的可擴展性，遵循下面這些強制要求是非常重要的。

子微前端和編排器之間的強制要求：

子微前端之間的強制要求

子微前端之間是零耦合的。每個子微前端都不應該知道其他的微前端，必須能夠獨立工作。

不能從一個微前端導入另一個微前端

不能使用共享的狀態管理工具（如 Vuex，Redux）。

子微前端之間可以共享庫

所有的 CSS 代碼必須是範圍內的，以排除對樣式屬性的覆蓋。

決定採納微前端架構並不是過渡旅程的結束。這將是一個痛苦和危險的過程，但同樣也是一個有趣的認知經歷。許多陷阱將等待工程團隊去解決。

其中一個問題是整個微前端架構的維護問題。隨着時間的推移，系統可能會有幾十甚至幾百個微前端，而工程團隊將面臨新的挑戰：如何維護這些微前端。

如何引入新的微前端應用將是工程團隊在遷移到微前端架構後遇到的第一個問題。如何在不增加複雜性的情況下搭建一個新的微前端腳手架？由哪個團隊負責創建新的微前端？微前端應該遵循哪些標準？

這些相關的問題必須由工程團隊解決，以保持系統的可擴展性和易維護性。否則，系統在很短的時間內就會變得非常混亂。

我們預期得到的解決方案是，每個新的微前端都能快速創建，並且有非常相似的設置，以保持所有微前端之間的一致性。我想到了「傳送帶（conveyor）」這個詞。

我們有多種方法可以達成該目的。我想和大家分享一個如何實現該目標的想法，那就是使用一個可以在幾分鐘內基於模板創建新微前端的工具。這可以是現成的解決方案，如 cookiecutter 或其他類似工具。

創建新的微前端只是萬里長征第一步。隨着時間的推移，將會有許多微前端需要與基本模板進行同步。這可能也是我們需要模板的原因：解決漏洞、更新配置、更新其他軟件包的版本等。

令人遺憾的是，cookiecutter 無法將現有的項目與模板同步。為了解決這個問題，在我的公司中，我們開發了自己的解決方案，它可以為新創建或已有的微前端提供一個腳手架。

在編寫概念驗證（Prove of Concept）項目的過程中，我創建了 mucli 項目，它基於我們組織中遵循的類似原則。該項目會在 Github 上獲取倉庫，在倉庫中尋找模板，並創建新項目或同步現有的項目。它提供了如下開箱即用的功能：

從模板庫創建和同步項目。你可以創建自己的模板庫並使用 mucli 進行項目創建和同步。模板庫是完全獨立的，由你自行維護。mucli 包只是與你的模板協作而已。

用戶友好的命令行界面，可以為每個模板添加自定義的用戶問題。

支持在文件中插入動態值，能夠根據設置或用戶互動來創建自定義的文件。

前綴系統，可以使用不同的前綴來標記文件，以便在同步過程中對這些文件進行操作。

可組合的模板，它可以基於較小的模塊創建出一個非常靈活的模板。

歡迎了解 mucli 項目並為其貢獻內容。我將在接下來的文章中深入探討它的實現細節。

在這篇文章中，我分享了我們從創業公司轉變為成熟公司期間的想法和決定。如果你對這些話題感興趣的話，可以通過 GitHub 或 Twitter 與我聯繫。

聲明：本文為InfoQ翻譯，未經許可禁止轉載。