consul集群架构

上一篇文章是如何安装搭建consul集群并在这个集群上如何进行注册和发现服务，偏向于技术点的记录；这一篇从更宏观的角度对consul进行说明，偏向于架构的层面。由于consul集群的建立完全按照leader浩哥的要求来的，所以写文章的目的是想把这些琐碎的知识点总结一下，下面是架构图：

图中分为四个主要的部分：服务、Nginx、服务调用者和consul集群。

服务可能有几十上百或者更多个，这些服务分布在各个独立的项目（微服务）中，而某一个微服务又部署在一台以上的虚机或者物理机上。在各自提供服务的项目中如果写死consul集群的IP和端口的时候就会将所有的服务都注册在同一个consul集群的server上，虽然当这个server挂掉的时候集群依然能够提供服务，但是将所有的服务注册在某一个节点上本身就是不合理的。这样在注册的时候增加Nginx负载将注册服务的请求平均分布到集群中不同的consul节点上，同样在获取服务的时候也要经过Nginx这一层进行负载。注册服务的详细过程如下：

服务一在IP1上，服务二在IP2上，Nginx在IP3上，consul server1在IP4上，consul server2在IP5上。服务一在IP1上启动的时候会根据配置的spring.cloud.consul.host=IP3以及spring.cloud.consul.port=80配置，注意这里的端口配置不是8500而是80，这样在注册的时候服务请求就会经过Nginx，Nginx根据配置文件中的IP4和IP5设置会负载到某一个consul集群中的IP4上去，这时由于端口号没有指定会默认使用8500在负载之后的IP4上进行服务的注册，第二的服务也是如此流程。

################################

补充：

服务调用端会在consul集群中查询服务提供的地址，获取地址后，通过Nginx负载后直接调用服务

集群通过健康检查的方式判断服务是否还能提供服务，如果不能会被踢出