1 前言

   上篇文章提到利用eureka做服务发现，spring config server做集中配置，但是由于eureka 2.0已经停止开源开发，建议开发者切换到consul或者zookeeper上。

除了上篇文件提到的架构：

我们可以考虑利用consul实现集中配置和服务发现。

2 服务发现

spring cloud提供了多个服务发现框架集成，euerka已经停止开发了，目前最流行的是consul

Feature	euerka	Consul	zookeeper	etcd
服务健康检查	可配支持	服务状态，内存，硬盘等	(弱)长连接，keepalive	连接心跳
多数据中心	—	支持	—	—
kv 存储服务	—	支持	支持	支持
一致性	—	raft	paxos	raft
cap	ap	ca	cp	cp
使用接口(多语言能力)	http（sidecar）	支持 http 和 dns	客户端	http/grpc
watch 支持	支持 long polling/大部分增量	全量/支持long polling	支持	支持 long polling
自身监控	metrics	metrics	—	metrics
安全	—	acl /https	acl	https 支持（弱）
spring cloud 集成	已支持	已支持	已支持	已支持

为何选择consul？

• 一站式解决方案，提供服务发现，服务配置，服务切分等功能，可以单独应用，可以一起使用
• 服务发现：支持DNS和http
• 丰富的健康检测，内存是否超过90%，是否返回200 ok等
• K/V存储
• 安全的服务通信：利用Intentions实现服务切分，控制服务的访问权限
• 多数据中心

3 Consul架构

Consul基本概念

本文根据官网最准确描述进行理解，不是摘自各个blog

• Agent：Agent就是consul的一个节点，每个节点都运行一个agent，agent可以以client 或者server方式启动
• Client： 如果Agent以client方式启动，就称之为client。Client节点负责转发RPC请求，唯一参与的后端行为是参加gossip pool。需要的资源和带宽很少
• Server：如果Agent以server方式启动，称之为server。Server承担的功能很多：Raft一致性算法，集群状态，响应RPC查询，数据中心之间交换WAN gossip协议，转发请求给leader或者其它数据中心
• Data center：私有的，低延迟，高带宽的网络
• Consensus （一致性）协议 Raft https://www.consul.io/docs/internals/consensus.html Raft算法保证分布式一致性，事务顺序和leader选举
• Gossip协议：结对关系，事件广播，失败检测，基于UDP

协议Raft

分布式环境下的一致性问题如何解决？具体来说，我们要解决的是这个问题：

在分布式环境下，多个节点同时操作数据，读写数据，如何就某个值的最终结果达成一致？

为了解决这个问题，分布式一致性协议算法应运而生。先来了解一下最早的分布式一致性算法Paxos。

总体来说，分布式系统间通信存在两种模型，一种是共享内存，一种是消息传递。Paxos 算法解决的问题是在一个可能发生上述异常的分布式系统中如何就某个值达成一致，保证不论发生以上任何异常，都不会破坏决议的一致性。一个典型的场景是，在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么他们最后能得到一个一致的状态。为保证每个节点执行相同的命令序列，需要在每一条指令上执行一个“一致性算法”以保证每个节点看到的指令一致。一个通用的一致性算法可以应用在许多场景中，是分布式计算中的重要问题。

Paxos算法是基于消息传递且具有高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一

具体算法原理现在暂时不讲解，因为非常复杂，我们先从逻辑上梳理分布式算法的作用。是否可以应用于分布式事务,是否leader的选举采用了paxos算法？答案是肯定的：

Raft和Paxos都是分布式一致性算法，Paxos提出更早，但是很难以理解，所以从实用性和落地性，提出了新的分布式一致性算法Raft，很多的开源框架都是基于者两个算法。具体原理参考下面的连接动画：

http://thesecretlivesofdata.com/raft/

Consul架构图