华为云DevOps系列之 —— DevOps概览（二）新型软件技术及交付模式

新兴软件技术及交付模式

1. 云原生与微服务简介

1）云原生

概念

单机->分布式->云计算

• 企业的云化，不仅仅是基础设施和平台的升级，应用也需要摒弃传统的设计方法 架构设计->开发方式->部署维护 ，整个生命周期都基于云的特点设计，构建原生为云而设计的应用，充分利用的发挥云平台的弹性以及分布式优势，这就是 云原生
• 全新技术
  • 容器
  • 微服务
  • 服务网格
  • …

云原生定义 —— Cloud Native关键特征

• 云环境下构建、运行、管理软件的新的 系统实践范式
• 充分利用云基础设施与平台服务
• 具备 微服务化、弹性伸缩、分布式、高可用、多租户、自动化 等关健特征
  

云原生应用

• 专为云模型构建
• 云原生应用系统与操作系统等基础设施分离，不依赖Linux/Windows等底层平台或依赖某个云平台
• 满足扩展性需求（垂直扩展/水平扩展）
• CNCF（云原生计算基金会）给出的云原生三大特征
  • 容器化封装
  • 动态管理
  • 面向微服务
• 云原生应用12要素
  • 基准代码：一份代码库对应多份部署，所有部署的基准代码相同（每份部署可以使用不同的版本）
  • 依赖：声明依赖项（应用：生产、开发环境）
  • 配置：环境中存储配置（推荐将配置存储在环境变量中，方便部署修改，环境变量与语言和统计无关）
  • 后端服务：每个后端服务是一个资源（eg：一个MySQL数据库是一个资源，两个MySQL数据库是两个不同的资源）
  • 构建，发布，运行：严格区分这三个步骤（eg：直接修改运行中的代码非常不可取 —— 很难同步回构建步骤）
  • 进程：应用程序通常是以一个或多个进程运行的
  • 端口绑定：通过端口绑定提供服务
  • 并发：通过进程模型进行扩展
  • 易处理：快速启动、优雅终止、最大化健壮性，有利于快速弹性的伸缩应用
  • 开发环境与线上环境等价：尽可能保持开发预发布线上环境相同
  • 日志：当作事件流
  • 管理进程：后台管理任务当作一次性进程运行
    

2）微服务

概念

单体架构（Monolithic）：一个归档包（eg：war包/jar包），包含了所有功能的应用程序，部署简单，技术单一，用人成本低
随着互联网发展单体架构出现的缺陷

• 复杂性高，单体架构包含模块多，边界模糊，依赖关系不清晰，代码质量参差不齐，项目复杂，修改代码比较困难
• 技术债务逐渐上升：需求更迭、人员更迭，已使用的系统设计/代码难以修改（应用程序的其他模块可能以意料之外的方式使用它）
• 部署速度逐渐变慢：代码增加——>构建、部署时间增加，每次功能变更/Bug修复都需要重新部署整个应用（全量部署耗时长，影响范围大、风险高）
• 扩展能力受限，无法按需伸缩（单体应用只能作为一个整体进行扩展，无法结合业务模块的特点进行伸缩）
• 阻碍技术创新：一般使用统一的技术平台/方案解决所有问题，所有成员使用相同的开发语言和架构，引入新的框架/技术平台非常困难

 
由于单体架构以上缺陷，越来越多公司采用 微服务架构范式 解决上面的问题

• 将单个应用程序开发为 $\color{red}一组小型服务$
• 每个小型服务都 $\color{red}在自己的进程中运行$，通过轻量机制通信（通常是HTTP资源API）
• 服务 $\color{red}围绕业务功能进行构建$
• $\color{red}独立部署$
• 可以使用 $\color{red} 不同的编程语言$
• 可以使用 $\color{red}不同的数据存储技术$
• 服务仅做 $\color{red}最低限度的集中管理$

优势

• 微服务可以将应用拆分成多个核心功能，每个功能称为一项服务，可以 $\color{red}单独构建和部署$
• 缩短TTM（Time To Market）时间
• 有助于实现更加敏捷的部署和更新（开发时间缩短）
• 高度可扩展（跨多服务器等）
• 弹性伸缩（独立服务不会彼此影响），一个服务出现故障，不会导致整个应用下线
• 易于部署（模块化）
• 易于访问
• 更加开放（多语言API，自由选择语言技术）

劣势

• 运维要求较高（单体服务只需要保证一个应用的运行，微服务中，要保证几十甚至几百个服务的正常运行与协作）
• 分布式固有的复杂性（系统容错、网络延迟、分布式事务等）
• 接口调整成本高（微服务通过接口通信，若修改某个微服务的API，可能所有使用了该接口的微服务都需要做调整）
• 重复劳动（很多服务可能使用相同的功能，而这个功能没有达到分解为一个微服务的程度，这时可能各个服务都会开发这一功能，导致代码重复）

