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

摘要

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

视频内容

发布系统的演进

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

技术架构-早期(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机器执行性能压测。

我今天的分享就到这里,谢谢大家!

原文发布于微信公众号 - IT大咖说(itdakashuo)

原文发表时间:2017-11-10

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Web项目聚集地

你真的懂前后端分离吗?

最近这一段时间由于Nodejs的逐渐成熟和日趋稳定,越来越多的公司中的前端团队开始尝试使用Nodejs来练一下手,尝一尝鲜。

2693
来自专栏Android群英传

沪江学习Android端重构实践

873
来自专栏知晓程序

用手机也能看小程序后台数据了!微信你很棒棒哦

这个小程序,能让开发者、运营者在手机上就能查看小程序的运营数据,随时随地掌握小程序的市场反应。

981
来自专栏hadoop学习笔记

详谈分布式系统缓存的设计细节

在分布式Web程序设计中,解决高并发以及内部解耦的关键技术离不开缓存和队列,而缓存角色类似计算机硬件中CPU的各级缓存。如今的业务规模稍大的互联网项目,即使在最...

1314
来自专栏IT技术精选文摘

分布式系统常见事务处理机制

为保障系统的可用性、可靠性以及性能,在分布式系统中,往往会设置数据冗余,即对数据进行复制。举例来说,当一个数据库的副本被破环以后,那么系统只需要转换到其他数据副...

1898
来自专栏Java呓语

架构·微服务架构(一)

微服务架构模式作为替代单体应用和面向服务架构的一个可行的选择,在业内迅速取得进展。由于这个架构模式仍然在不断的发展中,在业界存在很多困惑——这种模式关乎什么?它...

5132
来自专栏微信公众号:Java团长

大型网站技术架构演化

说到大型网站,就要先理一下大型网站的特点:高并发,大流量,高可用,海量数据等,本文根据《大型网站技术架构》一书整理如下:

1362
来自专栏运维小白

18.12 keepalived + LVS

Keepalived+LVS DR 完整架构需要两台服务器(角色为dir)分别安装keepalived软件,目的是实现高可用,但keepalived本身也有负载...

3068
来自专栏python开发者

软件开发过程自动化原理及技术(完整示例)

软件开发过程自动化原理及技术 一个简单完整的自动化示例 1   概述 关于本文,最开始只是想写一些关于 软件自动化测试开发 的文章,但是后来写着写着,发现不先在...

2675
来自专栏嵌入式程序猿

web server 你真的需要

最近有几个项目都是涉及到嵌入式web服务器的,我们经常要用到像js脚本,cgi 技术和css格式样表,以及html语言来描述网页,那么怎么调试呢?对于做惯了嵌入...

3306

扫码关注云+社区

领取腾讯云代金券