微信扫描登录
或者
请输入您的邮件地址来登录或者创建帐号
提 交取 消
GITBOOK.CN需要您的浏览器打开cookies设置以支持登录功能

从开发、到测试、到发布、到运维——猎聘研发持续交付体系

本篇文章整理自刘中兵5月9日在『ITA1024运维技术精英群』里的分享实录:从开发、到测试、到发布、到运维——猎聘研发持续交付体系。

enter image description here

我叫刘中兵,目前担任猎聘网基础研发总监,负责公司基础保障技术体系建设,如基础架构、服务中间件与服务治理、运维研发与持续交付体系、搜索平台与算法、舆情监控平台、开放平台、公共业务平台等。

今天我给大家分享的是,猎聘网如何建设持续交付体系,来保障开发、测试、发布、运维的自动化。

enter image description here

这种现代化的流水线,与手工酿造的过程比,优势明显:

enter image description here

啤酒工业化流程属于工业时代的产物,经历了几十年的改造。而现在科技行业的互联网产品研发,只有将近20年。而且对于不同阶段的公司,由于技术的差异性,很难完全一样的去建立。每个公司随着从小到大的发展过程,必然要经历这样的技术体系建设过程。猎聘网也不例外。

之前的开发、测试、上线和运维流程:

互联网公司都会经历从小到大的阶段,技术人员规模也会经历不同阶段,从1人到10人属于初创期,10人到100人属于发展期,100人到1000人属于规模化发展期,从1000人到10000人甚至10万人属于大规模运行期。

猎聘网也经历了这样的发展过程,从1人发展到10人发展到100人,目前技术人员规模在几百人规模。正处于技术从手工到现代化的建设时期。

之前的一个产品开发会经历这样的阶段:

  • 需求阶段:产品经理讲解需求,技术人员开发
  • 开发联调阶段:所有技术人员共享1套测试环境,经常互相影响、互相依赖、查找问题耗时
  • 测试阶段:十几个需求共享1套或多套测试环境,环境故障频发、不易解决,环境太多维护成本高,仅功能测试,安全、性能、API、回归等偶尔需要时靠手工,效率低;
  • 发布阶段:排队上线,前期运维通过手工打包上传启动,后期通过脚本或工具启动,但需要用户服务停机、上线时间长;
  • 生产阶段:早期线上服务宕机靠用户报告,后来服务靠监控宕机报警,而服务的质量、故障、响应速度、成功率等等都缺少完善的监控体系,对于服务治理和灾备降级等基本靠发现一例解决一例;

以上的状态,可以发现:研发人员缺少开发、测试的工具和环境,测试缺少一些自动化的工具,运维刀耕火种缺少持续发布检测的工具,服务监控问题发现和问题治理缺少工具。

随着需求上线次数达到每周几百上千规模、并行需求开发到几百个,这显然满足不了交付的速度和质量,而且问题频发。

下面就是早期开发人员和运维人员工作的环境:

enter image description here

随着人员规模增大、迭代速度加快、并行需求增多、服务规模扩大,我们来看看,一个产品应该怎样炼成的?

对于每周几千项目次上线、并行近百个需求开发测试、线上数千个服务实例的治理来说,传统软件的敏捷(如XP、Scrum、TDD)已不能适应这种灵活性。

互联网产品的特点,是需求多变、快速反馈、快速验证。这需要一套自动化的持续交付体系来保证开发、测试、上线、运维多个环节的频繁交付,来保证批量的小粒度需求被高质量开发、快速测试、快速部署到生产环境,并保证高质量运行和治理。

为了实现需求的持续快速交付,猎聘建设了一整套的持续交付体系,实现了软件开发、构建、测试、持续集成、部署和监控治理的全面自动化工具化。

下面是猎聘网所建设的整个持续交付体系:

enter image description here

该体系分为4个大的阶段:

  • 产品需求阶段:只需要建设响应的OA系统和流程就可以了;
  • 开发阶段:能够快速、标准、持续的构建开发环境,让开发工程师能够互不影响的进行测试;
  • 测试阶段:有一套多维度的持续集成系统,来检查潜在的代码问题;
  • 发布阶段:从线下到线上、到配置、打包、编译、部署,一套工具体系来实现快速上线;
  • 生产阶段:需要从硬件、服务、接口、代码、数据、流量等多维度监测和治理线上服务;

