新兴软件技术及交付模式

1. 云原生与微服务简介

1）云原生

概念

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

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

• 全新技术

• 容器

• 微服务

• 服务网格

• ....

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

• 云环境下构建、运行、管理软件的新的 系统实践范式

• 充分利用云基础设施与平台服务

• 具备 微服务化、弹性伸缩、分布式、高可用、多租户、自动化 等关健特征

• 

云原生应用

• 专为云模型构建

• 云原生应用系统与操作系统等基础设施分离，不依赖 Linux/Windows 等底层平台或依赖某个云平台

• 满足扩展性需求（垂直扩展/水平扩展）

• CNCF（云原生计算基金会）给出的云原生三大特征

• 容器化封装

• 动态管理

• 面向微服务

• 云原生应用 12 要素

• 基准代码：一份代码库对应多份部署，所有部署的基准代码相同（每份部署可以使用不同的版本）

• 依赖：声明依赖项（应用：生产、开发环境）

• 配置：环境中存储配置（推荐将配置存储在环境变量中，方便部署修改，环境变量与语言和统计无关）

• 后端服务：每个后端服务是一个资源（eg：一个 MySQL 数据库是一个资源，两个 MySQL 数据库是两个不同的资源）

• 构建，发布，运行：严格区分这三个步骤（eg：直接修改运行中的代码非常不可取 —— 很难同步回构建步骤）

• 进程：应用程序通常是以一个或多个进程运行的

• 端口绑定：通过端口绑定提供服务

• 并发：通过进程模型进行扩展

• 易处理：快速启动、优雅终止、最大化健壮性，有利于快速弹性的伸缩应用

• 开发环境与线上环境等价：尽可能保持开发预发布线上环境相同

• 日志：当作事件流

• 管理进程：后台管理任务当作一次性进程运行

• 

2）微服务

概念

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

• 复杂性高，单体架构包含模块多，边界模糊，依赖关系不清晰，代码质量参差不齐，项目复杂，修改代码比较困难

• 技术债务逐渐上升：需求更迭、人员更迭，已使用的系统设计/代码难以修改（应用程序的其他模块可能以意料之外的方式使用它）

• 部署速度逐渐变慢：代码增加——>构建、部署时间增加，每次功能变更/Bug 修复都需要重新部署整个应用（全量部署耗时长，影响范围大、风险高）

• 扩展能力受限，无法按需伸缩（单体应用只能作为一个整体进行扩展，无法结合业务模块的特点进行伸缩）

• 阻碍技术创新：一般使用统一的技术平台/方案解决所有问题，所有成员使用相同的开发语言和架构，引入新的框架/技术平台非常困难

 由于单体架构以上缺陷，越来越多公司采用 <font color="red">微服务架构范式</font> 解决上面的问题

• 将单个应用程序开发为 $一组小型服务$
  

• 每个小型服务都 $在自己的进程中运行$，通过轻量机制通信（通常是 HTTP 资源 API）

• 服务 $围绕业务功能进行构建$
  

• $独立部署$
  

• 可以使用 $不同的编程语言$
  

• 可以使用 $不同的数据存储技术$
  

• 服务仅做 $最低限度的集中管理$
  

优势

• 微服务可以将应用拆分成多个核心功能，每个功能称为一项服务，可以 $单独构建和部署$
  

• 缩短 TTM（Time To Market）时间

• 有助于实现更加敏捷的部署和更新（开发时间缩短）

• 高度可扩展（跨多服务器等）

• 弹性伸缩（独立服务不会彼此影响），一个服务出现故障，不会导致整个应用下线

• 易于部署（模块化）

• 易于访问

• 更加开放（多语言 API，自由选择语言技术）

劣势

• 运维要求较高（单体服务只需要保证一个应用的运行，微服务中，要保证几十甚至几百个服务的正常运行与协作）

• 分布式固有的复杂性（系统容错、网络延迟、分布式事务等）

• 接口调整成本高（微服务通过接口通信，若修改某个微服务的 API，可能所有使用了该接口的微服务都需要做调整）

• 重复劳动（很多服务可能使用相同的功能，而这个功能没有达到分解为一个微服务的程度，这时可能各个服务都会开发这一功能，导致代码重复）

2. 敏捷与 DevOps

1）敏捷

敏捷软件开发宣言

• 价值观

• 个体和互动 高于 流程和工具

• 工作的伙伴 高于 详尽的文档

• 客户合作 高于 合同谈判

• 响应变化 高于 遵循计划

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

• 十二原则

• 

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

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

敏捷常用的工程方法

• 以 Scrum 为基础的方法论居于主流地位，使用率最高

• 其他的还有：看板方法、精益创业、极限编程等

• 小众方法论：DSDM、FDD、RAD

• 

2）DevOps

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

DevOps 的概念

• 维基百科：DveOps
  

• DevOps，是一种重视 $软件开发人员（Dev）$和$IT运维技术人员（Ops）$之间沟通合作的文化

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

DevOps 专家的观点

• DevOps $打破开发与运维之间的孤岛$

  
  
  

• DevOps $通常指的是新兴的专业化运动$

  
  
  

DevOps 领先企业的观点

DevOps 生命周期过程

• 文化：是建⽴一体化的全功能团队， 打破开发(Dev)与技术运营(Ops)隔阂，形成 DevOps 的协同合作的文化氛围

• 自动化：从构建到运维过程的自动化

• 精益：小步快跑，持续改善

• 度量：建⽴有效的监控与度量手段快速获得反馈，推动产品和团队的持续改进

• 分享：不同职能、不同产品之间经验分享能够促进 DevOps 的文化沉淀，促进 产品迭代和更新。

• 

• 计划阶段：运维人员为开发人员提供需求，并制定发布计划

• 编码/构建/验证阶段：Scrum、极限编程和精益生产，持续集成、自动化测试等

• 部署阶段：开发团队负责部署、监控部署过程，以及部署后的运行

DevOps 收益与价值

• 《2019 DevOps 状态报告》

• DevOps Eilite 组织 VS DevOps Low 组织

• $208$ 倍的代码部署频率

• $106$ 倍的代码到部署时间效率

• $1/2604$ 的故障恢复时间

• $1/7$ 的变更失败率

• 变更失败率指软件发布后不可用或者服务质量 出现不可接受的性能下降

• 故障恢复时间指从现网发现问题，到故障全部恢复的时间

DevOps 持续交付实施框架

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

• 

3）敏捷和 DevOps 关系

• EXIN（国际信息科学考试学会）的 DevOps Master 白皮书，下图为 DevOps 知识体系图，它将 DevOps 诠释为如下四个部分

• 敏捷管理：包含计划、需求、设计、开发

• 持续交付：包括开发、部署、运营

• IT 服务管理：包括运营、周期终止

• 精益管理：从计划到周期终止的全程

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

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

• 从交付全流程的覆盖范围看，经历了敏捷开发、持续集成、持续交付、DevOps 四 个重要阶段

• 敏捷开发

• 拥抱变化

• 快速迭代

• 持续集成

• 提交新代码后，自动构建和测试

• 保障最终代码没有问题

• 持续发布

• 集成后的代码自动部署到类生产环境中

• 评审通过的代码进入生产阶段

• 持续部署是持续交付的最高阶段

• DevOps

• 更快的交付周期

• 更高效的交付流程

• 重视客户体验

• 保障软件质量

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