微服务体系结构是软件开发中最热门的趋势之一。作为CTO，你需要知道何时使用它们。但你也需要对这个主题有更深入的了解才能真正掌握你的项目。通过进一步了解微服务中的设计模式，您将确切了解微服务是如何工作的，以及开发人员如何使它们更高效、可伸缩和更安全。满足最流行的微服务设计模式。

在上一篇关于微服务的文章中，我们介绍了这种流行的软件体系结构的基础知识。有了这些知识，您就知道微服务最适合哪种项目了。但是一旦你决定去做它，会有更多的决定要做。这就是为什么你应该学习设计模式。

微服务中的设计模式是什么？

如您所知，微服务是一个很大程度上独立的应用程序组件，其任务是系统中的特定功能。多个微服务，每个微服务负责应用程序的另一个功能，再加上客户端（例如web和移动应用程序的前端）和其他（可选）中间层，构成了基于微服务的体系结构。

这种类型的设置有许多优点，例如能够用不同的技术编写任何服务并独立地部署它们，以及性能提升等等。但它也带来了一些挑战，包括复杂的管理和配置。

设计模式的存在旨在解决微服务中的此类常见挑战，并提供经验证的解决方案，使您的体系结构更高效，整个管理过程更省钱、更麻烦。因此，了解它们是更好地理解微服务的一个很好的方法——比实际的编码更高层次，但又足够具体，可以理解微服务的内部工作原理。

 

为什么要学习设计模式？

选择正确的设计模式可以决定你的基于微服务的项目的成败。它们是微服务本身并不是万能药的最好证明，要真正从中受益，你需要正确地使用它们。

如果您不关心微服务设计模式：

• 你的应用程序可能表现不佳（由于不必要的调用和资源使用效率低下），
• 整个系统将不稳定（例如连接和集成问题），
• 它可能面临可伸缩性问题（添加更多的服务可能导致难以维护依赖性，甚至可能使其成为事实上的一个整体），
• 它可能会通过向公众公开微服务的端点或通过其他方式危害安全性。
• 您可能有更多的维护和调试工作要做，而不是做更好的准备。

微服务设计模式的类型

微服务中的设计模式几乎存在于架构的每个方面。一些最重要的问题可分为以下几个方面：

通信

它涉及微服务和客户端应用程序（前端层）之间的通信方法。

内部沟通

这些设计模式构成了微服务之间进行通信的各种方式。

安全

各种与安全相关的问题，如安全层的组织、不同类型用户对特定微服务的授权和访问级别等。

可用性

确保所有的微服务都准备好满足系统的需求（不管流量有多大），确保尽可能少的停机时间。这包括确保微服务可以在另一台计算机上重新启动，或者是否有足够的计算机可用，微服务能够自行报告其当前状态，运行状况检查等等。

服务发现

它指的是微服务用来找到彼此并知道它们的位置的方法。

配置

设置参数并监控整个系统的性能，以便在您进行过程中不断优化

在本文的后续部分中，我们将主要关注第一种类型，讨论三种最流行的通信模式——直接模式、API网关和前端后端（BFF）。它们提供了一个很好的机会来了解基于微服务的体系结构是如何工作的，以及开发人员的选择对其性能的影响。

直接模式

这是基于微服务架构的最基本的设置。在这种模式下，客户端应用程序直接向微服务发出请求，如下图所示。每个微服务都有一个公共端点（URL），客户端可以与之通信。

这非常容易设置，对于相对较小的应用程序来说已经足够了，但是随着应用程序的规模和复杂性的增长，这些挑战会变得越来越明显和麻烦：

性能问题

即使是应用程序的一个页面也可能需要对不同的微服务进行多次调用，这可能会导致较大的延迟和性能问题。

可伸缩性问题

因为客户端应用程序直接引用微服务，所以对微服务的任何更改都可能导致应用程序崩溃。这使得维护困难。

安全问题

没有中间层，微服务的端点就会暴露出来。这不一定会使应用程序本身就不安全，但它肯定会使安全问题变得更难处理。

复杂性问题

此外，每个公共微服务都需要包含安全和其他跨服务任务。如果有一个额外的层，它们可以被包含在那里，使所有的微服务更简单。

由于微服务通常被推荐用于复杂的应用程序，因此必须有更具可伸缩性的模式。

API网关

当然有！API网关将这一切提升到一个级别。如下图所述，它提供了一个额外的层，一组微服务和前端层之间的单一入口点。它解决了我们刚刚提到的所有问题，通过向公众隐藏微服务的端点，从客户端抽象对微服务的引用，并通过聚合多个调用来减少延迟。

然而，API网关模式仍然不能避免可伸缩性问题。当体系结构围绕一个客户机时，这已经足够了。但是如果有多个客户端应用程序，API网关最终可能会膨胀，因为它吸收了来自不同客户端应用程序的所有不同需求。最终，它可能会成为一个单一的应用程序，并面临许多与直接模式相同的问题。

因此，如果您计划让基于microservices的系统具有多个客户机或不同的业务域，那么您应该从一开始就考虑使用前端后端模式。

前端的后端（BFF）

网关API本质上是BFF模式的变体。它还提供了微服务和客户端之间的附加层。但它不是单一的入口点，而是为每个客户机引入了多个网关。

使用BFF，您可以添加一个为每个客户机的需求量身打造的API，从而消除了由于将它们都放在一个地方而导致的大量膨胀。结果模式如下图所示。

值得一提的是，这种特定的模式可能仍会扩展到特别复杂的应用程序。还可以为特定的业务域创建不同的网关。这个模型足够灵活，可以响应任何类型的基于微服务的情况。

这是否意味着每个基于微服务的架构都应该使用BFF模式？不一定。设计越复杂，需要的设置和配置就越多。并不是每个应用程序都需要这样做。但是如果你想创建一个应用程序的生态系统，或者计划在将来扩展它，为了将来的可扩展性，你可以选择更复杂的通信模式。

如果你想了解更多关于BFF的信息，一定要阅读我们的前端案例研究的后端——这是一个应用程序生态系统的故事，它是使用模式重塑的。

其他值得注意的设计模式

正如我前面提到的，设计模式存在于微服务的各个方面。开发人员常常被迫在这两者之间做出选择，考虑到不同的因素。在其他一些情况下，它们可以组合在一起或一起使用。

对于内部通信，一些最流行的模式包括REST、gRPC、messagebroker或远程过程调用。在安全性方面，访问控制列表（ACL）可以用于每个微服务或每个网关，也可以作为独立的微服务（或者根本不使用）。说到可用性，我们可以使用基于DNS或硬件的负载平衡。服务发现可以在客户端或服务器端执行。至于配置，可以是外部化的（每个微服务都有自己的一个）或集中化（所有配置都在一个地方）。名单还在继续。

另请参阅：gRPC实用介绍

结论

随着微服务越来越流行，新的设计模式出现了，以帮助解决各种开发挑战，并使体系结构更加高效。尽可能多地了解它们是值得的，但归根结底还是要为特定的软件生态系统选择正确的软件。说到这一点-相信你的开发人员，但要确保你知道他们的选择和他们对你的软件的影响。

 

原文：https://tsh.io/blog/design-patterns-in-microservices-api-gateway-bff-and-more/

本文：http://jiagoushi.pro/node/1088

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】