Введение в Dubbo (3) — Принципы архитектуры

Автор: No Dishwashing Studio - Marklux

Источник:Введение в Dubbo (3) — Принципы архитектуры

Все права принадлежат автору, при перепечатке указывать источник

предисловие

В предыдущих двух статьях мы узнали об основных концепциях и простом использовании распределенных сервисов. Теперь давайте посмотрим, как dubbo предоставляет эти функции, как это работает и какова общая иерархия фреймворка.

На эту статью ссылаетсяПодробное объяснение дизайна архитектуры DubboиОфициальное руководство пользователя Dubbo

основная функция

Прежде всего, мы должны понять три основные функции, предоставляемые Dubbo:

1. коммуникация

   Предоставляет множество абстрактных методов для платформы NIO, а также предоставляет множество методов для взаимной связи и вызова между различными службами. Включает синхронные, асинхронные модели, модели запросов и ответов.

2. Служба управления

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

3. Регистрационный центр

   Обеспечьте реестр услуг, чтобы услуги можно было динамически добавлять, удалять и обновлять в режиме реального времени для потребителей.

Архитектура узла

Обратитесь к этой диаграмме архитектуры узла, представленной в официальном руководстве dubbo:

Объясните роль каждого узла:

• Provider

  Поставщики открытых услуг

• Consumer

  Потребитель, вызывающий удаленную службу

• Container

  работающий сервисный контейнер

• Registry

  Реестр служб для обнаружения служб

• Monitor

  Центр мониторинга вызова службы статистики

Затем вам нужно понять общие отношения и процесс вызова:

1. Сервис-контейнер отвечает за запуск, загрузку и работу сервис-провайдера (его можно понимать как: бизнес-код, написанный сервис-провайдером для разработчика, а сервис-контейнер обеспечивает работающую среду, так что разработчику не нужно заботиться о деталях запуска и подключения)

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

3. Реестр возвращает список адресов поставщика услуг потребителю.Если есть изменение, реестр передаст данные об изменении потребителю на основе постоянного подключения.

4. Потребитель услуги из списка адресов провайдера выбирает провайдера для вызова на основе алгоритма мягкой балансировки нагрузки и, если вызов завершается неудачно, выбирает другого провайдера для вызова.

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

Преимущества

Вышеупомянутая архитектура узла привносит в dubbo несколько очень мощных функций, которые также являются преимуществами dubbo:

возможность подключения

Все узлы подключены, а потребление сетевых вызовов снижено за счет оптимизации.

Отражено:

• Центр регистрации отвечает за регистрацию и поиск адресов службы, что эквивалентно службе каталогов. Поставщики услуг и потребители взаимодействуют с центром регистрации только при запуске. Центр регистрации не пересылает запросы, и нагрузка невелика.
• Центр мониторинга отвечает за подсчет количества вызовов службы, времени вызова и т. д. Сначала статистика собирается в памяти и каждую минуту отправляется на сервер центра мониторинга, а затем отображается в отчете.
• Поставщик услуг регистрирует предоставляемые им услуги в центре регистрации и сообщает о времени вызова в центр мониторинга, который не включает накладные расходы сети.
• Потребитель услуг получает список адресов поставщиков услуг из центра регистрации, напрямую звонит провайдеру в соответствии с алгоритмом загрузки и сообщает центру мониторинга время звонка, которое включает в себя накладные расходы сети.
• Центр регистрации, поставщик услуг и потребитель услуг являются долгосрочными соединениями, за исключением центра мониторинга.
• Центр регистрации воспринимает существование поставщика услуг через длинное соединение.Если поставщик услуг не работает, центр регистрации немедленно подтолкнет событие, чтобы уведомить потребителя.
• Центр регистрации и центр мониторинга отключены, что не влияет на работающих провайдеров и потребителей, а потребитель кэширует список поставщиков локально.
• Центр регистрации и центр мониторинга не являются обязательными, и потребители услуг могут напрямую подключаться к поставщикам услуг.

прочность

Даже если какие-то узлы в сервисе не будут работать должным образом, система в целом не рухнет, а минимизирует потери за счет множества отказоустойчивых стратегий.

Отражено:

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

Масштабируемость

Когда масштаб службы необходимо скорректировать, нет необходимости приостанавливать службу и повторно развертывать ее, но ее можно динамически переключать, что отражается как:

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

Возможность обновления

По мере дальнейшего роста сервисного кластера может потребоваться переход на гибкую вычислительную архитектуру. Но сама сервисная структура dubbo не окажет сопротивления обновлению.

Горизонтальная иерархия

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

Структура Dubbo разделена на 10 уровней, а верхний уровень Service — это уровень интерфейса для разработчиков, которые действительно хотят использовать Dubbo для разработки распределенных сервисов для реализации бизнес-логики. Светло-голубой фон слева на рисунке — это интерфейс, используемый потребителем услуги, светло-зеленый фон справа — это интерфейс, используемый поставщиком услуги, а интерфейс, расположенный на центральной оси, — это интерфейс, используемый обеими сторонами. .

