Проектирование распределенной среды RPC

0 Предисловие

Заранее желаю всем счастливого Праздника Весны! Ладно, поговорим кратко.

То, что я делаю, занимается работой, связанной с большим разработкой данных, в основном ответственна за содержание, рассчитанное этому часть данных. Недавно проходные задачи Cluster Cluster всегда появляются для воспроизведения, подключающихся в связи с проблемами, связанными с HS2. Исследования узнали о внутренних принципах. Внезапно они хотят достичь рамок RPC, чтобы они могли разработать и реализовать рамочный процесс RPC. Вы также можете понять И решить некоторые проблемы, а затем позвольте себе лучше развиваться (ха-ха, вы скажете, что у меня есть несколько мечей, чтобы взять фронт? Не решайте проблему, на самом деле изучать RPC. Не волнуйтесь, этот тип проблемы был решен Последующее наблюдение я также отправлю подробную статью).

1 Проектирование трубопроводов КРМ?

На принципиальной схеме я отметил номер проточной программы, пройдемся по ней:

• ① Клиент звонит в службу в виде местного звонка
• ② После того, как клиентская заглушка получает вызов, она собирает соответствующую информацию о вызове службы в тело сообщения, которое необходимо передать по сети, находит адрес службы (хост:порт) и обрабатывает сообщение.编码Затем передайте его Коннектору для отправки
• ③ Сообщение канала соединителя, отправленное по сети акцептору
• ④ Акцептор после получения сообщения на сервер-заглушку
• ⑤ Заглушка сервера выполняет обработку сообщений解码, и по декодированному результату проходит反射позвонить в местную службу
• ⑥ Сервер выполняет локальную службу и возвращает результат на сервер-заглушку.
• ⑦ Заглушка сервера собирает и упаковывает возвращаемые результаты и编码Затем передайте его Акцептанту для отправки
• ⑧ Accapeor отправляет сообщение для разъема через сетевой канал
• ⑨ После того, как коннектор получает сообщение, он передает его клиентской заглушке, а клиентская заглушка получает сообщение и выполняет解码Затем передать его клиенту
• ⑩ Клиент получает окончательный результат вызова службы

Можно видеть, что RPC в основном отвечает за шаги со 2 по 9. Другими словами, основная ответственность RPC состоит в том, чтобы инкапсулировать эти шаги и сделать их прозрачными для пользователей, чтобы пользователи могли использовать их, как если бы они вызывали локальные вызовы. Сервисы.

2 Сделать технический выбор для RPC

• сериализовать/десериализовать

  Сначала исключите Java ObjectInputStream и ObjectOutputStream, потому что не только реализация класса, которая должна быть гарантированно сериализована или десериализованаSerializableИнтерфейс, но и для обеспечения согласованности версии JDK, компания использует So Many и использует много языков, что, очевидно, неосуществимо.После размышлений над этим снова и снова, я решил использовать Objesess.

• коммуникационные технологии

  Точно так же мы сначала исключаем собственный ввод-вывод Java, потому что требуется большой контроль при чтении сообщений, которые настолько неясны и сложны в использовании.Бывает, что я некоторое время контактировал с технологиями, связанными с Netty, поэтому я больше не бороться и ударить Нетти напрямую.

• Технология высокой параллелизма

  Технология удаленного вызова должна быть многопоточной, и только таким образом можно удовлетворить несколько одновременных запросов на обработку. Это может использовать Executor, предоставленный JDK.

• Регистрация и обнаружение службы

  Работник зоопарка. При запуске Сервера автоматически прописывается служебная информация (включая хост, порт, а также nettyPort) в ZK in; при запуске Клиента автоматически подписывается служебная информация, требующая удаленного списка вызовов в локальный кеш.

• балансировки нагрузки

  Распределенные системы неотделимы от алгоритмов балансировки нагрузки.Хороший алгоритм балансировки нагрузки может в полной мере использовать вычислительные ресурсы различных серверов и улучшить параллелизм и вычислительную мощность системы.

• Неинвазивный

  С помощью фреймворка Spring

Схема архитектуры RPC выглядит следующим образом:

3 Воплощение мечты о RPC

Из диаграммы архитектуры мы знаем, что RPC — это структура C/S.

