Либо Dubbo, либо Dubbox, в том числе до«Говоря о Даббо (1): почему выбирают»Другие фреймворки, представленные в ,Его суть — фреймворк удаленного вызова, а если нет распределённого требования к удалённым звонкам, то по сути и нет необходимости использовать столь тяжёлый фреймворк. распределение вызовов удаленных служб.Основное внимание уделяется распределенному управлению.. Какие основные функции фреймворк вроде Dubbox обеспечивает с точки зрения распределенного управления?

1 Основные функции Даббо

1. Удаленное общение: удаленное общение, который обеспечивает абстрактную инкапсуляцию различных инфраструктур NIO, включая режимы обмена информацией «синхронный-асинхронный» и «запрос-ответ».
2. Кластер: Сервисная структура, обеспечивает прозрачные удаленные вызовы процедур на основе методов интерфейса, включая поддержку нескольких протоколов и поддержку кластеров, таких как программная балансировка нагрузки, отказоустойчивость, маршрутизация адресов и динамическая конфигурация.
3. Реестр: Сервисный реестрНа основе службы каталогов реестра служба может потреблять только поставщик услуг динамического поиска, адрес прозрачен, так что поставщик услуг может увеличивать или уменьшать гладкую машину.

Какие роли компонентов Dubbo задействует для трех вышеупомянутых основных функций для совместной работы над распределенным управлением?

2 роли компонента Даббо

роль компонента	инструкция
Provider	Поставщик услуг, предоставляющий услугу
Consumer	Потребитель службы, вызывающий удаленную службу
Registry	Реестр для регистрации и обнаружения служб
Monitor	Центр мониторинга, который подсчитывает время вызова и время вызова сервисов.
Container	работающий сервисный контейнер

Описание вызывающих отношений:

1. Сервисный контейнер КонтейнерОтвечает за запуск, загрузку и работу поставщиков услуг.
2. поставщик услугПри запуске зарегистрируйте собственные службы в реестре.
3. Потребитель услуг ПотребительПри запуске подпишитесь в реестре на нужные вам услуги.
4. РеестрВозвращает список адресов поставщиков услуг потребителю. Если есть изменение, реестр передаст данные об изменении потребителю на основе постоянного подключения.
5. Потребитель услуг Потребитель, Из списка адресов провайдеров на основе алгоритма мягкой балансировки нагрузки выберите провайдера для звонка, а в случае сбоя звонка выберите другого провайдера для звонка.
6. Потребитель услуги Потребитель и поставщик Поставщик, накапливать в памяти количество звонков и время разговора, и регулярно отправлять статистические данные в центр мониторинга Монитор каждую минуту.

3 Общая архитектура Дуббо

Все вышеперечисленноеМожно сказать, что взаимосвязь компонентов на абстрактном уровне представляет собой вертикальный анализ компонентов с моделью обслуживания., на самом деле, самая большая особенность DubboМногоуровневая архитектура, используйте этот метод, чтобы отделить (или максимизировать слабую связь) между различными уровнями. так что мыВзгляните на архитектуру Dubbo горизонтально, многослойно., как показано на рисунке:

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

Ниже, в сочетании с официальными документами Dubbo, давайте разберемся с точками проектирования каждого уровня в многоуровневой архитектуре фреймворка:

