微服务(Microservices)概述

我高考零分!

已于 2022-05-10 10:18:57 修改

阅读量936

点赞数 5

分类专栏： SpringCloud 文章标签：微服务 java 后端

于 2022-05-10 10:04:56 首次发布

本文链接：https://blog.csdn.net/Amber_1/article/details/124681017

版权

SpringCloud 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

一、概览

微服务架构由一组小型自治服务组成。每个服务都是自包含的，应该在有限的上下文中实现单一的业务能力。有界上下文是业务内的自然划分，并提供了一个明确的边界，域模型存在于其中。
在这里插入图片描述

二、什么是微服务？

微服务体积小、独立且松耦合。一个小型开发团队可以编写和维护服务。
每个服务都是一个单独的代码库，可以由一个小型开发团队管理。
服务可以独立部署。团队无需重建和重新部署整个应用程序即可更新现有服务。
服务负责保存自己的数据或外部状态。这与传统模型不同，在传统模型中，单独的数据层处理数据持久性。
服务通过使用定义良好的 API 相互通信。每个服务的内部实现细节对其他服务是隐藏的。
支持多语言编程。例如，服务不需要共享相同的技术堆栈、库或框架。

除了服务本身，典型的微服务架构中还出现了一些其他组件：

管理/编排。该组件负责在节点上放置服务、识别故障、跨节点重新平衡服务等等。通常，这个组件是一种现成的技术，例如 Kubernetes，而不是定制的东西。

API 网关。API 网关是客户端的入口点。客户端不是直接调用服务，而是调用 API 网关，后者将调用转发到后端的适当服务。

使用 API 网关的优势包括：

它将客户端与服务分离。无需更新所有客户端即可对服务进行版本控制或重构。
服务可以使用对 Web 不友好的消息传递协议，例如 AMQP。
API 网关可以执行其他横切功能，例如身份验证、日志记录、SSL 终止和负载平衡。
开箱即用的策略，例如用于限制、缓存、转换或验证的策略。

三、与单体架构对比

微服务架构	单体架构
有一个焦点。它只做一件事并且做得很好。微服务针对特定的问题域，并包含管理该体验所需的一切（包括数据）。微服务中的“微”是关于范围，而不是大小。	具有广泛的焦点。紧密集成的软件包试图一次解决许多业务挑战，创建许多代码依赖项。
是松耦合的。微服务开发要求服务尽可能自给自足，并避免对其他服务的硬编码引用。	是紧耦合的。单体通常是相互依赖的组件的错综复杂的网络，如果没有精心设计的步骤序列，就无法部署。
连续交付。微服务非常适合拥有具有不断发展的功能集的应用程序的团队。为了尽快向市场交付价值，微服务通过自动化定期交付到生产中。	依赖于预定的交付。开发应用程序并按计划交付更新，通常每季度或每年一次。
拥有拥有服务生命周期的独立团队。微服务转型既关乎技术，也关乎团队结构。微服务由独立的团队构建、交付和运行。不是每个服务都需要这种处理，但它是关键业务服务的强大模型。	拥有许多拥有服务生命周期的团队。项目团队负责构建软件的第一次迭代，然后分开进行下一个任务。软件移交给运营团队进行维护。
具有强调大规模分布式系统的设计模式和技术。微服务架构依赖于一组服务发现、消息传递、网络路由、故障检测、日志记录、存储、身份等功能。团队无法使用与单体软件相同的方法和工具来构建和运行微服务。	有设计模式和技术，把过程放在首位。孤立的工具和流程，专注于关键的开发阶段、质量保证和发布到生产生

3.1.优势

敏捷。 由于微服务是独立部署的，因此更容易管理错误修复和功能发布。您可以在不重新部署整个应用程序的情况下更新服务，并在出现问题时回滚更新。在很多传统的应用程序中，如果在应用程序的某个部分发现了一个bug，就会阻塞整个发布过程。新功能可能会等待集成、测试和发布的错误修复。
小而专注的团队。微服务应该足够小，以至于单个功能团队可以构建、测试和部署它。小团队规模促进更大的敏捷性。大型团队往往效率较低，因为沟通速度较慢，管理开销增加，敏捷性降低。
小代码库。在单体应用程序中，随着时间的推移，代码依赖项会变得复杂。添加新功能需要在很多地方接触代码。通过不共享代码或数据存储，微服务架构可以最大程度地减少依赖关系，从而更容易添加新功能。
混合技术。团队可以选择最适合其服务的技术，并酌情使用技术堆栈组合。
故障隔离。如果单个微服务不可用，它不会中断整个应用程序，只要任何上游微服务都设计为正确处理故障（例如，通过实现断路）。
可扩展性。服务可以独立扩展，让您可以扩展需要更多资源的子系统，而无需扩展整个应用程序。使用 Kubernetes 或 Service Fabric 等编排器，您可以将更高密度的服务打包到单个主机上，从而更有效地利用资源。
数据隔离。执行模式更新要容易得多，因为只有一个微服务受到影响。在单体应用程序中，模式更新可能变得非常具有挑战性，因为应用程序的不同部分可能都涉及相同的数据，从而使对模式的任何更改都存在风险。

