瞭解新興架構模式：微應用架構

作者 | Gio Lodi

譯者 | 劉志勇

策劃 | Tina  

本文最初發表於 Increment 雜誌，經原作者 Gio Lodi 授權，InfoQ 中文站翻譯並分享。

本文講述了微服務（Microservice）所啓發的新興架構模式如何爲特性開發注入活力並加快開發者的速度。

20 世紀末，網絡公司，如 Netflix 和亞馬遜，都面臨着大規模軟件開發的挑戰。要將數百個貢獻者對龐大的共享代碼庫進行修改所產生的摩擦降到最小，他們將軟件分割成可以在雲中租用的硬件上隔離部署和擴展的服務。將單體應用分解爲獨立的微服務集羣，使團隊可以更快地行動，減少操作衝突。以產品爲導向的團隊可以擁有單獨的服務，並對其開發和運營進行精細控制。

如今，移動開發團隊也面臨着上世紀末這些網絡巨頭所遇到的規模挑戰。另外，他們還必須克服額外的障礙：應用程序作爲單一的二進制文件交付，用戶可以下載到自己的設備上運行。隨着移動應用程序代碼庫的增長，編譯成越來越大的二進制文件所需的時間也越來越長。

爲了應對這些擴展的挑戰，SoundCloud、Just Eat 和 realestate.com.au 這樣的移動團隊一直在探索一種類似於微服務的方法來構建他們的應用。由於將模塊隔離在專用代碼庫中，他們發現可以避免冗長的構建時間，轉而使用能夠提供更快反饋週期的專門的、特定功能的應用程序。

採用微應用架構。

1 什麼是微應用？

微服務將後端分離出來的區域單獨部署。與此類似，移動開發者可以將應用程序的不同核心部分——單一特性、共享業務邏輯和低級特性——轉移到獨立的模塊庫中。由此產生的模塊彼此獨立，並且獨立於主要的應用程序代碼庫，團隊可以自行處理它們。

這種架構不同於其他強調模塊化的方法，即微應用（Microapp），使用特定模塊作爲快速開發和測試的工具。團隊可以構建一個或多個面向內部的微應用程序，以滿足其需要，僅包含所開發特性所需的模塊。舉例來說，一個負責電子商務應用的結賬組件的團隊，可以構建一個測試微應用，枚舉出支付方式、送貨地址和購車內容的組合。這樣，他們就可以更快地測試結賬流程，而不用在主應用程序中手工複製每一個組合。

針對特定的特性配置專門的微應用程序，對於迭代速度來說是一大優勢。與面向用戶的應用程序相比，微應用程序構建起來更快，因爲需要更少的編譯代碼。另外，由於微應用僅用於內部，他們不需要精緻的用戶體驗，可以預先植入相關的測試數據，並能避開客戶旅程的整個環節，例如登機。在驗證更改時，這會顯著地減少摩擦，並且與更快的構建時間相結合，從而創建更快速有效的開發流程。

因此，微應用的架構包括一個模塊化設計，並輔之以專門的應用程序（稱爲微應用），供開發和測試使用，這就是爲了提高開發者的速度。與 MVC （模型 - 視圖 - 控制器）或 MVVM （模型 - 視圖 - 控制器） 等明確定義的框架相比，它更像是一種抽象的框架，因爲架構根據具體應用的特性而有所不同。然而，儘管沒有一種放之四海而皆準的辦法，但所有的成功實施都是一樣的。

2 微應用程序的基礎

在其核心部分，微應用程序是一種由鬆散耦合、高度內聚的模塊組成的網絡，高層的特性模塊依賴於低層的特性模塊。這些模塊通過一個薄薄的協調層連接起來，即面向用戶的應用程序，並由高級工具的骨幹支持。每一個特性模塊都可以有一個或多個專門的微應用程序，團隊可以在開發和測試更改時得到快速反饋。

面向用戶的應用

面向用戶的應用程序的代碼庫包含了孤立的模塊，並作爲協調器，將它們整合爲統一的用戶體驗。其實現應儘可能少，因爲所有的特性和業務邏輯都存在於專門的模塊中。它在啓動時實例化特性模塊，提供模塊所需的服務，將相關信息從一個模塊傳遞給另一個模塊，並傳播操作系統和應用程序的生命週期事件。

特性模塊

每一個特性或特性組屬於同一業務垂直領域，在一個專門的模塊中存在。舉例來說，在電子商務應用程序中，瀏覽庫存可能存在於購物車管理不同的模塊中。在模塊的代碼庫中，有該功能所需的所有業務邏輯和自定義用戶界面。

模塊並不直接實現低級別的特性，比如聯網或持久性；相反，它們爲所需的低級別的特性定義了抽象，並依賴於插入的應用程序來提供具體的實現。開發者主要通過單元測試和建立專門的微應用程序來迭代特性模塊。

用戶界面模塊

不管微應用是否具有設計系統，所有跨特性的用戶界面元素和配置都應該在一個專門庫中，可以導入特性模塊。這樣可以大大減少用戶界面代碼的重複，並幫助爲用戶提供一致的視覺體驗。

基礎與實用模塊

基礎模塊和實用模塊提供了特性模塊和麪向用戶的應用程序共享的低級特性。

