【Sofice小司笔记】4 DevOps, CI, CD

DevOps

DevOps 这个词，其实就是 Development 和 Operations 两个词的组合。

它的目标：让开发人员和运维人员更好地沟通合作，通过自动化流程来使得软件整体过程更加快捷和可靠

在 DevOps 的流程下，运维人员会在项目开发期间就介入到开发过程中，了解开发人员使用的系统架构和技术路线，从而制定适当的运维方案。而开发人员也会在运维的初期参与到系统部署中，并提供系统部署的优化建议。

CI：持续集成，CD：持续交付

DevOps的起源

单体架构 + 瀑布模式

这个时候只有开发人员 ，没有运维人员，开发人员就是全栈，项目开发好，找台服务器安装好环境，把 jar 包丢到远程服务器，放上去开启服务就可以。

这个时候服务监控也简单，服务出了问题，直接去线上看一下运行日志，为了解放双手监控服务，开发者会写一些脚本分析日志，服务器少，部署简单，通常开发就可以完成运维的工作，不需要专门的运维来做部署，所以开发模式很简答，直接按照瀑布流方式开发就可以。

分布式架构 + 敏捷开发模式

随着业务体量发展越来越大，一台机器扛不住，那么就加机器，单机变多机，业务架构也开始加入了 nginx，cdn 缓存等通用基础服务，业务变多肯定会招人，就涉及到多人协同开发，多人多机器模式。但是这个时候也不是 DEVOPS，而是 DEV+OPS，这时 Ops 的主要职责就是：硬件维护、网络设备维护、DBA 、基础服务维护、数据监控等，运维们擅长写各种部署，监控脚本，减少机械的重复工作，开发模式变成了敏捷开发模式。

• 敏捷开发的核心理念

  既然我们无法充分了解用户的真实需求是怎样的，将一个大的目标不断拆解，把它变成一个个可交付的小目标，然后通过不断迭代，以小步快跑的方式持续开发。另外，一个项目是很大的，为了保证项目质量，测试环节不可减少，为了加快速度增大开发效率，测试的工作最好是和开发同步交替进行的，需要将测试环节从后面注入到整个开发环节当中，每次可交付的都是一个可用的功能集合，对开发交付的内容进行持续验证。

• 多人协同开发问题

  人员一多，为了更好的分工，大多会将项目进行拆分，每个人负责专注于一部分。

• 多机器问题

  之前机器很少架构简单的时候，开发就可以干运维的活，就算加了几台服务器，那也是脚本将 JAR 包同时发布到这些机器上，好像也挺简单，但是会有两个人同时上线部署被覆盖的问题。

  公司业务一大，像大公司的动不动就是几千台服务器，就需要专门的运维介入了，一方面是因为开发分工每个人都专注于自己的事情，不会那么用心进行维护，另一方面是运维的学习成本确实变高了，开发人质量参差不齐。

微服务架构 + DevOps

将项目拆成一个个小的服务单独部署，拆分部署催生出 DevOps。一个微服务有新需求时，进行一轮DevOps即可。

DevOps 常用的工具

• Git
• Jenkins：开源的 CI/CD 服务器，帮助用户自动化交付流水线的不同阶段。Jenkins 之所以流行的主要原因是其巨大的插件生态系统。目前，它提供 1000 多个插件，因此它可以和几乎所有 DevOps 工具集成
• Docker
• Kubernetes：容器编排平台，将容器化推进到下一个层面。它可以使用 Docker 或者其他替代产品。使用 Kubernetes 用户可以将容器组织成逻辑单元。如果你只有几个容器，那么可能并不需要容器编排平台。但是，当系统达到一定级别的复杂度，需要扩展资源的时候，这就是合理的下一步。Kubernetes 让用户可以自动化管理上百个容器的过程。