持续交付流程体系:

1、开发阶段--持续发布CP:快速构建测试环境、让RD/QA完成80%的功能测试。

包括:开发环境快速部署(凤凰系统)->测试环境快速部署(凤凰系统)->测试数据快速构建->OpenStack/KVM/Docker弹性发布等。

2、测试阶段--持续集成CI:自动化持续构建、帮助发现20%的代码潜在问题。

包括:代码自动评审(CodeReview)->代码静态检查(Sonar)->研发单元测试(UT)->QA自动化测试(UI-Selenium/APITest/APP)->技术可用性测试(性能/压力/安全),并提供CI质量报告衡量代码质量。

3、发布阶段--持续部署CD:版本规划、打包、一键部署、多泳道发布。

包括:包编译服务(Compile)->版本包管理(Package)->CMDB配置(龙潭)->Env配置(闪电)->灰度(青龙)->生产线(青龙),以及变色龙指令系统等;

4、生产阶段--持续监控CM:多维度监控、安全分析、调用链分析工具。

包括:硬件监控(Zabbix)->实时日志(雷达系统)->服务质量(红警系统)->调用链(CAT)

1. 持续交付的前提——是一切标准化

一切的持续交付的前提都是标准,不标准的一切开发都将会随着规模化的扩展,带来无穷无尽的后腿——技术债务。为此,我们从网络、硬件,到系统、软件,再到项目的配置、服务等,都进行了标准化。

enter image description here

我们将标准从服务部署的顺序,依次制定了标准的规范:网络层->服务器层->系统层->软件层->配置层->服务层。

enter image description here

网络架构标准化

以上是我们的网络架构逻辑图(其中IP是示意)。我们将整个硬件资源划分成4个大区域,每一个区域一个网段,并留有足够的扩展IP。每一个区域内按照功能模块又有独立的网段规划。

网络分区如下:

开发环境区域,用户开发阶段测试

  • 开发环境+公共区+存储区
  • 发布环境+公共区+存储区
  • 凤凰发布系统

持续集成区域,用于测试阶段的持续集成

  • Review+Sonar+Test+CI

线上发布区域,用户上线阶段的代码编译发布

  • 发布+配置+编译+打包+指令

线上区,用于服务运行与服务监控治理

  • 线上服务区:分多分区+存储区
  • 线上服务中心:服务中心+作业调度+消息中间件
  • 线上监控:日志+服务质量+调用链+监控

服务器标准化(主机+KVM+Docker未来)

部分主机:重要服务采用标准化主机,48G/96G+24core

部分KVM:OpenStack。部分不重要服务采用KVM共享资源

私有云:尝试Docker管理线下服务器,将IP、内存资源池化管理,减少CMDB运维成本,并逐步推行至线上。

猎聘目前的服务器采用主机+OpenStackKVM方式,正在考虑接入Docker进行资源池化的管理,来降低运维资源管理成本、便于扩容。

enter image description here

对于服务器资源,我们通过CMDB进行标准化配置管理。

enter image description here

新服务器的上架,会部署服务器发现的Agent自动上报服务器信息的变更到CMDB配置系统。

enter image description here

系统标准化(CentOS)

硬件之上的第三个层面,就是进行服务器linux系统本身的标准化。我们将不同功能的服务器进行分类,进行不同的配置项设置和标准化检查,比如nginx服务器,会配置许多跟nginx相关的系统属性。

这些系统属性会自动上报CMDB进行比对,一旦发现配置变更,就可以发送运维人员进行修复。这保证了我们所有的服务器配置都是一致的,出现问题便于统一解决,大大降低了个性化操作失误。

enter image description here

软件标准化

第四个阶段是软件的标准化,我们将公司所有部署所采用的软件统一获取安装包、版本,并规定每个软件占用的端口、安装路径。并通过后文提到的CMDB龙潭系统来进行自动化的软件安装,这样就可以保证公司所有的软件安装都是完全一致的。

enter image description here

配置标准化

