為什麼要有分散式配置中心

阿新 • • 發佈：2018-11-12

一、前言

對於配置檔案，我們並不陌生，它提供我們可以動態修改程式執行能力。引用別人的一句話就是：

系統執行時(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生成策略了。沒有一個策略是完美的，只有適合自己的才是最好的。