1. Уровень интерфейса службы (служба): относится к фактической бизнес-логике, согласно поставщику услуг и потребителю услуг.Интерфейс и реализация, соответствующие бизнес-дизайну.
2. Уровень конфигурации (Config): внешний интерфейс конфигурации, сосредоточенный на ServiceConfig и ReferenceConfig, вы можете напрямую создать новый класс конфигурации или создать класс конфигурации с помощью конфигурации синтаксического анализа Spring.
3. Уровень сервисного прокси (прокси): прозрачный прокси интерфейса службы,Создание заглушки на стороне клиента и каркаса службы на стороне сервера., сосредоточенный на ServiceProxy, а интерфейс расширения — ProxyFactory.
4. Уровень реестра службы (Реестр): инкапсулирует регистрацию и обнаружение адресов службы, сосредоточенных на URL-адресе службы, и расширенными интерфейсами являются RegistryFactory, Registry и RegistryService. Реестра услуг может не быть, и в этом случае поставщик услуг напрямую предоставляет услугу.
5. Кластерный слой (кластер): инкапсулирует маршрутизацию и балансировку нагрузки нескольких провайдеров, а также соединяет реестр с Invoker в качестве центра и расширенными интерфейсами Cluster, Directory, Router и LoadBalance. Объединение нескольких поставщиков услуг в одного поставщика услуг обеспечивает прозрачность для потребителей услуг и требует взаимодействия только с одним поставщиком услуг.
6. Слой монитора (монитор): отслеживайте количество вызовов RPC и время вызова, используя статистику в качестве центра, а расширенные интерфейсы — MonitorFactory, Monitor и MonitorService.
7. Уровень удаленного вызова (протокол): инкапсулирует вызовы RPC, сосредоточенные на вызове и результате, а расширенными интерфейсами являются протокол, вызывающий и экспортер. Протокол — это служебный домен, это основная запись функции, предоставляемая и на которую ссылается Invoker, и она отвечает за управление жизненным циклом Invoker. Invoker — это домен объекта, это основная модель Dubbo, другие модели полагаются на него или преобразуются в него, он представляет собой исполняемое тело и может инициировать вызовы для него, это может быть локальная реализация или он может быть Является удаленной реализацией и, возможно, кластерной реализацией.
8. Уровень обмена информацией (Exchange): инкапсулирует режим ответа на запрос, от синхронного до асинхронного, с запросом и ответом в качестве центра, а расширенными интерфейсами являются Exchanger, ExchangeChannel, ExchangeClient и ExchangeServer.
9. Сетевой транспортный уровень (транспорт): абстрактные мина и нетти — это унифицированные интерфейсы, сосредоточенные на сообщении, а расширенные интерфейсы — это канал, транспортер, клиент, сервер и кодек.
10. Уровень сериализации данных (Serialize): некоторые инструменты многократного использования, расширенные интерфейсы: Serialization, ObjectInput, ObjectOutput и ThreadPool.

Как видно из приведенного выше рисунка,Для поставщиков услуг и потребителей услуг Dubbo предоставляет интерфейсы, о которых необходимо заботиться и которые необходимо расширять за счет 10 уровней структуры, а также строит всю экосистему услуг (поставщики услуг и сами потребители услуг ориентированы на услуги)..

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

1. В RPC Protocol является базовым уровнем, то есть пока есть Protocol + Invoker + Exporter, непрозрачные вызовы RPC могут выполняться, а затем Filter перехватывает точки на основном процессе Invoker.
2. Потребитель и Провайдер на рисунке являются абстрактными понятиями, и я просто хочу, чтобы зритель более интуитивно понимал, какие категории принадлежат клиенту и серверу Причина, по которой Клиент и Сервер не используются, заключается в том, что Dubbo использует Провайдер, Потребитель, Реестр , Monitor разделяет логические верхние узлы и поддерживает единую концепцию.
3. Кластер является периферийным понятием, поэтому цель Кластера состоит в том, чтобы замаскировать несколько Инвокеров под один Инвокер, чтобы другие обращали внимание только на Инвокера уровня Протокола. Добавление или удаление Кластера не повлияет на другие уровни, потому что только один обеспечивает В противном случае кластер не требуется.
4. Уровень Proxy инкапсулирует прозрачный прокси всех интерфейсов, в то время как другие уровни сосредоточены на Invoker. Только когда он предоставляется пользователю, Proxy используется для преобразования Invoker в интерфейс или реализация интерфейса преобразуется в Invoker. , то есть для удаления Proxy Layer RPC запустить можно, но он не такой прозрачный, и вроде не настраивает удаленные сервисы как локальные сервисы.
5. Реализация Remoting является реализацией протокола Dubbo. Если вы выберете протокол RMI, весь Remoting не будет использоваться. Remoting разделен на транспортный транспортный уровень и уровень обмена информацией Exchange. Транспортный уровень отвечает только за один способ передачи сообщений Абстракция Netty и Grizzly, он также может расширять транспорт UDP, а уровень Exchange инкапсулирует семантику запроса-ответа поверх транспортного уровня.
6. Реестр и Монитор на самом деле не слой, а независимый узел, просто для общего обзора, нарисованные вместе слоями.

4 Процесс вызова службы

5 Регистрация/снятие с учета услуг

Регистрация и отмена услуг выполняются поставщиком услуг, поэтому схема последовательности услуг регистрации и услуги отмены показана на рисунке:

6 Подписка/отмена услуг

Чтобы удовлетворить потребности прикладной системы, потребителю услуги может потребоваться подписаться на услугу, опубликованную назначенным поставщиком услуг из реестра услуг, и при уведомлении о том, что услуга может быть использована, услуга может быть вызвана напрямую. И наоборот, если услуга больше не нужна, ее можно отменить. Взгляните на соответствующую временную диаграмму ниже, как показано на рисунке:

7 ссылок и рекомендованной литературы

1. dubbo.io
2. Подробное объяснение дизайна архитектуры Dubbo