China Life Zhangqing Nan: China Life Insurance How to build PaaS platform-based containers

Oral / Author:
Zhang Qingnan China R & D Center for Advanced Life Architect
editor:
Rancher Labs

16c2c37e06d66af7?w=692&h=462&f=jpeg&s=106552

China Life senior architect Zhang Qingnan R & D Center

Since 2017, China Life started using the container technology to build a PaaS platform, "Rice off the cloud" and with the continuous integration / sustained delivery technology, the development of the whole process automation and comprehensive management of the application container, to 2019, "Rice off cloud "has supported the production run, China Life management application container 15 key systems of more than 4,800. Application container technology facilitates optimizing the entire development process of China Life and control, greatly shorten the iterative cycle of the software, and the way to carry the container to deploy applications to achieve resilient and elastic, quickly build application deployment. This article describes the practice of building China Life PaaS platform-based containers.

16c2c38267e941c6?w=1497&h=838&f=png&s=415008

In early 2017, China Life Insurance cloud container construction started in June completed the set up R & D and production testing of cloud cloud. After the build is completed, a large scale development and test cloud, cloud production is still in the experimental stage. By the end of 2017, we have a migration of 54 systems in the R & D environment, almost all of Java class systems are developed and tested in the cloud.


June 2018, the production line cloud on the business-critical systems on first truly - big health platform, a cloud-based system entirely native development. Since then, we continue to cloud the production line on other business-critical systems. In early 2019, part of the China Life Insurance branch of China Life started using PaaS platform.


Up to now, China Life Insurance have 174 servers, mostly in high-end blade machine, hosting more than 600 micro-services, running more than 4,000 containers, 15 business-critical systems running on the production clouds. China Life preservation platform next-generation core business system has been completely on the cloud, integrated query, batch jobs and other services modules also in July on the production line to the cloud. In addition, China Life's life insurance APP and customer-facing part of a service-oriented marketers of micro E shop system is also running on the cloud. Meanwhile, China Life's unified user systems running on the cloud.


Over the past more than two years, China Life PaaS cloud has been stable operation, mainly because Rancher relatively stable, and we do a lot relevant safeguard stability in the deployment and operation and maintenance.

16c2c3865883bad0?w=1488&h=837&f=png&s=356961

本文的内容分为三部分,一是中国人寿为什么要建设PaaS平台,二是我们是怎么建设PaaS平台,最后是我们如何利用PaaS平台。

为何建设PaaS平台?

16c2c38f5d87d566?w=1920&h=1080&f=png&s=610535

中国人寿建设PaaS平台的目标很简单,就是一句话“为了更好地使用资源”。大家都应该知道,字越少,事儿越大。一句话的目标听来宽泛,我们需要分解它,以便于更好地理解。

16c2c393b0ab7710?w=1496&h=843&f=png&s=351511

首先,什么是资源?我们觉得以下三类内容是我们需要考虑的:一是“环境”,程序需要运行起来,就需要使用CPU、内存、磁盘操作系统,这些程序运行起来的需要的最基本的资源就是环境;光有环境你的程序可能还是无法运行,大部分系统的运行还需要依赖中间件,比如web中间件、数据库、缓存服务等,这些是你需要的“技术依赖”;有了这些,你的程序可以运行起来了,但不一定能处理业务。比如我们开发一个出单服务,这可能需要依赖保单服务、支付服务,这些是你的“业务依赖”。


上述三个就是我们需要解决的资源问题,一是环境资源,二是技术依赖,三是业务依赖。

16c2c39932ac2311?w=1920&h=1080&f=png&s=629093

理解了什么是资源,我们再去看什么是“更好地使用”。我们认为它包括两个方面的内容,一是对人来说,能够更便利地使用资源,最好能达到像使用水电一样,想用的时候就打开,想用多少就用多少,用完了就关上。二是对应用来说,能更有效地利用资源,以达到节约资源和降低成本的目的。过去需要花10份的资源才能做成的事情,现在用5份资源就能完成。

16c2c3a1852137cd?w=1920&h=1080&f=png&s=654781

用一句话总结中国人寿的PaaS平台,就是:基于“容器技术”和“自动化技术”为“人”和“应用”提供服务,解决“更好地使用资源”问题的“云平台”。

16c2c3a5851e45ad?w=1497&h=835&f=png&s=352498

首先,这句话里包含了两大关键技术:“容器技术”和“自动化技术”。