有了基础软件之后,就是部署我们公司自身研发的应用了。我们的应用支持Tomcat、Java、Python、Android、iOS,我们将所有的软件类型都按照同样的部署目录和配置路径进行配置。

例如以上的tomcat配置,包括bin、conf、logs、temp、work目录,还包括脚本start.sh和stop.sh,配置文件JAVA_OPTS、server.xml。这样就保证了全站的tomcat war部署都在这样的配置路径下。同样的,我们将Java、Python等项目也按照同样的规格进行配置标准化。将配置做成标配。

enter image description here

服务标准化

在软件开发层面,同样需要进行标准化。为此,我们开发了两个技术产品:

1、框架的规范——雨燕框架Swift:该框架基于Spring进行封装,基于HTTP等多种协议,规定了Controller、Service代码的包命名、层次、类命名、接口命名、参数规范、返回值规范、页面规范,公司的服务统一分为Service、Web两层服务。

同时,该框架提供了很多公共的服务组件,比如缓存组件LPCache、KV组件LPKF、数据库分库分表组件LPDAL、文件访问组件LPFS等。所有这些组件和框架与行业的做法大同小异,但对于一个公司来说,简单而统一会减少很多不一致造成的麻烦,因为服务化、互相可调用的前提就是标准一致。

2、服务的规范——服务中心Router:基于Swift,我们研发的Router分布式服务协调组件,类似于Zookeeper的服务发现模式,所有的服务注册到该组件,其他服务基于该组件进行服务发现。

至此,我们通过网络、服务器、系统、软件、配置、框架与服务6个层面,来约束和规范所有的代码和配置环境,让每一个配置都成为标配。

有了一致的标准,就可以做持续交互的体系了。

2. 开发阶段——持续发布CP

Continuous Publish是为了保证开发阶段,所有的代码可以快速的被部署到开发、测试环境,并能够为所有的研发、QA提供稳定、可靠的、互不影响的环境,进行快速迭代开发和测试。即具备持续发布的能力。

enter image description here

为此,我们建设了开发环境的发布平台“凤凰系统”,来实现对2套开发环境、9套测试环境的快速发布,可以保证在1小时内快速回复一套全站环境。如图中左侧所示,该系统还能够与线上的青龙系统进行贯通,实现线下到线上发布的一体化。所有这些系统对于目标机器的操作,都通过变色龙指令系统实现。

enter image description here

一套系统的发布过程,可以从0开始,首先获取新初始化的标准的系统,然后通过凤凰系统进行软件的安装、配置生成与发布、全站项目的发布,交付QA使用。

enter image description here

一套环境所使用的软件,在系统中已经初始化定义,只需要勾选软件列表,系统底层通过原子指令系统(后文会讲到)来执行这么多软件在目标服务器的安装。

enter image description here

安装完软件后,可以通过3步完成环境发布:

创建分区:选择在该环境(即目标IP,可以是多个IP)的项目部署方案,并生产成配置文件发布到目标服务器,配置文件根据你项目的不同生成不同的配置,如右上角的图所示;

推送配置:调用变色龙指令系统,将配置文件(及各种xml、conf文件)发送到目标服务器上,按照之前制定的配置规范放置;

发布项目:通过凤凰系统,可以发布所选择项目并启动,就完成了整个环境的发布过程。

enter image description here

由于凤凰系统可以管理多套开发测试环境,因此每一套环境,系统都有一套Host配置,通过以上的工具,自动映射到本机的C:\Windows\System32\drivers\etc\hosts文件,启用浏览器,就可以访问web工程的url了。

enter image description here

为了保证服务高可用,凤凰系统会对所有的环境、项目进行实时监测,发现异常进行报警和通知、或者自动恢复服务。

以上通过凤凰系统,就完成了开发人员、测试人员对环境持续发布的需求,保证了每周上百个工程、需求的并行开发、联调、测试。

3. 测试阶段——持续集成CI

Continuous Integration是为了保证在测试阶段,帮助开发工程师、QA自动发现代码潜在的风险、规范、异常、环境不可用因素。由于日常的项目代码变更其实只有20%,而这一套环境会对全部的100%代码进行持续的构建和监测,让我们对20%变动的代码和80%不变动的代码都有持续监测。

