DevOps与敏捷开发、Kubernetes、微服务、应用架构模式的关系 | 福利送书

点击“博文视点Broadview”，获取更多书讯

1. DevOps与敏捷开发

敏捷开发主要是针对应用的开发，其目的是加快开发对应用需求的响应，快速交付价值，快速响应变化。敏捷开发是用短的迭代周期来适应更快的变化，而且保持增量的持续改进的过程。DevOps涵盖的不仅仅是开发，还包括开发之后的部署、发布、运维等应用生命周期的整个流程，延伸整个响应、交付的流程到实施、发布和运维，从而涵盖整条IT价值流。

2. DevOps与Kubernetes

容器及Kubernetes促进了DevOps，当为一个应用打包容器镜像时，选择基础镜像及安装依赖部分就是原先需要运维人员所做的环境创建和配置。而使用容器后，此过程由开发人员和运维人员共同商议决定，从而促进了开发人员与运维人员的合作。

Docker 使容器具备了较好的可操作性、可移植性，Kubernetes 使容器具备了企业级使用的条件，企业级容器平台也成为CI/CD工具落地的新一代基础架构。容器编排器带来的一个巨大转变是，原来只有运维人员关心环境的部署，无论是测试环境还是生产环境，都是运维人员搞定的；而容器化之后，需要开发人员自己写Dockerfile或者Kubernetes的YAML文件，关心应用运行环境的部署。Kubernetes让开发人员无须再关注底层资源，使得交付速度更快。为了实现应用的持续集成和持续交付，必须缩小本地与线上的差异，确保环境的一致性，保持开发环境、测试环境和生产环境尽可能相似。Kubernetes正好提供了这种一致性，并且通过Kubernetes配置文件构建的环境可以实现版本化。

从开发人员的角度来讲，使用Kubernetes绝对不像使用虚拟机一样，开发人员除了写代码、做构建、做测试，还需要知道应用的容器运行环境。开发人员需要知道容器和原来的部署方式是不一样的，需要区分有状态和无状态。开发人员需要写Dockerfile，需要关心环境的交付，需要了解太多原来不了解的东西。

Kubernetes + Docker 是Dev和Ops融合的一个桥梁。Docker是微服务的交付工具，有了微服务之后，服务太多了，单靠运维人员根本管不过来，而且很容易出错，这就需要开发人员关心环境的交付。例如配置改了什么、创建了哪些目录、如何配置权限等，只有开发人员最清楚，这些信息很难通过文档的形式及时、准确地同步到运维部门，就算是同步过来了，运维部门的维护量也非常大。所以有了Kubernetes，最大的改变就是环境交付提前——每个开发人员多花5%的时间，来换取运维人员200%的劳动，并且提高了稳定性。此外，有了Kubernetes以后，运维层要关注服务发现、配置中心、熔断降级。Kubernetes虽然复杂，但是其设计理念非常符合DevOps的思想。

3. DevOps与微服务

传统的单体应用模块化并不注重模块间接口的契约化，在进行模块集成时经常会出现应用功能不可用的情况，需要花费大量时间进行修复。微服务架构的应用往往由数量众多的微服务构成，在这种情况下，DevOps的CI/CD必不可少。通过CI/CD可以实现整个开发流程的自动化，从而极大地提升开发效率。

4. DevOps与应用架构模式

康威定律指出，软件的架构和软件团队的结构是一致的，所以应用开发团队对软件产品的架构和成果有着巨大的影响。为了使DevOps的IT价值流可以快速地流动，必须利用康威定律发挥团队的优势，灵活地组织团队。如果不理解康威定律，就会妨碍团队安全、独立地工作，它们会被紧紧地耦合在一起，所有工作都相互依赖和等待，即使做很小的变更也会导致全局性、灾难性的后果。

