2019云计算开源产业大会丨张君：互联网金融保险场景下的云原生运维增效之道

我们也在云原生领域遇到了一些新的问题，比如很多次由于隔离不彻底的问题，一个节点的单个容器，磁盘空间用完了就会导致整个节点更换，除此之外内核其实是共享的，包括建成数、文件系统、注册用户和Linux操作系统的资源，这些都是无法进行彻底隔离的，有些资源可以通过这种手段隔离，但是不可否认，由于这些资源隔离的不彻底给我们带来了一系列问题。

目前我们已经引入事件审批中心的概念，其实就是社区开源的方案，我们做了一些进阶改造，也把我们关心的所有组件发生的事情转化上报，但是并没有彻底解决问题，包括K8S资源配置以及大规模恢复的问题，可以发现虽然我们在这个阶段好像通过容器的超卖省了一些钱，但是只要有些大规格的容器在运行就一定会有大量的资源浪费，包括大规模微服务的问题，比如无链路级的需求，系统越来越复杂，功能越来越复杂，产品线越来越多，如果每次只做局部的功能更新，没有去做全链路的回归可能不放心，每次都做回归成本会非常高，这些问题是不是可以通过新的技术解决，希望做些更细的管控。

我们处在一个云原生快速发展的时代，细分技术和解决方案层出不穷，我们期望通过引入Kata Container解决隔离不彻底的问题，比如刚才提到的IO和磁盘线程等等，防止单个容器孤岛导致整个节点挂掉。当然，我们对资源分配、资源调度和资源占用的问题期望引入新的调度机制，应用分为制造型、内存型和IO型，通过自定义的调度逻辑把资源调度更优化，提高资源利用率的同时保证稳定性。

现在有些高规格的容器只要在运行，一定就会产生大量资源占用，有些改造不彻底的离线计算应用，只要启动就会有大量资源浪费，我们已经在和Serverless团队进行探索和沟通，扩容以后怎么去缩？缩的指标怎么定义？时间点和标准没有办法定义，因为盲目缩容会导致生产不稳定，我们期望在此基础上用到阿里云现在的ECA方案，就是把公有云IaaS层作为资源池，这样就可以做到彻底按人计费。

刚才提到大规模微服务当中灰度链路需求，我们不希望每次少量的应用变更就会做全链路的回归，期望通过引入Service Mesh技术解决这些问题。发布的时候我们可以去做1%的灰度引流，进入新的版本链路验证和评估新的版本应用对生产的影响，然后可以大大降低刚才提到的场景回归侧的成本，并且还是可控的，Service Mesh可以给我们带来微服务更便捷，包括网商银行的DB管理和精细化管控，这些也是我们所期望的。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!