需求开发应用部署“一条龙”，平安云如何加速容器场景落地

2019 年 6 月 20 日，由 Rancher Labs（以下简称 Rancher）主办的第三届企业容器创新大会（Enterprise Container Innovation Conference, 以下简称 ECIC）在北京喜来登大酒店盛大举行。本届 ECIC 规模宏大，全天共设置了 17 场主题演讲，吸引了近千名容器技术爱好者参加，超过 10000 名观众在线上直播平台观看了本次盛会。

来自 Rancher、阿里云、百度云、平安科技、中国联通、飞贷金融科技、中国人寿、SmartX、华泰保险、厦门航空、JFrog、新东方、Cisco 等近 20 家企业的技术负责人出席了本届 ECIC，在大会现场带来了关于企业容器项目实践经验的精彩分享。

平安科技 CTO 及总架构师方国伟

大会现场，平安科技 CTO 及总架构师方国伟提出，近年来在云计算赛道上，容器因为它轻量、灵活、易管理、易迁移等特性被企业广泛采用，如一辆高速前进的方程式赛车脱颖而出，成为了企业云化历程中的大势所趋。在未来 3 年，平安云将会重点投入容器建设，解决容器快速交付的难题，并且进行微服务的支撑。

以下是平安科技 CTO 及总架构师方国伟的演讲实录：

大家上午好！谢谢梁胜博士，谢谢 Rancher 邀请我们在企业容器创新大会上分享。

先和大家介绍一下平安科技的容器应用情况，我们从 2014 年开始关注容器技术，2015 年开始构建容器相关的产品，也从 2015 年开始和 Rancher 接触以及合作，是 Rancher 在国内最早合作的企业之一。刚才梁胜博士在介绍 Rancher 产品的时候，提到了平安云支持容器服务，可以通过 Rancher 进行多集群管理。

平安云对外提供“2+1”的云服务。公有云和其他公有云平台是一样的，对外提供服务，用户自己注册，审核之后变成平安云的客户，这就是公有云。第二部分是专有云，专有云和平安整体发展领域有比较大的关系，平安集团专注于五个生态圈，金融、医疗、智慧城市、汽车和房地产，我们针对各个垂直领域建立独立的物理隔离的云平台，这就是我们的专有云。

公有云和专有云在技术架构上基本上是一样的，区别在部署、安全隔离和法规征信方面。比如金融云，央行会有专门的金融云的认证规范，专有云平台要满足这个规范之后才可以将自己称作为金融云。

“2+1”中的 2，一个是公有云，另一个是专有云，专有云按不同行业划分，政府客户基本上就会将应用部署在政务云上。那“2+1”中的 1 就是私有云，国内大企业比较倾向于在自己的数据中心内部署私有云平台，平安则为他们提供解决方案，让客户在自己的数据中心里构建和平安专有云、公有云类似的云平台。

私有云整体架构和公有云、专有云类似，区别在私有云在产品上面公有云的子集，绝大部分客户并不需要一个特别复杂的云平台在企业内部运行。

平安云和其他云的区别在哪里？我们最大的区别在于我们对外提供 Full Stack（全栈服务），在我们前面提到的五个生态圈领域，每个生态圈领域有专门的公司构建 SaaS 服务。有些云平台厂商不提供应用，有些云平台厂商上不碰应用，但是下不碰数据等自己的市场策略。

平安整体的战略思路在于我们整体业务层面能力比较强，我们有大量 SaaS 应用，比如一账通，这是一款针对金融领域的 SaaS 平台，我们对外提供的服务 Full Stack 从底下的 IaaS、PaaS 到上面的 SaaS，以整体的形式为客户提供解决方案。容器在这里面的角色就非常重要了，因为容器可以跨平台，在私有云和专有云上我们可以进行多云管理，这些都是容器在当中的价值。

接下来，我会讲一下我们怎么看到容器在云平台内的作用以及我们做的一些事情。前面也提到，我们从 2014 年开始关注容器，2015 年开始容器相关的产品，当中很重要的原因就是我们觉得容器可以改变云计算的多个方面，尤其是在计算服务提供方式上。我列举了一些容器的特点，它更加灵活，也可以和底层资源进行耦合。

