NodeJS 中的微服务架构

Posted 2023-03-08

【中文标题】NodeJS 中的微服务架构

【英文标题】：Microservices Architecture in NodeJS

【发布时间】：2017-03-19 18:48:04

【问题描述】：

我正在做一个副项目，我决定将我的 Skelton 项目重新设计为微服务，到目前为止，我还没有找到任何遵循这种模式的开源项目。经过大量阅读和搜索，我得出了这个设计的结论，但我仍然有一些问题和想法。

以下是我的问题和想法：

如果我有来自同一个微服务的 2 个节点，如何使 API 网关足够智能以加载平衡请求？ 如果其中一个微服务发生故障，发现应该如何知道？ 有没有类似的实现？我的设计对吗？ 我应该使用 Eureka 还是类似的东西？

【问题讨论】：

API 网关通常内置负载均衡功能。有些甚至实现了粘性会话等功能。三个最流行的 API 网关都是负载均衡器（它们最初不是作为 API 网关设计的）：haproxy、nginx 和 Apache。使用 Web 服务器和负载均衡器作为 API 网关的问题是，如果要添加或删除节点，则需要重新启动网关。我专门编写了一个 API 网关，以允许在不重新启动的情况下动态添加和删除节点：github.com/slebetman/typhos。它还没有准备好投入生产，但你可以分叉它

此外，由于 API 网关通常是负载均衡器，它们通常具有检测节点返回 400 和 500 错误的功能。所以通常发现服务只是将 url 返回到服务，并且该 url 几乎总是指向 API 网关。一些架构不使用 API 网关 (Amazon)，因此它们依赖于发现服务来检测宕机节点

@slebetman 是的，我知道，但我正在从头开始构建它，因为我没有找到任何适用于 nodejs 的好的网关，你有什么推荐的吗？

@SideeqYoussef 你有没有使用任何特定的库来实现这个架构？

【参考方案1】：

你的设计没问题。

如果您的 API 网关需要实现（可能就是这种情况）CAS/某种身份验证（通过其中一种服务 - 即某种用户服务），并且还应该跟踪所有请求并修改标头承载请求者元数据（用于内部 ACL/范围使用） - 您的 API 网关应该在 Node 中完成，但应该在关注负载平衡/HTTPS 的 Haproxy 下

Discovery 的位置正确 - 如果您要寻找适合您设计的一款，除了Consul，别无他法。

您可以使用 consul-template 或为服务和 API-Gateway 使用自己的微发现框架，以便它们在启动时共享端点数据。

ACL/Authorization 应按服务实现，API 网关的第一次请求应受所有授权中间件的约束。

使用 API 网关为每个请求提供请求 ID 来跟踪请求是很明智的，因此可以在“内部”系统中跟踪其生命周期。

我会添加 Redis 用于消息传递/workers/queues/fast in-memory 诸如缓存/缓存失效之类的东西（如果没有一个，您将无法处理所有 MS 架构） - 如果您有更多分布式事务，则使用 RabbitMQ还有很多消息

将所有这些都放在容器 (Docker) 上，以便更容易维护和组装。

至于 BI，为什么需要为此提供服务？您可以拥有外部的 ELK Elastisearch、Logstash、Kibana）并同时拥有仪表板、日志聚合和庞大的大数据仓库。

【参考方案2】：

你的设计看起来不错。我们还在使用 API Gateway 方法构建我们的微服务项目。包括网关服务（GW）在内的所有服务都是容器化的（我们使用 docker） Java 应用程序（spring boot 或 dropwizard）。也可以使用 nodejs 构建类似的架构。与您的问题相关的一些主题：

身份验证/授权：

GW 服务是客户端的单一入口点。所有的身份验证/授权操作都在 GW 中使用

JSON web tokens(JWT)

处理，它也有 nodejs 库。我们将用户角色等授权信息保存在 JWT 令牌中。一旦令牌在 GW 中生成并返回给客户端，客户端在每次请求时都会在 HTTP 标头中发送令牌，然后我们检查令牌是否客户端具有调用特定服务所需的角色或令牌是否已过期。在这种方法中，您不需要在服务器端跟踪用户的会话。实际上没有会话。所需信息在 JWT 令牌中。

服务发现/负载均衡：

我们使用

docker

，

docker swarm

是docker引擎捆绑的docker引擎集群工具（docker v.12.1之后）。我们的服务是码头集装箱。使用 docker 的容器化方法可以轻松部署、维护和扩展服务。在项目开始的时候，我们一起使用了

Haproxy、Registrator

和

Consul

来实现服务发现和负载均衡，和你画的差不多。然后我们意识到，只要我们创建一个

docker 网络

并使用

docker swarm

部署我们的服务，我们就不需要它们来进行服务发现和负载平衡。使用这种方法，您可以通过为每个环境创建不同的网络，在一台或多台机器上轻松地为您的服务（如 dev、beta、prod）创建隔离环境。一旦您创建了网络并部署了服务，服务发现和负载平衡就不再是您关心的问题了。在同一个 docker 网络中，每个容器都有其他容器的 DNS 记录，并且可以与它们通信。使用 docker swarm，您可以通过一个命令轻松扩展服务。在对服务的每个请求中，docker 将请求分发（负载平衡）到服务实例。