Центр распределенной конфигурации -- Apollo

распределенный

Apollo (Apollo) — это центр распределенной конфигурации Ctrip с открытым исходным кодом, который может централизованно управлять конфигурацией различных сред и кластеров приложений, поддерживает горячее распространение конфигураций и передает их на сторону приложения в режиме реального времени, а также имеет стандартизированные разрешения и процессы. В сценариях управления конфигурацией распределенных микросервисов

Введение в центр конфигурации Apollo

Функции программы становятся все более и более сложными, а конфигурация программы увеличивается: различные функциональные переключатели, конфигурация параметров, адрес сервера... Ожидания от конфигурации программы также становятся все выше и выше: горячее развертывание и эффективное в режиме реального времени, оттенки серого релиз, управление кластером и конфигурация в зависимости от среды, идеальный механизм аудита полномочий... В этом контексте появился Центр конфигурации Apollo. Apollo поддерживает конфигурацию в четырехмерном формате Key-Value.* ПрименениеФактическая конфигурация приложения, клиент времени выполнения Apollo должен знать, кто является текущим приложением, таким образом, можно получить соответствующую конфигурацию. Каждое приложение имеет соответствующий идентификатор --appId, который необходимо настроить в коде.

  • Окружающая обстановкаДля настройки соответствующей среды клиенту Apollo необходимо знать, в какой среде находится текущее приложение, чтобы он мог получить конфигурацию приложения; среда не имеет ничего общего с кодом, один и тот же код, развернутый в разных средах, должен получить конфигурация различных сред, среда по умолчанию указывается путем чтения конфигурации на машине (свойство env в server.properties)
  • КластерГруппировка разных экземпляров под приложением, например, по разным центрам обработки данных, экземпляры в шанхайском машинном зале разделены на кластер, а экземпляры в шэньчжэньском компьютерном зале разделены на кластер; для разных кластеров одна и та же конфигурация может иметь разные значения Кластер указывается по умолчанию путем чтения конфигурации на машине (свойство idc в server.properties)
  • Пространство именГруппировка различных конфигураций в рамках приложения представляет собой набор элементов конфигурации.Вы можете просто классифицировать пространство имен как файл (конфигурации), а различные типы конфигураций хранятся в разных файлах, таких как файлы конфигурации базы данных, файлы конфигурации RPC и конфигурация самого приложения, файлы и т. д., приложения могут напрямую читать пространства имен конфигурации общедоступных компонентов, таких как DAL, RPC и т. д., приложения также могут настраивать конфигурацию общедоступных компонентов, наследуя пространства имен конфигурации общедоступных компонентов, например, начальный номер подключения к базе данных DAL

Apollo при создании проекта по умолчанию создает «приложение» пространства имен, «приложение» используется самим приложением. Например, файл конфигурации по умолчанию application.yaml Spring Boot в проекте, здесь application.yaml эквивалентен «приложению» пространства имен. Для большинства приложений пространство имен «application» уже настроено для соответствия сценариям повседневного использования.

Код для клиента для получения пространства имен «приложение» выглядит следующим образом.

    Config config = ConfigService.getAppConfig()

Код для клиента, чтобы получить пространство имен, отличное от «приложения», выглядит следующим образом.

    Config config = ConfigService.getConfig(namespaceName)

Формат файлов конфигурации пространства имен имеет различные форматы, свойства, xml, yml, yaml, json и т. д. Пространство имен также имеет следующие советы по формату: пространства имен в формате без свойств должны вызываться при использовании клиентом.ConfigService.getConfigFile(String namespace, ConfigFileFormat configFileFormat)Чтобы получить, если вы используете интерфейс Htpp для прямого вызова, соответствующий параметр пространства имен должен передать имя пространства имен плюс имя суффикса, например источник данных.) Пространство имен частного разрешения может быть получено только приложением для которым оно принадлежит. Когда приложение пытается получить частное пространство имен другого приложения, клиент Apollo сообщит об исключении «404».

общественное (общедоступное) разрешение Пространство имен с публичным разрешением, которое может быть получено любым приложением

Тип пространства имен

  • Частные типы имеют частные разрешения, например, упомянутое выше пространство имен «приложение» является частным типом.
  • Общедоступный тип имеет общедоступное разрешение Пространство имен общедоступного типа эквивалентно конфигурации вне приложения, а имя пространства имен используется для идентификации общедоступного пространства имен, поэтому имя общедоступного пространства имен должно быть глобально уникальным.

