Введение
Что такое фреймворки RPC с открытым исходным кодом?
Один привязан к конкретной языковой платформе, а другой является языково-независимым, то есть кросс-языковой платформой.
Среды RPC с открытым исходным кодом, привязанные к языковой платформе, в основном включают следующее.
- Dubbo: самая ранняя инфраструктура RPC с открытым исходным кодом в Китае, разработанная Alibaba и открытая в конце 2011 года, поддерживает только язык Java.
- Мотан: инфраструктура RPC, используемая внутри Weibo, с открытым исходным кодом в 2016 году и поддерживающая только язык Java.
- Tars: инфраструктура RPC, используемая внутри Tencent, с открытым исходным кодом в 2017 году и поддерживающая только язык C++.
- Spring Cloud: среда RPC, исходный код которой был открыт Pivotal в 2014 году и поддерживает только язык Java.
Среды RPC с открытым исходным кодом для кросс-язычных платформ в основном включают следующее.
- gRPC: межъязыковая RPC-инфраструктура Google с открытым исходным кодом в 2015 году, поддерживающая несколько языков.
- Thrift: это межъязыковая RPC-инфраструктура внутренней системы, первоначально разработанная Facebook.В 2007 году она была внесена в фонд Apache Foundation и стала одним из проектов Apache с открытым исходным кодом, поддерживающим несколько языков.
Если ваш бизнес-сценарий ограничен только одним языком, вы можете выбрать одну из инфраструктур RPC, привязанных к языку;
Если это связано с взаимными вызовами между несколькими языковыми платформами, вам следует выбрать межъязыковую платформу RPC.
2. Фреймворк RPC, в чем разница между ними?
1. Dubbo
Давайте сначала поговорим о Dubbo. Можно сказать, что Dubbo является самой ранней инфраструктурой RPC с открытым исходным кодом в Китае. В настоящее время он поддерживает только язык Java. Его архитектура показана на следующем рисунке.
Как видно из рисунка, архитектура Dubbo в основном включает четыре роли, где Consumer — потребитель сервиса, Provider — поставщик сервиса, Registry — реестр, а Monitor — система мониторинга.
Конкретный процесс взаимодействия заключается в том, что после того, как Потребитель получает узел Провайдера через центр регистрации, он устанавливает соединение с Провайдером через SDK клиента Dubbo и инициирует вызов. Сторона поставщика получает запрос потребителя через серверный SDK Dubbo, а затем возвращает результат потребителю после обработки.
2. Motan
Motan — еще один известный в Китае фреймворк RPC с открытым исходным кодом, который также поддерживает реализацию только на языке Java, его архитектуру можно описать следующим рисунком.
Архитектуры Motan и Dubbo аналогичны, и обеим необходимо ввести SDK на стороне клиента (потребитель услуг) и на стороне сервера (поставщик услуг).Среда Motan в основном включает следующие функциональные модули.
- register: используется для взаимодействия с реестром, включая такие функции, как службы регистрации, службы подписки, уведомления об изменении службы и отправка пульса службы.
- протокол: используется для описания службы RPC и управления конфигурацией службы RPC.Этот уровень также может добавлять фильтры с различными функциями для выполнения таких функций, как статистика и ограничения параллелизма.
- сериализовать: сериализовать и десериализовать объекты, такие как параметры и результаты в запросах RPC.
- транспорт: используется для удаленной связи, используется режим длинной связи TCP Netty NIO по умолчанию.
- кластер: при запросе доступный сервер будет выбран в соответствии с различными стратегиями высокой доступности и балансировки нагрузки для инициирования удаленных вызовов.
3. Tars
Tars — это проект с открытым исходным кодом, созданный Tencent на основе многолетней внутренней практики использования микросервисной архитектуры, который поддерживает только язык C++, схема его архитектуры выглядит следующим образом.
Взаимодействие архитектуры Tars в основном включает следующие процессы:
- Процесс выпуска службы: загрузите пакет выпуска сервера в исправление в веб-системе.После успешной загрузки отправьте запрос на выпуск сервера в Интернете, который будет передан узлу службой реестра, а затем узел извлечет сервер выпустить пакет на локальный сервер и подтянуть сервис.
- Процесс команды управления: запрос команды службы сервера управления может быть отправлен в веб-систему, которая передается службой реестра службе узла, а затем узел отправляет команды управления на сервер.
- Процесс сообщения пульса: после запуска службы сервера он будет периодически сообщать о пульсе узлу, а затем узел будет сообщать информацию о пульсе службы службе реестра, которая управляется реестром.
- Процесс предоставления информации: после того, как служба сервера запущена, она будет регулярно сообщать статистическую информацию в stat, распечатывать удаленные журналы в журнал, регулярно сообщать информацию об атрибутах в prop, сообщать об аномальной информации для уведомления и извлекать информацию о конфигурации службы из config.
- Клиент получает доступ к серверному процессу: клиент может косвенно получить доступ к серверу через имя объекта сервера Obj, клиент будет извлекать информацию о маршрутизации сервера (например, IP-адрес, информацию о порте) из реестра, а затем в соответствии с конкретными бизнес-характеристиками ( синхронный или асинхронный, TCP или UDP) для доступа к серверу (конечно, клиент также может напрямую обращаться к серверу через IP/порт).
4. Spring Cloud
Spring Cloud использует функции Spring Boot для интеграции превосходных компонентов в отрасли с открытым исходным кодом и в целом предоставляет набор решений для управления услугами в микросервисной архитектуре.
Поддерживается только языковая платформа Java, а ее архитектурную схему можно описать следующим рисунком.
Видно, что микросервисная архитектура Spring Cloud состоит из множества компонентов, и процесс взаимодействия каждого компонента выглядит следующим образом.
- Запросы на доступ к внутренним службам через API-шлюз Zuul, сначала через Token для аутентификации безопасности.
- После прохождения аутентификации безопасности шлюз Zuul получает список доступных сервисных узлов из регистрационного центра Eureka.
- Выберите доступный узел из доступных сервисных узлов и распределите запрос на этот узел.
- В течение всего процесса запроса компонент Hystrix отвечает за обработку фьюзов тайм-аута сервиса, компонент Turbine — за мониторинг вызовов и индикаторов, связанных с фьюзами, между сервисами, компонент Sleuth — за мониторинг цепочки вызовов, а ELK — за лог. анализ.
5. gRPC
Давайте сначала взглянем на gRPC, Его принцип заключается в том, чтобы определить параметры и типы возвращаемых значений интерфейса службы через файл IDL (язык определения интерфейса), а затем сгенерировать конкретный код реализации сервера и клиента с помощью программы генерации кода. , чтобы в gRPC клиентские приложения могли вызывать соответствующие методы на другом сервере, как если бы они были локальными объектами.
Его основные черты включают в себя три аспекта.
- Протокол связи использует HTTP/2, поскольку HTTP/2 предоставляет такие механизмы, как мультиплексирование соединений, двунаправленная потоковая передача, отправка на сервер, приоритет запросов, сжатие заголовков и т. д.
- IDL использует ProtoBuf.ProtoBuf – это протокол сериализации данных, разработанный Google. Он отличается высокой эффективностью сжатия и передачи и простым синтаксисом.
- Многоязычная поддержка, которая может автоматически генерировать клиентский и серверный код соответствующего языка на основе нескольких языков.
6. Thrift
Тогда взгляните на Thrift. Thrift — это упрощенная межъязыковая схема связи RPC, которая поддерживает до 25 языков программирования. Для поддержки нескольких языков, таких как gRPC, Thrift также имеет набор собственного языка определения интерфейса IDL, который может генерировать код SDK клиентской и серверной части различных языков программирования через генератор кода. разное. Его архитектурную схему можно описать следующим рисунком.
На этом рисунке мы можем увидеть характеристики фреймворка Thrift RPC.
- Поддерживает несколько форматов сериализации: двоичный, компактный, JSON, мультиплексированный и т. д.
- Поддержка различных методов связи: таких как Socket, Framed, File, Memory, zlib и т. д.
- Сервер поддерживает несколько методов обработки: простой, пул потоков, неблокирующий и т. д.
Что касается микросервисов, я резюмирую технический маршрут и делюсь им с вами.