Введение: Официальный Spring RSocket Broker разрабатывался давно, я думал, что он будет выпущен вместе с Spring Cloud 2021.0, но этого не произошло. Тем не менее, Spring RSocket Broker выпустил последнюю версию 0.3. Хотя это все еще предварительная версия, она в настоящее время доступна.Учитывая, что официальный документ еще не предоставлен, всем все еще сложно начать работу и сделать демо, поэтому Эта статья предназначена для того, чтобы помочь вам быстро начать работу со Spring RSocket Broker и проанализировать характеристики RSocket Broker.

Автор Гром Том
Источник | Публичная учетная запись Alibaba Technology

Официальный Spring RSocket Broker на самом деле разрабатывался давно, я думал, что он будет выпущен вместе с Spring Cloud 2021.0, но этого не произошло. Тем не менее, Spring RSocket Broker выпустил последнюю версию 0.3. Хотя это все еще предварительная версия, она в настоящее время доступна.Учитывая, что официальный документ еще не предоставлен, всем все еще сложно начать работу и сделать демо, поэтому Эта статья предназначена для того, чтобы помочь вам быстро начать работу со Spring RSocket Broker и проанализировать характеристики RSocket Broker.

Архитектура Spring RSocket Broker

Сначала давайте взглянем на архитектурную схему Spring RSocket Broker следующим образом:

Rsocket Broker предоставляет внешнюю службу поддержки кластера, его основное обслуживание является экспедированием для регистрации приложений и запроса RSCOcke, и каждый брокер в кластере поддерживает единую глобальную таблицу маршрутизации. Rsocket Broker имеет два порта прослушивания: порт 8001 в основном отвечает за предоставление внешнего RSCocket Service, например, длительное соединение между брокером, а затем передача и прием запроса RSCOcke в течение длительного подключения. Порт 7001 в основном отвечает за связь между узлами брокеров в кластере, таких как пошаговая информация об метаданных, для обеспечения единства таблицы маршрутизации Global Service, а также переадресация по запросу между брокером и протоколом связи между брокером все еще Rsocket.

Когда сервисное приложение устанавливает соединение с Брокером, оно отправляет Брокеру некоторую базовую информацию.Соответствующие атрибуты в основном включают: идентификатор узла маршрутизации (routeId), имя службы (имя-службы) и теги (теги).

• Идентификатор узла маршрутизации (routeId): это уникальный идентификатор, применяемый к длинному соединению, созданному брокером. Обычно это UUID. Конечно, он также может быть указан пользователем. Уникальность соединения сделает обработку глобальная таблица маршрутизации каждого брокерского кластера намного проще. Обратите внимание, что routeId — это идентификатор длинного соединения, а не идентификатор приложения, идентификатор приложения идентифицируется тегами. Если приложение и брокер создают два длинных соединения, то есть два разных routeId.Конечно, в этом случае каждое соединение может предоставить другое имя службы.
• Имя службы: на самом деле это DNS-имя службы.Если другие приложения хотят вызывать службу RSocket, предоставляемую приложением, им необходимо указать имя службы. Хотя Spring RSocket предоставляет messageMapping, ключ сопоставления является внутренним для приложения и не может быть гарантированно уникальным в глобальном масштабе.Только имя службы + ключ сопоставления RSocket могут найти указанную службу.Это согласуется с принципом http: ключ сопоставления аналогичен на HTTP-путь, а имя службы похоже на доменное имя.
• Метка: Метка используется для идентификации службы RSocket, предоставляемой приложением.Конечно, спецификация RSocket Broker также предоставляет некоторые метки по умолчанию, такие как InstanceName, ClusterName, Region, MajorVersion и т. д. Теги — это не просто метаинформация о сервисах, они также могут участвовать в маршрутизации сервисов. Например, вы можете установить версию службы, имя кластера и т. д., направленная маршрутизация, которая была самой большой проблемой при разработке, может быть легко решена с помощью метки, например, вы можете пометить службу с помощью InstanceName=app-leijuan. , а затем задайте InstanceName в вызове для вызова разработчика. Экземпляр службы, запущенный пользователем. Вам не нужно беспокоиться о производительности маршрутизации на основе тегов, за ней стоит Roaring BitMap, а скорость очень высока.

