善用兵者，役不再籍，粮不三载。取用于国，因粮于敌，故军食可足也。

——《孙子兵法》

在古代，带兵作战的将领，不仅要能善于用兵，而且要能保障粮食的充足。正所谓兵马未动，粮草先行。粮草永远摆在第一位，因为在冷**时代，战争中的将士都是在拼力气，吃饱才有力气打仗。

在今天互联网的“战争”环境中，我们为了能更快应对市场变化，一直以来不断调整作战的方针和打法，也从传统的开发方式转变为了敏捷开发，由敏捷开发又过渡了到 DevOps。在 2019 年的中国 DevOps 行业报告中指出：“尽管受访企业期望 DevOps 能够带来更高效的交付效率，提升客户满意度，创造更多的商业价值，但成功实践 DevOps 依然是一个难题 。”

其中，28.22% 被调查者认为自己组织的 DevOps 实践是不成功的， 41.13%的被调查者不清楚如何衡量自己组织的 DevOps 实践是否成功。如果以一个更加直观的数据来展示，就是在接受调查的企业中有69.35%是没有能很好的了解和实践DevOps的。

也许，在实践DevOps的这几年来，并没有多少公司是真正知道什么是DevOps的。DevOps只是从字面上理解的打破部门墙的一键发布的工具链吗，是否有了这个工具链就是DevOps？答案是否定的。

那么，DevOps是什么？

DevOps 是集文化理念、实践和工具于一身，可以提高组织高速交付应用程序和服务的能力，与使用传统软件开发和基础设施管理流程相比，能够帮助组织更快地发展和改进产品。这种速度使组织能够更好地服务其客户，并在市场上更高效地参与竞争。

——AWS

从AWS给出的定义来看，好像也还是比较的抽象。那如果简单的来说，DevOps就是让软件过程既“快”又“稳”。何为快和稳，这个快和稳体现在，部署频率、交付周期、平均修复时长、变更失败比例这4个维度上。

在2018年的 DevOps 调查报告中基于上述4个维度，由于仅有6%达到了所规定的高性能指标，为了避免特殊原因造成数据过低，所以放宽的条件，并给出了准高性能DevOps指标。

从达成这一准高性能DevOps指标的团队分析来看，其具体体现在三个方面：一方面是自动化、标准化、质量保证、敏捷方法的实践活动上；一方面是DevOps各个阶段的对应工具上。除此以外就是，团队正在开发应用的架构上。

架构的选择对于DevOps的实践是至关重要的，从某种程度上来说，架构就是DevOps这场战役的粮草，它是支撑着DevOps成功落地的重要前提。受访的准高性能DevOps指标的团队将“使用微服务框架”作为团队正在开发应用的架构上的Top1。

什么是微服务

是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。

微服务的起源是由 Peter Rodgers 博士于 2005 年度云计算博览会提出的微 Web 服务 (Micro-Web-Service) 开始，Juval Löwy 则是与他有类似的前导想法，将类别变成细粒服务 (granular services)，以作为Microsoft下一阶段的软件架构，其核心想法是让服务是由类似 Unix 管道的访问方式使用，而且复杂的服务背后是使用简单URI来开放接口，任何服务，任何细粒都能被开放 (exposed)。这个设计在 HP 的实验室被实现，具有改变复杂软件系统的强大力量。

2014年，Martin Fowler与James Lewis共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通信。同时服务会使用最小的规模的集中管理 (例如Docker) 能力，服务可以用不同的编程语言与数据库等组件实现。

微服务的特点

根据 Martin Fowler 的分析，微服务架构有以下的一些通用特性，但并非所有微服务架构应用都必须具备所有这些特性：

