近几年来，“微服务体系结构”这个术语出现了，它描述了将软件应用程序设计为可独立部署的服务套件的特定方式。尽管这种架构风格没有确切的定义，但围绕业务能力，自动化部署，智能终端以及数据的分散控制等方面存在着某些共同特征。
“微服务” - 这一个在软件架构拥挤的街道上的又一个新名词。尽管我们的自然倾向是以轻蔑的眼光来传递它，但这个术语描述了一种我们发现越来越吸引人的软件系统风格。我们已经看到许多项目在过去几年中都采用了这种风格，迄今为止的结果是积极的，因此对于我们的许多人来说，这正成为构建企业应用程序的默认风格。但可悲的是，没有太多的信息去描述了微服务的风格以及如何去做。简而言之，微服务架构风格是一种将单个应用程序作为一套小型服务来开发的方法，每个服务都运行在自己的进程中，并与轻量级机制（通常是HTTP、RPC调用资源API方式出现）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。
单体应用示例图 微服务示例图
当我们要开始解释什么是微服务风格时，将其与单体应用风格进行比较是非常有用的：我们可以将单一应用程序包含的所有功能构建为单一个单元（如单体应用示例图所示）。企业应用程序通常建立在三个主要部分之上：一个客户端用户界面（由用户计算机上的浏览器中运行的HTML页面和JavaScript组成）数据库（关系数据库管理的许多表系统）和一个服务器端应用程序。服务器端应用程序将处理HTTP请求，执行业务逻辑，从数据库检索和更新数据，选择并填充要发送到浏览器的HTML视图。这个服务器端应用程序是一个庞然大物 - 一个逻辑上可执行文件。系统的任何更改都涉及构建和部署新版本的服务器端应用程序。这种单一的应用是构建这种系统的一种自然方式。处理请求的所有逻辑都在一个进程中运行，允许您使用语言的基本功能将应用程序划分为类库，类，函数和名称空间。谨慎操作时，您可以在开发人员的笔记本电脑上运行和测试应用程序，并使用部署管道来确保更改经过适当测试并部署到生产环境中。您可以通过在负载均器后面运行多个实例来横向扩展整体。虽然单一应用程序取得很多成功案例，但越来越多的人感到沮丧 - 尤其是随着更多应用程序部署到云中。变更周期是连在一起的 - 对应用程序的一小部分进行更改，需要重建和部署整个整体。随着时间的推移，通常很难保持良好的模块化结构，这使得难以保持应该仅影响该模块中的一个模块的变化。扩展需要扩展整个应用程序，而不是扩展需要变更的那部分资源。
单体应用集群 微服务应用集群
这些挫败感导致了微服务架构风格出现：将应用程序构建为服务套件。除了服务可独立部署和扩展之外，每个服务还提供了一个牢固的模块边界，甚至允许用不同的编程语言编写不同的服务。他们也可以由不同的团队管理。我并不认为微服务风格是新颖的或创新的，它的根源至少可以追溯到Unix的设计原则。但目前我认为没有足够多的人考虑微服务架构，并且许多软件开发如果使用它们会更好。
微服务架构的特点
我们不能说微服务架构风格已经有了一个正式的定义，但我可以试图描述我们认为符合标准的架构的共同特征。与其他常见特性的任何定义一样，并非所有微服务架构都具有所有特性，但我们确实期望大多数微服务架构具有大多数特性。我们的目的是试图描述在自己的工作中所看到的以及所了解的团队的类似努力。特别是我们并没有制定一些符合的定义。
通过服务进行组件化
自从我们进入软件行业以来，就一直希望通过将组件整合在一起来构建系统，这与我们在现实世界中看到事物的方式非常相似。在谈论组件时，遇到了构成组件的困难定义。我们的定义是， 组件是可独立更换和升级的软件单元。微服务体系结构也使用类似库包装的概念，但是它们组装自己软件的主要方式是分解为服务。我们将库定义为链接到程序中的组件，并使用内存中的函数调用进行调用，而服务是与Web服务请求或远程过程调用等机制进行通信的进程外组件。（这与许多面向对象程序中服务对象的概念不同。使用服务作为组件（而不是库）的一个主要原因是服务可独立部署。如果您的应用程序由单个进程中的多个库组成，那么对任何单个组件的更改都会导致必须重新部署整个应用程序。但是，如果该应用程序分解为多个服务，则可以期望许多单一服务更改只需要重新部署该部分服务。但这不是绝对的，有些改变会改变服务接口，导致一些协调，但是一个好的微服务架构的目标是通过服务合约中的内聚服务边界和进化机制来最小化这些问题。使用服务作为组件的另一个后果是更明确的组件接口。大多数语言没有一个好的机制来定义一个明确的发布接口。通常只有文档和纪律能够防止客户端破坏组件的封装，导致组件之间过于紧密的耦合。通过使用显式远程调用机制，服务可以更容易地避免这种情况。使用这样的服务确实有缺点。远程调用比进程内调用更加昂贵，因此远程API需要更粗粒度，这通常更难以使用。如果您需要更改组件之间的责任分配，那么当您跨越流程边界时，这种行为的移动难以实现。在第一个近似值中，我们可以观察到服务映射到运行时进程，但这只是第一个近似值。服务可能由多个进程组成，这些进程将始终开发并部署在一起，例如应用程序进程和仅由该服务使用的数据库。
围绕业务能力进行组织
当想要将大型应用程序拆分为多个部分时，管理层往往侧重于技术层，导致UI团队，服务器端逻辑团队和数据库团队协同出现不少问题。当团队沿着这些路线分开时，即使是简单的变更也会导致跨团队项目需要时间和预算批准。一个聪明的团队将围绕这一点进行优化，并为两个弊端中的较小者提供丰富实践 - 只需将逻辑强制到他们可以访问的任何应用程序。换言之，就是无处不在的逻辑。这是康威法则一个例子。
任何设计系统（定义广泛）的组织都将产生一个设计，其结构是该组织通信结构的副本。
- 梅尔文康威，1967年
微服务团队成员组织的方法不同，分解成围绕业务能力进行组织的服务 。这些服务需要对该业务领域的软件进行广泛的实施，包括用户界面，持久性存储和任何外部协作。因此，团队是跨职能的，包括开发所需的全部技能：用户体验，数据库和项目管理。
是产品不是项目
我们看到的大多数应用程序开发工作都使用项目模型：目标是提供一些随后被认为已完成的软件。完成后，软件被移交给维护组织，并且构建它的项目团队被解散。微服务支持者倾向于避免这种模式，而更倾向于认为团队应该在其整个生命周期内拥有产品。对此的一个共同启发就是亚马逊的“你自己构建，运行它”的概念，即开发团队负责生产软件的全部责任。这使开发人员日常接触到他们的软件在生产中的行为，并增加与用户的联系，因为他们必须承担至少一些支持负担。产品的心态，与企业能力的关联。软件并不是一组待完成的功能，而是一个持续的关系，问题是软件如何帮助其用户提高业务能力。没有理由不能为单一应用程序采用同样的方法，但较小的服务粒度可以更容易地创建服务开发人员与其用户之间的个人关系。
智能端点和哑管道
在构建不同流程之间的沟通结构时，我们看到许多产品和方法都强调将重要的智慧融入沟通机制本身。一个很好的例子就是企业服务总线（ESB），ESB产品通常包含用于消息路由，编排，转换和应用业务规则的复杂设施。
成为网络，而不是网络后面
- 伊恩罗宾逊
微服务团队使用万维网（在很大程度上，Unix）构建的原则和协议。开发人员或操作人员可以通过很少的努力来缓存经常使用的资源。常用的第二种方法是通过轻量级消息总线进行消息传递。所选择的基础架构通常是愚蠢的（仅仅是作为一个消息路由器的行为） - 简单的实现，比如RabbitMQ或ZeroMQ，不仅仅是提供可靠的异步结构 - 智能仍然存在于正在生成和消费信息; 在服务中。在整体架构中，组件正在执行中，它们之间的通信通过方法调用或函数调用进行。将巨人变成微服务的最大问题在于改变沟通模式。从内存中方法调用到RPC的天真转换会导致性能不佳的健谈通信。相反，你需要用更粗糙的方法来替换细粒度的通信。
分散治理
集中治理的后果之一是在单一技术平台上实现标准化的趋势。经验表明，这种方法是狭隘的 - 并非每一个问题都是钉子，而不是每一个解决方案。我们更喜欢使用正确的工具来完成这项工作，而单片应用程序可以在一定程度上利用不同的语言，但这并不常见。将整体零件拆分成服务时，我们在构建每个服务时都有选择。你想使用Node.js来站立一个简单的报告页面？去吧。C ++用于特别粗糙的近实时组件？精细。你想交换一个不同的数据库风格，更适合一个组件的读取行为？我们有技术来重建他。当然，仅仅因为你可以做点什么，并不意味着你应该这样做- 但是用这种方式划分你的系统意味着你可以选择。构建微服务的团队也更喜欢采用不同的标准方法。他们更喜欢生产有用的工具，而其他开发人员可以用它来解决他们所面临的类似问题，而不是使用一套定义好的标准。这些工具通常从实施中收获，并与更广泛的群体共享，有时但不完全使用内部开源模型。
分散数据管理
数据管理的分权化以多种不同的方式呈现。在最抽象的层面上，这意味着世界的概念模型在不同系统之间会有所不同。在整个大型企业中进行整合时，这是一个常见问题，客户的销售视图将与支持视图不同。在销售视图中称为客户的某些内容在支持视图中可能完全不显示。那些确实可能具有不同的属性和（更糟糕的）具有微妙不同语义的共同属性。
以这种方式选择管理不一致对于许多开发团队来说是一个新的挑战，但它往往符合商业惯例。通常企业处理一定程度的不一致性，以便快速响应需求，同时采取某种逆转过程来处理错误。只要修正错误的成本低于失败业务的成本，这种折中是值得的。
基础设施自动
基础设施自动化技术在过去几年中发生了巨大变化 - 特别是云和AWS的发展降低了构建，部署和运行微服务的运营复杂性。由微服务构建的许多产品或系统都由具有持续交付丰富经验的团队构建，这是持续集成的先驱。这种构建软件的团队广泛使用基础设施自动化技术。由于这不是一篇关于持续交付的文章，我们将在这里提请注意几个关键功能。我们希望尽可能多的信心使我们的软件能够工作，所以我们进行了大量的自动化测试。推动工作软件“向上”流水线意味着我们可以自动部署 到每个新环境。
我们看到团队使用广泛的基础设施自动化的另一个领域是管理生产中的微服务。与我们之前的断言相反，只要部署无聊，整体架构和微服务之间没有太大差别，每个架构的运营环境可能会有惊人的不同。
设计失败
将服务用作组件的后果是应用程序需要进行设计，以便它们可以容忍服务的失败。任何服务电话都可能由于供应商不可用而失败，客户必须尽可能优雅地回应。与单片设计相比，这是一个缺点，因为它引入了额外的复杂性来处理它。结果是微服务团队不断反思服务失败如何影响用户体验。
进化设计
微服务从业者通常来自进化设计背景，并将服务分解视为进一步的工具，以使应用程序开发人员能够控制其应用程序中的更改，而不会降低更改速度。变更控制并不一定意味着降低变更 - 通过正确的态度和工具，您可以对软件进行频繁，快速且控制良好的变更。无论您何时试图将软件系统分解为组件，您都面临着如何分割这些组件的决定 - 我们决定切割应用程序的原则是什么？组件的关键属性是独立替换和可升级性的概念 - 这意味着我们寻找可以想象重写组件而不影响其协作者的点。事实上许多微服务集团都明确预计许多服务将被废弃，而不是长远发展。使用单体应用时，任何更改都需要完整构建和部署整个应用程序。但是，对于微服务，您只需重新部署您修改的服务。这可以简化并加速发布过程。缺点是你不得不担心改变一个服务打破它的消费者。传统的集成方法是尝试使用版本控制来解决这个问题，但微服务领域的偏好是仅使用版本控制作为最后的手段。我们可以通过设计服务尽可能容忍供应商的变化来避免大量的版本控制。