Функция каждого уровня кратко объясняется ниже (поскольку я не читал исходный код, поэтому я просто ссылаюсь на личное понимание документа)

1. Уровень интерфейса службы (служба)

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

2. Уровень конфигурации (Config)

   Где настроить общие параметры запуска.

3. Уровень сервисного прокси (прокси)

   Интерфейс вызывает прозрачный прокси, который преобразует Invoker в интерфейс, напрямую вызываемый пользователем. Без этого уровня RPC по-прежнему можно реализовать, но пользователям необходимо вручную формировать Invoker, и прозрачные вызовы не могут быть реализованы.

4. Уровень регистрации службы (реестр)

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

5. Кластерный слой (кластер)

   Инкапсулирует маршруты для нескольких поставщиков и обеспечивает балансировку нагрузки, соединяя реестры. Карта, реализующая интеграцию нескольких поставщиков услуг в одного поставщика услуг.

6. Уровень мониторинга (Монитор)

   Определите количество вызовов RPC и ситуацию вызова.

7. Уровень удаленного вызова (протокол)

   Основной уровень, который инкапсулирует вызовы RPC. Протокол отвечает за управление жизненным циклом Invokers. Invoker — это основная модель Dubbo, представляющаяисполняемый, все вызовы основаны на Invoker, будь то локальные или удаленные вызовы или кластерные вызовы.

8. Уровень обмена информацией (Exchange)

   Инкапсулирует различные режимы связи: запрос-ответ, синхронный в асинхронный и т. д.

9. Сетевой транспортный уровень (транспорт)

   Abstract mina и netty — это унифицированные интерфейсы, предоставляющие базовые возможности nio.

10. Уровень сериализации данных (Serialize)

    Предоставьте несколько основных инструментов многократного использования.

Анализ потока вызовов

На основе следующего рисунка проанализируйте отношения планирования между потребителями услуг и поставщиками услуг на уровне RPC.

Как мы резюмировали ранее, он в основном делится на 3 этапа:

1. Поставщик услуг публикует услугу в реестре услуг.
2. Потребитель услуги подписывается на услугу из реестра
3. Вызывающий службу вызывает службу по подписке

Разверните детали и обратитесь к следующему рисунку:

резюме

Сама структура даббо не сложная, слои четкие.

Понимание архитектуры dubbo помогает понять идеи дизайна распределенных систем и облегчает начало работы.

Реализация системы dubbo также будет проанализирована с точки зрения исходного кода.

предисловие

В предыдущих двух статьях мы узнали об основных концепциях и простом использовании распределенных сервисов. Теперь давайте посмотрим, как dubbo предоставляет эти функции, как это работает и какова общая иерархия фреймворка.

На эту статью ссылаетсяПодробное объяснение дизайна архитектуры DubboиОфициальное руководство пользователя Dubbo

основная функция

Прежде всего, мы должны понять три основные функции, предоставляемые Dubbo:

1. коммуникация

   Предоставляет множество абстрактных методов для платформы NIO, а также предоставляет множество методов для взаимной связи и вызова между различными службами. Включает синхронные, асинхронные модели, модели запросов и ответов.

2. Служба управления

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

3. Регистрационный центр

   Обеспечьте реестр услуг, чтобы услуги можно было динамически добавлять, удалять и обновлять в режиме реального времени для потребителей.

Архитектура узла

Обратитесь к этой диаграмме архитектуры узла, представленной в официальном руководстве dubbo:

Объясните роль каждого узла:

• Provider

  Поставщики открытых услуг

• Consumer

  Потребитель, вызывающий удаленную службу

• Container

  работающий сервисный контейнер

• Registry

  Реестр служб для обнаружения служб

• Monitor

  Центр мониторинга вызова службы статистики

Затем вам нужно понять общие отношения и процесс вызова:

1. Сервис-контейнер отвечает за запуск, загрузку и работу сервис-провайдера (его можно понимать как: бизнес-код, написанный сервис-провайдером для разработчика, а сервис-контейнер обеспечивает работающую среду, так что разработчику не нужно заботиться о деталях запуска и подключения)

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

3. Реестр возвращает список адресов поставщика услуг потребителю.Если есть изменение, реестр передаст данные об изменении потребителю на основе постоянного подключения.

4. Потребитель услуги из списка адресов провайдера выбирает провайдера для вызова на основе алгоритма мягкой балансировки нагрузки и, если вызов завершается неудачно, выбирает другого провайдера для вызова.

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

Преимущества

Вышеупомянутая архитектура узла привносит в dubbo несколько очень мощных функций, которые также являются преимуществами dubbo:

возможность подключения

Все узлы подключены, а потребление сетевых вызовов снижено за счет оптимизации.

Отражено:

• Центр регистрации отвечает за регистрацию и поиск адресов службы, что эквивалентно службе каталогов. Поставщики услуг и потребители взаимодействуют с центром регистрации только при запуске. Центр регистрации не пересылает запросы, и нагрузка невелика.
• Центр мониторинга отвечает за подсчет количества вызовов службы, времени вызова и т. д. Сначала статистика собирается в памяти и каждую минуту отправляется на сервер центра мониторинга, а затем отображается в отчете.
• Поставщик услуг регистрирует предоставляемые им услуги в центре регистрации и сообщает о времени вызова в центр мониторинга, который не включает накладные расходы сети.
• Потребитель услуг получает список адресов поставщиков услуг из центра регистрации, напрямую звонит провайдеру в соответствии с алгоритмом загрузки и сообщает центру мониторинга время звонка, которое включает в себя накладные расходы сети.
• Центр регистрации, поставщик услуг и потребитель услуг являются долгосрочными соединениями, за исключением центра мониторинга.
• Центр регистрации воспринимает существование поставщика услуг через длинное соединение.Если поставщик услуг не работает, центр регистрации немедленно подтолкнет событие, чтобы уведомить потребителя.
• Центр регистрации и центр мониторинга отключены, что не влияет на работающих провайдеров и потребителей, а потребитель кэширует список поставщиков локально.
• Центр регистрации и центр мониторинга не являются обязательными, и потребители услуг могут напрямую подключаться к поставщикам услуг.

прочность

Даже если какие-то узлы в сервисе не будут работать должным образом, система в целом не рухнет, а минимизирует потери за счет множества отказоустойчивых стратегий.

Отражено:

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

Масштабируемость

Когда масштаб службы необходимо скорректировать, нет необходимости приостанавливать службу и повторно развертывать ее, но ее можно динамически переключать, что отражается как:

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

Возможность обновления

По мере дальнейшего роста сервисного кластера может потребоваться переход на гибкую вычислительную архитектуру. Но сама сервисная структура dubbo не окажет сопротивления обновлению.

Горизонтальная иерархия

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

Структура Dubbo разделена на 10 уровней, а верхний уровень Service — это уровень интерфейса для разработчиков, которые действительно хотят использовать Dubbo для разработки распределенных сервисов для реализации бизнес-логики. Светло-голубой фон слева на рисунке — это интерфейс, используемый потребителем услуги, светло-зеленый фон справа — это интерфейс, используемый поставщиком услуги, а интерфейс, расположенный на центральной оси, — это интерфейс, используемый обеими сторонами. .

Функция каждого уровня кратко объясняется ниже (поскольку я не читал исходный код, поэтому я просто ссылаюсь на личное понимание документа)

1. Уровень интерфейса службы (служба)

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

2. Уровень конфигурации (Config)

   Где настроить общие параметры запуска.

3. Уровень сервисного прокси (прокси)

   Интерфейс вызывает прозрачный прокси, который преобразует Invoker в интерфейс, напрямую вызываемый пользователем. Без этого уровня RPC по-прежнему можно реализовать, но пользователям необходимо вручную формировать Invoker, и прозрачные вызовы не могут быть реализованы.

4. Уровень регистрации службы (реестр)

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

5. Кластерный слой (кластер)

   Инкапсулирует маршруты для нескольких поставщиков и обеспечивает балансировку нагрузки, соединяя реестры. Карта, реализующая интеграцию нескольких поставщиков услуг в одного поставщика услуг.

6. Уровень мониторинга (Монитор)

   Определите количество вызовов RPC и ситуацию вызова.

7. Уровень удаленного вызова (протокол)

   Основной уровень, который инкапсулирует вызовы RPC. Протокол отвечает за управление жизненным циклом Invokers. Invoker — это основная модель Dubbo, представляющаяисполняемый, все вызовы основаны на Invoker, будь то локальные или удаленные вызовы или кластерные вызовы.

8. Уровень обмена информацией (Exchange)

   Инкапсулирует различные режимы связи: запрос-ответ, синхронный в асинхронный и т. д.

9. Сетевой транспортный уровень (транспорт)

   Abstract mina и netty — это унифицированные интерфейсы, предоставляющие базовые возможности nio.

10. Уровень сериализации данных (Serialize)

    Предоставьте несколько основных инструментов многократного использования.

Анализ потока вызовов

На основе следующего рисунка проанализируйте отношения планирования между потребителями услуг и поставщиками услуг на уровне RPC.

Как мы резюмировали ранее, он в основном делится на 3 этапа:

1. Поставщик услуг публикует услугу в реестре услуг.
2. Потребитель услуги подписывается на услугу из реестра
3. Вызывающий службу вызывает службу по подписке

Разверните детали и обратитесь к следующему рисунку:

резюме

Сама структура даббо не сложная, слои четкие.

Понимание архитектуры dubbo помогает понять идеи дизайна распределенных систем и облегчает начало работы.

Реализация системы dubbo также будет проанализирована с точки зрения исходного кода.