一、前言

对于配置文件，我们并不陌生，它提供我们可以动态修改程序运行能力。引用别人的一句话就是：

系统运行时(runtime)飞行姿态的动态调整！

我可以把我们的工作称之为在快速飞行的飞机上修理零件。我们人类总是无法掌控和预知一切。对于我们系统来说，我们总是需要预留一些控制线条，以便在我们需要的时候做出调整，控制系统方向（如灰度控制、限流调整），这对于拥抱变化的互联网行业尤为重要。

对于单机版，我们称之为配置（文件）；对于分布式集群系统，我们称之为配置中心（系统）;

二、为什么要有分布式配置中心

1、项目背景

我们现在有一个项目，使用SSM进行开发的，配置文件的话我们知道是一个叫做application.properties的文件。

我们也知道这个配置文件会在项目启动的时候被加载到内存中进行使用的。

2、需求一

由于业务的变动，用户在以前进行注册的时候默认的用户名是“小强”，但是新的领导来了，需要把这个改成“小明”。因为，业务的流量还是比较大的，所以，没有办法在白天流量高峰期修改配置文件，进行重启！

此时，就辛苦开发的小哥了，他们需要等到半夜里凌晨三四点的时候，没有流量的时候，小心翼翼的去修改application.properties配置文件，必将系统进行重启。

另外，公司采用的是集群，进行了负载均衡，系统部署在了多台服务器上，那么开发小哥需要一台台的进行修改，小心翼翼的进行修改，生怕出了一点意外！

开发小哥是在忍受不了这种变更了，修改一个配置就需要如此周折的去完成这件事情！忍无可忍，于是像交流群里的一位大神请教，大神指点让他去搜索一下“分布式配置中心”。

3、需求二

我们在进行业务开发的时候，一般会有多个环境，至少应该有三个：开发、测试、线上。那这三个环境之间的配置文件肯定是有不同的，比如说他们之间的数据库是肯定不同的！application.properties例如：

那我们如何使不同环境之间进行隔离哪？答案很简单，不就是指定三个不同的文件，然后在项目启动的时候指定不同的环境不就行了吗？于是开发小哥就动起来了，修改如下：

修改之后，运维的小哥不愿意了！因为，一开始没有进行环境隔离的时候，只有一个环境（开发完成之后，直接修改配置文件，合并到主干，线上发布），运维小哥在使用Jenkins+Git+Maven进行自动化集成的时候，只需要配置一下就行了！在Jenkins启动的脚本命令是：java -jar ssm.jar 就可以搞定了，经开发小哥这样一搞，修改启动的命令不说，新增了环境，还要为他们创建不同环境的自动化集成。

分别需要设置的命令如下：

运维小哥的工作量直接翻了一倍多，想想还有十几个项目需要这样进行修改，运维小哥悄悄的拿起了抽屉里准备了很久的xxx走向了开发小哥。

4、到底什么是分布式配置中心

从上边的两个小需求，我们已经可以看出来，传统配置的方式已经暴露出了很多问题，其他的诸如：历史版本管理，权限控制，安全性等等问题，是传统的配置文件无法解决的！

随着业务的发展、微服务架构的升级，服务的数量、程序的配置日益增多（各种微服务、各种服务器地址、各种参数），传统的配置文件方式和数据库的方式已无法满足开发人员对配置管理的要求：

安全性：配置跟随源代码保存在代码库中，容易造成配置泄漏；
时效性：修改配置，需要重启服务才能生效；
局限性：无法支持动态调整：例如日志开关、功能开关；

因此，我们需要配置中心来统一管理配置！把业务开发者从复杂以及繁琐的配置中解脱出来，只需专注于业务代码本身，从而能够显著提升开发以及运维效率。同时将配置和发布包解藕也进一步提升发布的成功率，并为运维的细力度管控、应急处理等提供强有力的支持。

三、配置的一步步演进

当我们是一个单机服务的是，我们的配置通常写在一个文件中的，代码发布的时候，把配置文件和程序推送到机器上去。

1、单机配置文件

当随着业务的用户量增加，通常我们会把我们的服务进行多机器（集群）部署。这时候，配置的发布就变成了如下：

2、多机器配置

行，这样发配置也能接受，业务的急剧扩张，导致单机服务无法满业务需求。这时候需要对单体大服务进行切开，服务走向SOA(微服务化)。

3、分布式集群部署配置文件

这样去部署配置简直是一场噩梦，而且无法做到快速的动态的调整。失去了配置主要意义之一。这时候就需要今天说的统一配置中心。

三、一个简版的配置中心是什么样的

1、配置中心的特点

