オーラル/著者：
張Qingnan中国R＆Dセンターの高度なライフアーキテクトのための
エディタ：
二階建て研究所
中国の生命シニアアーキテクト張Qingnan R＆Dセンター
2017年以来、中国の生命は、ライスオフ」、2019年に、「クラウドオフライス」と継続的インテグレーション/持続送達技術、プロセス全体の自動化とアプリケーションコンテナの総合的管理の発展とのPaaSプラットフォームを構築するためのコンテナ技術を使用して開始しましたクラウドは「生産運転、中国の生命管理アプリケーションのコンテナを超える4800の15のキーシステムをサポートしてきました。Applicationコンテナの技術が大幅にすばやくアプリケーションの展開を構築、ソフトウェアの反復サイクル、および弾性伸縮達成するためにアプリケーションを展開するために、コンテナを運ぶための方法を短くする、中国の生命と制御の開発プロセス全体の最適化を容易にします。この記事では、中国の生命のPaaSプラットフォームベースのコンテナを構築する練習を説明しています。
2017年初頭に、建設6月に始まった中国の生命保険クラウドコンテナは、クラウドクラウドのセットアップR＆Dと生産テストを完了しました。ビルドは、大規模な開発およびテストクラウドを完了した後に、クラウドの生産は、実験段階にとどまっています。2017年の終わりまでに、私たちは、ほとんどすべてのJavaクラスのシステムのクラウドで開発され、テストされ、R＆D環境で54のシステムの移行を持っています。
2018年6月、最初の真のビジネス・クリティカルなシステムでは、生産ラインの雲 - 大きな健康プラットフォーム、クラウドベースのシステム完全にネイティブ開発。それ以来、私たちは、他のビジネス・クリティカルなシステムの生産ラインをクラウドに続けます。初期の2019年には、中国の生命の中国生命保険の枝の一部は、PaaSのプラットフォームを使用して開始しました。
今までは、中国の生命保険は、4,000以上のコンテナ、生産雲で実行されている15ビジネス・クリティカルなシステムを実行して、600以上のマイクロホスティングサービスを、主にハイエンドのブレードマシンでは、174台のサーバーを持っています。中国の生命保全プラットフォーム次世代のコアビジネスシステムは、クラウドへの生産ラインで、7月にも、クラウド、統合されたクエリ、バッチジョブや他のサービスモジュール上で完全にされています。また、中国の生命の生命保険APPおよびマイクロEショップシステムのサービス指向のマーケティング担当者の顧客対応の部分も、クラウド上で実行されています。一方、中国の生命の統一されたユーザーのシステムがクラウド上で実行されています。
過去二年以上にわたり、中国の生命のPaaSクラウドは、主にランチャーが比較的安定しているため、安定した動作となっている、と私たちは導入と運用・保守における多くの関連するセーフガードの安定性を行います。
本文的内容分为三部分，一是中国人寿为什么要建设PaaS平台，二是我们是怎么建设PaaS平台，最后是我们如何利用PaaS平台。
为何建设PaaS平台？
中国人寿建设PaaS平台的目标很简单，就是一句话“为了更好地使用资源”。大家都应该知道，字越少，事儿越大。一句话的目标听来宽泛，我们需要分解它，以便于更好地理解。
首先，什么是资源？我们觉得以下三类内容是我们需要考虑的：一是“环境”，程序需要运行起来，就需要使用CPU、内存、磁盘操作系统，这些程序运行起来的需要的最基本的资源就是环境；光有环境你的程序可能还是无法运行，大部分系统的运行还需要依赖中间件，比如web中间件、数据库、缓存服务等，这些是你需要的“技术依赖”；有了这些，你的程序可以运行起来了，但不一定能处理业务。比如我们开发一个出单服务，这可能需要依赖保单服务、支付服务，这些是你的“业务依赖”。
上述三个就是我们需要解决的资源问题，一是环境资源，二是技术依赖，三是业务依赖。
理解了什么是资源，我们再去看什么是“更好地使用”。我们认为它包括两个方面的内容，一是对人来说，能够更便利地使用资源，最好能达到像使用水电一样，想用的时候就打开，想用多少就用多少，用完了就关上。二是对应用来说，能更有效地利用资源，以达到节约资源和降低成本的目的。过去需要花10份的资源才能做成的事情，现在用5份资源就能完成。
用一句话总结中国人寿的PaaS平台，就是：基于“容器技术”和“自动化技术”为“人”和“应用”提供服务，解决“更好地使用资源”问题的“云平台”。
首先，这句话里包含了两大关键技术：“容器技术”和“自动化技术”。
我们先来说说以Docker为代表的容器技术。为什么中国人寿要用Docker容器技术搭建PaaS平台，而非使用传统的虚拟化技术呢？
在这个项目启动之前，中国人寿已经大量地使用基于VMware的虚拟化技术了。那么，在搭建PaaS平台的时候，为什么我们不用VMware搭PaaS，而是用容器来进行搭建呢？主要有两个原因。一是容器的“轻”，这个“轻”体现在各个方面。举个例子，容器是基于进程的资源管理，所有运行的容器共享一个宿主机上的资源，它是抢占式的。虚拟机像是切蛋糕，你把资源分配给它，无论它是否使用，它始终都会占用这个资源，其他人无法使用。容器要比虚机模式节省非常多的资源，我们在后面会用一组数据说明这个问题。
第二个原因也非常重要：容器是以应用为中心的，容器一旦启用，启动的是一个应用；而虚机是以环境为中心的 ，当你启动虚机的时候，它为你提供的是一个操作系统。二者之间区别很大。中国人寿PaaS平台的建设以应用为中心。诚然PaaS译为Platform as a Service，但我一直将它当作是APP as a Service去考虑这一问题。
中国人寿使用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的版本。
说完了容器技术，接下来讲第二个关键技术，以Jenkins为中心的自动化技术。
中国人寿的自动化技术主要用于持续集成和持续交付，我们重点谈一下持续集成。
我们认为，容器技术使持续集成技术格外强大。在容器技术之前，持续集成指的是，当代码发生变化，触发Jenkins上的一个Job，将程序编译打包后，发布到一个固定环境的固定中间件上，让它跑起来，你所能做的就是能让代码的变动触发程序的变化。而有了容器技术之后，你就能做到当环境变化后，通过触发持续集成搭建新的环境；当中间件依赖变化后，通过触发持续集成构建新的中间件；当业务应用架构变化后，例如从一个应用变成了十个应用，还是可以通过触发持续集成拉起一套全新的应用体系。这点非常关键，因为我们刚才说了，我们想解决的问题是环境依赖、技术依赖和业务依赖，现在通过容器技术，通过docker-compose文件结合持续集成，我们基本可以做到自动获取任何资源了。这是第一个关键点。
第二个关键点是持续集成使容器技术在中国人寿这样的企业广泛推广，它大幅降低了技术人员的使用门槛。中国人寿有各种产品、不同的团队，并不是所有的开发人员都有意愿去学习和掌握什么是PaaS、什么是Docker、什么是镜像、怎样做部署。但我们又希望所有人都能把容器用起来，那该怎么做呢？在公司内部推广的时候，每一个需要对接进来的系统，我们都会让PaaS团队为这个系统实现持续集成。持续集成将代码编译、构建镜像、镜像更新、应用商店等等全部自动化。如此一来，对研发项目组、对开发人员而言，他的工作没有发生任何大变化，只需更新代码即可，PaaS的使用均由持续集成自动化执行。
我们的服务对象包括两类，一类是“人”，一类是“应用”。我们希望为“人”即项目经理、开发人员、运维人员提供研发运营模式上的革新，对“应用”提供微服务架构、无服务器架构等架构模式上的革新。
中国人寿PaaS平台旨在解决“是否更好地使用资源”的问题。我们如何判断是否更好地使用资源呢？我们可以将它量化为三项，即：是不是省时了、是不是省事了、是不是省钱了。
中国人寿有一组数据，它并非整个平台的使用成果，而是中国人寿的一个分公司在平台迁移前后的数据成果，我们将过去部署在虚机上的服务器和部署在云上进行了前后对比。
上图是平台的资源使用情况和效率提升情况。资源之所以节省，是因为容器基于争抢资源的模式，能极大避免虚机时代资源占用浪费的问题。效率的提升，则是由于持续集成极大地提升了研发及资源获取的效率。在中国人寿，我们申请设备需要走流程进行审批，这个过程会花费大量的时间，现在可以通过持续集成实现“自管理”，开发人员在需要资源时，通过触发持续集成自动获取资源。
如何建设PaaS平台？
上图是我们在2017年立项时画的，这张简单的图指导了中国人寿两年左右的PaaS平台建设工作。
我们认为，中国人寿需要有一款自己的PaaS产品，我们要基于这个产品搭建两朵云，一朵是开发测试云，一朵是生产云。两朵云有不一样的定位。开发测试云解决的是资源利用率、管理成本和研发效率等问题，生产云主要解决微服务托管、快速部署、交付一致性、弹性伸缩等问题。
两朵云对应用的要求也不一样。对于开发测试云而言，所有你能搬上开发测试云的应用，我都能帮你做容器化和自动化，你享受开发测试环境带来的种种优点即可。但对于生产云，我们有更高的要求，生产云的应用必须是云原生的应用，必须做好微服务化改造，技术人员自身还必须知道如何利用云上的优点。所以两朵云对应用的要求是不一样的。
我们在开发测试云上做了持续集成，通过持续交付打通两朵云，两种云结合为DevOps夯实了基础。
上图是我们对产品的定位，主要关注四个部分：第一部分是通过Rancher进行容器管理；第二部分通过Harbor进行镜像管理；第三部分是通过Git进行应用商店管理；最后一部分是是基于Jenkins搭建CI/CD，开发运维一体化。
这四部分明确之后，我们通过中国人寿的稻客云门户集中管理底层云生态，再通过稻客云门户对接用户管理，统一权限、统一用户，进行界面上的集成，让用户在一个界面上完成所有事情，以及实现监控、日志等功能。
除此之外，稻客云门户还可以实现两个比较有意思的功能，一是多租户，一是快速部署。Rancher 1.6版本里没有基于用户层面的多租户隔离，它基于环境进行隔离，所以如果一个环境上很多用户，上层运行的应用能互相看到，和我们理解的多租户隔离有所区别，所以中国人寿自行开发了多租户隔离功能。
快速部署是一个将发布流程极简化的功能，它屏蔽了持续集成以及PaaS、Docker的过程。我们先前有个情况，分公司的同事希望运行自己的应用，但又不想关注PaaS、Docker、容器包括持续集成等技术。为了解决这个问题，我们开发了一个界面，让分公司选好应用程序，点击上传，再点击启动，我们在容器上运行应用程序，再将容器IP返回去，就完成一次快速部署。
中国人寿在北京和上海各有一个数据中心，在上海和北京各部署了一套生产云，开发测试云只部署在北京。每朵云的管控节点均为独立部署，每个管控节点托管很多个不同的环境。当中有一个关键点，即环境的划分。一个环境里托管的主机越多，共享的应用就越多，从而规模效益越好，资源利用率也越高。但这样会使隔离性降低，当系统出现问题时，运维难度将呈几何级上升。
因此，在开发测试环境中，我们追求尽量扩大规模效益，在开发测试环境划分了5个大环境，所有机器部署在五个大环境当中，大家混合使用，资源利用率很高。但在生产环境中，我们非常谨慎，一个关键系统独占一个环境。正如我先前所说的：两朵云的定位不同，想解决的问题也是不同的。
如何利用PaaS平台？
前文曾经提到，中国人寿PaaS平台的服务对象一类是“人”，一类是“应用”。“人”指的是项目经理、研发人员、运营人员，“应用”指的是微服务框架和无服务架构的支持。
对于项目经理而言，我们希望为他提供的变革是自服务。过去，项目经理的主要职责是找各种能够提供资源的对象，获取开发所需的资源。现在，我们希望对他进行变革，利用PaaS平台，让他通过平台、应用商店、持续集成实现自助服务，提升项目经理获取资源的效率。
对于开发人员而言，我们希望达到自动化。刚才前面几位嘉宾在分享的时候，提到了开发人员专注于业务逻辑开发。我们认为开发人员要做的最基本的事情是开发代码、提交代码、测试、查看，开发人员只需要做这几件事情，剩下的活动比如编译、构建、部署、测试等完全通过持续集成、自动化脚本来实现。
我们通过持续交付，为运维人员提供软件交付上的变革。我们在开发环境专门找了一台开发交付机部署Jenkins，这台机器打通了跳板区的镜像仓库，为每一个在云上提交的项目实现交付任务。交付任务完成后，我们将Jenkins上的用户权限提交给应用的应用经理及应用团队。当应用团队需要交付时，先将代码提交到交付机器上，再在Jenkins上执行交付任务，交付的Jenkins会抓取代码，打包编译、构建镜像，将发布镜像推到跳板区的镜像仓库，再由生产的运维同事在应用商店里选取应用，点击部署，一键部署后将整个应用从Rancher上拽起来。
文初提到中国人寿PaaS云平台上线的第一个业务应用——大健康平台，拥有45个微服务，运行200多个应用容器。因为大健康平台是第一个上线的业务应用，我们对它进行了测试，从开始交付到运维人员现场部署一共花了8分钟。假如我们手工按传统的方式去部署，200多个应用预计要花2周的时间。
中国人寿PaaS平台的微服务主要有三个场景。第一个场景是应用完全微服务化，全部应用均跑在容器上。我们为这个应用拽取两个应用栈，让它能实现蓝绿发布与灰度部署，这两个栈是一样的，栈里面的微服务通过服务名进行通信，这一功能由Rancher实现。对外提供服务则是在Rancher界面上配置一个内部代理，将内部代理固定到主机，在PaaS环境外配置一个外部代理，指向两个栈的内部代理。
第二个场景就是部分应用容器化，一个应用在进行微服务改造后，一半跑在传统环境上，另外一半跑在云上。这种情况建议引入两个关键组件，应用网关和服务发展中心。
非常に重要なポイントは、我々はランチャー1.6が提供するフラットなネットワークモードを使用し、あります。このモードでは、各容器は、その外部の環境で、同社の他の施設のIPインターワーキングを実際のIP、IPおよびPaaSのを取得します。このような設定後、それをアプリケーション三マイクロサービスがクラウド上に展開されている分割、3つのサービスは、サービス登録を介して、IPを介して直接マイクロ登録ディスカバリサービスセンターに登録し、従来のアプリケーション上のマイクロサービスとの間で通信されているものとしますディスカバリーセンターが直接通信することができます。クラウドアプリケーションは、マイクロサービスやレガシーアプリケーションへのアクセスを必要とする外に、あなたは、上記のアプリケーションゲートウェイを介してアクセスすることができます。
最後のモードは非常に簡単です、それはマイクロサービスではないかもしれないが、それだけで通常のアプリケーションで、クラウドで展開する必要があります。例えば、私は、月の営業日が始まってい訪問を大量に生成されます、私はどのように行う、拡張が必要ですか？私たちが繧、上側のデプロイAN社内代理店でのサービス展開として、コンテナを使用した後にこれは、最も単純なシナリオで、双方は、外部負荷を指すことができます。
編集者注：
この記事は、北京で開催された2019年6月20日に中国の生命張Qingnanランチャーに基づいて 第三の容器企業イノベーション会議 （エンタープライズコンテナイノベーション会議、ECICと呼ぶ）仕上げで演説を行いました。ECICはこのスケール、17日の基調演説を通じて設定したが、参加することはほぼ千コンテナ技術の愛好家を魅了し、10,000人以上の観客がオンライン観ます。あなたは、総会のスピーチを録音ランチャー公共数でより多くの記事を読むことができます。