3.2.劣势

微服务的好处不是免费的。以下是在着手构建微服务架构之前需要考虑的一些挑战。

复杂性。微服务应用程序比同等的单体应用程序具有更多的移动部分。每个服务都更简单，但整个系统作为一个整体更复杂。
开发和测试。编写依赖于其他依赖服务的小型服务与编写传统的单体或分层应用程序需要不同的方法。现有工具并不总是设计用于处理服务依赖项。跨服务边界重构可能很困难。测试服务依赖项也具有挑战性，尤其是在应用程序快速发展的情况下。
缺乏治理。构建微服务的去中心化方法具有优势，但也可能导致问题。您最终可能会使用如此多不同的语言和框架，从而使应用程序变得难以维护。在不过度限制团队灵活性的情况下，制定一些项目范围的标准可能很有用。这尤其适用于横切功能，例如日志记录。
网络拥塞和延迟。使用许多小的、细粒度的服务可以导致更多的服务间通信。此外，如果服务依赖链变得太长（服务 A 调用 B，后者调用 C…），额外的延迟可能会成为问题。您需要仔细设计 API。避免过于冗长的 API，考虑序列化格式，并寻找使用异步通信模式的地方，例如基于队列的负载均衡。
数据完整性。每个微服务负责自己的数据持久性。因此，数据一致性可能是一个挑战。尽可能接受最终的一致性。
管理。要在微服务方面取得成功，需要成熟的 DevOps 文化。跨服务的相关日志记录可能具有挑战性。通常，日志记录必须关联单个用户操作的多个服务调用。
版本控制。对服务的更新不得破坏依赖它的服务。多个服务可以在任何给定时间更新，因此如果没有仔细设计，您可能会遇到向后或向前兼容性的问题。
技术储备。微服务是高度分布式的系统。仔细评估团队是否具备成功的技能和经验。

四、与SOA架构区别

面向服务的架构 (SOA) 一词最早出现在 1990 年代，用于描述一种为整个企业组件化应用程序服务的方法。微服务和 SOA 共享将单体应用程序分解为更小的服务的原则，但存在显着差异。

SOA 通常具有企业范围——单个服务可能被许多单独的应用程序使用，这些应用程序都通过企业服务总线 (ESB) 进行通信。另一方面，微服务将范围限制在应用程序中。微服务仅满足一个应用程序的需求，通常通过 API 与共享 ESB 进行通信。如果另一个应用程序需要相同的微服务，它会单独运行该微服务。这种差异会影响数据的管理方式。

使用 SOA，所有应用程序都可以从源中获取和修改数据。这在数据完整性和一致性方面具有优势，但可能会导致瓶颈和服务缓慢。使用 SOA，每个服务都可以设计为从后端关系数据库读取和写入数据，该数据库是公司的记录系统。相比之下，微服务通常被设计为可以在本地访问他们需要的所有数据——简化设计并提高性能——可能以数据复制为代价。

在典型的微服务示例中，应用程序中的每个微服务可能都有自己的数据库——电子商务应用程序可能有一个使用帐户数据库管理帐户信息的服务，一个使用自己的库存数据库管理库存的服务，等等——允许每个服务在没有瓶颈的情况下运行，并在后端同步数据以确保必要时的一致性。

五、组件

5.1.服务发现

5.1.1概括

在微服务应用程序中，正在运行的服务实例集是动态变化的。实例具有动态分配的网络位置。因此，为了让客户端向服务发出请求，它必须使用服务发现机制。

服务发现的一个关键部分是服务注册表。服务注册表是可用服务实例的数据库。服务注册中心提供管理 API 和查询 API。服务实例使用管理 API 在服务注册表中注册和注销。系统组件使用查询 API 来发现可用的服务实例。

有两种主要的服务发现模式：客户端发现和服务端发现。在使用客户端服务发现的系统中，客户端查询服务注册表，选择可用实例并发出请求。在使用服务器端发现的系统中，客户端通过路由器发出请求，路由器查询服务注册表并将请求转发到可用实例。

