一份可以同时满足传统与互联网业务的Dev平台攻略

胥建英 2018-12-06 10:06:00
        作者介绍

胥建英,拥有八年云计算领域、云自动化运维、DevOps及微服务建设经验。

 

DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

 

本篇主要讲的是Dev环节的支撑平台。一套Dev平台如何同时支持传统企业交付模式以及互联网业务交付模式。关于支撑Ops阶段的平台涉及内容庞大复杂,后续会从数据中心Ops的角度展开论述。

 

关于本人对Dev与Ops环节的支撑平台的划分,大致为如下:

 

 

一、场景分析

 

互联网业务的特点是自开发、自运维,标准的Devops模式。从研发活动来看,涉及五个阶段:Code,Build,Test,Deploy,Monitor。每个阶段的职责不同。

 

 

传统IT业务的特点是研发团队负责开发交付,IT技术支持团队负责实施(部署、升级),客户负责运维,且传统IT企业交付的往往是一整套完整的解决方案。

 

 

相比较互联网业务模式,研发活动流程变成如下,增加了Assemble(装配过程):

 

 

也就是如何将开发团队的输出装配为面向客户交付的解决方案包。

 

两种场景下的共同诉求都是Devops理念中构建、测试,发布更加快捷、频繁、可靠。

 

1、Code阶段
 

 

核心目标是如何快速、低门槛地开发,同时对于QA来说,是要解决如何进行统计度量(代码量、产出率等)的问题。

 

快速、低门槛让开发尽可能只聚焦于核心业务逻辑的实现,更多的工程相关的属性依托于可视化、自动化的构筑生成。因此需要契约化的工程结构,以支撑后续的运行维护管理。

 

微服务架构模式下,微服务是最小的工程单元,因此也就是定义一种符合微服务的契约化的工程属性。微服务的特征要求具备独立可编译部署变更,对外需要清晰的API等。

 

 

因此可以定义譬如下面的开发工程的目录结构:

 

 

一般一个微服务的开发顺序可参照如下:

 

 

一般在设计阶段就需要输出API定义,传统的往往是Word或者Excel等定义,用于评审,然后开发阶段需要编写代码去定义,此部分则可以完全简化,基于YAML/JSON定义API文件,并基于Swagger直接可视化展示API用于评审,开发阶段同样基于此文件直接生成API代码和到业务逻辑的调用。最终开发者直接编写API的实现单元即可。

 

依托于契约化松耦合的目录结构,需要Devops平台具备如下的能力:

 

  • 微服务的初始化管理服务。微服务自身就是个后续需要被维护管理的对象,故而需要一个微服务管理的能力。包含:微服务定义,开发工程生成,以及关键指标的搜集(代码量、开发语言、责任人、提交次数等)。

  • 基于主流开发工具(Eclipse、IDEA)可一键式生成API代码。

 

微服务初始化管理服务(后续简称Codeinit)结构可大致表述为如下:

 

 

至此基于微服务管理服务的Code过程变为:

 

 

2、Build阶段
 

 

核心目标是检查原始代码的质量并编译生成可执行的包。

 

 

  • 下载代码:是指从代码仓库下载到编译服务器;

  • 门禁检查:包含契约化目录规范的检查,圈复杂度检查,FindBugs检查,代码样式检查等;

  • 编译:则是将原始代码生成二进制,使用语言自身的编译器完成,打包则是生成预期的最终可部署的包,其包含编译产生的二进制文件以及程序的配置文件等;

  • 推送:是指生成的包推送到包仓库(FTP服务器、镜像库等);

  • 统计:贯穿在整个Build阶段,是指Build阶段的各种度量指标,譬如编译次数、编译成功率等。

 

 

3、Assemble阶段
 

 

Assemble核心目标是微服务包到服务包,服务包到解决方案大包,或者微服务包到解决方案大包的自动化装配过程。需要一种契约化的包的装配规则的定义,包含目标包类型(解决方案、服务),包含服务或者微服务。最终客户拿到的是一个基于部署系统可部署的完整的大包,不用自己手动下载组装配套的多个包。

 

 

