首页 -> 新闻中心 -> 云计算 -> 正文
2019云计算开源产业大会丨张君:互联网金融保险场景下的云原生运维增效之道
2019-07-04

张君:大家好,我在国泰产险负责保险中台运维工作,同时也是云原生在国泰的推广者,今天和大家一起分享的是“互联网金融管理场景下的云原生运维增效之道”。

国泰产险是在2008年8月在国内成立的第一家产险公司,2016年7月引进蚂蚁金服作为战略投资者,2017年中旬启动凤凰涅磐的项目,背后做的就是IDC上云工程,整个年度保费增加102%,其中互联网业务占比68.5%,2018年中启动保险中台战略,也有引入微服务架构,2018年底整个保费上涨195%,其中互联网业务占比93%。2019年初公司提出科技赋能业务、降费增效业务,3月底保险中台上线,目前中台处于产品稳定迭代周期,赋予了国泰很强的实施业务的能力,更多日结业务也在往实时业务转型。

国泰产险在生态的产品也是比较丰富的,帐户安全险、健康险和意外险等等,产业合作伙伴包括哈罗、饿了么、飞猪和小米等等,2018年中旬启动保险中台计划的时候,整个技术部有了这样的诉求,我们要有互联网化的交付速度,敏捷响应业务的需求,同时会有更大规模的微服务运维,大规模的微服务给运维带来了很多难题,比较期望通过容器解决环境标准化、资源调度、业务互联等等问题。这些也有一些历史背景,不是说上云就上云,也有一部分业务是在虚拟机里面跑的。

我们选择这样一个公有云平台支撑业务的时候就会有这样的要求,除了按照经典运维发布的产品化能力以外也要有容器的产品,除了已有的K8S技术,更强的Serverless和Mesh产品也要有比较完善的能力,同时要有完善的监控体系。目前国泰产险在云上面已经有了6套KOS集群,可以满足不同研发测试和上下游需求,其实每个环节都不仅仅是90个应用,已经有100多个应用了。

选择公有云供应商的时候,刚才也有同学提到SOFA Mesh,包括中间件和分布式数据库的需求,我们就有找到蚂蚁金融云,主打金融分布式解决方案,并且是做FaaS方案支撑。SOFA Stack是蚂蚁金服自主研发的金融及分布式框架,包含各个需要的组件,其中比较常用的包括SOFA IDC、SOFA Mesh,SOFA Stack Cafe就是蚂蚁金融云的容器产品。

为什么我们会选择蚂蚁金融云的SOFA Stack Cafe?我们选择某种技术方案的时候,考虑落地持续运营的情况下不只是考虑产品本身,比如选择K8S,对比公有云产品的时候就要做一些差异化的比较,社区版本的能力基础上Cafe提供的是这样的能力。

首先是简化落地,K8S本身的概念比较多,Cafe在简化落地方面也下了功夫,具体就是通过外部UI的形式定制化、流程化地把我们要部署在K8S上面的原生资源具象化,每一个资源都是有很多特定的配置选项,这种成本会非常之高。

然后是日志采集,我们知道最佳实践包括两种:一种就是把更加云原生的业务改造,比如MQ等等存储,通过后端再抓取到日志平台当中。另一种就是在没有做云原生改动的应用,一般来说就是部署Sofa Stack。

我们在做选型之前其实是有一段时间的探索的,这些经验告诉我们,每个应用上面都配置组件的话目录繁多,每个目录都有不同的日志文件,我们要配置很复杂的收集规则,应用数量增大以后管理的工作也会非常繁重,管理成本也会非常之高。我们和这些团队接触之初就提出搜集创想,终端用户只需要配置一个搜集日志的目录以后就什么都不用管了,Cafe团队通过两个迭代,帮助我们实现这样一个创想,有了这样的功能以后现在回过头来看各个公有云的产品就会发现大家都有这样的能力,之前没有人具备这样的能力。

原地升级是Cafe一个比较有趣的功能,有些场景只能针对IP和网段来做安全限制,这种情况下可以用到原地升级,也有支持做发布变更的特性。

应用管理就是通过外部UI定制化和流程化,原来这种晦涩的云原生资源屏蔽,终端用户可以延续原来的经典发布习惯,可以四处发布部署自己的服务。我们刚才说的日志采集也是通过应用管理的入口去做编辑配置,包括上面的日志采集也是通过应用管理来做。

原生升级现在我们已经在大规模使用,落地场景当中还要有最后一公里的代码发布部署,社区版本的K8S并没有持续升级的能力,一般都是需要用户自己搞定,我们希望Cafe团队提供一个最简单、最有效的持续提升的方案,最后我们采用的是双重构建的形式,直接从代码仓库拉代码,再到构建运行逻辑框架,非常简单地解决我们最后一公里的难题。

持续运营优雅发布也有被称之为无损发布,实际生产发布的过程当中我们发现原生社区很多并不优雅,经常出现大概2%-5%的比例的错误,我们基于这种情况,结合Sofa、Cafe以及原生K8S的能力研发出了一套适合我们自己的方案,这套方案已经支持多个协议,可以做到实时业务链路的全覆盖,不单是给我们业务赋能,就是随时随地变更的能力,同时也解决了研发测试运维发布线的痛点。

事件审计中心这个功能源自于我们生产实践的过程当中发现的社区版本K8S事件功能,覆盖面不够全,力度也不够细,基于社区扩展的功能我们作出我了一些改进,其实就是社区提供的NPD方案,目前包括内核错误日志,还有我们关心的组件发生了什么,没有这样的功能的话我们是非常被动的,很多时候生产场景并不像原生社区那样简单。

监控方面SofaStack也有一些独到的地方,结合业务级和应用级的监控能力,现在这些能力已经具备,其中有一个能力是比较有亮点的,比如我们正在和Cafe团队来谈监控分析能力的接入,其实在蚂蚁内部是经过生产实践的,应用也是非常便捷的,如果把这种监控分析能力接入Cafe之后,我们在生产上遇到的比较极端的情况就不需要自己再去手动把内存文件传到本地这样复杂的过程,开发运维点击两个按纽就可以实现现场分析的能力。

我们还有一个亮点叫做发布审计,应用原生版本的K8S的时候会非常方便,一个Apply就可以搞定你想要做的很多事情,金融级的生产产品方便和安全其实是有冲突的,Cafe提供一个发布单的功能,所有的变更发布、运行调配、扩速溶等等需要变更的功能都需要一组发布单,当然刚开始可能觉得非常不方便,原来Apply一下就搞定了,现在鼠标去点三四下就会觉得很不方便,其实用下来以后,这个功能让我们的受益是很大的,可以做到发布的过程可追溯,原来的K8S只能通过授权,不知道谁做了什么事情,或者想查发布行为也是很难查的,发布单做到可追溯可审查可分段管控,也可以让开发创建发布单,验证以后去做一个发布的动作,生产上的很多故障都是发布引起的,发布单也对我们排除故障有好处。

最后就是快照回滚,其实这是社区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管理和精细化管控,这些也是我们所期望的。

新闻搜索

覆盖全国各省会城市及海外城市的网速测试
→选择要测试的地区
→选择目标测试点