基礎模塊集中了一些特性的實現，比如與遠程 API 的接口或者從設備存儲中加載數據。將所有與低級特性相關的邏輯聚合起來，使其能夠在進行更改時更好地進行局部推理。在不同的特性模塊使用相同的底層邏輯時，每個模塊都可以從其他模塊的改進中獲益。回到我們的電子商務應用的例子，庫存瀏覽團隊的開發者可能希望通過加速網絡響應解碼來提高銷量。由於網絡解碼是基礎模塊的一部分，開發者所做的更改會讓應用程序中的所有請求變得更快，而不僅僅是瀏覽特性模塊的請求。

實用模塊所持有的邏輯，例如標準庫擴展，或定義明確的、孤立的功能，比如自定義日期格式化。這種代碼的變化速度往往比基礎或功能組件慢得多，因此將其存儲在一個專門的庫中意味着在構建消費者應用程序時無需重新編譯。

工具

在微應用程序中，CI 可以檢查每一個更改集，確定修改過的模塊及其下游依賴關係，並且只對代碼庫中較小的子集運行測試，而忽略那些未受更改影響的子集。這些構建將變得更快，因爲表面積較小，開發者也可以更快地得到關於他們修改的反饋。

以腳本或高級代碼生成工具（如 Tuist）形式出現的自動化，使得將新模塊集成到面向用戶的應用程序中成爲一項不太容易出錯的任務，使開發者不必編輯包含許多選項的配置文件，完全不需要對應用程序的依賴關係樹進行全面的心智表徵，並且不需要知道構建系統的神祕細節。微應用程序的自動化底層的質量，可能是爭論發佈所花費的時間與任何人都能觸發的一步到位的過程之間的差異。

CI 和自動化在微應用程序中必不可少，能夠確保測試和部署的快速進行以及模塊的無縫集成。

3 挑戰與權衡

像任何架構模式一樣，微應用的方法也有取有舍。微服務在很大程度上影響了微應用的架構，但這兩者之間有一個關鍵的區別。微服務是單獨部署的，而構成微應用的模塊則是編譯成相同的二進制文件。這種技術約束限制了各個團隊在選擇如何構建其模塊時的自由。

以第三方庫爲例。在其模塊的孤立背景下，團隊可以自由選擇不同的實施策略。但是如果兩個團隊導入了兩個庫來解決同一個問題呢？面向用戶的應用程序將會有額外的 “重量”，使得它的下載和更新的成本很高。相反，團隊將需要協調並達成可在整個應用程序中採用的最小可行的第三方庫列表。

在軟件開發中，團隊之間的有效溝通和協作是普遍存在的挑戰，但是微應用對孤立組件的強調加劇了這一挑戰。在確保最終產品的一致性的同時，給予團隊在其模塊內的操作自由是一種很難達到的平衡，工程領導層必須在幫助實現這一平衡方面扮演重要角色。召開定期內部會議以及跨模塊輪換開發者可以幫助打破知識孤島，確保開發者熟悉代碼庫的每一部分，並促進團隊間採用最佳編碼實踐。

單純的模塊化並不一定能帶來更快的開發速度。爲模塊劃分適當的界限是定義微應用架構的一個關鍵，但是也很有挑戰性。高級模塊的界限應該與你的組織結構相一致。舉例來說，電子商務公司可能有專門的庫存和支付部門，其應用模塊應該根據這些業務特性進行區分。另外，由業務需求驅動的更改需要更新到多個模塊，而孤立的開發流程可能會開始崩潰。

4 微應用架構之路

採用微應用架構需要時間，需要大量的學習和實驗。在你最初的幾次模塊提取過程中，要注意你的系統組件之間的界限、一個組件的隔離和遷移要求，代碼庫應該如何組織，以及你的工具需要如何改進以支持應用程序的構建、測試和部署，因爲應用程序已經變得完全模塊化。

在應用程序中已被隔離或由多個特性共享的部分可以成爲你第一個模塊提取的理想選擇。這幾個模塊只需對代碼做一些簡單的更改，讓你的團隊專注於提取過程本身並加以學習。例子包括基礎組件，如 API 客戶端；無處不在的用戶界面元素，例如具有自定義風格的按鈕；或沒有上游依賴關係的低級特性集羣，例如標準庫擴展。

一旦你提取出三到五個模塊，就把你所學到的轉化爲創建新模塊的明確標準。這些標準應該規定一個模塊的代碼庫應該如何組織，它應該如何集成到面向用戶的應用程序中，以及它的 CI 設置。自動化應該使任何人都能生成構建新模塊所需的 “腳手架”。這種在學習、文檔和工具方面的早期投資將爲剩餘的遷移工作奠定堅實的基礎。

微應用架構仍處於起步階段，團隊有很多空間來迭代並創新這些方法。我期待有更多的開發者來實驗它的實施細節，進一步拓展它的界限，並分享他們的學習成果。我希望這個關於架構的可能性、特點和挑戰的討論能夠成爲一個有用的起點。

作者介紹：

Gio Lodi，熱衷於測試、自動化和生產力的愛好者，自稱是一個極客。他是 Automattic 的遠程移動基礎設施工程師，並且是 Swift 測試驅動開發的作者。

原文鏈接：

https://increment.com/mobile/microapps-architecture/

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/qfitz0LOnzcOZpqWwUTmng