微服務化改造系列之三：配置中心

前情概要：

• 微服務化改造系列之一：總覽

• 微服務化改造系列之二：服務註冊中心

配置中心概述

這篇文章是微服務化改造系列的第三篇，主題是配置中心。上一篇咱們談到服務註冊中心，即經過提供某種註冊和發現的機制，解決服務互通的問題。那麼問題來了，一個服務如何知道服務註冊中心的地址呢？這就涉及到服務配置了。咱們知道，大至一個PaaS平臺，小至一個緩存框架，通常都依賴於特定的配置以正常提供服務，微服務也不例外。

配置分類

• 按配置的來源劃分，主要有源代碼（俗稱hard-code），文件，數據庫和遠程調用。

• 按配置的適用環境劃分，可分爲開發環境，測試環境，預發佈環境，生產環境等。

• 按配置的集成階段劃分，可分爲編譯時，打包時和運行時。編譯時，最多見的有兩種，一是源代碼級的配置，二是把配置文件和源代碼一塊兒提交到代碼倉庫中。打包時，即在應用打包階段經過某種方式將配置（通常是文件形式）打入最終的應用包中。運行時，是指應用啓動前並不知道具體的配置，而是在啓動時，先從本地或者遠程獲取配置，而後再正常啓動。

• 按配置的加載方式劃分，可分爲單次加載型配置和動態加載型配置。

演變

隨着業務複雜度的上升和技術架構的演變，對應用的配置方式也提出了愈來愈高的要求。一個典型的演變過程每每是這樣的，起初全部配置跟源代碼一塊兒放在代碼倉庫中；以後出於安全性的考慮，將配置文件從代碼倉庫中分離出來，或者放在CI服務器上經過打包腳本打入應用包中，或者直接放到運行應用的服務器的特定目錄下，剩下的非文件形式的關鍵配置則存入數據庫中。上述這種方式，在單體應用階段很是常見，也每每能夠運行的很好，但到了微服務階段，面對爆發式增加的應用數量和服務器數量，就顯得無能爲力了。這時，就輪到配置中心大顯身手了。那什麼是配置中心？簡單來講，就是一種統一管理各類應用配置的基礎服務組件。

可選框架

選型一個合格的配置中心，至少須要知足以下4個核心需求：

• 非開發環境下應用配置的保密性，避免將關鍵配置寫入源代碼

• 不一樣部署環境下應用配置的隔離性，好比非生產環境的配置不能用於生產環境

• 同一部署環境下的服務器應用配置的一致性，即全部服務器使用同一份配置

• 分佈式環境下應用配置的可管理性，即提供遠程管理配置的能力

如今開源社區主流的配置中心框架有Spring Cloud Config和disconf，二者都知足了上述4個核心需求，但又有所區別。

Spring Cloud Config

Spring Cloud Config能夠說是一個爲Spring量身定作的輕量級配置中心，巧妙的將應用運行環境映射爲profile，應用版本映射爲label。在服務端，基於特定的外部系統（Git、文件系統或者Vault）存儲和管理應用配置；在客戶端，利用強大的Spring配置系統，在運行時加載應用配置。

disconf

disconf是前百度資深研發工程師廖綺綺的開源做品。在服務端，提供了完善的操做界面管理各類運行環境，應用和配置文件；在客戶端，深度集成Spring，經過Spring AOP實現應用配置的自動加載和刷新。

方案選型

不論是Spring Cloud Config仍是disconf，默認提供的客戶端都深度綁定了Spring框架，這對非Spring應用而言無疑增長了集成成本，即使它們都提供了獲取應用配置的API。最終咱們仍是選用了微服務化改造以前自研的Matrix做爲配置中心，一方面，能夠保持新老系統使用同一套配置服務，下降維護成本，另外一方面，在知足4個核心需求的前提下，Matrix還提供了一些獨有的能力。

• 分離配置文件和配置項。對於配置文件，經過各種配套打包插件（sbt, maven, gradle），在打包時將配置文件打入應用包中，同時最小化對CI的侵入性；對於配置項，提供SDK，幫助應用從服務端獲取配置項，同時支持簡單的緩存機制。

• 增長應用版本維度，即對於同一應用，能夠在服務端針對不一樣版本或版本區間維護不一樣的應用配置。

• 應用配置的版本化支持，相似於Git，能夠將任一應用配置回退到任一歷史版本。

進一步信息可參考我以前寫的Matrix設計文檔。

Matrix架構圖

下一篇我將給你們介紹微服務架構的另外一個基礎組件——受權中心，敬請期待！

參考

• Spring Cloud Config

• disconf

• Matrix