分佈式 配置中心

配置

配置(Configuration) 這個概念每一個技術人都不陌生，能夠說一個不提供幾個配置參數的系統都很差意思上線跟別的系統打招呼。

究其本質是咱們人類沒法掌控和預知一切，映射到軟件領域上，咱們老是須要對系統的某些功能特性預留出一些控制的線頭，以便咱們在將來須要的時候，能夠人爲的撥弄這些線頭從而控制系統的行爲特徵，我把它叫作 「系統運行時(runtime)飛行姿態的動態調整「。

靜態配置

咱們的系統存在一些外部依賴，這些依賴與業務無關，可是在開發階段具備不肯定性，咱們一般會將這些配置在屬性文件中，如數據庫url,帳戶名，密碼,等，這些配置項基本不會輕易改變，並且配置也簡單，基本都是字符串，因此稱他們爲靜態配置

所謂靜態配置，就是在程序啓動前一次性配好，啓動時一次性生效，在程序運行期通常不會變化的配置。

具體包括：

• 環境相關配置

有些配置是和環境相關的，每一個環境的配置不同，例如數據庫、中間件和其它服務的鏈接字符串配置。這些配置一次性配好，運行期通常不變。

• 安全配置

有些配置和安全相關，例如用戶名，密碼，訪問令牌，許可證書等，這些也是一次性配好，運行期通常不變。由於涉及安全，相關信息通常須要加密存儲，對配置訪問須要權限控制。

動態配置

​ 咱們在業務開發中，會提早預料到業務的不肯定性，而產生的複雜的業務配置項，類型簡單的可使數字，字符，複雜點的能夠是數組，map，以及其混合的組織形式，因爲業務需求，會須要經常發生改變，這類配置項，咱們稱爲動態配置。

所謂動態配置，就是在程序的運行期能夠根據須要動態調整的配置。動態配置讓應用行爲和功能的調整變得更加靈活，是持續交付和 DevOps 的最佳實踐。

• 2.1 應用配置

和應用相關的配置，例如服務請求超時，線程池和隊列的大小，緩存過時時間，數據庫鏈接池的容量，日誌輸出級別，限流熔斷閥值，服務安全黑白名單等。通常開發或者運維會根據應用的實際運行狀況調整這些配置。

• 2.2 業務配置

和業務相關的一些配置，例如促銷規則，貸款額度，利率等業務參數，A/B 測試參數等。通常產品運營或開發人員會根據實際的業務需求，動態調整這些參數。

• 2.3 功能開關

在英文中也稱 Feature Flag/Toggle/Switch，簡單的只有真假兩個值，複雜的能夠是多值參數。功能開關是 DevOps 的一種最佳實踐，在運維中有不少應用場景，好比藍綠部署，灰度開關，降級開關，主備切換開關，數據庫遷移開關等。功能開關在國外互聯網公司用得比較多，國內尚未普及開，因此我在下一節會給出一些功能開關的高級應用場景。

爲何要有配置中心呢

在單機時代，咱們都是用配置文件來存儲配置項。一個配置文件通常是一組配置項的集合或者叫配置集，一個系統根據邏輯模塊劃分，能夠有1到多個配置文件。

在集中式開放時代，配置文件基本夠用了，由於那是配置的管理一般不會成爲一個很大的問題。若是要修改一個配置，登陸到這臺機器上，登陸到這臺生產機器上，vi配置這個配置文件，而後reload一下並非很大的負擔。

在分佈式系統中，一次構建、發佈、上線是很是很是重的一個過程，它不像單機時代那樣重啓一臺機器、一個進程就能夠了。

時效性

在分佈式系統中，它涉及到將軟件包(例如war)分發到可能超過幾千臺機器，而後將幾千臺機器上的應用進程一一重啓這麼一個過程，超過2000臺機器的一個應用一次完整的發佈過程須要多長時間，相信你們都必定會清楚，因此從時效性上來講，配置中心是勢在必行。

統一管理

分發到幾千臺機器上，誰能保證幾千次配置都會一致，不會有哪一個人手誤致使文件更改有錯誤，因此有一個應用統一管理管理配置，以後其餘應用須要更改本地配置的時候，來向配置中心拉取，以後替換配置，以後從新發布就行了，這樣就能保證全部機器上的配置的都一致。

分佈式三項原則

在分佈式計算技術的設計和實現中，CAP理論是一個重要的指導原則，其基本內容以下：

