实用微服务

实用微服务

如今，微服务是软件体系结构领域中最受欢迎的热门词汇之一。有许多材料都在介绍微服务的基本原理以及它的好处，但教你如何在企业场景中使用微服务的资料就十分少了。

在这篇文章中，我打算介绍微服务架构（MSA）的关键架构概念以及如何在实践中使用这些架构原则。

单体架构

企业软件应用程序旨在实现众多业务需求。因此，一个给定的软件应用程序提供了数百个功能，所有这些功能都堆积在一个单一的应用程序中。例如，ERP，CRM和其他各种软件系统都构建为具有数百个功能的庞然大物。这种庞大软件应用程序的部署，故障排除，扩展和升级都将会是一场噩梦。

面向服务的体系结构（SOA）旨在通过引入“服务是聚集体”的概念，以及从同一应用程序中提取出相似的功能来克服上述的问题。因此，在SOA中，软件应用程序被设计为“粗粒度”服务的组合。然而，在SOA中，服务的范围非常泛，这导致了服务过于复杂和庞大，通常可能会有几十个功能并且还有复杂的消息格式和标准（e.g. WS*标准）。

图一：单体架构

在大多数情况下，SOA中的服务是相互独立的，但它们与其他服务同时部署（例如将几个Web应用程序同时部署在一个Tomcat实例上）。与整体软件应用类似，这些服务随着功能的不断累加而不断增大。显然，这会导致这些应用程序变得像ERPs之类的单体架构一样庞大。图1显示了一个包含多种服务的零售软件应用程序。所有这些服务都部署到同一个应用程序运行环境。所以它是单体架构的一个很好的例子。以下是基于单体架构的应用程序的一些特性。

• 单体应用程序是作为一个单元来进行设计，开发和部署的。
• 单体应用程序非常复杂; 这导致了维护，升级和增加新功能变得很困难。
• 难以用单体架构去实现敏捷开发和交付方法。
• 在单体架构中，更新某一部分内容时需要重新部署整个应用程序。
• 扩展：必须扩展为单个应用程序，并且难以按照资源需求冲突进行扩展（例如：一项服务需要更多的CPU，而另一项需要更多的内存）
• 可靠性 - 一项不稳定的服务可能会关闭整个应用程序
• 很难创新：由于所有功能必须建立在同类技术/框架上，所以采用新技术和框架很困难。

单体架构的这些特性导致了微服务架构的产生。

微服务架构

微服务体系结构（MSA）的最初目标是发展一个有着一套小型且独立服务的单体应用软件。这些服务在自己的过程中运行，并独立开发和部署。

在微服务体系结构的大多数定义中，都认为它是将一个在大规模架构中可用的服务分离成一套独立服务的过程。但是，在我看来，微服务不仅仅是这样。

关键点是，通过观察单体架构所提供的功能，我们可以确定所需的业务功能。然后，这些业务功能可以作为完全独立的，有细粒度和自包含（微观）的服务来实施。它们可能会在不同的技术堆栈上实施，而每项服务都是针对一个非常具体且有限的业务范围。

因此如图2所示，我们上面解释的在线零售系统场景可以通过微服务架构实现。通过微服务架构，零售软件应用程序被实现为一套微服务。正如您在图2中看到的那样，根据业务需求，从最初的一组整体服务中又创建了一个额外的微服务。所以，显而易见的是，使用微服务架构是超越整体服务分裂的东西。

图2：微服务架构

因此，让我们深入了解微服务的关键架构原则，并专注于如何在实践中使用它们。

设计微服务：大小，范围和功能

您可能通过使用微服务架构从头开始构建软件应用程序，或者将现有应用程序/服务转换为微服务。无论哪种方式，正确决定微服务的规模，范围和功能是非常重要的。刚开始在实践中实施微服务架构时，这可能是最困难的事情了。

我们来讨论一些与微服务的规模，范围和功能有关的实际关注点和误解。

