意图

用户对聚合器服务进行一次调用，然后聚合器将调用每个相关的微服务。

解释

真实世界例子

我们的网络市场需要有关产品及其当前库存的信息。 它调用聚合服务，聚合服务依次调用产品信息微服务和产品库存微服务，返回组合信息。

通俗地说

聚合器微服务从各种微服务中收集数据，并返回一个聚合数据以进行处理。

Stack Overflow上说

聚合器微服务调用多个服务以实现应用程序所需的功能。

目的

在客户端上提供帮助程序服务实例，并从共享资源上转移常用功能。

解释

真实世界例子

远程服务有许多客户端访问它提供的功能。 该服务是旧版应用程序，无法更新。 用户的大量请求导致连接问题。新的请求频率规则需要同时实现延迟检测和客户端日志功能。

通俗的说

使用“大使”模式，我们可以实现来自客户端的频率较低的轮询以及延迟检查和日志记录。

微软文档做了如下阐述

可以将大使服务视为与客户端位于同一位置的进程外代理。 此模式对于以语言不可知的方式减轻常见的客户端连接任务（例如监视，日志记录，路由，安全性（如TLS）和弹性模式）的工作很有用。 它通常与旧版应用程序或其他难以修改的应用程序一起使用，以扩展其网络功能。 它还可以使专业团队实现这些功能。

目的

API网关将所有对微服务的调用聚合到一起。用户对API网关进行一次调用，然后API网关调用每个相关的微服务。

解释

使用微服务模式，客户端可能需要来自多个不同微服务的数据。 如果客户端直接调用每个微服务，则可能会导致更长的加载时间，因为客户端将不得不为每个调用的微服务发出网络请求。此外，让客户端调用每个微服务会直接将客户端与该微服务相关联-如果微服务的内部实现发生了变化（例如，如果将来某个时候合并了两个微服务），或者微服务的位置（主机和端口） 更改，则必须更新使用这些微服务的每个客户端。

API网关模式的目的是缓解其中的一些问题。 在API网关模式中，在客户端和微服务之间放置了一个附加实体（API网关）。API网关的工作是将对微服务的调用进行聚合。 客户端不是一次单独调用每个微服务，而是一次调用API网关。 然后，API网关调用客户端所需的每个微服务。

目的

为了避免昂贵的资源重新获取，方法是在资源使用后不立即释放资源。资源保留其身份，保留在某些快速访问的存储中，并被重新使用，以避免再次获取它们。

类图

适用性

在以下情况下使用缓存模式

• 重复获取，初始化和释放同一资源会导致不必要的性能开销。

鸣谢

• Write-through, write-around, write-back: Cache explained
• Read-Through, Write-Through, Write-Behind, and Refresh-Ahead Caching
• Cache-Aside pattern

意图

以这样一种方式处理昂贵的远程服务调用，即单个服务/组件的故障不会导致整个应用程序宕机，我们可以尽快重新连接到服务。

解释

真实世界例子

想象一个 Web 应用程序，它同时具有用于获取数据的本地文件/图像和远程服务。 这些远程服务有时可能健康且响应迅速，或者由于各种原因可能在某 个时间点变得缓慢和无响应。因此，如果其中一个远程服务缓慢或未成功响应，我们的应用程序将尝试使用多个线程/进程从远程服务获取响应，很快它们都会挂起（也称为 [线程饥饿]thread starvation)导致我们的整个 Web 应用程序崩溃。我们应该能够检测到这种情况并向用户显示适当的消息，以便他/她可以探索不受远程服务故障影响的应用程序的其他部分。 同时，其他正常工作的服务应保持正常运行，不受此故障的影响。

意图

将静态内容部署到基于云的存储服务，该服务可以将它们直接交付给客户端。 这可以减少对昂贵计算实例的需求。

解释

真实世界例子

全球性的营销网站（静态内容）需要快速的部署以开始吸引潜在的客户。为了将托管费用和维护成本降至最低，使用云托管存储服务和内容交付网络。

通俗地说

静态内容托管模式利用云原生存储服务来存储内容和全球内容交付网络，将其缓存在世界各地的多个数据中心。 在静态网站上，单个网页包含静态内容。 它们还可能包含客户端脚本，例如 Javascript。相比之下，动态网站依赖于服务器端处理，包括服务器端脚本，如 PHP、JSP 或 ASP.NET。

目的

用于处理执行分布式事务时可能遇到的所有问题。

类图

适用场合

当我们需要提交两个数据库去完成事务，提交不是原子性且可能因此造成问题时，适合用这个设计模式。

解释

处理分布式事务很棘手，但如果我们不仔细处理，可能会带来不想要的后果。假设我们有一个电子商务网站，它有一个支付微服务和一个运输微服务。如果当前运输可用，但支付服务不可用，或者反之，当我们已经收到用户的订单后，我们应该如何处理？我们需要有一个机制来处理这些情况。我们必须将订单指向其中一个服务（在这个例子中是运输），然后将订单添加到另一个服务的数据库中（在这个例子中是支付），因为两个数据库不能原子地更新。如果我们当前无法做到这一点，应该有一个队列，可以将这个请求排队，并且必须有一个机制，允许队列中出现失败。所有这些都需要通过不断的重试，在保证幂等性（即使请求多次，变化只应用一次）的情况下，由一个指挥类来完成，以达到最终一致性的状态。

含义

分片模式是指将数据存储划分为水平分区或分片。每个分片都有相同的模式，但持有自己独特的数据子集。

一个分片本身就是一个数据存储（它可以包含许多不同类型的实体的数据），运行在作为存储节点的服务器上。

类图

适用场景

这种设计模式提供了一下的好处：

• 你可以通过增加在额外的存储节点上，运行的更多分片来实现系统扩容。
• 系统可以使用现成的廉价硬件，而不是为每个存储节点使用专门（或者昂贵）的服务器硬件。
• 你可以通过平衡各分片之间的工作负载来减少竞争，以提高性能。
• 在云环境中，分片可以在物理上靠近访问该节点数据的用户。