Удаленный вызов процедур (RPC) — это компьютерный протокол связи. Протокол позволяет программе, работающей на одном компьютере, вызывать подпрограмму на другом компьютере без необходимости дополнительного программирования этого взаимодействия программистом. Основная цель RPC — упростить создание распределенных приложений, предоставляя мощные возможности удаленного вызова без ущерба для семантической простоты локальных вызовов.
В свободное время перед стажировкой я реализовал легковесный распределенный RPC-фреймворк с именем buddha (https://github.com/tinylcy/buddha), количество кода не большое, а воробей маленький, но полный. В этой статье шаг за шагом объясняется конструкция будды, разборка компонентов рамы и факторы, которые следует учитывать.
Сериализация и десериализация
В сети все данные будут преобразованы в байты для передачи, поэтому на уровне кода инфраструктуре RPC необходимо реализовать взаимное преобразование между данными в определенном формате и массивами байтов. Например, в Java предусмотрен метод сериализации по умолчанию, но если он находится в сценарии с высоким параллелизмом, использование собственного метода сериализации Java может столкнуться с узкими местами в производительности. В результате появилось множество эффективных сред сериализации с открытым исходным кодом, таких как Kryo, fastjson и Protobuf. В настоящее время buddha поддерживает две среды сериализации: Kryo и fastjson.
Распаковка и вклейка TCP
Поскольку TCP заботится только о потоке байтов, верхний не знает формат данных. Если данные клиентского прикладного уровня, которые будут переданы следующими, слишком велики, TCP будет передавать данные с декомпозицией, следовательно, необходимо, чтобы служебный пакет обрабатывал липкий конец (чтобы гарантировать упорядоченность по данным TCP); если клиент отправляет объем данных мало, TCP не будет сразу высылать данные, а будет в буфере, а потом сохранять высланные при достижении определенного порога, надо работать с распаковкой на сервере.
Благодаря приведенному выше анализу мы понимаем причины прилипания или распаковки TCP.Ключом к решению этой проблемы является добавление граничной информации к пакету данных.Обычно используемые методы заключаются в следующем.
-
Отправитель добавляет заголовок пакета к каждому пакету данных, и заголовок содержит по крайней мере длину пакета данных, так что, когда получатель получает данные, длина действительных данных пакета данных получается путем считывания информации о длине заголовка.
-
Отправитель инкапсулирует каждый пакет данных фиксированной длины (дополнительное заполнение 0), так что принимающая сторона считывает данные каждого пакета данных в соответствии с согласованной фиксированной длиной после получения данных.
-
Специальный символ используется для различения каждого пакета данных, и принимающая сторона также использует специальный символ для разделения границы пакета данных.
buddha использует первый метод для решения проблемы распаковки и приклеивания TCP.
БИО и НИО
BIO часто используется в классической модели «на соединение — на поток».Многопоточность используется, поскольку такие функции, как accept(), read() и write(), синхронно Во время операции ввода-вывода, если поток заблокирован, приложение неизбежно войдет в состояние зависания, но на самом деле ЦП в это время находится в состоянии простоя. Включение многопоточности позволяет ЦП обслуживать больше потоков и улучшает загрузку ЦП. Однако в случае большого количества активных потоков использование многопоточной модели возвращает следующие проблемы.
-
Создание и уничтожение потоков стоит дорого, операционная система Linux, поток - это, по сути, процесс создания и уничтожения потоков, принадлежащих к тяжеловесной операции.
-
В JVM каждый поток занимает фиксированный размер стека, а объем памяти JVM ограничен, поэтому, если потоков слишком много, сами потоки будут занимать слишком много ресурсов.
-
Стоимость переключения потоков высока, и каждое переключение потока требует сохранения контекста, восстановления и переключения между пользовательским режимом и режимом ядра. Если потоков слишком много, больший процент процессорного времени будет затрачен на переключение потоков.
Первые две проблемы решаются с помощью пула потоков, но накладные расходы, вызванные переключением потоков, все еще существуют. Поэтому в сценариях с высокой степенью параллелизма традиционная BIO бессильна. Важными особенностями NIO являются: функции чтения, записи, регистрации и получения не блокируются на этапе готовности и могут немедленно возвращаться, что позволяет нам полностью использовать ЦП без использования нескольких потоков. Если соединение не может читать или записывать, вы можете записать это событие, а затем переключиться на другое готовое соединение для чтения и записи данных. В buddha Netty используется для написания более четко структурированных программ NIO.
Регистрация и обнаружение службы
В практических приложениях поставщикам услуг RPC часто приходится использовать кластеры для обеспечения стабильности и надежности обслуживания. Поэтому необходимо внедрить центр регистрации услуг.Поставщик услуг регистрирует информацию об адресах доступных в настоящее время услуг в центре регистрации.Когда клиент делает удаленный вызов, он сначала получает список доступных в настоящее время услуг через центр регистрации услуг, и затем получает конкретную информацию об адресе поставщика услуг (на этом этапе может быть выполнена балансировка нагрузки) и инициирует вызов поставщика услуг в соответствии с информацией об адресе. Клиент может кэшировать список доступных служб и должен уведомлять клиента, когда список служб в реестре изменяется. В то же время, когда поставщик услуг становится недоступным, реестр также необходимо уведомить о том, что услуга недоступна. buddha использует ZooKeeper для реализации функций регистрации и обнаружения сервисов.
Код
Будда - это легкая распределенная структура RPC, рожденная в процессе обучения и проверки RPC. Код размещен на Github (https://github.com/tinylcy/buddha).
Ссылаться на
-
Концептуальная модель и анализ реализации RPC (http://mindwind.me/blog/2016/05/22/RPC- Концептуальная модель и реализация parsing.html)
-
НеттиРпк (https://github.com/luxiaoxun/NettyRpc)
Источник: http://tinylcy.me/2017/07/04/Как реализовать распределенную структуру RPC/
Заявление об авторских правах: содержимое получено из Интернета, и авторские права принадлежат первоначальному создателю. Если мы не можем подтвердить, мы укажем автора и источник.Если есть какие-либо нарушения, пожалуйста, сообщите нам, мы немедленно удалим их и приносим свои извинения. благодаря.
-END-
Архитектурный дайджест
ID: Архдайджест
Архитектура интернет-приложений丨Архитектурные технологии丨Большие веб-сайты丨Большие данные丨Машинное обучение
Чтобы увидеть больше интересных статей, нажмите ниже: читать оригинал