解密YY互娱运维|基于 DevOPS 理念的持续部署平台实践
嘉宾简介：
刘亚丹，现任职于欢聚 YY 互动娱乐事业部，负责事业部的基础平台运维管理工作，经历服务器从数百到数千的规模。目前 IAAS 平台的虚拟主机规模近3000台，运行的页游超过40款，类 PAAS 平台运行的 web项目超过200个。虚拟化平均比例在1:8左右。
分享主题：
基于 DevOPS 理念的持续部署平台实践
暖场：
大家晚上好，很高兴能在这里与各位大牛交流分享，作为一个工作7年的互联网运维小兵，在这里分享自己的一点工作实践，我开始是拒绝的，但迫于群规的压力，我硬头皮接下了，一来是对自己工作的一个总结和学习，另一方面，希望我的工作分享能对一些朋友有些参考意义。
好了，开场白不多说。
正文：
今天我的主题是“基于 DevOPS理念的持续部署平台实践”，接下来我先上一张图，直观展示下整个产品开发的过程：
这里面在我们内部定义了3个系统：研发管理系统，QA 系统，持续部署平台（包括云监控）
研发管理系统负责创建需求，跟进任务状态，贯穿项目始末； QA系统负责提供项目安全扫描，兼容性测试和接口测试的自动化服务及生成测试报告；持续部署系统负责自动布署和线上运维监控报警等事宜。三大系统形成一个闭环，从产品设计到开发、测试、运维统一由系统辅助完成，达到提高效率、改进质量、节省成本的目的。
今天我重点分享下我们的持续部署平台（内部代号：升龙），以及围绕这个系统我们做了哪些组件或者说工作。
功能，特性
持续部署系统提供了以下功能和特性：
-
一键打包，发布，版本回滚
-
IAAS
-
插件平台
-
AppRouter
-
自助式运维
-
监控、告警
-
弹性伸缩
-
web日志 Debug 和可视化
内部概念说明
这里先说一个对我们系统来说非常重要的几个概念：
持续部署平台的角色有：人, 项目，模块
人即项目管理员，一个人可以管理多个项目，一个项目也可能是多个人管理。
项目对应的是一个业务，一个业务又分多个模块，每个模块就是一个独立的部署单元；模块一般是按功能进行划分，比如最常见，一个项目由 admin 模块，user 模块。我们的部署系统的部署操作最小单元是项目的模块。
下面对刚才提到的几个功能展开讲下：
一键打包，一键发布，版本回滚
打包
持续部署平台对接了 svn，一个项目一个 svn 地址库，开发只需填写一个 svn 地址，按照我们约定的pom.xml 规范，可以自动打包及创建对应的项目模块。如果是新项目，创建项目的时候自动创建 svn 版本库
这张图是进入平台后，与打包相关的配置.
打包：这里可以选择编译器版本等信息
发布：
打包好后，需要进行发布前配置，包括数据源的申请和配置，以及 Nginx ，JDK 版本，JVM 参数定制，域名设置等
配置好后，就可以进行发布了
发布的时候，需要选择发布模块，发布版本（即历史上每次打包的版本），点击部署，即可发布。
发布支持：分布发布，所谓的分布发布，即选择一部分服务器进行发布新版本，其他服务器运行旧版本。
版本回滚
若需要回滚，则选择相应版本进行回滚
IAAS：
部署平台集成了 IAAS 的基础服务，在部署平台上可以一键创建相关资源。
如：
云数据库： API 化，基于 mysql ，提供一套远程数据库服务（社区版 mysql5.5）；提供各类套餐；
云 redis/memcached：API化，提供一套远程缓存服务（源生的 redis和 memcached）；提供各类套餐
消息队列：API 化，基于 RabbitMQ 集群的消息队列服务
云存储：API化，（基于 TFS 的对象存储）
云 cdn：API 化，一键对接第三方CDN 服务
虚拟主机：基于 openstack 的计算虚拟化，使用宿主机本地存储，vlan providernetwork。
还有其他，不列出来了
插件平台
类似于Heroku的Addons系统，所有的数据源，统一由插件平台进行管理和创建；插件使用方式，通过环境变量的方式注册到VM内，程序启动时从环境变量中获取；
插件平台与部署系统的关系是：
AppRouter
AppRouter（应用路由器）：实际上是一个 Nginx 服务器，自写了一个 WAF模块，主动拦截攻击或打印疑似攻击日志，上报中心端进行分析处理；AppRouter支持 API 操作配置 upstream 代理到后端的多个应用服务器；支持 server 内自定义 location 规则。简单架构如下（RS 即运行 java 容器的 vm）：
如何下架构示意图：
我们在新版中支持扩展性更灵活扩展性更好的架构（多机房部署）：
这张图里面，引入了 OSPF + LVS-TUNNEL 模式做负载均衡，可扩展性更好，缺点是要交换机上也配置支持
自助式运维
自助式运维支持对 vm 管理，支持对数据源的操作，比如查询 redis 数据，查询 mysql 数据，以及导出相关数据。
这里上一张执行系统命令的页面。
监控，告警
基础监控
我们的监控系统底层是用的 zabbix，提供 vm,云数据库，云缓存常规指标的监控。其中云数据库提供 slowlog 查询（目前在规划数据库实例的质量管理系统）
VM 的基础监控：cpu,mem，io，disk，net-traffic，connections，procs
数据源 mysql，redis，mc 的基础监控。
自定义监控：支持 TCP,DNS,PING,HTTP,支持自定义告警条件和策略。
上一张 vm 基础监控的页面：
自定义监控：
告警：
平台告警，我们通过一个叫做 cloudmonitor 的组件进行告警，告警的方式支持短信，YY，邮件方式。
实现方式是：在zabbix 的事件接口上，定期获取事件，按业务维度进行汇总分析发送给业务开发负责人和运维负责人。做了一定程度的事件聚合，比如宿主机 down 机，宿主机上的 vm 相关相关信息关联起来，从业务开发负责人看：某 vm down 机是由于某宿主机引起；从运维层面看，某宿主机 down，影响了这些 vm，这些 vm 运行了这些业务。
弹性伸缩：
示意图：
弹性伸缩由资源池（vm）、CloudRouter这两个关键组件
CloudRouter是资源的调度器，它在用户的任务、与资源的分配之间，起到核心的协调作用。
CloudRouter示意图
当前我们的业务弹性伸缩基于 VM，伸缩的策略是模块所有 vm 实例的平均负载和方差；数据来源于我们的云监控系统（基于 zabbix及其API 的封装）
具体规则如图：
web日志debug 和可视化
文本日志：
rsyslog收集所有 vm 的业务日志以及 AppRouter 的访问日志到集中端，开发人员需要查证问题，登陆日志收集集中端进行查证。
web日志可视化
这个系统我们是对接公司其他团队的技术平台，使用 storm 做实时日志分析（延时10分钟），这里不展开讲了。
资源隔离
虚拟计算：目前计算虚拟化用的 kvm，由 kvm 做计算和内存的资源隔离
虚拟存储：本地存储，VM 运行在宿主机本地
云 mysql/redis：多实例直接运行在物理机上。
虚拟网络：openstack 的 vlan provider networking。传统交换机二层 VLAN 隔离。
异地容灾解决方案
我们专门有一个灾备机房，核心业务在灾备机房可在平台上快速构建一个灾备环境，出现机房故障时，可通过切换 dns 做快速切换（灾备切换是一个比较严谨的事情，业务层的数据一致性，需要业务考虑好）
开发框架：
基于 sping 框架封装的代号为 leopard的开发框架，与我们的持续部署平台紧密整合
目前最需完善之处：
平台，业务的可用性，可靠性的度量，比如：
数据源实例质量分析系统未上线，数据源的质量管理被动
应用的可用性度量
可视化不够，如业务的架构图
隔离性不好，如数据源实例在同一宿主机的资源隔离
平台化不够，如从新人入职到快速使用这个平台，中间有较多人与人之间的沟通
总结：
-
质量：基础组件平台保障高可用，故障自动隔离；包括AppRouter，云 mysql，云 redis,云 memcached；第一个版本是 VIP，目前正在做的第二个版本考虑适用 dns 切换做故障隔离（有 dns ttl 和 jvm 虚拟机 ttl 的问题，暂不深究）
-
效率：执行 DevOPS 理念，开发人员自助式运维管理，运维只负责基础平台的稳定性，以及基于企业数据安全管理的一些事情。把运维的能力通过平台服务化输出，如高可用，弹性伸缩，故障隔离等。
-
成本：虚拟化，弹性节省服务器成本，自动化，自助式运维节省人力成本
经验分享
我们构建这个平台的一些经验分享：
-
我们的理念：平台推动引导平台用户具备 DevOps理念，以及整合ITIL 相关管理流程规范理念，将一切资源服务化(API化), 组件化（SDK），构建一个敏捷，弹性，高可用，安全，资源隔离，流程规范，用户体验好的技术平台。
-
对于正在构建的公司，建议找到突破口，获得企业 IT 管理决策人员支持(感觉目前DEVOPS是共识，IT 老板基本都是支持态度)
-
运维三部曲标准化，服务化，无状态化
-
没有最好的，只有最适合的
我的分享就到这里。谢谢大家。
浙公网安备 33010602011771号