• 代码行数/团队规模是糟糕的指标：有一些划分微服务规模的讨论是根据其实施代码或其团队规模（即双比萨团队）来决定的。然而，这些被认为是非常不切实际和糟糕的指标，因为我们仍然可以用更少的代码/双比萨团队来开发完全违反了微服务架构原则的服务。
• '微'这个词有点误导：大多数开发者倾向于认为他们应该尝试尽可能小的服务。这是一个错误的解释。
• 在SOA环境中，服务通常以单块形式实现，并支持几十种操作/功能。因此，拥有类似SOA的服务并将它们重新命名为微服务并不会给您提供任何微服务架构的好处。

那么，我们应该如何正确设计微服务架构中的服务？

设计微服务指南

• 单一责任原则（Single Responsibility Principle，简称SRP）：微服务的业务范围有限且重点突出，有助于我们满足服务开发和交付的敏捷性。
• 在微服务的设计阶段，我们应该找到它们的边界并将它们与业务功能（在域驱动设计中称为有界上下文）进行对比。
• 确保微服务设计满足服务的敏捷性/独立开发和部署。
• 我们的重点应放在微服务的范围上，而不是关于如何缩小服务范围。服务的（正确）大小应该能恰好满足给定的业务能力。
• 与SOA中的服务不同，给定的微服务应该具有非常少的操作/功能和简单的消息格式。
• 从较广泛的服务边界开始，随着时间的推移重新构建较小的服务边界（基于业务需求）通常是一种好的做法。

在我们的零售用例中，您可以发现我们已将其巨大功能分为四种不同的微服务，即“库存”，“会计”，“运输”和“商店”。它们各自解决了一个有限但专一的业务范围，以便每个服务都完全相互分离，并确保了开发和部署的敏捷性。

微服务中的消息

在单体应用程序中，不同处理器/组件的业务功能通过函数或语言级方法来调用。在SOA中，这转向了更加松散耦合的Web服务级别消息传递，它主要基于不同协议（如HTTP，JMS）上的SOAP。Web服务有着几十次的操作和复杂的消息模式，这是它普及的关键阻力。对于微服务体系结构，它需要有一个简单的轻量级的消息机制。

同步消息传递 - REST，Thrift

对于微服务架构中的同步消息传递（客户端期望得到服务的及时响应并会一直等待响应），REST是一致的选择，因为它提供了基于资源API风格的使用HTTP请求响应实现的简单消息传递风格。因此，大多数微服务都使用HTTP以及基于资源API的样式来实现（每个功能都由资源和在这些资源之上执行的操作来表示）。

图3：使用REST接口公开微服务

使用Thrift（您可以在其中为微服务定义接口定义），作为REST / HTTP同步消息的替代方案。

异步消息传递 - AMQP，STOMP，MQTT

对于某些微服务场景，需要使用异步消息传递技术（客户端不会立即响应，或者根本不接受响应）。在这种情况下，异步消息协议（如AMQP，STOMP或MQTT）被广泛使用。

消息格式 - JSON，XML，Thrift，ProtoBuf，Avro

决定微服务最适合的消息格式是另一个关键因素。传统的单体应用程序使用复杂的二进制格式，基于SOA / Web服务的应用程序使用基于复杂消息格式（SOAP）和模式（xsd）的文本消息。在大多数基于微服务的应用程序中，使用简单的基于文本的消息格式，如HTTP资源API风格之上的JSON和XML。在我们需要二进制消息格式（在某些使用情况下，文本消息可能变得冗长）的情况下，微服务可以利用二进制消息格式，例如二进制Thrift，ProtoBuf或Avro。

服务合同 - 定义服务接口 - Swagger，RAML，Thrift IDL

当您将业务功能实施为服务时，您需要定义和发布服务合同。在传统的单体应用程序中，我们几乎找不到这种功能来定义应用程序的业务功能。在SOA / Web服务世界中，使用WSDL来定义服务契约，但是我们都知道，WSDL并不是定义微服务合同的理想解决方案，因为WSDL非常复杂且与SOAP紧密结合。

