現實場景html
傳統應用打包部署, 會在不一樣的環境配置不一樣的包, 如Local環境, Dev環境, 測試環境, UAT環境, 生產環境分別製做不一樣的發佈包,git
每一個包裏環境特定配置.每一次部署都要修改配置文件, 提交審覈代碼, 才能打包, 很是的不方便. 相信不少朋友和我同樣碰到過這種問題. 若是是共用環境, 因爲環境問題, 常常會致使一個甚至多個team成員處於pending狀態.github
痛點:正則表達式
配置散亂格式不統一spring
有的用properties, 有的用xml 或 yml 等, 還有存在DB裏, 團隊傾向本身造輪子, 反正是五花八門,數據庫
主要採用本地靜態文件, 配置修改麻煩緩存
配置修改通常須要通過一個較長的測試發佈週期, 在分佈式環境下, 當服務實例不少的時候, 修改配置費時費力安全
容易引起生產事故服務器
在發佈的時候將測試環境配置帶到生產上,這種示例家常便飯.微信
配置缺少安全審計和版本控制
誰改的配置? 改了什麼? 何時改的? 天哪誰知道改了配置影響別人的什麼服務? 出了問題及時回滾吧.
由此分佈式配置中心應運而生, 如今市面上開源的配置中心有
1.Spring出品: Spring-cloud/Spring-cloud-config
https://github.com/spring-cloud/spring-cloud-config
2.螞蟻金服專家發起:Disconf https://github.com/knightliao/disconf
3.攜程出品: Apollo https://github.com/ctripcorp/apollo/
今天和你們聊的是第三個由上海攜程出品的開源分佈式配置中心Apollo, 名字很是的高大上叫阿波羅(讓人聯想起了美國登月計劃)
從github的Star上能夠判斷,受用戶關注度遠超前兩個, 達到了1.7W+顆星, 而且還在快速的增加. https://starcharts.herokuapp.com/ctripcorp/apollo
隨着應用程序配置日益增多複雜, 各類功能開關, 參數配置, 服務器地址等對於應用配置的指望也愈來愈高, 配置修改後實施生效, 灰度發佈, 分環境, 分集羣管理, 完善權限機制, 審覈機制等.在這樣的大背景下,傳統的靜態配置文件,數據庫等方式已經愈來愈沒法知足配置管理的需求.
Apollo的亮點
1. configService
提供配置獲取接口
提供配置推送接口
服務於Apollo客戶端
2.AdminService
提供配置管理接口
提供配置修改發佈接口
無語管理界面Portal
3.Client
爲應用獲取配置,支持實時更新
經過MetaServer獲取ConfigService服務列表
使用客戶端軟負載 SLB方式調用ConfigService
4.Portal
配置管理界面
經過MetaServer獲取AdminService的服務列表
使用客戶端軟負載SLB方式調用AdminService
三個輔助服務模塊
Eureka
用於服務發現和註冊
Config/AdminService註冊實例並按期彙報心跳
和ConfigService住在一塊兒部署
MetaServer
Portal經過域名訪問MetaServer獲取AdminService的地址列表
Client經過域名訪問MeT啊Server獲取ConfigService地址列表
邏輯角色和ConfigService在一塊兒部署
NginxLB
和域名系統配合,協助Portal訪問MetaServer獲取AdminService地址列表
和域名系統配合,協助Client訪問MetaServer獲取ConfigService地址列表
和域名系統配合,協助用戶訪問Portal進行配置管理
有些概念不是一會兒就能明白的, 須要在實際項目中碰見後纔會思考這類問題如何去解決, apoll給了咱們一個很好的方案
功能特性:
靜態配置管理
動態配置管理
統一管理,不一樣環境不一樣配置
配置緩存
配置校驗
配置生效時效
配置更新推送
配置定時拉取
用戶權限管理
受權, 審計,審覈
配置版本管理
配置合規檢測
實例配置監控
灰度發佈
告警通知
依賴關係
Demo環境:
http://106.12.25.204:8070/ 帳號/密碼:apollo/admin
參考文獻:
http://www.javashuo.com/article/p-fvmevrup-kg.html
今日推薦閱讀文章精選推薦
諮詢工做加微信
掃描二維碼
歡迎自薦和推薦, 須要的微信推送簡歷!
請猛戳下面二維碼瞭解更多