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

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

📍 整体性及其问题

🙂 当我们开始学习后端开发和实现时，很多人都会把所有功能都放在一个代码库里。例如，如果我们想构建一个电商网站的后端，那么我们可以选择一个只包含以下功能的 index.js 文件：

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

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

🎯 借助微服务，我们可以解决这些问题，还可以有效地使用Docker 、Kubernetes等一些先进技术。

📍 微服务

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

😌 我们来看一个包含支付、产品和物流服务的电商应用示例。它可能看起来像这样：

例子：-

产品
--> 使用：JAVA、MYSQL
--> 运行于：端口 3001
支付
--> 使用：NODE、MongoDB
--> 运行于：端口 4000
物流
--> 使用：Python、SQLite
--> 运行于：端口 3002

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

📍 微服务模式

🔥 在实现微服务的过程中，有一些模式可以借鉴，例如使用 BFF（后端服务于前端）和服务发现。

BFF（前端后端）

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

服务发现注册表

👉 当我们需要为某个服务创建多个实例，并通过服务发现获取特定实例的地址时，可以使用此功能。

🙂注意：我们也会看看具体实现方式，如果您不能完全理解，请不要惊慌。

微服务间通信

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

电路中断

👉 当一个或多个调用之间出现故障，而其他调用持续等待时，就会出现这种情况。例如，外汇服务 2 到服务 3 的调用失败，服务 1 将继续等待。在这种情况下，我们可以执行以下操作：

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

日志聚合模式

👉 这种模式用于存储所有活跃微服务的日志，以便我们能够跟踪和监控它们。

无服务器

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

🔥关注我们获取更多内容。我们将在下一篇博客中详细介绍具体实施情况。欢迎分享本系列文章并留下您的评论。