没有它，你的 DevOps 可能玩不转
善用兵者，役不再籍，粮不三载。取用于国，因粮于敌，故军食可足也。
——《孙子兵法》
那么，DevOps是什么？
DevOps 是集文化理念、实践和工具于一身，可以提高组织高速交付应用程序和服务的能力，与使用传统软件开发和基础设施管理流程相比，能够帮助组织更快地发展和改进产品。这种速度使组织能够更好地服务其客户，并在市场上更高效地参与竞争。
——AWS
什么是微服务
是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。
微服务的特点
根据 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调查困难或性能等问题） 既然微服务有其使用的场景，那么也一定有其优缺点。
微服务的优势
逻辑清晰：
简化部署：
可扩展性强：
灵活组合减少浪费：在微服务架构中，可以通过组合已有的微服务以达到功能重用的目的，减少了重复浪费。
技术异构：
微服务的缺点
服务的注册与发现问题； 服务之间的分布式事务问题； 数据隔离再来的报表处理问题； 服务之间的分布式一致性问题； 服务管理的复杂性，服务的编排； 不同服务实例的管理。