架構只能用在後端嗎？談談架構在APP和前端里的應用和演進

作者 | 李運華

編輯 | 小智

不想當 CTO 的架構師不是好程序員，幾乎每個程序員內心都有一個架構師的夢想。前端工程師 + 程序員 + 系統管理員 + 對各種技術靈活搭配的能力 + 模式總結 = 架構師，架構師在一家公司、一個項目有多重要？我們做了一個數據——

上篇文章《程序員職業發展路徑圖：從菜鳥工程師到高級架構師》，縱向梳理了程序員到架構師的發展路徑，我們今天將橫向展開，聊聊架構理念和技術除了後端系統，在 APP 里的應用。

App 架構的演進

架構設計相關的理念、技術、實踐，比如存儲高可用、微服務、異地多活等，都是後端系統才會涉及。事實上確實也是如此，通常情況下我們講架構設計，主要聚焦在後端系統，但這並不意味著 App、前端就沒有架構設計了，專欄所講述的整套架構設計理念，雖然是來源於我的後端設計經驗，但一旦形成完善的技術理論後，同樣適應於 App 和前端。

架構設計理念，可以提煉為下面幾個關鍵點：

架構是系統的頂層結構。

架構設計的主要目的是為了解決軟體系統複雜度帶來的問題。

架構設計需要遵循三個主要原則：合適原則、簡單原則、演化原則。

架構設計首先要掌握業界已經成熟的各種架構模式，然後再進行優化、調整、創新。

Web App

最早的 App 有很多採用這種架構，大多數嘗試性的業務，一開始也是這樣的架構。Web App 架構又叫包殼架構，簡單來說就是在 Web 的業務上包裝一個 App 的殼，業務邏輯完全還是 Web 實現，App 殼完成安裝的功能，讓用戶看起來像是在使用 App，實際上和用瀏覽器訪問 PC 網站沒有太大差別。

為何早期的 App 或者嘗試新的業務採用這種架構比較多呢？簡單來說，就是當時業務面臨的複雜度決定的。我們以早期的 App 為例，大約在 2010 年前後，移動互聯網雖然發展很迅速，但受限於用戶的設備、移動網路的速度等約束，PC 互聯網還是主流，移動互聯網還是一個新鮮事物，未來的發展前景和發展趨勢，其實當年大家也不一定能完全看得清楚。

例如淘寶也是在 2013 年才開始決定「All in 無線」的，在這樣的業務背景下，當時的業務重心還是在 PC 互聯網上，移動互聯網更多是嘗試性的。既然是嘗試，那就要求快速和低成本，雖然當時的 Android 和 iOS 已經都有了開發 App 的功能，但原生的開發成本太高，因此自然而然，Web App 這種包殼架構就被大家作為首選嘗試架構了，其主要解決「快速開發」和「低成本」兩個複雜度問題，架構設計遵循「合適原則」和「簡單原則」。

原生 App

Web App 雖然解決了「快速開發」和「低成本」兩個複雜度問題，但隨著業務的發展，Web App 的劣勢逐漸成為了主要的複雜度問題，主要體現在：

移動設備的發展速度遠遠超過 Web 技術的發展速度，因此 Web App 的體驗相比原生 App 的體驗，差距越來越明顯。

移動互聯網飛速發展，趨勢越來越明顯，App 承載的業務邏輯也越來越複雜，進一步加劇了 Web App 的體驗問題。

移動設備在用戶體驗方面有很多優化和改進，而 Web App 無法利用這些技術優勢，只有原生 App 才能夠利用這些技術優勢。

因此，隨著業務發展和技術演進，移動開發的複雜度從「快速開發」和「低成本」轉向了「用戶體驗」，而要保證用戶體驗，採用原生 App 的架構是最合適的，這裡的架構設計遵循「演化原則」。

原生 App 解決了用戶體驗問題，沒記錯的話大約在 2013 年前後開始快速發展，那個時候的 Android 工程師和 iOS 工程師就像現在的人工智慧工程師一樣非常搶手，很多同學也是那時候從後端轉行到 App 開發的。

Hybrid App

原生 App 很好的解決了用戶體驗問題，但業務和技術也在發展，移動互聯網此時已經成為明確的大趨勢，團隊需要考慮的不是要不要轉移動互聯網的問題，而是要考慮如何在移動互聯網更具競爭力的問題，因此各種基於移動互聯網特點的功能和體驗方式不斷被創造出來，大家拼的競爭方式就是看誰更快抓住用戶需求和痛點。

因此，移動開發的複雜度又回到了「快速開發」，這時就發現了原生 App 開發的痛點：由於 Android、iOS、Windows Phone（你沒看錯，當年確實是這三個主流平台）的原生開發完全不能兼容，同樣的功能需要三個平台重複開發，每個平台還有一些差異，因此自然快不起來。