配置的增删改查；
不同环境配置隔离（开发、测试、预发布、灰度/线上）；
高性能、高可用性；
请求量多、高并发；
读多写少；

2、简版配置系统

我们可以设计出如下的简版配置中心：

设计说明点：

通过OA系统对每一条配置（每一个配置有唯一的配置ID）进行增删改查；
区分不同环境的配置，每个环境同一配置ID对应不同数据库记录；
配置最终以json格式（便于编辑和理解）储存在mysql数据库中；
引入redis集群，做配置的缓存（比如可以设置配置修改后1分钟后生效）；
配置对外服务，多机器部署，满足性能需要；
如果有必要，可以引入配置历史修改记录；

很多时候，这样可以基本上满足我们对配置系统的基本需求，对配置的增删改查，能容忍一段时间的数据不一致性。

这种设计，由于所有的配置都存放在集中式缓存中，这样集中式的缓存也会有他的性能瓶颈。而且，每次配置的访问都需要发起rpc请求(网络请求)，因此考虑在客户端引入本地缓存（localCache，例如Ehcache）。

四、简版基础上的一些改进

1、配置中心之性能可用性改进

考虑到，减少网络请求的因素，在客户端引入localcache，来解决系统的高可用，高性能、可伸缩性。本地缓存配置中心如下：

相对于第一版的改进点是，在客户端引入localcache。开启线程异步调用配置服务，更新本地配置。

这样可以减少rpc调用。

基于数据的CAP原理，该方式只做到了AP，这里会存在数据的一段时间的不一致性，但最终会保证是配置的最终一致性。如何解决这个数据不一致性问题？

2、配置中心之数据一致性改进

还好，配置通常都只会有一个入口修改，因此可以考虑在配置修改后，通知应用服务清理本地缓存和分布式缓存。这里可以引入mq或ZooKeeper。

最后通过，推拉相结合的方式，完成数据的一致性。

六、开源项目

关于分布式配置中心，网上已经有很多开源的解决方案，例如：

1、Apollo

Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。

项目地址：https://github.com/ctripcorp/apollo

2、XDiamond

全局配置中心，存储应用的配置项，解决配置混乱分散的问题。名字来源于淘宝的开源项目Diamond，前面加上一个字母X以示区别。

项目地址：https://github.com/hengyunabc/xdiamond

3、Qconf

QConf 是一个分布式配置管理工具。用来替代传统的配置文件，使得配置信息和程序代码分离，同时配置变化能够实时同步到客户端，而且保证用户高效读取配置，这使的工程师从琐碎的配置修改、代码提交、配置上线流程中解放出来，极大地简化了配置管理工作。

项目地址：https://github.com/Qihoo360/QConf

4、Disconf

专注于各种「分布式系统配置管理」的「通用组件」和「通用平台」, 提供统一的「配置管理服务」包括百度、滴滴出行、银联、网易、拉勾网、苏宁易购、顺丰科技等知名互联网公司正在使用!「disconf」在「2015 年度新增开源软件排名 TOP 100(OSC开源中国提供)」中排名第16强。Disconf的功能特点描述图：

项目地址：https://github.com/knightliao/disconf

5、Spring Cloud Config

Spring Cloud Config为分布式系统中的外部配置提供服务器和客户端支持。

项目地址：https://github.com/spring-cloud/spring-cloud-config

6、主要区别

如果再有人问你分布式ID，这篇文章丢给他！

1.背景

在我们的业务需求中通常有需要一些唯一的ID，来记录我们某个数据的标识:

某个用户的ID
某个订单的单号
某个信息的ID

通常我们会调研各种各样的生成策略，根据不同的业务，采取最合适的策略，下面我会讨论一下各种策略/算法，以及他们的一些优劣点。

2.UUID

UUID是通用唯一识别码（Universally Unique Identifier)的缩写，开放软件基金会(OSF)规范定义了包括网卡MAC地址、时间戳、名字空间（Namespace）、随机或伪随机数、时序等元素。利用这些元素来生成UUID。

UUID是由128位二进制组成，一般转换成十六进制，然后用String表示。在java中有个UUID类,在他的注释中我们看见这里有4种不同的UUID的生成策略:

randomly: 基于随机数生成UUID，由于Java中的随机数是伪随机数，其重复的概率是可以被计算出来的。这个一般我们用下面的代码获取基于随机数的UUID:
time-based:基于时间的UUID,这个一般是通过当前时间，随机数，和本地Mac地址来计算出来，自带的JDK包并没有这个算法的我们在一些UUIDUtil中，比如我们的log4j.core.util，会重新定义UUID的高位和低位。
DCE security:DCE安全的UUID。
name-based：基于名字的UUID，通过计算名字和名字空间的MD5来计算UUID。

