超大流量电商平台系统背后的持续集成与发布

发布作为应用上线前的最后一个步骤，一直以来都是运维做的比较频繁也是风险比较高的操作，发布系统不仅要做到提升发布效率，更重要的是保障发布过程中系统的稳定，减少因发布导致的故障。本次演讲主要讲述美联的发布&持续集成系统的演进以及在提高发布效率，保障系统稳定上的实践。

发布系统的演进

发布系统的演进在一定程度上代表了运维体系甚至是公司技术架构的演进。

技术架构-早期(2011-2013)

最早期的开发语言是PHP，最流行的开源运行环境是LNMP，代码管理是SVN。

最开始的是人肉发布，后来有了PHP主站发布系统。它能代替人肉进行发布和操作，支持文件发布，有了回滚的功能，还有最简单的审批操作。

业务架构-中期(2014-2015)

到了2014年，我们的业务架构有所调整，建立了自己的交易平台。

开发语言变成了JAVA，运行环境是TOMCAT，代码管理用的是GIT。

业务系统改成JAVA以后对发布系统也提出了更多的挑战。JAVA发布和PHP发布有很大区别，于是我们做了JAVA的发布系统。

发布系统也改为StarkPlus，需要支持更多的发布类型、发布模式，以及更多的发布功能。

发布系统的特点是支持类型多，有JAVA、C++、NodeJS、PHP、Golang、Css_js以及二方库。

发布策略也多，有分批发布、分组发布、流式发布、自动发布和自定义发布。

功能多。原来的系统每次只能发布一个特定的分支，现在有一个应用多个分支并行开发的情况，所以我们需要多分支集成。

我们的应用又部署在多个机房，每个机房的配置可能都是不一样的，构建也不同，所以需要多机房构建。

最开始只有三套环境，后来慢慢发现三套环境已经不能满足我们的研发需求，需要多套环境部署。

Docker是目前非常流行的一个容器，我们现在也有部分应用在Docker上面，要对Docker做一些支持。同时也支持Docker和KBM的混合发布。

还有集成测试、安全扫描、性能压测和jar包检测，这些是其它业务团队做的工具，我们把它们集成到我们的发布系统中，来增强这些功能。

实践之路

运维的基础-标准化

首先要做好基础软件及配置标准化，OS、JDK、tomcat、nginx等等为运维提供了一套最标准的环境，所有的应用都跑在同样的环境上。

应用本身配置的标准化，应用命名、配置管理，启停脚本、检测脚本、部署目录、日志目录这些有统一的标准。

我们提供了一个应用的模版，假如应用完全符合我们的标准，就不需要改动可以直接接入，但也有些特殊的应用可能情况会不一样。

应用配置管理

应用类型配置可以使用我们的标准模版，也可以做一些自定义的功能，主要是人员角色、应用类型、启停命令和软件包信息。其实它们集成在我们的发布系统里面，后来我们发现这些设置不仅仅是发布系统要用，其它很多运维系统、业务系统都会用到。于是我们把它罗列出来单独成立了一个配置中心。

上图是我们发布系统的一个依赖关系，里面的一圈是它的核心依赖，CMDB管理服务器，配置中心管理应用的配置，OpsAgent在每个机器上部署一个Agent，用来执行一些在服务器上持续的操作。Gitlab做代码管理，流程引擎用于审批内容。

外围一圈都是用于增强我们的功能和一些外部依赖，有监控、安全扫描等等。

发布系统架构非常简单，主要就是两部分，一个是JAVA前端，用来做页面和流程控制。下面一个是用Pathon写的一组worker，用于执行一些具体的操作，例如代码的构建、合并、部署。中间通过一个MQ做任务队列和解耦，它们之间通过DB来进行传递。

分支管理

上图是我们的分支管理。所有的开发分支都是来源于master，在开发分支上开发完成将近发布的时候，发布系统会从master上拉出一个release，把feature分支一个个往上合，合完以后发布这个release分支。release分支发到线上成功以后再把它合回到master，创建一个基线。

新建&导入变更

创建变更有两种方式，一种是新建变更，就是从master上拉出一个新的分支；另一种是导入变更，已经有了从另外的开发分支上的一个分支，需要手动把这个分支拉出来进行导入。

集成&发布

上图是我们集成发布的页面。最上层是我们的三套部署环境；发布的基础信息包括了应用名和当前发布的分支名称等；下面是我们发布过程，发布过程会根据应用类型的不同而有所区别；集成区的分支就是当前分支在发布中，待集成区是已经开发提交了集成但是还没有进行发布。

进入线上

预发必须部署成功，集成区的checklist要全部通过。

代码合并

手动解决在代码合并过程中发生的冲突。Release分支更换策略就是新加入的分支或者修改feature分支代码的时候，Release分支是不会变的，不用再解决第二次冲突。

不同应用类型的构建方式是不一样的，而且构建是基于合并完成的Release分支，像JAVA、C++、GOLANG、NODEJS是放在一个Docker容器中进行构建，构建完成后会有产出。

健康检查

每个应用都有健康检查URL：/status

当访问/status时，检查核心依赖（DB、cache、依赖应用），预热数据。

执行成功返回“SUCCESS”，其余状况均为失败。

发布计划&审批

日常发布是周一至周四工作时间，由主管审批；

常规紧急发布在周五、周末，由研发D进行审批；

节假日例如法定节假日、运营商封网等，也是研发D审批；

特殊时期比如大促、集团发布会等期间，理论上是不允许任何发布的，如需发布就需要通过CTO审批。

我们的特色

研发流程闭环

深度整合发布系统与项目管理系统（PMO），需求、项目可以创建、关联变更。变更发布后可以通知到PMO的系统去更新需求和项目状态，这样就可以明确每次发布的目的。

多机房、多分组构建

同一个应用在不同的机房有不同的配置，在不同的分组提供的服务也有区别。

线下&预发多套环境

因为需求多、变更多，所以部署变更非常频繁，测试总是抱怨环境不稳定。大项目希望能独占一套项目环境，解决环境的隔离。

Jar包检测&Diff

Jar包冲突检测：Jar包冲突会导致莫名其妙的问题，难以排查。

Snapshot包检测：Snapshot版本更新频率高，不可控。

Jar包版本限制：已经废弃的版本、有bug的版本不能被使用。

Jar包Diff：查看本次发布版本和基线版本的jar包差异。

稳定性

前端扫描：对于css_js的发布做前端代码质量检测；

安全扫描：对java代码做静态安全性分析；

集成测试：预发环境发布的同时执行单元测试、接口测试；

性能监控&压测：线上beta发布后对beta机器执行性能压测。

我今天的分享就到这里，谢谢大家！