• 通过服务实现应用的组件化(Componentizationvia Services)：微服务架构中将组件定义为可被独立替换和升级的软件单元，在应用架构设计中通过将整体应用切分成可独立部署及升级的微服务方式进行组件化设计。
• 围绕业务能力组织服务(Organizedaround Business Capabilities)：微服务架构采取以业务能力为出发点组织服务的策略，因此微服务团队的组织结构必须是跨功能的（如：既管应用，也管数据库）、强搭配的DevOps开发运维一体化团队，通常这些团队不会太大（如：亚马逊的“Two pizza team”- 不超过12人）。
• 产品而非项目模式(Productsnot Projects)：传统的应用模式是一个团队以项目模式开发完整的应用，开发完成后就交付给运维团队负责维护；微服务架构则倡导一个团队应该如开发产品般负责一个“微服务”完整的生命周期，倡导“谁开发，谁运营”的开发运维一体化方法。
• 智能端点与管道扁平化(Smartendpoints and dumb pipes)：微服务架构主张将组件间通讯的相关业务逻辑/智能放在组件端点侧而非放在通讯组件中，通讯机制或组件应该尽量简单及松耦合。RESTful HTTP协议和仅提供消息路由功能的轻量级异步机制是微服务架构中最常用的通讯机制。
• “去中心化”治理(DecentralizedGovernance)：整体式应用往往倾向于采用单一技术平台，微服务架构则鼓励使用合适的工具完成各自的任务，每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。微服务的技术标准倾向于寻找其他开发者已成功验证解决类似问题的技术。
• “去中心化”数据管理(DecentralizedData Management)：微服务架构倡导采用多样性持久化(PolyglotPersistence)的方法，让每个微服务管理其自有数据库，并允许不同微服务采用不同的数据持久化技术。
• 基础设施自动化(InfrastructureAutomation)：云化及自动化部署等技术极大地降低了微服务构建、部署和运维的难度，通过应用持续集成和持续交付等方法有助于达到加速推出市场的目的。
• 故障处理设计(Designfor failure)：微服务架构所带来的一个后果是必须考虑每个服务的失败容错机制。因此，微服务非常重视建立架构及业务相关指标的实时监控和日志机制。
• 演进式的设计(EvolutionaryDesign)：微服务应用更注重快速更新，因此系统的设计会随时间不断变化及演进。微服务的设计受业务功能的生命周期等因素影响。如某应用是整体式应用，但逐渐朝微应用架构方向演进，整体式应用仍是核心，但新功能将使用应用所提供的API构建。再如在某微服务应用中，可替代性模块化设计的基本原则，在实施后发现某两个微服务经常必须同时更新，则这很可能意味着应将其合并为一个微服务。
  
  

微服务适用的场景

基于微服务的优势，我们可以看到，微服务比较实用于以下场景：

• 对于业务流程较为复杂，且业务会变得逐渐复杂的项目，可以考虑使用微服务架构
• 项目存在多个团队（公司）多种开发语言时
• 核心业务和非核心业务变得泾渭分明
• 需要平滑升级时（服务无中断、客户无感知）
• 想对系统进行细粒度监控时 （bug调查困难或性能等问题）
• 既然微服务有其使用的场景，那么也一定有其优缺点。
  

既然微服务有其使用的场景，那么也一定有其优缺点。

微服务的优势

微服务的诞生正是在互联网高速发展，技术日新月异变化以及传统架构无法适应快速变化等多种因素共同推动下的必然产物。从一个网站的演变可以看到使用微服务后带来了很多优点，总结如下：

• 逻辑清晰：
  

这个特点是由微服务的单一职责的要求所带来的。逻辑清晰带来的是微服务的可维护性，在我们对一个微服务进行修改时，能够更容易分析到这个修改到底会产生什么影响，从而通过完备的测试保证修改质量。

• 简化部署：
  

微服务则可以只对一个微服务单独进行部署，不影响其他功能的同时，在效率上也得到了提升，从而快速的发布新的功能。

• 可扩展性强：
  

在分布式系统中，采用微服务的系统相对单块系统具备更好的可扩展性。
灵活组合减少浪费：在微服务架构中，可以通过组合已有的微服务以达到功能重用的目的，减少了重复浪费。

• 技术异构：
  

微服务间松耦合，不同的微服务可以选择不同的技术栈进行开发。

微服务的缺点

以往单体应用，排查问题通常是看一下日志，研究错误信息和调用堆栈。而微服务架构整个应用分散成多个服务，定位故障点非常困难。在微服务架构中，一个服务故障可能会产生雪崩效用，导致整个系统故障。

微服务架构虽然逻辑设计上看是完美的，但就像积木搭建的华丽宫殿一样，经不起风吹草动。微服务架构虽然解决了旧问题，也引入了新的问题：提高了系统的复杂度，此外还有：

• 服务的注册与发现问题；
• 服务之间的分布式事务问题；
• 数据隔离再来的报表处理问题；
• 服务之间的分布式一致性问题；
• 服务管理的复杂性，服务的编排；
• 不同服务实例的管理。2
  

微服务在使用上是一把“双刃剑”，这就像粮草如果在搬运的过程中被敌方夺取，那可能会是毁灭性的。所以DevOps团队在微服务的架构上需要非常的重视，一个成熟度高的微服务框架才是实现其DevOps的重要前提，反之亦然。（转自敏捷的小智）

