基于 DevOps 理念的私有 PaaS 平台实践

作者简介：

刘亚丹 YY 互动娱乐事业部运维经理

负责YY互娱事业部的基础运维平台建设管理工作，8年互联网运维从业经验、经历服务器从数百到数千的规模，走过从手工运维到自动化平台化运维方式转变，积极拥抱云计算大潮，推行 Web 类业务迈向虚拟化云化的基础设施，致力于 PaaS运维平台的 ITIL理念与 DevOps 理念融合、对云形态下的互联网企业运维平台建设管理有较深理解和实战经验。

前言

云计算从2006年 AWS 推出 EC2开始，至今已经10年，从最开始多数人不清楚云计算为何物，到如今，大到 BAT等互联网公司,传统金融、证券、制造业企业，小到初创企业，都在积极推进云计算战略，以此加快业务交付效率，降低成本、提升竞争力。云计算的首要目的是将底层硬件抽象化，向上提供计算资源，存储资源，网络资源。

其关键核心是提高了IT业务交付效率，使企业花费更少的钱，办更多的事情，同时满足质量，安全的需求。在云计算大潮下，企业内IT部门，需结合自身的业务特点，思考提供怎样的云计算基础设施服务（IaaS）,以及基于 IaaS又提供怎样的 PaaS ，才能满足企业对于质量，效率，成本，安全四元组合的最佳要求，是摆在每一个运维从业者面前的问题。

YY 互娱基于 DevOps 理念，并结合 ITIL 最佳实践理念，从13年开始推出自己的IaaS，基于自身条件，推出一套符合企业内部要求的私有 PaaS 运维平台，并在实践中不断的改进完善IaaS，PaaS。本文将系统的从4个方面，分享YY互娱运维团队对于 PaaS 运维平台实践经验及未来展望，希望对大家有一些参考意义。

一、 运维价值体系

说到运维，还得从运维的价值体系说起。运维的价值体系，从四个维度来概括，即质量，效率，成本，安全。这体现的是一个经济问题，是运维部门总结工作时，公司高层能听得懂的语言。我们从事一切运维工作，大到公司运维平台体系构建，小到某项具体运维工作，最终将从这4个维度的数据来衡量，因此，运维工作应该以提高业务的质量，效率为出发点，在成本和安全中寻求最佳平衡点。在云计算的形式下，应当以自动化，服务化等技术手段为依托，数据化，可视化体现运维的价值输出。

二、 运维平台化方式

纵观整个运维技术的发展历程，运维平台化体系建设，我们认为主要有以下3种形式。

1. 面向流程

提供独立的工具子系统，再将工具 API 化，向上提供整合能力。

上面这种运维平台模式，是典型的以 ITIL 最佳实践为参考的运维体系建设。我们从一个常见的业务上线场景说起，来看看这种模式的特点。

假如一个 Web 业务需要上线，需要服务器资源，需求人（开发或者业务运维）需要到 CMDB 查看是否有空闲资源，若有，则到“服务器申请”流程里面提一个工单，经过一个审批流程（至少3个审批节点），拿到服务器。

同样，业务上线还需要数据库，需要缓存，需要 DNS 解析，需要开通权限，需要添加监控等等，需求人都必须到相应的系统提单，才能完成需求。这样的流程体系下，对于需求的管理方是比较好的，各类需求，资源都可以较好的记录以及控制。

但对于核心的业务上线，变更、即面向用户的价值交付，效率很低，业务上线周期长，人力成本高。

ITIL 最佳实践中总共包括六大操作流程五大服务支持流程，流程都包括五大要点：流程目标、基本概念、主要活动、好处与风险，以及关键绩效指标与报表。以流程为导向建设运维体系，在互联网时代本身变化极快，不断试错，追求敏捷高效的目标冲突越来越大。

ITIL 面向流程的运维体系亟需改进，而改进的方向，即面向业务的服务化方向改进。

2. 面向服务

基础组件API 化（IaaS化），向上提供整合能力,再做面向运维的集中信息管理,配置管理，变更管理等。

如上图所示，我们仍旧以一个 Web 业务上线的场景，来进行说明。

