我现在已经研究了微服务的概念,并了解它们是什么以及为什么它们是必要的.
快速复习
简而言之,monolith应用程序被分解为独立的可部署单元,每个单元通常公开它自己的Web API并拥有自己的数据库.每项服务都履行一项责任并做得很好.这些服务通过REST或SOAP等同步Web服务进行通信,或者使用JMS等异步消息传递来协同处理某些请求.我们的整体应用程序已成为一个分布式系统.通常,所有这些细粒度的API都可以通过API网关或代理提供,它充当单点入口外观,执行安全性和监视相关任务.
适应微服务的主要原因是高可用性,零停机更新和通过特定服务的水平扩展实现的高性能,以及系统中更松散的耦合,这意味着更容易维护.此外,IDE功能,构建和部署过程将显着加快,并且更容易更改框架甚至语言.
微服务与集群和容器化技术(如Docker)密切相关.每个微服务都可以打包为docker容器,以便在任何平台上运行它.集群的主要概念是服务发现,复制,负载平衡和容错. Docker Swarm是一个集群工具,它协调这些容器化服务,将它们粘合在一起,并以声明方式处理所有这些任务,保持集群的所需状态.
理论上听起来既简单又简单,但我仍然不明白如何在实践中实现这一点,即使我非常了解Docker Swarm.让我们看一个具体的例子.
这是个问题
我正在使用Spring Boot构建一个简单的java应用程序,由MySQL数据库支持.我想构建一个系统,用户从服务A获取网页并提交表单.服务A将对数据进行一些操作并将其发送到服务B,后者将进一步操作数据,写入数据库,返回一些内容,最后将一些响应发送回用户.
现在的问题是,服务A不知道在哪里找到服务B,服务B也不知道在哪里找到数据库(因为它们可以部署在集群中的任何节点上),所以我不知道应该如何配置Spring启动应用程序.我想到的第一件事是使用DNS,但我找不到如何在docker swarm中设置这样一个系统的教程.在Spring中为分布式云部署配置连接参数的正确方法是什么？我已经研究过Spring Cloud项目,但不明白它是否是这种困境的关键.
我也很困惑应该如何部署数据库.他们是否应该居住在集群中,与服务一起部署(可能借助于docker compose),还是以更传统的方式使用固定IP进行管理？
最后一个问题是关于负载平衡.如果每个服务应该有多个负载平衡器,或者只有一个主负载均衡器,我会感到困惑.负载均衡器是否具有映射到域名的静态IP,并且所有用户请求都以此负载均衡器为目标？如果负载均衡器出现故障怎么办呢？它是否会尽一切努力来扩展服务毫无意义？是否有必要使用Docker Swarm设置负载均衡器,因为它有自己的路由网格？哪个节点最终用户应该定位？
一个
乙
C
A是您的DB,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上侦听的服务,所有群集主机将在端口8018上侦听并以循环方式将其路由到容器.
但是,最佳做法是在主机发生故障时让应用程序负载平衡器位于主机前面.
