[YY互娱]基于 DevOps 理念的私有 PaaS 平台实践(3)

• 交付模型

交付模型,指在我们的 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,PHP-FPM)环境.这一层引入 Nginx,是考虑到部分七层业务逻辑控制,交由项目级别的控制,不至于每次项目级别的变更,而影响上一层AppRouter 全局层面的变更.这一层具备弹性伸缩的能力,后续章节具体讲解弹性能力实现方式.
• Cache 层,提供纯 Cache 和数据型 Cache.这一层我们主要是使用的 Redis,以域名和端口的方式对外暴露,通过域名切换,具备故障切换的能力.
• DB数据持久化.这一层目前对于所有业务实例,默认提供带主从的实例对,业务发生故障时,需要根据业务场景对数据一致性要求情况,进行故障切换.这一层当前未引入开源类似 MHA,MMM 等架构,而是通过域名切换的方式来实现,这里面参考了 AWS 的实现方法.我们的架构一般都是 MM 架构,当主节点发生 Down 机后,域名切换到从实例,Master 恢复后,只要修复主从关系即可.对于高并发访问量的业务,需要一主多从,或者 Mysql 环形复制场景,这些需要根据业务特性做一些人工介入.

（编辑：ASP站长网）