面向服务的运维平台，首先需要构建底层资源的 IaaS 化，API 化。有了 IaaS化，我们就具备了提供一个一站式的运维平台的基础能力。在这样的运维平台上，业务上线需要数据库资源，平台提供对应的实例配置套餐，一键创建并返回给用户。

同样，制定一套标准的发布规范，实现自动化部署，业务在发布的时候，从 IaaS 资源池自动分配服务器。其他的资源，如 CDN，域名解析等，同样可以在平台上自助完成。

这样，业务上线的流程，全部以自动化，自助的方式完成。再往前，平台与持续集成，自动化测试平台进行对接，即可完成自动化测试，并根据自动化测试结果来决定是否进行发布。

这里面主要是以 DevOps 的理念来构建运维平台，这个方式也是我们的实践方式，后续内容将详细描述。

3. “拿来主义”

1. 公有云平台

   公有云平台提供了完备的基础资源和强大的功能特性，且具体完善的 API，一般创业公司完全可以基于公有云平台进行运维平台化管理，无需自己再去开发一套运维管理平台，也没有能力去开发。不过一旦公司做大，考虑到单一供应商的风险，势必考虑至少两家云平台的资源，甚至可能还存在自有数据中心，这样就面临着混合云管理需求。

2. ITSM 商业软件
   在云计算和 DevOps 驱动下，当前也有商业的ITSM 管理软件，提供一站式运维管理平台软件或者服务，而不是提供离散的 ITSM 管理套件。这类软件，在互联网 的时代，对于传统行业的 IT 部门转型升级会非常有帮助。

三、 YY互娱 - PaaS 运维平台理念和实践

业务场景

YY 互娱在这几年处于高速发展的过程，即要稳固拓展 PC 端的市场，又需要在移动端寻求突破，业务场景：

1. 快速试错

互联网时代竞争激烈，特别是移动互联网时代，谁能快速推出产品，快速迭代，谁就能在市场上占得先机。快速试错是一种常见的竞争手段。PaaS 平台的业务交付运行模式，最大特点就是效率高，成本低，可以很好的满足快速试错的业务需求。

2. 人力不足

长期以来，互联网企业在运维方面的人力投入是不够的，很多时候是扮演的救火员的角色，PaaS 在平台层面提供一站式运维服务，高可用架构质量保障，减少业务上线对运维人员的依赖，在不需要运维人员介入，开发人员自己就可以上线业务，并持续迭代。

基于 IaaS 的 PaaS 平台，将硬件环境与软件环境进行了解耦，也降低了硬件故障对线上业务的影响，释放了运维自身的压力。

3. 成本压力

业务上线需求多，如果按传统的方式提供物理资源，对资源的需求量极大，而业务的访问量，生命周期不可预测，造成硬件资源利用率低。很多时候通过混合部署业务，提高硬件资源利用率，造成后期维护成本非常高。

平台理念

基于上面的业务场景，以及云计算的大背景，YY 互娱技术团队基于 OpenStack ，推出自己的 IaaS平台，主要面向游戏业务的云计算平台。基于 IaaS能力，逐步构建自己的PaaS平台。

我们的平台理念是：运维技术服务化，转化为生产力。平台提供高可用高性能高质量的基础架构服务，满足业务的快速交付。平台提供一系列的工具，组件，来支撑开发人员自助式运维。

开发人员只要使用平台，无需找到运维人员，就能应用运维的能力，如高可用，弹性伸缩，配置管理，容灾备份等能力，达到 NoOps 的目的，减少开发、运维不必要的沟通成本，使开发人员专注于业务开发。

执行 DeoOps 理念，平台将开发、测试，运维流程自动化打通，将持续集成，自动化测试的能力以服务化的方式输出到平台。最终，将业务价值交付涉及的各种能力，通过平台输出到业务，达到技术服务转化为生产力的目标。

实践历程

1. 整体架构

PaaS运维平台的整体架构：

两种颜色代表两个视图，蓝色部分代表从业务维度的视图，即从PaaS平台用户的维度看到的架构。灰色部分代表从运维自身的视图，即运维全局的视图。