最终效果:研发团队视角提供微服务,形成一种原子能力的微服务池子,不同解决方案定义不同的微服务打包策略,基于Devops平台自动装配不同的解决方案包。

 

 

4、Deploy阶段
 

 

Deploy阶段隶属于Ops范围,涉及上下内容很多,后续详细展开论述,此部分只做概要介绍。

 

部署系统的核心目标是可视化/自动化地将解决方案包/服务包/微服务包部署到不同的环境的节点上。这里面涉及几个名词:包、部署动作、环境、节点,需要展开论述:

 

  • 包:指的是开发活动交付的软件的载体,可以是ZIP/镜像等。

  • 环境:指的是部署活动中涉及的Alpha (服务内自验证环境),Beta(服务间联调环境),Gamma(类生产环境),Product(生产环境)。

  • 节点:这里面定义的是在可直接部署包的介质,需要强调的是可直接部署性。一般性硬件和软件是分离的两拨人,一个数据中心内允许两次驻场:设备采购到位后,硬件调测人员进驻进行硬件安装配置;其次是软件调测人员驻场,进行操作系统安装及其之后的过程。

    而对于部署系统来说,此处部署的是软件包,并不包括OS安装配置,故而也就引出了另一个系统:独立的装机服务,此即为部署系统的其中一个上下文,但并非属于部署系统。但是实际往往也没有独立的装机服务,譬如节点如果全是虚拟机,而一般企业虚拟机的生命周期管理往往存在于独立的云管理平台中(物理机的初始化、OS安装、虚拟机发放)。此时云管理平台即可承载此处所需的装机能力。

 

 

5、Monitor阶段
 

 

DevOps模式下的Monitor隶属于Ops范围,涉及内容和上下文很多,其内容包含监控(硬件、OS、业务的性能、调用链、拨测),告警和故障诊断等,上下文涉及变更、事件、报表、通道等后续展开论述。

 

此处需要附加说明的是即使从Dev阶段也是需要Monitor能力的,也就是监控统计Code、Build、Assemble阶段的各个指标。

 

二、Dev平台技术调研分析

 

1、Docker
 

 

分析目标:基于上述Dev平台建设思路,Docker的目标在此处位于Build或Assemble阶段场景之一,也就是流水线环节中构建包(镜像),所以重点分析的是Docker镜像库及构建镜像的环节。但是不仅限于Docker,需要扩展分析支持带状态应用的下的容器技术(类似虚拟机形态的面向资源的容器的镜像模型和构建)。

 

2、Kubernates
 

 

分析目标:基于上述Dev(Ops)平台建设思路,Kubernates的目标在于Deploy阶段使用场景之一,也就是流水线环节中部署系统,重点分析基于Kubernates部署应用的流程、运行机制和部署架构。

 

3、Jekins
 

 

分析目标:基于上述Dev平台建设思路,Jekins的目标是自动化Code到Build或者Assemble阶段,重点分析其使用流程,Jekins的扩展性(譬如插件生态、二次开发能力等),用于决策整个Code->Assemble阶段是自研借鉴或者还是基于其二次开发。

 

4、Gerrit
 

 

分析目标:基于上述Dev平台建设思路,Gerrit的目标是Code阶段的代码Review,重点分析其使用方式(操作和角色权限控制)和环境部署,用于集成到整个Dev流水线之中。

 

5、Github
 

 

分析目标:基于上述Dev平台建设思路,此处主要是提供代码仓库,需要重点分析其使用方式、API(或Lib库)等,同时横向需要比较分析Gitlab,已决定采取何种构建代码仓库。

 

以上是关于Dev环节的支撑平台的概述,后续将从数据中心Ops的角度展开讲支撑Ops阶段的平台,欢迎大家留言交流。

活动预告