UUID的优点:

通过本地生成，没有经过网络I/O，性能较快
无序，无法预测他的生成顺序。(当然这个也是他的缺点之一)

UUID的缺点:

128位二进制一般转换成36位的16进制，太长了只能用String存储，空间占用较多。
不能生成递增有序的数字

适用场景:UUID的适用场景可以为不担心过多的空间占用，以及不需要生成有递增趋势的数字。在Log4j里面他在UuidPatternConverter中加入了UUID来标识每一条日志。

3.数据库主键自增

大家对于唯一标识最容易想到的就是主键自增，这个也是我们最常用的方法。例如我们有个订单服务，那么把订单id设置为主键自增即可。

优点:

简单方便，有序递增，方便排序和分页

缺点:

分库分表会带来问题，需要进行改造。
并发性能不高，受限于数据库的性能。
简单递增容易被其他人猜测利用，比如你有一个用户服务用的递增，那么其他人可以根据分析注册的用户ID来得到当天你的服务有多少人注册，从而就能猜测出你这个服务当前的一个大概状况。
数据库宕机服务不可用。

适用场景:
根据上面可以总结出来，当数据量不多，并发性能不高的时候这个很适合，比如一些to B的业务，商家注册这些，商家注册和用户注册不是一个数量级的，所以可以数据库主键递增。如果对顺序递增强依赖，那么也可以使用数据库主键自增。

4.Redis

熟悉Redis的同学，应该知道在Redis中有两个命令Incr，IncrBy,因为Redis是单线程的所以能保证原子性。

优点：

性能比数据库好，能满足有序递增。

缺点：

由于redis是内存的KV数据库，即使有AOF和RDB，但是依然会存在数据丢失，有可能会造成ID重复。
依赖于redis，redis要是不稳定，会影响ID生成。

适用：由于其性能比数据库好，但是有可能会出现ID重复和不稳定，这一块如果可以接受那么就可以使用。也适用于到了某个时间，比如每天都刷新ID，那么这个ID就需要重置，通过(Incr Today)，每天都会从0开始加。

5.Zookeeper

利用ZK的Znode数据版本如下面的代码，每次都不获取期望版本号也就是每次都会成功，那么每次都会返回最新的版本号:

Zookeeper这个方案用得较少，严重依赖Zookeeper集群，并且性能不是很高，所以不予推荐。

6.数据库分段+服务缓存ID

这个方法在美团的Leaf中有介绍，详情可以参考美团技术团队的发布的技术文章:Leaf——美团点评分布式ID生成系统,这个方案是将数据库主键自增进行优化。

biz_tag代表每个不同的业务，max_id代表每个业务设置的大小，step代表每个proxyServer缓存的步长。
之前我们的每个服务都访问的是数据库，现在不需要，每个服务直接和我们的ProxyServer做交互，减少了对数据库的依赖。我们的每个ProxyServer回去数据库中拿出步长的长度，比如server1拿到了1-1000,server2拿到来 1001-2000。如果用完会再次去数据库中拿。

优点:

比主键递增性能高，能保证趋势递增。
如果DB宕机，proxServer由于有缓存依然可以坚持一段时间。

缺点:

和主键递增一样，容易被人猜测。
DB宕机，虽然能支撑一段时间但是仍然会造成系统不可用。

适用场景:需要趋势递增，并且ID大小可控制的，可以使用这套方案。

当然这个方案也可以通过一些手段避免被人猜测，把ID变成是无序的，比如把我们生成的数据是一个递增的long型，把这个Long分成几个部分，比如可以分成几组三位数，几组四位数，然后在建立一个映射表，将我们的数据变成无序。

7.雪花算法-Snowflake

Snowflake是Twitter提出来的一个算法，其目的是生成一个64bit的整数:

1bit:一般是符号位，不做处理
41bit:用来记录时间戳，这里可以记录69年，如果设置好起始时间比如今年是2018年，那么可以用到2089年，到时候怎么办？要是这个系统能用69年，我相信这个系统早都重构了好多次了。
10bit:10bit用来记录机器ID，总共可以记录1024台机器，一般用前5位代表数据中心，后面5位是某个数据中心的机器ID
12bit:循环位，用来对同一个毫秒之内产生不同的ID，12位可以最多记录4095个，也就是在同一个机器同一毫秒最多记录4095个，多余的需要进行等待下毫秒。

上面只是一个将64bit划分的标准，当然也不一定这么做，可以根据不同业务的具体场景来划分，比如下面给出一个业务场景：

服务目前QPS10万，预计几年之内会发展到百万。
当前机器三地部署，上海，北京，深圳都有。
当前机器10台左右，预计未来会增加至百台。

