中国人寿如何基于容器搭建金融PaaS云平台

中国人寿的容器使用已经比较深入了。开发团队Java类的应用基本全部在开发测试云上进行了容器化，这占中国人寿总应用数量的一半以上。在生产云环境上，从2017年底开始，我们先将内部应用往生产云环境上搬；2018年6月一些对外的业务应用也陆续完成往生产云的迁移，目前有两个对外业务应用已经跑在生产云环境上。

在云规模上，目前中国人寿整个的云规模有服务器160多台，云化的、容器化的应用有94个，运行托管的容器有1700多个。

重点说一下网络和存储，中国人寿在网络和存储方面的选择，在不同云环境上有不同的考量，开发测试云和生产云是不同的。

在存储方面，中国人寿在开发测试环境上用的是Sun存储，这样的选择和我们的实际情况有关，因为我们在开发测试环境上没有足够的NAS设备。但是中国人寿在生产环境上使用的就是NAS存储了。

相信在不少组织中，研发程序员和运维人员的关系都很微妙，中国人寿也是这样，我们曾面临下面这两个问题。

第一，程序员天性崇尚自由，但原先他写的程序都是局限在一个虚拟机上，程序员经常需要向运维小伙伴要求多加一台机器，他们常觉得不方便、被限制。

第二，是发布新版本的问题。中国人寿很多年前就希望能有快速的版本更新，比如看能不能每月都发一个版本，但后来并没有成功。到了互联网时代，我们对发版的频度要求更高了，而中国人寿这样一个传统企业怎么去发版？到凌晨12点，然后停机。运维小伙伴负责去升级，程序员也得在一旁候着。这么一个长期的工作环境和形式，我们的程序员他们都心情很郁闷。

当时中国人寿也正好想要做X86的改造。我们以前很多应用是跑在小型机上的，包括一些非常重的应用。决定采纳容器、拥抱PaaS，对整个中国人寿而言都是一次重大的变革。我们集结的PaaS实施团队在PaaS、容器这些方面都非常专业且很有兴趣。对中国人寿这样的传统金融企业而言，上一个PaaS并不容易。Rancher产品功能很全面，帮我们快速解决了很多底层的基础的问题，不过我们仍要做很多传统应用的适用性改造。不过最后事实也证明这样一个变革、这样一种投入是值得的。容器轻量、快速、标准，在资源调配与节约、应用快速发布等等方面都解决了我们原先的痛点与困境。

首先，新技术的使用和推广，在用户心理层面存在什么问题？那就是，拍手叫好的多，但真正推广、上线、迁移的时候，大家的实际心理接受程度又不一样。我们怎么有效地解决这个问题？中国人寿的PaaS云平台，所面向的大部分用户都是人寿内部团队。于是我们选择一些热爱并拥抱这个这个系统和平台的人来从头到尾参与这个系统，让接受度高的团队先做出一个样板工程，以最终的优秀成果为标杆进行更大范围的推广，让其他团队的领导和成员看到实际的各项指标，如性能、效率、成本等各方面的成果，以数据和指标说话，最终达到了中国人寿内部大部分团队的应用的容器化改造与迁移。

另外，还有自身能力的提升的问题。毕竟中国人寿是一个传统企业，对新技术的上手和落地可能不如互联网公司那么快。所以我们一方面是加强自身团队的打造，一定要建立自己的容器技术团队；另一方面则要选择借力一些已有的产品和解决方案，不新造轮子，比如选择跟Rancher这样的合作伙伴深入合作，这样就能整体把这个事情给解决。

首先是资源和成本的极大节约。中国人寿正在做新一代整体架构的改造，其中有很多新一代的核心系统。举一个实际的例子，原先，有个团队去做一个新的架构模式的开发，申请了80台虚机，然后发现这远不够他做新一代建设，80台虚机甚至搭不起一个开发环境。当时我们正好启动PaaS项目，就按照这80台虚机的资源，把这80台虚机托管到云上，在云环境下进行新一代核心系统的开发。原先，80台虚机连一套开发环境也托不起来；实际上在云环境下，我们托起了三套环境，资源才使用了2/3。这是一个资源的巨大节省。