為了解決「快速開發」的複雜度問題，大家自然又想到了 Web 的方式，但 Web 的體驗還是遠遠不如原生，怎麼解決這個問題呢？其實沒有辦法完美解決，但可以根據不同的業務要求選取不同的方案，例如對體驗要求高的業務採用原生 App 實現，對體驗要求不高的可以採用 Web 的方式實現，這就是 Hybrid App 架構的核心設計思想，主要遵循架構設計的「合適原則」。

文章出自《從0開始學架構》，「碼」上訂閱

組件化 & 容器化

Hybrid App 能夠較好的平衡「用戶體驗」和「快速開發」兩個複雜度問題（注意是「平衡」，不是「同時解決」），但對於一些超級 App 來說，隨著業務規模越來越大、業務越來越複雜，雖然在用戶看來可能是一個 App，但事實上承載了幾十上百個業務。

以手機淘寶為例，阿里確認「All in 無線」戰略後，手機淘寶定位為阿里集團移動端的「航空母艦」，上面承載了非常多的子業務，下圖是淘寶的首頁第一屏，相關的子業務初步估計就有 10 個以上。

再以微信為例，作為騰訊在移動互聯網的「航空母艦」，其業務也是非常的多，如下圖，「發現」tab 頁就有 7 個子業務。

這麼多業務集中在一個 App 上，每個業務又在不斷地擴展，後續又可能會擴展新的業務，並且每個業務就是一個獨立的團隊負責開發，因此整個 App 的可擴展性引入了新的複雜度問題。

可擴展的基本思想就是「拆」，但是這個思想應用到 App 和後端系統時，具體的做法就明顯不同了。簡單來說，App 和後端系統存在一個本質的區別，App 是面向用戶的，後端系統是不面向用戶的，因此 App 再怎麼拆，對用戶還是只能呈現同一個 App，不可能將一個 App 拆分為幾十個獨立 App；而後端系統就不一樣了，採用微服務架構後，後端系統可以拆分為幾百上千個子服務都沒有問題。同時，App 的業務再怎麼拆分，技術棧是一樣的，不然沒法集成在一個 App 裡面；而後端就不同了，不同的微服務可以用不同的技術棧開發。

在這種業務背景下，組件化和容器化架構應運而生，其基本思想都是將超級 App 拆分為眾多組件，這些組件遵循預先制定好的規範，獨立開發、獨立測試、獨立上線。如果某個組件依賴其他組件，組件之間通過消息系統進行通信，通過這種方式來實現組件隔離，從而避免各個團隊之間的互相依賴和影響，以提升團隊開發效率和整個系統的可擴展性。組件化和容器化的架構出現遵循架構設計的「演化原則」，只有當業務複雜度發展到一定規模後才適應，因此我們會看到大廠應用這個架構的比較多，而中小公司的 App，業務沒那麼複雜，其實並不一定需要採用組件化和容器化架構。

對於組件化和容器化並沒有非常嚴格的定義，我理解兩者在規範、拆分、團隊協作方面都是一樣的，區別在於發布方式，組件化採用的是靜態發布，即所有的組件各自獨自開發測試，然後跟隨 App 的某個版本統一上線；容器化採用的是動態發布，即容器可以動態載入組件，組件準備好了直接發布，容器會動態更新組件，無需等待某個版本才能上線。

跨平台 App

前面我介紹的各種 App 架構，除了 Web App 外，其他都面臨著同一個問題：跨平台需要重複開發。同一個功能和業務，Android 開發一遍，iOS 也要開發一遍，這裡其實存在人力投入的問題，違背了架構設計中的「簡單原則」。站在企業的角度來講，當然希望能夠減少人力投入成本（雖然我站在程序員的角度來講是不希望程序員被減少的），因此最近幾年各種跨平台方案不斷湧現，比較知名的有 Facebook 的 React Native、阿里的 Weex、Google 的 Flutter。雖然也有很多公司在嘗試使用，但目前這幾個方案都不算很成熟，且在用戶體驗方面與原生 App 還是有一定差距，例如 Airbnb 就宣布放棄使用 React Native，回歸使用原生技術。

本文出自極客時間《從 0 開始學架構》專欄，目前專欄已有 26000+ 人訂閱。專欄中，資深技術專家李運華從架構基礎、三大架構模式和實戰的角度分享他一整套的架構設計方法論。目前已經全部更新完，相信你學習後不僅能快速理解陌生的架構設計，更能對架構設計遊刃有餘。

現在訂閱，立享以下福利：

福利一：訂閱專欄，一次性獲得專欄全集，附贈《架構師成長技能圖譜》一份

福利二：老用戶每邀請一位好友購買，可以獲得 24 元現金返現，上不封頂，立即提現。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！