16c2c3ab628c4dfd?w=1495&h=840&f=png&s=346800

我们先来说说以Docker为代表的容器技术。为什么中国人寿要用Docker容器技术搭建PaaS平台,而非使用传统的虚拟化技术呢?


在这个项目启动之前,中国人寿已经大量地使用基于VMware的虚拟化技术了。那么,在搭建PaaS平台的时候,为什么我们不用VMware搭PaaS,而是用容器来进行搭建呢?主要有两个原因。一是容器的“轻”,这个“轻”体现在各个方面。举个例子,容器是基于进程的资源管理,所有运行的容器共享一个宿主机上的资源,它是抢占式的。虚拟机像是切蛋糕,你把资源分配给它,无论它是否使用,它始终都会占用这个资源,其他人无法使用。容器要比虚机模式节省非常多的资源,我们在后面会用一组数据说明这个问题。


第二个原因也非常重要:容器是以应用为中心的,容器一旦启用,启动的是一个应用;而虚机是以环境为中心的 ,当你启动虚机的时候,它为你提供的是一个操作系统。二者之间区别很大。中国人寿PaaS平台的建设以应用为中心。诚然PaaS译为Platform as a Service,但我一直将它当作是APP as a Service去考虑这一问题。

16c2c3b05ad13a63?w=1496&h=837&f=png&s=356589

中国人寿使用Rancher进行容器调度,目前用的是Rancher 1.6版本。2017年我们开始搭建中国人寿PaaS云平台的时候,Rancher还是1.0的版本。


我们选择Rancher主要有三方面的原因:


第一,Rancher足够简单,这个非常重要,Rancher的概念模型沿用的是Swarm的概念,上面是应用栈,底下是一组Service即微服务,这个概念与中国人寿“以应用为中心”的概念非常吻合,拿来即用,我们很喜欢这个概念。


第二,Rancher功能足够,不复杂,但足够。作为一个金融企业的IT部门,我们不需要那些花里胡哨的、没用的功能,Rancher产品本身使用简单,但提供的功能又能满足我们的需求,这样很好。


第三个原因也非常关键,就是稳定,我们从Rancher 1.0版本一直使用到现在的1.6版本。在Rancher1.5之后,Rancher基本上没有过多功能上的变化,一直在完善功能和应用性,后面的几个版本都非常稳定,我们从1.4版本开始上生产云,现在用的是1.6的版本。

16c2c3b5846093c7?w=1494&h=835&f=png&s=382572

说完了容器技术,接下来讲第二个关键技术,以Jenkins为中心的自动化技术。


中国人寿的自动化技术主要用于持续集成和持续交付,我们重点谈一下持续集成。


我们认为,容器技术使持续集成技术格外强大。在容器技术之前,持续集成指的是,当代码发生变化,触发Jenkins上的一个Job,将程序编译打包后,发布到一个固定环境的固定中间件上,让它跑起来,你所能做的就是能让代码的变动触发程序的变化。而有了容器技术之后,你就能做到当环境变化后,通过触发持续集成搭建新的环境;当中间件依赖变化后,通过触发持续集成构建新的中间件;当业务应用架构变化后,例如从一个应用变成了十个应用,还是可以通过触发持续集成拉起一套全新的应用体系。这点非常关键,因为我们刚才说了,我们想解决的问题是环境依赖、技术依赖和业务依赖,现在通过容器技术,通过docker-compose文件结合持续集成,我们基本可以做到自动获取任何资源了。这是第一个关键点。


第二个关键点是持续集成使容器技术在中国人寿这样的企业广泛推广,它大幅降低了技术人员的使用门槛。中国人寿有各种产品、不同的团队,并不是所有的开发人员都有意愿去学习和掌握什么是PaaS、什么是Docker、什么是镜像、怎样做部署。但我们又希望所有人都能把容器用起来,那该怎么做呢?在公司内部推广的时候,每一个需要对接进来的系统,我们都会让PaaS团队为这个系统实现持续集成。持续集成将代码编译、构建镜像、镜像更新、应用商店等等全部自动化。如此一来,对研发项目组、对开发人员而言,他的工作没有发生任何大变化,只需更新代码即可,PaaS的使用均由持续集成自动化执行。

16c2c3bbba1a050a?w=1496&h=844&f=png&s=418074

我们的服务对象包括两类,一类是“人”,一类是“应用”。我们希望为“人”即项目经理、开发人员、运维人员提供研发运营模式上的革新,对“应用”提供微服务架构、无服务器架构等架构模式上的革新。16c2c3bfe13ff44b?w=1920&h=1080&f=png&s=630512