这里面有一个非常值得思考的问题，就是为什么谷歌会花费这么大力去做 Kubernetes？并且在整个开源界去推广这个事情？我觉得最重要原因是谷歌整体在云上落后于像 AWS 这样的云厂商的，但是 AWS 最重要的服务是计算服务或者是它大部分的收入都与计算相关，它的计算服务是基于虚拟化的云主机来进行的。谷歌作为一个后来者，要想办法追赶 AWS，如果还是传统的模式，追赶上的可能性就很小了。如果谷歌要追赶上 AWS 的话，它一定要改变游戏规则，容器可以帮助它，容器不一定能够超越，但这是一个很好的机会。

对于平安云来讲，我们非常看重容器也是基于类似的原因。我们相信在几年之后，越来越多的应用会变得 Cloud Native，越来越多的用户会采用像微服务、Istio 这样的方式来进行部署，容器可以很快地满足客户部署上的要求。这就是为什么我们花很多力气在容器服务上，用 Kubernetes 来构建产品的原因，这是大的背景。

平安云在容器部署方面是怎样的呢？我们是紧紧围绕客户的需求来构建产品的。在梁胜博士演讲的时候也提到，我们实际使用容器的时候，用 Docker 或者是 Kubernetes 还是会产生一些问题的。不同的客户需求不一样，有些开发人员对 Docker 和 Kubernetes 很熟悉，他可以轻松地管理自己的 Kubernetes 集群。也有一些开发人员不太喜欢底下的 pod、端口等，他觉得只需要了解业务需求，写代码就可以了，无需关心底下容器相关的事情。所以不同的开发人员、不同客户对象需求是不一样的。

我们在平安云上提供了不同级别容器相关的服务，最底层毫无疑问的是 I 层的一些服务，从底向上我们会有 Kubernetes 集群，叫 EKS，其上面我们会有 Container Service，再往上我们会有 PaaS 平台，最上面是 DevOps 服务。这就是平安云上容器相关的几大服务。

EKS 概念上很简单，这是一个 Kubernetes 管理服务，梁胜博士也提到，无论我们在公有云还是私有云上，我们都部署一个 Kubernetes，当然你可以利用云主机自己去部署一个 Kubernetes，但是云上面提供原生的 EKS 服务，它与云上面的资源，无论是底下的各种资源还是上面的像日志服务、监控服务等，都可以比较快速地通过 API 把服务利用起来。对 Kubernetes 比较了解的开发人员或者是运维人员而言 EKS 是一个比较好的选择，Kubernetes 的 API 完全一样，如果他喜欢用 Kubernetes 命令来管理 K8S 服务也是完全一样的，相对而言比自己去安装一个 Kubernetes 简单一些。这是第一类基于 Docker、Kubernetes 的服务，你可以快速拿到 K8S 集群，构建自己的容器服务。

第二个产品我们叫做 Container Service，对于很多用户来讲，他不想关心 Kubernetes，也不想成为一个 Kubernetes 专家，他想拿到一个 Container，通过 Container 去部署他的应用。对于这一类客户来讲，我们提供 Container as a Service 即 CaaS 服务。你不用关心底下 Kubernetes 的东西，由平安云的后台服务和运营团队帮你管理集群。你拿到不同 Container，就在上面直接部署应用。当然我们也会管理相关的镜像市场，提供快速的镜像上传、下载、推拉等，也会应用编排一些功能，对客户来讲就是 Container as a Service。

我们内部在底下换过几次 Container Service 的技术，现在用的是 Kubernetes，这些对客户来说都是透明的。因为客户关心的是 Container，拿到的也是 Container，底下你用什么样的方式来做编排他都是可以接受的。我们以前用过 Mesos，后面把 Mesos 换成了 Kubernetes，这对用户来说也是无所谓的，所以这里面最大的区别在于用户关注的是 Container，他不关心编排，这是我们一个第二层级的，对不需要关心 Kubernetes 的用户来讲，他可以使用 CaaS 服务来进行应用部署。