Сценарии использования Общая конфигурация на уровне отдела, общая конфигурация на уровне команды, конфигурация, совместно используемая несколькими проектами, конфигурация клиента промежуточного ПО

  • Связанный тип (унаследованный тип) имеет частное разрешение, а пространство имен связанного типа наследуется от пространства имен общедоступного типа, которое используется для переопределения некоторых конфигураций общедоступного пространства имен. Например, общедоступное пространство имен имеет два элемента конфигурации.
        k1 = v1
        k2 = v2
    然后应用A有一个关联类型的Namespace关联此公共Namespace，且以新值v3覆盖配置项k1。那么在应用A实际运行时，获取到的公共Namespace的配置为
        k1 = v3
        k2 = v2
    使用场景  假设RPC框架的配置(如：timeout)有以下要求
*     提供一份全公司默认的配置，且可动态调整
* RPC客户端项目可以自定义某些配置项且可动态调整
        结合Apollo的公共类型的Namespace和关联类型的Namespace。RPC团队在Apollo上维护一个叫“rpc-client”的公共Namespace，在"rpc-client"Namespace上配置默认的参数值。rpc-client.jar里的代码读取"rpc-client"Namespace的配置即可；如需要调整默认的配置，只需要修改公共类型"rpc-client"Namespace的配置；如果客户端项目想要自定义或动态修改某些配置项，只需要在Apollo自己项目下关联"rpc-client"，就能创建关联类型"rpc-client"的Namespace，然后在关联类型下修改配置项即可。这里rpc-client.jar是在应用容器里运行的，所以rpc-client获取到"rpc-client"Namespace的配置是应用的关联类型的Namespace加上公共类型的Namespace
        例子  如下图，有三个应用：应用A、应用B、应用C
        应用A有两个私有类型的Namespace：application和NS-Private，以及一个关联类型的Namespace：NS-Public
        应用B有一个私有类型的Namespace：application，以及一个公共类型的Namespace：NS-Public
        应用C只有一个私有类型的Namespace：application
        ![](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/9/29/16d7d726928b404f~tplv-t2oaga2asx-image.image)
        应用A获取Apollo配置
        //application 
        Config appConfig = ConfigService.getAppConfig();
        appConfig.getProperty("k1", null); // k1 = v11
        appConfig.getProperty("k2", null); // k2 = v21
        //NS-Private
        Config privateConfig = ConfigService.getConfig("NS-Private");
        privateConfig.getProperty("k1", null); // k1 = v3
        privateConfig.getProperty("k3", null); // k3 = v4
        //NS-Public，覆盖公共类型配置的情况，k4被覆盖
        Config publicConfig = ConfigService.getConfig("NS-Public");
        publicConfig.getProperty("k4", null); // k4 = v6 cover
        publicConfig.getProperty("k6", null); // k6 = v6
        publicConfig.getProperty("k7", null); // k7 = v7
        应用B获取Apollo配置
        //application
        Config appConfig = ConfigService.getAppConfig();
        appConfig.getProperty("k1", null); // k1 = v12
        appConfig.getProperty("k2", null); // k2 = null
        appConfig.getProperty("k3", null); // k3 = v32
        //NS-Private，由于没有NS-Private Namespace 所以获取到default value
        Config privateConfig = ConfigService.getConfig("NS-Private");
        privateConfig.getProperty("k1", "default value"); 
        //NS-Public
        Config publicConfig = ConfigService.getConfig("NS-Public");
        publicConfig.getProperty("k4", null); // k4 = v5
        publicConfig.getProperty("k6", null); // k6 = v6
        publicConfig.getProperty("k7", null); // k7 = v7
        应用C获取Apollo配置
        //application
        Config appConfig = ConfigService.getAppConfig();
        appConfig.getProperty("k1", null); // k1 = v12
        appConfig.getProperty("k2", null); // k2 = null
        appConfig.getProperty("k3", null); // k3 = v33
        //NS-Private，由于没有NS-Private Namespace 所以获取到default value
        Config privateConfig = ConfigService.getConfig("NS-Private");
        privateConfig.getProperty("k1", "default value"); 
        //NS-Public，公共类型的Namespace，任何项目都可以获取到
        Config publicConfig = ConfigService.getConfig("NS-Public");
        publicConfig.getProperty("k4", null); // k4 = v5
        publicConfig.getProperty("k6", null); // k6 = v6
        publicConfig.getProperty("k7", null); // k7 = v7

ChangeListenerКак видно из приведенного выше кода, клиентское пространство имен сопоставляется с объектом конфигурации, а прослушиватель изменений конфигурации пространства имен регистрируется в объекте конфигурации.

Код пространства имен для мониторинга приложения в приложении A выглядит следующим образом.

