32 KiB
微服务
本文翻译自 Martin Fowler 的 microservices。
过去几年中出现了“微服务架构”这一术语，它描述了将软件应用程序设计为若干个可独立部署的服务套件的特定方法。尽管这种架构风格尚未有精确的定义，但围绕业务能力、自动部署、端点智能以及语言和数据的分散控制等组织来说，它们还是存在着某些共同特征。
“微服务”——在拥挤的软件架构街道上又一个新名词。虽然我们的自然倾向是对它轻蔑一瞥，但这一点术语描述了一种越来越有吸引力的软件系统风格。在过去几年中，我们已经看到许多项目使用了这种风格，到目前为止其结果都是正向的，以至于对于我们 ThoughtWorks 的许多同事来说，它已成为构建企业应用程序的默认风格。然而，遗憾的是，没有太多信息可以概述微服务的风格以及如何实现。
简而言之，微服务架构风格[1]是一种将单个应用程序开发为一套小型服务的方法，每个小型服务都在自己的进程中运行，并与轻量级机制（通常是 HTTP 资源 API）进行通信。这些服务围绕业务功能构建，可通过全自动部署机制来独立部署。这些服务共用一个最小型的集中式管理，它们可以使用不同的编程语言编写，并使用不同的数据存储技术。
在开始解释微服务风格之前，将它与单片（monolithic）风格进行比较是有用的：单片应用程序被构建为单一单元。企业应用程序通常由三个部分构成：客户端用户界面（由用户机器上的浏览器中运行的 HTML 页面和 javascript 组成）、数据库（由许多表组成，通常是在关系型数据库中管理）系统、服务器端应用程序。服务器端应用程序处理 HTTP 请求，执行一些逻辑处理，从数据库检索和更新数据，以及选择和填充到要发送到浏览器的 HTML 视图中。这个服务器端应用程序是一个整体 - 一个逻辑可执行文件[2]。对系统的任何更改都涉及构建和部署新版本的服务器端应用程序。
这种单片服务器是构建这种系统的自然方式。处理请求的所有逻辑都在一个进程中运行，允许您使用语言的基本功能将应用程序划分为类，函数和命名空间。需要注意的是，您可以在开发人员的笔记本电脑上运行和测试应用程序，并使用部署管道确保对更改进行适当测试并将其部署到生产环境中。您可以通过在负载均衡器后面运行许多实例来水平扩展整体块。
单片应用程序可以取得成功，但越来越多的人对它们感到沮丧 - 尤其是在将更多应用程序部署到云中时。变更周期联系在一起 - 对应用程序的一小部分进行了更改，需要重建和部署整个整体。随着时间的推移，通常很难保持良好的模块化结构，使得更难以保持应该只影响该模块中的一个模块的更改。扩展需要扩展整个应用程序，而不是需要更多资源的部分。
这些挫折导致了微服务架构风格：将应用程序构建为服务套件。除了服务可独立部署和扩展的事实之外，每个服务还提供了一个牢固的模块边界，甚至允许以不同的编程语言编写不同的服务。他们也可以由不同的团队管理。
我们并不认为微服务风格是新颖的或创新的，其根源至少可以归结为Unix的设计原则。但我们认为没有足够的人考虑微服务架构，如果使用它们，许多软件开发会更好。
微服务架构的特征
我们不能说微服务架构风格有正式的定义，但我们可以尝试描述我们认为适合标签的架构的共同特征。与概述共同特征的任何定义一样，并非所有微服务架构都具有所有特征，但我们确实期望大多数微服务架构都具有大多数特征。虽然我们的作者一直是这个相当宽松的社区的积极成员，但我们的目的是尝试描述我们在自己的工作中所看到的以及我们所知道的团队的类似努力。特别是我们没有规定一些符合的定义。
通过服务进行组件化
只要我们参与软件行业，就一直希望通过将组件集成在一起来构建系统，就像我们在物理世界中看到事物的方式一样。在过去的几十年中，我们已经看到了大多数语言平台的大型公共图书馆的大量进展。
在谈论组件时，我们遇到了构成组件的困难定义。我们的定义是 组件是可独立更换和升级的软件单元。
微服务架构将使用库，但他们将自己的软件组件化的主要方式是分解为服务。我们将库定义 为链接到程序中并使用内存中函数调用调用的组件，而服务是与Web服务请求或远程过程调用等机制进行通信的进程外组件。（这与许多面向对象程序中的服务对象的概念不同[3]。）
将服务用作组件（而不是库）的一个主要原因是服务可以独立部署。如果您在单个进程中有一个由多个库组成的应用程序[4]，则对任何单个组件的更改都会导致必须重新部署整个应用程序。但是，如果将该应用程序分解为多个服务，您可以预期许多单个服务更改只需要重新部署该服务。这不是绝对的，一些变化将改变服务接口，从而产生一些协调，但良好的微服务架构的目标是通过服务合同中的紧密服务边界和演化机制来最小化这些。
将服务用作组件的另一个结果是更明确的组件接口。大多数语言没有用于定义显式发布接口的良好机制。通常，它只是文档和规程阻止客户端破坏组件的封装，导致组件之间过于紧密的耦合。通过使用显式远程调用机制，服务可以更轻松地避免这种情况。
使用这样的服务确实有缺点。远程调用比进程内调用更昂贵，因此远程API需要更粗糙，这通常更难以使用。如果您需要更改组件之间的职责分配，那么当您跨越流程边界时，这种行为的移动就更难。
在第一次近似中，我们可以观察到服务映射到运行时进程，但这只是第一次近似。服务可能包含多个始终一起开发和部署的进程，例如应用程序进程和仅由该服务使用的数据库。
围绕业务能力进行组织
在将大型应用程序拆分为多个部分时，通常管理侧重于技术层，从而导致UI团队，服务器端逻辑团队和数据库团队。当团队按照这些方式分开时，即使是简单的更改也可能导致跨团队项目需要时间和预算批准。一个聪明的团队将围绕这个进行优化，并为两个恶魔中的较小者提供丰富的优势 - 只需将逻辑强制应用到他们可以访问的任何应用程序中。换句话说，逻辑无处不在。这是康威定律[5]的一个例子。
设计系统（广泛定义）的任何组织都将产生一种设计，其结构是组织通信结构的副本。
- Melvyn Conway，1967年
微服务划分方法是不同的，分为围绕业务能力组织的服务 。此类服务为该业务领域采用广泛的软件实现，包括用户界面，持久存储和任何外部协作。因此，团队是跨职能的，包括开发所需的全部技能：用户体验，数据库和项目管理。
以这种方式组建的一家公司是www.comparethemarket.com。跨职能团队负责构建和运营每个产品，每个产品分为多个通过消息总线进行通信的单独服务。
大型单片应用程序也可以围绕业务功能进行模块化，尽管这不是常见的情况。当然，我们会敦促一个庞大的团队构建一个单一的应用程序，以便沿着业务线划分自己。我们在这里看到的主要问题是，它们往往围绕太多的背景进行组织。如果整体跨越许多这些模块化边界，团队的个体成员很难将它们纳入短期记忆中。此外，我们看到模块化生产线需要大量的纪律来执行。服务组件所需的更明确的分离使得更容易保持团队边界清晰。
产品不是项目
我们看到的大多数应用程序开发工作都使用项目模型：其目的是提供一些软件然后被认为是完成的。完成后，软件将移交给维护组织，构建它的项目团队将被解散。
微服务支持者倾向于避免使用这种模式，而更倾向于认为团队应该在其整个生命周期内拥有产品。对此的一个共同启示是亚马逊的“你构建，运行它”的概念，开发团队对生产中的软件负全部责任。这使开发人员能够日常接触他们的软件在生产中的行为，并增加与用户的联系，因为他们必须承担至少一些支持负担。
产品心态，与业务能力的联系紧密相连。不是将软件视为一组要完成的功能，而是存在一种持续的关系，其中的问题是软件如何帮助其用户增强业务能力。
没有理由为什么这种方法不能与单一应用程序一起使用，但较小的服务粒度可以使创建服务开发人员与其用户之间的个人关系变得更加容易。
智能端点和哑管
在不同流程之间建立沟通结构时，我们已经看到许多产品和方法都强调将重要的智慧放入沟通机制本身。一个很好的例子是企业服务总线（ESB），其中ESB产品通常包括用于消息路由，编排，转换和应用业务规则的复杂工具。
微服务社区倾向于采用另一种方法： 智能端点和哑管。从微服务构建的应用程序旨在尽可能地分离和内聚 - 它们拥有自己的域逻辑，并且更像是传统Unix意义上的过滤器 - 接收请求，适当地应用逻辑并产生响应。这些是使用简单的RESTish协议而不是复杂的协议（如WS-Choreography或BPEL或中央工具的编排）编排的。
最常用的两种协议是带有资源API的HTTP请求 - 响应和轻量级消息传递[8]。第一个最好的表达方式是
是网络，而不是网络
- 伊恩罗宾逊
微服务团队使用万维网（在很大程度上，Unix）构建的原则和协议。经常使用的资源可以通过开发人员或操作人员的非常小的努力来缓存。
常用的第二种方法是通过轻量级消息总线进行消息传递。所选择的基础设施通常是愚蠢的（如同仅作为消息路由器那样愚蠢） - 像RabbitMQ或ZeroMQ这样的简单实现不仅仅提供可靠的异步结构 - 智能仍然存在于生成和消费信息; 在服务中。
在整体中，组件在进程中执行，它们之间的通信是通过方法调用或函数调用。将整体变为微服务的最大问题在于改变通信模式。从内存中方法调用到RPC的简单转换会导致繁琐的通信无法正常执行。相反，您需要用粗粒度的方法替换细粒度的通信。
权力下放的治理
集中治理的后果之一是在单一技术平台上实现标准化的趋势。经验表明，这种方法是有限的 - 并非每个问题都是钉子而不是每个解决方案都是锤子。我们更喜欢使用正确的工具来完成工作，而单片应用程序可以在一定程度上利用不同的语言，但这并不常见。
将monolith的组件拆分为服务，我们可以在构建每个组件时做出选择。您想使用Node.js站立一个简单的报告页面吗？去吧。C ++是否适用于特别近乎实时的组件？精细。您想要交换不同风格的数据库，以更好地适应一个组件的读取行为？我们有重建他的技术。
当然，仅仅因为你可以做某事，并不意味着你应该 - 但以这种方式对系统进行分区意味着你可以选择。
构建微服务的团队也更喜欢采用不同的标准方法。他们不是使用在纸上某处写下的一组定义标准，而是更愿意生成有用的工具，其他开发人员可以使用它来解决与他们面临的类似问题。这些工具通常从实现中收集并与更广泛的组共享，有时，但不仅仅是使用内部开源模型。现在git和github已成为事实上的版本控制系统，开源实践在内部变得越来越普遍。
Netflix是遵循这一理念的组织的一个很好的例子。共享有用的，尤其是经过实战考验的代码，因为库鼓励其他开发人员以类似的方式解决类似问题，但如果需要，可以选择不同的方法。共享库往往侧重于数据存储，进程间通信的常见问题，我们将在下面进一步讨论基础架构自动化。
对于微服务社区来说，管理费用特别缺乏吸引力。这并不是说社区不重视服务合同。恰恰相反，因为往往会有更多。只是他们正在寻找管理这些合同的不同方式。模式，如 容错读者和消费者驱动的契约通常应用于微服务。这些援助服务合同独立发展。在构建过程中执行消费者驱动的合同可以增强信心并快速反馈您的服务是否正常运行。事实上，我们知道澳大利亚的一个团队通过消费者驱动的合同推动新服务的建设。他们使用简单的工具，允许他们定义服务的合同。在编写新服务的代码之前，这将成为自动构建的一部分。然后，服务建立在满足合同的地步 - 一种避免'YAGNI'的优雅方法[9]构建新软件时的两难选择。这些技术和围绕它们成长的工具通过减少服务之间的时间耦合来限制中央合同管理的需要。
也许分散治理的最高点是建立它/运行它由亚马逊推广的精神。团队负责他们构建的软件的所有方面，包括全天候运行软件。放弃这种责任水平绝对不是常态，但我们确实看到越来越多的公司将责任推向开发团队。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]）
然而，尽管有这些积极的经验，但我们并不认为我们确信微服务是软件架构的未来发展方向。虽然到目前为止我们的经验与整体应用相比是积极的，但我们意识到没有足够的时间让我们做出充分的判断。
通常，您的架构决策的真正后果只有在您制作它们几年后才会明显。我们已经看到一个项目，其中一个强大的团队，对模块化的强烈渴望，已经构建了一个多年来已经腐朽的单片架构。许多人认为微服务不太可能出现这种衰退，因为服务边界是明确的，很难修补。然而，在我们看到足够的系统具有足够的年龄之前，我们无法真正评估微服务架构是如何成熟的。
人们可能会期望微服务成熟得很好。在组件化的任何努力中，成功取决于软件在组件中的适用程度。很难弄清楚组件边界的确切位置。进化设计认识到正确边界的困难，因此很容易重构它们的重要性。但是，当您的组件是具有远程通信的服务时，则重构比使用进程内库更难。跨服务边界移动代码很困难，需要在参与者之间协调任何接口更改，需要添加向后兼容性层，并且测试变得更加复杂。
另一个问题是如果组件没有干净地组成，那么您所做的就是将复杂性从组件内部转移到组件之间的连接。这不仅仅是移动复杂性，而是将其移动到一个不那么明确且难以控制的地方。当你看到一个小而简单的组件内部时，很容易认为事情会更好，同时缺少服务之间的混乱连接。
最后，还有团队技能的因素。新技术往往被更熟练的团队所采用。但对于技能更高的团队来说，一种更有效的技术并不一定适用于技能较低的团队。我们已经看到很多不太熟练的团队构建凌乱的单片架构，但是当微服务发生这种混乱时，需要花时间看看会发生什么。一个糟糕的团队总是会创建一个糟糕的系统 - 很难说微服务是否可以减少这种情况下的混乱或使情况变得更糟。
我们听到的一个合理的论点是，您不应该从微服务架构开始。而是 从整体开始，保持模块化，并在整体成为问题时将其拆分为微服务。（虽然 这个建议并不理想，但是好的进程内接口通常不是一个好的服务接口。）
所以我们谨慎乐观地写下这个。到目前为止，我们已经看到了足够的微服务风格，觉得它可能是 一条值得走的路。我们无法确定最终会在哪里结束，但软件开发的挑战之一是您只能根据您当前必须提供的不完善信息做出决策。
脚注
流行的 应用程序架构 Web服务 微服务
脚注 1： 2011年5月在威尼斯附近的软件建筑师研讨会上讨论了“微服务”这一术语，以描述参与者认为其中许多人最近正在探索的共同建筑风格。2012年5月，同一小组决定将“微服务”作为最合适的名称。詹姆斯在2012年3月在克拉科夫的第33个学位的微服务中提出了一些这样的想法 - Java，Unix方式和Fred George 同时也是如此。Netflix的阿德里安·科克罗夫特（Adrian Cockcroft）将这种方法描述为“细粒度的SOA”，这与网络规模的风格一样开创性，就像本文中提到的许多其他人一样 - Joe Walnes，Dan North，
2： Unix社区一直在使用monolith一词。它出现在“Unix编程的艺术”中，用于描述太大的系统。
3： 许多面向对象的设计人员，包括我们自己，在域驱动设计意义上使用术语服务对象来执行一个对象，该对象执行一个与实体无关的重要过程。这与我们在本文中如何使用“服务”的概念不同。可悲的是，服务这个词既有意义，我们必须忍受多义词。
4： 我们认为应用程序是一种将代码库，功能组和资金主体绑定在一起的社交构建。
5： 原始论文可以在Melvyn Conway的网站上找到
6： 我们无法抗拒提到Jim Webber关于ESB代表“Egregious Spaghetti Box”的声明。
7： Netflix使链接显式化 - 直到最近将其架构风格称为细粒度SOA。
8： 在极端规模下，组织经常转向二进制协议 - 例如protobufs。使用这些系统的系统仍然具有智能端点，哑管的特点 - 并且 在规模上权衡透明度。大多数网络资产，当然绝大多数企业都不需要做出这种权衡 - 透明度可能是一个巨大的胜利。
9： “YAGNI”或“你不需要它”是一个XP原则和劝告，直到你知道你需要它们才能添加功能。
10： 我们认为巨石是单一语言有点不太原谅 - 为了在今天的网络上构建系统，您可能需要了解JavaScript和XHTML，CSS，您选择的服务器端语言，SQL和ORM方言。几乎没有单一语言，但你知道我们的意思。
11： Adrian Cockcroft 在2013年11月在Flowcon 上发表的精彩演讲中特别提到“开发人员自助服务”和“开发人员运行他们所写的内容”（原文如此）。
12： 我们在这里有点不知所措。显然，在更复杂的拓扑中部署更多服务比部署单个整体更困难。幸运的是，模式降低了这种复杂性 - 工具投资仍然是必须的。
13： 实际上，Dan North将这种风格称为可替换组件体系结构而不是微服务。由于这似乎与特征的一部分相关，我们更喜欢后者。
14： Kent Beck强调这是他在实现模式中的设计原则之一 。
15： SOA并不是这段历史的根源。我记得当SOA术语出现在本世纪初时，人们说“我们已经这么做了多年”。一种观点认为，这种风格的根源在于COBOL程序在企业计算早期通过数据文件进行通信的方式。在另一个方向，可以说微服务与Erlang编程模型是一样的，但是应用于企业应用程序上下文。
参考
虽然这不是一个详尽的列表，但是从业者可以从中汲取灵感或者支持与本文中描述的类似哲学的许多来源。
博客和在线文章
Clemens Vasters在微软上的云博客 David Morgantini在他的博客上对该主题的介绍 来自Heroku的12个因子应用程序 英国政府数字服务设计原则 Jimmy Nilsson的博客和关于有关云块计算的infoq的文章 Alistair Cockburn在六角形建筑上
图书
释放它 在实践中休息 Web API设计（免费电子书）。Apigee的Brian Mulloy。 企业集成模式 unix编程的艺术 以测试为指导，发展面向对象的软件 现代企业：绩效与成长的组织设计 持续交付：通过构建，测试和部署自动化发布可靠的软件 领域驱动设计：解决软件核心的复杂性
演讲
没有建筑师的建筑。Erik Doernenburg。 我的公共汽车看起来很大吗？。Jim Webber和Martin Fowler，QCon 2008 Guerilla SOA。吉姆韦伯，2006年 有效交付的模式。Dan North，2011。 Adrian Cockcroft的幻灯片频道。 水and和超媒体。Ian Robinson，JavaZone 2010 正义将需要一百万个错综复杂的举动。Leonard Richardson，Qcon 2008。 Java，UNIX方式。James Lewis，JavaZone 2012 微服务架构。弗雷德乔治，你好！2012 在guardian.co.uk民主化关注数据。Graham Tackley，GOTO Aarhus 2013 使用RxJava进行功能反应式编程。Ben Christensen，GOTO Aarhus 2013（需要注册）。 打破巨石。Stefan Tilkov，2012年5月。
文件
L. Lamport，“可靠的分布式多处理系统的实现”，1978年http：// research.microsoft.com/en-us/um/people/lamport/pubs/implementation.pdf L. Lamport，R。Shostak，M。Pease，“The Byzantine Generals Problem”，1982（可在）http：// www.cs.cornell.edu/courses/cs614/2004sp/papers/lsp82.pdf RT Fielding，“建筑风格和基于网络的软件架构设计”，2000 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm EA Brewer，“走向强大的分布式系统”，2000 http://www.cs.berkeley.edu/~rewerer / cs262b-2004 / PODC-keynote.pdf E. Brewer，“十二年后的CAP：'规则'如何改变”，2012年，http：//www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed
重大修订
2014年3月25日：上一期是未来的微服务吗？
2014年3月24日：增加了关于进化设计的部分
2014年3月19日：增加了基础设施自动化和故障设计部分
2014年3月18日：增加了关于分散数据的部分
2014年3月17日：增加了关于权力下放治理的部分
2014年3月14日：增加了关于智能终端和哑管的部分
2014年3月13日：增加了关于产品而非项目的部分
2014年3月12日：增加了关于组织业务能力的部分
2014年3月10日：第一期出版