移動化浪潮下，談談多端優化以及延緩架構腐化

不知不覺移動的發展早已是驅動大量技術升級的主要力量，民眾已然享受到移動化時代給生活帶來的各種便利：購物、飲食、打車、轉賬等等，然而開發者卻面臨著移動端的諸多考驗：多分辨率適應、不同網絡環境的加載優化、Web和Native之爭、移動安全等等，并且加上移動技術的日新月異和快速更迭，大量開發者被新需求和新技術沖擊下找不著前進方向。

2016年12月2-3日， ArchSummit全球架構師峰會 將在北京舉行。本屆大會組委會策劃了“ 日新月異的移動架構 ”專題，并邀請了阿里巴巴資深專家肖恩老師擔任該專題出品人，我們借此機會采訪了肖恩老師，他為我們分享了目前對移動架構的趨勢見解和經驗教訓，希望可以為大家帶來啟發。

InfoQ：能否介紹智能生活與移動架構在技術要求上有哪些異同？您是如何兼顧這兩方面的知識的？

肖恩：手機上的App應該是現代智能生活解決方案的一個重要部分，App把手機變成了一個高級的遙控器。除了替代傳統遙控器的開關功能，App借助手機或者平板電腦的特性，在信息展示、設定和觸達方面有天然的優勢，確保了整體方案的用戶體驗。

在技術架構要求上，App的產品功能設定其實更純粹，作為端的一部分，配合云端和設備端來完成整個鏈路的閉環。大廠商智能設備App在架構需要額外考慮的是作為“航母”接入外部三方功能的一系列架構挑戰。譬如我們當時做的App，為了方便廠商或者獨立ISV進行自行開發和接入，以便于他們來參與部分的定制工作，因此我們必須提供一套完善的插件框架，結合Hybrid的展現技術，暴露出JScript的訪問控制API。整個App有點像小型的應用商店， 因此必須解決一整套的開發、測試、安全檢測、沙盒控制和功能上下架等功能 。這又是前端后端的一整套方案，只看App應用就顯得不夠完整了。

至于對技術知識的要求，如果有良好的接口設計和模型定義，那么云端、設備端和應用端的三端開發人員是可以不用知曉對方太多的底層細節知識的。當然有少部分人必須同時具備三端的經驗，否則設計整個系統的時候就有很大的問題。

就我個人而言，一直比較有運氣。在工作一開始就從事服務端開發，做了一些企業應用和框架中間件產品；07年以后第一次接觸iPhone應用開發，到最近幾年都有機會參與一些重要的App開發工作；而電子電路則是自己從初中開始的興趣愛好，多年來一直在學習提高，從原理上來看這些不同知識背后道理其實都是相通的。

InfoQ：從"iPhone OS"到"iOS10"的正式版發布，作為早期原生應用的開發者您有什么感慨？在這個過程中您遇過怎樣的驚喜和遺憾？

肖恩：作為早期的iOS原生應用開發者，還是有過一段傲嬌的時期的。早期沒有應用商店和開發文檔，都是靠一個修改過的class-dump工具和蘋果Cocoa桌面版的API文檔來進行摸索開發。有必要的話，還會去逆向iOS自帶的應用來了解API的調用方式。這導致了那時候App開發有相當的門檻，因此有一定的技術自豪感。

那時候早期的開發者都混一個叫做什么鋒的論壇，還有一個內部的QQ群。而且我還清楚的記得，那時候Holly發布說可以有一個原生鍵盤的中文輸入法放出來，很多人紛紛回帖說是騙子。

而自從iOS 2.0開始蘋果逐步開放SDK以后，這些技術門檻就逐步消除了，同時應用商店的審核對于第一批的“自由”開發者來說，存在不小的限制，因為很多私有API你看得到，但是不能使用了。因此興趣更多地轉移到App的產品設計上了。

InfoQ：能否為大家解釋“App會越做越小，但是功能和方向上會越來越超越App”這個趨勢？這對無線應用的技術提出了怎樣的要求？

