实践中的微服务

Question

我已经研究了微服务的概念很长一段时间，并了解它们是什么以及为什么它们是必要的。

快速复习

简而言之，单体应用程序被分解为独立的可部署单元，每个单元通常都公开自己的 Web API 并拥有自己的数据库。每个服务都履行一项职责并且做得很好。这些服务通过 REST 或 SOAP 等同步 Web 服务进行通信，或者使用 JMS 等异步消息传递协同完成某些请求。我们的单体应用程序已成为分布式系统。通常，所有这些细粒度 API 都通过 API 网关或代理提供，它们充当单点入口门面，执行安全和监控相关任务。

采用微服务的主要原因是高可用性、零停机更新和通过特定服务的水平扩展实现的高性能，以及系统中更松散的耦合，这意味着更容易维护。此外，IDE 功能、构建和部署过程将显着加快，并且更容易更改框架甚至语言。

微服务与集群和容器化技术密切相关，例如 Docker。每个微服务都可以打包为一个 docker 容器，以便在任何平台上运行。集群的主要概念是服务发现、复制、负载平衡和容错。 Docker Swarm 是一个集群工具，它可以编排这些容器化服务，将它们粘合在一起，并以声明的方式在后台处理所有这些任务，从而维护集群的所需状态。

理论上听起来很简单，但我仍然不明白如何在实践中实现这一点，即使我非常了解 Docker Swarm。我们来看一个具体的例子。

问题来了

我正在用 Spring Boot 构建一个简单的 Java 应用程序，由 MySQL 数据库支持。我想构建一个系统，用户从 Service A 获取网页并提交表单。 Service A 将对数据进行一些操作并将其发送给 Service B，后者将进一步操作数据，写入数据库，返回一些内容，最后返回一些响应给用户。

现在的问题是，Service A 不知道在哪里可以找到 Service B，Service B 也不知道在哪里可以找到 database（因为它们可以部署在集群中的任何节点上），所以我不知道应该如何配置 Spring boot 应用程序。我首先想到的是使用 DNS，但我找不到如何在 docker swarm 中设置这样的系统的教程。在 Spring 中配置连接参数以进行分布式云部署的正确方法是什么？我研究过Spring Cloud项目，但不明白它是否是这个困境的关键。

我也很困惑应该如何部署数据库。它们应该存在于集群中，与服务一起部署（可能在 docker compose 的帮助下），还是以更传统的方式使用固定 IP 来管理它们更好？

最后一个问题是关于负载平衡的。我很困惑每个服务是否应该有多个负载均衡器，或者只有一个主负载均衡器。负载均衡器是否应该将静态 IP 映射到域名，并且所有用户请求都以该负载均衡器为目标？如果负载均衡器发生故障怎么办，难道不是使扩展服务的所有努力都变得毫无意义吗？是否有必要使用 Docker Swarm 设置负载均衡器，因为它有自己的路由网格？那么最终用户应该针对哪个节点？

Answer 1

如果您正在考虑使用 Docker Swarm，则无需担心 DNS 配置，因为它已经由覆盖网络处理。假设您有三个服务：

一个 乙 C

A 是您的数据库，B 可能是第一个收集数据的服务，C 接收该数据并更新数据库 (A)

docker network create \
  --driver overlay \
  --subnet 10.9.9.0/24 \
  youroverlaynetwork

docker service create --network youroverlaynetwork --name A
docker service create --network youroverlaynetwork --name B
docker service create --network youroverlaynetwork --name C

创建所有服务后它们可以直接通过名称相互引用

这些请求针对该覆盖网络上的所有容器副本进行负载平衡。所以 A 总是可以通过引用“http://b”或仅通过调用主机名 B 来获得 B 的 IP。

当您在 Docker 中处理负载平衡时，swarm 服务已经在内部进行负载平衡。一旦你定义了一个监听 8018 端口的服务，所有 swarm 主机都会监听 8018 端口，并以循环方式将其路由到容器。

但是，在主机出现故障时，让应用程序负载平衡器位于主机前面仍然是最佳做法。