善用兵者，役不再籍，粮不三载。取用于国，因粮于敌，故军食可足也。

——《孙子兵法》

在古代，带兵作战的将领，不仅要能善于用兵，而且要能保障粮食的充足。正所谓兵马未动，粮草先行。粮草永远摆在第一位，因为在冷**时代，战争中的将士都是在拼力气，吃饱才有力气打仗。

在今天互联网的“战争”环境中，我们为了能更快应对市场变化，一直以来不断调整作战的方针和打法，也从传统的开发方式转变为了敏捷开发，由敏捷开发又过渡了到 DevOps。在 2019 年的中国 DevOps 行业报告中指出：“尽管受访企业期望 DevOps 能够带来更高效的交付效率，提升客户满意度，创造更多的商业价值，但成功实践 DevOps 依然是一个难题 。”

其中，28.22% 被调查者认为自己组织的 DevOps 实践是不成功的， 41.13%的被调查者不清楚如何衡量自己组织的 DevOps 实践是否成功。如果以一个更加直观的数据来展示，就是在接受调查的企业中有69.35%是没有能很好的了解和实践DevOps的。

也许，在实践DevOps的这几年来，并没有多少公司是真正知道什么是DevOps的。DevOps只是从字面上理解的打破部门墙的一键发布的工具链吗，是否有了这个工具链就是DevOps？答案是否定的。

那么，DevOps是什么？

DevOps 是集文化理念、实践和工具于一身，可以提高组织高速交付应用程序和服务的能力，与使用传统软件开发和基础设施管理流程相比，能够帮助组织更快地发展和改进产品。这种速度使组织能够更好地服务其客户，并在市场上更高效地参与竞争。

——AWS

从AWS给出的定义来看，好像也还是比较的抽象。那如果简单的来说，DevOps就是让软件过程既“快”又“稳”。何为快和稳，这个快和稳体现在，部署频率、交付周期、平均修复时长、变更失败比例这4个维度上。

在2018年的 DevOps 调查报告中基于上述4个维度，由于仅有6%达到了所规定的高性能指标，为了避免特殊原因造成数据过低，所以放宽的条件，并给出了准高性能DevOps指标。

从达成这一准高性能DevOps指标的团队分析来看，其具体体现在三个方面：一方面是自动化、标准化、质量保证、敏捷方法的实践活动上；一方面是DevOps各个阶段的对应工具上。除此以外就是，团队正在开发应用的架构上。

架构的选择对于DevOps的实践是至关重要的，从某种程度上来说，架构就是DevOps这场战役的粮草，它是支撑着DevOps成功落地的重要前提。受访的准高性能DevOps指标的团队将“使用微服务框架”作为团队正在开发应用的架构上的Top1。

什么是微服务

是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。

微服务的起源是由 Peter Rodgers 博士于 2005 年度云计算博览会提出的微 Web 服务 (Micro-Web-Service) 开始，Juval Löwy 则是与他有类似的前导想法，将类别变成细粒服务 (granular services)，以作为Microsoft下一阶段的软件架构，其核心想法是让服务是由类似 Unix 管道的访问方式使用，而且复杂的服务背后是使用简单URI来开放接口，任何服务，任何细粒都能被开放 (exposed)。这个设计在 HP 的实验室被实现，具有改变复杂软件系统的强大力量。

2014年，Martin Fowler与James Lewis共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通信。同时服务会使用最小的规模的集中管理 (例如Docker) 能力，服务可以用不同的编程语言与数据库等组件实现。

微服务的特点

根据 Martin Fowler 的分析，微服务架构有以下的一些通用特性，但并非所有微服务架构应用都必须具备所有这些特性：

