七：对微服务配置中心的理解
生活随笔
收集整理的這篇文章主要介紹了
七：对微服务配置中心的理解
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
微服務專欄地址
專欄：微服務
微服務系列總目錄
目錄
- 微服務專欄地址
- 目錄
- 1. 簡介
- 2. 微服務配置中心是什么
- 3. 為什么需要微服務配置中心
- 4. 微服務配置中心實現技術
- 4.1 網羅的實現技術
- 4.2 Apollo分布式配置中心
- 4.2.1 基礎模型
- 4.2.2 總體設計
- 4.3 Spring Cloud config
- 4.3.1 基礎流程
- 4.3.2 配置實時刷新
- 5. 技術如何選型
1. 簡介
通過以下幾個問題理解微服務中的集中配置中心
1. 微服務配置中心是什么
2. 為什么需要微服務配置中心
3. 微服務配置中心實現技術
4. 技術如何選型
2. 微服務配置中心是什么
集中式配置是將應用系統中對配置信息的管理作為一個新的應用功能模塊，區別與傳統的配置信息分散到系統各個角落方式，進行集中統一管理，并且提供額外功能。尤其是在微服務架構中，是不可或缺組件，甚至是必要組件之一。
3. 為什么需要微服務配置中心
在微服務體系中，服務的數量以及配置信息的日益增多，比如各種服務器參數配置、各種數據庫訪問參數配置、各種環境下配置信息的不同、配置信息修改之后實時生效等等，傳統的配置文件方式或者將配置信息存放于數據庫中的方式已無法滿足開發人員對配置管理的要求，如：
- 安全性：配置跟隨源代碼保存在代碼庫中，容易造成配置泄漏
- 時效性：修改配置，需要重啟服務才能生效
- 局限性：無法支持動態調整：例如日志開關、功能開關
4. 微服務配置中心實現技術
對微服務的幾種成熟或者流行的集中式配置實現技術做個簡要對比，重點理解一下apollo配置中心與SpringCloudConfig。
4.1 網羅的實現技術
- Apollo（阿波羅）：是攜程框架部門研發的分布式配置中心，能夠集中化管理應用不同環境、不同集群的配置，配置修改后能夠實時推送到應用端，并且具備規范的權限、流程治理等特性，適用于微服務配置管理場景。
- XDiamond：全局配置中心，存儲應用的配置項，解決配置混亂分散的問題。名字來源于淘寶的開源項目diamond，前面加上一個字母X以示區別。
- Qconf： 奇虎 360 內部分布式配置管理工具。 用來替代傳統的配置文件，使得配置信息和程序代碼分離，同時配置變化能夠實時同步到客戶端，而且保證用戶高效讀取配置，這使的工程師從瑣碎的配置修改、代碼提交、配置上線流程中解放出來，極大地簡化了配置管理工作。
- Disconf：百度的分布式配置管理平臺，專注于各種「分布式系統配置管理」的「通用組件」和「通用平臺」, 提供統一的「配置管理服務」
- SpringCloudConfig：為分布式系統中的外部配置提供服務器和客戶端支持。
4.2 Apollo分布式配置中心
目前僅對其基礎模型以及總體進行理解學習，更多關于Apollo的信息請點擊這里查閱其官方文檔
4.2.1 基礎模型
4.2.2 總體設計
上圖簡要描述了Apollo的總體設計，我們可以從下往上看：
- Config Service提供配置的讀取、推送等功能，服務對象是Apollo客戶端
- Admin Service提供配置的修改、發布等功能，服務對象是Apollo Portal（管理界面）
- Config Service和Admin Service都是多實例、無狀態部署，所以需要將自己注冊到Eureka中并保持心跳
- 在Eureka之上我們架了一層Meta Server用于封裝Eureka的服務發現接口
- Client通過域名訪問Meta Server獲取Config Service服務列表（IP+Port），而后直接通過IP+Port訪問服務，同時在Client側會做load balance、錯誤重試
- Portal通過域名訪問Meta Server獲取Admin Service服務列表（IP+Port），而后直接通過IP+Port訪問服務，同時在Portal側會做load balance、錯誤重試
- 為了簡化部署，我們實際上會把Config Service、Eureka和Meta Server三個邏輯角色部署在同一個JVM進程中
4.3 Spring Cloud config
這里簡單理解基礎流程以及實時刷新原理，后續demo以及代碼中會結合深入進行理解、使用
4.3.1 基礎流程
4.3.2 配置實時刷新
- 與git倉庫結合使用時，使用git的web hook監控git倉庫中配置信息的變更，一旦有變更，則推送給ConfigServer，進而通過Spring Cloud Bus實現實時更新
5. 技術如何選型
理解需求、技術特點是技術選型的首要任務
目前暫未對其他幾個分布式配置中心做深入的了解，但是仍首選Apollo，個人理由如下：
- 配置集中管理：分布式配置中心最基礎的要求，滿足
- 配置實效性：配置的修改實時生效要求，滿足
- 安全性：應用和配置的管理具有完善的權限管理機制，并且新增編輯和發布環節，盡量減少了人工誤操作發生的概率，所有的操作都有審計日志，方便追蹤，滿足
- 配置修改簡單：提供的圖形化界面形式的配置管理，滿足
- 部署簡單：依賴非常少，只需要基礎的mysql以及java運行環境即可，也提供了對應的一鍵安裝腳本，滿足
- 開源：源碼的重要性不言而喻，無論是解決問題、擴展新功能、或者后期代替官方渠道進而形成滿足自身特定需求的版本，滿足
官方理由：
正是基于配置的特殊性，所以Apollo從設計之初就立志于成為一個有治理能力的配置發布平臺，目前提供了以下的特性：
- 統一管理不同環境、不同集群的配置
- Apollo提供了一個統一界面集中式管理不同環境（environment）、不同集群（cluster）、不同命名空間（namespace）的配置。
- 同一份代碼部署在不同的集群，可以有不同的配置，比如zookeeper的地址等
- 通過命名空間（namespace）可以很方便地支持多個不同應用共享同一份配置，同時還允許應用對共享的配置進行覆蓋
- 配置修改實時生效（熱發布）
- 用戶在Apollo修改完配置并發布后，客戶端能實時（1秒）接收到最新的配置，并通知到應用程序
- 版本發布管理
- 所有的配置發布都有版本概念，從而可以方便地支持配置的回滾
- 灰度發布
- 支持配置的灰度發布，比如點了發布后，只對部分應用實例生效，等觀察一段時間沒問題后再推給所有應用實例
- 權限管理、發布審核、操作審計
- 應用和配置的管理都有完善的權限管理機制，對配置的管理還分為了編輯和發布兩個環節，從而減少人為的錯誤。
- 所有的操作都有審計日志，可以方便地追蹤問題
- 客戶端配置信息監控
- 可以在界面上方便地看到配置在被哪些實例使用
- 提供Java和.Net原生客戶端
- 提供了Java和.Net的原生客戶端，方便應用集成
- 支持Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties，方便應用使用（需要Spring 3.1.1+）
- 同時提供了Http接口，非Java和.Net應用也可以方便地使用
- 提供開放平臺API
- Apollo自身提供了比較完善的統一配置管理界面，支持多環境、多數據中心配置管理、權限、流程治理等特性。不過Apollo出于通用性考慮，不會對配置的修改做過多限制，只要符合基本的格式就能保存，不會針對不同的配置值進行針對性的校驗，如數據庫用戶名、密碼，Redis服務地址等
- 對于這類應用配置，Apollo支持應用方通過開放平臺API在Apollo進行配置的修改和發布，并且具備完善的授權和權限控制
- 部署簡單
- 配置中心作為基礎服務，可用性要求非常高，這就要求Apollo對外部依賴盡可能地少
- 目前唯一的外部依賴是MySQL，所以部署非常簡單，只要安裝好Java和MySQL就可以讓Apollo跑起來
- Apollo還提供了打包腳本，一鍵就可以生成所有需要的安裝包，并且支持自定義運行時參數
總結
以上是生活随笔為你收集整理的七：对微服务配置中心的理解的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 用C语言实现简单的一字棋游戏
- 下一篇： 安装fastadmin 该网页无法正常运