由于我们在REST架构风格的基础上构建了微服务，因此我们可以使用相同的REST API定义技术来定义微服务的契约。因此，微服务使用标准REST API定义语言（如Swagger和RAML）来定义服务合约。

对于其他不基于HTTP / REST（如Thrift）的微服务实现，我们可以使用协议级别'接口定义语言（IDL）'（例如：Thrift IDL）。

集成微服务（服务/流程间通信）

在微服务体系结构中，软件应用程序是作为一套独立服务构建的。因此，为了实现业务用例，需要在不同的微服务/进程之间建立通信结构。这就是为什么微服务之间的服务/流程沟通是如此重要。

在SOA实现中，通过企业服务总线（ESB）促进服务之间的服务间通信，并且大多数业务逻辑驻留在中间层（消息路由，转换和编排）中。但是，微服务体系结构促进消除中央消息总线/ ESB，并将“智能”或业务逻辑转移到服务和客户端（称为“智能终端”）。

由于微服务使用标准协议（如HTTP，JSON等），因此在涉及微服务之间的通信时，与不同协议集成的要求很少。微服务通信中的另一种替代方法是使用具有最小路由功能的轻量级消息总线或网关，只是在网关上没有业务逻辑的情况下充当“哑管”。基于这些，微服务架构中出现了几种通信模式。

点对点模式 - 直接调用服务

在点对点模式中，整个消息路由逻辑驻留在每个端点上，并且这些服务可以直接进行通信。每个微服务都公开了一个REST API，并且给定的微服务或外部客户可以通过其REST API调用另一个微服务。

图4：使用点对点连接的服务间通信

很明显，这种模式适用于相对简单的基于微服务的应用程序，但随着服务数量的增加，这将变得非常复杂。在传统的SOA实现中使用ESB的原因与此完全相同，那就是消除这种混乱的点对点集成链接。我们试着总结一下微服务通信的点对点模式的主要缺点。

• 非功能性需求（如最终用户身份验证，节流，监控等）必须在每个微服务级别实施。
• 由于复制常用功能，每个微服务实现可能变得复杂。
• 在服务和客户端之间的通信中没有控制（即使是监视，跟踪或过滤）。
• 通常，在大规模微服务实现中使用直接通信是不合适的。

因此，对于复杂的微服务用例，我们通常使用能够为微服务提供抽象层的轻量级中心消息传递总线，而不使用点对点连接或中心ESB。同时它也可以用来实现多种多样的非功能性能力。这种模式被称为API网关模式。

API网关模式

API网关模式的关键思想是，使用轻量级消息网关作为所有客户端/消费者的主要入口点，并在网关级别实现常见的非功能性需求。通常，API网关允许您通过REST / HTTP使用托管API。因此，可以通过API-GW将我们用微服务实现的业务功能公开为一个托管API。实际上，这是微服务架构和API管理的结合，它可以为您提供两全其美的解决方案。

图5：所有微服务都通过API-GW公开

如图5所示，在我们的零售业务场景中，所有微服务都通过API-GW公开，并且对所有客户端来说这都只是一个简单的入口点。如果一个微服务想要使用另一个微服务，那也需要通过API-GW来完成。

API-GW模式有以下几个优势。

• 能够在网关级为现有的微服务提供所需的抽象。例如，API网关可以为每个客户端提供一个不同的API，而不是提供一种适用于所有类型的API。
• 网关级别的轻量级消息路由/转换。
• 聚焦于应用非功能性业务，如安全性，监控和节流。
• 通过使用API​​-GW模式，微服务变得更加轻量级，因为所有非功能性业务都是在网关级别实施的。

API-GW模式很可能是微服务实现中使用最广的模式。

信息管理模式

微服务可以集成到异步消息传递场景中，例如使用队列或主题的单向请求和发布 - 订阅消息传递。给定的微服务可以是消息生产者，它可以异步地将消息发送到队列或主题。然后，作为消息消费者的微服务可以使用来自队列或主题的消息。这种风格将消息生产者与消息消费者分离开来，中间消息代理将缓冲消息，直到消费者能够处理它们。生产者微服务完全不了解消费者微服务。

