微服务生态体系建设之 三个火枪手（3） DevOps

本篇将介绍DevOps,以及比较成熟的狭义“DevOps”与微服务和容器技术的关系。

在讲DevOps之前，我们先分析一下，在软件生产的过程中，我们现在究竟遇到了什么问题？请看下面两幅图。（出自阿里云云栖社区）

相信这些问题正是我们各位项目经理和运维负责人的心结。

那怎么解决这些问题，我们就用DevOps。

我们先来看看DevOps在百度百科上的定义吧。

DevOps,即Development和Operations. 它是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。

我们再来看看IT部门的两个用来衡量软件开发的KPI指标：

1. 软件本身的质量
2. TTM（Time To Marketing）或者软件交付时间

由此可见，DevOps就是为了完成这两个KPI的。

这让我想起了我们公司正在实施的OTD项目，它的目标也是在保证生产质量的前提下，缩短从订单到交付的时间。实际上生产汽车和生产软件的KPI指标是一样的。

对于广义的DevOps来说，全流程如下图，它包含了敏捷的需求开发管理、持续集成、自动化测试、持续发布部署、持续运维、以及各个环节的敏捷的反馈。

而狭义的DevOps,关注点从代码提交开始，到代码部署到生产环境结束，即持续集成持续交付部署CICD部分。

1.代码提交和管理，（下图1,2,3）

2.持续集成：编译、单元测试执行、静态代码分析（下图4,5,6,7,8）

4.持续交付：打包发布部署到到各种测试环境（下图9,10,11,12,13,14,15）

5.持续测试：各种黑盒测试：功能、压力、安全等（下图尚未完全实现）

6持续部署：正式发布到生产环境（下图12,16）

7.持续监控运维：集成、测试、部署等过程的监控运维（下图尚未完全实现）

下图是我们目前建设的针对于容器云平台下的微服务应用的CICD全流程流水线的示意图。

         大家想想，假如我们把以上的1-7步串起来，就像生产汽车的流水线(pipeline)一样。我们把流水线的各个步骤定义在job里，然后交给机器人自动操作，只有在需要人工确认的地方才让相关人员参与，任何一个job一遍不通过,可以方便迅速地再来一遍，直到质量达到满意为止，那么我们的软件交付质量是不是可以大大提高，软件交付时间是不是可以大大缩小？

当然，要实现CICD并非易事，前提条件是，

1. 在持续集成CI那块，所用的开发架构要支持持续自动打包。而微服务开发使用的springboot能够基于pom.xml实现maven的持续自动打包。
2. 在持续交付CD那块，所发布的目标资源要有IaC（Infrastructure as Code）基础架构即代码的能力，可以通过代码来生成开发测试生产等环境。而容器技术提供了这个能力。

由此可见，微服务开发和CI持续集成是绝配，容器技术又和CD持续交付是绝配。第二篇文章又说了，微服务和容器是绝配。那么它们三个合在一起，就是真正的绝配了。他们仨就是“三个火枪手”组合：微服务、容器、狭义DevOps。

现在，我们隆重邀请CICD里的一号角色Jenkins先生登场。

对，Jenkins先生就是一个跑堂的，负责收拾布置餐桌、迎客、点菜、报菜名、传菜、卖单、送客、收拾布置餐桌，后厨在烧哪些菜，大堂有多少餐桌，几人位的餐桌分别有多少，不同的客户需要什么不同的流程，等等等等，这些事情他烂熟于心，所以客户对他很满意。

可问题来了，顾客现在越来越多、需求越来越多样化、菜品也越来越多、菜单天天更新、餐厅越来越大、顾客还想更多地自助、自己点菜、自己选位、自己买单。Jenkins先生开始忙不过来了，服务经常出错、三人位的桌子安排了6个人，菜单变更了，他却不知道，拿着旧菜单招呼客人…...这该怎么办？

这时候，我们就需要给Jenkins先生做个包装了，在他的前面做个平台，通过这个平台，各种资源、配置一目了然，不同服务流程可以让客户自己选择组装，各个环节的情况客户也能马上知道。这就是我们正在规划的敏捷开发部署平台，这个话题，留待以后细说。

最后，我强烈推荐大家读一下《凤凰项目—一个IT运维的传奇故事》这本DevOps的圣经级教科书。另外，infoQ上的一篇详解也相当不错。

下一篇，我将对“微服务生态体系建设之三个火枪手”进行一个简单的总结，敬请期待。

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！