服务实例在服务注册表中注册和注销有两种主要方式。一种选择是让服务实例向服务注册中心注册自己，即自注册模式。另一种选择是让其他系统组件代表服务处理注册和注销，即第三方注册模式。

在某些部署环境中，您需要使用服务注册表（例如Netflix Eureka、etcd或Apache Zookeeper ）来设置自己的服务发现基础架构。在其他部署环境中，服务发现是内置的。例如，Kubernetes和Marathon处理服务实例注册和注销。它们还在每个集群主机上运行一个代理，充当服务器端发现路由器的角色。

HTTP 反向代理和负载均衡器（例如 NGINX）也可以用作服务器端发现负载均衡器。服务注册中心可以将路由信息推送到 NGINX 并调用优雅的配置更新；例如，您可以使用Consul Template。NGINX Plus 支持额外的动态重新配置机制 ——它可以使用 DNS 从注册表中提取有关服务实例的信息，并提供用于远程重新配置的 API。

5.1.2为什么要使用服务发现？

假设您正在编写一些代码来调用具有 REST API 或 Thrift API 的服务。为了发出请求，您的代码需要知道服务实例的网络位置（IP 地址和端口）。在物理硬件上运行的传统应用程序中，服务实例的网络位置是相对静态的。例如，您的代码可以从偶尔更新的配置文件中读取网络位置。

然而，在现代的、基于云的微服务应用程序中，这是一个更难解决的问题，如下图所示。
在这里插入图片描述

服务实例具有动态分配的网络位置。此外，服务实例集会因自动缩放、故障和升级而动态变化。因此，您的客户端代码需要使用更精细的服务发现机制。

有两种主要的服务发现模式：客户端发现和服务器端发现。让我们先看看客户端发现。

5.1.3客户端发现模式

使用客户端发现时，客户端负责确定可用服务实例的网络位置以及它们之间的负载平衡请求。客户端查询服务注册表，它是可用服务实例的数据库。然后客户端使用负载平衡算法来选择一个可用的服务实例并发出请求。

下图显示了这种模式的结构。

通过客户端服务发现，客户端确定可用服务实例的网络位置并在它们之间平衡请求

服务实例的网络位置在启动时向服务注册表注册。当实例终止时，它会从服务注册表中删除。服务实例的注册通常使用心跳机制定期刷新。

Netflix OSS提供了一个很好的客户端发现模式示例。Netflix Eureka是一个服务注册中心。它提供了一个 REST API 来管理服务实例注册和查询可用实例。Netflix Ribbon是一个 IPC 客户端，它与 Eureka 一起在可用服务实例之间负载平衡请求。我们将在本文后面更深入地讨论 Eureka。

客户端发现模式有很多优点和缺点。这种模式相对简单，除了服务注册表之外，没有其他活动部分。此外，由于客户端知道可用的服务实例，它可以做出智能的、特定于应用程序的负载平衡决策，例如一致地使用散列。这种模式的一个重要缺点是它将客户端与服务注册表耦合在一起。您必须为服务客户端使用的每种编程语言和框架实现客户端服务发现逻辑。

现在我们已经了解了客户端发现，让我们来看看服务器端发现。

5.1.4 服务器端发现模式

服务发现的另一种方法是服务器端发现模式。下图显示了这种模式的结构。
在这里插入图片描述

客户端通过负载均衡器向服务发出请求。负载均衡器查询服务注册表并将每个请求路由到可用的服务实例。与客户端发现一样，服务实例在服务注册表中注册和注销。

AWS 弹性负载均衡器(ELB) 是服务器端发现路由器的一个示例。ELB 通常用于负载平衡来自 Internet 的外部流量。但是，您也可以使用 ELB 对虚拟私有云 (VPC) 内部的流量进行负载平衡。客户端使用其 DNS 名称通过 ELB 发出请求（HTTP 或 TCP）。ELB 负载平衡一组已注册的弹性计算云 (EC2) 实例或 EC2 容器服务 (ECS) 容器之间的流量。没有单独的服务注册表。相反，EC2 实例和 ECS 容器注册到 ELB 本身。

HTTP 服务器和负载均衡器（例如NGINX Plus和 NGINX）也可以用作服务器端发现负载均衡器。例如，这篇博文描述了使用Consul 模板动态重新配置 NGINX 反向代理。Consul Template 是一个工具，它可以从存储在Consul 服务注册表中的配置数据定期重新生成任意配置文件。每当文件更改时，它都会运行任意 shell 命令。在博客文章描述的示例中，Consul Template 生成一个nginx.conf文件，它配置反向代理，然后运行一个命令告诉 NGINX 重新加载配置。更复杂的实现可以使用其 HTTP API 或 DNS动态重新配置 NGINX Plus 。

