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