背景
Ponf的全稱是Planet‘s Configuration的縮寫咒精，是為了當(dāng)時(shí)代號(hào)星球項(xiàng)目專門編寫的分布式配置中間件。
問：市面上已經(jīng)有很多配置中心了旷档，為什么要專門做一個(gè)配置中間件模叙？
答：因?yàn)樾乔蝽?xiàng)目是源于老VIP項(xiàng)目的升級(jí)，它的目標(biāo)是將VIP從一個(gè)單體項(xiàng)目（一套程序多機(jī)部署）升級(jí)為微服務(wù)項(xiàng)目鞋屈，以解決團(tuán)隊(duì)快速增長范咨，項(xiàng)目難以管控的問題。但升級(jí)不是一步到位的厂庇，要兼容之前的數(shù)據(jù)和代碼渠啊，同時(shí)還要保證升級(jí)過程循序漸進(jìn)不能耗費(fèi)太多人力。
而在VIP項(xiàng)目中有一個(gè)非常復(fù)雜的配置系統(tǒng)权旷，數(shù)據(jù)大概有幾個(gè)G替蛉。我們的目標(biāo)是不下線原本的配置系統(tǒng)，同時(shí)為微服務(wù)提供高效簡介的配置服務(wù)炼杖。因此需要兼容原有的配置功能灭返，同時(shí)還要進(jìn)行微服務(wù)改進(jìn)。
Ponf要解決的問題
原來配置服務(wù)存在的問題：
- 邏輯簡單粗暴坤邪，每五分鐘掃描Mysql獲取全量配置熙含，并全量分發(fā)給所有服務(wù)。
- 使用Thrift進(jìn)行通訊艇纺，在目前微服務(wù)統(tǒng)一使用Dubbo進(jìn)行通訊的背景下怎静，又引入Thrift會(huì)增加學(xué)習(xí)成本。
- 原配置服務(wù)為單體服務(wù)黔衡，一旦出問題所有服務(wù)奔潰蚓聘。
Ponf要解決的問題：
- 兼容原來配置服務(wù)數(shù)據(jù)（Mysql），同時(shí)可以使用原配置頁面進(jìn)行配置
- 開箱即用盟劫，提供最簡單的get接口夜牡，讓用戶不需要理解任何實(shí)現(xiàn)原理
- 完全使用分布式架構(gòu)，不再存在單點(diǎn)問題
- 高性能侣签，高時(shí)效性
- 保證數(shù)據(jù)的一致性（原配置使用Mysql自然能保證完全的一致性塘装，而Ponf的目標(biāo)是實(shí)現(xiàn)時(shí)間一致性和最終一致性，時(shí)間一致性指的是在Ponf只能看到某一時(shí)間之前的數(shù)據(jù)影所，而不會(huì)既看見之前的數(shù)據(jù)又看到之后的數(shù)據(jù)）
- 使用Dubbo
方案
這是一套簡單而又高效的方案蹦肴，雖然不是完美的配置系統(tǒng)，但是是最適合星球項(xiàng)目的方案猴娩。
首先在Ponf中有多個(gè)ConfigServer阴幌，他們都注冊為Dubbo服務(wù)勺阐，給所有客戶端提供服務(wù)。同時(shí)ConfigServer無狀態(tài)矛双，所有的客戶端可以任意選擇自己的ConfigServer渊抽，也可以隨時(shí)切換。
流程：
- 客戶端發(fā)送心跳到ConfigServer议忽，內(nèi)容為客戶端配置Version
- ConfigServer回復(fù)Version
- 客戶端檢查Version是否一致腰吟，若一致則等待下次心跳發(fā)送。
- 若不一致徙瓶，則將自己所有的配置key的ID，以及每個(gè)Key對(duì)應(yīng)的Version發(fā)送給ConfigServer（使用ID節(jié)約空間）
- ConfigServer將Version落后的Key的Value發(fā)送給客戶端
- 客戶端完成更新
若客戶端業(yè)務(wù)程序在獲取一個(gè)本地沒有緩存的Key時(shí)嫉称，執(zhí)行上面的4-6（這是比較耗時(shí)的操作侦镇，建議初始化時(shí)把key注冊上）。當(dāng)然如果業(yè)務(wù)不需要時(shí)間一致性织阅，也可以直接獲取壳繁。
ConfigServer內(nèi)部邏輯，這里主要講ConfigServer如何通過無鎖的方式提供快照荔棉。
ConfigServer會(huì)定時(shí)從MySQL中獲取最新的配置闹炉，首先先獲取最新的Version，如果Version等與當(dāng)前Version則不更新润樱。
否則拉去所有Version大于ConfigServer的Version的數(shù)據(jù)渣触。
在ConfigServer的配置存儲(chǔ)在Config類中
class Config{
Map<String,ConfigEntity> entities;
Config prev;
}
class ConfigEntity{
String value;
int id;
int version;
}
當(dāng)ConfigServer啟動(dòng)時(shí)會(huì)創(chuàng)建第一個(gè)Config，將所有配置存儲(chǔ)在entities中壹若。
之后配置更新時(shí)嗅钻，新創(chuàng)建一個(gè)Config，將更新的配置存儲(chǔ)在新的entity中店展，并將prev指向之前的Config养篓。
然后使用Copy On Write的方式替換全局Config的引用。
當(dāng)進(jìn)行配置查詢時(shí)看赂蕴，ConfigServer會(huì)先查詢當(dāng)前Config柳弄，如果Key不存在再查詢prevConfig。
當(dāng)然如果單是這樣概说，Config鏈表會(huì)越來越長碧注，那么配置讀取的性能也會(huì)變差，因此每隔一定時(shí)間席怪，就會(huì)將鏈表進(jìn)行Merge应闯，然后再通過Copy On Write的方式替換掉原來的Config。
這樣就完成了ConfigServer的快照讀挂捻，由于完全不加鎖碉纺，所以性能很好！