图6：使用pub-sub的基于异步消息传递的集成

消费者/生产者之间的通信通过基于异步消息传递标准的消息代理来实现，例如AMQP，MQTT等。

分散数据管理

在单体架构中，应用程序将数据存储在单个和集中式数据库中，以实现应用程序的各种功能。

图7：单体应用程序使用集中式数据库来实现其所有功能

在微服务体系结构中，功能分散在多个微服务中，如果我们使用同一个集中式数据库，那么微服务将不再彼此独立（例如，如果数据库模式已从给定的微服务中改变，那将会破坏其他几个服务）。因此，每个微服务都必须有自己的数据库。

图8：微服务拥有自己的私有数据库，他们不能直接访问其他微服务拥有的数据库。

以下是在微服务架构中实施分散数据管理的关键方面。

• 每个微服务可以拥有一个专用数据库来存储实现其提供的业务功能所需的数据。
• 给定的微服务只能访问专用私有数据库，而不能访问其他微服务的数据库。
• 在某些业务场景中，您可能必须更新多个数据库才能进行单个事务。在这种情况下，其他微服务的数据库应该只能通过其服务API进行更新（不允许直接访问数据库）

分散的数据管理为您提供完全分离的微服务和选择不同数据管理技术（SQL或NoSQL等，每种服务的不同数据库管理系统）的自由。但是，对于涉及多个微服务的复杂事务用例，事务性的行为必须使用每种服务提供的API来实现，逻辑位于客户端或中介（GW）级别。

分布式治理

微服务架构有利于分布式治理。

总的来说，“治理”意味着建立并实施人员和解决方案如何共同工作来实现组织目标的方法。在SOA的背景下，SOA治理指导可重用服务的开发，确定如何设计和开发服务以及这些服务将随着时间的推移如何变化。它建立了服务提供者和服务消费者之间的协议，告诉消费者他们可以期待什么以及提供者他们有义务提供什么。在SOA治理中，有两种常用的治理类型：

• 设计时治理 - 定义和控制服务创建，设计和实施服务策略
• 运行时治理 - 在运行期间执行服务策略的能力

那么，微服务环境中的治理真的意味着什么？在微服务体系结构中，微服务被构建为完全独立并且与各种技术和平台解耦的服务。因此，不需要为服务设计和开发定义通用标准。因此，我们可以总结下面的微服务的分散治理特点。

• 在微服务架构中，不需要集中设计时治理。
• 微服务可以自行决定其设计和实现。
• 微服务架构促进通用/可重用服务的共享。
• 某些运行时间管理方面（如SLA，节流，监视，通用安全要求和服务发现）可以在API-GW级别实施。

服务注册和服务发现

在微服务架构中，您需要处理的微服务数量非常高。由于微服务的快速和灵活的开发/部署特性，它们的位置也会动态变化。因此，您需要在运行时查找微服务的位置。解决这个问题的方法是使用服务注册表。

服务注册表

服务注册表包含微服务实例及其位置。微服务实例在启动时向服务注册表注册，并在关闭时取消注册。消费者服务可以通过服务注册中心找到可用的微服务及其位置。

服务发现

要找到可用的微服务及其位置，我们需要有一个服务发现机制。有两种类型的服务发现机制，即客户端发现和服务器端发现。让我们仔细看看这些服务发现机制。

客户端发现

在这种方法中，客户端或API-GW通过查询服务注册机来获取服务实例的位置。

图9 - 客户端发现

在这里，客户端/ API-GW必须通过调用服务注册表组件来实现服务发现逻辑。

服务器端发现

通过这种方法，客户端/ API-GW将请求发送到运行在通用位置上的组件（例如负载均衡器）。该组件调用服务注册表并确定微服务的绝对位置。

图10 - 服务器端发现

微服务部署解决方案（如Kubernetes）（http://kubernetes.io/v1.1/docs/user-guide/services.html）提供服务端发现机制。

部署

