引入
小D是研發(fā)工程師，某天產(chǎn)品說要開發(fā)一個雙十一商品促銷功能。由于產(chǎn)品無法預估促銷商品的需求量，于是拍腦袋說，每個用戶限購10個!
小D代碼：
//產(chǎn)品需求每個用戶限購10個商品
privatestaticfinalintMAX_QTY_PER_USER=10;
publicbooleanpurchase(intquality) {i
if(quality>MAx_QTY_PER_USER) {
? ? thrownewIllegalArgumentException(
? ? ? ? String.format("每個用戶限購%d個商品"，MAX_QTY_PER_USER));
? ? }
? ? //商品購買邏輯
returntrue;
}
促銷當日中午，銷售火爆出乎產(chǎn)品預料，產(chǎn)品匆忙跑到小D處，要求趕緊改成每人限購2個!
小D只好放棄午飯，改代碼、回歸測試、上線，整整花了1個多小時才搞定。
小S是研發(fā)工程師，某天產(chǎn)品說要開發(fā)一個雙十一商品促銷功能。由于產(chǎn)品無法預估促銷商品的需求量，于是拍腦袋說，每個用戶限購10個!
小S吸取了小D的教訓，直接把配置寫在了集中式配置中心里頭：
促銷當日中午，銷售火爆出乎產(chǎn)品預料，產(chǎn)品匆忙跑到小S處，要求趕緊改成每人限購2個!
小S花了10秒鐘，改了配置就好了！！！
傳統(tǒng)應用配置的問題
主要采用本地文件靜態(tài)配置：本地靜態(tài)配置導致在運行時無法動態(tài)修改
配置散亂格式不標準：有的用xml格式，有的用properties，有的存DB
易引發(fā)生產(chǎn)事故：發(fā)布的時候容易將非生產(chǎn)的配置帶到生產(chǎn)上，引發(fā)事故
配置修改麻煩，周期長：當部署的服務器很多時，修改配置費時費力
配置信息缺少安全審計和版本控制功能：事后無法追溯，誰改的?改了什么?什么時候改的?當出現(xiàn)問題無法及時回滾
現(xiàn)代交付需求（云原生：包含兩個趨勢）
微服務：服務微化
容器化：現(xiàn)代的交付方式對配置有新的要求
開關(guān)驅(qū)動開發(fā)
現(xiàn)代配置核心需求
交付件和配置分離
抽象標準化：配置格式用戶不用擔心，配置中心提供接口，客戶對接
集中式：統(tǒng)一的配置中心，不需要根據(jù)業(yè)務團隊單獨搞一套
高可用
實時性
治理：權(quán)限審計、權(quán)限控制，誰在什么時間點干了什么事，支持回退
配置中心
配置的定義與場景
配置定義：
可獨立于程序的可配變量
同一份程序在不同配置下會有不同行為
連接字符串，應用配置，業(yè)務配置
配置形態(tài)
程序內(nèi)部硬編碼
配置文件
環(huán)境變量
啟動參數(shù)
基于數(shù)據(jù)庫
配置治理
權(quán)限控制和審計
不同環(huán)境、集群配置管理。
框架類組件配置管理
灰度發(fā)布
分類
靜態(tài)配置：
環(huán)境變量：數(shù)據(jù)庫、中間件、其他服務的連接字符串
安全配置：用戶名、密碼、令牌、許可證等
動態(tài)配置
應用配置：請求超時，線程池，隊列、緩存,數(shù)據(jù)庫連接池的容量、日志級別、限流熔斷閾值、黑白名單
功能開關(guān)：藍綠發(fā)布，灰度開關(guān)，降級開關(guān)，HA高可用開關(guān)，DB遷移
業(yè)務配置：促銷規(guī)則，貸款額度，利率等業(yè)務參數(shù)，A/B測試
藍綠發(fā)布：
沒有配置中心時，兩個版本需要依賴運維幫助我們配置路由，（效率較低，需要協(xié)調(diào)資源，想要切換也比較麻煩，需要開發(fā)和運維協(xié)調(diào)）
可在代碼中埋一個開關(guān)，通過配置中心的配合，做到藍綠版本的切換，加入藍色版本上線效果不佳，再次切換也比較方便。
功能降級：
當在遇到促銷火爆、非法攻擊使流量突增時，可以在應用層代碼中埋一個開關(guān)，去做限流和降級。還可以針對用戶去做不同處理，如vip用戶繼續(xù)訪問，普通用戶給一個友好提示進行限流降級。
數(shù)據(jù)遷移：
遷移過程漸進的方式，逐步的完成，這個過程的10%的讀寫、100%的讀寫，就需要配置中心去調(diào)節(jié)，盡可能小的去進行遷移
A/B測試：
在配置中心配合下，完成新功能的上線，很好的降低直接上線的風險。
概述
隨著程序功能的日益復雜，程序的配置也日益增多，各種參數(shù)的配置、功能的開關(guān)、服務器的地址。我們對程序的期望值也越來越高，配置修改完要實時生效、灰度發(fā)布、分環(huán)境、分集群管理、完善的權(quán)限審核機制等，在這樣的大環(huán)境下，傳統(tǒng)的key-value配置、或者數(shù)據(jù)庫的配置無法滿足對配置管理的需求。
Apollo采用微服務架構(gòu)，設(shè)計輕巧，功能完善，提供統(tǒng)一界面管理應用在不同環(huán)境不同集群的配置，用戶在Apollo修改完配置后可以實時生效，也支持版本的概念，支持回滾，支持灰度發(fā)布，支持完善的權(quán)限審核、發(fā)布審核、操作審計等。
配置中心屬于基礎(chǔ)服務，對可用性要求較高，所以Apollo對外部依賴要盡可能的少，目前唯一的外部依賴是數(shù)據(jù)庫，不需要任何組件，部署比較簡單，客戶端和服務端有多級緩存，數(shù)據(jù)庫掛了也不會有很大的影響。
簡化架構(gòu)
配置管理員去配置中心修改發(fā)布配置，可以實時通知到應用客戶端，客戶端也可通過拉取的方式進行獲取配置中心的最新配置。
核心概念
應用：即使用配置的應用，有一個唯一的appId
環(huán)境：DEV、FAT、UAT、PRO等。一個應用在多個環(huán)境下都有部署，Apollo可以管理多套環(huán)境。server.properties中注明環(huán)境
集群：一個應用下不同實例的分組。對不同的cluster，可以有不同的配置。比如：kafka地址針對上海機房和成都機房可以有不一樣的配置
名字空間：一個應用下不同的配置分組，例如：數(shù)據(jù)庫配置、框架配置、元數(shù)據(jù)配置可以建不同的分組管理配置。private、public、關(guān)聯(lián)繼承類型。
private：只能被所屬應用類型獲取。
public：必須全局唯一；主要是一些共有場景，例如部門級別、小組級別、中間件客戶端的共享配置。（**）
關(guān)聯(lián)繼承：私有繼承共有并有覆蓋，或者可以定制公共組件的配置場景
配置項：表示可以配置的項，支持properties、json、xml格式。定位方式分為：
私有配置：env+app+cluster+namespace+item_key
共有配置：env+cluster+namespace+item_key
權(quán)限
系統(tǒng)管理員：擁有所有的權(quán)限
創(chuàng)建者：可以代為創(chuàng)建項目，責任人是默認的項目管理員，一般創(chuàng)建者=責任人
項目管理員：可以創(chuàng)建Namespace，集群管理項目和Namespace權(quán)限
編輯權(quán)限：只能編輯不能發(fā)布
發(fā)布權(quán)限：只能發(fā)布不能編輯
查看，普通用戶：可以搜索查看所有項目配置，但不能做相關(guān)操作
快速入門
準備：
快速啟動安裝包下載地址：https://github.com/nobodyiam/apollo-build-scripts。下載之后進行解壓
初始化數(shù)據(jù)庫：
Apollo 服務端一共需要兩個數(shù)據(jù)庫：ApolloPortalDB 和 ApolloConfigDB。數(shù)據(jù)庫、表的創(chuàng)建和樣例數(shù)據(jù)的 sql 文件都在快速啟動安裝包的 sql 目錄中，只需要導入數(shù)據(jù)庫即可。
數(shù)據(jù)庫連接信息在 demo.sh 中，我們需要把對應的數(shù)據(jù)庫連接信息修改成我們自己安裝的地址，這樣 Apollo 才能正常啟動。
啟動：
./demo.shstart
發(fā)現(xiàn)http://localhost:8070?now！就可了。
創(chuàng)建用戶：
進入用戶管理界面：
http://{portal地址}/user-manage.html
創(chuàng)建項目：
增加新配置：增加、確定發(fā)布
修改應用配置：為當前應用
~/client/METE-INF/app.properties
客戶端訪問：
./dome.sh client
架構(gòu)設(shè)計
服務端
模塊介紹：
config service（服務Apollo客戶端）
配置獲取接口
配置推送接口
admin service（服務Portal）
配置管理接口
配置修改、發(fā)布接口
meta server
Portal通過域名訪問Meta Server獲取Admin Service服務列表
Client通過域名訪問Meta Server獲取Config Service服務列表相當于一個Eureka Proxy
邏輯角色，和Config Service住在一起部署
Eureka
服務注冊發(fā)現(xiàn)
config/admin service注冊并報心跳
和config service一起部署
Portal
配置管理界面
通過meta server獲取admin service服務列表
客戶端軟負載
client
應用獲取配置、實時更新
通過Meta server獲取config service服務列表
客戶端軟負載
config service服務于client客戶端，client通過config service獲取配置，config service也可以實時推送 配置給client
admin service服務于portal管理端，portal通過調(diào)用admin service進行管理 config service和admin service共享一個configdb
portal有單獨的db
config service和admin service一般是以服務、集群的方式進行部署此時就涉及到服務發(fā)現(xiàn)注冊的問 題
eureka?config service和admin service會在eureka中注冊并定期報心跳
meta aserver?為了支持多語言，meta server對eureka進行包裝，簡化client和portal去eureka找服務 的過程，直接找meta server就好
NginxLB?client和portal在尋找meta server（meta server也是集群部署）時，通過NginxLB負載均衡器
綜上：引入的eureka 、meta aserver、NginxLB解決的就是服務發(fā)現(xiàn)的問題簡化架
領(lǐng)域模型
一個（app）應用有多個集群（cluster），一個集群下有多個名字空間（namespace），一個名字空間下有若干個配置項（item），編輯提交（commit），和發(fā)布數(shù)據(jù)（release）。
AppNameSpace：（app）應用的元數(shù)據(jù)，如：應用有哪些名字空間、共有還是私有等，而名字空間（namespace）是指集群下具體的namespace實例。
Audit：用戶任何操作，都會被審計，后繼可做審計查詢
權(quán)限模型
用戶有角色、角色有權(quán)限。
Apollo支持第三方接入，需要申請token，分布角色，并做審計
實時推送設(shè)計
客戶端
推拉結(jié)合
保持一個長連接，配置實時推送
定期拉配置(fallback)
配置緩存在內(nèi)存
本地再緩存一份
C: \opt\data\appId\config-cache
應用程序
通過Apollo客戶端獲取最新配置
訂閱配置更新通知
高可用
結(jié)合架構(gòu)圖
SpringCloudConfig vs Apollo
spring cloud config
spring cloud config是基于應用（application）、環(huán)境（profile：dev/test/prod）、版本（label）3個維度的配置管理
優(yōu)勢：
配置存儲通過Git支持
spring無縫集成
涉及簡單輕量
不足：
動態(tài)配置能力弱
治理能力弱（審計、權(quán)限控制）
不算嚴格的企業(yè)級（適用小型項目）
接口樣例：
接口url:/{application}/{profile}/{label}
例如：http://localhost:9000/appfoo/production/master
簡化架構(gòu)
動態(tài)配置的實現(xiàn)：（較為復雜）
對比
結(jié)論：Apollo是企業(yè)生產(chǎn)級配置中心，適用范圍更廣
常見問題
cluster是什么？
一個應用不同實例的分組，比如典型的多機房部署按數(shù)據(jù)中心分集群。
Namespace是什么？
一個應用下不同配置的分組，例如：應用配置application，中間件配置framework，數(shù)據(jù)庫配置 database
多個應用想要用同一個配置，如何做到？
使用公有的Namespace
客戶端訪問配置是否有權(quán)限，是否支持配置加密？
Apollo client獲取配置沒有權(quán)限管控，配置加密需要應用層自己實現(xiàn)
為什么不能進行編輯發(fā)布操作？
編輯和發(fā)布需要管理員授權(quán)，即使是管理員自己也需要自己給自己授權(quán)