Config appConfig = ConfigService.getAppConfig();appConfig.addChangeListener(new ConfigChangeListener() {public void onChange(ConfigChangeEvent changeEvent) {//do something}})

        在应用A中监听 NS-Private 的 Namespace代码如下
        Config privateConfig = ConfigService.getConfig("NS-Private");
        privateConfig.addChangeListener(new ConfigChangeListener() {
        public void onChange(ConfigChangeEvent changeEvent) {
        //do something
        }
        })
        ## 在应用A、应用B和应用C中监听NS-Public Namespace代码如下
        Config publicConfig = ConfigService.getConfig("NS-Public");
        publicConfig.addChangeListener(new ConfigChangeListener() {
            public void onChange(ConfigChangeEvent changeEvent) {
                //do something
                }
        })

Несколько свойств конфигурации

  • Конфигурация - это только для чтения переменные, не зависящие от программы
    • Конфигурация сначала не зависит от программы, одна и та же программа будет вести себя по-разному в разных конфигурациях.
    • Конфигурация доступна программе только для чтения, программа меняет свое поведение, читая конфигурацию, и программа не должна изменять конфигурацию
  • Конфигурация сопровождает весь жизненный цикл приложения
    • Конфигурация проходит через весь жизненный цикл приложения.Приложение инициализируется чтением конфигурации при запуске, а поведение корректируется в соответствии с конфигурацией во время выполнения.
  • Конфигурации могут быть загружены несколькими способами
    • Общие методы загрузки конфигурации включают внутренний жесткий код программы, файлы конфигурации, переменные среды, параметры запуска, на основе базы данных и т. д.
  • Потребности в управлении конфигурацией
    • Контроль разрешений Поскольку конфигурация может изменить поведение программы, а неправильная конфигурация может даже привести к аварии, необходим более полный контроль разрешений на изменения конфигурации.
    • Различные среды и управление конфигурацией кластера Одна и та же программа может иметь разные конфигурации в разных средах (разработка, тестирование, производство) и разных кластерах (например, в разных центрах обработки данных), поэтому необходимо иметь полное управление средой и конфигурацией кластера.
    • Управление конфигурацией компонентов фреймворка — это особый вид конфигурации, который обычно разрабатывается и поддерживается другими командами, но среда выполнения находится в реальном бизнес-приложении, поэтому, по сути, можно считать, что компонент фреймворка также является частью приложение и должно быть более полным.
      Основываясь на особенностях конфигурации, Apollo с самого начала был определен как платформа для публикации конфигураций с возможностями управления.В настоящее время она предоставляет следующие функции.
  • Унифицированное управление конфигурацией разных сред и разных кластеров
    • Apollo предоставляет единый интерфейс для централизованного управления конфигурацией различных сред (Environment), разных кластеров (Cluster) и разных пространств имен (Namespace).
    • Один и тот же код развернут в разных кластерах и может иметь разную конфигурацию
    • Пространства имен могут легко поддерживать несколько разных приложений для использования одной и той же конфигурации, а также позволяют приложениям переопределять общую конфигурацию.
  • Горячий выпуск — изменение конфигурации вступает в силу в режиме реального времени. После того, как пользователь изменяет конфигурацию в Apollo и публикует ее, клиент может получить последнюю конфигурацию в режиме реального времени (1 секунду) и уведомить приложение.
  • Управление выпуском версии Все выпуски конфигурации имеют концепцию версии, которая может легко поддерживать откат конфигурации
  • Публикация в градациях серого Поддерживает настроенную публикацию в градациях серого. Например, после нажатия кнопки "Опубликовать" она повлияет только на некоторые экземпляры приложения. После наблюдения в течение определенного периода времени перед отправкой во все экземпляры приложения проблем не возникнет.
  • Управление разрешениями, аудит релизов, аудит операций
    • Управление приложением и конфигурацией имеет полный механизм управления полномочиями, а управление конфигурацией также разделено на два звена: редактирование и публикация, чтобы уменьшить человеческие ошибки.
    • Все операции имеют журналы аудита для легкого отслеживания проблем
  • Мониторинг информации о конфигурации клиента. Вы можете легко увидеть, какие экземпляры конфигурации используются на интерфейсе.
  • Предоставляет собственные клиенты Java и .Net.
    • Предоставляет собственные клиенты для Java и .Net для облегчения интеграции приложений.
    • Поддержка Spring Placeholder, Annotation и Spring Boot ConfigurationProperties для простоты использования приложения (требуется Spring 3.1.1+)
    • В то же время предоставляется Http-интерфейс, и приложения, отличные от Java и .Net, также могут быть легко использованы.
  • Предоставлять API открытой платформы
  • Простота развертывания

Настройка правил полученияТребуется только в том случае, если приложение настраивает кластер или пространство имен. С концепцией кластера правила конфигурации становятся более важными.Например, приложение развертывается в компьютерном зале A, но в Apollo не создается новый кластер, или во время выполнения указывается cluster=SomeCluster, но в Apollo не создается новый кластер. В это время Аполлона Каково поведение? Ниже описаны правила получения конфигурации.Применить правила сбора, настроенные самостоятельноКогда приложение использует следующий оператор для получения конфигурации, это называется получением конфигурации самого приложения, то есть конфигурации пространства имен приложения самого приложения.

        Config config = ConfigService.getAppConfig();

Правила получения конфигурации для этого случая вкратце таковы:

  1. Сначала найдите конфигурацию кластера среды выполнения (указанный apollo.cluster)
  2. Если не нашли, ищите конфигурацию кластера дата-центра
  3. Если все еще не найдено, верните конфигурацию кластера по умолчанию.
    Схема выглядит следующим образом
    配置查找顺序 
    所以，如果应用部署在A数据中心，但是用户没有在Apollo创建cluster，那么获取的配置就是默认cluster(default)的；如果应用部署在A数据中心，同时在运行时指定了apollo.cluster=SomeCluster，但是没有在Apollo创建cluster，那么获取的配置就是A数据中心cluster的配置，如果A数据中心cluster没有配置的话，那么获取的配置就是默认cluster(default)的
* 公共组件配置的获取规则
    以`FX.Hermes.Producer`为例，hermes producer是hermes发布的公共组件。当使用下面的语句获取配置时，称之为获取公共组件的配置
            Config config = ConfigService.getConfig("FX.Hermes.Producer")

Получите правила конфигурации для этого случая, вкратце:

  1. Сначала получите текущее приложение подFX.Hermes.ProducerКонфигурация пространства имен
  2. Тогда получите приложение ГермесFX.Hermes.ProducerКонфигурация пространства имен
  3. Объединение конфигурации двух вышеперечисленных частей является окончательной конфигурацией.Если есть части с одинаковым ключом, приложение должно иметь приоритет.
    Схема выглядит следующим образом
    公共组件配置获取规则

Таким образом реализуется управление конфигурацией компонентов фреймворка.Поставщик компонентов фреймворка предоставляет значение конфигурации по умолчанию, и приложение может переопределить его самостоятельно, если есть особые требования.

Дизайн центра конфигурации Apollo

общий дизайн

  • базовая модель
    • Пользователь изменяет и публикует конфигурацию в центре конфигурации.
    • Центр конфигурации уведомляет клиента Apollo о наличии обновления конфигурации.
    • Клиент Apollo извлекает последнюю конфигурацию из центра конфигурации, обновляет локальную конфигурацию и уведомляет приложение.

基础模型

  • Архитектурный модуль
    • Найдено четыре функциональных модуля, связанных со вспомогательными услугами, и три основных модуля: Apollo содержит семь модулей.
    • Четыре основных модуля и их основные функции
      • ConfigService предоставляет интерфейс получения конфигурации, интерфейс передачи конфигурации и обслуживает клиентов Apollo.
      • AdminService предоставляет интерфейс управления конфигурацией, интерфейс публикации изменений конфигурации и интерфейс управления услугами.
      • Клиент получает конфигурацию для приложения, поддерживает обновление в реальном времени, получает список служб ConfigService через MetaServer и использует клиентскую мягкую загрузку SLB для вызова ConfigService.
      • Портал настраивает интерфейс управления, получает список служб AdminService через MetaServer и вызывает AdminService с помощью SLB с программной загрузкой на стороне клиента.
    • Три вспомогательных модуля обнаружения служб
      • Eureka используется для обнаружения и регистрации служб, ConfigService и AdminService регистрируют экземпляры и регулярно сообщают о контрольных точках и развертываются в том же процессе, что и ConfigService.
      • Портал MetaServer обращается к MetaServer через доменное имя, чтобы получить список адресов AdminService, а Клиент обращается к MetaServer через доменное имя, чтобы получить список адресов ConfigService, который эквивалентен EurekaProxy и является логической ролью. и ConfigService развернуты в одном процессе
      • NginxLB сотрудничает с системой доменных имен, помогает порталу получить доступ к MetaServer для получения списка адресов AdminService, сотрудничает с системой доменных имен, помогает клиенту получить доступ к MetaServer для получения списка адресов ConfigService, сотрудничает с системой доменных имен, помогает пользователям получить доступ к порталу для управления конфигурацией
        Apollo架构
  • Анализ архитектуры
    **Apollo架构V1**  如果不考虑分布式微服务架构中的服务发现问题，Apollo的最简架构如下图所示
    ![Apollo架构V1](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/9/29/16d7d7275299a778~tplv-t2oaga2asx-image.image)
    要点
    * ConfigService是一个独立的微服务，服务于Client进行配置获取
    * Client和ConfigService保持长连接，通过一种推拉结合(push & pull)的模式，在实现配置实时更新的同时，保证配置更新不丢失
    * AdminService是一个独立的微服务，服务于Portal进行配置管理。Portal通过调用AdminService进行配置管理和发布
    * ConfigService和AdminService共享ConfigDB，ConfigDB中存放项目在某个环境中的配置信息。ConfigService/AdminService/ConfigDB三者在每个环境(DEV/FAT/UAT/PRO)中都要部署一份
    * Protal有一个独立的PortalDB，存放用户权限、项目和配置的元数据信息。Protal只需部署一份，它可以管理多套环境
    **Apollo架构 V2**   为了保证高可用，ConfigService和AdminService都是无状态以集群方式部署的，这时候就存在一个服务发现的问题：Client怎么找到ConfigService？Portal怎么找到AdminService？为了解决这个问题，Apollo在其架构中引入Eureka服务注册中心组件，实现微服务间的服务注册和发现，更新后的架构如下图所示
        ![Apollo架构V2](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/9/29/16d7d727764634a6~tplv-t2oaga2asx-image.image)
        要点
    * ConfigService和AdminService启动后都会注册到Eureka服务注册中心，并定期发送存活心跳
    * Eureka采用集群方式部署，使用分布式一致性协议保证每个实例的状态最终一致

Архитектура Аполлона V3Eureka — это Java-клиент со своим собственным сервисом обнаружения.Если Apollo поддерживает только клиентский доступ Java и не поддерживает клиентский доступ на других языках, тогда Client и Portal нужно только ввести Java-клиент Eureka для реализации функции обнаружения сервисов. После того как целевая служба обнаружена, ее можно перенаправить в экземпляр целевой службы через программную загрузку клиента (SLB, например Ribbon). Это классическая микросервисная архитектура, основанная на Eureka для обнаружения регистрации службы + клиентская лента для обеспечения мягкой маршрутизации, как показано на следующем рисунке.Apollo架构V3

Архитектура Аполлона V4
Для поддержки многоязычного клиента Apollo вводит роли метасервера, это фактически прокси-сервер EUREKA, предоставляет интерфейс обнаружения службы Eureka в простом и понятном HTTP-интерфейсе, что удобно для Client/Protal для передачи простого httpclient.Запросить список адресов ConfigService / Админасервис. После получения списка адресов экземпляров службы вы будете перемещены к целевому экземпляру с помощью простой политики программной загрузки клиента (Client SLB).

Другой вопрос заключается в том, что сам MetaServer не имеет состояния и развернут в кластере, так как же Client/Protal обнаруживает MetaServer? Традиционный подход заключается в использовании аппаратного или программного балансировщика нагрузки.Ctrip использует расширенный NginxLB (программный балансировщик нагрузки), а при эксплуатации и обслуживании настраивается доменное имя для кластера MetaServer, указывающее на кластер NginxLB, а затем NginxLB выполняет балансировку нагрузки. на МетаСервере и переадресация трафика. Клиент/Портал косвенно обращается к кластеру MetaServer через доменное имя + NginxLB

Архитектура после внедрения MetaServer и NginxLB выглядит следующим образом.Apollo架构V4

Архитектура Аполлона V5
Осталась последняя ссылка. Портал также развернут в кластере без сохранения состояния. Как пользователи могут обнаружить и получить доступ к порталу? Ответ — тоже простая традиционная практика: пользователи косвенно обращаются к кластеру Portal через доменное имя + NginxLB. Таким образом, версия V5 является окончательной архитектурой Apollo, включая пользовательскую сторону, как показано на следующем рисунке.Apollo架构V5

  • дизайн сервера
    配置发布后的实时推送设计  在配置中心中，一个重要的功能就是配置发布后实时推送到客户端。下面我们简要看一下这块是怎么设计实现的
![服务端设计](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/9/29/16d7d7280f721f5f~tplv-t2oaga2asx-image.image)
        上图简要描述了配置发布的大致过程
        1. 用户在Portal操作发布配置
        2. Portal调用Admin Service的接口操作发布
        3. Admin Service发布配置后，发送ReleaseMessage给各Config Service
        4. Config Service收到ReleaseMessage后通知对应的客户端
    **发送ReleaseMessage的实现方式**   Admin Service在配置发布后，需要通知所有的Config Service有配置发布，从而Config Service可以通知对应的客户端来拉取最新的配置。从概念上看，这是一个典型的消息使用场景，Admin Service作为Producer发出消息，各个Config Service作为consumer消费消息。通过一个消息组件(Message Queue)就能很好地实现Admin Service和Config Service的解耦。在实现上，Apollo为尽量减少外部依赖，没有采用外部的消息中间件，而是通过数据库实现了一个简单的消息队列
    实现方式如下
        1. Admin Service在配置发布后会往ReleaseMessage表插入一条消息记录，消息内容就是配置发布的AppId+Cluster+Namespace
        2. Config Service有一个线程会每秒扫描一次ReleaseMessage表，看是否有新的消息记
        3. Config Service如果发现有新的消息记录，那么会通知到所有的消息监听器(ReleaseMessageListener)，例如NotificationControllerV2
        4. 消息监听器得到配置发布的AppId+Cluster+Namespace后，会通知对应的客户端
示意图如下
![配置更新通知](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/9/29/16d7d728386cd0b0~tplv-t2oaga2asx-image.image)

Как сервис конфигурации уведомляет клиентаУзнав о конфигурации прослушивателя сообщений, новый выпуск должен сообщить клиенту, как это сделать? Это достигается следующим образом

  1. Клиент инициирует HTTP-запрос к интерфейсу уведомлений/v2 службы конфигурации, который является NotificationControllerV2.
  2. NotificationControllerV2 не возвращает результат сразу, а приостанавливает запрос через Spring DeferredResult
  3. Если в течение 60 секунд не будет опубликована ни одна конфигурация, которая интересует клиента, он вернет клиенту код состояния Http 304.
  4. Если существует выпуск конфигурации, который интересует клиента, NotificationControllerV2 вызовет метод setResult DeferredResult, передаст информацию о пространстве имен с изменениями конфигурации, и запрос будет немедленно возвращен. После того как клиент получит пространство имен изменения конфигурации из возвращенного результата, он немедленно запросит у службы конфигурации получение последней конфигурации пространства имен.

Клиентский дизайн客户端设计На приведенном выше рисунке кратко описан принцип реализации клиента Apollo.

  1. Клиент и сервер должны поддерживать постоянное соединение (через длительный опрос Http), чтобы он мог нажать в первый раз для получения обновленной конфигурации.
  2. Клиент также регулярно получает последнюю конфигурацию приложения с сервера центра конфигурации Apollo.
    • Это резервный механизм, чтобы предотвратить обновление конфигурации из-за сбоя механизма push.
    • Клиент регулярно извлекает локальную версию и сообщает о локальной версии. В общем, для запланированной операции извлечения сервер возвращает 304-Not Modified.
    • Частота синхронизации по умолчанию извлекается каждые 5 минут, и клиент также может переопределить ее, указав системное свойство: apollo.refreshInterval во время выполнения в минутах.
    • После того, как клиент получит последнюю конфигурацию приложения с сервера центра конфигурации Apollo, она будет сохранена в памяти
    • Клиент получит от сервера конфигурацию восстановления конфигурации в локальном кеше файловой системы, в случае сервисного или сетевого не может быть необоснованным, все равно из локального
    • Приложения могут получать последнюю конфигурацию от клиента Apollo и подписываться на уведомления об обновлении конфигурации.

Руководство пользователя Аполлона

разрешение имени

  • Обычные приложения Программы, работающие независимо, такие как веб-приложения, программы с основными функциями
  • Общие компоненты относятся к опубликованным библиотекам классов и клиентским программам, которые не работают независимо друг от друга, например к пакетам Java jar.

Общее руководство по доступу к приложениям

  • Создать проект
    • 1. Введите домашнюю страницу Apollo-Portal
    • 2. Нажмите «Создать проект».
    • 3. Введите информацию о проекте
      Отдел Выберите отдел, в котором находится приложение
      AppId приложения используется для представления уникального идентификатора удостоверения приложения. Формат представляет собой строку, которая должна соответствовать app.id, настроенному в клиентских app.properties.
      Имя приложения Имя приложения, используется только для отображения интерфейса
      Руководитель приложения выбранных людей станет администратором проекта по умолчанию с правами управления проектом, созданием кластера, созданием пространства имен и другими привилегиями.
    • 4. Нажмите «Отправить», чтобы создать успешный переход на домашнюю страницу проекта по умолчанию.
  • Назначение разрешения на проект
    Права администратора проекта Администраторы проекта могут управлять назначением прав проекта, создавать кластеры и создавать пространства имен.
  • Настройте разрешения на редактирование и публикацию
    Разрешения на редактирование позволяют пользователям создавать, изменять и удалять конфигурации в интерфейсе Apollo.
    Разрешения на публикацию позволяют пользователям публиковать и откатывать конфигурации в интерфейсе Apollo.
  • Добавление элемента конфигурации Редактирование конфигурации Вам необходимо иметь это разрешение на редактирование пространства имен, если вы обнаружите, что нет новой кнопки конфигурации, вы можете найти авторизацию администратора проекта.
  • Только выпуск конфигурации после публикации действительно будет применяться к использованию, поэтому после редактирования конфигурации вам необходимо опубликовать конфигурацию. Конфигурации выпуска должны иметь разрешение на публикацию этого пространства имен, и если вы не отпустите кнопку, вы можете найти авторизацию администратора проекта.
  • Приложение считывает конфигурацию. После успешной публикации конфигурации ее можно прочитать через клиент Apollo. В настоящее время Apollo предоставляет клиент Java. Если вы используете другие языки, вы также можете получить конфигурацию, напрямую обратившись к Http-интерфейсу.
  • Откат опубликованной конфигурации Если вы обнаружите какую-либо проблему с опубликованной конфигурацией, вы можете откатить конфигурацию, прочитанную клиентом, до предыдущей опубликованной версии, нажав кнопку «Откат». Механизм отката здесь аналогичен релизной системе.Операция отката в релизной системе заключается в откате инсталляционного пакета, развернутого на машине, до последней развернутой версии, но код в репозитории кода не будет откатываться, так что Разработка может быть переиздана после исправления кода. Откат в Apollo также представляет собой аналогичный механизм, после нажатия на откат конфигурация, опубликованная клиенту, откатывается на предыдущую опубликованную версию, то есть конфигурация, прочитанная клиентом, будет восстановлена ​​до предыдущей версии, но на на странице Отредактированные конфиги не откатываются, что позволяет разработке переопубликовать после исправления конфига

Общие этапы доступа к компонентамЭтапы доступа к общедоступным компонентам почти такие же, как и к обычным приложениям, с той лишь разницей, что общедоступным компонентам необходимо установить собственное уникальное пространство имен.

        1.创建项目
        2.项目管理员权限
        3.创建Namespace
        4.添加配置项
        5.发布配置
        6.应用读取配置

Применить переопределение общих шагов конфигурации компонента

    1.关联公共组件Namespace
    2.覆盖公共组件配置
    3.发布配置

Несколько AppID с одной и той же конфигурациейВ некоторых случаях, хотя само приложение не является общедоступным компонентом, все же необходимо использовать одну и ту же конфигурацию для нескольких APPID. В этом случае, если вы хотите реализовать несколько APPID, настраиваются основные концепции и общедоступные компоненты. В частности, это создание пространства имен под одним из приложений, записанное в общедоступную информацию о конфигурации, а затем чтение конфигурации пространства имен в каждом элементе; если приложению необходимо перезаписать общедоступную информацию о конфигурации, то в этом приложении под связанное общедоступное пространство имен и напишите конфигурацию, которую необходимо перезаписать

Применить политику доступаРассмотрите возможность клиентского доступа на языке, отличном от Java, — получите конфигурацию непосредственно через Http-интерфейс.

  • Чтение конфигурации из Apollo через HTTP-интерфейс с кешем
    Этот интерфейс будет получать конфигурацию из кэша, что подходит для запросов на вытягивание конфигурации с высокой частотой, таких как простой опрос конфигурации каждые 30 секунд. Поскольку кеш будет иметь задержку не более одной секунды, если вам нужно обновить конфигурацию в режиме реального времени с помощью push-уведомления о конфигурации, обратитесь к интерфейсу HTTP без кеша, чтобы прочитать конфигурацию из Apollo.
    **HTTP接口说明**
    **URL** {config_server_url}/configfiles/json/{appId}/{clusterName}/{namespaceName}?ip={clientIp}
    **Method**  GET
    **参数说明 ** 
![file](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/9/29/16d7d728a24bb557~tplv-t2oaga2asx-image.image)
        **HTTP接口返回格式**  该HTTP接口返回的是JSON格式、UTF-8编码，包含了对应namespace中所有的配置项。返回内容Sample如下
        {
        "portal.elastic.document.type":"biz",
        "portal.elastic.cluster.name":"hermes-es-fws"
        }
        *TIPS 通过{configserverurl}/configfiles/{appId}/{clusterName}/{namespaceName}?ip={clientIp}可以获取到properties形式的配置*
* 不带缓存的HTTP接口从Apollo读取配置  
    该接口会直接从数据库中获取配置，可以配合配置推送通知实现实时更新配置
    **URL**  {config_server_url}/configs/{appId}/{clusterName}/{namespaceName}?releaseKey={releaseKey}&ip={clientIp}
    **Method** GET
    **参数说明**
![file](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/gold-user-assets/2019/9/29/16d7d728d1fafe5a~tplv-t2oaga2asx-image.image)

Интерфейс HTTP возвращает формат JSON и кодировку UTF-8. Если конфигурация не изменилась (входящий ключ релиза равен ключу сервера), будет возвращено значение HttpStatus 304, а тело ответа будет пустым; если конфигурация изменилась, будет возвращено значение HttpStatus 200, а тело ответа будет быть метаинформацией соответствующего пространства имен и всех элементов конфигурации в нем. Образец возвращаемого содержимого выглядит следующим образом

            {
            "appId": "100004458",
            "cluster": "default",
            "namespaceName": "application",
            "configurations": {
            "portal.elastic.document.type":"biz",
            "portal.elastic.cluster.name":"hermes-es-fws"
            },
            "releaseKey": "20170430092936-dee2d58e74515ff3"
            }
  • Обновления конфигурации App-Aware
    APOLLO обеспечивает настройку нажима на основании конфигурации HTTP HTTP-уведомление о опросе, сторонние клиенты могут видеть их фактические потребности решить, следует ли использовать эту функцию. Если не так чувствителен к времени обновления конфигурации, обновление может быть настроено для периодически обновления, частота обновления может быть установлена ​​в зависимости от самого приложения в случае, рекомендуется 30 секунд или более. Если вам нужно выполнить обновления конфигурации в реальном времени (одну секунду), вы можете обратиться к следующей документации для функции обновления конфигурации
    **配置更新推送实现思路**  建议参考Apollo的Java实现RemoteConfigLongPollService.java

инициализацияПрежде всего, нам нужно определить, какие пространства имен нужно настроить для обновления и отправки.Реализация Apollo заключается в том, что когда программа получает конфигурацию определенного пространства имен в первый раз, она регистрирует его, и мы будем знать, какие пространства имен нужны для настройки и обновления. Результатом после инициализации является получение Карты уведомлений, содержимое namespaceName ->notificationId (начальное значение равно -1). Если вы обнаружите, что существует новое пространство имен, которое необходимо настроить для обновления и отправки во время текущего процесса, вы можете напрямую подключить его к карте уведомлений.

запросить услугуС помощью карты уведомлений вы можете запрашивать услуги. Ниже приведено описание логики запроса услуг. Конкретные параметры и описания URL см. в следующих описаниях интерфейса.

        1.请求远端服务，带上自己的应用信息以及notifications信息
        2.服务端针对传过来的每一个namespace和对应的notificationId，检查notificationId是否是最新的
        3.如果都是最新的，则保持住请求60秒，如果60秒内没有配置变化，则返回HttpStatus 304。如果60秒内有配置变化，则返回对应namespace的最新notificationId, HttpStatus 200
        4.如果传过来的notifications信息中发现有notificationId比服务端老，则直接返回对应namespace的最新notificationId, HttpStatus 200
        5.客户端拿到服务端返回后，判断返回的HttpStatus
        6.如果返回的HttpStatus是304，说明配置没有变化，重新执行第1步
        7.如果返回的HttpStauts是200，说明配置有变化，针对变化的namespace重新去服务端拉取配置，参见1.3 通过不带缓存的Http接口从Apollo读取配置。同时更新notifications map中的notificationId。重新执行第1步
    HTTP接口说明
    URL {config_server_url}/notifications/v2?appId={appId}&cluster={clusterName}¬ifications={notifications}
    Method GET
    参数说明

file

СОВЕТЫ Поскольку сервер будет удерживаться в течение 60 секунд, убедитесь, что время ожидания для доступа клиента к серверу превышает 60 секунд; не забудьте URL-кодировать параметры

    HTTP返回格式  该Http接口返回的是JSON格式、UTF-8编码，包含了有变化的namespace和最新的notificationId。返回内容Sample如下
        [{
            "namespaceName": "application",
            "notificationId": 101
        }]

Руководство по распределенному развертыванию

Официальная стратегия развертывания заключается в развертывании набора Apollo-Portal+ApolloPortalDB в производственной среде и отдельном развертывании MetaServer+AdminService+ConfigService в других средах (PRO, UAT, FAT, DEV) и использовании независимой базы данных ApolloConfigDB и сервисов приложений. ; MetaServer и служба конфигурации развернуты в одном процессе JVM, служба администрирования развернута в другом процессе JVM на том же сервере. Пример развертывания выглядит следующим образомfileСетевая политика При распределенном развертывании службам apollo-configservice и apollo-adminservice необходимо зарегистрировать свой собственный IP-адрес и порт на сервере Meta Server (сама служба apollo-configservice). Клиент и портал Apollo получат служебный адрес (IP+PORT) от сервера Meta Server, а затем получат прямой доступ через служебный адрес. apollo-configservice и apollo-adminservice разработаны на основе доверенной сети интрасети, поэтому из соображений безопасности не размещайте напрямую apollo-configservice и apollo-adminservice в общедоступной сети.

    部署步骤
        创建数据库  Apollo服务端依赖于MYSQL数据库，所以需要事先创建并完成初始化
        获取安装包  Apollo服务端安装包共3个: Apollo-AdminService、Apollo-ConfigService、Apollo-Portal
        部署Apollo服务端  获取安装包后就可以部署到测试和生产环境

резюме

В этой статье подробно описываются проектирование, использование, доступ к приложениям и методы развертывания центра распределенной конфигурации с открытым исходным кодом Apollo.В настоящее время клиент имеет только версии Java и .Net.Доступ клиентов на других языках может периодически извлекать и обновлять конфигурация через HTTP-интерфейс.Проталкивание в режиме реального времени через механизм HTTP Long Polling для реализации обновления конфигурации с учетом приложений.

Категории