??雙11的時候TPP引入了ajdk多租戶，對場景的cpu進行隔離，參考文章 《TPP穩定性之場景隔離和多租戶》。文章中對tpp提供給算法方案的二方服務客戶端進行改造，這些共享的二方服務注入root租戶的threadfactory，將共享服務與方案進行隔離，共享服務運行在root租戶中。 這樣算法方案里不會有線程，這樣不用擔心資源泄漏，因為tpp方案是熱部署的，新的方案instance構建并預熱，然后替換舊的方案instance，舊的方案classloader沒有被引用，系統會自動回收。

??隨著場景的增多，除了算法團隊，業務工程團隊也開始接入，他們都有自己業務相關的二方服務或二方包的需求，tpp維護幾千個場景和幾百個二方服務是有點力不從心了。任何一個場景提出的二方服務接入或著二方服務jar包升級都需要tpp走發布流程發布glaucus容器，業務迭代速度明顯要快于容器的更新速度，這種開發體驗是很差的。因此tpp要開放二方服務的開發和接入能力，讓場景owner自助完成，這樣場景onwer就可以像開發aone獨立應用一樣去迭代，只是不用關心機器資源，接入層，服務provider等。在tpp容器上實現這種開發模式就需要解決這些問題：
??1.私有的二方服務的熱部署，并且與方案有相同的生命周期：為什么不新起容器呢，還是上篇文章講的，tpp方案本身是熱部署的，一般機器運行最多幾百個場景，本來一個docker就能滿足要變成幾百個docker肯定是很浪費資源的。
??2.二方服務有自由的行為，可以開啟線程，熱部署就要能夠清理線程：否則老方案的資源無法卸載，多發布幾次方案和二方服務就會出現oom。

??我們的方案是將原來的一層租戶架構改成兩層租戶架構。回顧下原來的一層租戶架構：

??這里每個場景是一個租戶，它們有自己有界的線程池，設置了cpu shares和cpu quota，mem limit，場景下的所有方案都受所屬場景租戶限制。ajdk的租戶容器可以結束租戶創建的所有線程，但是熱部署的最小粒度是方案，因此不能直接destroy場景租戶，需要把單層租戶結構改成兩層租戶結構，即嵌套cgroup，如下圖所示：

??第一層還是場景租戶，用來控制場景的總cpu和mem。在場景租戶下為每個方案創建一個方案子租戶，目前不限制cpu和mem，因為對于cgroup來說子控制組總資源還是受父控制組的限制，還是匹配原來的場景資源隔離需求。方案租戶用來清理方案的資源，方案租戶容器生命周期和方案instance同步，方案下線/替換時，系統創建新的方案租戶，切流到新方案租戶，老方案租戶destroy，ajdk會結束老方案的線程，老方案沒有被引用會自動回收。容器新的classloader體系如下圖所示：

??私有插件和方案instance由同一個方案classloader加載，這里不會export，可以放心清理方案資源。對于廣泛使用的插件可以升級為系統共享插件，由glaucus classloader加載，export給方案，避免大家都加載一份插件浪費metaspace。

??有了多租戶的資源隔離和資源清理，我們將在tpp上構建新的開發模式，開發同學可以以接近獨立應用的自由度去開發自己的業務邏輯，隨時接自己需要的二方服務，隨時變更自己的業務邏輯，不用關心代碼跑在哪臺機器，不用擔心流量上漲需要擴容，不需要自己去接監控。后面我們會逐步改進，做得更完善

??參考文章：
??《TPP穩定性之場景隔離和多租戶》
??《JVM虛擬化 重新定義Java容器熱部署的資源管理機制》

總結

以上是生活随笔為你收集整理的TPP多租户隔离之资源清理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。