配置中心組件調研報告
| 功能 | Apollo | Nacos |
|---|---|---|
| 開源時間 | 2016.5 | 2018 |
| 版本管理 | 支持 | 支持 |
| 配置回滾 | 支持 | 支持 |
| 配置實時推送 | 支持（HTTP長輪詢1S內） | 支持（HTTP長輪詢1S內） |
| 灰度發布 | 支持 | 不支持 |
| 權限管理 | 支持 | 不支持 |
| 多集群 | 支持 | 支持 |
| 多環境 | 支持 | 支持 |
| 監聽查詢 | 支持 | 支持 |
| 多語言SDK | Java、Python、C、Go、NodeJs、PHP、OpenAPI | Java、Python、C#、Go、NodeJs、OpenAPI |
| 單機部署 | Apollo-all + MySQL | Nacos + MySQL（可選） |
| 分布式部署 | Config（2）+ Admin（2） + Portal（1） + MySQL | Nacos（3）+ MySQL |
| 配置格式校驗 | 支持 | 支持 |
| 通信協議 | HTTP | HTTP |
| 數據一致性 | 數據庫模擬消息隊列，Apollo定時讀取消息 | HTTP異步通知 |
前言
隨着程序功能的日益復雜，程序的配置日益增多：各種功能的開關、參數的配置、服務器的地址……
對程序配置的期望值也越來越高：配置修改后實時生效，灰度發布，分環境、分集群管理配置，完善的權限、審核機制……
在這樣的大環境下，傳統的通過配置文件、數據庫等方式已經越來越無法滿足開發人員對配置管理的需求。
配置中心應運而生！
1、硬編碼
沒有什么配置不配置的，直接寫在代碼里面，比如使用常量類
優勢：對開發友好，開發清楚地知道代碼需要用到什么配置
劣勢：涉及秘鑰等敏感配置直接暴露給開發人員，不安全；如果想修改配置必須重新發版，比較麻煩
2、外部化配置文件
Spring項目經常會在resoures目錄下放很多配置文件，各個環境對應不同的配置文件，通過SVN管理
優勢：配置文件外部化，支持多環境配置管理，修改配置只需重啟服務，無需發版
劣勢：系統龐大時，配置文件很多，多人開發，配置格式不統一，維護麻煩；敏感配置不需要暴露給開發人員，降低風險，但開發經常要和運維溝通怎么修改配置，溝通不恰當容易引發生產事故；而且，如果應用部署在多台機器，對運維來說，修改配置也是非常頭疼的事情（當然也可以引入NFS系統來解決一部分問題）
3、數據庫
配置信息存儲在數據庫中，靈活修改
優勢：可以靈活管理配置，無需重啟服務
劣勢：界面不友好，配置沒有版本管理，一旦出現問題，回滾或定位問題都比較麻煩；此外，數據庫必須要保證高可用，避免因此而造成生產故障
4、配置中心
微服務基礎架構體系中的一個不可或缺的基礎組件
優勢：集中化管理，敏感配置可控；多版本存儲，方便追溯；界面友好，修改配置一鍵發布；即使面對多集群也能從容應對，十分淡定
劣勢：引入組件，增加系統風險；如果是中途切換成配置中心，也會增加研發接入成本；配置中心也需要保證高可用，否則容易造成大面積影響
以上幾種管理配置文件的方式，我想都會有公司在用，不要因為配置中心有諸多優點，就盲目引進項目中，我覺得應該遵守以下兩個原則：
- 做人做事，要知道自己幾斤幾兩
釋義：沒深入研究過的技術，就不要隨便拿到公司項目中來試水啦，恐怕到時候坑夠你填的，要不然就是你有信心玩得轉它。
- 殺只雞而已，你拿牛刀來做甚？
釋義：小團隊小項目選擇簡單的配置管理方式就好了，要什么配置中心，純屬沒事找事。
總而言之，我們必須從實際出發，實事求是，選擇適合自己的技術棧。
目前
當下我們的各個項目是獨立的，各自的配置自行管理，缺少規范的權限、流程治理、以及不同版本的管理、回滾等。
Apollo
簡介
Apollo（阿波羅）是一款可靠的分布式配置管理中心，是由攜程開源的一個項目，能夠集中化管理應用不同環境、不同集群的配置，配置修改后能夠實時推送到應用端，並且具備規范的權限、流程治理等特性，適用於微服務配置管理場景。
Apollo支持4個維度管理Key-Value格式的配置：
- application (應用)
- environment (環境)
- cluster (集群)
- namespace (命名空間)
GitHub地址
GitHub - apolloconfig Start 26.1k
Demo地址
apollo/admin
同時，Apollo基於開源模式開發，開源地址：https://github.com/ctripcorp/apollo
架構圖
客戶端
下圖簡要描述了Apollo客戶端的實現原理：
- 客戶端和服務端保持了一個長連接，從而能第一時間獲得配置更新的推送。（通過Http Long Polling實現）
- 客戶端還會定時從Apollo配置中心服務端拉取應用的最新配置。
- 這是一個fallback機制，為了防止推送機制失效導致配置不更新
- 客戶端定時拉取會上報本地版本，所以一般情況下，對於定時拉取的操作，服務端都會返回304 - Not Modified
- 定時頻率默認為每5分鍾拉取一次，客戶端也可以通過在運行時指定System Property:
apollo.refreshInterval來覆蓋，單位為分鍾。
- 客戶端從Apollo配置中心服務端獲取到應用的最新配置后，會保存在內存中
- 客戶端會把從服務端獲取到的配置在本地文件系統緩存一份
- 在遇到服務不可用，或網絡不通的時候，依然能從本地恢復配置
- 應用程序可以從Apollo客戶端獲取最新的配置、訂閱配置更新通知
模塊架構
單環境
如果Linux Server 1宕機時，client就只能讀取本地磁盤上的config-cache了
分布式
- Portal部署在生產環境的機房，通過它來直接管理FAT、UAT、PRO等環境的配置
- Meta Server、Config Service和Admin Service在每個環境都單獨部署，使用獨立的數據庫
- Meta Server、Config Service和Admin Service在生產環境部署在兩個機房，實現雙活
- Meta Server和Config Service部署在同一個JVM進程內，Admin Service部署在同一台服務器的另一個JVM進程內
功能特性介紹
創建項目
要使用Apollo，第一步需要創建項目。
- 打開apollo-portal主頁
- 點擊“創建項目”
- 輸入項目信息
- 部門：選擇應用所在的部門
- 應用AppId：用來標識應用身份的唯一id，格式為string，需要和客戶端app.properties中配置的app.id對應
- 應用名稱：應用名，僅用於界面展示
- 應用負責人：選擇的人默認會成為該項目的管理員，具備項目權限管理、集群創建、Namespace創建等權限
-
點擊提交
創建成功后，會自動跳轉到項目首頁
項目權限分配
項目管理員權限
項目管理員擁有以下權限：
- 可以管理項目的權限分配
- 可以創建集群
- 可以創建Namespace
創建項目時填寫的應用負責人默認會成為項目的管理員之一，如果還需要其他人也成為項目管理員，可以按照下面步驟操作：
- 點擊頁面左側的“管理項目”
- 搜索需要添加的成員並點擊添加
配置編輯、發布權限
配置權限分為編輯和發布：
- 編輯權限允許用戶在Apollo界面上創建、修改、刪除配置
- 配置修改后只在Apollo界面上變化，不會影響到應用實際使用的配置
- 發布權限允許用戶在Apollo界面上發布、回滾配置
- 配置只有在發布、回滾動作后才會被應用實際使用到
- Apollo在用戶操作發布、回滾動作后實時通知到應用，並使最新配置生效
項目創建完，默認沒有分配配置的編輯和發布權限，需要項目管理員進行授權。
- 點擊application這個namespace的授權按鈕
- 分配修改權限
- 分配發布權限
添加配置項
編輯配置需要擁有這個Namespace的編輯權限，如果發現沒有新增配置按鈕，可以找項目管理員授權。
通過表格模式添加配置
- 點擊新增配置
- 輸入配置項
- 點擊提交
通過文本模式編輯
Apollo除了支持表格模式，逐個添加、修改配置外，還提供文本模式批量添加、修改。 這個對於從已有的properties文件遷移尤其有用。
- 切換到文本編輯模式
- 點擊右側的修改配置按鈕
- 輸入配置項，並點擊提交修改
發布配置
配置只有在發布后才會真的被應用使用到，所以在編輯完配置后，需要發布配置。
發布配置需要擁有這個Namespace的發布權限，如果發現沒有發布按鈕，可以找項目管理員授權。
- 點擊“發布按鈕”
- 填寫發布相關信息，點擊發布
應用讀取配置
配置發布成功后，應用就可以通過Apollo客戶端讀取到配置了。
Apollo目前提供Java客戶端，具體信息請點擊Java客戶端使用文檔：
如果應用使用了其它語言，也可以通過直接訪問Http接口獲取配置，具體可以參考其它語言客戶端接入指南
回滾已發布配置
如果發現已發布的配置有問題，可以通過點擊『回滾』按鈕來將客戶端讀取到的配置回滾到上一個發布版本。
這里的回滾機制類似於發布系統，發布系統中的回滾操作是將部署到機器上的安裝包回滾到上一個部署的版本，但代碼倉庫中的代碼是不會回滾的，從而開發可以在修復代碼后重新發布。
Apollo中的回滾也是類似的機制，點擊回滾后是將發布到客戶端的配置回滾到上一個已發布版本，也就是說客戶端讀取到的配置會恢復到上一個版本，但頁面上編輯狀態的配置是不會回滾的，從而開發可以在修復配置后重新發布。
Nacos
簡介
是阿里巴巴推出來的一個新開源項目，這是一個更易於構建雲原生應用的動態服務發現、配置管理和服務管理平台。致力於發現、配置和管理微服務。 Nacos 提供了一組簡單易用的特性集，實現動態服務發現、服務配置、服務元數據及流量管理。
架構圖
整體架構分為用戶層、業務層、內核層和插件，用戶層主要解決用戶使用的易用性問題，業務層主要解決服務發現和配置管理的功能問題，內核層解決分布式系統一致性、存儲、高可用等核心問題，插件解決擴展性問題。
用戶層
-
OpenAPI：暴露標准Rest風格HTTP接口，簡單易用，方便多語言集成
-
Console：易用控制台，做服務管理、配置管理等操作
-
SDK：多語言 SDK，目前幾乎支持所有主流編程語言
-
Agent：Sidecar 模式運行，通過標准 DNS 協議與業務解耦
-
CLI：命令行對產品進行輕量化管理，像 git 一樣好用
業務層
-
服務管理：實現服務 CRUD，域名 CRUD，服務健康狀態檢查，服務權重管理等功能
-
配置管理：實現配置管 CRUD，版本管理，灰度管理，監聽管理，推送軌跡，聚合數據等功能
-
元數據管理：提供元數據 CURD 和打標能力，為實現上層流量和服務灰度非常關鍵
內核層
-
插件機制：實現三個模塊可分可合能力，實現擴展點 SPI 機制，用於擴展自己公司定制
-
事件機制：實現異步化事件通知，SDK 數據變化異步通知等邏輯，是Nacos高性能的關鍵部分
-
日志模塊：管理日志分類，日志級別，日志可移植性（尤其避免沖突），日志格式，異常碼+幫助文檔
-
回調機制：SDK 通知數據，通過統一的模式回調用戶處理。接口和數據結構需要具備可擴展性
-
尋址模式：解決 Server IP 直連，域名訪問，Nameserver 尋址、廣播等多種尋址模式，需要可擴展
-
推送通道：解決 Server 與存儲、Server 間、Server 與 SDK 間高效通信問題
-
容量管理：管理每個租戶，分組下的容量，防止存儲被寫爆，影響服務可用性
-
流量管理：按照租戶，分組等多個維度對請求頻率，長鏈接個數，報文大小，請求流控進行控制
-
緩存機制：容災目錄，本地緩存，Server 緩存機制，是 Nacos 高可用的關鍵
-
啟動模式：按照單機模式，配置模式，服務模式，DNS 模式模式，啟動不同的模塊
-
一致性協議：解決不同數據，不同一致性要求情況下，不同一致性要求，是 Nacos 做到 AP 協議的關鍵
存儲模塊：解決數據持久化、非持久化存儲，解決數據分片問題
插件
-
Nameserver：解決 Namespace 到 ClusterID 的路由問題，解決用戶環境與 Nacos 物理環境映射問題
-
CMDB：解決元數據存儲，與三方 CMDB 系統對接問題，解決應用，人，資源關系
-
Metrics：暴露標准 Metrics 數據，方便與三方監控系統打通
-
Trace：暴露標准 Trace，方便與 SLA 系統打通，日志白平化，推送軌跡等能力，並且可以和計量計費系統打通
-
接入管理：相當於阿里雲開通服務，分配身份、容量、權限過程
-
用戶管理：解決用戶管理，登錄，SSO 等問題
-
權限管理：解決身份識別，訪問控制，角色管理等問題
-
審計系統：擴展接口方便與不同公司審計系統打通
-
通知系統：核心數據變更，或者操作，方便通過SMS系統打通，通知到對應人數據變更
功能特性介紹
服務管理
開發者或者運維人員往往需要在服務注冊后，通過友好的界面來查看服務的注冊情況，包括當前系統注冊的所有服務和每個服務的詳情。並在有權限控制的情況下，進行服務的一些配置的編輯操作。Nacos在這個版本開放的控制台的服務發現部分，主要就是提供用戶一個基本的運維頁面，能夠查看、編輯當前注冊的服務。
服務列表管理
服務列表幫助用戶以統一的視圖管理其所有的微服務以及服務健康狀態。整體界面布局是左上角有服務的搜索框和搜索按鈕，頁面中央是服務列表的展示。服務列表主要展示服務名、集群數目、實例數目、健康實例數目和詳情按鈕五個欄目。
在服務列表頁面點擊詳情，可以看到服務的詳情。可以查看服務、集群和實例的基本信息。
服務流量權重支持及流量保護
Nacos 為用戶提供了流量權重控制的能力，同時開放了服務流量的閾值保護，以幫助用戶更好的保護服務服務提供者集群不被意外打垮。如下圖所以，可以點擊實例的編輯按鈕，修改實例的權重。如果想增加實例的流量，可以將權重調大，如果不想實例接收流量，則可以將權重設為0。
服務元數據管理
Nacos提供多個維度的服務元數據的暴露，幫助用戶存儲自定義的信息。這些信息都是以K-V的數據結構存儲，在控制台上，會以k1=v1,k2=v2這樣的格式展示。類似的，編輯元數據可以通過相同的格式進行。例如服務的元數據編輯，首先點擊服務詳情頁右上角的“編輯服務”按鈕，然后在元數據輸入框輸入：version=1.0,env=prod。
點擊確認，就可以在服務詳情頁面，看到服務的元數據已經更新了。
服務優雅上下線
Nacos還提供服務實例的上下線操作，在服務詳情頁面，可以點擊實例的“上線”或者“下線”按鈕，被下線的實例，將不會包含在健康的實例列表里。
配置管理
Nacos支持基於Namespace和Group的配置分組管理，以便用戶更靈活的根據自己的需要按照環境或者應用、模塊等分組管理微服務以及Spring的大量配置，在配置管理中主要提供了配置歷史版本、回滾、訂閱者查詢等核心管理能力。
多配置格式編輯器
Nacos支持 YAML、Properties、TEXT、JSON、XML、HTML 等常見配置格式在線編輯、語法高亮、格式校驗，幫助用戶高效編輯的同時大幅降低格式錯誤帶來的風險。
Nacos支持配置標簽的能力，幫助用戶更好、更靈活的做到基於標簽的配置分類及管理。同時支持用戶對配置及其變更進行描述，方面多人或者跨團隊協作管理配置。
編輯DIFF
Nacos支持編輯DIFF能力，幫助用戶校驗修改內容，降低改錯帶來的風險。
示例代碼
Nacos提供示例代碼能力，能夠讓新手快速使用客戶端編程消費該配置，大幅降低新手使用門檻。
監聽者查詢
Nacos提供配置訂閱者即監聽者查詢能力，同時提供客戶端當前配置的MD5校驗值，以便幫助用戶更好的檢查配置變更是否推送到 Client 端。
配置的版本及一鍵回滾
Nacos通過提供配置版本管理及其一鍵回滾能力，幫助用戶改錯配置的時候能夠快速恢復，降低微服務系統在配置管理上的一定會遇到的可用性風險。
命名空間管理
Nacos 基於Namespace 幫助用戶邏輯隔離多個命名空間，這可以幫助用戶更好的管理測試、預發、生產等多環境服務和配置，讓每個環境的同一個配置（如數據庫數據源）可以定義不同的值。
登錄管理
Nacos0.8 版本支持簡單登錄功能，默認用戶名/密碼為： nacos/nacos。
修改默認用戶名/密碼方法
- 生成加密密碼， 在
com.alibaba.nacos.console.utils.PasswordEncoderUtil.main函數中，將 nacos 改成你要改成的密碼，運行即可得到加密有算法。注意鹽值是隨機的，所以生成密碼每次可能不一樣，請不要擔心。
public class PasswordEncoderUtil {
public static void main(String[] args) {
System.out.println(new BCryptPasswordEncoder().encode("nacos"));
}
}
- 創建用戶名或者密碼的時候，用指定用戶名密碼即可。
INSERT INTO users (username, password, enabled) VALUES ('nacos', '$2a$10$EuWPZHzz32dJN7jexM34MOeYirDdFAZm2kuWj7VEOJhhZkDrxfvUu', TRUE);
INSERT INTO roles (username, role) VALUES ('nacos', 'ROLE_ADMIN');
關閉登錄功能
由於部分公司自己開發控制台，不希望被nacos的安全filter攔截。因此nacos支持定制關閉登錄功能找到配置文件 ${nacoshome}/conf/application.properties， 替換以下內容即可。
## spring security config
### turn off security
spring.security.enabled=false
management.security=false
security.basic.enabled=false
nacos.security.ignore.urls=/**
#nacos.security.ignore.urls=/,/**/*.css,/**/*.js,/**/*.html,/**/*.map,/**/*.svg,/**/*.png,/**/*.ico,/console-fe/public/**,/v1/auth/login,/v1/console/health,/v1/cs/**,/v1/ns/**,/v1/cmdb/**,/actuator/**
會話時間
默認會話保持時間為30分鍾。30分鍾后需要重新登錄認證。 暫時不支持修改該默認時間。