第三类服务就是我连容器都不想管理，有没有这样的服务呢？正如梁胜博士在前面提到的，他讲的是 Rio，他们想构建一个MicroPaaS平台。这个有点像是平安云构建的 PaaS 服务，我们目前的产品叫做 APaaS，APaaS 的概念来自于 Gartner，Gartner 很多年前有份报告是分析平台层 Platform Service 里面到底有哪几类服务，它当时就把 PaaS 分为两大类，一类叫做 APaaS，一类叫做 IPaaS。APaaS 就是我们这边在做的，IPaaS 是 APaaS 之外的一些集成服务比如 MQ、认证等。这些服务都是平台层的，它统一放在 IPaaS 里面。刚才梁胜博士讲的 Rancher 做的是一个微小的 Micro Platform Rio。我最初在微软做 Windows Azure，一开始定位在 Platform Service，后来发现 Platform Service 有些问题，后来转到 VM 重新进入 IaaS 跟 Amazon AWS 是一样的。

这是我自己在工作这么多年的体会，为什么 APaaS 以前不太成功呢？原因在于 APaaS 构建方都是做技术架构的人，这实际上是一个很大的误区。APaaS 真正的用户对象是开发人员，在构建 APaaS 的时候，如果有开发人员参与的话，构建的成功率会高一些。因为他知道自己的痛点，知道自己想要什么，而不是运维人员、底下技术架构人员拍脑袋构建一个 Platform Service。所以平安构建 APaaS，我们是由应用架构团队牵头构建一个 APaaS，目的在于在你部署应用的过程中，你无须关心 Container，你只关心代码，通过代码可以在 APaaS 平台上进行部署，快速建立应用程序的部署。好处在于进一步降低容器相关服务的使用门槛。

容器我们是 2014 年开始关注的，现在已经过去了好多年，虽然我们都知道容器应该是指数型发展，但实际上容器整体的发展并没有我们预期的快。当时我认为容器肯定可以快速替换大部分的云主机，但实际上这件事情没有发生。将来容器发展速度肯定非常快，但现在来说，它没有我们预期快速增长的原因是因为在容器的使用上对于开发者而言过于复杂，我们希望通过 APaaS 平台，进一步降低使用门槛，底下容器更透明一些，让开发人员无需过多关心容器本身的细节。

这一目标应该是可以做到的，最开始我们想在 Windows 上构建一个 Platform Service，当时没有 Container，它是基于 VM 来构建的，这也没有问题，它只需要一个快速的资源分配力度和分配的机制，就可以实现了。在使用容器之后，我们现在回过头来做 APaaS，我觉得成功率会大大提升。

在做 APaaS 的时候，一个非常重要的问题在于对应用本身的服务的管理，对应用管理，对微服务本身的管理，包括对应用配置管理，这是很多时候做底层基础架构技术的人不容易看到的事情。如果我们做底下架构的服务构建的时候，大家会想到 CMDB，CMDB 可以管理技术架构的很多配置，但是如果你把应用部署起来之后，它也需要应用配置来把应用服务管理起来。这就是在 APaaS 构建里面非常重要的一个环节。只有把应用配置相关的事情构建好了，整个 APaaS、整个应用发布流程才会比较顺畅地构建起来。这是我们构建的第三个层次 APaaS。

接下来的 PAME 也是一个平台层的服务，这个平台层的服务在过去一两年也是非常重要的服务。最近一两年人工智能非常热，人工智能内有大量的机器学习、深度学习的需求。机器学习、深度学习需要大量的 GPU，GPU 在这方面做得效果还不错，当然如果有专门针对人工智能的芯片也是非常的好，但目前使用比较多的还是 GPU 的方式。为了解决大量数据训练的需求以及一些推理的需求，我们构建了一个 PAME 平台。

PAME 平台和容器的关系在于它的资源分配是基于容器来进行的，底下是 CaaS 容器服务，容器服务底下的硬件上面有 GPU 支持，所以我们构建了 PAME 平台来简化机器学习使用。除了计算资源之外，在深度学习平台上，非常重要的一点在于怎样去管理数据，这是非常重要的。深度训练的数据从哪里来、怎么存储、怎么进来？模型导进来之后怎么去管理？这一切都是 PAME 需要解决的问题，所以 PAME 本身的定位也是 PaaS 的一种，它不是 APaaS 平台，它是在平台层的另外一类服务，跟容器有紧密集成的一类服务，叫机器学习平台。

