概述
dev：开发 ops：运维 开发运维一体化
指导理念：一切皆服务，软件本身也是由各种服务组成，形成最终交付的功能，交付的频率很快。
整个方法论的基础是敏捷开发，尤其是精益思想和看板方法。以领域驱动设计作为指导的一种微服务架构的方式。微服务将整个软件系统按照一定的规则和约束不断地拆分，个别微服务的失效和更新不影响整个系统的使用。虚拟化技术在Devops中得到了大量的使用，软件的使用环境和软件的开发测试环境几乎完全一样，只要软件在开发测试环境通过，则可以部署到生产环境，这个过程可以完全自动化地实现。
从传统方式切换到Devops：
- 阶段一：将开发和运维的价值流工作流建立起来。已经开发完成并且投入使用才能产生价值。开发完成后还不足以让软件或者它的部分功能产生价值，只有当放在生产环境中进行部署和使用才可以。所以，在第一阶段，需要建立从开发到生产环境的工作流，建立起环境来支持持续的构建、集成和交付，同时建立看板实现可视化。为了能够保证流动起来，需要有缺陷控制。
- 阶段二：在适当的地方停下来看哪些地方有问题，持续地构建、改进自动化的测试套件，确保代码随时都处于可部署的状态。通过反馈机制，运维一端的问题要反馈到开发者。通过远程监控手段，完成对系统的自动化监控。
- 阶段三：通过不断地尝试让价值流动的更快、交付的更好。
敏捷软件开发
旧称轻量级软件开发，能够很好地应对模糊的、快速变化的需求。
敏捷软件开发重视个体的作用以及个体和个体之间的交流沟通，重视相应变化高于事先的计划，重视可运行的软件高于文档，重视客户的合作，欢迎客户在后期提出需求的变化。快速反馈，及早交付有价值的软件使得客户满意，以简洁为本。
常见的方法：Scrum、极限编程、看板。
技术层面的实践：TDD(测试驱动开发）、CI（持续集成）、CD（持续交付）、结对编程、重构。
管理层面的实践：每日站立会议、Scrum中的计划会议、回顾会议、评审会议。
常用工具：白板、单元测试工具等等。
看板方法：可视化工作流程、限制正在进行中的工作。
精益软件开发及其原则
1、减少浪费。包括创建不必要的功能和产品，把低价值的需求当高价值的需求，返工，不必要的复杂的设计，等待其他任务完成，无效沟通等等。
2、增强学习（不断学习）
3、尽量延迟决定
4、尽快发布给用户，让用户反馈。
5、给团队授权。和软件开发有关的权力应该由团队自己决定。
6、内置的完整性。希望能够达成客户对产品体验的一致性。
7、全局优化。
软件架构
软件结构：组件和组件之间的联系、组件和环境之间的关系。
面向服务的软件架构：又称SOA，使用一组分布式的组件的集合，建立服务的提供者和消费者之间的联系。通过一个企业的服务总线，为相互调用的服务提供底层的支持，比如服务之间的路由，以及消息和数据的转换工作。在运行时可以组合不同的服务，来满足动态变化的客户的需求。
服务编排的引擎：通过脚本来对消费服务和提供服务两者之间进行动态的指挥。根据顶层上不同业务的需求来编制下层的企业服务。
特点：服务之间高内聚低耦合，采用开放的标准提供良好的互操作性。通过模组化，将不同的功能分配到不同的服务，以达到比较高的可重用性。同时由于是在运行时绑定，在服务时可以动态地识别注册和调用。服务的设计要遵守一定的规约，服务之间最大化地重用。服务本身要保持无状态的，因为可能会有很多用户同时访问同一个服务，要保证一个服务支持多个用户的访问。
微服务及微服务架构
将原来单一的应用程序开发为一组小型服务，每个服务运行在自己独立的进程当中，可以独立地开发部署。服务之间采用轻量级的通信机制。
特点：通过服务来实现组件化。各个组件可以独立地替换及升级，服务可以进行独立地部署。去中心化，对于不同的微服务，可以使用不同的技术栈进行实现。服务之间只要约定共同遵守的接口，就不需要关心彼此是怎么实现的。对于微服务系统，更倾向于让每一个微服务去管理自己的数据库，它们可以有同一个数据库的不同的示例，甚至可以使用不同的数据库技术。同时，微服务架构中，基础设施实现了自动化，从而有效地管理众多服务所带来的集成、交付、测试、运维上的负担。
微服务在设计时要考虑高可用性，为每一个单独的服务完善监控和日志的记录，从而在微服务失效的时候能够尽早地发现问题，采取措施进行修复。如果不断地一起改变多个服务，就要考虑将这些服务合并放到同一个服务当中。
服务的消费者如何发现服务的提供者？
二者都需要在服务发现组件上面注册他们所能提供或者需要的服务。 消费者从服务的发现组件查询提供者的位置和接口，进而调用。心跳机制保证某服务的提供者或者消费者长时间没有通讯的反应，即没有心跳，则注册组件会认为他们失效了。
服务之间通过API网关进行通讯。微服务调用是一个细粒度的api，而客户的访问是粗粒度的请求。二者之间需要API网关进行匹配。
熔断器模式（circuit breaker）
一方面可以防止程序不断地尝试一个无效的操作，同时也能够在失效的服务被修复后尝试去恢复。
熔断器的状态
闭合状态：服务可以正常地调用和访问。（最上面）
断开状态：对于程序的请求返回错误响应。（最下面）
半断开：当出现错误时，隔一定数量的请求后还会尝试着调用该服务。调用成功，转到闭合状态。
微服务工具选型示例：
上图中，使用spring boot进行服务开发，使用Jenkins进行持续集成以及部署，使用docker将开发好的微服务封装，使用ZooKepper进行微服务的注册。当收到请求时，node.js先到zookeeper上查找需要的服务，然后到系统调用被docker封装的微服务。
