【编者的话】 中英人寿在移动应用开发与运维上引入DevOps，极大的提升了开发效率，进而实现持续交付能力。持续交付让移动应用上线的速度从以月为单位提升到周甚至到天. 通过在企业云上使用（Docker、Git、Jenkins etc）搭建自动化部署流水线, 使软件的构建、测试、部署的过程自动化实现。随着IT架构向云架构的转型，在架构级管理工具上采用虚拟化容器管理，实现从IaaS到PaaS的转变。对移动应用系统进行容器化管理，在企业云平台上采用基于Docker的容器管理方案。
以下主要分享中英人寿IT如何针对自身业务特点，应用和推广容器技术。IT根据不同用户群体的特点，有针对性的选择容器优势进行宣导，从而使容器技术的应用和推广更加顺利。
寿险行业及中英业务特点
保险公司业务复杂，同时中英人寿是中外合资企业，外方股东对于经营管理特别是信息技术的管理有诸多制度上的要求,审批复杂繁琐，推进新技术应用有诸多桎梏。 金融企业在IT技术使用上相对谨慎，加上繁多的规章制度和部门，新技术的应用和推广，往往困难重重。如何说服用户与管理层，打破传统观念，并合理控制风险都是IT在应用新技术上必须充分考虑到的。
- 系统架构复杂：应用系统都不是孤立的独立系统而是前中后台各种服务组成的一个时时运行的业务体系。一个标准的互联网服务会涉及前台展现，客户身份认证，时时数据查询，各类标准业务流程，支付通道，甚至包含在线核保，保全，理赔，图像处理，各类通知服务和各种服务质量追踪认证。
业务规则复杂：寿险业务逻辑普遍复杂，因寿险产品的复杂程度和特性化越来越高，产品种类一般都在数百种，通用业务规则数千条，还包含更加复杂的医疗健康规则，以及长期险的给类保全类给付规则，更何况还有理赔的规则。
管理制度众多：保险公司内部管理制度众多，涉及监管，合规，风险控制，信息安全及日常业务规则和信息技术及开发运维相关的各类制度。如中英这样的中外合资公司和包含了股东方的各类信息安全和数据安全管理要求。为了满足各类管理制度要求，系统设计的灵活性大大受限制。
需求变更频繁：各类规则不是固定的，而是不断增加的。随着服务，产品和各类业务活动的增加，对系统功能，业务规则的要求不断增加。且这些前后规则大部分不是替代关系，而是叠加的，均需要通过系统的支持来实现。- 用户要求快速上线：在当前互联网快速发展的驱使下，外部环境迅速变化，业务单位的需求随外部环境的变化迅速变化，频繁的变更和要求快速的交付已经变成常态
- 基础架构负担：数量众多复杂的业务系统对基础架构带来了极大调整，无论是服务器，网络，存储还是信息安全方面，运维的负担越来越大。
我们为什么要使用容器
实际业务需要
3个月内必须完整2个移动应用的开发和上线，并能确保足够的性能和扩展性效率的需求：- 基础架构要在满足安全性的基础上保证足够的弹性扩展和性能。
- 整体业务需求定稿预计要在启动一个半月以后才能完成，留给IT建设的时间不足2个月。
- 涉及多个业务团队协同，开发团队包含北京广州的4个团队，各有分工但又需要能协调快速推进，并能及时看到开发的阶段性效果。
成本的控制
- 项目投入成本固定，长期投入可能会有很大波动，初期的基础投入必须控制。
- 整个项目的基础投入的采购时间必须配合项目的开发周期。
- 运维人员不足，短期无法新增运维人员，必须最大化利用现有人员。
容器技术从2015年开始关注，随着容器技术的快速发展在2016年从推广使用角度都相对成熟。但作为一种新技术，如何能让一个相对传统，同时又有众多规章制度的金融行业公司使用，依然存在众多困难。具体使用人群和管理人群对容器的理解成为推广容器技术的关键新宿。重点人群的推广和理解困难程度远高于技术的使用本身，但正因如此更不能回避可能存在的最大阻碍。想要成功推广必须能把阻碍变成动力。
从寿险业务特点可以看出，系统架构和业务规则的复杂，迫切需要标准化来简化开发和运维自身的工作量。因此容器在CI/CD上的优势，成为向开发和运维部门的实际执行人员推动容器技术的重要抓手。
自动化，隔离和集中管理的优势，更多体现在管理上。这点在项目执行和上线后，逐步体现出期优势。项目执行过程中向管理人群介绍其相关知识和优势，成为今后进一步全面推广容器技术的重要抓手。
基于公有云的容器方案不一定在整体上降低成本，但其在成本控制灵活性上有很大优势。同时随着容器技术的发展，目前容器的稳定版本对于实际应用来说已经完全可以承受。特别是目前容器的商业技术支持，让不具备太多容器开发经验的用户也可以快速使用容器技术。在控制成本上有以下几个特点。从实际使用效果上看，设备采购到货到安装的时间从传统的按月计算，到现在基本忽略采购时间。部署上基础操作系统安装在云上忽略不计，环境部署在配置基础镜像的基础上基本是分钟级别的。这已经满足我们的使用要求。
我们是怎么实践的
为了能把容器技术的优势最大体现出来，项目本身是一个全新项目，避免过多历史包袱和其他相关问题。在项目实施过程中，采用公有云部署加快了环境部署的速度，容器的使用在这个项目中是彻底的。同时基于数据安全性的考虑，项目中所有数据均不落地，均采用Redis加载。在设计之初首先避免在安全性上收到过多传统规章制度的质疑，避免浪费过多时间在解释和说明上。同时不过分强调测试自动化，尽量保持原有的测试流程和方式。在使用用户层面基本感觉不到改变。避免了过多的沟通和解释。
自动构建，代码管理和版本管理都实现自动化和可随时回滚。让运维人员充分感受到了容器技术的优势。同时在服务器使用上利用率有极大提升，基本上减少了近一半的服务器要求。同时考虑到今后容灾和系统扩展的要求，本次公有云部署只使用公有云的基础服务。所有项目内应用均以服务形式独立运行在容器下，从而做到充分的隔离。减少对公有云服务的依赖，并确金融行业业务系统容灾的要求。如有任何故障均可以在企业内部及时恢复完全相同的生产运行环境。
在整个项目实践中，采用成熟的持续集成方案，并全部部署公有云的容器中。最大限度避免了技术上的挑战，整个项目中除了ELK的使用，由于经验不足环境配置的性能不佳需要调整外，整体上都执行顺利，未遇到太多技术困难。但在容器使用中还是遇到了一些特殊问题，因此寻找一个有经验的合作伙伴来推动容器，对于金融企业IT来说是非常重要的。不建议准备不充分，仓促上马。
我们的经验体会
容器技术应用和推广的关键是实际使用人员，因此IT内部对容器技术的认识程度非常重要。IT团队的参与必须是实际的参与，开发，运维和测试环节人员都必须参与。推动这类项目首先是IT内部管理者的认识问题，只有管理人员本身认识到容器技术的优势和迫切性，才有可能真正进行推广。纯技术人员的喜好，很难让容器技术得到真正有效推广。
实际应用必须循序渐进，不要过于追求先进性和完美。必须从自身能力出发，量力而行。在实际应用中最好要找到一个成熟的合作伙伴，必须讲容器技术是一种新技术，对于金融也IT来说更多专注的不是不断变化的新技术而是业务与技术应用的结合。因此为了少走弯路，成熟的合作伙伴是非常重要的保障。
运维自动化需要流程制度的配合，工具不能代替人员自身的管理要求。虽然自动化可以提高基础配置的效率，但真正提高效率的是开发和运维人员观念的转变。因此这个过程必须不断总结和修正，寻找问题和察觉。不要认为上了docker就一劳永逸，实际上真正开发和运维会遇到更多新的问题，因此必须正视面对这些问题。
由于容器技术和相关CI/CD技术的发展速度非常快，因此在应用推广中，负责人对技术方案的把握非常重要。尽量避免在同一个项目中采用过多从未尝试的技术或者版本，必须控制新技术尝试的范围，从而控制整体实施的风险。这实际是追求创新和稳定之间的一个权衡，负责人在实施中要避免过多受外界因素的影响。
同时必须考虑运维人员的工作负担，容器技术更多是对运维人员工作的改变，实际是要掌握更多新的知识和尝试更多新的技术。因此在项目实施中实际运维人员的工作量是增加的，这点必须考虑到，否则会得不偿失。
好了，以上是我对前期中英在容器方面实践的一些经验分享，谢谢大家。
Q&A
Q：您好，现在基于容器的解决方案也有很多，我想了解下部署后，你们是如何设置监控系统的，如果监控容器，可能会因为容器的生命周期不固定，导致部分监控数据会随着容器消失，变成无用数据；如果通过宿主机监控，那么你们是通过什么方式实现的，是通过自行开发，还是第三方开源程序，如何做到资源、应用数据的准确收集和合并？Q：请问在Docker化过程中，遇到的最大的难题是什么，最后是怎么解决的？谢谢！
A：您提的问题也是实践中最担心一些问题，由于容器的技术变化很快，目前监控方面的问题我们更多使用第三方厂商提供的软件进行监控。 保险公司IT本身对容器相关技术，更多目前还是处在摸索和熟悉阶段。我们更多把容器作为一种灵活的工具，因此对于后台管理和监控，没有使用Docker自带的工具。
Q：规模上去后，容器如何自动化的管理和容器配置文件如何自动化管理？谢谢！
A：最大困难还是对容器的理解问题，特别是管理层及运维开发实际操作人员如何理解容器。实际容器2015年下半年我们就想使用，但考虑到实际的推广困难，我们也是一直在找合适的机会，直到有合适机会才会真正开始应用和推广。我在分享中也提到了，谨慎原则，因为一旦第一步推广部顺利，那么后续困难就很大。所以我们第一步并没有给自己订立太高目标。
Q：您好，能否介绍下微服务技术改造方面的经验，尤其是数据拆分方面，如何破除数据库之间的表依赖，比如在单体应用里很多功能都是直接通过数据库的关联查询实现的，如果进行微服务改造，怎么处理类似的关联查询？ 另外，能否介绍分布式事务管理的技术方案？
A：规模问题更多要看自身情况，目前更多介绍上都在强调容器在规模上的优势。但正如我开始提的，实际在业务场景中，规模本身是随着业务发展而增长的。我们目前考虑就是随着规模的增长，自身对容器的使用和经验积累也会随之增长。同时对于我们这样的寿险公司来说，更多采用商业解决方案。这样有比较持续可靠的长期支持，毕竟这个技术变化很快，我们更多关注灵活性和我们选定的优势的发挥。自动化管理和容器配制文件，只要项目部是很多，那么问题不大。如果普遍推广的话（这也是我们下一步计划）那么开发和运维人员自身的能力提高是解决自动化的关键，而不只是软件。
Q：数据库的数据前移到Redis， 增删改也是通过Redis？
A：数据部分我分段来回答一下。数据拆本身更多是IT对业务的理解问题，中英IT在这方面是比较擅长的，毕竟是自己的业务。这点首先我认为没有什么通用解决方案，必须根据实际自身情况来考虑。中英情况我接着介绍一下。
最开始也介绍过由于业务复杂逻辑多，因此我们对外服务都有统一的接口层和再次基础上的业务逻辑封装层。关键是这次我们将大量关联数据采用缓存+路由查询的方式通过Redis来进行前台查询。把我们理解的数据往前推，这个逻辑和实现实际比较复杂，但结果就是基本不依赖后台的时时查询。但这里有很多场景的限制，这点也是我们实际实施中花最大力气去解决的。
关联查询问题会很多，特别是性能。所以我也提到，这点光用技术解决方案很难解决，必须结合业务逻辑，考虑如何把数据前推。关于分布式事务管理，目前我们不建议采用分布式的事务管理，那样只会带来更复杂的逻辑关系。我们最多是考虑Redis的集群部署，但事务处理都是集中的。对于复杂问题，我们尽量去回避，本身项目就有很多挑战，不希望在这方面有更多不稳定因素。
Q：如果通过服务调用的方式 更新后台数据的话，怎么做到事务的集中管理的呢？
A：不是数据库前移，我们由于考虑信息安全和合规的要求，实际这次数据不落地。Redis都是缓存数据，而且不写文件系统。只用作查询，对后台数据的更新删除，还是采用远程调用服务的方式。根据业务分析，我们的应用绝大多数是查询，因此首先保证查询速度。
Q：规模上去后，有没有测试过性能方面的场景，比如某种配置的物理设备，可以负载多少容器，性能相关指标如何？谢谢！
A：由于寿险公司核心业务系统都是集中系统，事务处理一开始就根据业务模块和逻辑做了划分。因此在内部本身就是事务逻辑非常严格控制。这里首先是业务逻辑就有严格的前后逻辑顺序，什么前提下能做什么不能做什么有严格划分的。在DB层面的事务，我们DB本身就是集中DB，不是分布式的，因此DB本身控制事务，不存在控制不住的情况。但如果调用太多，的确会有严重锁的问题，这点反而是我们比较头疼的问题。同时首先业务时时交互频率不是那么高，因为不像电商，这个问题不突出。
Q：您好，请问你们公司是否存在一些Windows应用，针对这些应用如何使用容器统一部署管理？
A：目前我们还没有这方面实际的经验。但在实施中考虑到规模的问题，因此这次实际选择的就是公用云，直接使用云的基础服务。另外关于性能和物理配制。这点，至少目前我们遇到的主要问题是内存不是CPU。合理分配内存是个经验积累的过程,我在分享里也提到了，我们遇到了因为配制不合理ELK性能非常差的情况，反而应用环境本身没什么问题。由于我们在规模上没有太多经验，因此不能给您更多的有用建议，这点互联网企业应该更有经验。
Q：您提到不过分强调测试自动化，尽量不改变测试流程，那么对于自动构建和单元测试的自动化有没有考虑呢？毕竟这些是比较消耗人力的部分。
A：我们有Windows应用，至少目前我认为用Docker来统一部署Windows应用不太合适，我们内部如果有这个要求会选择VM，VBOX也是不错选择。
Q：这次容器化改造后，对比原来的系统有哪些方面具体的提升呢？
A：自动构建我认为比较现实，单元测试有考虑。不过我们测试案例过于复杂，目前看短期实现不太现实。而且性能也是个问题，如果下一步要做我们会更多考虑一些特定场景。比如产品发布后的回归测试，这个有可能，但不会是普遍应用。
Q：请问中英人寿应用更新的自动化流程能做些介绍吗，有没有将应用和配置分离做改造？
A：性能本身我认为和容器没什么关系，虽然这次性能有很大提升，但更多是因为用了公有云和Redis做缓存。容器改造后最大提升的我认为目前是部署和更新的效率。对运维工作效率有非常大的提升，毕竟大部分应用环境的更新都自动化了。这点本质性变化。
Q：是否建议企业最佳实践是从新开发或重构应用开始容器化？
A：我们这次是个全新项目，所以不涉及改造。自动化部分就是标准的持续集成Git+Jenkins的自动化管道。Git根据环境做了一些分支，部署直接采用Docker方式。这是一整套的。Docker相关配制目前是在cSphere里做管理，实际我们没太多操心这个部分。对于开发来说实际没什么太大变动。只是自动化构建做通了。
以上内容根据2016年7月25日晚微信群分享内容整理。分享人张琦，中英人寿信息技术部总经理。中央财经大学保险专业毕业，具有15以上的寿险从业经验。长期从事寿险业务及信息技术相关工作。 DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesz，进群参与，您有想听的话题或者想分享的话题都可以给我们留言。
A：这是个最保险方法，但我认为重点不是全新或者重构。而是是不是能带来实际效益，我说的是业务效果。对于用户来说实际并不了解和关心容器技术，想推广一个过用户关，一个过运维和开发协调的关。
有疑问加站长微信联系（非本文作者）
