apollo 學習 配置 (一)

目錄

1. 什麼是配置
2. 配置中心的演變
3. 爲什麼選擇apollo,優勢是什麼
4. apollo介紹
   4.1 Apollo支持4個維度管理Key-Value格式的配置：
   4.2 apollo概覽
   4.3 Why Eureka
   4.4 可用性考慮
5. 接入apollo

1. 什麼是配置

配置是獨立於程序的只讀變量

配置首先是獨立於程序的，同一份程序在不同的配置下會有不同的行爲。
其次，配置對於程序是隻讀的，程序通過讀取配置來改變自己的行爲，但是程序不應該去改變配置。
常見的配置有：DB Connection Str、Thread Pool Size、Buffer Size、Request Timeout、Feature Switch、Server Urls等。

配置伴隨應用的整個生命週期

配置貫穿於應用的整個生命週期，應用在啓動時通過讀取配置來初始化，在運行時根據配置調整行爲。
配置可以有多種加載方式

配置也有很多種加載方式

常見的有程序內部hard code，配置文件，環境變量，啓動參數，基於數據庫等

配置需要治理

權限控制
由於配置能改變程序的行爲，不正確的配置甚至能引起災難，所以對配置的修改必須有比較完善的權限控制
不同環境、集羣配置管理
同一份程序在不同的環境（開發，測試，生產）、不同的集羣（如不同的數據中心）經常需要有不同的配置，所以需要有完善的環境、集羣配置管理
框架類組件配置管理
還有一類比較特殊的配置 - 框架類組件配置，比如CAT客戶端的配置。
雖然這類框架類組件是由其他團隊開發、維護，但是運行時是在業務實際應用內的，所以本質上可以認爲框架類組件也是應用的一部分。
這類組件對應的配置也需要有比較完善的管理方式。

2.配置中心的演變

2.1 最早期應該是hard code ,基本無配置可研
2.2 後來將配置抽離出來放到不同的配置文件中,但每次改動仍需要發佈
2.3 再後來,將配置單獨抽出來,存數據庫,由程序加載,提供可視化管理,這是較好的模型,但各公司自己實現的方式,可以滿足自己的業務,但不夠靈活,功能不夠強大;
2.4 在2.3的思想上,市面上有了一些生產級的產品出現,Spring的 Cloud Config,攜程的apollo等,其中apollo是當之無愧的number1;

3. 爲什麼選擇apollo,優勢是什麼

看圖

4.apollo簡介

Apollo（阿波羅）是攜程框架部門研發的開源配置管理中心，能夠集中化管理應用不同環境、不同集羣的配置，配置修改後能夠實時推送到應用端，並且具備規範的權限、流程治理等特性。

4.1 Apollo支持4個維度管理Key-Value格式的配置：

• application (應用)
• environment (環境)
• cluster (集羣)
• namespace (命名空間)

4.2 主要功能:

• 統一管理不同環境、不同集羣的配置
  Apollo提供了一個統一界面集中式管理不同環境（environment）、不同集羣（cluster）、不同命名空間（namespace）的配置。
  同一份代碼部署在不同的集羣，可以有不同的配置，比如zookeeper的地址等
  通過命名空間（namespace）可以很方便地支持多個不同應用共享同一份配置，同時還允許應用對共享的配置進行覆蓋

• 配置修改實時生效（熱發佈）
  用戶在Apollo修改完配置併發布後，客戶端能實時（1秒）接收到最新的配置，並通知到應用程序

• 版本發佈管理
  所有的配置發佈都有版本概念，從而可以方便地支持配置的回滾

• 灰度發佈

• 權限管理、發佈審覈、操作審計
  應用和配置的管理都有完善的權限管理機制，對配置的管理還分爲了編輯和發佈兩個環節，從而減少人爲的錯誤。
  所有的操作都有審計日誌，可以方便地追蹤問題

• 客戶端配置信息監控

• 提供Java和.Net原生客戶端

這些主要功能,簡直太友好了,大大的方便了開發,無需自己重複造輪子,估計即便造,也很難造這麼好!!!

4.2 apollo概覽

上圖簡要描述了Apollo的總體設計，我們可以從下往上看：

1. Config Service提供配置的讀取、推送等功能，服務對象是Apollo客戶端
2. Admin Service提供配置的修改、發佈等功能，服務對象是Apollo Portal（管理界面）
3. Config Service和Admin Service都是多實例、無狀態部署，所以需要將自己註冊到Eureka中並保持心跳
4. 在Eureka之上我們架了一層Meta Server用於封裝Eureka的服務發現接口
5. Client通過域名訪問Meta Server獲取Config Service服務列表（IP+Port），而後直接通過IP+Port訪問服務，同時在Client側會做load balance、錯誤重試
6. Portal通過域名訪問Meta Server獲取Admin Service服務列表（IP+Port），而後直接通過IP+Port訪問服務，同時在Portal側會做load balance、錯誤重試
7. 爲了簡化部署，我們實際上會把Config Service、Eureka和Meta Server三個邏輯角色部署在同一個JVM進程中

4.3 Why Eureka

爲什麼我們採用Eureka作爲服務註冊中心，而不是使用傳統的zk、etcd呢？我大致總結了一下，有以下幾方面的原因：

1. 它提供了完整的Service Registry和Service Discovery實現
   首先是提供了完整的實現，並且也經受住了Netflix自己的生產環境考驗，相對使用起來會比較省心。
2. 和Spring Cloud無縫集成

• 我們的項目本身就使用了Spring Cloud和Spring Boot，同時Spring Cloud還有一套非常完善的開源代碼來整合Eureka，所以使用起來非常方便。
• 另外，Eureka還支持在我們應用自身的容器中啓動，也就是說我們的應用啓動完之後，既充當了Eureka的角色，同時也是服務的提供者。這樣就極大的提高了服務的可用性。
• 這一點是我們選擇Eureka而不是zk、etcd等的主要原因，爲了提高配置中心的可用性和降低部署複雜度，我們需要儘可能地減少外部依賴。

3. Open Source
   最後一點是開源，由於代碼是開源的，所以非常便於我們瞭解它的實現原理和排查問題

4.4 可用性考慮

5.接入

5.1接入

當apollo搭建好了後,作爲一個成熟的工具,接入極其簡單,使用幾個簡單配置,就可基本接入;
java springboot爲例:

 # will inject 'application' namespace in bootstrap phase
apollo.bootstrap.enabled = true
#項目唯一標識
app.id=SampleApp
apollo.bootstrap.namespaces = application,你的命名空間
#你的搭建的apollo的meta service訪問地址
apollo.meta=http://apollo-rd.test.lei.com

5.2 監聽

當配置變動時,可以通知到客戶端;從而處理一些行爲;

Config config = ConfigService.getAppConfig(); //config instance is singleton for each namespace and is never null
config.addChangeListener(new ConfigChangeListener() {
    @Override
    public void onChange(ConfigChangeEvent changeEvent) {
        System.out.println("Changes for namespace " + changeEvent.getNamespace());
        for (String key : changeEvent.changedKeys()) {
            ConfigChange change = changeEvent.getChange(key);
            System.out.println(String.format("Found change - key: %s, oldValue: %s, newValue: %s, changeType: %s", change.getPropertyName(), change.getOldValue(), change.getNewValue(), change.getChangeType()));
        }
    }
});

基本功能即可使用;
本文簡單列出apollo一些點,具體可參考攜程在GitHub的官方介紹:
https://github.com/ctripcorp/apollo