作者| 阿里文娛技術(shù)專家 嘉若
責(zé)編 | 屠敏
封圖 | CSDN 下載自東方 IC
背景
作為開發(fā)者，在面對(duì)需求變更期間，我們通常的狀態(tài)是開發(fā)-自測(cè)-聯(lián)調(diào)，需要頻繁改動(dòng)代碼，即使修改少量代碼，也要重啟容器來檢查執(zhí)行效果。等待時(shí)間少則3-5分鐘，多則10分鐘以上，嚴(yán)重加長(zhǎng)了非開發(fā)時(shí)間。
有沒有更好的方式來解決這一問題？一種方案是寫出沒bug的代碼，這顯然很難，因?yàn)楹芏郻ug并非是技術(shù)型的，更多的是業(yè)務(wù)型；另一方案就是采用動(dòng)態(tài)語言，比如node.js,erlang，但這也就意味著技術(shù)選型的單一，以及放棄其他語言的生態(tài)。
那么，作為以JAVA語言為主的開發(fā)者，尋找一種可動(dòng)態(tài)部署的方案，就是非常靠譜的是可行方案。
Java動(dòng)態(tài)加載
ClassLoader
說到動(dòng)態(tài)部署，jvm的類加載機(jī)制是一個(gè)繞不過去的問題。我們都知道jvm采用雙親委派模式，Java 類是通過 Java 虛擬機(jī)加載的，某個(gè)類的 class 文件在被 classloader 加載后，會(huì)生成對(duì)應(yīng)的 Class 對(duì)象，之后就可以創(chuàng)建該類的實(shí)例。
基于雙親委派的模式既能保證jvm的安全性，也能基于此更高效的執(zhí)行class轉(zhuǎn)換的字節(jié)碼指令，加快執(zhí)行速度。
默認(rèn)的虛擬機(jī)行為只會(huì)在啟動(dòng)時(shí)加載類，類被加載后就不會(huì)被替換和更新，如果要實(shí)現(xiàn)動(dòng)態(tài)加載，需要改變classLoader的加載行為，令jvm監(jiān)聽到class文件的更新，重新加載class文件，但同時(shí)如此也會(huì)對(duì)jvm的安全留下大坑，如此需要十分謹(jǐn)慎。
HotSwap
在jdk1.4期間，jvm就引入了hotswap，允許調(diào)試者使用同一個(gè)類標(biāo)識(shí)來更新類的字節(jié)碼，避免了類的字節(jié)碼被修改就重載容器。但這個(gè)弊端是僅限于修改方法體的修改——也就是說除了方法體，不能添加方法域，也不能修改其他任何代碼。
目前商業(yè)軟件JRebel也做到在極少限制的情況，做到動(dòng)態(tài)更新類的變動(dòng)，但是這種方案商業(yè)應(yīng)用收費(fèi)，兼容性方面有待考驗(yàn)。
阿里開發(fā)的hotCode，也可以做到熱部署，采用的是遵守hotswap規(guī)則，同時(shí)采用代理的方式支持類字節(jié)碼的改變，目前已經(jīng)支持到不限于方法體的改動(dòng)，可以增加以及修改方法，解決了類級(jí)別的頻繁修改部署問題，但針對(duì)應(yīng)用級(jí)別（變化數(shù)量多）的還是需要重啟容器來解決。
多ClassLoader
基于應(yīng)用級(jí)別的動(dòng)態(tài)加載，我們可以理解為整個(gè)應(yīng)用的類改動(dòng)比較大 ，采用雙親委派模式，我們就需要重新啟動(dòng)整個(gè)應(yīng)用來解決了。
但Tomcat給我們了不同的解決方案，tomcat也是支持動(dòng)態(tài)部署的，tomcat把classLoader重新設(shè)計(jì)了，也是沿用雙親委派的模式之上，新擴(kuò)展了自己的classLoader，借此來管理和分離不同App的加載。
tomcat啟動(dòng)的時(shí)候會(huì)有啟動(dòng)一個(gè)線程檢查加載的類是否發(fā)生變化（具體參考Lifecycle的實(shí)現(xiàn)）,如果發(fā)生了變化就會(huì)把應(yīng)用的啟動(dòng)的線程停止掉清理，同時(shí)把該應(yīng)用的WebAPPClassLoader廢棄,再創(chuàng)建一個(gè)新的WebAPPClassLoader加載APP。
多classLoader的優(yōu)點(diǎn):
1)同一進(jìn)程可以加載不同的APP，即便有相同的className；
2)不同APP可以共享類庫，容器提前加載，無需多次加載；
3)APP 類隔離，減少?zèng)_突，同時(shí)單個(gè)APP的重加載不影響其他APP(但無法內(nèi)存和cpu隔離)。
微應(yīng)用平臺(tái)的Class動(dòng)態(tài)加載
YMAP（優(yōu)酷微應(yīng)用平臺(tái)），借鑒serverLess思想，支持應(yīng)用秒級(jí)部署，快速擴(kuò)縮容，支撐業(yè)務(wù)快速靈活變更，讓開發(fā)者只專注于業(yè)務(wù)。在熱部署方面，我們對(duì)比了多種方案。
方案對(duì)比
|
方案 |
優(yōu)點(diǎn) |
缺點(diǎn) |
|
熱部署 |
快速 |
局部更新 |
|
多classsLoader |
基于classLoader業(yè)務(wù)隔離 |
實(shí)現(xiàn)成本高 |
因?yàn)閅MAP要做一個(gè)平臺(tái)化的方案，所以不能只限于熱部署，還要考慮到應(yīng)用方的二方庫擴(kuò)展以及多文件的變動(dòng)，要做到快速，簡(jiǎn)單，易用，所以我們最終采用了多classLoader的方案。
class卸載
多classLoader的只是更好的解決了類隔離的問題，但要實(shí)現(xiàn)動(dòng)態(tài)部署的還需要結(jié)合jvm的class卸載的能力，那么怎樣才能卸載class？
JVM中的Class只有滿足以下三個(gè)條件，才能被GC回收，也就是該Class被卸載（unload）：
1) 該類所有的實(shí)例都已經(jīng)被GC。
2) 加載該類的ClassLoader實(shí)例已經(jīng)被GC。
3) 該類的java.lang.Class對(duì)象沒有在任何地方被引用。
如此,基于YMAP（優(yōu)酷微應(yīng)用平臺(tái)）ClassLoader的隔離，有新的應(yīng)用代碼部署的時(shí)候，采用新老classLoader的替換的方式，回收老APP的資源，就能做到不啟動(dòng)容器的情況下，做到應(yīng)用的重新部署。
YMAP（優(yōu)酷微應(yīng)用平臺(tái)） ClassLoader
以上就是YMAP的classLoader的架構(gòu)全貌，我們?cè)诙郼lassLoader基礎(chǔ)之上，增加一些更貼合業(yè)務(wù)的落地方案。
1) 原生支持spring的全能力，方便開發(fā)；
2) 中間件（DB，cache）以及基礎(chǔ)能力無需重復(fù)接入，一站支持，讓業(yè)務(wù)方只關(guān)心業(yè)務(wù)代碼；
3) 支持二方包自定義擴(kuò)展，增加業(yè)務(wù)開發(fā)靈活性；
4) 支持資源隔離（CPU和內(nèi)存隔離），支持混合部署，提升機(jī)器利用率；
5) 快速動(dòng)態(tài)部署，20s以內(nèi)。
資源隔離
Tomcat的多APP部署一直沒有沒有被推廣的原因之一，就是安全性太低了，多個(gè)APP之間會(huì)因?yàn)橘Y源劃分的問題被相互影響，那么如何解決資源隔離問題？
我們引入了集團(tuán)AliJdk的多租戶能力，復(fù)用的是linux的cgroup的能力，這個(gè)方案可以讓單臺(tái)機(jī)器上的部署的多個(gè)APP之間資源(內(nèi)存、CPU)相互隔離。
常見的資源隔離問題主要表現(xiàn)在多個(gè)應(yīng)用對(duì)資源的爭(zhēng)奪，比如APP1出現(xiàn)了死循環(huán)，導(dǎo)致耗費(fèi)了整個(gè)機(jī)器資源的cpu，其他應(yīng)用無法繼續(xù)獲得指令集的執(zhí)行時(shí)間。以及常見的內(nèi)存泄漏，也會(huì)導(dǎo)致其他應(yīng)用出現(xiàn)不可訪問的情況。
另外我們做過一個(gè)調(diào)查，發(fā)現(xiàn)多數(shù)的長(zhǎng)尾應(yīng)用在90%的時(shí)間，機(jī)器資源都是浪費(fèi)的，如果給這類的應(yīng)用采用硬件分離部署，會(huì)過多的浪費(fèi)主機(jī)資源，不如采用多租戶的方式，單容器部署多個(gè)應(yīng)用，可以大幅提升資源利用率。
ymap引入了多租戶能力，通過JVM的虛擬化/資源隔離，以支持容器的多租戶，讓多個(gè)應(yīng)用可以同時(shí)部署在同一個(gè)容器而互相不受影響，從而可以更大程度的提高資源利用率，降低單應(yīng)用的部署成本。
多租戶能力的引入，解決了以下痛點(diǎn):
1) 資源隔離能力，包括IO資源和CPU資源隔離，以及mem隔離；
2) 高密度部署，降低應(yīng)用部署成本；
3) 減少進(jìn)程間溝通（序列化開銷），打通共享能力。
快速部署
YmapClassLoader 幫助我們解決了技術(shù)上動(dòng)態(tài)加載能力，同時(shí)我們也配套了相應(yīng)的APP打包編譯系統(tǒng)，結(jié)合aone的構(gòu)建和git代碼管理能力，方便開發(fā)者快速變更和部署，從開發(fā)提交代碼，到編譯部署，再到測(cè)試反饋，提供一站式服務(wù)，整個(gè)過程控制在30s以內(nèi)，方便開發(fā)者快速驗(yàn)證，無需耗費(fèi)過多的時(shí)間再部署發(fā)布上。
優(yōu)酷微應(yīng)用平臺(tái)的生態(tài)
YMAP（優(yōu)酷微應(yīng)用平臺(tái)）的設(shè)計(jì)初心是希望實(shí)現(xiàn)類serverless的微服務(wù)平臺(tái)，讓開發(fā)者只關(guān)心專注于業(yè)務(wù)邏輯：
在設(shè)計(jì)上，基于低成本、安全、高效為關(guān)鍵目標(biāo)，為研發(fā)賦能；
在開發(fā)上，支持一站式發(fā)布體系，從開發(fā)，測(cè)試到發(fā)布，全部可視化支持；
在容器上，動(dòng)態(tài)部署能力，多租戶隔離能力，以及基礎(chǔ)服務(wù)擴(kuò)展能力，提升應(yīng)用部署效率，以及資源利用率；
在運(yùn)維上，幫應(yīng)用實(shí)現(xiàn)智能化運(yùn)維工作，應(yīng)用自動(dòng)接入監(jiān)控報(bào)警，一鍵快速擴(kuò)縮容，應(yīng)用運(yùn)維大盤以及微服務(wù)日志自動(dòng)云端化可視化等，提升應(yīng)用的運(yùn)維效率。
微應(yīng)用平臺(tái)服務(wù)架構(gòu)
微應(yīng)用平臺(tái)業(yè)務(wù)效果
YMAP（優(yōu)酷微應(yīng)用平臺(tái)）基于serverless的思想，讓應(yīng)用服務(wù)化，提供最小邏輯單元，讓業(yè)務(wù)快速開發(fā)落地，同時(shí)也兼顧資源效率的提升，采用1：N的部署方式，進(jìn)可能的提升主機(jī)利用率。從開發(fā)賦能到運(yùn)維賦能，為業(yè)務(wù)方帶來更低的成本，更靈活的應(yīng)對(duì)方式。
