1. Введение
Apollo [см. приложение] — это продукт центра конфигурации производственного уровня, разработанный и открытый отделом Ctrip Framework. Он может централизованно управлять конфигурацией приложений в различных средах и кластерах. После модификации конфигурации его можно передать на сторону приложения. в режиме реального времени, а также имеет стандартизированные разрешения, управление процессами и другие функции, подходящие для сценариев управления конфигурацией микросервисов.
В настоящее время Apollo относительно популярен в сообществе отечественных разработчиков, с более чем 5 тысячами звезд на Github, и у многих отечественных интернет-компаний есть посадочные кейсы.Можно сказать, что Apollo является продуктом номер 1 в текущей области продуктов центра конфигурации и его зрелости. и функции корпоративного уровня далеко намного сильнее, чем продукт Spring Cloud Config в системе Spring Cloud.
Apollo использует распределенную микросервисную архитектуру, и ее архитектура немного сложна.Хотя Сун Шун, автор Apollo, дал архитектурную диаграмму, если нет определенной основы распределенной микросервисной архитектуры, рядовым разработчикам и даже архитекторам очень сложно понять сразу. Чтобы дать всем лучшее понимание архитектурного дизайна Аполлона, я воспользовался моментом, чтобы заново проанализировать архитектуру Аполлона по-своему. Только полностью поняв архитектуру Apollo, вы сможете лучше развертывать и использовать Apollo в производственной практике. Кроме того, изучив архитектуру Apollo, вы сможете глубоко понять некоторые основные принципы микросервисной архитектуры.
2. Архитектура и модули
На следующем рисунке представлена архитектурная схема, данная Сун Шуном, автором «Аполлона»:
Схема архитектуры Аполлона, автор Сун Шунь
Если у вас недостаточно знаний для распределенной микросервисной архитектуры и вы не знаете о некоторых фреймворках Ctrip (таких как Software Load Balancer (SLB)), то эту архитектурную диаграмму с первого взгляда не так просто понять (на самом деле, это мой первый раз, когда я не понял эту структуру, когда увидел ее). Давайте сначала поместим это здесь.После того, как я позже повторно проанализирую эту архитектуру, будет легко понять, когда вы оглянетесь на эту архитектуру.
Ниже приведены семь модулей Apollo, четыре из которых являются основными модулями, связанными с функциями, а остальные три модуля являются вспомогательными модулями обнаружения служб:
Четыре основных модуля и их основные функции
1. ConfigService
- Предоставление интерфейса доступа к конфигурации
- Обеспечьте push-интерфейс конфигурации
- Обслуживание клиентов Аполлона
2. AdminService
- Предоставляет интерфейс управления конфигурацией
- Обеспечить модификацию конфигурации и интерфейс публикации
- Обслуживание интерфейса управления Портал
3. Client
- Получите конфигурацию для приложения, поддержите обновление в реальном времени
- Получить список сервисов ConfigService через MetaServer
- Вызовите ConfigService, используя метод SLB с плавной загрузкой клиента.
4. Portal
- Интерфейс управления конфигурацией
- Получить список услуг AdminService через MetaServer
- Вызовите AdminService, используя метод SLB с плавной загрузкой клиента.
Три вспомогательных модуля обнаружения служб
1. Eureka
- для обнаружения и регистрации услуг
- Config/AdminService регулярно регистрирует экземпляры и сообщает о контрольных точках
- Живое развертывание с помощью ConfigService
2. MetaServer
- Портал обращается к MetaServer через доменное имя, чтобы получить список адресов AdminService.
- Клиент обращается к метазеру через доменное имя, чтобы получить список адресов Configservice
- Эквивалент прокси-сервера Eureka
- Логические роли, живые и развертываемые с помощью ConfigService
3. NginxLB
- Сотрудничайте с Системой доменных имен, чтобы помочь порталу получить доступ к MetaServer для получения списка адресов AdminService.
- Сотрудничайте с Системой доменных имен, чтобы помочь Клиенту получить доступ к MetaServer для получения списка адресов ConfigService.
- Сотрудничайте с системой доменных имен, чтобы помочь пользователям получить доступ к порталу для управления конфигурацией.
3. Анализ архитектуры
Архитектура Аполлона V1
Если не учитывать проблему обнаружения сервисов в распределенной микросервисной архитектуре, минимальная архитектура Apollo показана на следующем рисунке:
Архитектура Apollo V1 от Ян Бо
Ключевые моменты:
- ConfigService — это независимый микросервис, который служит клиенту для получения конфигурации.
- Клиент и служба ConfigService поддерживают длительное соединение.В режиме push-and-pull конфигурация обновляется в режиме реального времени, гарантируя, что обновление конфигурации не будет потеряно.
- AdminService — это независимая микрослужба, которая служит порталу для управления конфигурацией. Портал выполняет управление конфигурацией и публикацию, вызывая AdminService.
- ConfigService и AdminService совместно используют ConfigDB, в которой хранится информация о конфигурации проекта в определенной среде. ConfigService/AdminService/ConfigDB должны быть развернуты в каждой среде (DEV/FAT/UAT/PRO).
- У портала есть отдельная база данных PortalDB, в которой хранятся метаданные о разрешениях пользователей, проектах и конфигурациях. Порталу нужно развернуть только одну копию, и он может управлять несколькими средами.
Архитектура Аполлона V2
Чтобы обеспечить высокую доступность, и ConfigService, и AdminService не имеют состояния и развернуты в кластере.В настоящее время существует проблема обнаружения службы: как клиент находит ConfigService? Как портал находит AdminService? Чтобы решить эту проблему, Apollo представила компонент реестра службы Eureka в своей архитектуре для реализации регистрации службы и обнаружения между микрослужбами.Обновленная архитектура показана на следующем рисунке:
Архитектура Apollo V2 от Ян Бо
Ключевые моменты:
- После запуска Config/AdminService он будет зарегистрирован в реестре службы Eureka, и будет регулярно отправляться контрольное сообщение.
- Eureka развертывается в кластерах и использует протокол распределенного консенсуса, чтобы гарантировать, что состояние каждого экземпляра в конечном итоге будет согласованным.
Архитектура Аполлона V3
Мы знаем, что Eureka — это Java-клиент со своим собственным сервисом обнаружения.Если Apollo поддерживает только клиентский доступ Java и не поддерживает клиентский доступ на других языках, то Client и Portal нужно только ввести Java-клиент Eureka для реализации сервисов.Функция обнаружения. После того как целевая служба обнаружена, ее можно перенаправить в экземпляр целевой службы через программную загрузку клиента (SLB, например Ribbon). Это классическая микросервисная архитектура, основанная на Eureka для обнаружения регистрации службы + клиентская лента для обеспечения мягкой маршрутизации, как показано на следующем рисунке.
Архитектура Apollo V3 от Ян Бо
Архитектура Аполлона V4
В Ctrip сценарии приложений включают не только Java, но и многие устаревшие приложения .Net. Автор Apollo также считает, что после того, как исходный код был открыт для сообщества, многие пользовательские приложения не поддерживают Java. Однако Eureka (включая мягкую загрузку Ribbon) изначально поддерживает только клиенты Java.Если вы хотите разработать клиенты Eureka/Ribbon для нескольких языков, рабочая нагрузка будет очень большой и неконтролируемой. С этой целью автор Apollo представил роль MetaServer, которая на самом деле является прокси-сервером Eureka, который предоставляет интерфейс обнаружения служб Eureka в виде более простого и явного HTTP-интерфейса, который удобно использовать для запросов Client/Protal через простой HTTPClient Список адресов для Config/AdminService. После получения списка адресов экземпляров службы используйте простую мягкую загрузку клиента (Client SLB) маршрутизация политики находит целевой экземпляр и инициирует вызов.
Теперь другой вопрос, сам MetaServer тоже развернут в кластерном режиме без состояния, так как же Client/Protal обнаруживает MetaServer? Традиционный подход заключается в использовании аппаратного или программного балансировщика нагрузки.Например, Ctrip использует расширенный NginxLB (также известный как программный балансировщик нагрузки), а при эксплуатации и обслуживании настраивается доменное имя для кластера MetaServer, чтобы оно указывало на кластер NginxLB. Балансировка нагрузки и переадресация трафика. Клиент/Портал косвенно обращается к кластеру MetaServer через доменное имя + NginxLB.
Архитектура после внедрения MetaServer и NginxLB показана на следующем рисунке:
Архитектура Apollo V4 от Ян Бо
Архитектура Аполлона V5
Версия V4 уже представляет собой полную картину архитектуры Apollo, и теперь осталось еще последнее звено: Portal также не имеет состояния и развернут в кластере.Как пользователи обнаруживают и получают доступ к Portal? Ответ — тоже простая традиционная практика: пользователи косвенно обращаются к кластеру MetaServer через доменное имя + NginxLB.
Таким образом, версия V5 является окончательной архитектурой Apollo, включая пользовательскую сторону, как показано на следующем рисунке:
Архитектура Apollo V5 от Ян Бо
4. Вывод
1. После моего анализа в третьей части, я считаю, что у всех будет более четкое представление об архитектуре микросервиса Аполлона.В качестве вопроса, давайте вернемся к архитектурной диаграмме, приведенной Сонг Шуном во второй части.Вы понимаете? Насколько это соответствует моей архитектуре? Напоминаю, что точка зрения Сун Шуня — сверху вниз, а моя — сбоку.
2. ConfgService/AdminService/Client/Portal — это четыре основных модуля микросервиса Apollo, которые взаимодействуют друг с другом для выполнения бизнес-функции центра конфигурации Eureka/MetaServer/NginxLB — это модули, помогающие обнаруживать сервисы между микросервисами.
3. Apollo использует микросервисную архитектуру.Архитектура и развертывание несколько сложны, но каждый сервис несет единственную ответственность и легко расширяется. Кроме того, Apollo может централизованно управлять конфигурациями в нескольких средах (DEV/FAT/UAT/PRO) только с одним набором Portal, что является изюминкой его архитектуры. .
4. Обнаружение служб является основой микросервисной архитектуры В микросервисной архитектуре Apollo используются как обнаружение служб в стиле реестра Eureka, так и централизованное обнаружение служб в стиле прокси-сервера NginxLB.
Недавно я сотрудничал с Geek Time, в сочетании с моим многолетним практическим опытом построения архитектуры на передовых предприятиях, и запустил видеокурс «Практика микросервисной архитектуры 160 лекций», Благодаря объяснению принципа и практической работе он поможет вам понять мейнстрим от 0 до 1. Формирование и архитектура стека технологий микросервисов, встаньте на продвинутый путь от программиста до архитектора.
5. Приложение
Оцените эту статью