Kubernetes和Marathon等一些部署环境在集群中的每个主机上运行一个代理。代理扮演服务器端发现负载平衡器的角色。为了向服务发出请求，客户端使用主机的 IP 地址和服务分配的端口通过代理路由请求。然后，代理将请求透明地转发到集群中某处运行的可用服务实例。

服务器端发现模式有几个优点和缺点。这种模式的一大好处是发现的细节从客户端抽象出来。客户端只需向负载均衡器发出请求。这消除了为服务客户端使用的每种编程语言和框架实现发现逻辑的需要。此外，如上所述，某些部署环境免费提供此功能。然而，这种模式也有一些缺点。除非部署环境提供负载均衡器，否则它是您需要设置和管理的另一个高可用性系统组件。

5.1.5服务注册中心

服务注册中心是服务发现的关键部分。它是一个包含服务实例的网络位置的数据库。服务注册中心需要高度可用并且是最新的。客户端可以缓存从服务注册表获得的网络位置。但是，该信息最终会过时，客户端将无法发现服务实例。因此，服务注册中心由一组服务器组成，这些服务器使用复制协议来保持一致性。

如前所述，Netflix Eureka是服务注册中心的一个很好的例子。它提供了一个用于注册和查询服务实例的 REST API。服务实例使用POST请求注册其网络位置。每 30 秒，它必须使用PUT请求刷新其注册。通过使用 HTTPDELETE请求或实例注册超时来删除注册。如您所料，客户端可以使用 HTTPGET请求检索已注册的服务实例。

Netflix 通过在每个 Amazon EC2 可用区中运行一个或多个 Eureka 服务器来实现高可用性。每个 Eureka 服务器都在具有弹性 IP 地址的 EC2 实例上运行。DNSTEXT记录用于存储 Eureka 集群配置，它是从可用区到 Eureka 服务器网络位置列表的映射。当 Eureka 服务器启动时，它会查询 DNS 以检索 Eureka 集群配置，定位其对等点，并为自己分配一个未使用的弹性 IP 地址。

Eureka 客户端——服务和服务客户端——查询 DNS 以发现 Eureka 服务器的网络位置。客户更喜欢在同一可用区中使用 Eureka 服务器。但是，如果没有可用的，客户端将使用另一个可用区中的 Eureka 服务器。

服务注册表的其他示例包括：

etcd – 一种高度可用、分布式、一致的键值存储，用于共享配置和服务发现。使用 etcd 的两个著名项目是 Kubernetes 和Cloud Foundry。
consul – 发现和配置服务的工具。它提供了一个 API，允许客户端注册和发现服务。Consul 可以执行健康检查以确定服务可用性。
Apache Zookeeper – 一种广泛使用的高性能分布式应用程序协调服务。Apache Zookeeper 最初是 Hadoop 的一个子项目，但现在是一个顶级项目。

此外，如前所述，Kubernetes、Marathon 和 AWS 等一些系统没有明确的服务注册表。相反，服务注册表只是基础架构的内置部分。

现在我们已经了解了服务注册中心的概念，让我们看看服务实例是如何注册到服务注册中心的。

5.1.5.1 服务注册选项

如前所述，服务实例必须在服务注册表中注册和注销。有几种不同的方法来处理注册和注销。一种选择是让服务实例自己注册，即自注册模式。另一种选择是让其他系统组件管理服务实例的注册，即第三方注册模式。我们先来看看自注册模式。

5.1.5.1.1自注册模式

当使用自注册模式时，服务实例负责向服务注册中心注册和注销自己。此外，如果需要，服务实例会发送心跳请求以防止其注册过期。下图显示了这种模式的结构。
在这里插入图片描述

这种方法的一个很好的例子是Netflix OSS Eureka 客户端。Eureka 客户端处理服务实例注册和注销的所有方面。Spring Cloud 项目实现了包括服务发现在内的各种模式，使得向 Eureka 自动注册服务实例变得容易。您只需使用注解来注解您的 Java 配置类@EnableEurekaClient。

自注册模式有各种优点和缺点。一个好处是它相对简单，不需要任何其他系统组件。但是，一个主要缺点是它将服务实例与服务注册表耦合。您必须在服务使用的每种编程语言和框架中实现注册代码。

将服务与服务注册表分离的另一种方法是第三方注册模式。

5.1.5.1.2第三方注册模式