机器学习平台的原理很简单，前面我们讲 EKS 的时候，里面是个 Manage EKS Service。在 PAME 里面，用户可以选择不同的学习框架，如果用户有 Tensorflow，我给他快速构建一个 Tensorflow 平台，他可以学习，相当于我们可以快速把机器学习框架包装起来，同时加上在机器学习里面需要用到的数据导入导出模型管理这样的一些需求整合在一起，作为服务提供给客户。

对于用户来讲，不用像以前给 GPU 的服务器或者 GPU 的云主机，这些东西申请之后比较庞大。PAME 是基于容器的，所以资源用完了，你就可以关掉退出，资源消耗收费就是云计算的 pay as you go。这就是我们的第四个服务，叫做 PAME 服务。

我们构建了很多服务，但无论是 APaaS 也好、PAME 也好，我们的目标还是在上面部署应用，应用本身的管理需要 CI/CD 平台、DevOps 平台来做这个事情。我们构建了神兵研发管理平台，这相当于平安的 CI/CD 和 DevOps 平台。

这个平台有几个特点，第一就是在整体的项目管理周期里面，从项目管理到代码管理，到需求故事，测试、版本迭代、敏捷看板所有这些功能都集中在一个产品里面。这是从研发管理流程上看，它可以部署到前面的我们讲到的平台，无论是 CaaS 还是 APaaS 也好，都是打通的。

第二个就是在所有的环节里面，我们从研发管理的角度来讲，你有流程吗？比如说要不要经过一些测试，要不要扫描，像这一类的内容我们直接就加入到流程里面，该做镜像扫描就做镜像扫描，该做安全扫描就做安全扫描，该做测试就测试。好处是什么？就是我们公司所有研发过程都能看的非常清楚，这个系统在我们集团内部月活超过 26000。

我们有一个数据平台，我们重点加强了这部分的内容，很多企业不知道研发人员的产出是怎样的，我相信很多做研发管理的人都会有这样的困惑，你不知道人员的产出是怎样的，你也不知道假设一个部门需要扩编了，申请的 10 个额外编制是应该给还是不给，甚至你不知道他的开发效率是怎样的。

我们希望做的是基于数据的管理。平安近几年来一直强调基于数据驱动的管理，所以我们从研发管理的角度提供了一个数据平台，可以非常清楚的看到每个研发人员递交了多少代码？代码的质量怎样？所有这些都是有数据的，能帮助你提升整个研发管理。不仅仅关注他的效率，还可以关注代码质量，员工的工作情况等等。每个需求从提出到上线，整体的迭代时间多长，开发人员的工作情况等等，这些都可以从一个平台非常好的反馈出来。这是从神兵的角度、研发管理角度可以看到的。

除此之外，我们还做了一个微服务框架，光有容器还不够，你还得有运行的东西，现在比较流行用微服务的方式构建应用平台。我们在云上专门做了一个框架 PAFA-CLOUD，它是平安整体框架的方式。我们之前有 PAFA-1，PAFA-2 到 PAFA-5，这个版本我们不叫 PAFA-6 了，直接命名为 PAFA-CLOUD。原因在于我们专门以 Cloud Native 的方式构建这一框架。

那么，它的基本概念是怎样的呢？在企业内部，我的团队大部分开发的应用都是底层技术框架的应用，但是对大部分公司来讲，它的开发人员都是依赖业务来做开发的。我们知道，业务应用开发人员关注的点不完全在技术上面，更多的还是集中在业务逻辑上。所以大部分开发人员时间都放到怎样把业务需求分集成业务逻辑，然后依靠代码来实现。他也不需要花太多时间进行用户认证、日志归结、收集等等，我们希望他花在这上面的时间越少越好。

这是我们整体框架的图，我们完全基于 Spring Cloud，然后加了很多定制的内容。上面有 API 网关，底下有服务治理平台，最下面是基础设施。无论是 CaaS 也好，还是 DH、ECS、BMS，这些都是底层资源。对用户来讲，他只需要关注业务服务就好了。像分布事务、灰度发布、分布调度，每个应用、每个项目都需要做的事情，我们都需要通过框架的方式来实现，大大降低了每个项目组开发时的非业务负担，提升了业务应用的开发效率。

还有一方面是和 PAFA 相关联的事情。比如说你有神兵，日志有日志云、消息有消息云，这些东西在里面做了很多对接。这表明什么呢？我们在企业里边如果要逐渐构建，大家现在都很热衷于讲中台的概念，那在 PAFA 里面就可以慢慢地把共享的服务做起来，你的应用开发就会变得越来越快，你可以依赖的服务越来越多，你不需要每个服务、每个项目都自己做，如果每个项目都是重新造轮子，这样你的效率就会大大降低。

