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

6 月 28 日，Rancher Labs 在北京举办了Container Day 2018容器技术大会。在大会上，Rancher Labs CEO 及联合创始人梁胜博士、中国人寿研发中心开发五部副总经理王川、技术处高级经理郑晓勇、开发五部云计算架构师张青南、ZStack CEO 及创始人张鑫进行了一场圆桌讨论。

本文整理摘取自圆桌讨论环节的内容，由中国人寿的嘉宾分享了中国人寿使用容器技术、搭建金融 PaaS 云平台的心路历程，以及存储、网络、CI/CD、微服务、数据库拆分等具体技术细节和经验。

中国人寿容器使用情况如何？

中国人寿从 2016 年底开始做技术调研，于 2017 年正式开始利用容器技术搭建金融 PaaS 云平台，用了半年多的时间完成了两朵云环境的搭建， 一朵是开发测试的云环境，一朵是生产的云环境 。中国人寿在开发测试云环境里做了持续集成，两朵云之间通过持续交付进行打通。最后又用了半年多时间在内部进行推广。

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

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

具体技术细节的补充？

中国人寿两朵云的最底层的容器调度与管理都是使用了 Rancher 平台。Docker 用的是 17.03 的版本。主机环境之前也尝试过使用红帽，最终迁到了 Ubuntu 上，使用的是 Ubuntu 16.04。

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

在网络方面，中国人寿在开发测试环境上，使用的是 IPsec 管理的 Overlay 网络。选择 Overlay 网络是因为，虽然它可能架构比较复杂，但最终使用时管理起来会比较容易，我们不用额外去给它准备 IP 资源。在生产环境上，我们使用的是扁平网络，扁平网络的一个好处在于，它的 IP 跟整个大网里的 IP 是互通的。存在的问题是我们要提前规划网络，规划 IP 资源的使用。

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

中国人寿最初为何决定采纳容器、搭建 PaaS？

我想来参加 Rancher Container Day 大会的在座各位肯定都是容器、PaaS 的专家，大家也许会觉得，这个问题的答案不是显然的吗？容器、PaaS 能带来这么大好处，当然需要去建一个金融的 PaaS 平台，不是吗？但对中国人寿这样一个传统的金融国企而言，使用容器搭建 PaaS 平台，其间也是有一些心路历程值得分享的。

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

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

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

虽然我不是什么心理辅导师，但是我觉得我们应该致力于给程序员创造一个良好的研发生态环境，实际上这也确实是很重要的。

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

有哪些挑战、哪些经验可以分享？

我们刚刚提到了 【变革】 这两个字，的确，在中国人寿 PaaS 云平台的搭建过程中，我们遇到过一些挑战，其中有两方面我想在此分享。第一个是用户心理层面的问题，第二个是中国人寿自身能力提升方面的问题。

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

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

容器和 PaaS 给中国人寿带去了哪些实际益处？

中国人寿使用容器技术、搭建 PaaS 平台之后，两大最显著的益处，一个是资源和成本的节约，一个是研发效率的提升。

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

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

而使用容器之后，情况则不同了。针对第一个问题，他只有在真正使用时才会占用资源，不用到的时候资源并没被预先占用。针对第二个问题，因为容器进行了一层又一层隔离，并且容器是一种标准化打包，所以在环境上也可以更加灵活，就不存在虚机那种强制要求分开部署的情况。这就是容器给我们带来的资源上的巨大节省。

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

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

持续集成

另外还有一点值得分享，中国人寿在做 PaaS 的过程中，不只是用了容器技术，另一个很重要的是自动化技术。

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

同时，完成了自动化的持续集成这个过程之后，也能大量地、快速地提升他们的研发效率，起码在集成效率上的提高非常大。拍个脑袋说个数，原来的集成可能需要 30 分钟，从代码编译、到检查、到部署；而通过持续集成去做的话，我们最终能在 5 分钟之内完成整个流水线的工作，大概是这么一个提升。

微服务的拆分或改造经验

我们觉得做微服务，最简单的方法是从头到尾来做，在最初新建系统的规划阶段就按微服务架构去做。我们基于微服务架构新建系统时，使用的是 Spring 全家桶，即 SpringBoot、SpringCloud 这些。

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

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

数据库拆分

中国人寿没有做额外的数据库拆分，因为目前这个云对数据库拆分起不到太大的帮助。若是新建系统，我们进行原生设计时就会考虑好数据结构。原有的老系统，目前我们碰到的正在拆的系统都还没有从数据层面去下手。

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

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