consul 日志配置_consul配置与实战

上一篇提到，项目用的分布式服务发现与注册组件是consul，这篇文章主要来讲下consul组件在项目中的应用以及相关介绍。本文以官方文档为主要参考consul文档。

1. consul介绍

consul是一个服务管理软件，主要功能如下：

支持多数据中心下，分布式高可用的，服务发现和配置共享。

consul支持健康检查，允许存储键值对。

一致性协议采用Raft算法,用来保证服务的高可用。

成员管理和消息广播采用GOSSIP协议，支持ACL访问控制。

1.1 服务注册与发现

服务注册是一个服务将其位置信息在“中心注册节点”注册的过程。该服务一般会将它的主机IP地址以及端口号进行注册，有时也会有服务访问的认证信息，使用协议，版本号，以及关于环境的一些细节信息。

而服务发现可以让一个应用或者组件发现其运行环境以及其它应用或组件的信息。用户配置一个服务发现工具就可以将实际容器跟运行配置分离开。常见配置信息包括：ip、端口号、名称等。

在传统情况下，当出现服务存在于多个主机节点上时，都会使用静态配置的方法来实现服务信息的注册。

而当在一个复杂的系统里，需要较强的可扩展性时，服务被频繁替换时，为避免服务中断，动态的服务注册和发现就很重要。

服务注册与发现的组件有很多，如Zookeeper、Etcd等。既可用于服务间的协调，同时又可用于服务的注册。

1.2 Consensus Protocol - Raft

Consul使用Consensus协议Raft提供一致性(Consistency)。本文只是简单介绍在consul中的一致性，后面专门一篇写raft。

raft算法

首先，Raft是一种基于Paxos的Consensus算法。相比于Paxos，Raft设计采用了较少的状态，并且是一种更简单、更易于理解的算法。

只有Server节点参与Raft，且是peer set的一员。所有的Client节点只是转发请求到Server。这种设计的考虑是，当更多的成员加入到peer set中时，quorum的规模也会增加。可能会导致性能问题是等待quorum个节点log entry。

启动Consul时，单个consul节点需要以bootstrap模式运行，该模式运行自我选举为leader。一旦Leader被选出来，其他Server可以添加Peer set中，保持一致性和安全性。最终一些Server添加到集群，bootstrap模式需要禁用。

因为所有Server都是Peer set中的成员，它们都知道谁是Leader。当一个RPC请求到达某个非Leader Server节点，请求就会被转发到Leader。如果RPC是一种query类型，这意味着它是只读的，Leader会基于FSM当前生成相应的结果，如果RPC是一种transaction类型，即修改状态，Leader产生一个新的日志条目，并基于Raft算法进行管理。一旦日志条目应用于有限状态机，transaction完成。

由于Raft的replication性质&#x