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

最后就是快照回滚，其实这是社区K8S不具备的能力，比如这样一次单一的发布可能包含更新定项、修改资源类型、扩速溶或者Service变动，这些东西都可以称之为一次发布，到了K8S以后就没有办法这样有体系地来做这件事情，Cafe通过发布能力把每次我们所关心的关键性资源，比如进项版本、启动命令、容器相关的设计等等都发布一个快照，这就赋予回滚的能力，原来要回滚的话可以切换一下镜像，不知道原来Restore的额度是多少，通过快照的能力可以让我们的应用回滚到任何时间的状态，这些不同的能力才是我们更看好的东西，仅仅提供云原生社区版的K8S要做推广难度是很大的。

下面我们通过四个方面来看国泰转向云原生以后的一些收益，主要包括成本、安全、效益和赋能。

按照资源成本来看，最明显的就是节省大量的服务器，运维管理以前都是Linux这些基础资源，现在我们不需要官方的东西，现在一个人管上百台、上千台规模的集群也不是什么难事。Cafe提供的精细化授权和安全变更的能力，还有多维度监控的能力要比经典运维更容易落地，如果总是被琐事缠身，有些工作是没有办法深入的，可能安全或者监控非常不到位，工作就会非常被动。

协作效率方面我们做了很多标准化的工作，新项目的申请资源到最终上线的这个场景，我们节约的时间大概是90%，经典发布的场景当中应用部署的力度是比较低的，一台机器一个应用，导致资源利用率非常低，同时也需要大量的机器承载业务，可能导致运维管理成本是非常高的，一个人要管几百台机器，国泰产品全面容器化以后，运维管理一个集群、上百个节点上千个Pod都不是什么难题。

K8S当中我们关注的是整个资源池，包括整个业务应用优先级进行保障的概念，实时业务链路分为一级优先级，针对这种应用资源进行充分保障，比如Resource和Request Limit，二三级的业务就在容器来做，针对基础资源的利用率进行优化，Cafe可以保证不停机的情况下所有容器的资源进行扩缩容，体验也是非常好的。

生产运行一段时间以后我们针对基础资源进行统计，同比经典发布的场景下，基础资源的开销同比下降30%，如果把生产和非生产加起来的话，这个数字节省了50%，其实这个数字是远远超过预期的，已经有50%的基础资源开销节省的情况下，我们发现原生的调度器的调度逻辑是比较粗放的，仍然还有优化的空间。

这些属于基础资源成本，运维管理成本大概降低30%-50%，这个数值是比较粗略的，其实运维就可以更加深入到业务场景，安全和精细化管理方面花上更多的心思。

Cafe权限体系目前已经和蚂蚁金融云打通，可以非常便捷地授权，通过自定义的角色分组绑定非常便捷地给予不同的权限。API管控方面Cafe做了租户级以及集群级的隔离。安全变更方面包括分组发布以及基于快照回滚，监控方面还有多方面能力。

落地的过程当中我们提出了几个标准化，原来的场景是经典发布，就是从一个项目上线一开始提出OA申请，部门负责人审批、运维负责人审批、运维采购资源、初始化环境和发布，大概需要经历五到七个人，最快两三分钟，再到现在的四五个人，现在已经标准化、模板化，执行链接再到芯片应用发布部署，全程最快三分钟就搞定，并且不需要跨部门协作，直接进行自主研发。

业务赋能肯定是公司最看重的，借助Cafe和金融云的能力，目前弹性扩容的时间大概是2分53秒，加上技术站可能更快一些，扩容的指标不仅可以依赖于基础资源，也可以到业务指标进行扩速溶，通过以上所说的能力把经典发布的低效率不可能变成了现在的高效率可能。

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

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

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

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

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

（编辑：核心网）

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