Приложения могут регистрироваться на одном или нескольких узлах RSocket Broker в кластере, в зависимости от конфигурации Broker Client, о которой мы поговорим позже.

Примечание. Не воспринимайте ServiceName как полное имя интерфейса Java, например com.example.user.UserService, тогда, когда приложение имеет несколько таких служб Java, с ним будет сложнее иметь дело. На самом деле имя_службы в основном используется для маршрутизации запросов. Например, приложение-служба включает в себя несколько интерфейсов службы, таких как UerService и UserExtraService. Можно задать для имени службы значение com.example.user. Конечно, необходимо убедиться, что имя службы уникально. Исходный ключ маршрутизации RSocket настроен.Для метода Имя интерфейса + Имя метода UserService.findUserById проблем нет.

После того, как приложение зарегистрировано на брокере, если приложение хочет вызвать определенную службу RSocket, ему нужно только инициировать запрос вызова RSocket к брокеру в соответствии с именем службы + ключом маршрутизации, и тогда брокер найдет службу, которая может предоставить услугу в соответствии с внутренней глобальной таблицей маршрутизации. Узел службы (RouteId), а затем перенаправляет запрос на соответствующий узел службы. После обработки узла службы он возвращает ответ брокеру, а брокер возвращает ответ звонящему.

Если на текущем узле брокера нет соответствующего доступа к сервисному маршруту, это брокер, который перенаправляет запрос брокеру с сервисным узлом, который является переадресацией запроса, а затем возвращает результат, обработанный этим брокером, вызывающей стороне. Некоторые студенты могут спросить, может быть бесконечный цикл цепочки вызовов, например, брокер 1 перенаправляет запрос брокеру 3, служба на брокере 3 внезапно отключается, и брокер 3 может отправить его обратно брокеру 1, а затем брокер 1 обнаруживает, что другие брокеры отправляют? Этой ситуации не произойдет.Брокеры будут синхронизировать онлайн- и офлайн-информацию приложений, поэтому каждый брокер поддерживает единую глобальную таблицу маршрутизации для кластера, поэтому брокер1 перенаправляет сообщения брокеру2, и должно быть маршрутное соединение для соответствующей службы на брокере2. если на брокере2 возникла авария и маршрут, соответствующий сервису, пропал, он будет переадресован брокеру с сервисом.Конечно, если он не найден, запрос в это время будет удерживаться брокером, и ошибка будет возвращена после тайм-аута.

Два примера проекта Spring RSocket Broker

Далее мы рассмотрим реальный пример разработки, три приложения: сервер-брокер, поставщик услуг и вызывающая служба. Пакет разработки, соответствующий Spring RSocket Broker, отправлен в репозиторий Maven, и вы можете просмотреть его в конце статьи.

1 RSocket Broker Server

RSocket Broker Server — это стандартное приложение Spring Boot, вам нужно только добавить следующие зависимости в приложение Spring Boot:

Затем добавьте следующую конфигурацию в файл application.yaml:

Затем запустите приложение Spring Boot, и Брокер запустится и будет прослушивать порты 7001 и 8001. Некоторые студенты могут спросить, почему бы не предоставить независимое приложение для запуска RSocket Broker? Это может быть связано с отправной точкой проекта Spring Cloud. Как и Spring Config Server и Registry Server, все они встроены в приложение. В основном это помогает разработчикам настраивать функции брокера, такие как добавление веб-консоли. , подключение к системе Ops и т. д., и гибкость будет снижена очень высокая.

2 RSocket Service Provider

Далее мы создадим приложение Spring Boot для предоставления сервисов RSocket во внешний мир.Сначала добавим следующие зависимости: spring-boot-starter-rsocket является стандартным, что удобно для приложений Spring Boot для интеграции RSocket, и rsocket-broker -client-spring, это клиент Spring брокера, который отвечает за завершение соединения с брокером RSocket.

Затем добавьте следующую конфигурацию клиента брокера в application.yaml приложения-службы.Здесь должно быть объяснено имя службы.Рекомендуется использовать метод именования DNS, упомянутый выше, чтобы гарантировать, что имя службы не будет конфликтовать. Далее идет список адресов брокеров, а именно:

Далее нам также нужно написать сервис RSocket, который является стандартным Spring RSocket, Код выглядит следующим образом:

