微服务例举（续）

什么是微服务？

微服务架构的基础是将单个应用程序开发为一套小型独立服务，这些服务在本身的流程中运行，独立开发和部署。

如图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网关的角色如何变化。还讨论了微服务架构的关键特性及其优缺点，这将是理解其他部分的基础。