肖恩：我對這個問題的理解，可能換一種說法更貼切：某些App逐步沉淀成為大而全的航母應用，而獨立開發者做的App因為這些平臺的存在而做得更加輕巧，功能更加單一。

這可能是超出了蘋果和谷歌的意料之外的一種現象。這也是為什么大廠商要推動自己的混合應用框架，挾諸多開發者以令OS的原因吧？我個人還是認為手機App的初心還是在原生應用，但是我們必須混合多種開發技能，畢竟需求和應用場景各不相同。

InfoQ：您認為近幾年移動架構設計思想有什么變化？在移動化浪潮中，客戶端和服務端的邊界在哪里，各自的架構設計應著重研究哪些方面？

肖恩：我能觀察到的就是前端技術的滲入，原來只能應用到瀏覽器上的技術，現在紛紛出現在原生應用的開發陣營。另外一個就是后端一些模式和概念（或其變形）滲入到應用前端開發過程中。 這種前端后端技術的互相滲透，一定程度上模糊了客戶端和后端的技術邊界 。

我們還可以看到一些原本出現在服務端的API調用編排及數據格式轉換等技術（參見淘寶的TQL及非死book的GraphQL），都紛紛出現在手機應用開發上。而移動化浪潮也是直接促進了通訊協議的升級，譬如千年不變的HTTP 1.1到2.0升級，這些在我看來都是很好的證據，說明前后端是互相交織促進、滾動發展的。

另外，隨著終端和網絡能力的提升，系統和中間件的成熟，移動架構設計走向了容器化、模塊化、動態化。總結一下近幾年客戶端、服務端表現出的幾個趨勢：

1. 基礎中間件走向成熟：網絡加速、IM、Push、圖片、數據統計、分享、社區、Crash分析、安全加固等云端結合的基礎服務提供方逐步集中到幾個有實力的社區或企業中；

2. App云端一體化：諸如FireBase、LeanCloud、AWS Mobile Hub的MBaaS架構極大地提升了端直接操縱云的能力，服務端和客戶端的角色也發生了調整，服務端專注于提供穩定、可靠的基礎服務以及基礎服務端組合編排的能力，客戶端更靈活的編排這些服務實現功能；

3. 動態化：除H5外，ReactNative和WeeX的出現也提供了另一種動態化方式，客戶端提供渲染引擎，服務端提供頁面下發、更新、個性化的能力；

4. 個性化(智能化)：客戶端采集更豐富的數據，服務端依托大數據和算法提供更加個性和智能的服務。

InfoQ：移動端網絡環境復雜（尤其在鄉村下），在高峰期高流量的壓力下還要保證流暢度，您認為在改善網絡通道上有哪些事情可以做？

肖恩：網絡通道的優化涉及了云、管、端。除滿足性能外還需考慮體驗、安全和容災的要求。從客戶端體驗視角出發，移動端網絡優化最有效的方式就是 減少網絡請求 ，例如客戶端本地緩存(圖片)、使用Push機制替換Pull獲取數據(收藏夾、購物車)都是經典且有效的方法。

對于必不可少的網絡請求我們希望每個請求都 盡可能快地響應 ，典型的網絡請求包括：DNS、TCP連接、安全通道建立、Request發送、Response接收，其中每個階段都有值得優化的空間：

1. 使用自建的HttpDNS服務替換運營商DNS服務，DNS異步化并把結果緩存在客戶端，IP直連服務端等方式，不僅可以把請求中DNS等待耗時降為0，而且可以做到更加智能地調度，實現IDC按用戶單元化部署、客戶端就近就快接入、容災快速切換；

2. 使用雙工、多路復用的TCP長連接通訊協議(如SPDY、HTTP2)，不需要每次請求都建立TCP連接的同時，也對Request、Response的頭和內容進行壓縮；

3. 服務端TCP協議棧參數調優，優化慢啟動和擁塞避免；