我们整体的理念是怎样的呢？我们那整体的理念就是希望行成一条龙的方式，实现把应用开发、流程进行整体管理。一条龙的意思就是，如果你要从业务写代码开始，我为你提供一个整套的框架。你需要去开发，去测试，去部署，我们就有神兵 DevOps 平台来做这个事情。部署到容器、云主机等等底下的相关资源，你可以选择 APaaS，也可以选择容器相关的服务来部署你的应用。

这样一连串的流程，我们把它叫做一条龙流程。我们照顾到了从应用架构设计开始、到开发测试、到部署相关的这一切。这是我们在平安推的一条龙流程，可以极大地提升整个应用开发效率。

我们过去几年从各个层面上和 Rancher 都有比较多的合作，在这里分享的是与 Rancher 联合探索应用容器化实践。我们知道，在之前的大部分应用都不是用容器方式去构建的。Rancher 在容器方面做得比较领先，而且一直非常专注地做容器相关的事情。我们和 Rancher 合作，把大部分我们内部常用的服务进行容器化包装、打包，可以作为服务化部署。无论是基于 Helm 还是基于 Operator 的方式，把它构建成不同的服务。

我们认为这是将来非常重要的趋势。公有云上，你可以用去虚拟化的云主机运行容器，另一方面，我们也做安全容器，容器下面加一个很薄的虚拟化层进行隔离等等。按照这个趋势看，越来越多的隔离应用会以容器的方式运行。这就是为什么我们和 Rancher 合作，针对常用的服务进行服务化改造，方便用户快速地获取服务。云上的服务非常多，有些服务是云平台上直接提供服务建设的，有一些通过 Managed Service 提供，还有一些人通过容器化的方式来实现。

最后要分享的是我们对容器本身的判断。从一开始的时候我们分析容器的起因，谷歌之所以要花很大力气做 Kubernetes，我相信它是想对 AWS 发起冲击，通过改变游戏规则来实现弯道超车。我们也看到越来越多的应用 Cloud Native 方向发展。我们认为，这个事情对平安云的向前推进是非常有好处的，所以我们愿意花很多力气、投入很多资源在容器方面，包括容器延伸上来做一些事情。

除了我们传统的云上服务之外，我们现在做的另外一些事情跟容器的关系也非常密切。比如物联网，刚才梁胜博士提及物联网在 IOT 里面，它并不仅仅是简单的端到云，中间还涉及边缘。尤其是将来 5G 越来越多，设备越来越多，云上的性能越来越好，整条链从端到边缘到云上，容器的作用会越来越大。

为什么呢？因为我们不希望是从端到边缘到云上面，它的部署模型是不一样的，或者运行环境的差异性很大。容器天生有一个非常好的特性，它底下是松耦合的，或者它解耦比较好。这个特性在我们构建整套体系的时候，从端到边缘到云体系当中，使整个 Programing Model 相对比较统一。比如大边缘上，我用 Kubernetes，小边缘上，我用 K3S。大家都是在整个体系里面，应用可以在不同的点切换，当然大家知道,小边缘它更靠近 Devices，大边缘它更靠近 Cloud。

我们在区块链上尤其是平安的壹账链上做得挺不错的，在部署的过程中，我们也是基于容器实现的。人工智能识别中我们很多的服务也是可以通过容器的方式来做。私有云也是一样的，为了更好地降低耦合度，加快应用部署。我们也相信越来越多的私有云场景里有容器相关的技术。

我们的私有云场景我再简单地解释一下，我们整体有一个 PA-CMP，我们叫壹云管，这是个多管管理的体系，底下的产品我们是可以自选的，用户可以选择云主机，那他就只有云主机产品在多云管理里面。比如用户之后需要容器，那就是增加容器服务在多云管理里面。用户可以选自己想要的产品组合成一个他私有的解决方案。

我们认为容器相关技术对大部分企业、大部分云厂商有非常大的作用，我们希望和 Rancher 以及更多的厂商合作，构建好整体的服务。我今天的演讲就到这里，谢谢！