您现在的位置是:网站首页> 内容页

天马行空-DevOps平台建设概述

  • 金沙官网登录
  • 2019-05-20
  • 254人已阅读
简介概述DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作

概述

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

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

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

 

场景分析

互联网业务的特点是自开发,自运维,标准的devops模式,从研发活动来看,涉及五个阶段,code,build,test,deploy,monitor。每个阶段的职责不同。

 

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

 

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

 

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

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

Code阶段

核心目标是如何快速,低门槛的开发,同时对于QA来说,如何可进行统计度量(代码量,产出率等)。而快速,低门槛则尽可能让开发只聚焦与核心业务逻辑的实现,更多的工程相关的属性依托于可视化,自动化的构筑生成。因此需要契约化的工程结构,以支撑后续的运行维护管理。微服务架构模式下,微服务是最小的工程单元,因此也即是定义一种符合微服务的契约化的工程属性。微服务的特征要求具备独立可编译部署变更,对外需要清晰的API等。

 

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

 

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

 

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

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

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

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

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

 

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

 

Build阶段

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

 

下载代码:是指从代码仓库下载到编译服务器门禁检查:包含契约化目录规范的检查,圈复杂度检查,findbugs检查,代码样式检查等。编译:则是将原始代码生成二进制,使用语言自身的编译器完成,打包则是生成预期的最终可部署的包,其包含编译产生的二进制文件以及程序的配置文件等。推送:是指生成的包推送到包仓库(FTP服务器,镜像库等)。统计:贯穿在整个Build阶段,是指Build阶段的各种度量指标,譬如编译次数,编译成功率等。

 

 

Assemble阶段

Assemble核心目标是微服务包到服务包,服务包到解决方案大包,或者微服务包到解决方案大包的自动化装配过程。

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

 

 

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

 

 

Deploy阶段

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

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

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

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

节点:这里面定义的是在可直接部署包的介质,需要强调的是可直接部署性。一般性硬件和软件是分离的两拨人,一个数据中心内允许两次驻场,以此是设备采购到位后,硬件调测人员进驻进行硬件安装配置,其次是软件调测人员驻场,进行操作系统安装及其之后的过程,而对于部署系统来说,此处部署的是软件包,并不包括OS安装配置,故而也就引出了另一个系统:独立的装机服务,此即为部署系统的其中一个上下文,但并非属于部署系统。但是实际往往也可能没有独立的装机服务,譬如节点如果全是虚拟机,而一般企业往往虚拟机的生命周期管理存在与独立的云管理平台中(物理机的初始化,OS安装,虚拟机发放)。此时云管理平台即可承载此处所需的装机能力。

 

Monitor阶段

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

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

Dev平台技术调研分析

Kubernates/Docker,

Jekins

Github

 

 

 

 

 

 

1 0 9)

文章评论

Top