当涉及到微服务架构时，微服务的部署起着至关重要的作用，并具有以下关键要求。

• 能够独立于其他微服务部署/取消部署。
• 必须能够在每个微服务级别进行扩展（给定的服务可能会获得比其他服务更多的流量）。
• 快速构建和部署微服务。
• 一个微服务中的失败不得影响任何其他服务。

Docker（一种开放源代码引擎，可让开发人员和系统管理员在Linux环境中部署自给自足的应用程序容器）为部署满足上述要求的微服务提供了一种绝佳方式。所涉及的关键步骤如下。

• 将微服务封装为（Docker）容器映像。
• 将每个服务实例部署为一个容器。
• 缩放是根据更改容器实例的数量完成的。
• 构建，部署和启动微服务将会更快，因为我们使用的是docker容器（这比常规VM快得多）

Kubernetes通过将一个Linux容器集群作为单个系统进行管理，在多个主机上管理和运行Docker容器，提供容器的位置，服务发现和复制控制，扩展了Docker的功能。正如您所看到的，这些功能中的大部分对我们的微服务环境也是至关重要的。因此，使用Kubernetes（在Docker之上）进行微服务部署已经成为一种非常强大的方法，特别适用于大规模微服务部署。

图11：构建和部署微服务作为容器

在图11中，它展示了零售应用程序微服务部署的概述。每个微服务实例都被部署为一个容器，每个主机有两个容器。您可以任意更改在给定主机上运行的容器。

安全

在实践中使用微服务时，保护微服务是相当普遍的要求。在进入微服务安全之前，让我们快速浏览一下我们通常如何在单一应用程序级别实现安全性。

• 在一个典型的单一应用程序中，安全性是指发现“谁是呼叫者”，“呼叫者可以做什么”以及“我们如何传播这些信息”。
• 这通常在位于请求处理链开头的通用安全组件实现，该组件使用底层用户存储库（或用户存储）填充所需的信息。

那么，我们可以直接将这种模式转化为微服务架构吗？是的，但是这需要在每个微服务级别实施安全组件，该安全组件与中央/共享用户存储库交谈并检索所需的信息。这是解决微服务安全问题的一种非常乏味的方法。

相反，我们可以利用广泛使用的API-Security标准（如OAuth2和OpenID Connect）来找到解决微服务安全问题的更好解决方案。在深入研究之前，让我们总结每个标准的目的以及我们如何使用它们。

• OAuth2 - 是一种访问委派协议。客户端使用授权服务器进行身份验证，并获得一个被称为“访问令牌”的不透明令牌。访问令牌具有关于用户/客户端的零信息。它只提供只能由授权服务器检索的用户信息。因此这被称为“by-reference token”，即使在公共网络/互联网中使用该令牌也是安全的。
• OpenID Connect的行为与OAuth类似，但除了Access令牌之外，授权服务器还会发出包含有关用户信息的ID令牌。这通常由JWT（JSON Web令牌）实现，并由授权服务器签名。所以，这确保了授权服务器和客户端之间的信任。因此，JWT令牌被称为“按价值令牌”，因为它包含用户的信息，显然在内部网络之外使用它是不安全的。

现在，让我们看看我们如何使用这些标准来保护我们的零售示例中的微服务。

图12：使用OAuth2和OpenID 连接来保证微服务的安全性

如图12所示，这些是实施微服务安全所涉及的关键步骤。

• 将身份验证留给OAuth和OpenID Connect服务器（授权服务器），以便微服务成功提供访问权限，因为某人有权使用这些数据。
• 使用API​​-GW样式，其中有一个入口点用于所有客户端请求。
• 客户端连接到授权服务器并获取访问令牌（By-reference Token）。然后将访问令牌与请求一起发送到API-GW。
• 网关上的令牌转换--API-GW提取访问令牌并将其发送到授权服务器以检索JWT（通过值令牌）。
• 然后，GW将此JWT与请求一起传递给微服务层。
• JWT包含帮助存储用户会话等必要信息。如果每个服务都可以理解JSON Web令牌，那么您已经分发了您的身份机制，该机制允许您在整个系统中传输身份。
• 在每个微服务层，我们可以有一个处理JWT的组件，这是一个相当简单的实现。

