微服務架構中配置中心的選擇

點擊上方藍色「方誌朋」，選擇「設爲星標」

回覆「666」獲取獨家整理的學習資料！html

 
來源：r6d.cn/XsTR
git

目前公司內部微服務架構基礎設施建設中，技術選型以Spring Cloud技術爲主，也被你們俗稱做「全家桶」。github

因其具有微服務架構體系中所需的各個服務組件，好比服務註冊發現(如Spring Cloud Eureka、Zookeeper、Consul)、API網關路由服務(Spring Cloud Zuul)，客戶端負載均衡(Spring Cloud Ribbon，Zuul默認集成了Ribbon)、服務容錯保護(Spring Cloud Hystrix)，消息總線 (Spring Cloud Bus)、分佈式配置中心(Spring Cloud Config)、消息驅動的微服務(Spring Cloud Stream)、分佈式鏈路跟蹤服務(Spring Cloud Sleuth)。web

本篇主要圍繞其中一個組件分佈式配置中心展開討論。面試

Spring Cloud Config配置中心介紹&架構

在微服務架構體系中配置中心是比較重要的組件之一，Spring Cloud官方自身提供了Spring Cloud Config分佈式配置中心，由它來提供集中化的外部配置支持，它分爲客戶端和服務端兩個部分。其中服務端稱做配置中心，是一個獨立的微服務應用，用來鏈接倉庫(如Git、Svn)並未客戶端提供獲取配置的接口；而客戶端是各微服務應用，經過指定配置中心地址從遠端獲取配置內容，啓動時加載配置信息到應用上下文中。因Spring Cloud Config實現的配置中心默認採用了Git來存儲配置信息，因此版本控制管理也是基於Git倉庫自己的特性來支持的。對該組件調研後，主要採用基於消息總線的架構方式，架構圖以下所示：spring

基於消息總線的配置中心架構中須要依賴外部的MQ組件，如Rabbit、Kafka 實現遠程環境事件變動通知，客戶端實時配置變動能夠基於Git Hook功能實現。同時架構圖中看到最右側，有一個Self scheduleing refresher 這個是我在實踐中本身新增的一個擴展功能，目的是當依賴的消息組件出現問題時，此時若是Git倉庫配置發生了變動，會致使部分或全部客戶端可能沒法獲取到最新配置，這樣就形成了客戶端應用配置數據沒法達到最終一致性，進而引發線上問題。數據庫

Self scheduleing refresher 是一個定時任務，默認5分鐘執行一次，執行時會判斷本地的Git倉庫版本與遠程Git倉庫版本若是不一致，則會從配置中心獲取最新配置進行加載，保障了配置最終一致性。json

通過實際使用你會發現Spring Cloud Config這個配置中心並非很是好用，若是是小規模的項目可使用問題不大，但它並不適用於中大型的企業級的配置管理。所以，我對業界開源的配置中心作個對比後最終選擇了攜程開源的Apollo配置中心解決了微服務架構配置管理和其餘項目中配置管理痛點。緩存

下面就針對Spring Cloud Config和Apollo配置中心作個更加直觀的比對：Apollo VS Spring Cloud Config微信

經過以上對比圖發現Spring Cloud Config缺陷仍是挺大的，好比最後一條高可用，Apollo配置中心客戶端應用加載配置後本地會生成緩存文件，即便配置中心全部的服務都掛掉，只是配置沒法更新，可是不影響你的服務啓動。而這Spring Cloud Config是沒法作到的，有人會說咱們能夠在應用classpath下添加應用配置文件做爲「兜底使用」，這樣作首先配置不會自動同步，並且也不是Spring Cloud Config自身的功能。

另外還有一個緣由是由於現階段項目中也使用了一些自研的配置中心，但都差強人意，有的配置中心僅支持xml格式的，沒法支持KV形式；還有的配置中心是基於JMX開發的，但只支持屬性配置推送。因此通過對Apollo配置中心的調研和使用發現這款產品不只適用於微服務配置管理場景，同時也支持多種配置格式，如xml、json、yml，還支持多語言客戶端的接入，在配置服務治理方面也是很完善的，在攜程內部已經支撐10萬+的實例運行，成熟又穩定！

開源配置中心對比

下面這個圖詳細的開源配置中心對比圖：

在上述幾個開源配置中內心，Apollo社區是很是活躍的，不斷更新迭代，github上的Star數量已達8K+，Fork數量已達2.8K+。在Apollo出現以前百度開源的disconf配置中心使用的更多些，disconf最新代碼更新時間仍是2年前的，且與Apollo的對比社區活躍度有所降低。

Apollo配置中心介紹&架構

Apollo（阿波羅）是攜程框架部門研發的分佈式配置中心，可以集中化管理應用不一樣環境、不一樣集羣的配置，配置修改後可以實時推送到應用端，而且具有規範的權限、流程治理等特性，適用於微服務配置管理場景。服務端基於Spring Boot和Spring Cloud開發，不依賴外部容器，便於部署。Java客戶端不依賴任何框架，可以運行於全部Java運行時環境，同時對Spring/Spring Boot環境也有額外支持。原生支持Java和.Net客戶端，同時也支持其餘語言客戶端，目前已支持Go、PHP、Python、NodeJS、C++。

主要功能特性：

統一管理不一樣環境、不一樣集羣的配置配置修改實時生效（熱發佈）版本發佈管理灰度發佈權限管理、發佈審覈、操做審計客戶端配置信息監控提供Java和.Net原生客戶端提供開放平臺API 部署簡單，依賴少

