本文翻译自Martin Fowler的微服务
“微服务” - 在拥挤的软件架构街道上又一个新名词。 虽然我们的自然倾向是通过轻蔑的眼神传递这些东西，但这一点术语描述了我们发现越来越有吸引力的软件系统风格。 我们已经看到许多项目在过去几年中使用了这种风格，到目前为止的结果是积极的，以至于对于我们的许多同事而言，这已经成为构建企业应用程序的默认样式。 然而，遗憾的是，没有太多信息可以概述微服务的风格以及如何实现。
简而言之，微服务架构风格[1]是一种将单个应用程序开发为一套小型服务的方法，每个小型服务都在自己的进程中运行，并用轻量级机制（通常是HTTP资源API）进行通信。 这些服务围绕业务功能构建，可通过全自动部署机制独立部署。 这些服务至少可以集中管理，可以用不同的编程语言编写，并使用不同的数据存储技术。
为了开始解释微服务架构，将它与整体应用架构进行比较是有用的：作为单个整体构建的单片应用程序。 企业应用程序通常由三个主要部分构成：客户端用户界面（由用户机器上的浏览器中运行的HTML页面和javascript组成）数据库（由插入到公共数据库管理中的许多表组成，通常是关系数据库管理系统）和服务器端应用程序。 服务器端应用程序将处理HTTP请求，执行逻辑，从数据库检索和更新数据，以及选择和填充要发送到浏览器的HTML视图。 这个服务器端应用程序是一个整体 - 一个逻辑可执行文件[2]。 对系统的任何更改都涉及构建和部署新版本的服务器端应用程序。
这种单个服务器是构建这种系统的自然方式。 处理请求的所有逻辑都在一个进程中运行，允许您使用语言的基本功能将应用程序划分为类，函数和命名空间。 需要注意的是，您可以在开发人员的笔记本电脑上运行和测试应用程序，并使用部署管道确保对更改进行适当测试并将其部署到生产环境中。 您可以通过在负载均衡器后面运行许多实例来水平扩展整体。
单个应用程序可以取得成功，但越来越多的人对它们感到沮丧 - 特别是在将更多应用程序部署到云中时。 变更周期联系在一起 - 对应用程序的一小部分进行了更改，需要重建和部署整个整体。 随着时间的推移，通常很难保持良好的模块化结构，使得更难以保持应该只影响该模块中的一个模块的更改。 扩展需要扩展整个应用程序，而不是需要更多资源的部分。
这些挫折导致产生了微服务架构风格：将应用程序构建为服务套件。 除了服务可独立部署和扩展的事实之外，每个服务还提供了一个牢固的模块边界，甚至允许以不同的编程语言编写不同的服务。 他们也可以由不同的团队管理。
我们并不认为微服务风格是新颖的或创新的，其根源至少可以归结为Unix的设计原则。 但我们认为没有足够的人考虑微服务架构，如果使用它们，许多软件开发会更好。
微服务架构的特征
我们不能说微服务架构风格有正式的定义，但我们可以尝试描述我们认为适合架构的共同特征。 与概述共同特征的任何定义一样，并非所有微服务架构都具有所有特征，但我们确实期望大多数微服务架构都具有大多数特征。 虽然我们的作者一直是这个相当宽松的社区的积极成员，但我们的目的是尝试描述我们在自己的工作中所看到的以及我们所知道的团队的类似努力。 特别是我们没有规定一些符合的定义。
通过服务进行组件化
只要我们参与软件行业，就一直希望通过将组件集成在一起来构建系统，就像我们在物理世界中看到事物的方式一样。 在过去的几十年中，我们已经看到了大多数语言平台的大型公共库的大量进展。
在谈论组件时，我们遇到了定义组件的困难。 我们的定义是组件是可独立更换和升级的软件单元。
微服务架构会使用依赖库，但他们将自己的软件组件化的主要方式是分解为服务。 我们将库定义为链接到程序中并调用内存中函数的组件，而服务是与Web服务请求或RPC等机制进行通信的进程外组件。 （这与许多面向对象程序中的服务对象的概念不同[3]。）
将服务用作组件（而不是库）的一个主要原因是服务可以独立部署。 如果您在单个进程中有一个由多个库组成的应用程序[4]，则对任何单个组件的更改都会导致必须重新部署整个应用程序。 但是，如果将该应用程序分解为多个服务，您可以预期许多单个服务更改只需要重新部署该服务。 这不是绝对的，一些变化将改变服务接口，从而产生一些协调，但良好的微服务架构的目标是通过服务合同中的紧密服务边界和演化机制来最小化这些。
将服务用作组件的另一个结果是更明确的组件接口。 大多数语言没有用于定义显式发布接口的良好机制。 通常，它只是文档和规程阻止客户端破坏组件的封装，导致组件之间过于紧密的耦合。 通过使用显式远程调用机制，服务可以更轻松地避免这种情况。
使用这样的服务确实有缺点。 远程调用比进程内调用更昂贵，因此远程API需要更粗糙，这通常更难以使用。 如果您需要更改组件之间的职责分配，那么当您跨越流程边界时，这种行为的变化就更难。
在第一次近似中，我们可以观察到服务映射到运行时进程，但这只是第一次近似。 服务可能包含多个始终一起开发和部署的进程，例如应用程序进程和仅由该服务使用的数据库。
围绕业务功能进行组织
在将大型应用程序拆分为多个部分时，通常管理侧重于技术层，从而导致UI团队，服务器端逻辑团队和数据库团队。 当团队按照这些方式分开时，即使是简单的更改也可能导致跨团队项目需要时间和预算批准。 一个聪明的团队将围绕这个进行优化，并为两个恶魔中的较小者提供丰富的优势 - 只需将逻辑强制应用到他们可以访问的任何应用程序中。 换句话说，逻辑无处不在。 这是康威定律[5]的一个例子。
1 | 设计系统（广泛定义）的任何组织都将产生一种设计，其结构是组织通信结构的副本。 |
微服务通过围绕业务功能组织来划分服务的方法是不同的。 此类服务为该业务领域采用广泛的软件实现，包括用户界面，持久存储和任何外部协作。 因此，团队是跨职能的，包括开发所需的全部技能：用户体验，数据库和项目管理。
以这种方式组建的一家公司是 www.comparethemarket.com。 跨职能团队负责构建和运营每个产品，每个产品分为多个通过消息总线进行通信的单独服务。
大型单片应用程序也可以围绕业务功能进行模块化，尽管这不是常见的情况。 当然，我们会敦促一个庞大的团队构建一个单一的应用程序，以便沿着业务线划分自己。 我们在这里看到的主要问题是，它们往往围绕太多的背景进行组织。 如果整体跨越许多这些模块化边界，团队的个别成员可能难以将它们装入短期记忆中。 此外，我们看到模块化生产线需要大量的纪律来执行。 服务组件所需的更明确的分离使得更容易保持团队边界清晰。
产品不是项目
我们看到的大多数应用程序开发工作都使用项目模型：其目的是提供一些软件然后被认为是完成的。 完成后，软件将移交给维护组织，构建它的项目团队将被解散。
微服务支持者倾向于避免使用这种模式，而更倾向于认为团队应该在其整个生命周期内拥有产品。 对此的一个共同启示是亚马逊的“你构建，运行它”的概念，开发团队对生产中的软件负全部责任。 这使开发人员能够日常接触他们的软件在生产中的行为，并增加与用户的联系，因为他们必须承担至少一些支持负担。
产品心态，与业务能力的联系紧密相连。 不是将软件视为一组要完成的功能，而是存在一种持续的关系，其中的问题是软件如何帮助其用户增强业务能力。
没有理由为什么这种方法不能与单一应用程序一起使用，但较小的服务粒度可以使创建服务开发人员与其用户之间的个人关系变得更加容易。
智能endpoints和dump pipes
在不同进程之间建立沟通结构时，我们已经看到许多产品和方法都强调将重要的智慧放入沟通机制本身。 一个很好的例子是企业服务总线（ESB），其中ESB产品通常包括用于消息路由，编排，转换和应用业务规则的复杂工具。
微服务社区倾向于采用另一种方法：智能endpoints和dump pipes。 从微服务构建的应用程序旨在尽可能地分离和内聚 - 它们拥有自己的域逻辑，并且更像是传统Unix意义上的过滤器 - 接收请求，适当地应用逻辑并产生响应。 这些是使用简单的RESTish协议而不是复杂的协议（如WS-Choreography或BPEL或中央工具的编排）编排的。
最常用的两种协议是带有资源API的HTTP请求-响应 和 轻量级消息传递[8]。 第一个最好的表达方式是
1 | 成为网络，而不是在网络后面 |
微服务团队使用万维网（在很大程度上，Unix）构建的原则和协议。 经常使用的资源可以通过开发人员或操作人员的非常小的努力来缓存。
常用的第二种方法是通过轻量级消息总线进行消息传递。 所选择的基础设施通常是愚蠢的（如同仅作为消息路由器那样愚蠢） - 诸如RabbitMQ或ZeroMQ之类的简单实现除了提供可靠的异步结构之外没有多大作用 - 智能仍然存在于生产和 消费信息; 在服务中。
在整体应用中，组件在进程中执行，它们之间的通信是通过方法调用或函数调用。 将整体变为微服务的最大问题在于改变通信模式。 从内存中方法调用到RPC的简单转换会导致繁琐的通信无法正常执行。 相反，您需要用粗粒度的方法替换细粒度的通信。
去中心化治理
集中治理的后果之一是在单一技术平台上实现标准化的趋势。 经验表明，这种方法是有限的 - 并非每个问题都是钉子而不是每个解决方案都是锤子。 我们更喜欢使用正确的工具来完成工作，而单片应用程序可以在一定程度上利用不同的语言，但这并不常见。
将整体应用的组件拆分为服务，我们可以在构建每个组件时做出选择。 您想使用Node.js站立一个简单的报告页面吗？ 去吧。 C++是否适用于特别近乎实时的组件？ 精细。 您想要交换不同风格的数据库，以更好地适应一个组件的读取行为？ 我们有重建他的技术。
当然，仅仅因为你可以做某事，并不意味着你应该 - 但以这种方式对系统进行划分意味着你可以选择。
构建微服务的团队也更喜欢采用不同的标准方法。 他们不是使用在纸上某处写下的一组定义标准，而是更愿意生成有用的工具，其他开发人员可以使用它来解决与他们面临的类似问题。 这些工具通常从实现中收集并与更广泛的组共享，有时不仅仅是使用内部开源模型。 现在git和github已成为事实上的版本控制系统，开源实践在内部变得越来越普遍。
Netflix是遵循这一理念的一个很好的例子。 共享有用的，尤其是经过实战考验的代码，因为库鼓励其他开发人员以类似的方式解决类似的问题，但如果需要，可以选择不同的方法。 共享库往往侧重于数据存储，进程间通信的常见问题，我们将在下面进一步讨论基础架构自动化。
对于微服务社区来说，管理费用特别缺乏吸引力。这并不是说社区不重视服务合同。恰恰相反，因为往往会有更多。只是他们正在寻找管理这些合同的不同方式。容忍阅读器和消费者驱动合同等模式通常应用于微服务。这些援助服务合同独立发展。在构建过程中执行消费者驱动的合同可以增强信心并快速反馈您的服务是否正常运行。事实上，我们知道澳大利亚的一个团队通过消费者驱动的合同推动新服务的建设。他们使用简单的工具，允许他们定义服务的合同。在编写新服务的代码之前，这将成为自动构建的一部分。然后，该服务仅在满足合同的情况下构建 - 这是在构建新软件时避免’YAGNI’(“YAGNI”或“You Aren’t Going To Need It 你不会需要它”是一个XP原则和劝告，直到你知道你需要它们才能添加功能) 困境的优雅方法。这些技术和围绕它们成长的工具通过减少服务之间的时间耦合来限制中央合同管理的需要。
也许分散治理的最高点是由亚马逊推广的精神建立/运行它。 团队负责他们构建的软件的所有方面，包括全天候运行软件。 放弃这种责任水平绝对不是常态，但我们确实看到越来越多的公司将责任推向开发团队。 Netflix是另一个采用这种精神的组织[11]。 每天晚上凌晨3点被您的手机唤醒肯定是在编写代码时注重质量的强大动力。 这些想法与传统的集中治理模式相差甚远。
去中心化数据管理
数据管理的分散化以多种不同的方式呈现。 在最抽象的层面上，它意味着世界的概念模型在不同系统之间会有所不同。 这是在大型企业中集成时的常见问题，客户的销售视图将与支持视图不同。 销售视图中称为客户的某些内容可能根本不会出现在支持视图中。 那些做的可能具有不同的属性和（更糟糕的）具有微妙不同语义的共同属性。
此问题在应用程序之间很常见，但也可能在应用程序中发生，特别是当该应用程序分为单独的组件时。 一种有用的思考方式是有界上下文 的领域驱动设计概念。 DDD将复杂域划分为多个有界上下文，并映射出它们之间的关系。 此过程对单片和微服务体系结构都很有用，但服务和上下文边界之间存在自然关联，这有助于澄清，正如我们在业务功能部分中所述，强化了分离。
除了关于概念模型的分散决策之外，微服务还分散了数据存储决策。 虽然单一应用程序更喜欢单个逻辑数据库来存储持久性数据，但企业通常更喜欢跨越一系列应用程序的单个数据库 - 其中许多决策是通过供应商围绕许可的商业模型来实现的。 微服务更喜欢让每个服务管理自己的数据库，可以是相同数据库技术的不同实例，也可以是完全不同的数据库系统 - 这种方法称为多语言持久性(Polyglot Persistence)。 您可以在整体应用中使用多语言持久性，但它在微服务中更常出现。
跨微服务的分散数据对数据更新有影响。 处理更新的常用方法是在更新多个资源时使用事务来保证一致性。 这种方法通常用于整体结构中。
使用这样的事务有助于保持一致性，但会产生显着的时间耦合，这在多个服务中是有问题的。 众所周知，分布式事务很难实现，因此微服务架构强调服务之间的无事务协调，明确认识到一致性可能只是最终的一致性，而问题是通过补偿操作来处理的。
选择以这种方式管理数据不一致 是许多开发团队面临的新挑战，但它通常与业务实践相匹配。 企业通常会处理一定程度的不一致，以便快速响应需求，同时采取某种逆转流程来应对错误。 只要修复错误的成本低于在更大的一致性下丢失业务的成本，那么权衡是值得的。
基础设施自动化
基础设施自动化技术在过去几年中发生了巨大变化 - 特别是云和AWS的发展降低了构建、部署和运行微服务的操作复杂性。
许多使用微服务构建的产品或系统都是由具有丰富的持续交付和其前身持续集成经验的团队构建的。 以这种方式构建软件的团队广泛使用基础设施自动化技术。 这在下面显示的构建管道中说明。
由于这不是关于持续交付的文章，我们将在这里注意几个关键功能。 我们希望尽可能多的信心，我们的软件正在运行，因此我们运行了大量的自动化测试。 软件“向上”的管道意味着我们自动部署到每个新环境。
通过这些环境，整个应用程序将非常开心地构建、测试并推动。 事实证明，一旦你投资自动化的生产之路，那么部署更多应用程序似乎不再那么可怕了。 请记住，CD的目标之一就是使部署无聊，所以无论是一个还是三个应用程序，只要它仍然无聊就无所谓[12]。
我们看到团队使用广泛的基础设施自动化的另一个领域是管理生产中的微服务。 与我们上面的断言相反，只要部署很无聊，整体和微服务之间没有太大的区别，每个部署的运营环境可能会截然不同。
设计失败处理
使用服务作为组件的结果是，需要设计程序让它们能够容忍服务的失败。 由于供应者不可用，任何服务调用都可能失败，客户必须尽可能优雅地对此做出响应。 与单片设计相比，这是一个缺点，因为它引入了额外的复杂性来处理它。 结果是微服务团队不断反思服务失败如何影响用户体验。 Netflix的Simian Army在工作日引发服务甚至数据中心的故障，以测试应用程序的弹性和监控。
生产中的这种自动化测试足以让大多数操作组在休息一周之前就会出现这种情绪。 这并不是说整体式建筑风格不具备复杂的监控设置 - 在我们的经验中它不常见。
由于服务可能随时发生故障，因此能够快速检测故障并在可能的情况下自动恢复服务非常重要。 微服务应用程序非常重视应用程序的实时监控，检查架构元素（数据库每秒获得多少请求）和业务相关度量（例如每分钟收到多少订单）。 语义监控可以提供出现问题的早期预警系统，从而触发开发团队跟进和调查。
这对于微服务架构尤为重要，因为微服务对编排和事件协作 的偏好会导致紧急行为。 虽然许多权威人士赞扬偶然出现的价值，但事实是，新兴行为有时可能是一件坏事。 监控对于快速发现不良紧急行为至关重要，因此可以修复。
整体结构可以像微服务一样透明 - 事实上，它们应该是。 不同之处在于您绝对需要知道在不同进程中运行的服务何时断开连接。 对于同一过程中的库，这种透明性不太可能有用。
微服务团队希望看到针对每个服务的复杂监控和日志记录设置，例如显示上/下状态的仪表板以及各种运营和业务相关指标。 有关断路器状态，当前吞吐量和延迟的详细信息是我们经常遇到的其他示例。
进化设计
微服务从业者通常来自进化设计背景，并将服务分解视为进一步的工具，使应用程序开发人员能够控制应用程序中的更改， 而不会降低变更速度。 变更控制并不一定意味着改变 - 通过正确的态度和工具，您可以对软件进行频繁，快速和良好控制的更改。
每当您尝试将软件系统分解为组件时，您就面临着如何分割各个部分的决定 - 我们决定切割应用程序的原则是什么？ 组件的关键属性是独立替换和可升级性的概念[13] - 这意味着我们寻找可以想象在不影响其协作者的情况下重写组件的点。 实际上，许多微服务组通过明确地期望许多服务被废弃而不是长期演变来进一步考虑这一点。
Guardian网站是一个设计和构建为整体的应用程序的一个很好的例子，但是在微服务方向上不断发展。 monolith仍然是网站的核心，但他们更喜欢通过构建使用monolith API的微服务来添加新功能。 这种方法对于本质上是临时的功能尤其方便，例如处理体育赛事的专用页面。 网站的这一部分可以使用快速开发语言快速组合在一起，并在事件结束后删除。 我们在金融机构看到过类似的方法，为市场机会增加新服务，并在几个月甚至几周后丢弃。
这种对可替换性的强调是模块化设计的更一般原则的一个特例， 即通过变化模式驱动模块化[14]。 您希望在同一模块中保持同时更改的内容。 很少变化的系统部分应该与目前正在经历大量流失的系统处于不同的服务中。 如果您发现自己反复更改两项服务，那就表明它们应该合并。
将组件放入服务中可以为更细粒度的发布计划添加机会。 对于整体，任何更改都需要完整构建和部署整个应用程序。 但是，使用微服务，您只需要重新部署您修改的服务。 这可以简化并加快发布过程。 缺点是您必须担心一项服务的变化会打破其消费者。 传统的集成方法是尝试使用版本控制来解决这个问题，但微服务世界中的偏好仅仅是使用版本控制作为最后的手段。 我们可以通过设计服务尽可能容忍提供者的变化来避免大量的版本控制。
微服务是未来吗？
我们写这篇文章的主要目的是解释微服务的主要思想和原则。 通过花时间来做到这一点，我们清楚地认为微服务架构风格是一个重要的想法 - 值得认真考虑企业应用程序。 我们最近使用这种方式构建了几个系统，并了解了其他使用和支持这种方法的人。
我们知道谁在某种程度上开创了这种架构风格，包括亚马逊，Netflix，卫报，英国政府数字服务，realestate.com.au，Forward和comparethemarket.com。 2013年的会议周充满了一些公司的例子，这些公司正在转向可以归类为微服务的公司 - 包括Travis CI。 此外，有很多组织长期以来一直在做我们称之为微服务的东西，但没有使用过这个名字。 （通常这被标记为SOA - 尽管如我们所说，SOA有许多相互矛盾的形式。[15]）
然而，尽管有这些积极的经验，但我们并不认为我们确信微服务是软件架构的未来发展方向。 虽然到目前为止我们的经验与整体应用相比是积极的，但我们意识到没有足够的时间让我们做出充分的判断。
通常，您的架构决策的真正后果只有在您制作它们几年后才会明显。 我们已经看到一个项目，其中一个强大的团队，对模块化的强烈渴望，已经构建了一个多年来已经腐朽的单片架构。 许多人认为，微服务不太可能出现这种衰退，因为服务边界是明确的，很难修补。 然而，在我们看到足够的系统具有足够的年龄之前，我们无法真正评估微服务架构是如何成熟的。
人们可能会期望微服务成熟得很好。 在组件化的任何努力中，成功取决于软件在组件中的适用程度。 很难弄清楚组件边界的确切位置。 进化设计认识到正确边界的困难，因此很容易重构它们的重要性。 但是，当您的组件是具有远程通信的服务时，则重构比使用进程内库更难。 跨服务边界移动代码是困难的，任何接口更改都需要在参与者之间进行协调，需要添加向后兼容性层，并且测试变得更加复杂。
另一个问题是如果组件没有干净地组成，那么您所做的就是将复杂性从组件内部转移到组件之间的连接。 这不仅仅是移动复杂性，而是将其移动到一个不那么明确且难以控制的地方。 当你看到一个小而简单的组件内部时，很容易认为事情会更好，同时缺少服务之间的混乱连接。
最后，还有团队技能的因素。 新技术往往被更熟练的团队所采用。 但对于技能更高的团队来说，一种更有效的技术并不一定适用于技能较低的团队。 我们已经看到很多不太熟练的团队构建凌乱的单片架构，但是当微服务发生这种混乱时，需要花时间看看会发生什么。 一个糟糕的团队总是会创建一个糟糕的系统 - 很难说微服务是否可以减少这种情况下的混乱或使情况变得更糟。
我们听到的一个合理的论点是，您不应该从微服务架构开始。 而是从整体开始，保持模块化，并在整体成为问题时将其拆分为微服务。 （虽然这个建议并不理想，但是好的进程内接口通常不是一个好的服务接口。）
所以我们谨慎乐观地写下这个。 到目前为止，我们已经看到了足够的微服务风格，觉得它可能是一条值得走的路。 我们无法确定最终会在哪里结束，但软件开发的挑战之一是您只能根据您当前必须提供的不完善信息做出决策。
旁注
微服务有多大？
虽然“微服务”已经成为这种建筑风格的流行名称，但它的名字确实导致了对服务规模的不幸关注以及关于什么构成“微”的争论。 在我们与微服务从业者的对话中，我们看到了各种规模的服务。 报道的最大尺寸遵循亚马逊关于Two Pizza Team的概念（即整个团队可以由两个比萨饼喂养），意味着不超过十几个人。 在规模较小的规模上，我们已经看到了一个由六人组成的团队支持六项服务的设置。
这导致了这样的问题：在这个尺寸范围内是否存在足够大的差异，即每个人的服务和每人服务的尺寸不应该集中在一个微服务标签下。 目前我们认为将它们组合在一起会更好，但当我们进一步探索这种风格时，我们肯定会改变主意。
微服务和SOA
当我们谈到微服务时，一个常见的问题是这是否只是我们十年前看到的面向服务架构（SOA）。这一点有其优点，因为微服务风格与一些SOA倡导者非常相似。然而，问题是SOA意味着太多不同的东西，而且大多数时候我们遇到称为“SOA”的东西，它与我们在这里描述的样式有很大的不同，通常是因为我们专注于ESBs整合单片应用程序。
特别是我们已经看到了许多拙劣的服务导向实现 - 从隐藏ESB [6]中的复杂性的趋势，到耗资数百万并且没有价值的失败的多年计划，到积极抑制变化的集中治理模型，有时很难看到过去的这些问题。
当然，微服务社区中使用的许多技术都是从开发人员在大型组织中集成服务的经验中发展而来的。容忍读者模式就是一个例子。使用网络的努力做出了贡献，使用简单的协议是从这些经验中获得的另一种方法 - 远离中心标准的反应，这种标准已达到复杂性，坦率地说，令人惊叹。 （只要你需要一个本体来管理你的本体，你就知道你遇到了很大的麻烦。）
SOA的这种常见表现导致一些微服务提倡者完全拒绝SOA标签，尽管其他人认为微服务是SOA的一种形式[7]，也许服务导向正确。无论哪种方式，SOA代表这些不同的事物 意味着有一个更清晰地定义这种建筑风格的术语是有价值的。
许多语言，很多选择
JVM作为一个平台的发展只是在一个通用平台中混合语言的最新例子。 通常的做法是采用更高级别的语言来利用几十年来更高级别的抽象。 正如下降到裸机并将性能敏感代码写入较低级别的代码。 然而，许多整体应用不需要这种级别的性能优化，也不需要DSL和更高级别的抽象（令我们沮丧）。 相反，单一应用通常是单一语言，其趋势是限制使用的技术数量[10]。
经过实战检验的标准和强制执行的标准
微服务团队倾向于避开企业架构小组制定的严格执行标准，但很乐意使用甚至传播HTTP，ATOM和其他微格式等开放标准的使用，这有点二分法。
关键的区别在于如何制定标准以及如何实施标准。 由IETF等团体管理的标准只有在更广泛的世界中有多个实时实施并且通常来自成功的开源项目时才成为标准。
这些标准与企业界的许多标准不同，它们通常由最近没有编程经验或受供应商过度影响的团体开发。
做正确的事情很容易
我们发现由于持续交付和部署而增加自动化的一个副作用是创建有用的工具来帮助开发人员和操作人员。 用于创建人工制品，管理代码库，提供简单服务或添加标准监视和日志记录的工具现在非常普遍。 网上最好的例子可能是Netflix的开源工具集，但还有其他一些，包括我们广泛使用的Dropwizard。
断路器和生产就绪代码
断路器出现在 Release It 中，以及其他模式，如Bulkhead和Timeout。 这些模式一起实施，在构建通信应用程序时至关重要。 这篇Netflix博客文章很好地解释了它们的应用。
同步调用被认为是有害的
每当您在服务之间进行多次同步调用时，您将遇到停机的乘法效应。 简而言之，这就是系统停机时间成为各个组件停机时间的产物。 您面临一个选择，使您的呼叫异步或管理停机时间。 在www.guardian.co.uk，他们在新平台上实施了一个简单的规则 - 每个用户请求一个同步调用，而在Netflix，他们的平台API重新设计已经在API结构中构建了异步性。