在集團大資料、算法的背景下，貓客（天貓用戶端）首頁率先從2015年的坑位營運走向2016年的全面個性化，貓客首頁個性化業務點多達50多處，個性化場景大部分通過通過aladdin（天貓推薦）接入tpp（集團個性化平台）來實作的。走向個性化的同時也接入大量的第三方服務，例如：阿裡媽媽鑽展、新人禮包等。
2016老版本貓客首頁問題梳理
線上問題定位周期長：首頁用戶端同學+首頁服務端同學+阿拉丁+算法同學。定位參與同學過多，定位問下效率低下
個性化業務支援效率低：首頁用戶端同學+首頁服務端同學+阿拉丁+算法同學。參與同學過多、鍊路過長，對業務的快速支撐有影響
在走向個性化的同時也接入大量的第三方服務，例如流量寶、新人禮包、超品等，每次接入第三方業務服務，首頁服務端都需要做開發釋出，頻繁的釋出導緻首頁的穩定性變差。
2016老版本貓客首頁問題分析
從圖上看首頁服務端同學做大量的服務接入、字段轉換、埋點拼接等工作，對服務端同學成長并不利，價值不高
阿拉丁同學在這個鍊路主要做些tpp算法資料透傳的工作，對服務端開發的阿拉丁同學價值同樣不高
如果通過“服務端動态化技術方案”，把整個鍊路價值低環節去掉，讓端上同學直接對接業務&算法，這樣讓端上同學直接了解業務，同時有問題端上同學可以快速定位，同時對業務支援的鍊路也大大縮減。
把價值低的首頁服務端同學解放出來，去建設價值高“服務端動态化”平台。
2017新版貓客首頁業務架構
為了承接2017新的業務架構，貓客首頁研發的服務端動态化平台tac，後面我們主要介紹動态化平台tac。
tac
tangram app container
tac目标
低成本開發與釋出流程
低成本搭建與維護開發環境
高穩定性保障
動态化腳本語言選型
結論：在目前高并發，低延時，追求極緻使用者體驗的移動會聯網背景下，穩定性、性能對服務端來說至關重要，故容器化使用集團很多開發人員精通的java語言。對應目前貓客tangram，android開發人員可以完全勝任。
java語言動态釋出: 動态編譯、動态加載、熱部署
1. 動态編譯技術選型
結論：為了讓開發人員獲得的類編譯資訊、友善問題定位，同時結合集團服務端早普及jdk1.6且目前很多應用已更新1.8，故使用了standardjavafilemanager進行類的動态編譯。
2. 動态加載技術選型
結論：結合tomcat的類加載結構進行，以及類加載雙親委派模型，采用了通過多個classloader來實作類的動态加載
3. 類熱部署技術選型
java的熱部署一直是個比較難解決，無論asm,cglilb也隻能實作方法體的熱部署，對于整個類檔案的修改無法支撐
結合jvm的垃圾回收機制，采用了重新定義classloader，老的classloader又jvm自動回收，來實作類的熱部署
tac —架構1.0
tac包括兩部分：tac控制台、tac引擎
tac控制台：動态服務開發，測試，釋出的流程，類的動态編譯在該部分的“預釋出”階段。
tac引擎-協定層：主要是目前hsf支援的rmi和hessian，通過hsf向外提供服務。
tac引擎-core: 主要負責動态服務的加載和執行工作，已經一下安全，監控等職責。類的動态加載、熱部署在該部分承載。
tac引擎-資料池：主要承擔資料服務接入
tac流程和和相關流程節點的核心技術
1.tac控制台-申請階段
2. tac控制台-開發階段
3.tac控制台-預釋出階段
預釋出階段-類的動态編譯
4. tac控制台-開發調試
5. tac控制台-正式釋出（将觸發tac引擎-core做類的動态加載、熱部署）
6. tac引擎-core（類的動态加載、熱部署）
7. tac控制台-線上回歸
8. tac控制台-釋出結果
目前tac支援的業務，動态服務已達50+
目前tac已支撐支援天貓無線業務
貓客-首頁精選
貓客-品牌+
貓客-我的
貓客-全鍊路猜你喜歡
貓客-全鍊路商品資訊一緻性
貓客-商品說明書
tac 2.0 規劃
微服務獨立部署
微服務互相調用
tac混合雲部署
引擎core完全獨立
立體監控大盤
2017新首頁開發模式
2017新貓客首頁服務端技術架構圖-理想生活上天貓
架構師的成長之路，永無止境。如果你對這套架構模式、解決方案，還有其他的想法和建議，也歡迎在文章底部留言，我們一起交流、學習。