2. 敏捷与DevOps

1）敏捷

敏捷软件开发宣言

• 价值观
  • 个体和互动 高于 流程和工具
  • 工作的伙伴 高于 详尽的文档
  • 客户合作 高于 合同谈判
  • 响应变化 高于 遵循计划

  尽管右项有其价值，我们更重视左项的价值

• 十二原则
  

可工作的软件是进度的首要度量标准

价值驱动 - 敏捷与传统瀑布型模式的最大区别

敏捷常用的工程方法

• 以Scrum为基础的方法论居于主流地位，使用率最高
• 其他的还有：看板方法、精益创业、极限编程等
• 小众方法论：DSDM、FDD、RAD
  

2）DevOps

• Devops，一方面它本身代表了一种运动，世界范围、行业范围内去推动这种文化和工作方式，另一方面也是代表了强调打 破部门墙， $\color{red}开发和运维$通力协作的文化，以及具体如何协作、更快交付业务价值的交付方式、协作方式。

DevOps的概念

• 维基百科：DveOps
• DevOps，是一种重视 $\color{red}软件开发人员（Dev）$和 $\color{red}IT运维技术人员（Ops）$之间沟通合作的文化

为了按时交付软件产品和服务，开发和运维工作必须紧密合作
DevOps可以看作是开发、运维和质量保证 三者的交集

DevOps专家的观点

• DevOps $\color{red}打破开发与运维之间的孤岛$
  

• DevOps $\color{red}通常指的是新兴的专业化运动$
  

DevOps领先企业的观点

DevOps生命周期过程

• 文化：是建⽴一体化的全功能团队， 打破开发(Dev)与技术运营(Ops)隔阂，形成DevOps的协同合作的文化氛围
• 自动化：从构建到运维过程的自动化
• 精益：小步快跑，持续改善
• 度量：建⽴有效的监控与度量手段快速获得反馈，推动产品和团队的持续改进
• 分享：不同职能、不同产品之间经验分享能够促进DevOps的文化沉淀，促进 产品迭代和更新。
  
• 计划阶段：运维人员为开发人员提供需求，并制定发布计划
• 编码/构建/验证阶段：Scrum、极限编程和精益生产，持续集成、自动化测试等
• 部署阶段：开发团队负责部署、监控部署过程，以及部署后的运行

DevOps 收益与价值

• 《2019 DevOps 状态报告》
• DevOps Eilite组织 VS DevOps Low组织
  • $\color{red}208$ 倍的代码部署频率
  • $\color{red}106$ 倍的代码到部署时间效率
  • $\color{red}1/2604$ 的故障恢复时间
  • $\color{red}1/7$ 的变更失败率

• 变更失败率指软件发布后不可用或者服务质量 出现不可接受的性能下降
• 故障恢复时间指从现网发现问题，到故障全部恢复的时间

DevOps持续交付实施框架

• 发布频率不同，工作方式或者具体实践是很不同的，如 果要从100天发布一次的水平提升到一天发布100次的水平，在这七个领域都有很多 改进动作需要落实才能做到
  

3）敏捷和DevOps关系

• EXIN（国际信息科学考试学会）的DevOps Master白皮书，下图为DevOps知识体系图，它将DevOps诠释为如下四个部分
  • 敏捷管理：包含计划、需求、设计、开发
  • 持续交付：包括开发、部署、运营
  • IT服务管理：包括运营、周期终止
  • 精益管理：从计划到周期终止的全程

• DevOps不是对敏捷的否定，而是融合了敏捷和精益的思想和方法，并在其基础上的进一步发展

敏捷与DevOps关系——DevOps覆盖端到端交付周期

• 从交付全流程的覆盖范围看，经历了敏捷开发、持续集成、持续交付、DevOps四 个重要阶段
  • 敏捷开发
    • 拥抱变化
    • 快速迭代
  • 持续集成
    • 提交新代码后，自动构建和测试
    • 保障最终代码没有问题
  • 持续发布
    • 集成后的代码自动部署到类生产环境中
    • 评审通过的代码进入生产阶段
    • 持续部署是持续交付的最高阶段
  • DevOps
    • 更快的交付周期
    • 更高效的交付流程
    • 重视客户体验
    • 保障软件质量

最后，欢迎大家关注我的个人微信公众号 『小小猿若尘』，获取更多IT技术、干货知识、热点资讯。同时，我在公众号中分享了精心整理的一些视频资料（包括 Python全栈教程、AI教程、前端、数据库等），大家回复相应关键词即可获取网盘视频链接，感谢大家的关注😊