enter image description here

持续集成,严格意义来讲,是通过非人工测试的手段,来发现代码bug和潜在问题的。所以我们也会通过以上的多个层面进行自动化集成测试,保障代码质量。

系统逻辑架构如图所示,分为研发阶段的代码质量测试、持续集成测试、架构层面的压力性能测试,并最终形成CI质量报告。底层依赖用例库和测试数据,结合Jekins等工具来实现日常的持续集成。

enter image description here

持续集成的基础是有一个触发器,能够自动发现代码的变更、进行自动化测试。我们采用了行业的Jekins。

enter image description here

我们采用Sonar来基于我们的雨燕框架规范(命名、格式规范等),扫描所有的代码、发现不同级别的bug。目前已经支持Java、Python、Android、iOS等代码的扫描。使用这里测试的bug,可以将我们的开发喜欢慢慢培养的越来越好。

enter image description here

我们采用Sonar来基于我们的雨燕框架规范(命名、格式规范等),扫描所有的代码、发现不同级别的bug。目前已经支持Java、Python、Android、iOS等代码的扫描。使用这里测试的bug,可以将我们的开发喜欢慢慢培养的越来越好。

enter image description here

在代码的集成测试环节,可以通过3个层面进行测试和质量保证:

UT单元测试:用于研发环节80%的核心代码进行边界测试,以QA的视角,对所有代码进行覆盖度测试;这一环节作为工程师的可选环节,对于需求变动较少的项目适用;

API自动化测试:用于QA环节对80%的主干接口进行集成测试,以运维的视角,对集成环境进行主干功能测试;这一环节我们提供了白虎API平台,对于平台型的API项目适用;

Web自动化测试:用于部署环节对80%的用户界面进行模拟测试,以用户的视角,对集成环境进行模拟测试;这一环节采用了开源的Selenium,对于Web项目适用;

enter image description here

该平台的实现逻辑是,将各个平台的HTTP API接口参数、返回值录入系统,并针对不同的场景选择不同的接口添加测试场景,并录入入参出参的用例,点击测试就可以测试该系统是否可以正常运行。

该系统会每天自动构建运行所有的场景用例,发送质量报告。这对于集成环境的质量监控,能够发现环境、代码变更导致的错误。

enter image description here

CI集成测试,旨在通过系统工具,测试和发现QA工程师功能测试之外的代码质量、潜在bug、集成环境变更、性能等问题。在这条路上,用的多成本高效益高,用的少成本低效益也低,所以我们也在根据场景分别选用不同的方法和工具。

4. 发布阶段——持续部署CD

Continuous Deploy是为了保证在发布上线阶段,帮助QA和运维快速实现代码检测、编译、打包、灰度和发布上线。我们在线上为了实现多需求并行上线,采用了多泳道发布的模式。这些由一整套的青龙、龙潭、变色龙指令系统来完成。

enter image description here

为了实现持续快速的部署,我们建立了一整套系统,实现打包、编译、发布、配置等。

enter image description here

前文我们说到,线下采用了凤凰系统进行发布,与线上的龙潭、青龙可以实现一体化的编译和环境发布工作。

enter image description here

线上发布环境用来发布多个区域,如灰度区S、多泳道区域ABC(即每个区域都是独立完整的执行环境,可以摘除任意一个区域不接入流量,进行不引入流浪的内测),其中龙潭用来实现配置发布、青龙实现代码发布,所有的发布指令都通过变色龙系统执行指令。

enter image description here

青龙系统负责管辖灰度区S、正式区ABC,另外的D区用来执行大批量的离线作业任务。青龙系统负责从SVN获取代码、从龙潭获取配置,将代码打包、编译、检测,通过后发布到线上,启动Tomcat。

enter image description here

青龙多泳道分区发布:线上的ABC区,都可以摘除外部Nginx流量,进行该区域的批量发布、整体测试,通过后再接入流量。这样做的好处是,发布期间对用户毫无影响,并可以进行长时间的内测,有问题时的回滚。

enter image description here

青龙发布功能实现了闭环:支持TomcatWeb、Java单进程、Python、JS、Android、iOS项目发布。

enter image description here