一、「C」是指一致性，即當一個Process（過程）修改了某個數據後，其餘Process讀取這是數據是，獲得的是更新後的數據，但並非全部系統都 能夠作到這一點。例如，在一些並不是嚴格要求一致性的系統中，後來的Process獲得的數據可能仍是修改以前的數據，或者須要等待必定時間後才能獲得修改 以後的數據，這被成爲「弱一致性」，最經典的應用就是DNS系統。當用戶修改了DNS配置後，每每不會立刻在全網更新，一定會有一個延遲，這個延遲被稱爲 「不一致窗口」，它的長度取決於系統的負載、冗餘的個數等因素。但對於某些系統而言，一旦寫入，後面讀取的必定是修改後的數據，如銀行帳戶信息，這被稱爲 「強一致性」。

二、「A」是指可用性。即系統老是可以爲用戶提供連續的服務能力。當用戶發出請求是，系統能給出響應（成功或者失敗），並且是當即給出響應，而不是等待其餘事情完成才響應。若是須要等待某件事情完成才響應，那麼「可用性」就不存在了。

三、「P」是指容錯性。任何一個分佈式計算系統都是由多個節點組成的。在正常狀況下，節點與節點之間的通訊是正常的。可是在某些狀況下，節點之間的通訊會 斷開，這種斷開成爲「Partition」。在分佈式計算的實現中，Partition是很常見的，由於節點不可能永遠不出故障，尤爲是對於跨物理地區的 海量存儲系統而言，而容錯性則能夠保證若是隻是系統中的部分節點不可用，那麼相關的操做仍舊可以正常完成。

演進中的配置中心

通過上面的內容，你們知道確定要有一個配置中心來統一管理，經過配置中心繫統對每一條配置（每個配置有惟一的配置ID）進行增刪改查。區分不一樣環境的配置，每一個環境同一配置ID對應不一樣數據庫記錄。配置最終以key-value儲存在mysql數據庫中。

1.

能夠有一個配置中心，經過配置中心對每一條配置進行增刪改查，配置最終以key-value儲存在mysql數據庫,配置對外服務，多機器部署，知足性能須要。應用直接去調用配置中心提供的接口查詢配置，這樣可能對數據庫壓力太大，這樣的話能夠在配置中心添加緩存，每次查詢緩存，這樣的話每次查詢的時候，就不會調用數據庫，每次可用直接查詢緩存，每次更改配置的時候，順便更改緩存，這樣能保證可用性和一致性。

不少時候，這樣能夠基本上知足咱們對配置系統的基本需求，對配置的增刪改查，能容忍一段時間的數據不一致性。

這種設計，因爲全部的配置都存放在集中式緩存中，這樣集中式的緩存也會有他的性能瓶頸。並且，每次配置的訪問都須要發起rpc請求(網絡請求)，所以考慮在客戶端引入本地緩存（localCache，例如Ehcache）。

2.

能在服務端使用緩存，爲何不能再客戶端使用緩存呢。

使用客戶端緩存，那麼緩存存在哪呢？

在客戶端使用緩存能夠分紅三種，分佈式緩存，內存和硬盤。

可是這三種各有利弊。

分佈式緩存 那麼網絡資源的耗費沒有獲得節約，可是能夠保證應用讀取的配置一致性的保證。

內存 不用耗費網絡資源，很快，可是重啓會丟失配置

硬盤 不用耗費網絡資源，不會丟失配置，相對來講會慢一些

考慮到，減小網絡請求的因素，在客戶端引入localcache，雖然內存和硬盤能夠節省網絡資源，可是內存和硬盤都存在各自的缺點，那麼咱們能夠採用內存+硬盤的格式，把資源保存再硬盤裏，每次重啓時在從硬盤中讀取以後加載到內存中。這樣的話來解決系統的高可用，高性能、可伸縮性。

一致性的話的咱們能夠採用縮短更新緩存的問題來解決。也能夠經過配置中心通知應用配置更新，應用從配置中心拉取最新的配置、更新本地配置並通知到應用。

php與配置中心

與c#、Java、Go、Python、Node.JS等等應用不一樣，php的程序不支持常駐內存，php每處理完一個請求後，資源都會被釋放掉；這也就意味着若是咱們在請求進來時，都須要去訪問配置中心得到各類配置信息。

由於配置中心是外部程序，每次訪問都是跨進程通信；假設獲取一個配置須要耗時1ms，那麼一百項配置就是0.1s；這是巨大的潛在性能影響。

由於php的動態性，咱們可使用動態生成php文件的形式來作緩存。咱們也可使用相似 confd這樣的工具作去監控watch配置中心中各個值。在值發生變動時，便觸發腳本去刪除掉緩存文件，那麼下次程序再調用 get_key函數時，便會自動去配置中心得到新值，並從新緩存。