使用第三方注册模式时，服务实例不负责将自己注册到服务注册中心。相反，另一个称为服务注册器的系统组件处理注册。服务注册器通过轮询部署环境或订阅事件来跟踪对运行实例集的更改。当它注意到一个新可用的服务实例时，它会向服务注册表注册该实例。服务注册器还注销终止的服务实例。下图显示了这种模式的结构。
在这里插入图片描述

服务注册器的一个示例是开源Registrator项目。它会自动注册和注销部署为 Docker 容器的服务实例。Registrator 支持多个服务注册中心，包括 etcd 和 Consul。

服务注册商的另一个例子是NetflixOSS Prana。它主要用于以非 JVM 语言编写的服务，是与服务实例并行运行的 sidecar 应用程序。Prana 向 Netflix Eureka 注册和注销服务实例。

服务注册器是部署环境的内置组件。Autoscaling Group 创建的 EC2 实例可以自动注册到 ELB。Kubernetes 服务会自动注册并可供发现。

第三方注册模式有各种优点和缺点。一个主要的好处是服务与服务注册表分离。您不需要为开发人员使用的每种编程语言和框架实现服务注册逻辑。相反，服务实例注册在专用服务中以集中方式处理。

这种模式的一个缺点是，除非它内置到部署环境中，否则它是另一个需要设置和管理的高可用性系统组件。

5.2网关

5.2.1概述

理论上，客户端可以直接向每个微服务发出请求。每个微服务都有一个公共端点（https:// *serviceName* .api.company.name）。该 URL 将映射到微服务的负载均衡器，该负载均衡器在可用实例之间分配请求。为了检索产品详细信息，移动客户端将向上面列出的每个服务发出请求。
在这里插入图片描述

不幸的是，此选项存在挑战和限制。一个问题是客户端的需求与每个微服务公开的细粒度 API 之间的不匹配。此示例中的客户端必须发出七个单独的请求。在更复杂的应用程序中，它可能需要做更多的事情。例如，亚马逊描述了数百种服务如何参与呈现他们的产品页面。虽然客户端可以通过 LAN 发出这么多请求，但在公共 Internet 上可能效率太低，而且在移动网络上肯定不切实际。这种方法还使客户端代码更加复杂。

客户端直接调用微服务的另一个问题是，有些可能使用不适合 Web 的协议。一项服务可能使用 Thrift 二进制 RPC，而另一项服务可能使用 AMQP 消息传递协议。这两种协议对浏览器或防火墙都不是特别友好，最好在内部使用。应用程序应在防火墙外使用 HTTP 和 WebSocket 等协议。

这种方法的另一个缺点是难以重构微服务。随着时间的推移，我们可能想要改变系统划分为服务的方式。例如，我们可能会合并两个服务或将一个服务拆分为两个或多个服务。但是，如果客户端直接与服务通信，那么执行这种重构可能会非常困难。

由于这些类型的问题，客户直接与微服务对话几乎没有意义。

5.2.2 应用场景

通常更好的方法是使用所谓的API Gateway。API 网关是一个服务器，它是系统的单一入口点。它类似于面向对象设计的外观模式。API 网关封装了内部系统架构，并提供了为每个客户端量身定制的 API。它可能具有其他职责，例如身份验证、监控、负载平衡、缓存、请求整形和管理以及静态响应处理。

下图显示了 API 网关通常如何适应架构：

API 网关使电子商务应用程序的移动客户端能够访问其 7 个微服务的 RESTful API

API 网关负责请求路由、组合和协议转换。来自客户端的所有请求首先通过 API 网关。然后它将请求路由到适当的微服务。API 网关通常会通过调用多个微服务并聚合结果来处理请求。它可以在 HTTP 和 WebSocket 等 Web 协议与内部使用的 Web 不友好协议之间进行转换。

API 网关还可以为每个客户端提供自定义 API。它通常为移动客户端公开一个粗粒度的 API。例如，考虑产品详细信息场景。API 网关可以提供一个端点 ( /productdetails?productid= *xxx* )，使移动客户端能够通过单个请求检索所有产品详细信息。API 网关通过调用各种服务（产品信息、推荐、评论等）并组合结果来处理请求。

API 网关的一个很好的例子是Netflix API 网关。Netflix 流媒体服务可在数百种不同类型的设备上使用，包括电视、机顶盒、智能手机、游戏系统、平板电脑等。最初，Netflix 试图为其流媒体服务提供一种万能的API。然而，他们发现由于设备种类繁多及其独特的需求，它并不能很好地工作。今天，他们使用 API 网关，通过运行特定于设备的适配器代码为每个设备提供定制的 API。适配器通常通过平均调用六到七个后端服务来处理每个请求。Netflix API 网关每天处理数十亿个请求。