宗心：淘寶無線事業(yè)部資深開發(fā)工程師，手機淘寶iOS架構組開發(fā)工程師，2012年底參與開發(fā)手機淘寶iOS3.0版本，經(jīng)歷大小幾十個版本的變遷，針對手機淘寶總體設計架構，hybrid框架解決方案，插件化解決方案以及手機淘寶核心業(yè)務組件均有參與和貢獻。（阿里巴巴無線事業(yè)部：負責手機淘寶并為阿里巴巴各條無線產品線提供基礎技術和設施）。
2014年手機淘寶經(jīng)歷了自誕生以來最大規(guī)模的一次重構。經(jīng)歷了去年業(yè)務的爆炸性增長，以及性能穩(wěn)定性等多方面挑戰(zhàn)后，手機淘寶在開發(fā)模式，客戶端架構上面都必須做到輕量，透明，延展，敏捷。本內容會重點介紹手機淘寶iOS基礎架構的第三代架構如何演進落地，實現(xiàn)多條業(yè)務線間獨立并行、研發(fā)效率提升的目標，以及如何應對未來可能變化。以下是關于手機淘寶客戶端架構探索實踐的精彩內容：
如圖所示，手機淘寶從1.0用單工程編寫開始，東西非常簡陋；到2.0為索引許多三方庫的龐大的單工程；再到3.0打破了單工程開發(fā)模式實現(xiàn)業(yè)務復用，包括承載充值，聚劃算，航旅等業(yè)務，由于業(yè)務越來越多，我們想到了插件化的方案，就是制定一套業(yè)務的規(guī)則和標準，讓這些插件按照我們的標準，我們提供的庫進行開發(fā)。
我們遇到了產品和技術上的挑戰(zhàn)和開發(fā)的痛點，協(xié)同方式上的迭代依賴和分支管理困難，合并依賴關系過于復雜！調試自測效率低——模塊依賴下的不穩(wěn)定因素，業(yè)務多，回歸成本大，測試資源嚴重不足！其他模塊引起的不穩(wěn)定性因素。發(fā)布的靈活性不足——版本發(fā)布無法快速響應，線上已發(fā)布版本穩(wěn)定性，灰度以及線上版本crash難以修復！由于很多APP集成到客戶端，各個業(yè)務的對接有一定的難度，自己的業(yè)務開發(fā)完全不夠支持這些功能，十余個團隊的代碼整合也不易，業(yè)務持續(xù)增長的量變將會導致質變。
2014年是手機淘寶自誕生以來最大規(guī)模的底層重構，改變了開發(fā)方式、工程結構、結構模型、打包方式。我們將圍繞開發(fā)效率和性能穩(wěn)定性等一系列問題探索新的路線，主要有：
工程拆分——支持多團隊并行開發(fā)
多個業(yè)務團隊更改一個或多個文件，交叉管理時，底層的東西不穩(wěn)定就沒有辦法進行上層開發(fā)，所以首先進行業(yè)務解耦；其次要進行獨立調試；最后修改配置完成集成。拆分的結果如圖所示，實踐證明，工程拆分以后，整體業(yè)務的盆跑速度有了明顯提升。
工程拆分分為三個階段：
- 開發(fā)階段：提供穩(wěn)定的開發(fā)環(huán)境（底層庫，接口），各個業(yè)務方獨立開發(fā)；
- 測試階段：單獨業(yè)務獨立打包，針對該業(yè)務的測試回歸；
- 集成階段：修改podfile進行集成測試，針對整體流程做回歸。
架構重構——重新梳理容器和總線規(guī)則。
架構重構需要解決幾個問題：迭代開發(fā)，并行開發(fā)能力差；
耦合嚴重，核心功能（URL導航）復雜；試錯成本過高，增加減少業(yè)務帶來的成本；快速迭代下的穩(wěn)定性問題。架構重構的指導思想如圖所示，我們制定規(guī)范，讓各個業(yè)務方自己運行，依照規(guī)范直接集成進來或出去。核心的架構在容器層，初始化在容器層統(tǒng)一管理，總線是一個核心的解耦方案，通過圖2中三種方式進行解耦。容器之上下全部為bundles，每一個業(yè)務全部做成bundle以后，當耦合度解的很好的時候，任何的bundles都可以拼成一個APP。
用總線的方式解除耦合，制定標準。
URL總線（跨平臺統(tǒng)一URL尋址方式）：三平臺統(tǒng)一URL，自動降級，中心分發(fā)（支持hook）。
服務總線 ：根據(jù)服務接口提供穩(wěn)定服務。
消息總線 ：中心分發(fā)，按需加載。
總線也是為了分而治之的原則，各個業(yè)務方對其他業(yè)務方都是透明的，減少了以前全在一起的中心總線的復雜度問題。只需要遵守規(guī)則，不關心底層/其他業(yè)務實現(xiàn)。下圖是一個總線圖，
減少新業(yè)務接入/移除成本：
標準化：統(tǒng)一的通信調用標準，bundle間互通的基礎；無法回避的瘦身問題。
靈活性：Bundle自由組裝（淘寶生活，碼上淘），中間件基礎庫自由引入。
下圖為一個bundlapp,將手機淘寶等的部分bundles拿出來作一個配置 ，將業(yè)務bundles，底層bundles作一個重組，組出一個app手機窗口，目的是做一個bundle的復用。
及時響應線上問題如下所示
『Move fast and break things』
via Hot Patch
- 線上嚴重問題快速修復（小時級的響應時間）
AOP編碼形式 - Before/After/Replace 某個方法
- 編寫容易，發(fā)布規(guī)范
配套工具——使用有力工具增加開發(fā)效率。
工程拆分遇到的問題：頻繁的更換spec；源碼引入造成的pod update緩慢等原因；開發(fā)階段集成階段等問題。
工具解決：摩天輪自動打包平臺（自動生成spec，framework引入）；開發(fā)-集成-灰度，多階段管理。
其他工具解決的問題：核心鏈路性能監(jiān)控平臺；Crash分析平臺。
6月初上線以來，重構結果為：集成 Bundle：30+；改造為服務：10+（登錄、緩存、搜索組件）；Hot Patch 修復線上嚴重故障 10+ 起；Patch 最大6KB，大部分不到1KB（iOS）。最大的陣痛是底層依賴遷移引起的編譯失敗，主要是由于底層庫的pod依賴規(guī)則不同步造成問題。
關于重構之后的未來探討如圖所示
PPT下載地址：http://club.alibabatech.org/resource_detail.htm?topicId=153
