微服務架構，配置中心的技術選型

目前公司內部微服務架構基礎設施建設中，技術選型以 Spring Cloud 技術爲主，也被大家俗稱作 “全家桶”。

因其具備微服務架構體系中所需的各個服務組件，比如服務註冊發現 (如 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)。

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

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

在微服務架構體系中配置中心是比較重要的組件之一，Spring Cloud 官方自身提供了 Spring Cloud Config 分佈式配置中心，由它來提供集中化的外部配置支持，它分爲客戶端和服務端兩個部分。

其中服務端稱作配置中心，是一個獨立的微服務應用，用來連接倉庫 (如 Git、Svn) 並未客戶端提供獲取配置的接口；而客戶端是各微服務應用，通過指定配置中心地址從遠端獲取配置內容，啓動時加載配置信息到應用上下文中。

因 Spring Cloud Config 實現的配置中心默認採用了 Git 來存儲配置信息，所以版本控制管理也是基於 Git 倉庫本身的特性來支持的 。
對該組件調研後，主要採用基於消息總線的架構方式，架構圖如下所示：

基於消息總線的配置中心架構中需要依賴外部的 MQ 組件，如 Rabbit、Kafka 實現遠程環境事件變更通知，客戶端實時配置變更可以基於 Git Hook 功能實現。

同時架構圖中看到最右側，有一個 Self scheduleing refresher 這個是我在實踐中自己新增的一個擴展功能，目的是當依賴的消息組件出現問題時，此時如果 Git 倉庫配置發生了變更，會導致部分或所有客戶端可能無法獲取到最新配置，這樣就造成了客戶端應用配置數據無法達到最終一致性，進而引起線上問題。

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

經過實際使用你會發現 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 社區是非常活躍的，不斷更新迭代。

在 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 客戶端架構：

客戶端架構原理：

1. 推拉結合方式

• 客戶端與配置中心保持一個長連接，配置實時推送

• 定時拉配置 (默認 5 分鐘)

2. 本地緩存

• 配置緩存在內存

• 本地緩存一份配置文件

3. 應用程序

• 通過 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>

需要自行編譯打成 jar 包使用。

這個 jar 包對 Spring Cloud 配置刷新機制集成 Apollo 客戶端做了進一步封裝，實現的主要功能如下：

1、在 Apollo 配置中心發佈配置後，微服務應用客戶端監聽配置變更，包括默認的配置和公共的配置，通過 ContextRefresher 中的 refresh() 方法完成應用環境上下文的配置刷新。

2、支持對日誌級別和日誌路徑文件的動態配置變更。[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 配置中心作爲你的配置管理基礎服務使用。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/sVr6oMd5u2kd7YWQiZ0gMQ