从业务维度的视图，大概分为4层，从下而上，面向服务，包括硬件层，IaaS，PaaS和业务层。

从运维自身的视图，包括全局资源中心，监控中心，数据源中心，报表中心，安全体系等。

接下来的篇幅，主要把面向业务的各个核心组件及实践做介绍。

2. 标准化

标准化是运维自动化的基础，PaaS 平台的标准将以系统化，自动化的方式落地。
标准化主要包括这些规范：

• 基础应用软件规范（Nginx,Resin,Tomcat等）

• 应用程序打包规范（Java,PHP）

• 应用程序部署规范

• 监控规范

• 其他

以上规范，全部落地到PaaS 平台的各个子系统，由子系统自动化完成。比如对VM 环境的标准化，通过 VM 镜像方式交付。

3. IaaS

我们的 IaaS 层提供了以下服务，来满足我们的应用上线。

• 计算虚拟化
  计算虚拟化部分，我们这里使用 VM，将 VM 作为我们容器计算的最小单元。当前使用 OpenStack 开源实现方案，使用 KVM 做 hypervisor。提供各类 VM 套餐满足不同业务场景。计算能力扩展我们采取的 VM 的横向扩展，即 ScalingOut，后面章节会介绍。

• 存储虚拟化
  考虑到性能问题，我们VM使用了本地存储。没有使用 Ceph分布式存储。
  对象存储上，对接了公司提供的基础服务。

• 网络虚拟化
  网络部分，采用了Neutron Provider Network，未实现 VPC 网络隔离。

• 数据源

• 数据源我们提供了3类数据源，Mysql，Redis，Memcached。这3类资源是平台上使用最频繁的组件。我们以单物理机多实例的方式运行，未主动采用 cgroup 进行资源隔离。这些插件在被创建的时候会自动添加监控，用户可以在平台查看相关监控状态信息。

• 插件平台。上述基础组件以插件方式与平台整合，类似于 Heroku 的 Addons服务。

具体业务流程描述如下：

• 插件注册：插件开发者将自己开发的插件接入插件平台。

• 获取插件：PaaS 平台的项目用户请求插件平台，获取插件授权信息。

• 返回授权：插件平台将来自 PaaS 平台的请求转发到具体的插件，获取具体插件的地址，授权等信息，并将信息存储在插件平台然后返回给PaaS 平台。比如 Mysql 实例，返回域名，端口，账号，密码。

• 插件注入容器： 项目模块发布的时候，由CloudRouter 从 PaaS 平台上获取插件信息并将相关信息注册到业务容器环境变量。关于 CloudRouter 的功能，后续会详细描述。

• 容器访问插件：业务容器从环境变量中获取到的插件信息，直接请求具体的插件。

  插件平台的引入，增强了PaaS平台的开放性和灵活性，项目所需的所有基础组件，不需要 PaaS 平台自己提供，可以由公司其他开发同事提供。插件平台面向公司内部所有开发人员，设置了一定的运营策略，如贡献率,引用量，收获赞等，并与公司的绩效积分，技术职级评定做一定关联。

• 其他资源
  其他基础服务，我们同时提供了 CDN，消息队列等。
  CDN 是使用第三方厂商基础服务，通过 API对接，实现一键创建 CDN 服务。消息队列服务底层采用了 RabbitMQ集群。
  同样，这些资源也以插件方式整合到平台。

4. 持续交付

基于上面的 IaaS 层，我们有了构建 PaaS 的基础能力，来解决持续交付的问题。我们从以下几个方面来描述

• 交付模型

交付模型，指在我们的 PaaS 平台上的业务，构建一个业务的模型。这个模型也是基于我们的应用程序打包规范来做的。这里再简单描述下：

• PaaS 平台业务交付的对象包括：人, 项目，模块。

• 人即项目管理员，一个人可以管理多个项目，一个项目也可能是多个人管理。

项目对应的是一个业务，一个项目又分多个模块，每个模块就是一个独立的部署单元；模块一般是按功能进行划分，比如最常见，一个项目有 admin 模块，user 模块。我们的PaaS平台的部署操作最小单元是项目的模块。以 Java 应用为例，模块的类型有 War和Jar。不同类型对应不同的部署动作。

