【2018可信云大会】希云cSphere张春源：国内保险行业容器云总结报告

定制的k8s能够使用户不再纠结细节，这个占比在25%。调研下来发现占比最多的还是商业化的产品，因为商业化的产品占比要比开源和开源的k8s和定制的k8s还要多，这也说明了保险公司关注的不是技术的细节，而是更加关注如何基于新的技术在业务上支撑产生的价值。

为什么保险公司会选择商业化的产品，我也接触了好多公司的CIO。1、商业化采购的产品，第一重要的因素是比较放心，因为出了任何问题都有供应商提供支持。2、像开源对于保险公司来说整体的应用成本其实不省钱，总体算下来甚至会比商业产品更贵。他们最后还是希望优势结合，各司其职。3、容器技术也是比较新的，对于保险公司来说，他们不可能招很多的研发研究底层平台的技术细节，可以还是希望有能力的第三方合作厂商能提供企业级的功能。

保险公司应用了容器之后，基于容器平台部署的业务系统占比情况也做了总结，目前来说核心业务系统占比差不多26%，电商平台占比20%，销管系统占比18%，偿二代系统占比8%，移动展业13%，银保通7%，其他的占比8%。希云承接的是银保监会第一家批复的企业国宝人寿，现在国宝人寿95%的业务都是基于容器部署，包括数据库也是。国内保险行业现在做的，像国宝人寿从筹备到开业、验收、上线整体全面实践了DevOps整套的体系，我们总结下来，根据当时批的IT的预算花下来总体能省49.22%。

降成本和提效率都是非常有成效的事情，服务器的资源来看，调研发现，最大的还是VMware平台，达到58%的数额，其次是物理机，主要是运行数据库和存储，占比22%，现代行业的发展，云计算成为主流，所以像互联网类的业务可以部署到公有云上，希云目前服务的保险公司基本上都是有公有云服务的，差不多占比12%，其他的基础设施占比8%。容器平台建设完之后下一步就是要选择如何将业务系统进行上容器。

大多数保险公司都会关注这个问题，比如是不是单体应用可以省、是不是需要改，包括要怎么改等问题都会有担心，为此希云和合作伙伴，包括现在服务的保险公司进行了多次的讨论，并进行了验证，我们发现应用系统上容器不一定改成微服务，因为使用容器，包括像微服务，还包括分布式架构、互联网的架构、对于底层服务器资源来说，容器是可以基于物理机也可以基于虚拟机，还可以基于云虚拟机的部署，实践下来总结了4点：

1、保险公司IT人员首先不需要掌握容器平台的技术细节，重点是掌控怎么样基于成熟的平台迁移应用以及符合监管的要求。

2、考虑老系统有些历史的包袱，优先推荐新的迁移的业务系统树立标杆。

3、有些系统部署的复杂度是比较高的，比如部署过程当中经常需要手动进行参与，并且容易出错，而且部署频率还比较高，这样应用都是可以尝试使用容器做部署，这个时间下比如Oracle的部署基于容器的部署就是1-2分钟，这样对于开发测试来说效率是非常高的。

4、一定要有一定的耐心制定容器推广的计划，这不仅对自己有好处，也让公司所有同事受益。

DevOps是一种文化，如何让DevOps成为一种文化的信仰，DevOps在金融企业落地，我们发现确实有一定的难度。我们在实践当中发现，虽然有难度，但是我们可以把一个大的难题拆成小的难题，比如我们可以从公司的上层定义DevOps的体系，包括需求管理、微服务框架、代码仓库、代码质量管理、自动化测试、自动化编译构建、容器部署、虚机部署、云平台部署。我们把保险公司的参数列了出来，有的是第一步是需求管理，可以基于腾讯的Tars进行框架开发，也可以进行代码扫描，还可以自动化测试、自动化编译，进行部署到云上，这样的分布就比较高。还有一些偏老的系统比如什么都没有，或者现在只有虚拟机部署，第三方开发完之后把包给过来部署到虚拟机，这样这个系统的分就比较低。

针对体系来说，我们把这个公司的系统对应下来可以打出来一个分，现在这个系统符合整体DevOps整个管理体系能到哪个阶段，如果已经到了这个系统就会比较好，如果没到的话，达到了一个或者很少数的参数，这个系统在后续发展当中就有待进一步的优化。有了这个体系我们可以作为一个参考，不管是对于内部的研发团队还是对于外部开发商的团队都可以把它当成是一个标尺或者是标准衡量的规则进行约束和管理。

DevOps文化的落地也需要配套一些工具，DevOps的核心是持续集成和持续部署，就是大家所说的CICD，实践好CICD对企业来说非常关键的，调研下来发现，不管是银行还是保险公司，好像DevOps行业是标配，大家都在使用，占比高达到5%，经过这么多年的历练，它的功能和插件都很优秀，去年我在可信云大会上说实践DevOps是必由之路，到目前为止我还是觉得容器是实现DevOps流程里面最佳技术，尤其是很好的弥补了DevOps后面CD的过程。

微服务框架调研下来有的保险公司会选择开源的SpringCloud，有的选择了腾讯的Tars，希云除了提供一站式的解决方案之外，前面也有提到，我们调研下来发现，腾讯在内部的使用量上首先是比较大的，足以能证明开源框架的成熟能力，我们实际的情况，比如和一家保险公司共同拆分了业务系统，当时选择了腾讯开源的Tars，发现Tars跟开源的SpringCloud对比的时候有一些优点，首先Tars是完全开源，Tars可以支持多种云，不仅包括java包括C++、PHP和python，接下来也会把golang进行开源，因为当时系统是用C写的，所以使用Tars对我们的承诺会很低。另外用Tars的java开发比传统性能会提升十倍以上的数字。

第二是敏捷开发方面的优势，Tars是根据接口描述的文件，自动的可以帮开发者生成服务端和客户端相关心的代码，这样我们只关心业务逻辑如何实现，不用专注于底层。Tars是具备了微服务体系的高扩展性，包括功能扩展时仅需要新增接口，性能扩展时可以进行水面扩容，这时候也是大家比较关注的，它扩缩容的时候会不会对业务造成影响，我们实践的时候发现Tars在这方面做的非常出色，随着扩缩容的时候应用都是无感知的。这样对我们在整个项目里的投入，人员的成本都是非常大的节省。

第三是高可用性的优势，业务以名字服务注册、客户端通过服务名获取实际服务地值的时候，当服务界面因为故障无法上报信息量的时候，我们也会把地址信息发送到客户端，根据返回的情况自己进行业务判断，进行故障的评定。Tars支持网络服务端就近调度的策略，同时调度策略再细分可以根据IDC、SET分组功能进行选择。这样可以满足更加丰富个性化的调度需求，防止因为访问量突增或者服务器故障造成系统的崩溃。Tars底层是通过非主侧的异部请求的队列，并对队列的长度进行监控，保证系统正常运行。

（编辑：源码网）

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