在线发布时,可以通过Web界面实时查看发布过程中的日志,就跟linux终端直接使用start.sh一样,可以看到所有的系统输出日志,并能够自动检测,提示成功和失败。

enter image description here

发布后的项目,青龙会对全站服务阶段进行可用性检测,有问题的项目会报警给运维人员处理。

enter image description here

龙潭系统负责为青龙发布ABC项目前的配置生成和发布准备工作,包括mysql数据源、项目svn地址、项目引用的memcached、redis、项目启动的端口、JVM配置参数等。

enter image description here

如上左图所示,可以在系统中进行项目所有属性的标准化配置,并将配置后的信息生成标准化的配置文件,例如server.xml、log4j.properties等。右图是将各种配置文件推送到目标区域的所有服务器IP中。

enter image description here

为了统一项目之间的打包编译和引用,我们将公司内的JAR和外部第三方的JAR,统一指定命名、版本号,每一个项目引用这个公共的POM文件,这样减少了项目版本不一致的问题,统一化了项目的版本库管理。

enter image description here

项目在线上运行时,是基于Router框架来实现服务发现的。而每一个项目本身也会有很多的KeyValue变量配置,例如某一个用户属性的阈值、某一项功能的开关等等,这些信息通过一个闪电配置系统实时发布到线上,线上项目基于Zookeeper来读取改配置。

enter image description here

无论是凤凰、还是龙潭和青龙,所有的Web系统对于物理服务器的操作,都是通过变色龙指令系统来实现的。该系统开放了一个执行指令的HTTPAPI,提前定义好的指令名会传输给它,它负责调用远程的PuppetAgent来执行Shell指令操作。并将日志通过API回归现实到青龙等Web系统界面中。

enter image description here

如上图所示,目前我们定义了300多种系统操作原子指令,它们承担着如发布、停止、启动、拷贝、检测等各方面的功能。每一个指令都是一个Shell脚本,可以被Puppet执行。

5. 生产阶段——持续监控CM

Continuous Monitor是为了保证在发布上线阶段,帮助运维实现服务、流量、故障的快速发现和整理。包括日志流、接口/SQL失败率、性能、响应时间、程序调用链、调度任务等多方面的监控。以便快速发现问题、甚至自我修复。

enter image description here

线上服务的治理和监控是多维度的,这完全看当前系统的需求,进行抽象开发。目前我们提供了以上的各维度监控工具。

enter image description here

该系统基于Flume+Kafka+ES+Spark,通过Flume节点收集线上上千个服务Tomcat节点的实时日志流,传输到Kafka集群和ES集群,分别通过Web系统展现实时的日志流和历史日志流,并基于Spark提供基于日志的统计需求。这样所有的开发工程师就不用登录到目标服务器IP,直接在浏览器就可以看日志和分析日志了。

enter image description here

这是实时日志的界面,如这个示例,该系统部署了8个IP,点击“All”可以查看所有IP的日志流,并可以输入关键字进行搜索和问题分析。该日志界面通过Ajax实现,目前日志延时不超过5s。

enter image description here

线上每一个服务示例,起JVM、API、Redis、Memcached、SQL等每一个环节都可能出现并发、性能、容量的故障,我们通过红警系统实时收集各个接口和依赖服务的性能指标,展示在如上左图所示的大盘中,飘红的就会是有问题的项目需要进行质量优化。右图展示了JVM各个指标的明细,如GC次数、线程数、CPU使用率等,超过一定阈值会报警。

enter image description here

前面的青龙系统发布时,我们提到了D区,该区域是用来专门执行调度作业的。业务线的作业基于啄木鸟来进行调度,并将执行的结果反馈到作业大盘中,通过这个大盘可以看到已经执行成功、失败、待执行的所有任务,以便对问题进行处理。

enter image description here

各服务与其他服务之间,通过埋点,记录API调用链的时间和参数,来统一分析调用链中的性能消耗、故障点。这采用了第三方开源的CAT系统。

至此,就讲完了我们如何通过建设标准化的、从开发、到测试、到发布、到运维的持续交付系统,来实现快速持续交付的目的。其中每一个环节都建设了很多的系统平台,技术本身并没有太大的难度,重点是对每一个系统做综合的设计和运营。

