双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上构建新的开发模式，开发同学可以以接近独立应用的自由度去开发自己的业务逻辑，随时接自己需要的二方服务，随时变更自己的业务逻辑，不用关心代码跑在哪台机器，不用担心流量上涨需要扩容，不需要自己去接监控。后面我们会逐步改进，做得更完善
