什么是微服务？
微服务架构的基础是将单个应用程序开发为一套小型独立服务，这些服务在自己的流程中运行，独立开发和部署。
如图1-4所示，通过将单片应用层分解为独立的面向业务功能的服务，可以将在线零售软件应用程序转换为微服务架构。 此外，我们通过将其功能分解为每个服务来摆脱中央ESB，以便服务处理服务间通信和组合逻辑。
图1-4使用微服务架构构建的在线零售应用程序
因此，微服务层的每个微服务都提供了明确定义的业务能力（最好是小范围），它们是独立设计，开发，部署和管理的。
尽管与其通信的ESB和服务层发生了变化，但API管理层几乎保持不变。 API网关和管理层将业务功能公开为托管API;我们可以选择将网关隔离到独立的基于每个API的运行时。
深入了解微服务的主要特征。
以业务能力为导向
微服务体系结构的一个关键概念是，服务必须基于业务功能进行设计，以便给定的服务能够满足特定的业务目的，并具有明确定义的职责。给定的服务应该专注于只做一件事并做得好。
重要的是要理解粗粒度服务（例如在SOA上下文中开发的Web服务）或细粒度服务（不映射到业务能力）不适合微服务架构。相反，服务的大小应该完全基于范围和业务功能。此外，请记住，使服务太小（即，针对映射到业务功能的细粒度功能）将被视为反模式。
示例场景中，在SOA / Web服务实现中使用了粗粒度服务，例如Product，Order等（参见图1-3），当我们进入微服务时，我们确定了一组更细粒度的服务，面向业务能力的服务，例如产品详细信息，订单处理，产品搜索，购物车等。
服务的大小永远不会根据代码行数或处理该服务的人数来确定。诸如单一责任原则（SRP），康威定律，十二因子应用程序，域驱动设计（DDD）等概念在识别和设计微服务的范围和功能方面非常有用。将在“设计微服务”中讨论围绕业务功能设计微服务的关键概念和基础知识。
自治：独立开发，部署和扩展
拥有自治服务可能是实现微服务架构背后最重要的驱动力。微服务作为独立实体被开发，部署和扩展。与Web服务或单一应用程序体系结构不同，服务不共享相同的执行运行时。相反，它们通过利用容器等技术部署为独立的运行时。容器和容器管理技术（如Docker，Kubernetes和Mesos）的成功和不断增加的适应性对于实现服务自治至关重要，并有助于微服务架构的整体成功。将在“部署和运行微服务”中深入研究微服务的部署方面。
自治服务可确保整个系统的弹性，因为已将故障与服务隔离开来。这些服务通过网络上的服务间通信和通过消息传递松散耦合。可以在各种交互方式和消息格式之上构建服务间通信（将“服务间通信”中详细介绍）。通过与技术无关的服务合同公开的API，消费者可以使用这些合同与该服务协作。此类服务也可以通过API网关公开为托管API。
服务的独立部署提供了独立扩展服务的先天能力。随着业务功能的消耗不同，我们可以扩展获得更多流量的微服务，而无需扩展其他服务。
我们可以在电子商务应用程序用例中观察这些微服务的特性，如图1-3所示。粗粒度服务（如Product，Order等）与SOA / Web Services方法共享相同的应用程序服务器运行时。因此，其中一个服务中的故障（例如内存不足或CPU旋转）可能会破坏整个应用程序服务器运行时。而且，在许多情况下，与其他功能相比，可以非常频繁地使用诸如产品搜索之类的功能。使用单一方法，无法扩展产品搜索功能，因为它与其他服务共享相同的应用程序服务器运行时（您必须共享整个应用程序服务器运行时）。如图1-4所示，将这些粗粒度服务隔离到微服务中使它们可以独立部署，将故障隔离到每个服务级别，并允许根据消耗的方式独立扩展给定的微服务。
没有中央ESB：聪明的终点以及DumbB管道
微服务架构促进了企业服务总线（ESB）的消除。 ESB曾经是大多数智能设备在基于SOA / Web服务的架构中所处的位置。微服务架构引入了一种新的服务集成方式，称为智能端点和哑管，而不是使用ESB。如本章前面所述，大多数业务功能都是通过底层服务和系统的集成或管理在ESB级别实现的。使用智能端点和哑管，所有业务逻辑（包括服务间通信逻辑）都驻留在每个微服务级别（它们是智能端点），所有这些服务都连接到原始消息系统（哑管） ，没有任何业务逻辑。
大多数天真的微服务采用者认为，通过将系统转换为微服务架构，他们可以简单地摆脱集中式ESB架构的所有复杂性。然而，现实情况是，通过微服务架构，ESB的集中功能分散到所有微服务中。现在，ESB提供的功能必须在微服务级别实现。
因为，关键是ESB的复杂性不会消失。相反，它会分布在您发的所有微服务中。微服务组合（使用同步或异步样式），通过不同通信协议的服务间通信，诸如断路器的弹性模式的应用，与其他应用程序的集成，SaaS（例如，Salesforce），API，数据和专有系统以及可观察的集成服务，都可作为开发的微服务的一部分来实现。事实上，由于在微服务架构中必须处理的服务数量，创建组合和服务间通信的复杂性可能更具挑战性（由于网络上的服务间通信，服务更容易出错） ）。
大多数早期的微服务采用者（如Netflix）只是从头开始实现了大部分功能。但是，如果我们要用微服务架构完全取代ESB，必须选择特定的技术，在微服务级别构建这些ESB的功能，而不是从头开始重新实现它们。
下面将详细研究和并讨论一些必要的问题
将详细介绍所有要求，并在“服务间通信”和“集成微服务”中讨论实现它们的可用技术。
失败和容错
由于服务及其服务间网络通信的激增，微服务更容易出现故障。给定的微服务应用程序是细粒度服务的集合，因此一个或多个服务的失败不应该导致整个应用程序崩溃。因此，我们应该优雅地处理微服务的特定故障，以便对应用程序的业务功能的影响最小。以容错的方式设计微服务，需要从设计，开发和部署阶段调整所需的技术。
例如，在零售示例中，假设产品详细信息微服务对电子商务应用程序的功能至关重要。因此，我们需要应用所有与弹性相关的功能，例断路器，灾难恢复，负载平衡，故障转移和基于流量模式的动态扩展，会在“集成微服务”中详细讨论。
使用Netflix的Chaos Monkey等工具模仿所有这些可能的故障作为服务开发和测试的一部分非常重要。给定的服务实施还应负责所有与弹性相关的活动;这些行为会自动验证为CICD（持续集成，持续交付）流程的一部分。
容错的另一个方面是能够观察在生产中运行的微服务的行为。检测或预测服务中的故障并恢复此类服务非常重要。例如，假设您在在线零售应用程序示例中为所有微服务启用了监视，跟踪，日志记录等。然后，您会在产品搜索服务中观察到显着的延迟和低TPS（每秒事务数）。这表明该服务可能在将来中断。如果微服务是可观察的，应该能够分析当前症状的原因。因此，即使在开发阶段使用了混沌测试，为所有微服务提供可靠的可观察性基础设施以实现容错也很重要。我们将在“可观察性”中详细讨论可观察性技术。
将会详细介绍“集成微服务”以及“部署和运行微服务”中的容错技术和最佳实践。
分散式数据管理
在单一体系结构中，应用程序将数据存储在单个和集中式逻辑数据库中，以实现应用程序的各种功能和任务。在微服务架构中，功能分散在多个微服务中。如果我们使用相同的集中式数据库，那么微服务将不再彼此独立（例如，如果数据库模式由一个微服务更改，那么将破坏其他几个服务）。因此，每个微服务必须具有自己的数据库和数据库模式。
每个微服务都可以有一个私有数据库来保存需要实现其提供的业务功能的数据。给定的微服务只能访问专用的私有数据库，而不能访问其他微服务的数据库。
在某些业务场景中，可能必须为单个事务更新多个数据库。在这种情况下，其他微服务的数据库应能只通过相应的服务API进行更新（不允许它们直接访问数据库）。分散式数据管理为您提供完全分离的微服务，并可自由选择不同的数据管理技术（SQL或NoSQL等，为每项服务提供不同的数据库管理系统）。我们将在“数据管理”中详细介绍微服务架构的数据管理技术。
服务治理
SOA治理是SOA运营成功背后的关键驱动力之一; 它提供组织中不同实体（开发团队，服务消费者等）之间的合作与协调。 虽然它定义了一套全面的理论概念作为SOA治理的一部分，但在实践中只有少数几个概念被积极使用。当转向微服务架构时，大多数有用的治理概念都被丢弃，微服务中的治理被解释为一个分散的过程，它允许每个团队/实体管理自己的域，因为它更喜欢。 分散治理适用于服务开发，部署和执行过程，但除此之外还有很多其他内容。 因此，故意不使用分散治理这一术语。
可以确定治理的两个关键方面：服务的设计时治理（选择技术，协议等）和运行时治理（服务定义，服务注册和发现，服务版本控制，服务运行时依赖性，服务所有权和使用者，实施QoS和服务可观察性）。
微服务中的设计时治理主要是一个分散的过程，每个服务所有者都可以自由地设计，开发和运行他们的服务。然后，他们可以使用正确的工具来完成工作，而不是在单一技术平台上进行标准化。但是，应该定义一些适用于整个组织的通用标准（例如，无论开发语言如何，所有代码都应通过审核流程并自动合并到主线中）。
微服务的运行时治理方面是在各个层面实现的，通常不会在微服务上下文中将其称为运行时治理（服务注册表和发现是一种在微服务架构中非常有用的流行概念）。因此，如果我们看一下运行时治理的观点，而不是将这些概念作为一组离散概念来学习，就更容易理解它们。
运行时治理在微服务架构中绝对至关重要（它比SOA运行时治理更重要），仅仅因为必须处理的微服务数量。运行时治理的实现通常作为集中组件完成。例如，假设需要在在线零售应用场景中发现服务端点和元数据。然后，所有服务都必须调用集中式注册服务（它可以具有自己的扩展功能，但是逻辑上集中的组件）。同样，如果我们想要通过集中限制来应用QoS（服务质量）强制执行（例如安全性），我们需要一个中心位置，例如API Manager / gateway来实现这一点。实际上，一些运行时治理方面也在API网关层实现。
将在“微服务治理”和“API，事件和流”中的API管理中详细介绍微服务治理方面。
可观测
服务可观察性可以被视为监视，分布式日志记录，分布式跟踪以及服务的运行时行为和依赖性和可视化的组合。因此，可观察性也可以被视为运行时治理的一部分。随着细粒度服务的激增，观察服务的运行时行为的能力绝对至关重要。可观察性组件通常是微服务实现中的集中组件，并且每个服务将数据推送到那些组件中（而不是可观察性运行时从服务中提取数据）。可观察性对于识别和调试潜在问题非常有用，而服务正在生产中，也可用于业务功能目的（如货币化）。将在“可观察性”中讨论构建可观察服务的各种工具和技术。
微服务：福利和责任
与任何架构或技术一样，微服务架构也有好处和责任。由于对关键的微服务特性有很好的理解，因此现在是讨论它们的好时机。让我们从微服务的好处开始。
优点
微服务架构普及的主要原因之一是它提供优于传统软件架构模式的好处。让我们仔细看看微服务架构的主要优点。
微服务架构有利于自主服务开发，这有助于灵活快速地开发业务功能。在传统架构中，将业务功能转换为生产就绪软件应用程序功能需要很多周期，主要是由于系统的大小，代码库和依赖性。通过自主服务开发，只需要关注服务的接口和功能（而不是整个系统的功能，这要复杂得多），因为所有其他服务只能通过服务接口通过网络调用进行通信。
由于其自主性，微服务也是可替换的。由于我们将服务构建为一个独立的实体，通过网络调用和定义的API进行通信，因此可以轻松地将该功能替换为另一个更好的实现。专注于特定功能，具有限的范围和大小，并将其部署在独立的运行时中，所有这些都使构建可替换服务变得更加容易。
可替换性还有助于实现故障隔离和预测。如上所述，由于任何给定组件或服务的失败，基于微服务的应用程序不会像传统的单片应用程序那样爆炸。具有适当的可观察性功能还有助于识别或预测潜在的故障。
易于部署和扩展是微服务最重要的价值。借助现代基于云的容器本机基础架构，轻松部署服务并动态扩展服务的能力变得微不足道。由于正在构建自治服务功能，因此可以轻松利用所有此类容器和原生云技术来促进敏捷部署和可伸缩性。
由于微服务是面向业务能力的，因此它们可以与组织/团队结构保持一致。通常，给定组织的结构可以提供业务功能。因此，可以轻松地将每项服务的所有权提供给拥有业务功能的团队。因此，鉴于微服务专注于特定的业务功能，可以选择一个相对较小的团队来拥有该微服务。这对开发团队产生了积极影响，因为给定服务的范围简单且定义明确。这样，团队就可以完全拥有服务的整个生命周期。
责任
微服务架构的大部分责任主要是需要应对服务激增。
服务间通信复杂性可能比实际服务的实施更具挑战性。如前所述，智能端点和哑管概念迫使将服务间通信逻辑作为微服务的一部分。服务开发人员必须花费大量时间在管道上的微服务，以创建复合业务的功能。
通过网络传递许多服务也使服务的治理与可观察性方面变得复杂。如果没有适当的治理和可观察性工具，那么识别服务依赖性和检测故障将是一场噩梦。例如，使用微服务架构，服务生命周期管理，测试，发现，监控，服务质量以及各种其他服务治理功能将变得更加复杂。
严重依赖于部署方法
部署和扩展微服务的成功在很大程度上取决于容器和容器编排系统的采用。如果你没有这样的基础设施，将需要投入时间和精力（甚至不考虑拥有一个没有容器而成功的微服务架构）。最终，成功的微服务架构也取决于团队和人员。服务的所有权，考虑使服务轻量级和容器本地化，没有集中服务等的中心点，需要组织级工程文化的变化。
分布式数据的复杂性与事务管理
由于微服务架构促进了将数据本地化到给定服务，因此分布式数据管理将非常艰巨。这同样适用于分布式事务。实现跨多个微服务的事务边界将非常具有挑战性。
如何以及何时使用微服务
微服务架构如何从传统的集中式企业架构演变而来，涵盖了它的关键特性，并讨论了使用它的优缺点。但是，需要有一套可靠的指南来确定何时使用微服务架构以及什么时候避免使用微服务架构。
当企业架构需要模块化时，微服务架构是理想的选择。
当尝试使用软件应用程序解决业务问题非常简单，也可能根本不需要微服务（具有简单的单片Web应用程序和数据库通常就足够了）。
软件应用程序必须采用基于容器的部署。
如果系统太复杂而无法分离到微服务中，那么应该确定可以以最小的影响引入微服务的区域。然后，开始在微服务上实现一个小用例，并围绕它构建所需的生态系统组件。
了解业务功能对于设计微服务至关重要。在服务实现之前，了解微服务设计技术（如“设计微服务”中所述）是必不可少的。
对于每个特定的微服务域（例如数据管理，服务间通信，安全性等），将在后面的章节中详细讨论最佳实践和反模式。
摘要
本章的主要目标是概述企业体系结构的当前状态以及微服务如何适应它。在节中，讨论了企业架构如何从单片应用程序演变为微服务。讨论了当进入微服务时，ESB和API网关的角色如何变化。还讨论了微服务架构的关键特性及其优缺点，这将是理解其余部分的基础。