我们也将这一系列的技术型系统取了系列的名字,称之为猎聘动物园。

enter image description here

Q&A

1、这套系统,多少人用了多长时间实现的啊

刘中兵:用了2年。

2、请问,白虎,雷达,红警是都是来源系统?还是自研平台?

刘中兵:猎聘动物园的系统,都是自研系统。

3、刚才您说以前是做工程管理的,请问你们的持续交付系统是如何和需求挂接的?如果某个项目的需求变化很频繁,或者有多个分支版本,你们也采用了什么平台吗?

刘中兵:持续交付目的是为了实现从产品需求交到用户手里的过程,这个过程越快、质量越高越好。所以为了这个过程,就要建设保障开发、测试、上线、运维的各种工具。我们同事测试的需求有几十个,每周上线数千次工程。需求和开发之间,其实就是产品文档。

4、我想了解下,对于每周上千次的上线的管理机制。相关工程之间的依赖性以及如果出现意外的回滚,这些是如何操作的?

刘中兵:我们项目依赖也很多,为了多个项目并行开发,所以我们线下管理了十来套完整的环境。因为我们的产品迭代真的很快。回滚的话,系统可以支持回滚。

5、你们各个系统都是独立运行?

刘中兵:各个系统之间有交互,都是API方式。比如变色龙为青龙、龙潭提供脚本执行能力,其中授权、权限、秘钥等必不可少的,跟一般的Open授权类似。

6、整套系统完成一次上线,需要多长时间? 好像是需要多个系统配合完成的。

刘中兵:开发阶段用线下凤凰,随时发布随时用,全套30分钟,单个项目几十秒。线上发布一般我们是批量一个需求拖几十个工程上线,发布人员就会批量选择几十个工程,批量点击发布,一次发布大概20分钟,是全站多个区的。

7、这些系统都是运维开发的么?

刘中兵:都是开发人员开发的,所以我们对开发人员要求还是比较高的,需要懂产品、懂业务、懂运营,甚至还得懂推销、销售,否则开发、运维那卖不掉。

8、回滚如果数据库结构变了,且用户产生了数据,如何做到整个版本库包括数据库脚本的回滚。

刘中兵:如果是数据库结构变了,回滚就需要开发人员主动改数据库了。这套系统只管代码的回滚。

9、批量的实现原理方便大体讲一下?

刘中兵:批量发布,就是选择比如50个工程,依次svn、mvn打包、编译、检测、发布。在发布时,为了防止某个项目发布导致用户不可用,我们会分区发布,我们分了ABC三个区。比如发布A区时,A区是没有用户流量的。

10、对于我们这种小公司,老师有没有什么好的建议?

刘中兵:其实猎聘网也是从小到大发展过来的,最开始我也提到,公司是从1--10--100--1000人发展过来的,我觉得1人不需要这些,10人需要简单工具,100人需要稍微体系化工具,再多就需要体系化了。1000人以上更需要现代化了。

11、我想问,这套体系如何进行问题的快速定位定界。尤其是服务化的体系架构,另外,服务的治理涉及了吗?

刘中兵:问题定位,我们为发布阶段、线上服务治理阶段,做了很对汇总的监控、质量检测工具,比如红警、雷达、青龙项目监控图等等。 服务治理,其中提到了SOA的Router服务发现,但对于服务的升级、降级、限流等,主要是策略上的。

12、支持git版本库和svn版本库的区别在哪里?还能支持别的商业的吗?

刘中兵:其实没有区别,就是下载代码的方式不同。对于脚本来说,就是svn和git指令不同。暂时没有其他的支持。

13、我觉得小公司初期最重要的是标准化。生产环境与测试环境统一标准,记录所有的环境配置。为以后运维工具化和自动化做准备。

刘中兵:这个很同意,越早做标准越好。我们推的还算早,但也很痛苦痛苦痛苦。

14、从小团队到千人规模,知识的传承是怎么实现的?人员流动是个大麻烦

刘中兵:只是传承,我们要求要写3种类型文档: 1、产品使用文档,面向用户的、流程 2、技术开发文档,面向自己技术架构流转的 3、系统接口文档,面向系统对接的外部开发者的