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

• 交付模型

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

• PaaS 平台业务交付的对象包括：人,项目,模块.
• 人即项目管理员,一个人可以管理多个项目,一个项目也可能是多个人管理.

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

• 项目管理

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

• 持续集成
  以Java 项目为列,我们约定在 pom.xml 根据模块名称打包成对应类型的包.并自动创建对应的项目模块,打好的程序包上传到分布式文件系统(DFS).实现只要将代码提交到版本库,即可一键打包发布.在我们的现实情况中,并没有对每一个项目要求持续集成,而是选择性的,其中的原因是：
  • 大部分项目都是小型项目,不涉及多人协同开发,这样的场景下不涉及到复杂的持续集成场景.
  • 小步快跑.本身项目的迭代速度比较快,集成频率比较高,一般不会出现持续集成不通过导致需要花费大量精力解决集成失败的问题.

• 持续测试
  PaaS 平台与自动化测试平台进行对接,在基础信息上同步共享,包括项目名称,项目成员,版本库地址等.持续测试的实践经验是：
  • 业务分级.对核心项目进行严格的持续测试,包括单元测试,QA 自动化测试.对非核心项目,默认不进行测试.是否测试的权限交给项目管理员,项目管理员一般都是开发团队的 Leader.
  • 风险控制.在实际的运作中,测试能发现的问题是有限的,需要考虑一旦出现问题的补救措施.因此,对于核心的业务系统,引入风险监控,降低 bug 的影响范围.
• 持续部署
  持续部署中,涉及到如下几个问题,我们的解决方案是：
  • 数据源.项目所需的数据源(Mysql,Redis)实例,用户在平台上一键创建,然后通过环境变量的方式注入到业务容器.具体流程见前面章节“插件平台”所描述.
  • 配置管理.包括运行环境的管理,JVM 参数定制,Nginx 参数定制,域名配置,证书配置等,这类配置全部在平台,由用户自助或系统自动化完成.
  • 发布.涉及“包版本”发布审批,服务器资源自动分配,“配置管理“中涉及的各项配置应用到相关组件.
  • 回滚.平台支持包版本快速回滚.
• 持续反馈
  • 基础资源监控及监控数据展示
  • 运行维护
  • 业务可用性监控和数据展示上述三点在后面的章节详细说明

5. 高可用架构

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

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!