交易

微服务中的交易支持如何？事实上，支持跨多个微服务的分布式事务是一项特别复杂的任务。微服务架构本身鼓励服务之间的无事务协调。

这个想法是，一个给定的服务是完全独立的，并基于单一责任原则。跨多个微服务分布式事务的需求通常是微服务体系结构中设计缺陷的一个症状，通常可以通过重构微服务的范围来解决。

但是，如果强制要求在多个服务之间进行分布式事务，那么可以通过在每个微服务级别引入“补偿操作”来实现这种情况。关键的想法是，给定的微服务基于单一职责原则，如果给定的微服务未能执行给定的操作，我们可以认为这是整个微服务的失败。然后，所有其他（上游）操作都必须通过调用这些微服务的相应补偿操作来撤消。

设计失败

微服务体系结构引入了一系列分散的服务，并与单一设计相比，这增加了在每个服务级别出现故障的可能性。由于网络问题，基础资源不可用等原因，给定的微服务可能会失败。不可用或无响应的微服务不应该使整个基于微服务的应用程序失效。因此，微服务应该具有容错能力，能够在可能的情况下进行恢复，并且客户端必须优雅地处理它。

另外，由于服务可能随时发生故障，因此能够快速检测（实时监控）故障并在可能的情况下自动恢复服务很重要。在微服务上下文中处理错误时有几种常用的模式。

断路器

当您正在对微服务进行外部调用时，可以在每次调用时配置一个故障监视器组件，当故障达到某个阈值时，该组件将停止对该服务的任何进一步调用（跳闸电路）。在打开状态（您可以配置）发出一定数量的请求后，将电路切换回关闭状态。

这种模式对于避免不必要的资源消耗，由于超时导致的请求延迟以及给我们机会来监视系统（基于活动的开路状态）非常有用。

隔离

由于微服务应用程序包含许多微服务，因此基于微服务的应用程序的一部分的故障不应该影响应用程序的其余部分。隔离模式是关于隔离应用程序的不同部分，以便应用程序的此部分中的服务失败不会影响任何其他服务。

超时

超时模式是一种机制，当您认为它不会到来时，您可以停止等待来自微服务的响应。在这里您可以配置您希望等待的时间间隔。

那么，我们在哪里以及如何在微服务中使用这些模式？在大多数情况下，这些模式中的大多数适用于网关级别。这意味着当微服务不可用或没有响应时，在网关级别，我们可以决定是否使用断路器或超时模式将请求发送到微服务。此外，在网关级别实现的诸如bulkhead之类的模式作为所有客户端请求的单一入口点是非常重要的，因此提供服务中的失败不应影响其他微服务的调用。

此外，Gateway可以作为每个微服务通过Gateway调用时获得每个微服务的状态和监控的中心点。

微服务，企业集成，API管理等等。

我们已经讨论了微服务架构的各种特性以及如何在现代企业IT环境中实现它们。但是，我们应该记住，微服务不是万能的。流行词概念的盲目修改并不能解决您“真正”的企业IT问题。正如你在整篇博客文章中看到的那样，微服务有很多优点，我们应该利用它们。但是我们也必须记住，用微技术解决所有企业IT问题是不现实的。例如，微服务体系结构促进消除作为中央总线的ESB，但是当涉及到真实世界的IT时，现有的相当多的应用程序/服务不是基于微服务。所以，为了与他们整合，我们需要某种集成总线。所以，理想情况下，微服务和其他企业架构概念（如集成）的混合方法将更加现实。我将在另一篇博文中进一步讨论它们。

希望这可以让你更清楚地了解如何在企业中使用微服务。

参考

http://martinfowler.com/articles/microservices.html http://techblog.netflix.com/2011/12/making-netflix-api-more-resilient.html http://www.infoq.com/articles/ seven-uservices-antipatterns https://pragprog.com/book/mnee/release-it