TPP多租户隔离之资源清理-阿里云开发者社区

开发者社区> 搜索与推荐技术> 正文
登录阅读全文

TPP多租户隔离之资源清理

简介: 利用ajdk实现jvm虚拟化,实现容器业务方案的热部署和资源隔离

  双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。

  我们的方案是将原来的一层租户架构改成两层租户架构。回顾下原来的一层租户架构:
多租户隔离.png
  这里每个场景是一个租户,它们有自己有界的线程池,设置了cpu shares和cpu quota,mem limit,场景下的所有方案都受所属场景租户限制。ajdk的租户容器可以结束租户创建的所有线程,但是热部署的最小粒度是方案,因此不能直接destroy场景租户,需要把单层租户结构改成两层租户结构,即嵌套cgroup,如下图所示:

场景方案隔离.png
  第一层还是场景租户,用来控制场景的总cpu和mem。在场景租户下为每个方案创建一个方案子租户,目前不限制cpu和mem,因为对于cgroup来说子控制组总资源还是受父控制组的限制,还是匹配原来的场景资源隔离需求。方案租户用来清理方案的资源,方案租户容器生命周期和方案instance同步,方案下线/替换时,系统创建新的方案租户,切流到新方案租户,老方案租户destroy,ajdk会结束老方案的线程,老方案没有被引用会自动回收。容器新的classloader体系如下图所示:

tpp类加载体系.png
  私有插件和方案instance由同一个方案classloader加载,这里不会export,可以放心清理方案资源。对于广泛使用的插件可以升级为系统共享插件,由glaucus classloader加载,export给方案,避免大家都加载一份插件浪费metaspace。

  有了多租户的资源隔离和资源清理,我们将在tpp上构建新的开发模式,开发同学可以以接近独立应用的自由度去开发自己的业务逻辑,随时接自己需要的二方服务,随时变更自己的业务逻辑,不用关心代码跑在哪台机器,不用担心流量上涨需要扩容,不需要自己去接监控。后面我们会逐步改进,做得更完善

  参考文章:
  《TPP稳定性之场景隔离和多租户》
  《JVM虚拟化 重新定义Java容器热部署的资源管理机制》

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:

AI Online Serving,阿里巴巴集团搜索与推荐,算法与工程技术的大本营,大数据深度学习时代的创新主场。

官方博客
最新文章
相关文章
友情链接