3.1 Первая автономная версия

Автономная версия относительно проста, и в ней не нужно учитывать балансировку нагрузки (нет zookeeper), она будет намного проще, но ее можно использовать только для локального тестирования. Общая идея RPC состоит в том, чтобы создать класс сервисного прокси для клиента, а затем построить канал связи между клиентом и сервером для передачи данных.Если сервер получает данные, ему необходимо вызвать локальный сервис через механизм отражения для получения результата. Продолжайте возвращаться к клиенту по каналу связи, пока клиент не получит данные, что является завершенным вызовом RPC.

3.1.1 Создание сервисного прокси

Прокси-класс можно создать с помощью встроенных в JDK Proxy.newProxyInstance и InvocationHandler. Есть много онлайн-блогов для подробностей, поэтому я не буду их представлять. Конечно, это также может быть реализовано с использованием технологии байт-кода CGLIB.

3.1.2 Создайте канал связи и отправляйте и получайте сообщения

Клиент устанавливает канал связи с сервером через сокет для поддержания соединения. Его можно получить через сконструированный SocketObjectInputStreamиObjectOutputStream.但是有一点需要注意，如果Client端先获取ObjectOutputStream, то сервер может получить только сначалаObjectInputStream, иначе возникнет тупик и связь будет невозможна.

3.1.3 Отражение вызовов местной службы

Сервер получает метод в соответствии с запрошенной информацией и обратно вызывает метод для экземпляра службы.

3.2 Еще одна распространяемая версия

Мы начинаем с архитектуры верхнего уровня для проектирования и реализации, то есть схемы архитектуры RPC после выбора технологии. В основном это включает в себя регистрацию сервисов, реализованных Zookeeper с помощью обнаружения.

3.2.1 Регистрация и обнаружение службы

При запуске серверной части все файлы, предоставленные текущим сервером с@ZnsServiceАннотированная реализация службы регистрируется в Zookeeper, а структура данных, хранящаяся в Zookeeper, имеет вид ip:httpPort:acceptorPort.

При запуске клиента согласно отсканированному@ZnsClientАннотированный интерфейс службы извлекает информацию о поставщике услуг из Zookeeper и кэширует ее локально. В то же время события мониторинга этих служб добавляются в Zookeeper. Как только узел изменяется (онлайн/офлайн), локальный кэш будет немедленно обновлен.

3.2.2 Балансировка нагрузки вызовов службы

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

3.2.3 Сетевой канал

• Acceptor

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

• Connector

Инициируется клиентом при вызове удаленной службы,ZnsRequestManagerНачнетConnectorиAcceptorПодключайтесь и сохраняйте информацию о канале одновременноChannelHolderвнутрь, пока запрос не будет выполнен, а затем информация о канале уничтожается.

3.2.4 Управление пулом запросов

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

3.2.5 Асинхронный обратный вызов результата ответа

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

4. Резюме

В этот раз меня сугубо интересовало решение проблемы с подключением Thrift к HS2, я несколько дней думал над общей архитектурой RPC, а потом стал судорожно набирать код каждую ночь. Я назвал эту структуру RPC какzns, что сейчас сделано1.0-SNAPSHOTверсии, можно использовать в обычном режиме. В процессе разработки мы также столкнулись с некоторыми небольшими проблемами, которые обычно игнорировались, а некоторые не встречались или пропускались в рабочем проекте. Поскольку он находится на ранней стадии, будут некоторые ошибки.Если вы заинтересованы, вы можете упомянуть PR и ВЫПУСК.Конечно, вы также можете клонировать код для местных исследований и изучения. Хотя в настоящее время до создания действительно стабильного RPC-фреймворка, который можно было бы запустить в производство, еще далеко, но я буду придерживаться его, ведь RPC действительно включает в себя множество моментов. Ya hoh! Наконец-то успешно реализована версия 1.0, хе-хе...

Адрес источника

• zns исходный адрес

• Код исходного кода ZNS Краткое представление:

  znsЗависит отzns-api, zns-common, zns-client, zns-serverОн состоит из четырех основных модулей.zns-service-api, zns-service-consumer, zns-service-providerтри модуля правильноznsВарианты использования для тестирования.