Затем мы запускаем сервисное приложение, и мы увидим информацию о том, что приложение зарегистрировано в Брокере в выводе журнала RSocket Broker, так что служба RSocket завершила регистрацию на Брокере.

3 RSocket Service Consumer

Затем нам нужно создать приложение для вызова службы RSocket.Как и приложение службы, добавьте те же зависимости.Поскольку приложение не предоставляет службы RSocket для внешнего мира, вы можете настроить имя службы на пространство имен + имя приложения, в основном: Не иметь того же имени, что и другие приложения, а именно:

Следующим шагом является написание веб-контроллера для доступа к службе RSocket, просто внедрите Bean-компонент BrokerRSocketRequester, а затем вызовите службу RSocket, что аналогично использованию RSocketRequester в Spring RSocket.Код выглядит следующим образом:

Как только вы начнете приложение, вы можете использовать команду curl для тестирования, вы можете увидеть знакомый вывод Hello Ping.

Вы можете подумать, что этот клиентский вызов относительно примитивен.На самом деле вам нужно только интегрировать spring-retrosocket, а затем знакомый вам интерфейс Java, например:

Три мысли о Spring RSocket Broker

1 Особенности брокера RSocket

Spring RSocket Broker разрабатывался давно, все разработчики — члены команды Spring Cloud, Олег имеет большой опыт работы с Reactive и RSocket, Спенсер также является основным архитектором Spring Cloud. Спенсер говорил об изменениях, внесенных RSocket в Spring Cloud на нескольких конференциях, что является полностью подрывным. Также из приведенного выше примера приложения видно, не говоря уже о полностью асинхронной производительности Reactive, вам больше не нужно регистрировать сервисы, и вам не нужно локально запускать отвечающий порт. услуги могут передаваться через брокера, совершать взаимные звонки. Что касается преимуществ RSocket Broker, Spring RSocket Broker имеет соответствующие инструкции, а именно:

Routing and forwarding are used to forward RSocket requests between two RSocket connections via broker. In some cases, point-to-point interactions between a client and server are enough, in an enterprise environment, it is useful to decouple the client and server from each other. Some examples of why decoupling is necessary include blue/green deployments, load balancing, A/B testing, feature toggles, etc. Additionally, providing an intermediary can help with security and scalability. Finally, with the load balancing, routing and QoS, better overall application latency and throughput can be achieved than by direct connections.

2 Решения для прямого общения в RSocket Broker

У некоторых студентов могут возникнуть сомнения, будет ли определенная потеря производительности через RSocket Broker, у моего приложения QPS очень высокий, задержки быть не может. Не беда, помните, что в сервисное приложение была добавлена ​​зависимость spring-boot-starter-rsocket? Нам нужно только добавить следующие элементы конфигурации в application.yaml, чтобы открыть порт прослушивания службы RSocket, а затем использовать метаинформацию, предоставленную RSocket Broker, а затем мы используем RSocketRequester для создания соединения с целевой службой. Какая-то нагрузка есть, но она уже очень маленькая, нам просто нужно использовать Reactor-pool для автоматического управления пулом подключений прямых подключений.

3 Rsocket Broker запрос в ожидании

Spring RSocket Broker Также представлена ​​поддержка отложенного обслуживания на линии. В качестве примера предположим, что приложение-1 и служба-1 работают нормально в сети, вдруг служба-1 является примером друзей в автономном режиме, на этот раз запрос, отправленный из приложения-1, не может найти целевой узел, на этот раз как быть с участием?

• Отклонить запрос и немедленно вернуть отказ: это то, что мы часто называем отказоустойчивым дизайном, который часто используется при проектировании архитектуры предприятия. Если вы используете синхронную связь и режим пула потоков, вы в основном должны использовать этот дизайн, иначе долгосрочная блокировка потока немедленно сделает ваш сервис неспособным отвечать на запросы.
• Ожидание подключения службы к сети: Брокер сначала удерживает запрос, а затем ждет, пока служба подключится к сети, прежде чем перенаправить его в онлайн-службу. Такой дизайн иногда очень полезен. Например, в сценарии FaaS шлюз подтвердил существование функции. В настоящее время функция находится только в автономном режиме, поэтому вы можете активировать функцию для перехода в режим онлайн, а затем запросить ожидание. Кроме того, существует проблема сетевого джиттера, из-за которого соединение будет прервано.В это время вы также можете подождать, пока служба не подключится к сети. Другой сценарий — сервис-релиз, например, есть только один экземпляр длиннохвостового сервиса, пока вы можете перезапустить приложение в течение 3-5 секунд, брокер может помочь вам удержать запрос, а затем сотрудничать с клиентом. retry. , даже если есть только один экземпляр, служба не будет считаться прерванной. Например, в K8S установите последний образ приложения, а затем установите его для получения последнего, поэтому подойдет кнопка повторного развертывания. Конечно время ожидания этого запроса не бесконечно, можно поставить таймаут и потом вернуть ошибку.

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

