微服务和单体架构优缺点(微服务和单体服务的区别)

导语：微服务与单体架构：一种实用的方法

单体及其问题

当我们开始学习后端开发和实现时，我们中的许多人在一个代码库中实现我们所有的功能。外汇。如果我们想构建电子商务商店的后端，那么我们可以使用一个包含以下功能的 index.js 文件来完成该项目：-

购物订单

物品或产品

支付

店铺

钱包

购物车

但是这样做对吗？我们确实拥有单体架构的优势，例如易于测试和易于部署。但我们确实存在一些问题，例如可伸缩性、负载平衡和错误处理。

通过微服务，我们可以解决这些问题，我们还可以有效地使用一些先进的技术，如 Docker、Kubernetes。

微服务

微服务架构包括松散耦合的独立服务的工作，它们通常在不同的端口上工作，并且通常使用自己的数据库。

让我们举一个带有支付、产品和运输服务的电子商务应用程序的例子。它可能看起来像这样：-

例子:-

产品

--> 使用:- JAVA, MYSQL

--> 工作在:- PORT 3001

支付

--> 使用:- NODE, MongoDB

-->工作在:- PORT 4000

关系

--> 使用:- Python, SQLite

--> 工作在:- PORT 3002

现在这些服务可以使用 API 等相互通信。我们的优势是负载均衡，错误处理（如果支付服务失败不会影响产品服务），以及这种架构（微服务）的模块化代码。

微服务模式

在我们实现微服务的同时，有一些模式，例如使用 BFF（前端后端），服务发现

BFF（前端后端）

在这里，我们有 API 网关来处理所有的事情，如身份验证、负载平衡等，并充当反向代理来接受传入的请求并给出适当的结果。

服务发现注册表

当我们有多个服务实例并且我们从服务发现中获取特定实例的地址时使用它。

注意：- 我们也会看到实现，如果您不能完全理解，请不要惊慌。

微服务间通信

这是我们可以在服务之间进行调用的方法之一。您可以根据功能进行同步调用或异步调用。在这里，我们使用了将从服务 1 传递消息的队列。

断路器

这种情况出现在一个或多个调用在其间失败而其他一直在等待时。外汇。 Service2-->Service3调用失败，Service 1会一直等待。在这种情况下，我们可以执行以下操作：-

使用存储在服务 2 和 3 的缓存中的最近一次调用并给出响应

Fallback call：- Service 3 调用另一个第三方 API 并等待很长时间时的情况。然后 Service 2 可以直接调用那个 3rd 方 API

日志聚合模式

这是我们存储活动微服务的所有日志的模式，以便我们可以跟踪和监控它们

无服务器

这是一个云计算应用程序，我们可以在其中使用调用时触发的函数。虽然这些功能确实有冷启动时间，但在大多数应用程序中可能非常有效。

本文内容由小思整理编辑！