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

📍 单体架构及其问题

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

• 购物订单
• 商品或产品
• 支付
• 店铺
• 钱包
• 大车

🙋 但这样做真的正确吗？我们确实拥有单体架构的优势，比如易于测试和部署。但我们也面临一些问题，比如可扩展性、负载均衡和错误处理。

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

📍 微服务

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

😌 让我们以一个包含支付、产品和配送服务的电商应用为例。它可能看起来像这样：-

例子：-

产品
--> 使用：- JAVA、MYSQL
--> 正在处理：- 端口 3001
付款
--> 使用：- NODE、MongoDB
--> 正在处理：- 端口 4000
运输
--> 使用：- Python、SQLite
--> 正在处理：- 端口 3002

🙂 现在这些服务可以通过 API 等方式相互通信。这种架构（微服务）带来了负载均衡、错误处理（即使支付服务出现故障，也不会影响产品服务）以及模块化代码的优势。

📍 微服务模式

🔥 当我们实现微服务时，有一些模式，例如使用 BFF（后端用于前端）、服务发现

BFF（前端后端）

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

服务发现注册表

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

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

微服务间通信

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

熔断

👉 当中间一个或多个调用失败，而其他调用继续等待时，就会出现这种情况。例如，Service2->Service3 调用失败，Service 1 将继续等待。在这种情况下，我们可以执行以下操作：

• 使用服务 2 和 3 缓存中存储的最近一次调用并给出响应
• 回退调用：当服务 3 调用另一个第三方 API 并等待很长时间时，服务 2 可以直接调用该第三方 API。

日志聚合模式

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

无服务器

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

🔥关注我们，了解更多。我们将在下一篇博客中分享具体实现。分享本系列并发表你的看法