1、应用场景
微服务架构、分布式架构场景下的服务发现、组件实例的发现、健康检查等。完成自动化服务发现，在服务动态上下线过程中，无需人工介入配置。
通常是结合客户端负载工具（例如ribbon）配合使用。
2、技术选型
常见的注册中心有zookeeper 、eureka、consul、etcd。从生态发展、便利性、语言无关性等角度来综合考量，选择consul，多数据中心支持，支持k-v能力，可扩展为配置中心。github地址：https://github.com/hashicorp/consul
具体选型就不展开了，可参看consul官网安利 https://www.consul.io/intro/vs/eureka.html
3、架构原理
consul节点在启动时可以定义自身角色，client、server两种。
client节点只负责转发外部请求，是无状态的；
server节点的职责是使用raft协议保证数据一致性，响应客户端的请求，维护集群状态，与其他数据中心交互。
节点之间通过gossip广播协议（谣言协议），进行节点之间的数据交互，最终大家达到一致。
3.1 搭建集群
3节点或五个server节点组一个集群，为什么是单数，因为集群需要选举一个leader来保证数据一致性。票数要超过半数以上才能选举为leader。
程序只有一个文件consul，从官网下载解压即可使用，使用如下命令启动第一个：
consul agent -server -ui -bootstrap-expect 3 -data-dir /consul/data -config-dir /consul/config -client 0.0.0.0
-server 指明为server节点
bootstrap-expect：启动集群需要的最少server数量
config-dir：没什么用，我们都是通过命令行配置启动
client：暴露给客户端访问的地址，默认是127.0.0.1，客户端就访问不了了
data-dir：关键的来了，这个目录很关键，存放一些持久化信息。包括：
1、node-id集群中该节点的ID
2、checks子目录，存放每个注册服务的健康检查配置信息
3、raft子目录，存放raft一致性协议实现数据同步的信息
4、services:在该节点上注册的服务，非常重要，即我们用spring-cloud-consul-discovery客户端往consul集群注册的信息，会保存在这，具体注册到哪一台server上，就是随机了
其他两个用如下命令启动：
consul agent -server -ui -retry-join consul-server1 -data-dir /consul/data -config-dir /consul/config -client 0.0.0.0
多了个retry-join，加入其他已存在的节点
三个节点启动后，他们就会自选举一个为leader。
可以通过consul members命令查看集群状态
3.2 在云上构建consul集群
docker容器化部署参考：https://github.com/wuzuquan/docker-file/tree/master/consul
三节点组一个集群，详细配置参考dockerfile及docker-compose文件。
对外通过一个lb组件暴露接口（lb要具备故障转移能力）。
注意事项：docker与虚拟机的最大差异在网络与存储，需要将/consul/data目录挂载到外部存储，这样才能具备故障转移能力。data目录存储了服务信息、节点集群信息。
3.3 服务注册
#注册中心、服务发现
spring.cloud.consul.host=11.4.74.47
spring.cloud.consul.port=800
spring.cloud.consul.discovery.prefer-ip-address=true
spring.cloud.consul.discovery.healthCheckPath=/metrics/health
spring.cloud.consul.discovery.fail-fast=false
spring.cloud.consul.discovery.tags=service
spring.cloud.consul.discovery.instance-id= ${spring.application.name}:${spring.cloud.client.ipAddress}
服务注册接口：http://host:port/v1/agent/service/register
服务实体示例（一般采用spring-cloud-consul-discovery实现）：
{id='order-service-172-18-245-161', name='order-service', tags=[service], address='172.18.245.161', port=8080, enableTagOverride=null, check=Check{script='null', interval='10s', ttl='null', http='http://172.18.245.161:8080/metrics/health', tcp='null', timeout='null', deregisterCriticalServiceAfter='null', tlsSkipVerify=null, status='null'}, checks=null}
注意事项：ID必须唯一，容器化多实例注册的时候最好根据ip自动生成id，保持唯一性
name：服务名
tags设置为service，用于性能监控工具prometheus过滤
check：健康检查策略
3.4 服务发现
http://11.4.74.48:800/v1/health/service/ticket-center
服务发现，简单的说，就是消费者去注册中心上查询注册了哪些服务，服务有多少个实例，哪些是健康的，哪些是不可用的。
服务发现通常结合客户端负载工具ribbon一起使用。
在springboot应用中引入spring-cloud-consul-discovery组件即可，配置参考如下：
# 开启重试
spring.cloud.loadbalancer.retry.enabled=true
# 请求连接的超时时间
ribbon.ConnectTimeout=1000
# 请求处理的超时时间
ribbon.ReadTimeout=10000
# 对所有操作请求都进行重试
ribbon.OkToRetryOnAllOperations=true
#最多重试多少台服务器
ribbon.MaxAutoRetriesNextServer=3
#每台服务器最多重试次数，但是首次调用不包括在内
ribbon.MaxAutoRetries=1
ribbon.httpclient.enabled=false
ribbon.okhttp.enabled=true
ribbon.client.name=dslf
ribbon.NFLoadBalancerRuleClassName=com.netflix.loadbalancer.WeightedResponseTimeRule
注意事项：容错机制非常重要，是服务交互高可靠的保障。
具体代码模板安利一下：
https://github.com/wuzuquan/microservice
3.4 神坑
consul-discovery这个组件实现的服务过滤器有个bug。
当某台consul-server不可用时，在该节点上注册的所有实例皆会被认为不可用。
修复bug详见自定义过滤器：CustomConsulServerFilter
4 开发应用
4.1 通过resttemplate+ribbon实现服务调用
首先往容器内注入定制化的resttemplate
@Primary
@LoadBalanced
@Bean
public RestTemplate restTemplateLB() {
RestTemplate restTemplate= new RestTemplate(OkHttp3Factory());
// RestTemplate restTemplate= new RestTemplate(nettyFactory());
List<HttpMessageConverter<?>> messageConverters = new ArrayList<>();
messageConverters.add(new FormHttpMessageConverter());
messageConverters.add(new StringHttpMessageConverter());
MappingJackson2XmlHttpMessageConverter xmlConverter=new MappingJackson2XmlHttpMessageConverter();
xmlConverter.setDefaultCharset(Charset.forName("utf-8"));
List<MediaType> list = new ArrayList<MediaType>();
list.add(MediaType.APPLICATION_XML);
xmlConverter.setSupportedMediaTypes(list);
messageConverters.add(0,xmlConverter);
messageConverters.add(0,new ProtostuffHttpMessageConverter());
messageConverters.add(0,jsonConverter);
restTemplate.setMessageConverters(messageConverters);
// 把自定义的ClientHttpRequestInterceptor添加到RestTemplate，可添加多个
restTemplate.setInterceptors(Collections.singletonList(new ProtobufHeaderInterceptor()));
return restTemplate;
}
在使用的地方
@Autowired
private RestTemplate restTemplate;
@RequestMapping(value = "/zipkintest")
public String testRibbon(){
return restTemplate.getForObject("http://booking-service/v1/tbempdata/get?id=06645",String.class);
}
5 可用性方面的考量
5.1 消费者与注册中心是什么关系？
服务消费者从注册中心定时同步（5s 10s 15s 策略可以自己配置）服务元数据到本地缓存，之后通过ribbon客户端负载工具直接调其中一个实例，跟注册中心是弱关联关系，即使在运行过程中，consul集群完全不可用，也能继续使用缓存数据。
5.2 当在服务调用的某个瞬间，某个实例不可用咋办，又没有同步更新到最新的服务元数据，此时服务调用会失败吗？
该ribbon工具登场了，ribbon可以配置重试容错机制，每个实例几次，都失败时，重试其他IP。这样就保证了高可用性。
5.3 服务增删实例要怎么操作
不需要操作，不需要人工介入。自动注册，自动健康检查、自动同步。
人是最没用的 😀
5.4 server可用性
挂一台、挂二台、全挂，会造成什么影响
因为微服务是注册到哪个server节点上，就由哪个server节点做健康检查。
5.5 性能如何
官方文档讲的不是很清楚，可以支持几千个node，这里的node是指consul节点。
一个数据中心几千几万个服务应该没什么压力。具体找机会压测
5.6 如何实时获取服务的健康状态
不可能，也不需要
5.7 微服务如何优雅的配置consul地址
假设server节点有3个，若干个client，client是无状态的，负责转发请求，有点类似负载均衡的作用。
spring-cloud客户端只能指定一个地址，有N种方式接入：
1、直接任意指定其中一个server ip
2、在3个server前端架设一个haproxy负载均衡，配置负载均衡的ip地址
3、指定任意一个client的ip
4、指定DNS，例如测试环境中的
consul-server2.2consul-cluster，会解析到服务名对应的server实例
都不优雅，dns会相对好些，但目前rancher的dns性能不是很稳定，压测数据太low。
关键的一点是，保持稳定的ip地址，利用云环境的故障转移，怎么接都是ok的。
测试环境可以用host网络模式，怎么玩都可以，方便测试。
生产环境一定别这么搞，直接用虚拟IP即可，并且要保持IP不变。
5.7.1 consul-template
官方的一个扩展工具，可以配置监听server节点的数据状态，动态更新生成想要的配置文件，例如nginx的upstream，有些mysql集群方案也采用了consul。后续有空再研究吧
