DevOps是什么呢？

有人说它是一种方法，也有人说它是一种工具，还有人说它是一种思想。更有甚者，说它是一种哲学。

说的有点玄乎，我们看看DevOps的维基百科定义是这样的：

DevOps是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

软件工程方法论演变

一个软件从零开始到最终交付，大概包括以下几个阶段：规划、编码、构建、测试、发布、部署和维护。

image-20210508145243566

随着软件产业的日益发展壮大，软件的规模也在逐渐变得庞大。软件的复杂度不断攀升。一个人已经hold不住了，就开始出现了精细化分工。

码农的队伍扩大，工种增加。除了软件开发工程师之外，又有了软件测试工程师，软件运维工程师。

image-20210508145436254

分工之后，传统的软件开发流程是这样的：

软件开发人员花费数周和数月编写代码，然后将代码交给QA（质量保障）团队进行测试，然后将最终的发布版交给运维团队去布署。所有的这三个阶段，即开发，测试，布署。

早期所采用的软件交付模型，称之为“瀑布（Waterfall）模型”。

image-20210508145559418

瀑布模型，就是等一个阶段所有工作完成之后，再进入下一个阶段。

随着时间推移，用户对系统的需求不断增加，与此同时，用户给的时间周期却越来越少。在这个情况下，大家发现，笨重迟缓的瀑布式开发已经不合时宜了。

于是，软件开发团队引入了一个新的概念，那就是大名鼎鼎的——“敏捷开发（Agile Development）”。敏捷开发在2000年左右开始被世人所关注，是一种能应对快速变化需求的软件开发能力。其实简单来说，就是把大项目变成小项目，把大时间点变成小时间点，然后这样：

image-20210508150051963

敏捷开发大幅提高了开发团队的工作效率，让版本的更新速度变得更快，而项目风险更低。

image-20210508150125083

虽然敏捷开发大幅提升了软件开发的效率和版本更新的速度，但是它的效果仅限于开发环节。研发们发现，运维那边，依旧是铁板一块，成为了新的瓶颈。

运维工程师，和开发工程师有着完全不同的思维逻辑。运维团队的座右铭，很简单，就是“稳定压倒一切”。运维的核心诉求，就是不出问题。什么情况下最容易出问题？发生改变的时候最容易出问题。所以说，运维非常排斥“改变”。于是乎，矛盾就在两者之间集中爆发了。这个时候，我们的DevOps，隆重登场了。

image-20210508150434009

DevOps不是某一个特定软件、工具或平台的名字。从目标来看，DevOps就是让开发人员和运维人员更好地沟通合作，通过自动化流程来使得软件整体过程更加快捷和可靠。想要充分落地DevOps，当然离不开软件和平台的支持。

image-20210508150729149

DevOps生态圈中令人眼花缭乱的工具；上述这些关键要素里面，技术（工具和平台）是最容易实现的，流程次之，思维转变反而最困难。

换言之，DevOps考验的不仅是一家企业的技术，更是管理水平和企业文化。

对比前面所说的瀑布式开发和敏捷开发，我们可以明显看出，DevOps贯穿了软件全生命周期，而不仅限于开发阶段。

image-20210508150935032

下面这张图，更明显地说明了DevOps所处的位置，还有它的价值：

image-20210508151003032

软件开发架构演变

软件开发架构的演变大致分这4个过程：单体 -> 分层MVC -> 面向服务SOA -> 微服务。

  • 单体(Monolithic)架构：是最简单的软件架构，常用于传统的应用软件开发以及传统 Web 应用，适用于用户业务不复杂、访问量较小的时候。开发人员将数据处理和UI界面展示代码全部糅合在一起，整体开发测试和发布。

image-20210508153118380

  • MVC (Modle View Controller) 架构： 当业务规模很小时，将所有功能都部署在同一个进程中，通过双机或者前置负载均衡器实现负载分流；此时，用于分离前后台逻辑的 MVC 架构是关键。
  • RPC (Remote Procedure Call)架构：当垂直应用越来越多，应用之间交互不可避免，将核心和公共业务抽取出来，作为独立的服务，实现前后台逻辑分离。此时，用于提高业务复用及拆分的 RPC 框架是关键。
  • SOA (Service Oriented Architecture)架构：随着业务发展，服务数量越来越多，服务生命周期管控和运行态的治理成为瓶颈，此时用于提升服务质量的 SOA 服务治理是关键。
  • 微服务架构：随着敏捷开发、持续支付、DevOps 理论的发展和实践，以及基于 Docker 等轻量级容器 (LXC) 部署应用和服务的成熟，微服务架构开始流行，逐渐成为应用架构的未来演进方向。通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队敏捷交付，应用的交付周期将缩短，运营成本也将大幅下降。

下面是另外一种架构演变的描述，供参考：

image-20211021133204289

注意不要被这些专业概念迷糊了双眼，我们架构设计的三大原则是：简单、适度、演化。适合的才是好的。

DevOps与虚拟化、容器、微服务

这几年云计算技术突飞猛进，大家应该对虚拟化、容器、微服务这些概念并不陌生。当我们提到这些概念的时候，也会偶尔提及DevOps。

它们之间有什么联系呢？大家可以设想一下，如果要对一项工作进行精细化分工，我们是对一个大铁疙瘩进行加工方便？还是拆成一块一块进行加工更加方便？

显然是拆分之后会更加方便。所谓“微服务”，就是将原来黑盒化的一个整体产品进行拆分（解耦），从一个提供多种服务的整体，拆成各自提供不同服务的多个个体。

微服务架构下，不同的工程师可以对各自负责的模块进行处理，例如开发、测试、部署、迭代。而虚拟化，其实就是一种敏捷的云计算服务。它从硬件上，将一个系统“划分”为多个系统，系统之间相互隔离，为微服务提供便利。容器就更彻底了，不是划分为不同的操作系统，而是在操作系统上划分为不同的“运行环境”（Container），占用资源更少，部署速度更快。

虚拟化和容器，其实为DevOps提供了很好的前提条件。开发环境和部署环境都可以更好地隔离了，减小了相互之间的影响。这也是DevOps为什么2009年时不火，现在越来越火的一个主要原因之一。

DevOps工具集

DevOps平台的搭建可通过如下工具进行实现，具体安装步骤可参考链接：

项目管理（PM）：Jira

代码管理：GitLab

持续集成（CI）：GitLab CI

镜像仓库：VMware Harbor

容器：Docker

容器平台： Rancher

镜像扫描：Clairctl

编排：Kubernetes

服务注册与发现：etcd

脚本语言：Python

日志管理：ELK

系统监控：Prometheus

Web服务器：Nginx

数据库：MySQL+Redis+Mongo

最后的话

时代在发展，客户的需求瞬息万变，市场的风向也难以预测。作为企业，想要生存下去，只有让自己变得更快。作为员工，特别是软件工程从业者，需要不断学习新知识，提升自己的眼界，能够快速合理的用自己的专业知识解决客户需求，提高企业运营效率，降低运营成本才是硬道理。

（完）