4. Модель широковещательной рассылки сообщений

Spring RSocket Broker также поддерживает широковещательную рассылку сообщений, то есть пересылку запросов RSocket в пакет сервисных узлов. Вещание сообщений в основном включает следующие модели:

• FireAnderbet Model: Push-сценарий конфигурации, запрос на обновление конфигурации в список услуг, соответствующих имени сервиса.
• Модель requestResponse: отправьте запрос нескольким службам, а затем верните ответ первого ответа вызывающей стороне, независимо от того, является ли результат ответа успешным или неудачным, это похоже на Promise.race() в JavaScript. Для функции Promise.race() бизнес-сценариев, похоже, не так много, для облегчения понимания здесь добавлен тайм-аут, который преобразуется в: «Вернуть правильный результат как можно скорее в течение указанного времени». Например, в сценарии синхронизации данных данные будут синхронизированы с несколькими серверами резервного копирования, но по разным причинам синхронизация данных на сервере резервного копирования может быть задержана или потеряна, поэтому я запросил данные с нескольких серверов резервного копирования и договорились, что если на резервном сервере таких данных нет, то через 1-секундный тайм-аут будет возвращено исключение, чтобы корректные данные можно было получить из резервного кластера серверов с максимальной скоростью. Конечно, в реальной архитектуре мы добавим уровень поддержки кеша, чтобы избежать нескольких одновременных запросов к сервису, что приводит к трате большего количества ресурсов.
• Модель requestStream: отправляйте запросы на несколько серверов, затем объединяйте возвращенные потоки, а затем возвращайте объединенный поток сообщений вызывающей стороне. Это очень полезно в сценариях мониторинга.Вы хотите, чтобы каждая служба или приложение сообщали журналы в течение 5 минут, а затем составляли статистику, что очень полезно в настоящее время.
• Модель канала: непрерывная отправка информации по каналам нескольких серверов, а затем объединение отправленной информации. Эту модель можно использовать, если у вас есть несколько заданий для отправки, а затем объединяются результаты ответов на задания из каждого приложения.

Из вышеупомянутых моделей он может в основном покрыть многие потребности вещания. Если компания хочет, чтобы вы сделали сервер конфигурации для отправки конфигурации, можно ли это сделать за считанные минуты с помощью RSocket Broker? С помощью RSocket Broker + Agent выполнить операции по эксплуатации и обслуживанию, сбору логов и т. д. не составит труда. В сценарии сбора метрик Prometheus вам нужно всего лишь отправить одну команду для сбора метрик на всех машинах, что намного проще, чем отправка HTTP-запросов на каждый узел.

5 Шлюз и Брокер

Большинство конструкций шлюза используют метод активного подключения, то есть прокси-режим, в котором шлюз активно подключается к службе вверх по течению. Конечно, подключиться к службе вверх по течению, необходимо использовать открытие обслуживания, умные DNS и т. Д. Принцип не будет повторяться. Архитектура брокера принимает пассивный режим, то есть ждет службы подключения к брокеру, то есть, когда служба готова, она может активно подключаться к брокеру, а затем пересылать запрос на основе длительного соединения, установленного между Приложение и брокер. По сравнению с архитектурой шлюза режим брокера намного проще. Нет необходимости управлять соединительным пулом Upstream Services Internall, и нет необходимости в регистрации услуг и открытии. Конечно, нет никаких особых требований к подключению к сети, И это также применимо к гибридным облачным сценариям.

Хотя протокол Rsocket Broker Rsocket на основе RSCocke, но может также поддерживать различные протоколы в виде мостового моста, моста, когда HTTP HTTP HTTP может быть расширен.

6 Встроенный брокер RSocket

