架構在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 架構的核心設計思想，主要遵循架構設計的「合適原則」。

 

組件化 & 容器化

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，迴歸使用原生技術。