震坤行DevOps工程效能演进之路

1. 什么是DevOps

DevOps是一种软件开发方法,涉及软件在整个开发生命周期中的持续开发,持续测试,持续集成,持续部署和持续监控。

DevOps目的是更快速,更可靠地创建质量更好的软件,同时在开发、测试、运维团队之间形成自动化的协同.

在近期中国信通院(CAICT)发布的《中国DevOps现状调查报告(2019年)》(以下简称报告)中,超八成企业表示,通过采用DevOps获得了研发效率的显著提升。正是因为DevOps能够给企业开发带来诸多益处,目前,DevOps已经成为企业软件研发的主流,被众多行业企业所采用。

2. 震坤行DevOps规划

2.1. 设计原则

震坤行的DevOps以容器化技术为支撑,基于微服务架构来设计,实现集中化管控,并为上层应用系统提供 基础技术服务和公共业务组件服务,整体架构遵循以下设计原则:

1.先进性和成熟性。互联网技术发展迅速,新的技术不断涌现并趋于成熟,系统设计需要在满足实用性的基础上,立足高起点,选用先进性和成熟性融合较好的技术,既能确保平台领先,满足3-5年的技术发展需要,也要保证经过较好的实践验证。

2.开放性与标准化。平台选用的所有产品和技术都需要符合国际、国内相关标准,是开放的可兼容系统, 并能与不同厂商的产品兼容,以有效地保护投资。因此在总体设计中应秉承开放式、松耦合、标准化设计原则,使系统有适应外界环境变化的能力,易于调整、扩充和组合,最大限度满足业务要求。

3.可靠性与安全性。安全可靠的运行是整个系统建设的基础。提供良好的安全可靠性策略,支持多种安全可靠性技术手段,制定严格的安全可靠性管理措施。要配置严密的数据安全体系,避免非法入侵,确保系统数据的准确性、正确性,防止异常情况的发生。

4.可维护性和易用性。提供界面化的管理工具,实现对系统的日常维护,同时提供及时可靠的告警和通知机制,实现对问题和故障的预警和及时通知。

5.运营流程的敏捷性与规范性原则。系统具备开发更新的敏捷性,能够敏捷地支撑各类复杂业务的交付。因此,平台具备一个高效的流程设计和管理工具就成为一个必要的条件,保障业务开发过程能够规范、 高效、快捷。

2.2. 总体规划

基于以上设计原则,制定了3+1(三个平台+一套开发脚手架)的总体规划

容器云平台

作为底层支撑,以容器技术为主,旨在为上层提供统一的资源池管理与调度。将CPU,内存,网络,存储等变成可以通过代码管理的资源服务,可以理解为我们自己的简单私有云。容器云是DevOps的重要基础,没有容器云提供的可伸缩,自服务,虚拟化的体系,DevOps理念只能是纸上谈兵。

微服务平台

提供微服务架构的基础设施,包括服务注册和发现,安全中心,配置中心,服务网关,熔断限流中心,metrics,log和tracing信息的收集、展示、监控、报警等。使开发团队可以将精力集中在业务逻辑开发上,其它与业务无关的技术工作由平台统一处理赋能给应用开发者。

DevOps平台

作为可视化平台,将容器云平台、微服务平台和开发脚手架集成起来,屏蔽掉技术细节,提供给开发人员使用。以流程自动化、工具自动化为主要手段,为最终业务交付提供更敏捷、更数字化的能力。开发人员借助DevOps平台的开发流水线,可以实现从代码提交,代码检查,自动化编译,镜像打包,版本控制到自动化部署,自动化测试等一系列的开发、测试、和交付工作,并借助智能运维,促进业务支撑系统集中统一的运营和管理。

开发脚手架

旨在尽量多地包含日常开发之所需,减少开发者的重复性工作以及提供一些最佳实践。并通过开发脚手架来统一技术栈,固化一些日常的开发规范。

2.3. 实施规划

1. 第一阶段: 容器云基础平台搭建

• 架构设计、集群设计、资源管理设计
  

• 搭建容器云基础平台和容器云管理平台,建立服务控制中心
  

• 打通容器云平台与IaaS层资源(主机、网络、存储)的统一管理接口。

2. 第二阶段: 微服务化和容器化改造

• 平台基础组件(MySql、Redis、微服务基础设施等)的微服务化和容器化设计、改造、迁移和部署。
  

• 平台业务组件的微服务化和容器化设计、改造、迁移和部署。
  

3. 第三阶段: 应用项目分批迁移

• 应用项目的分批、分阶段迁移和部署,分析并选取部分应用项目,迁移到容器云平台。  
  

