RPC как архитектурный стиль

RPC как архитектурный стиль Когда говорят о RPC, часто вспоминают конкретные фреймворки, но вообще-то это отдельный архитектурный стиль, который сейчас переживает своё возрождение Когда только появились распределенные системы, программисты отчаянно цеплялись за прошлое и хотели программировать так же, как раньше - просто вызывая нужные функции. Это позволило бы думать о бизнес-логике, не переживая о технических деталях взаимодействия клиента и сервера. Поэтому появился промежуточный слой - RPC-фреймворк. У каждого RPC-фреймворка должны быть свои компоненты:

Клиентский стаб: это объект, который выглядит, как вызываемая функция, но под капотом упаковывает все атрибуты, сериализует их (т.е. превращает в байты) и отправляет на сервер с помощью транспортного протокола

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

Процесс сериализации и десереализации часто называют маршалингом Когда нужно создать эти стабы и скелетоны, программист описывает их на специальном языке (IDL), а RPC-фреймворк уже генерирует реальные объекты Такой подход позволяет забыть программисту о нюансах сетевого взаимодействия. И это оказалось самой большой проблемой RPC Какие "заблуждения" мешали первым проектировщикам распределенных систем: Сеть надежна (но вообще-то пакеты теряются) Задержка равна нулю (по факту миллисекунды и секунды) Пропускная способность бесконечна (при удаленном взаимодействии канал ограничен) Сеть безопасна (на самом деле появляются злоумышленники, прослушка) Топология не меняется (инстансы перезапускаются, IP меняются) Всегда один администратор (в микросервисной архитектуре у каждого микросервиса может быть по своему администратору) Транспортные расходы нулевые (сериализация и сжатие стоят времени, иногда немалого) Сеть однородна (забыли про разные протоколы, файрволы, прокси) Как раз как ответ на эти проблемы и возник другой архитектурный стиль - REST. Одно из главных нововведений в нём - снижение уровня абстракции, чтобы всё-таки заставить программиста (и аналитика заодно) думать о сети Но сейчас перестали радикально отрицать RPC, и появились фреймворки нового поколения, которые учитывают вышеописанные проблемы

‼️ Поэтому, если вы приходите на проект, где используется RPC, важно ознакомиться с техническими подробностями используемого фреймворка: так вы поймете, какие проблемы он уже закрыл, а о каких вам придется позаботиться самостоятельно Самый популярный фреймворк сейчас - это gRPC (RPC от Google). Он нормализовал 4 вида взаимодействия: 🔁 Unary: один запрос, один ответ ⏪ Server streaming: например, клиент запросил лог, сервер шлёт строки одну за другой ⏩ Client streaming: например, клиент загружает большой файл чанками ↔️ Bidirectional streaming: обе стороны пишут и читают одновременно (голосовой чат, биржевые котировки) Наравне с RPC существовал RMI (remote method invocation). По смыслу он очень похож на RPC, но вызываются там не просто функции, а методы конкретных объектов. Можно сказать, что это адаптация RPC к объектно-ориентированной парадигме. Поскольку особой любовью к этой парадигме отличается Java, считается, что RMI создан только для Java-подобных языков. И протокол у него тоже особый: JRMP (Java Remote Method Protocol) Однако в теории, такая концепция может использоваться не только для Java. И несмотря на то, что она мало где используется, уже даже появились фреймворки на других языках с похожей идеей (например, PyRO - Python Remote Objects). Но они уже не считаются RMI Сталкивались ли в своей практике с RPC? Как вы считаете, какой из этих стилей удобнее для системного аналитика? @maximbelovmentor