• 项目管理

项目的管理包括项目的新建，以及用户权限管理，属性管理。需要的基础信息包括：项目 代码库地址，项目成员等等。
项目管理中涉及的信息

• 持续集成
  以Java 项目为列，我们约定在 pom.xml 根据模块名称打包成对应类型的包。并自动创建对应的项目模块，打好的程序包上传到分布式文件系统（DFS）。实现只要将代码提交到版本库，即可一键打包发布。在我们的现实情况中，并没有对每一个项目要求持续集成，而是选择性的，其中的原因是：

• 大部分项目都是小型项目，不涉及多人协同开发，这样的场景下不涉及到复杂的持续集成场景。

• 小步快跑。本身项目的迭代速度比较快，集成频率比较高，一般不会出现持续集成不通过导致需要花费大量精力解决集成失败的问题。

• 持续测试
  PaaS 平台与自动化测试平台进行对接，在基础信息上同步共享，包括项目名称，项目成员，版本库地址等。持续测试的实践经验是：

• 业务分级。对核心项目进行严格的持续测试，包括单元测试，QA 自动化测试。对非核心项目，默认不进行测试。是否测试的权限交给项目管理员，项目管理员一般都是开发团队的 Leader。

• 风险控制。在实际的运作中，测试能发现的问题是有限的，需要考虑一旦出现问题的补救措施。因此，对于核心的业务系统，引入风险监控，降低 bug 的影响范围。

• 持续部署
  持续部署中，涉及到如下几个问题，我们的解决方案是：

• 数据源。项目所需的数据源（Mysql，Redis）实例，用户在平台上一键创建，然后通过环境变量的方式注入到业务容器。具体流程见前面章节“插件平台”所描述。

• 配置管理。包括运行环境的管理，JVM 参数定制，Nginx 参数定制，域名配置，证书配置等，这类配置全部在平台，由用户自助或系统自动化完成。

• 发布。涉及“包版本”发布审批，服务器资源自动分配，“配置管理“中涉及的各项配置应用到相关组件。

• 回滚。平台支持包版本快速回滚。

• 持续反馈

• 基础资源监控及监控数据展示

• 运行维护

• 业务可用性监控和数据展示

  上述三点在后面的章节详细说明

5. 高可用架构

平台架构高可用设计，从最上层的攻击防御，到数据持久化层，全部提供高可用方案。业务只要接入平台，就具备全部的能力。。

• 云防DDOS，接入公司层安全中心的DDOS 防火墙，保障业务安全。

• GSLB，平台提供多机房，多链路接入的能力。项目域名自动解析到多个机房，提供就近接入的能力。

• OSPF-LVS，四层负载均衡采用OSPF-LVS 架构，具备平滑的水平扩展的能力。

• AppRouter 应用路由层，Nginx提供七层的路由转发，同样具备平滑的水平扩展能力。

• Container，应用逻辑层。这一层是项目级别的配置。提供 Nginx 容器（Tomcat，Resin,PHP-FPM）环境。这一层引入 Nginx，是考虑到部分七层业务逻辑控制，交由项目级别的控制，不至于每次项目级别的变更，而影响上一层AppRouter 全局层面的变更。这一层具备弹性伸缩的能力，后续章节具体讲解弹性能力实现方式。

• Cache 层，提供纯 Cache 和数据型 Cache。这一层我们主要是使用的 Redis，以域名和端口的方式对外暴露，通过域名切换，具备故障切换的能力。

• DB数据持久化.这一层目前对于所有业务实例，默认提供带主从的实例对，业务发生故障时，需要根据业务场景对数据一致性要求情况，进行故障切换。这一层当前未引入开源类似 MHA,MMM 等架构，而是通过域名切换的方式来实现，这里面参考了 AWS 的实现方法。

  我们的架构一般都是 MM 架构，当主节点发生 Down 机后，域名切换到从实例，Master 恢复后，只要修复主从关系即可。对于高并发访问量的业务，需要一主多从，或者 Mysql 环形复制场景，这些需要根据业务特性做一些人工介入。

6. 弹性扩展

• 声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系 [邮箱地址] 删除