为了实现DevOps，不但要减少职能化导向的负面影响，而且还要更好地运用市场化导向的效果，从而使团队可以安全、独立地工作，并且快速地向客户交付价值。因此，应用的架构模式需要保证团队可以独立运作，彼此充分解耦，从而避免过多不必要的协调与沟通。在传统的紧耦合架构中，即使做微小的变更也可能导致大规模的故障。因此，负责某个组件的开发人员不得不和负责其他组件的开发人员不断地协调与沟通。为了测试整个应用能否工作，需要集成数百名甚至数千名开发人员编写的代码，而这些开发人员编写的代码又依赖数十个甚至数百个其他应用。另外，测试需要在稀缺的集成环境中完成，而集成环境通常需要花费数周来安装和配置。结果是不仅延长了交付周期，还导致开发人员的生产力低下和部署质量不佳。

应用赖以生存的架构在很大程度上决定了代码的测试和部署方式。架构是应用开发的首要因素，它还决定了是否能够快速和安全地实施变更。如果架构能够支持团队独立、安全、快速地进行开发、测试和部署，那么就可以提高和维持开发人员的生产力，并且持续改善部署质量。微服务架构模式就具有这种特性，松耦合的架构意味着在生产环境中可以独立更新某一个微服务，而无须更新其他微服务。康威定律告诉我们，必须鼓励建立小规模的团队，减少团队间的沟通，而微服务架构真正从软件架构上支持这种工作模式，将DevOps的流动性和灵活性发挥到极致。

本文节选自《云原生架构：从技术演进到最佳实践》

本书分为“技术演进篇”和“最佳实践篇”两篇，涉及4个部分，共19章，大概的内容分布及简介如下。

技术演进篇

第1部分 系统资源（第1~5章）

基础架构解决的是一些通用性问题，主要涉及应用运行时所需要的系统资源，这些系统资源是设计任何类型的应用都需要重视的内容。针对不同的系统资源，应用的部署、运行方式也不尽相同。这一部分将首先介绍操作系统、虚拟化等基本知识，然后讲解云计算相关内容，以及容器与容器编排的核心知识。

第2部分 应用架构（第6~11章）

架构的重要性在于实现应用的非功能性需求。非功能性需求往往能决定一个应用运行时的质量，也能决定开发时的质量。这一部分将宏观介绍应用架构的定义、分类、目标等，列举主流架构视图，并按照技术演进过程介绍单体架构、分布式架构、SOA架构、微服务架构等内容。

第3部分 软件工程（第12~16章）

1968 年，世界各地的计算机科学家在德国的Garmisch召开了一次国际会议，在会上正式提出了“软件工程”一词。软件工程管理的核心目的是支撑新的演进式架构。软件工程的整个流程分为5个阶段：应用设计、软件开发、开发运维一体化、SRE运维、数字化运营。在这一部分中，我们将紧密围绕以上5个技术演进阶段，从软件工程角度讲解云原生应用架构的实现。

最佳实践篇

第4部分 架构、应用落地与中台构建（第17~19章）

在这一部分中，我们将详细剖析云原生架构，介绍其定义、涉及的关键技术，以及具体的实现过程。本部分还会介绍应用落地的最佳实践，涉及应用改造、应用拆分、API设计与治理等。此外，“中台”这个概念也与云原生密不可分，本部分还会阐述云原生应用与中台之间的关系，以及如何通过中台使应用的云原生化更加便捷。

要想一网打尽云原生架构技术精髓，掌握从技术演进到最佳实战的终极密码，欢迎阅读《云原生架构：从技术演进到最佳实践》。

（京东满100减50，到手50元，快快扫码抢购吧！）

公众号粉丝福利， 为大家争取了3本新书名额哦。
感谢电子工业出版社杨老师支持！
扫描下面二维码参与本次活动
【11月06日12点30分开奖】
赶快加入吧！

 热文推荐  

• 一行Python代码解决问题是时尚还是玄学
  

• 看半小时漫画，通晓计算机基础
  

• 基于Spinnaker的全自动渐进式交付
  

• 1024程序员：算法&仓鼠&创业
  

---

▼点击阅读原文，查看本书详情~