解析CIFS|太平洋保险集团王辉：金融行业云计算和云原生建设实践
2024-06-07
各位嘉宾、各位同仁：
大家好！我是来自太平洋保险的王辉。今天我给大家分享一下偏技术方面的云平台的材料，也是我们近十几年太平洋保险集团在云基础设施建设方面的思考和实践。
简单介绍一下自己，我的整个职业生涯基本上都是在云计算的行业。一开始是在银行，也是在做云平台，主要是给行内自己做，后面去了互联网，给同行业做，一直在金融行业。现在在太平洋保险数智研究院，负责云计算、云原生相关的工作，还有大模型的基础化能力我也在负责。
主要分享以下几块：
01
金融数字化转型要求
这是一个背景材料，从2017年左右开始监管一直在强调云计算的重要性，也是在大力推广云计算的能力。
云计算对于数字化转型的意义
云计算到底是什么，大家都知道其实就是基础设施，原来计算存储的能力通过云计算的方式供应给业务。云计算包括哪些？我之前总结了一下，有很多项，如果现在大家对云有所了解，公有云上有两百多项服务，一切的所有能力都可以叫云计算，云计算是提供基础能力的，从数据中心到基础设施硬件到IAAS计算存储网络安全，再到PAAS中间件，再到高阶的IOT、物联网、区块链都可以在云计算里面找到它的定位。作为配套的资源混部能力，提升资源使用率，都属于云计算的范畴。
太保数字化转型路线
太保的云计算使用经历分了五个阶段，也是跟业务紧密耦合的。最早在零几年开始做太保的集中化，是在2002年做ITSP，逐步引入了虚拟化技术。如果对之前的信息技术比较了解的话，就知道当时POWER是比较领先的，在WARE之前，当时都是用这个POWER虚拟化技术。第二个阶段，我们是从2009年就开始看X86的虚拟化技术，这是第二个内部管理信息化阶段。第三个是渠道，日活的量就明显上来了，所以对快速弹性上线的要求提了很高标准。14、15年左右开始做容器，那时候容器有不同的技术栈，我们后面走了MESOS的技术路线。这个技术路线之后，19年左右不再演进，在下一个阶段我们慢慢转向K8S。通过K8S实现整个云原生的能力。22年基于信创的能力要求，我们去做整体的云能力升级。再往后新一轮的数字化规划叫DHP，全面云原生化，通过数据智能、云原生的基础能力实现业务的目标。
太保云计算建设阶段及目标
新的云平台规划的时候提了四个大点，为什么要提这些？首先太保集团属于一个综合性的企业，它下面有很多不同的子公司，不同的子公司有不同的法人，所以我们会有一些计量要求，这块对服务可计量，怎么运营我们是比较关注的，和银行稍微不同。
服务化，因为运营肯定涉及到有服务化的能力，全部把我们的能力从线下模式搬到线上，也是比较关注的。
弹性伸缩主要考虑到现在的业务发展和资源实际的供给能力不是完全匹配的，这块也是比较关注的。
资源共享，刚才提到了一个集团性质的，如果原来还是按照每家子公司自己去建，资源的碎片化比较严重，这块我们是比较关注。
现在看下面的云发展路径，从刚才提到第一代虚拟化，到第二代，其实是虚拟化加管理能力，再往后就是公有云下沉的体系化，其实我们现在是走在第三代，第四代就是基于第三代的公有云体系化产业实现云原生能力，我们现在往云原生技术发展的阶段。
（信创）云平台选型建议
在信创云选云时刚才提到我们关注的四个能力，总结下来，我们到底关注这个平台的哪些点？第一是产品功能能否满足使用，因为业务有不同的诉求。第二是产品功能，第三是安全稳定，高可用体系。还有网络，公有云体系化产业下来之后，整个网络是集中化的能力，虽说是分布式能力，还是由逻辑群在提供服务的。性能关注点一个是网络转发，现在慢慢都是从原来的硬件网络设施往软件定义网络设施去走，所以软件网络关的能力性能转发是比较关注的。
从上面来看，我们有40+产品，设计了很多高可用力去做测试。
云原生之路：云原生定义
云原生，在我们看来其实是能够给业务带来很多价值的。之前的云原生有很多定义，现在比较流行或比较认可的就是2018年CNCF总结的，偏技术方面的，就是讲云原生应该有哪些技术，最终的本质还没有讲。我们现在理解云原生就是把原来的基础设施能力做成平台化，业务和基础设施做轻量解耦，两者没有什么关联，这个程度我们就实现云原生化。
云原生之路：云原生的价值
云原生到底能带来什么价值，总结下来有几个方面：
1、如何快速支撑业务创新。要求是什么？我要快速的架构敏捷，我要一个服务你能快速的提供给我，原来传统架构里面甚至按周计的形式，现在几分钟就要搭建好这样的平台，为业务快速上线。
2、不确定性，只有云基础设施是达不到的，从应用架构层面需要做匹配。面向业务的不确定性一开始有个MVP，但是可能未来会很快增长，这个架构就要按照云原生的架构去设计，如果有快速业务上来的时候，很快就能横向扩展支撑它。
3、未来的架构迭代，基础设施的架构迭代，未来一定是不能对业务产生太大影响的，之前我们的技术发展能力对业务的解耦做得并不好，很多底层的基础设施能力升级，业务一定要有很紧密的配合，这个对业务，尤其是对我们的应用开发部门带来很大的影响，后面我们就往架构迭代去走。
云原生建设目标
我们总结的云原生的建设目标：
云原生文化。云原生本身你可能短期内不一定能见到它的价值，但是你一定要理解它，或者是我们的业务团队可能相对比较难，但是应用开发团队一定要理解云原生能给他带来什么。云原生文化如何建立？第一就是以应用为中心，要认可云原生是包含高可用架构的。另外高效的交付能力，数字原生基础设施，这个我们底层的云现在逐步往这个体系上走。
云原生技术。技术有很多，总结下来有几大部分，服务化能力、弹性能力、可观测性能力、韧性能力、自动化能力、无服务器化。
云原生组织。要为上面的文化或者是技术架构去匹配组织，包括架构管理、架构路线、平台开发、平台技术运营，再到运维。
云原生技术定义
我给大家看一下云原生技术，我们现在有哪些能力，刚才提到有六块，现在总结下来有30项能力。目前和我们当前建设能力差不多，绿色的是我们现在平台上已有的，包含服务化能力，服务治理的能力，现在还有我们逐步从微服1.0走向变成平台和业务代码的解耦，也是现在正在做的，已经具备基础能力。黑色的包括多活，后面会提到多活多中心，或者是两地三中心架构下的能力。弹性现在还用到SPA和AS的弹性伸缩，加上负载均衡去做一体化的弹性能力，从上到下是全流程的。可观测性这块比较关键，尤其是云原生化之后，我们的服务拆分会有很多不同的服务，现在只是把链路追踪能力和一些指标关联起来，后面还有很多要去做的。韧性主要是在服务治理平台里面去实现的。自动化能力，其实建设得比较久了，包括一开始的自动化运维或者CI、CD的自动化发布。现在我们基于应用蓝图的一体化运营能力是建设重点。运维已经是老生常谈的问题，智能运维肯定是要做的方向，但是很难做。我们现在做了很多年，也只是做到了一点点场景化。像现在做的阈值的动态调整，还有一点点成绩，其他的还在做，包括技术AI如何实现快速智能运维，也是在考虑范围内。
云原生微服务应用选型标准
应用改造，有几个原则，为什么要拆微服务。春节前监管刚发了一个11号文，里面有18条，其中一点很重要，分布式业务到底怎么做的问题。现在来看有些分布式是拆得有点儿过头了。现在里面有个要求，什么样的业务才需要去拆。从自己的经验来看，肯定是相对比较复杂的，而不是所有业务都需要拆。现在看下来一个业务部门比较大，架构比较复杂的，另外是出现一定的瓶颈，这是拆的原则。其他的对业务本身的更新效率，还有自己独立化的升级，有一定要求的。这样去拆。拆的过程中和拆后，能影响一定的背景。微服务改造从四个方面，尽量要小，独立运行，轻量化部署，微服务之间的松耦合。
02
云计算建设路径
云原生微服务改造模式
如果我拆单个应用有一定的价值，但是不是呈体系化的。互联网之前有个中台的概念，中台还是有点借鉴价值的。现在我们的实际经验，把很多业务，原来授权一百多个业务，能够拆成不同的能力层去做服务化的治理，这样无论从资源的调动效率还有资源的节省都有一定的价值，中台化还是有一定价值的。
云原生应用的定义
再看一下对微服务的定义，如何看一个应用是复杂的云原生，它的技术标准是什么？技术标准和刚才的2018年的CNCF的定义有一些相似，我们定义了四大必选，你一定要支持CICD持续快速发布，一定要容器化，做小一点，因为容器的特性非常快，无论启动和扩容都非常快。一定是要拆成微服务。配套可观测应用的能力。这是最基本的四点要求。再往下金融云原生对下面的能力有要求，第一个就是融单能力或者高可用能力，现在在往两地三中心去做，后面还会做多地多中心或者面向未来的性能扩展的单元化能力。服务网络刚才也提到了，现在已经在做，服务网格应该是未来微服务比较好的方向。后面再配套的就是SRE，再高级的就是做成本控制的。可选的是现在正在尝试中，必选的是现在一定要求去做的。我们现在也是按照这个架构，团队去建组织。
03
金融云建设实践
新云实践-重点关注内容
我们在2022年新云重点建设的内容，我们重点关注这些，架构演进，现在上肯定不是一步到位，一开始只上了单个中心的，生产也是，后面演进到能做两地三中心级别的同活双活以及管控能力。高可用率，还会分计算存储和网络。
安全能力，我们会从端到端，从北向的入口，从互联网的入口层再到下面的云内的平台安全和云的租户安全都会考虑。
我们用了成熟的云平台技术，下来之后有些不太适应，最主要的就是监控体系的配合。所以在监控体系方面我们和厂商做了大量的工作，才做得比较稳定。
对云原生微服务的能力，原有的服务如何迁移到新的平台里面去。
04
面向应用的运营
高可用部署-存储集
几个点重点讲一下，高可用，我们用的方案，原来有主机组的概念，现在是用部署级，里面包括了集成、存储。中间件主要是集群内的分布式，加上跨集群的能力。
基础安全-层层防护纵深体系
这是安全的防护体系，从互联网边界到内网，每一层都做，有些可能是采用全栈云平台的方案，发现有些能力还是满足不了竞争要求，所以做了整合，两方面做结合。传统能力和云原生的能力。我们重点关注几个点，配置文件的转化，有个文具实现配置文件的快速转。另外应用的配置文件怎么迁移过来的问题，这个问题主要是通过K8S把原来的配置都换到KV6（音）方式去实现的。这是监控和告警的优化，有几点。第一我们把所有的告警的原数据拿过来，在平台做自己的规则整理和分发，另外把它的可读性做了增强。
微服务的平滑迁移方案
微服务的迁移，原来有自己的技术开源体系的，微服务体系往这边迁，最主要的是双注册能力，我们通过编车做了双注册，这样就实现应用平滑迁移，而不需要把所有的业务一次性全迁移。
云原生应用交付&应用运维范式
这边我再强调一下，我们的应用蓝图，是我们现在比较关注的，从交付到运维，都是通过一个蓝图走到底的模式，并且这个蓝图是可以复制的，这样会大大提高效率，并且还能从应用的角度去看所有问题。这是蓝图的实现模式，主要是通过混合运维来做的。
05
云计算带来的价值
从资源的快速供应来看，虚拟机和容器都实现了分钟级可得的能力，这是最明显的，降低TCO，提高运维自动化水平，提升人效，稳定可靠、资源率整体提升。
我们做到云原生之后能够达到什么样的能力，最关键的还是异地多活加无限扩容，这两个能力是比较关注的，其他的像成本降低，秒级容灾也是我们十分关注的。
我分享的内容大概是这么多，谢谢大家！