中国人寿PaaS平台旨在解决“是否更好地使用资源”的问题。我们如何判断是否更好地使用资源呢?我们可以将它量化为三项,即:是不是省时了、是不是省事了、是不是省钱了。

16c2c3e844c23bbd?w=1495&h=839&f=png&s=408389

中国人寿有一组数据,它并非整个平台的使用成果,而是中国人寿的一个分公司在平台迁移前后的数据成果,我们将过去部署在虚机上的服务器和部署在云上进行了前后对比。


上图是平台的资源使用情况和效率提升情况。资源之所以节省,是因为容器基于争抢资源的模式,能极大避免虚机时代资源占用浪费的问题。效率的提升,则是由于持续集成极大地提升了研发及资源获取的效率。在中国人寿,我们申请设备需要走流程进行审批,这个过程会花费大量的时间,现在可以通过持续集成实现“自管理”,开发人员在需要资源时,通过触发持续集成自动获取资源。

如何建设PaaS平台?

16c2c3ed2928fa34?w=1499&h=836&f=png&s=421335

上图是我们在2017年立项时画的,这张简单的图指导了中国人寿两年左右的PaaS平台建设工作。


我们认为,中国人寿需要有一款自己的PaaS产品,我们要基于这个产品搭建两朵云,一朵是开发测试云,一朵是生产云。两朵云有不一样的定位。开发测试云解决的是资源利用率、管理成本和研发效率等问题,生产云主要解决微服务托管、快速部署、交付一致性、弹性伸缩等问题。


两朵云对应用的要求也不一样。对于开发测试云而言,所有你能搬上开发测试云的应用,我都能帮你做容器化和自动化,你享受开发测试环境带来的种种优点即可。但对于生产云,我们有更高的要求,生产云的应用必须是云原生的应用,必须做好微服务化改造,技术人员自身还必须知道如何利用云上的优点。所以两朵云对应用的要求是不一样的。


我们在开发测试云上做了持续集成,通过持续交付打通两朵云,两种云结合为DevOps夯实了基础。

16c2c3f1fa48f185?w=1505&h=838&f=png&s=264244

上图是我们对产品的定位,主要关注四个部分:第一部分是通过Rancher进行容器管理;第二部分通过Harbor进行镜像管理;第三部分是通过Git进行应用商店管理;最后一部分是是基于Jenkins搭建CI/CD,开发运维一体化。

16c2c4245153678f?w=1503&h=841&f=png&s=399479

这四部分明确之后,我们通过中国人寿的稻客云门户集中管理底层云生态,再通过稻客云门户对接用户管理,统一权限、统一用户,进行界面上的集成,让用户在一个界面上完成所有事情,以及实现监控、日志等功能。


除此之外,稻客云门户还可以实现两个比较有意思的功能,一是多租户,一是快速部署。Rancher 1.6版本里没有基于用户层面的多租户隔离,它基于环境进行隔离,所以如果一个环境上很多用户,上层运行的应用能互相看到,和我们理解的多租户隔离有所区别,所以中国人寿自行开发了多租户隔离功能。


快速部署是一个将发布流程极简化的功能,它屏蔽了持续集成以及PaaS、Docker的过程。我们先前有个情况,分公司的同事希望运行自己的应用,但又不想关注PaaS、Docker、容器包括持续集成等技术。为了解决这个问题,我们开发了一个界面,让分公司选好应用程序,点击上传,再点击启动,我们在容器上运行应用程序,再将容器IP返回去,就完成一次快速部署。

16c2c428e0e77e23?w=1495&h=840&f=png&s=241519

中国人寿在北京和上海各有一个数据中心,在上海和北京各部署了一套生产云,开发测试云只部署在北京。每朵云的管控节点均为独立部署,每个管控节点托管很多个不同的环境。当中有一个关键点,即环境的划分。一个环境里托管的主机越多,共享的应用就越多,从而规模效益越好,资源利用率也越高。但这样会使隔离性降低,当系统出现问题时,运维难度将呈几何级上升。


因此,在开发测试环境中,我们追求尽量扩大规模效益,在开发测试环境划分了5个大环境,所有机器部署在五个大环境当中,大家混合使用,资源利用率很高。但在生产环境中,我们非常谨慎,一个关键系统独占一个环境。正如我先前所说的:两朵云的定位不同,想解决的问题也是不同的。

