架構師是如何煉成的?以天貓APP架構&開發模式升級工程為例
在集團大數據、算法的背景下,貓客(天貓客戶端)首頁率先從2015年的坑位運營走向2016年的全麵個性化,貓客首頁個性化業務點多達50多處,個性化場景大部分通過通過Aladdin(天貓推薦)接入TPP(集團個性化平台)來實現的。走向個性化的同時也接入大量的第三方服務,例如:阿裏媽媽鑽展、新人禮包等。
- 線上問題定位周期長:首頁客戶端同學+首頁服務端同學+阿拉丁+算法同學。定位參與同學過多,定位問下效率低下
- 個性化業務支持效率低:首頁客戶端同學+首頁服務端同學+阿拉丁+算法同學。參與同學過多、鏈路過長,對業務的快速支撐有影響
- 在走向個性化的同時也接入大量的第三方服務,例如流量寶、新人禮包、超品等,每次接入第三方業務服務,首頁服務端都需要做開發發布,頻繁的發布導致首頁的穩定性變差。
- 從圖上看首頁服務端同學做大量的服務接入、字段轉換、埋點拚接等工作,對服務端同學成長並不利,價值不高
- 阿拉丁同學在這個鏈路主要做些TPP算法數據透傳的工作,對服務端開發的阿拉丁同學價值同樣不高
- 如果通過“服務端動態化技術方案”,把整個鏈路價值低環節去掉,讓端上同學直接對接業務&算法,這樣讓端上同學直接了解業務,同時有問題端上同學可以快速定位,同時對業務支持的鏈路也大大縮減。
- 把價值低的首頁服務端同學解放出來,去建設價值高“服務端動態化”平台。
為了承接2017新的業務架構,貓客首頁研發的服務端動態化平台TAC,後麵我們主要介紹動態化平台TAC。
Tangram App Container
低成本開發與發布流程
低成本搭建與維護開發環境
高穩定性保障
結論:在目前高並發,低延時,追求極致用戶體驗的移動會聯網背景下,穩定性、性能對服務端來說至關重要,故容器化使用集團很多開發人員精通的java語言。對應目前貓客Tangram,Android開發人員可以完全勝任。
Java語言動態發布: 動態編譯、動態加載、熱部署
1. 動態編譯技術選型
結論:為了讓開發人員獲得的類編譯信息、方便問題定位,同時結合集團服務端早普及jdk1.6且目前很多應用已升級1.8,故使用了StandardJavaFileManager進行類的動態編譯。
1. // 1.創建需要動態編譯的代碼字符串
2. String nr = "\r\n"; //回車
3. String source = "package temp.com; " + nr +
4. " public class Hello{" + nr +
5. " public static void main (String[] args){" + nr +
6. " System.out.println(\"HelloWorld! 1\");" + nr +
7. " }" + nr +
8. " }";
9. // 2.將欲動態編譯的代碼寫入文件中 1.創建臨時目錄 2.寫入臨時文件目錄
10.File dir = new File(System.getProperty("user.dir") + "/temp"); //臨時目錄
11.// 如果 \temp 不存在 就創建
12.if (!dir.exists()) {
13. dir.mkdir();
14.}
15.FileWriter writer = new FileWriter(new File(dir,"Hello.java"));
16.writer.write(source);
17.writer.flush();
18.writer.close();
19.
20.// 3.取得當前係統的編譯器
21.JavaCompiler javaCompiler = ToolProvider.getSystemJavaCompiler();
22.// 4.獲取一個文件管理器
23.StandardJavaFileManager javaFileManager = javaCompiler.getStandardFileManager(null, null, null);
24.// 5.文件管理器根與文件連接起來
25.Iterable it = javaFileManager.getJavaFileObjects(new File(dir,"Hello.java"));
26.// 6.創建編譯任務
27.CompilationTask task = javaCompiler.getTask(null, javaFileManager, null, Arrays.asList("-d", "./temp"), null, it);
28.// 7.執行編譯
29.task.call();
30.javaFileManager.close();
結論:結合Tomcat的類加載結構進行,以及類加載雙親委派模型,采用了通過多個classloader來實現類的動態加載
3. 類熱部署技術選型
- Java的熱部署一直是個比較難解決,無論asm,cglilb也隻能實現方法體的熱部署,對於整個類文件的修改無法支撐
- 結合Jvm的垃圾回收機製,采用了重新定義classloader,老的classloader又JVM自動回收,來實現類的熱部署
- TAC包括兩部分:TAC控製台、TAC引擎
- TAC控製台:動態服務開發,測試,發布的流程,類的動態編譯在該部分的“預發布”階段。
- TAC引擎-協議層:主要是目前HSF支持的RMI和Hessian,通過HSF向外提供服務。
- TAC引擎-CORE: 主要負責動態服務的加載和執行工作,已經一下安全,監控等職責。類的動態加載、熱部署在該部分承載。
- TAC引擎-數據池:主要承擔數據服務接入
2. TAC控製台-開發階段
3.TAC控製台-預發布階段
預發布階段-類的動態編譯
4. TAC控製台-開發調試
5. TAC控製台-正式發布(將觸發TAC引擎-CORE做類的動態加載、熱部署)
6. TAC引擎-CORE(類的動態加載、熱部署)
目前TAC支持的業務,動態服務已達50+
- 微服務獨立部署
- 微服務相互調用
- TAC混合雲部署
- 引擎Core完全獨立
- 立體監控大盤
架構師的成長之路,永無止境。如果你對這套架構模式、解決方案,還有其他的想法和建議,也歡迎在文章底部留言,我們一起交流、學習。
本文出自阿裏技術公眾號,原文鏈接
最後更新:2017-07-27 10:02:43