• 通过服务实现应用的组件化(Componentizationvia Services)：微服务架构中将组件定义为可被独立替换和升级的软件单元，在应用架构设计中通过将整体应用切分成可独立部署及升级的微服务方式进行组件化设计。
• 围绕业务能力组织服务(Organizedaround Business Capabilities)：微服务架构采取以业务能力为出发点组织服务的策略，因此微服务团队的组织结构必须是跨功能的（如：既管应用，也管数据库）、强搭配的DevOps开发运维一体化团队，通常这些团队不会太大（如：亚马逊的“Two pizza team”- 不超过12人）。
• 产品而非项目模式(Productsnot Projects)：传统的应用模式是一个团队以项目模式开发完整的应用，开发完成后就交付给运维团队负责维护；微服务架构则倡导一个团队应该如开发产品般负责一个“微服务”完整的生命周期，倡导“谁开发，谁运营”的开发运维一体化方法。
• 智能端点与管道扁平化(Smartendpoints and dumb pipes)：微服务架构主张将组件间通讯的相关业务逻辑/智能放在组件端点侧而非放在通讯组件中，通讯机制或组件应该尽量简单及松耦合。RESTful HTTP协议和仅提供消息路由功能的轻量级异步机制是微服务架构中最常用的通讯机制。
• “去中心化”治理(DecentralizedGovernance)：整体式应用往往倾向于采用单一技术平台，微服务架构则鼓励使用合适的工具完成各自的任务，每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。微服务的技术标准倾向于寻找其他开发者已成功验证解决类似问题的技术。
• “去中心化”数据管理(DecentralizedData Management)：微服务架构倡导采用多样性持久化(PolyglotPersistence)的方法，让每个微服务管理其自有数据库，并允许不同微服务采用不同的数据持久化技术。
• 基础设施自动化(InfrastructureAutomation)：云化及自动化部署等技术极大地降低了微服务构建、部署和运维的难度，通过应用持续集成和持续交付等方法有助于达到加速推出市场的目的。
• 故障处理设计(Designfor failure)：微服务架构所带来的一个后果是必须考虑每个服务的失败容错机制。因此，微服务非常重视建立架构及业务相关指标的实时监控和日志机制。
• 演进式的设计(EvolutionaryDesign)：微服务应用更注重快速更新，因此系统的设计会随时间不断变化及演进。微服务的设计受业务功能的生命周期等因素影响。如某应用是整体式应用，但逐渐朝微应用架构方向演进，整体式应用仍是核心，但新功能将使用应用所提供的API构建。再如在某微服务应用中，可替代性模块化设计的基本原则，在实施后发现某两个微服务经常必须同时更新，则这很可能意味着应将其合并为一个微服务。
  
  

微服务适用的场景

基于微服务的优势，我们可以看到，微服务比较实用于以下场景：

• 对于业务流程较为复杂，且业务会变得逐渐复杂的项目，可以考虑使用微服务架构
• 项目存在多个团队（公司）多种开发语言时
• 核心业务和非核心业务变得泾渭分明
• 需要平滑升级时（服务无中断、客户无感知）
• 想对系统进行细粒度监控时 （bug调查困难或性能等问题）
• 既然微服务有其使用的场景，那么也一定有其优缺点。
  

既然微服务有其使用的场景，那么也一定有其优缺点。

微服务的优势

微服务的诞生正是在互联网高速发展，技术日新月异变化以及传统架构无法适应快速变化等多种因素共同推动下的必然产物。从一个网站的演变可以看到使用微服务后带来了很多优点，总结如下：

• 逻辑清晰：
  

这个特点是由微服务的单一职责的要求所带来的。逻辑清晰带来的是微服务的可维护性，在我们对一个微服务进行修改时，能够更容易分析到这个修改到底会产生什么影响，从而通过完备的测试保证修改质量。

• 简化部署：
  

微服务则可以只对一个微服务单独进行部署，不影响其他功能的同时，在效率上也得到了提升，从而快速的发布新的功能。

• 可扩展性强：
  

在分布式系统中，采用微服务的系统相对单块系统具备更好的可扩展性。
灵活组合减少浪费：在微服务架构中，可以通过组合已有的微服务以达到功能重用的目的，减少了重复浪费。

• 技术异构：
  

微服务间松耦合，不同的微服务可以选择不同的技术栈进行开发。

微服务的缺点

以往单体应用，排查问题通常是看一下日志，研究错误信息和调用堆栈。而微服务架构整个应用分散成多个服务，定位故障点非常困难。在微服务架构中，一个服务故障可能会产生雪崩效用，导致整个系统故障。

微服务架构虽然逻辑设计上看是完美的，但就像积木搭建的华丽宫殿一样，经不起风吹草动。微服务架构虽然解决了旧问题，也引入了新的问题：提高了系统的复杂度，此外还有：

• 服务的注册与发现问题；
• 服务之间的分布式事务问题；
• 数据隔离再来的报表处理问题；
• 服务之间的分布式一致性问题；
• 服务管理的复杂性，服务的编排；
• 不同服务实例的管理。2
  

微服务在使用上是一把“双刃剑”，这就像粮草如果在搬运的过程中被敌方夺取，那可能会是毁灭性的。所以DevOps团队在微服务的架构上需要非常的重视，一个成熟度高的微服务框架才是实现其DevOps的重要前提，反之亦然。（转自敏捷的小智）