如何利用PaaS平台?

16c2c42ea8d5536c?w=1490&h=839&f=png&s=352024

前文曾经提到,中国人寿PaaS平台的服务对象一类是“人”,一类是“应用”。“人”指的是项目经理、研发人员、运营人员,“应用”指的是微服务框架和无服务架构的支持。

16c2c4339f01a1fa?w=1496&h=839&f=png&s=463077

对于项目经理而言,我们希望为他提供的变革是自服务。过去,项目经理的主要职责是找各种能够提供资源的对象,获取开发所需的资源。现在,我们希望对他进行变革,利用PaaS平台,让他通过平台、应用商店、持续集成实现自助服务,提升项目经理获取资源的效率。

16c2c4379c11b222?w=1495&h=841&f=png&s=393506

对于开发人员而言,我们希望达到自动化。刚才前面几位嘉宾在分享的时候,提到了开发人员专注于业务逻辑开发。我们认为开发人员要做的最基本的事情是开发代码、提交代码、测试、查看,开发人员只需要做这几件事情,剩下的活动比如编译、构建、部署、测试等完全通过持续集成、自动化脚本来实现。

16c2c45301965672?w=1497&h=841&f=png&s=374736

我们通过持续交付,为运维人员提供软件交付上的变革。我们在开发环境专门找了一台开发交付机部署Jenkins,这台机器打通了跳板区的镜像仓库,为每一个在云上提交的项目实现交付任务。交付任务完成后,我们将Jenkins上的用户权限提交给应用的应用经理及应用团队。当应用团队需要交付时,先将代码提交到交付机器上,再在Jenkins上执行交付任务,交付的Jenkins会抓取代码,打包编译、构建镜像,将发布镜像推到跳板区的镜像仓库,再由生产的运维同事在应用商店里选取应用,点击部署,一键部署后将整个应用从Rancher上拽起来。


文初提到中国人寿PaaS云平台上线的第一个业务应用——大健康平台,拥有45个微服务,运行200多个应用容器。因为大健康平台是第一个上线的业务应用,我们对它进行了测试,从开始交付到运维人员现场部署一共花了8分钟。假如我们手工按传统的方式去部署,200多个应用预计要花2周的时间。

16c2c4579b144714?w=1496&h=844&f=png&s=375514

中国人寿PaaS平台的微服务主要有三个场景。第一个场景是应用完全微服务化,全部应用均跑在容器上。我们为这个应用拽取两个应用栈,让它能实现蓝绿发布与灰度部署,这两个栈是一样的,栈里面的微服务通过服务名进行通信,这一功能由Rancher实现。对外提供服务则是在Rancher界面上配置一个内部代理,将内部代理固定到主机,在PaaS环境外配置一个外部代理,指向两个栈的内部代理。

16c2c45bdc992cc9?w=1496&h=842&f=png&s=379522

第二个场景就是部分应用容器化,一个应用在进行微服务改造后,一半跑在传统环境上,另外一半跑在云上。这种情况建议引入两个关键组件,应用网关和服务发展中心。


There are very crucial point, we use a flat network mode Rancher 1.6 provides. In this mode, each vessel to get a real IP, IP and PaaS in their external environment, the company's other facilities IP interworking. After such settings, it is assumed that an application split three micro-services are deployed on a cloud, three services are registered with the micro-registration discovery service center, and the communication between the micro-services over conventional application directly through the IP, through a service registration discovery Center can directly communicate. Outside the cloud applications need access to micro-services or legacy applications, you can access through the above application gateway.

16c2c45f31bb4fa4?w=1498&h=837&f=png&s=308646

The last mode is very simple, it may not be micro-services, it is just an ordinary application, needs to be expansion in the cloud. For example, I have a business day of the month began, will produce a large number of visits, I need expansion, how do? This is the simplest scenario, after we use containerized, as a service deployment in PaaS, the upper deploy an in-house agency, the two sides can point to an external load.


Editor's note:
This article is based in China Life Zhang Qingnan Rancher on June 20, 2019 held in Beijing in the third container enterprise Innovation Conference (Enterprise Container Innovation Conference, referred to as the ECIC) made a speech on finishing. ECIC this scale, 17 were set up throughout the day keynote speeches, attracted nearly a thousand container technology enthusiasts to participate, more than 10,000 spectators watch online. You can read more articles in the General Assembly speech Record Rancher public number.




Guess you like

Origin blog.51cto.com/12462495/2423751