Чтобы ответить на предыдущий вопрос, RSocket Broker встроен в приложение. Вам нужно добавить соответствующие зависимости и конфигурации, а затем запустить соответствующее приложение. Это похоже на Spring Config Server и т. Д. В основном это облегчает разработчикам расширение соответствующие функции Брокера Интеграция с другими системами. В сочетании с функциями RSocket Broker, представленными ранее, мы можем сразу же реализовать некоторые типичные бизнес-сценарии, внедрив RSocket Broker:

• Конфигурация/сервер реестра: поскольку приложение установило длительное соединение с брокером, метаинформация также отправляется брокеру, поэтому сервер реестра является само собой разумеющимся. RSocket Broker поддерживает различные модели широковещательной рассылки сообщений, поэтому Config Server практически готов. Отправка конфигурации отдельного приложения на основе независимой отправки тега и общая передача на основе имени службы выполняются без проблем.
• Веб-консоль: после внедрения брокера разработайте веб-консоль, что очень просто для Spring Boot.
• Шлюз данных. Если вы хотите создать шлюз данных для предоставления служб доступа к внешним данным, все рабочие узлы данных подключаются к брокеру, после чего брокер может предоставлять внешние службы.
• Интеграция системы Ops: это можно интегрировать с помощью Spring Boot.Для других, таких как проверка работоспособности приложения доступа и т. д., нужно только отправить сообщение в приложение.
• Элегантный онлайн и в автономном режиме приложений и брокеров: нажав информацию о конфигурации брокеров, приложения могут подключаться к новым узлам брокеров для завершения онлайн и в автономном режиме кластера брокеров. Чтобы пойти в Интернете и в автономном режиме, просто отправьте сообщение Manore_Remove в кластере брокера, а затем приложение может выйти в автономный режим после 3-5.

7 Spring RSocket Broker Client

В настоящее время клиент SDK rsocket Broker в основном включает в себя Java и Node.js, но вам не нужно беспокоиться о клиенте Broker SDK других языков. Клиент Broker просто добавляет новое сообщение / x.rsocket.brack. К составным метаданным rsocket SDK SDK. Спецификация метаданных V0, с помощью Rsocket Multi языковые SDK, приложения, разработанные на основных языках, могут быть быстро подключены к брокеру.

Четыре резюме

Наконец, одноклассник спросил, созрел ли RSocket сейчас? В экосистеме Spring он был очень зрелым. RSocket Java SDK разработан командой Spring. Spring RSocket обеспечивает интеграцию RSocket и Spring. Spring Boot имеет встроенный rsocket-starter, а Spring Cloud Function также добавляет поддержку RSocket. Учитывая привычки Java-разработчиков, spring-retrosocket также предоставляется. Все остальные продукты Spring в основном поддерживают Reactive, поэтому подключение можно выполнить через Reactive. Все периферийные устройства RSocket готовы, и все ждут появления RSocket Broker, что упрощает интеграцию и развертывание. Кроме того, различные текущие сервисы, такие как REST API, GraphQL или RPC framework, сложно ли перейти на RSocket? Если это воплощено в Spring, то нужно добавить вещь @MessageMapping, и тогда вы сможете получить доступ к этим сервисам через RSocket. Для служб Dubbo/HSF добавьте аннотацию, предоставляемую spring-retrosocket, в интерфейс, после чего вы сможете получить доступ к этим службам через протокол RSocket. REST API может добавлять @MessageMapping на основе контроллера. Что касается GraphQL, никаких настроек не требуется, просто добавьте новый GraphqlController для подключения к базовой службе GraphQL. Что касается текущей функции Spring RSocket Broker, то для среднего предприятия можно сказать, что она полностью дееспособна без какой-либо корректировки.Это Spring Config Server.Позиционирование Spring Registry Server и Spring Cloud Gateway является такой же.

Что касается того, что команда Spring Cloud говорила о влиянии RSocket на Spring Cloud и опыт разработки, я полагаю, что после прочтения этого у вас будет собственное мнение. Но есть еще старая поговорка: «Есть на свете лошадь, а есть лошадь. Лошадь бывает часто, а лошадь бывает не очень часто».

Оригинальная ссылка

Эта статья является оригинальным контентом Alibaba Cloud и не может быть воспроизведена без разрешения.