Apollo整體架構設計：

各組件做用說明：

Apollo HA高可用設計：

Apollo客戶端架構：

客戶端架構原理：

推拉結合方式客戶端與配置中心保持一個長鏈接，配置實時推送定時拉配置(默認5分鐘)
本地緩存配置緩存在內存本地緩存一份配置文件
應用程序經過Apollo客戶端獲取最新配置訂閱配置更新通知

Apollo核心概念：

application (應用)

每一個應用都須要有惟一的身份標識 -- appId

environment (環境)

Apollo客戶端經過不一樣環境獲取對應配置

cluster (集羣)

一個應用下不一樣實例的分組，不一樣的cluster，能夠有不一樣的配置。好比北京機房和天津機房能夠有不同的kafka或zk地址配置。

namespace (命名空間)

一個應用下不一樣配置的分組，不一樣的namespace的相似於不一樣的文件。如：數據庫配置，RPC配置等。支持繼承公共組件的配置。配置分類私有類型（private）：只能被所屬應用獲取公共類型（public）：必須全局惟一。使用場景：部門/小組級別共享配置，中間件客戶端配置。關聯類型（繼承類型）：私有繼承公有配置並覆蓋；定製公共組件配置場景。配置項(Item)默認和公共配置使用properties格式；私有配置支持properties/json/xml/yaml/yml格式。定位方式：app+cluster+namespace+item_key

權限管理

系統管理員擁有全部的權限建立者能夠代爲建立項目，責任人默認是項目管理員，通常建立者=責任人項目管理員可建立集羣，Namespace，管理項目和Namespace權限編輯權限只能編輯不能發佈發佈權限只能發佈不能編輯普通用戶能夠搜索查看全部項目配置，但沒有相關操做權限

Apollo配置中使用及擴展

使用Apollo配置中心後，作了進一步的功能開發擴展，接入公司的SSO和郵件通知接入。基於Spring Cloud Config微服務架構體系中，若是以前使用了Spring Cloud Config配置中心，也能夠經過下列方式平滑的遷移到Apollo配置中心。

Spring Cloud微服務項目在pom.xml中引入以下依賴：

<dependency>
     <groupId>com.letv.micro.apollo</groupId>
    <artifactId>micro-apollo-spring-boot-starter</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>

該源碼參考Github：https://github.com/david1228/micro-apollo-spring-boot-starter，須要自行編譯打成jar包使用。這個jar包對Spring Cloud配置刷新機制集成Apollo客戶端作了進一步封裝，實現的主要功能以下：

一、在Apollo配置中心發佈配置後，微服務應用客戶端監聽配置變動，包括默認的配置和公共的配置，經過ContextRefresher中的refresh()方法完成應用環境上下文的配置刷新。二、支持對日誌級別和日誌路徑文件的動態配置變動。[Apollo Client沒法很好的支持日誌級別和日誌路徑文件的變動，因日誌的LoggingApplicationListener加載優先級高，Apollo配置加載滯後。

上述jar包已上傳公司的Maven私服。具體配置使用示例能夠參考「4.Apollo配置中心使用示例」

引入micro-apollo-spring-boot-starter以後，能夠將spring-cloud-stater-config依賴從pom.xml中去掉了。Apollo配置中心公共配置命名規範:公共配置建議統一放到新建立的項目中，該項目中存放Spring Cloud相關的公共組件的配置，好比Eureka、Zipkin、Stream等配置，好比Eureka地址多是多個微服務應用共用的，便於在該項目中統一對配置進行管理。建立項目時，選擇的部門如爲「微服務公共平臺(dpms)」各微服務應用項目建立後能夠添加Namespace，選擇關聯公共配置。公共配置命名規則：{部門前綴}.application 或者 {部門前綴}.application-{具體的細分配置} 當Apollo配置發佈後，若需讓Spring Cloud配置實現動態加載，公共配置命名必須以application關鍵字開頭，在上述依賴的jar包中會對這類命名的Namespace作配置變動監聽。例如：

dpms.application-eureka 存放eureka相關配置或 dpms.application-zipkin 存放zipkin相關配置或 dpms.application 存放Spring Cloud全部的公共相關配置其餘微服務應用關聯公共配置後，默認使用的公共配置項。你也能夠對公共配置全部參數作覆蓋，覆蓋後優先獲取本項目中的配置，這個特性在Apolo的公共配置界面可以直觀的展現出來。

以上就是對爲何要選擇Apollo配置中心的一些介紹，相信你的項目中可能也遇到了相似的配置管理問題或痛點，強烈建議使用Apollo配置中心做爲你的配置管理基礎服務使用。

關於Apollo更詳盡的文檔請參考Github：https://github.com/ctripcorp/apollo

熱門內容：

 
      
      
      
       
       
                
       
 
      
  
       
       
       
        
        
                 
        
  
       最近面試BAT，整理一份面試資料《Java面試BAT通關手冊》，覆蓋了Java核心技術、JVM、Java併發、SSM、微服務、數據庫、數據結構等等。
獲取方式：點「在看」，關注公衆號並回復 666 領取，更多內容陸續奉上。
 
      
      
      
       
       
                
       
 
      
 
      
      
      
       
       
                
       
 
      
  
       
       
       
        
        
                 
        
  
       明天見(｡･ω･｡)ﾉ

本文分享自微信公衆號 - 方誌朋（walkingstory）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。