我们后来也分析了一下，为什么搬到云上能节省到这么多资源？因为在虚机环境下：第一，团队通常会超配申请资源，超额申请但最后并没有使用到，从而导致了资源浪费；第二，很多时候我们实际使用的系统很多，运行的技术环境不同，有的运行在红帽上，有的运行在Ubuntu上，有的中间件是Tomcat，有的是WebLogic……很多系统不能部署在同一台机器上，必须分开部署，需要的机器资源自然更多。

另外一个就是研发效率的极大提升。就以申请环境这么一个过程为具体例子吧。因为中国人寿有研发中心和数据中心，通常是研发中心向我们架构团队提出要求，架构团队内部讨论审核这个资源要求合不合理；如果合理就给到数据中心的架构团队，数据中心架构团队再内部沟通审核；如果数据中心架构团队觉得要求不合理，那双方再开会来达成共识吧；之后再把这个达成共识的需求给到数据中心的运维团队，运维团队去制作虚机，然后安装软件，然后再交还给我们研发团队。这个流程相当的复杂，一般我们申请一些机器、一些设备，需要大概一周左右的时间才能到位。但也没有办法，规模大、结构复杂的企业团队就是常面临这种问题。

而上了PaaS之后，我们用到了PaaS里面的应用商店，把一些基础的应用打包成镜像上架到应用商店。后续使用时基本上是秒用，需要一个环境的话，基本上一点用商店就能立马拉起来。这是一个上百倍的环境准备效率的提升。

并不是中国人寿的所有开发人员都清楚什么是Docker，什么是PaaS。他不太了解也不需要了解，他可能只是关注一套业务代码的开发。所以我们在帮助应用团队将应用迁到PaaS的过程中，先给应用团队的应用进行持续集成。这个开发团队只要提交代码，剩下的由我们通过持续集成为他们进行代码编译、镜像打包、做PaaS平台的托起，整个过程是不用项目组参与的，而是通过持续集成、通过自动化去完成的。如此一来，有效降低了他们技术上的使用门槛。

以今年6月我们刚上线的对外业务系统为例，它原先面临着非常大的运维问题。为了高可用、非停机升级、灰度发布，我们将这个上线的微服务拆成了两个独立的、相同的栈。最后一共是有70多个微服务，运行着128个应用容器。如果是用传统方法、在非云的模式下，我们数据中心甚至不会同意去接这个项目，因为它的运维难度、甚至光上线难度就非常大。但是PaaS云平台让我们得以解决这一难题，我们在云上用到了应用商店、Rancher的应用发布，只用10分钟就完成了整个系统的上线和128个容器的部署。我们的经验是，如果条件可行的话，微服务架构这种的还是从头新建可能更好一点，碰到的坑可能会少一点。

另一个一定要提的建议就是，一定要跟云相结合。中国人寿的整个过程都是做的持续集成、持续交付，都是用的自动化技术去对接。跟云结合，这个技术是很好的。这是我们这边的一点体验。

我们的Oracle、MySQL都在容器上实现容器化，都能在云环境上运行。在开发环境上，如果说如果项目组急切需要一个数据库，我们会直接用镜像在云上给他托起Oracle、MySQL或MangoDB这些，直接给到项目组。生产环境上，我们没有把数据库运行在生产云上。

因为就中国人寿的情况来看，我们的开发测试云和生产云的定位和目标都是不同，因而策略不同。在开发上是为了方便项目组快速去用，所以提供这个服务。不过我们也知道有不少公司会把所有的数据库（MySQL）都搬到云上。只能说，各公司有各自的情况和需求。中国人寿拆分数据库的需求不那么强烈，我们根据自己情况评估认为，将数据库拆分或者部署在生产云上所花费的成本可能得不偿失。一切决策都是跟不同公司数据量的大小、系统的具体情况有关的。