使用微服务的设计模式 - fabric

21-08-24 banq

电子商务企业正在使用微服务为其商店构建一组可重用的组件。这些服务通过独立于前端运行,可以更轻松地将您的内容大规模交付到多个渠道。

在这篇文章中,我将讨论您可以实现的几种设计模式并解释它们提供的功能。我还将讨论常见的用例。

 

理解软件设计模式

软件设计模式是定义的解决常见问题的方法。它们帮助开发人员了解系统的组件如何相互关联和交互。没有“完美”的设计模式——每一种都有优点和缺点,并且在特定情况下很有帮助。

大多数开发人员花费数年时间练习正确地获取这些模式。但是,通过正确应用它们,您可以取得成果。现代电子商务架构有五种设计模式:

  • 扼杀者模式:一种从遗留软件迁移到更现代方法的有用方法。
  • 大使模式:这为您提供了一种处理网络问题的封装方法。
  • Sidecar 模式:这可以帮助您添加功能,而不会与软件的其余部分过于紧密地耦合。
  • API 接口:这些帮助软件服务和组件进行通信。
  • 函数链:这些帮助代码处理顺序任务。

虽然实现是最困难的部分,但了解每个模式的名称和意图是必不可少的第一步。在本指南的最后,您将有一个起点来决定每种方法何时适合您的电子商务平台。

 

扼杀者模式

以扼杀无花果树命名,扼杀模式正在逐渐从一个平台移动到另一个平台。为此,您可以通过一个接一个地替换部分软件,直到最终将旧系统完全扼杀。在实践中,您可以将其分解为三个步骤:

  • 转换:您创建服务的新版本,一次替换一个
  • 共存:将新服务和旧服务一起运行的地方
  • 淘汰:您更换所需的一切,并可以淘汰旧系统

使用扼杀者模式允许持续交付新功能和高代码覆盖率。它还促进了模块化、测试驱动的方法,使您能够隔离问题并确保您提供的每项服务都能正常运行。

这是转移到新软件设置的好方法,例如从单体应用到微服务。它让您可以将工作分解为可管理的块,从而快速推动结果。此外,您可以将任务分配给不同的团队,以增加整个工程组织的支持度和责任感。

另一方面,这可能需要时间。但是,您可以通过让团队并行工作来缓解这种情况。正确地建立团队确定事物的技术方面一样重要。

 

大使模式

在大使模式中,“大使”服务致力于沟通。您创建一个代理进程或服务来处理应用程序其余部分的网络请求。

使用大使服务后,您可以添加监控、日志记录和呼叫重新路由等功能。将请求从一种格式转换为另一种格式非常有用——例如,多渠道电子商务,您将产品分发给许多不同的前端消费者。

如果您混合使用传统软件和现代软件,它可以帮助缩小差距,确保您的网络符合现代安全和责任标准。从组织的角度来看,它允许您为代理服务本身分配一个团队,从而允许您划分责任。 

虽然大使模式可以快速将不同的系统联系在一起,但如果网络延迟是一个问题,则它并不理想。它可以增加服务间通信以及更高的内存和 CPU 使用率。

如果您在摆脱您一直在维护的单体应用或遗留软件时遇到问题,大使可能是规避这些弱点的好方法。它允许您向旧软件添加功能,而无需重写所有内容。

 

边车模式

在 sidecar 模式中,您将一组指定的功能移动到一个单独的组件中。该组件与主应用程序一起存在,通常共享相同的生命周期。

Sidecar 与其父级一起托管,甚至可以在同一进程中运行。这意味着当 sidecar 与父级通信时几乎没有延迟,并且它可以访问相同的资源。

但是,它可以使用与主要服务不同的编程语言或框架,并且多个边车可以使用不同的语言。这意味着在添加额外功能或迎合不同团队成员的优势和偏好时,您可以使用适合该工作的工具。

通常,sidecar 进程可以处理外围功能,例如日志记录或网络连接,而主应用程序处理核心功能。因此,如果您需要移动或重新配置应用程序,团队可以专注于 sidecar,而无需更改主应用程序。

这是一个具有许多潜在应用的简单模式。例如,在电子商务环境中,您可以使用它来记录金融交易。由于详细记录在电子商务中至关重要,因此您可以拥有一个独立的记录,以便随着时间的推移进行添加和构建。

您还可以使用 sidecar 模式来处理网络操作,例如向旧服务添加现代加密。这可以让您对旧的电子商务系统进行部分现代化,而无需完全重写。

 

API接口

应用程序编程接口或API是软件组件使用一组定义的调用相互通信的方式。Web 服务或微服务通常使用 API。

除了通过网络通信使用它们之外,您还可以将它们用于同一主机上的微服务之间的通信。API 接口中有几种常见的模式。

REST 是最受认可的。它是计算机科学课程的主要内容,也是大量网站和服务的标准。它包括一组动词,用于实现 CRUD 模式。RESTful 服务是无状态且可缓存的,因此非常适合 Web。

在无头商务中,API 允许多个前端应用程序与您的后端服务进行通信。部署在任何其他平台上的网站、应用程序和软件可以将 API 请求发送到同一位置。这使您可以单独处理每个组件,进行改进和添加,而无需担心对整个生态系统的影响。

在集成服务或软件时,API 是最常用的连接方式。fabric 的 API 集有完整的文档来帮助您使用它们。

 

函数链

您可以在云上构建自包含、无状态并可按需执行的无服务器函数。Amazon Web Services、Microsoft Azure 和 Google Cloud 等服务让您可以创建这些,因此您不必担心硬件问题。

您可以将无服务器函数组织成一个函数链。在这种模式中,每个函数在完成时调用下一个函数。如果用户操作启动了一系列处理缓慢的任务,则此模式是理想的。第一个函数可以响应用户,所以他们不会等待。

应用此模式时需要考虑几个问题。理想情况下,函数是独立的且可替换的,但这里的函数是相互依赖的。这打破了面向对象的设计原则,但对于某些应用程序是必要的。您可以使用排队系统按顺序调用函数,使它们更独立可操作和可扩展。

函数链对于实现定义明确的顺序任务很有用。例如,您可能希望在用户下订单后调用函数链,通过不同的微服务处理数据并将其推送到每个后续数据存储中。

这些任务都可以独立发生,也可以在后台发生。这样,您的电子商务商店的 UI 会保持快速,而后端函数可能需要几分钟才能完成。

 

猜你喜欢