4. 安全通道選用內置證書和能夠0、1-RTT完成握手的算法(參考TLS 1.3)，保障安全的同時能夠極大地降低TLS握手時間；

5. 選用Protobuf等二進制協議減小傳輸數據大小，使用ETag和304減少不必要的Response傳輸。

基本上就這幾個方面了，我們得針對各自場景，有選擇性地進行調優。

InfoQ：不少企業兼顧開發iOS和Android應用，能否談談iOS和Android共同開發下有哪些降低各端開發成本的架構思路？

肖恩：設備碎片化頗令人頭疼，尤其是Android設備的碎片化。我能想到的主要方式還是通過iOS和Android端統一架構、統一UI、使用統一且成熟的基礎中間件，嘗試ReactNative、WeeX等混合跨端方案來降低適配難度。

底層基礎組件可以使用C/C++編寫，非核心業務內容使用H5編寫做到多端復用。同時在界面設計上盡可能避免不同設備的兼容問題；根據應用安裝的分布情況，對產品設備的支持程度進行取舍來解決這類問題。

InfoQ：面對移動開發迅速更新換代，相關技術也越來越復雜，您認為技術負責人怎樣才能做好移動客戶端架構和技術選型，在這個過程中如何做好通盤考慮以及取舍和平衡？

肖恩：如果是小型團隊，要快速地打造一個應用，我覺得怎么快怎么來就好。如果是中大型團隊，并且要維持一個穩定的產品，那么還是要選擇已經被證明的技術方案。如果團隊能力允許的話，要盡可能地對要使用的新技術有一個充分的評估和了解，免費的東西最貴，開源的框架技術拿到手上最好還是多看一眼再用。

就個人偏好而言，我偏保守地穩妥發展。舉例來說：我現在的主力筆記本還在用Yosemite，等大家切換到了Sierra以后，我會開始升級到El Capitan，另外一臺測試機則利用開發者賬號，第一時間升級最新的OS測試版本來體驗把玩。

InfoQ：有人提過規模變大才是架構腐化的根源，您認可這個看法嗎？能否結合服務治理談談有哪些措施和思想可以避免架構腐化？

肖恩：首先，我覺得這是個不容易直接得出結論的問題，且很容易引起爭論。其次，我認為 架構腐化是不可避免的，而規模變大可能會讓架構腐敗變得更快而已 。

在沒有服務治理概念的年代，依然可以找到設計良好的系統，而現在有了服務治理框架和工具，系統依然可能會腐化得很快。兩者的關系就好比人的壽命長短和鍛煉方式程度一樣，其實并沒有直接的聯系。

記得我最初幾年在做Dubbo時，參與過幾個項目的服務化改造。當時的工作是通過梳理一個巨無霸應用的功能和范圍邊界，確定出一些核心的領域模型概念，基于這些概念，劃分成子系統剝離出業務接口，然后利用Dubbo等RPC框架部署成獨立的服務集群。因此這個階段的服務治理，主要就是抽絲剝繭地分離大系統。

到了中后期，服務化被廣泛使用后，我們就遇到了接口泛濫、版本控制、循環依賴等各種新的問題。

到了全民無線的時期，對服務化的新要求則是針對移動應用領域如何進行優化和支持了。

后來我在帶領團隊做一些重要的移動App的時候，因為多變的需求沖擊，產品功能設計也不夠充分，加上團隊也比較稚嫩，所以那時候App的架構腐化得更快，到后來基本只能在原來代碼上面堆砌功能，因為推倒重來的代價太大，因此非常痛苦。

結合我在兩端開發不堪回首的經歷，我認為：借助工具框架的力量，妥善做好應用功能分析分解，確保服務之間（或者應用內部功能模塊之間）的模塊化隔離解耦，也許能延緩一下架構腐化的速度。另外，團隊的能力可能比這些方法論更重要。

 

 

來自：http://www.infoq.com/cn/news/2016/10/Multiterminal-optimization-delay