• 验证应用在容器云平台运行稳定性,积累系统迁移经验。
  

• 建立标准化的镜像打包规范、应用开发规范、应用运营管理规范、运维手册等。
  

4. 第四阶段:统一管理、持续运营

• 将微服务设计、开发、构建、部署、上线等过程与DevOps管理流程和工具结合起来,实现持续集成和交付流水线,建立DevOps过程管理规范。
  

• 建立基于机器学习的智能运维,实现自动巡检,日常任务自动化,实现业务趋势预测和运维助手机器人。

2.4. 技术架构

架构方案以Docker容器为承载,微服务架构为支撑,结合Kubernetes作为集群管理平台,既适合当前业务支撑系统发展的实际需求,又具有支撑未来业务高速发展的先进性。

2.5. 技术选型

1.应用层:开发基于微服务的容器化业务服务。

2.服务层:内置基础类的企业服务,满足应用的各种基本技术需求,包括: Tomcat, Kafka, RabbitMQ, Redis, Nginx, Spark, Flink, Flume, ES等.

3.平台管理层:以开源技术Docker,Kubernetes,Istio为核心引擎,在其基础上自主开发Devops平台,提供简便的一键式自动化安装部署、应用灰度发布、镜像全生命周期管理、配置管理,以及基于容器、应用、服务、资源等不同视角的综合监控,集成了GIT-Lab、Sonarqube、Jenkins、Katalon、TAPD、Grafana等一些列的管理工具,实现开发运营一体化。

4.数据层: 数据存储在MySQL、Hadoop、MongoDB等开源存储系统中管理。

5.资源层: 几百台x86,分布在不同的物理地域的多个数据中心。

该技术框架符合公司IT战略规划要求,并适应IT互联网化发展趋势。该开源架构在大并发业务量下的稳定性 和吞吐性能已通过生产验证,各方面性能(可靠性、扩展性、安全性、可维护性等)表现优秀。

3. 震坤行DevOps现状

震坤行自2018年四季度启动整个DevOps规划落地的研发工作,经过一年的开发和建设,3+1的总体规划初步落地。

3.1. 容器云平台

震坤行容器云平台基于Google的开源项目kubernetes(k8s)搭建,k8s于2016年发布1.0版本并以惊人的 速度发展,2018年,k8s彻底击败其它竞争对手,成为容器编排领域的事实标准。包括BAT在内的众多一线互联网公司都在热情的拥抱k8s,并基于k8s来构建自己基础架构。目前震坤行在阿里云和公司自建机房中一共建立了3个k8s集群,分别用于开发,测试和生产。随着容器云平台的建成,为公司的基础架构提供了以下特性:

1.低成本。目前震坤行运行的应用实例总数达上千个。如果使用传统的虚拟机技术或云服务器支撑这种规模的集群,需要购买几百台服务器并投入大量的运维成本。由于容器云平台的建成,目前只用了七十多台服务器,就支撑了这上千个应用实例的运行,极大的降低了服务器购买成本和运维成本。

2.高效率。传统的上线流程中,需要提交服务器购买申请,购买服务器,安装和配置环境等工作,耗时以小时甚至以天记算。而在容器云中,只需一键既可完成整个流程,耗时以秒计算。

3.隔离底层的云服务提供商。由于我们的应用是运行在自己的容器云上,所以可以在不同的底层云服务商 (如阿里云、腾讯云)之间无缝切换,而不需要应用做任何的改造。

3.2. 微服务平台

微服务管理是DevOps的核心,在DevOps对多系统、多应用、多服务的集中协同管理中,我们引入微服务架构来进行服务的治理。震坤行的微服务应用管理架构如图所示。

各系统业务应用以微服务的形式部署在容器云平台之上,由平台统一管理,主要实现:

1.微服务应用注册、发现、编排、升级、回退、伸缩和漂移。基于K8S实现。

2.微服务应用配置统一管理。基于Apollo实现。

3.微服务应用入口统一管理。基于Envoy实现,通过k8s的服务注册获取服务信息并分发请求。

4.微服务应用认证、鉴权、授权、审计。基于Spring Security OAuth自研。

5.微服务应用熔断、降级、隔离、流控。基于阿里的开源项目Sentinel实现。

6.微服务应用定时任务统一调度。基于开源项目xxl-job实现。

7.微服务应用数据库同步。基于阿里的Otter+Canal实现。

8.微服务应用异步通讯。基于RabbitMQ传递业务相关消息,基于Kafka传递metrics,log等非业务相关的消息。

9.服务平台metrics的统一采集、监控和报警。基于Prometheus + Grafana + AlertManager实现