这个时候我们根据上面的场景可以再次合理的划分62bit,QPS几年之内会发展到百万，那么每毫秒就是千级的请求，目前10台机器那么每台机器承担百级的请求，为了保证扩展，后面的循环位可以限制到1024，也就是2^10，那么循环位10位就足够了。

机器三地部署我们可以用3bit总共8来表示机房位置，当前的机器10台，为了保证扩展到百台那么可以用7bit 128来表示，时间位依然是41bit,那么还剩下64-10-3-7-41-1 = 2bit,还剩下2bit可以用来进行扩展。

适用场景:当我们需要无序不能被猜测的ID，并且需要一定高性能，且需要long型，那么就可以使用我们雪花算法。比如常见的订单ID，用雪花算法别人就发猜测你每天的订单量是多少。

7.1一个简单的Snowflake

public class IdWorker{

    private long workerId;
    private long datacenterId;
    private long sequence = 0;
    /**
     * 2018/9/29日，从此时开始计算，可以用到2089年
     */
    private long twepoch = 1538211907857L;

    private long workerIdBits = 5L;
    private long datacenterIdBits = 5L;
    private long sequenceBits = 12L;

    private long workerIdShift = sequenceBits;
    private long datacenterIdShift = sequenceBits + workerIdBits;
    private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
    // 得到0000000000000000000000000000000000000000000000000000111111111111
    private long sequenceMask = -1L ^ (-1L << sequenceBits);

    private long lastTimestamp = -1L;


    public IdWorker(long workerId, long datacenterId){
        this.workerId = workerId;
        this.datacenterId = datacenterId;
    }
    public synchronized long nextId() {
        long timestamp = timeGen();
        //时间回拨，抛出异常
        if (timestamp < lastTimestamp) {
            System.err.printf("clock is moving backwards.  Rejecting requests until %d.", lastTimestamp);
            throw new RuntimeException(String.format("Clock moved backwards.  Refusing to generate id for %d milliseconds",
                    lastTimestamp - timestamp));
        }

        if (lastTimestamp == timestamp) {
            sequence = (sequence + 1) & sequenceMask;
            if (sequence == 0) {
                timestamp = tilNextMillis(lastTimestamp);
            }
        } else {
            sequence = 0;
        }

        lastTimestamp = timestamp;
        return ((timestamp - twepoch) << timestampLeftShift) |
                (datacenterId << datacenterIdShift) |
                (workerId << workerIdShift) |
                sequence;
    }

    /**
     * 当前ms已经满了
     * @param lastTimestamp
     * @return
     */
    private long tilNextMillis(long lastTimestamp) {
        long timestamp = timeGen();
        while (timestamp <= lastTimestamp) {
            timestamp = timeGen();
        }
        return timestamp;
    }

    private long timeGen(){
        return System.currentTimeMillis();
    }

    public static void main(String[] args) {
        IdWorker worker = new IdWorker(1,1);
        for (int i = 0; i < 30; i++) {
            System.out.println(worker.nextId());
        }
    }

}

上面定义了雪花算法的实现，在nextId中是我们生成雪花算法的关键。

7.2防止时钟回拨

因为机器的原因会发生时间回拨，我们的雪花算法是强依赖我们的时间的，如果时间发生回拨，有可能会生成重复的ID，在我们上面的nextId中我们用当前时间和上一次的时间进行判断，如果当前时间小于上一次的时间那么肯定是发生了回拨，普通的算法会直接抛出异常,这里我们可以对其进行优化,一般分为两个情况:

如果时间回拨时间较短，比如配置5ms以内，那么可以直接等待一定的时间，让机器的时间追上来。
如果时间的回拨时间较长，我们不能接受这么长的阻塞等待，那么又有两个策略:

直接拒绝，抛出异常，打日志，通知RD时钟回滚。
利用扩展位，上面我们讨论过不同业务场景位数可能用不到那么多，那么我们可以把扩展位数利用起来了，比如当这个时间回拨比较长的时候，我们可以不需要等待，直接在扩展位加1。2位的扩展位允许我们有3次大的时钟回拨，一般来说就够了，如果其超过三次我们还是选择抛出异常，打日志。

通过上面的几种策略可以比较的防护我们的时钟回拨，防止出现回拨之后大量的异常出现。下面是修改之后的代码，这里修改了时钟回拨的逻辑:

最后

本文分析了各种生产分布式ID的算法的原理，以及他们的适用场景，相信你已经能为自己的项目选择好一个合适的分布式ID生成策略了。没有一个策略是完美的，只有适合自己的才是最好的。

为什么要有分布式配置中心