内容简介：读DevOps软件架构师行动指南01(6.5)
对于《DevOps软件架构师行动指南》这本书，整体偏大框架的介绍，但是仍然还是有一定的阅读价值，至少对DevOps架构方法论和关键技术有一个全面的了解和认知。
书里面给出定义为，DevOps是一套实践方法，在保证高质量的前提下缩短系统变更从提交到部署至生产环境的时间。实际上看了这个定义你也很难对DevOps有一个全面的了解。因此也可以定义为，DevOps是在保证质量的前提下，提供的一整套从开发，测试到生产运维的持续交付和管控方法论。在整个过程中需要实现自动化，可视化，流水线式作用，同时将质量管控无缝嵌入其中。
DevOps拓展了原有的持续集成方法论，其核心增加了组件化和微服务架构，其次增加在交付和部署的时候和PaaS云资源池和动态调度的集成。
不仅在新系统的开发交付，其更加重要价值在于老系统在后续变更中的持续交付和集成能力。也就是常说的实现了开发，运维和质量管控的一体化作业。也就是我们经常说的，打开了开发和运维之间的鸿沟，真正实现了开发，运维的一体化作业。
DevOps提倡将运维人员作为首要的干系人，并在需求阶段一开始就介入 。
DevOps确保整个发布过程是可视化的，同时实现发布过程的质量控制，可管理和可追溯。以确保在部署出现问题的时候能够快速的查找原因或整体回滚。
运维人员后期运维难的一个重要原因就是前面所以开发和测试过程对他们都是黑盒，对于这种部署在软硬件环境里的黑盒系统，在出现故障时候他们也很难第一时间查找到真正的原因并快速解决。
DevOps和敏捷，我更愿意理解为 需求的条目化，持续集成，可视化 这几个关键点的实践。
在协同上面要注意到，DevOps有两个重点， 其一是开发，QA+测试，运维三大角色之间的协同；其二是软件打包版本在开发，测试，生产多个环境间的自动化部署和迁移 。
人们从不同的视角定义DevOps，例如运维人员采用敏捷实践，开发人员承担运维责任，以及其它一些视角的定义。但共同目标都是 缩短一个功能或改进点从业务思路构想到最终部署给用户的时间 。
云即平台
在DevOps有一个重点就是应用托管和自动部署，在自动部署的过程中才是需要动态的创建虚拟机和分配资源。因此和DevOps真正配合协同的是PaaS平台层能力，而不是IaaS平台。同时我们可以看到，DevOps实践过程中更多的是和更加轻量化的 Docker 容器协同，而Docker容器管理的基础单位是镜像。
在和PaaS协同时候，对于底层软硬件设施的基础架构和可见性进一步对开发人员屏蔽。
对于虚拟机故障的恢复，一个重点就是状态的保持和迁移，对于分布式架构师要做的主要决策之一就是如何在应用的不同部分划分状态。对于无状态组件最容易快速恢复和迁移，对于客户端Session状态由于数据量很小，也方便处理，而对于不同数据量状态处理方法：
1. 少量的持久状态： 需要在多个会话间维护，可以保持在文件系统中，采用ZooKeeper或Memcached
2. 中等量状态： 采用 Memcached 保存，并提供持久化存储机制
3. 大量的持久状态： 保持在结构化数据库，或者Hadoop分布式文件系统中
环境是执行软件系统的一组计算资源，包括了所有支持软件，数据集，网络通信，以及执行软件系统所需要定义的外部实体。对于环境，我们常会分为开发，测试，UAT，生产等多个环境，但是这并不是云特有的属性。 简单的创建和快速迁移环境的能力才是云特有的能力。而这正是DevOps里面实现持续集成和交付的关键。
将生产轻松的从一个环境切换到另一个环境的结果就是使业务连续性的实现变得更加容易。业务连续性意味着当主数据中心发生灾难的时候业务能够继续运作。
第2章整体写的相当弱，特别是对于DevOps为何需要和云结合，维护需要PaaS平台能力没说透彻。
运维
运维整体架构可以参考ITIL标准体系。运维服务包括供给硬件，提供软件，或者支持不同的IT功能。由运维提供的服务还包括了SLA服务等级水平协议的规格说明，软硬件环境状态监控，容量规划，事件管理，故障和问题跟踪处理，日常环境检查，环境和数据备份，业务连续性和信息安全等。
容量规划实际上仍然需要业务部门或IT项目提供具体的容量需求，运维部门再整体进行容量测算和规划，以在满足业务系统性能需求的前提下保证最高的资源利用率。
软硬件的性能和状态监控是实施了云平台后运维人员工作的一个重大改变，即底层资源已经被云平台接管，运维人员日常监控不再是传统方式登陆到物理服务器或虚拟机后台，因为这些资源本身也可能是动态在变化。 在这种情况下运维更加需要借助云平台提供的性能监控分析和日志查看 工具 来辅助完成运维监控工作。
DevOps不仅仅是考虑软件变更在交付过程中的自动化，也需要考虑后续运维过程的自动化。
IT服务治理，单独的一个内容，需要提供什么样的服务，安全要求如何，合规要求如何？SLA服务级别如何定义？日常的变更，发布，问题，事件管理流程是如何的？服务的业务连续性如何保证？高可用性如何保证？这些都需要在IT服务和治理管控框架中进行定义。
对于服务设计需遵循标准化，松耦合，抽象，可复用，自治，无状态，可发现，可组装等标准原则。
服务移交，开发和运维角色之间的一个重要衔接点，如何移交，具体究竟应该移交哪些内容？一个简单的原则就是最终移交的内容和文档，能够确保运维人员后续的日常运维和管控要求。服务移交一定不是移交一个全黑盒的软件部署包，否则后续运维人员很难真正进行运维。
监控是运维过程中最重要的核心，因为它收集事件，检测事故和度量以判断是否符合服务等级协议。它提供服务改善的基础。服务等级协议也可以定义和监控运维活动，例如事故发生后的响应时间。监控的结果由开发或运维团队来进行分析并采取行动。
监控可以和其他控制结合在一起，例如对云资源的自动伸缩控制。
由IT服务和日常运维来反向推动持续服务改进（重要）：这个足可以单独写一篇文章来谈，持续服务改进的主要焦点是在IT服务和业务需求之间达成一致。ITIL提出的持续改进关键步骤包括了提出目标-》定义度量和KPI-》采集数据-》分析数据-》改进方案和计划-》执行改进-》观察和分析结果。
同传统发布不同，DevOps发布属于高频率的小规模发布，可以将DevOps发布视为更小规模的并发流。一种审视DevOps和ITIL之间关系的方法是，DevOps对各种ITIL服务提供持续交付，而不是将这些服务打包进主要发布版本。（如何理解？）
这部分内容，仍然没有将DevOps和传统运维过程的交叉点讲太明白。
实施DevOps往往需求架构调整，其关键原因就是尽量减少每次部署动作对整体应用的影响，同时匹配前面谈到的持续高频，小规模发布的需求。而这种关键调整的关键就是微服务架构。对于微服务架构我前面很多文章都已经谈到过了，这本书这部分仍然没有讲透。
微服务架构对于部署流水线作业带来的好处可以总结为：
1. 团队可以按微服务模块单独划分，减少团队之间的耦合和交叉影响
2. 多个微服务模块组件松耦合，完全可以独立自治管理，对于变更发布仅需要发布最小组件单位，降低风险
微服务架构本质仍然是组件化架构+接口服务化，可以看到这种松耦合架构，再加上单个可以独立管理和部署的组件更加轻量，方便我们更加容器去实施自动化部署和持续集成。也方便软件和服务部署时的最小化原则。
在采用微服务架构后，如果是要细化管理到每个微服务组件或模块，其本质是增加了整个DevOps和部署流水线过程的管理难度，即我所有的管理对象，配置和版本控制对象都必须到组件级别，同时还需要进一步管理好组件间的集成和依赖关系。
从代码提交到版本控制系统开始，整个部署流水线工作就启动。部署流水线工作一个重点就是持续集成，对于持续集成我在前面博客有文章专门谈到过了，书里面介绍了定义持续集成的一种方法是在一个阶段和下一个阶段之间有一个自动触发器，直到集成测试。
持续集成需要完成代码构建打包，部署，单元测试，环境迁移，集成测试，部署等一系列动作。
在部署流水线中移动系统要关注两个方面的内容， 其一是可追溯性 ，可追溯意味着对于生产中的任何系统，可以准确的确定它如何进入生产环境。这意味着不仅要跟踪源代码，还需要跟踪所有工具命令。 其二在移动过程中需要关注各个环境之间的差异 ，以确保在环境迁移过程中能够自动化的配置和设置各种环境变量信息。
Jenkins，Github，Ant，Maven，JUnit等都是我们可以采用的持续集成和管理工具。
构建的目的是创建适合于部署的东西，有多种把系统元素打包并用于部署的标准方法，其中包括了 打包为WAR部署包，制作虚拟机镜像或者制作类似Docker容器镜像等 。
我们看到在DevOps和Docker集成的时候，实际在第一次部署前首先是制作Docker容器镜像，然后对整个容器镜像文件进行部署，同时在后续环境迁移过程中迁移的基本单位也是该容器镜像文件。
部署
部署是将服务的某个版本投入到生产环境的过程。对于服务部署更加需要关注的是后续服务的版本升级。服务部署的总体目标是：对系统用户产生最小影响的情况下，将服务的升级版本投入到生产环境中，这些影响可能是失败或停机时间。
服务的变更由三个原因：修复错误，提升服务质量或者增加新功能。
对于微服务模块的部署，其场景往往更加复杂，一方面是微服务模块本身的部署和应用托管，一方面是需要将微服务模块提供的微服务API接口注册到微服务网关。同时可以看到对于微服务模块本身在进行服务升级或变更的时候需要全面的分析微服务模块和服务API接口相互之间的依赖和影响关系。
对于灰度发布或滚动升级是保证系统安全可靠运行的一个常见方法，为了实现滚动升级需要PaaS管理平台和微服务模块本身的配置改造来支撑。滚动升级在资源使用方面更加有效，但是容易引起逻辑一致性问题：
1. 单个服务多个版本同时服务，容易提供不一致的服务
2. 客户端可能假设依赖服务的一个版本，但是实际上是由另外一个版本服务提供
逻辑一致性的解决方法是使用某些功能开关的组合，向前或向后兼容，以及版本意识和管理。部署必须偶尔回滚，对于功能开关还需要支持回滚功能。
功能开关用来控制是否激活一个功能，而在判断一个功能是否激活的时候，需要判断是否所有涉及到该功能的服务都全部升级完成，只有全部升级完成才能够在所有虚拟机上同时激活该功能。同时在分布式架构和集群中，还需要采用ZooKeeper等事务协调机制来保证一致性。
服务版本需要支持向前兼容性，如果一个服务版本升级不能向前兼容，这就意味着所有原来消费老服务版本的系统或模块都需要进行修改。在这种情况下往往只能够发布一个新版本服务，保证新老版本服务同时运行，并在后续变更中逐渐消亡或替代老服务版本。
部分部署方法： 金丝雀测试和A/B测试 。P86页。
提供自动化的回滚能力仍然是在自动化部署和持续集成中需要考虑的问题，而对于回滚真正的难点在于数据库和数据的回滚，而不是部署包和镜像文件的回滚。对于数据的回滚当前仍然是一个难题，如果是完全恢复上一次的数据库备份，仍然需要耗费相当长的时间才能够完成。
以上所述就是小编给大家介绍的《读DevOps软件架构师行动指南01(6.5)》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