10.微服务平台log的统一采集、展示和查询。基于ElasticSearch + Filebeat + Kibana实现

11.微服务平台tracing信息的统一采集、展示和查询。基于Pinpoint和阿里的ARMS实现。

12.微服务应用流量管理。基于Istio实现。

业务开发人员在基于微服务的容器云平台之上,通过服务拼装,可以快速实现业务能力上线,快速响应业务变革,不再需要等待漫长的IT改造时间。只有采用微服务架构,才能使DevOps的持续开发流水线发挥更大的优势,通过DevOps持续集成理念,支 撑上层服务的全生命周期管理,从根源上提速应用微服务的开发、变更、部署、测试和上线效率。

3.3. DevOps平台

DevOps平台立项初期,曾考虑过购买某第三方devops平台,经过评估后发现主要有两个问题,一是每年需要上百万的资金投入,二是会和某一个共有云深度绑定。最终管理层决定自研DevOps平台,优先解决研发的痛点问题,再逐步覆盖整个研发流程。

震坤行自研的DevOps平台于2019年三季度上线,截止目前(2019年四季度)为止,80%的自研项目已经或正在接入DevOps平台,平台每天处理上百次流水线部署任务。

开发人员借助DevOps平台的开发流水线,可以实现从代码提交,代码检查,自动化编译,镜像打包,版本控制到自动化部署,自动化测试等一系列的开发、测试和交付工作,并借助智能运维,促进业务支撑系统集 中统一的运营和管理。DevOps平台和容器云平台集成管理工作流程如图所示:

DevOps平台集成了各种开源组件实现 CI/CT/CD (持续集成、持续测试、持续交付)的全过程管理。整个过程可以依托平台自动化工具一键完成,大大提升了应用发布效率,并且在效率提升的同时保证质量,降低了业务风险。与可视化监控工具集成,提供了开发代 码质量、版本发布、测试结果、缺陷修复、运维监控指标等整个开发过程的可视化监控和管理。如下图所示 :

3.4. 开发脚手架

整个脚手架由3部分组成。

第一部分是一个SpringBoot的项目脚手架。这个脚手架的源码是公司gitlab上的一个SpringBoot项目,然后我们把这个项目做成Maven的archetype模板,开发人员可以使用这个模板参数化的定制脚 手架并生成自己的项目。脚手架的存在目的是解决一些jar包依赖不能解决的问题,比如建立标准的目录结构 、提供一些常用的脚本,展示一些常见场景的代码处理示例等等。

第二部分是zaf框架。zaf框架本质上是一组存放于公司maven私服上的jar包,每个jar包提供了一种日常开发 中常用的能力,比如接入配置中心,接入消息队列,发送邮件、短信等等。开发人员可以在项目的pom中引 入这些jar包的dependency,从而获得相应的能力。

第三部分是一个VUE+NodeJs的前端项目的脚手架。用来帮助初始化前端项目,统一前端技术栈。原则上,所有能通过依赖jar包解决的问题或提供的能力,都应该通过zaf框架来提供,只有jar包依赖解决不了的问题,才应该放到脚手架项目中解决。脚手架项目尽量做到轻量级。结合DevOps平台和开发脚手架可以自动实现以下特性

4. 震坤行DevOps展望

4.1. 单件流

研发效率提升如上图所示,从传统的瀑布开发模式转到敏捷开发模式,一个需求从进入开发到部署上线,耗时从两个月缩短到两周。这个转变,可以靠更紧密的沟通,更高的工作强度来实现。从敏捷到DevOps,可以把这个时间缩短到两天,而这个转变,光靠人是不行的,必须要有强大的工具链支 撑,把测试、部署等能力赋能给开发并高度自动化才有可能实现。而提供并不断完善这个工具链,使震坤行的应用开发工作最终达到精益制造理论中效率最高的状态:单件流。就是DevOps的主要目标之一。通过DevOps的落地,我们将把复杂的工作简单化,简单的工作标准化,标准的工作流程化,流程的工作自动化,自动的工作智能化.

4.2. aiDevOps

随着人工智能的快速发展,AI介入DevOps中的趋势越来越明显,在此基础上,DevOps的发展趋势也将呈现由零散到整合,由自动化到智能化的变化过程。事实上,现在已经有不少组织开始在运维方面运用人工智能的方法使传统运维变的智能化。例如:循环神经 网络(Recurrent Neural Network,RNN)可以对日志和工单文本进行分析,也可以对时序数据进行预测。自编码器可以进行异常检测等，随着震坤行DevOps工作的逐步推进,DevOps将部分运维工作整合到开发,而剩下的工作将以智能化运维 的方式代替,即所谓的AI+DevOps:aiDevOps。