xRPC будет выпущен, узнайте больше о экосистеме APISIX
API7.ai
January 21, 2021
По мере того как бизнес-сценарии и требования становятся все более сложными и разнообразными, появляется все больше стандартов и протоколов. Apache APISIX, как топовый проект с открытым исходным кодом фонда Apache, активно участвует и способствует расширению связанных экосистем.
В этой статье мы рассмотрим примеры предстоящего фреймворка xRPC и мультиязычных плагинов Apache APISIX с двух точек зрения: многопротокольный прокси и поддержка мультиязычности.
Многопротокольный прокси
В Apache APISIX каждый запрос соответствует объекту Route. В настоящее время существует два основных сценария проксирования в Apache APISIX.
Первый — это проксирование по протоколу HTTP, которое в настоящее время является наиболее часто используемым в APISIX. На основе проксирования по протоколу HTTP Apache APISIX реализует десятки возможностей управления трафиком, таких как детализированное управление потоком, безопасность и наблюдаемость.
Второй — это динамическое проксирование и балансировка нагрузки на основе TCP и UDP, что обеспечивает базовые возможности допуска трафика и логирования на уровне соединений. Эта модель проксирования может обрабатывать любые запросы, основанные на протоколах TCP/UDP, такие как MySQL, Redis, Mongo или DNS. Однако, поскольку это проксирование на основе TCP/UDP без протоколов верхнего уровня приложений, оно может получать только базовую информацию о кватернионе, что делает его немного слабее в плане расширяемости.
Почему xRPC
Из-за ограничений Stream Route в плане проксирования протоколов и нашего желания поддерживать больше протоколов уровня приложений в APISIX для обслуживания большего числа пользователей и сценариев применения, был создан фреймворк xRPC.
Фреймворк xRPC делает расширение возможностей протоколов очень простым, как для специфических, так и для частных протоколов данных, с точной детализацией и более высоким уровнем контроля, аналогичным проксированию по протоколу HTTP, таким как наблюдаемость на уровне запросов, расширенный контроль доступа и политики проксирования.
Что такое xRPC
xRPC буквально означает, что X — это абстрактное представление ресурса протокола. А RPC — это то, что мы считаем все ресурсы, проходящие через шлюз, как процесс диспетчеризации, то есть это фреймворк расширения протоколов. Таким образом, по своей сути xRPC — это базовый фреймворк, а не реализация конкретного протокола.
Как видно из вышеприведенной архитектуры, xRPC — это фреймворк, основанный на расширениях APISIX Core. На основе этого фреймворка пользователи могут реализовать различные протоколы уровня приложений, такие как Redis, MySQL, Mongo и Postgres. На основе различных протоколов можно абстрагировать некоторые общие факторы и реализовать связанные возможности плагинов, чтобы разные протоколы могли использовать эти возможности.
Таким образом, основная роль xRPC может быть сведена к следующему: предоставление доступа к стандартизированным протоколам уровня приложений, поддержка обмена возможностями между протоколами и предоставление пользователям возможности расширения пользовательских протоколов.
Примеры сценариев применения
С фреймворком xRPC, какие сценарии он может решать? Вот несколько примеров.
- Пример 1: Redis не поддерживает TLS в более ранних версиях. Если в нашей системе есть несколько версий Redis, и мы не можем обновить Redis в производственной среде по каким-то причинам, но нам нужно добавить возможность TLS. В этом случае мы можем использовать протокол Redis на основе xPRC для решения вышеуказанной ситуации.
- Пример 2: Когда мы хотим ограничить частоту запросов определенных IP-адресов или вызывающих сторон и хотим визуализировать частоту каждого источника вызовов, что Redis не поддерживает. Это идеально решается с использованием протокола Redis, расширенного xRPC.
- Пример 3: Если вы хотите временно включить функцию медленных запросов в MySQL, вам просто нужно подключиться к MySQL Protocol и настроить соответствующую политику в APISIX, что избавляет вас от утомительного шага входа на машину экземпляра за экземпляром.
Конечно, существует множество подобных сценариев применения, и мы надеемся, что после выпуска функции вы сможете больше экспериментировать и практиковать в реальных приложениях. Процесс вызова xPRC показан на следующей диаграмме.
Как только вышестоящие сервисы будут взяты под управление Apache APISIX, различные вышестоящие сервисы приложений могут управляться единообразно. Функции, такие как логирование, мониторинг, безопасность и устранение неполадок, могут быть выполнены через стандартизированный набор политик.
Планируемые этапы реализации
Текущий дизайн фреймворка xRPC Apache APISIX изначально разделен на 5 этапов.
- Этап 1: Чтение данных и декодирование протокола.
- Этап 2: Фаза доступа. Предоставляет функцию доступа к плагинам, что позволяет реализовать сценарии требований безопасности, управления потоком и доступа.
- Этап 3: Пересылка данных и балансировка нагрузки. Предоставляет поддержку доступа для пользовательских политик и алгоритмов балансировки нагрузки.
- Этап 4: Отправка данных и кодирование протокола.
- Этап 5: Фаза логирования. Предоставляет доступ к плагинам для реализации сценариев требований логирования и записи.
Мультиязычная экосистема
Для удовлетворения все более богатой и большой базы вычислительных языков создание поддержки кода для мультиязычной среды стало первым порогом для соответствия будущему развитию технологий. Apache APISIX также провел много исследований и практики на пути мультиязычной разработки.
Например, недавно была реализована поддержка WebAssembly. Подробности и особенности можно найти в статье "Apache APISIX Embraces WASM Ecology". Конечно, поддержка WASM в Apache APISIX все еще находится на экспериментальной стадии, и мы будем продолжать улучшать поддержку WASM в будущем. Если вы заинтересованы в этом проекте, пожалуйста, не стесняйтесь вносить вклад в проект wasm-nginx-module.
Тем временем, Apache APISIX уже поддерживает несколько языков разработки через "xPluginRunner Multilanguage Plugin Runtime" до реализации поддержки WASM. То есть, при разработке плагинов APISIX пользователи могут писать и расширять плагины APISIX не только с помощью кода Lua, который изначально поддерживается APISIX, но и с использованием своих знакомых языков, таких как Go, Java и Python.
xPluginRunner
Реализация xPluginRunner показана на рисунке выше. Весь процесс коммуникации заключается в том, что "до" и "после" выполнения встроенных плагинов APISIX инициирует локальные RPC-запросы к среде выполнения плагинов каждого языка. В плагин-раннере реализуются вычисления и обработка политик внутри каждого плагина, и результат в конечном итоге возвращается в APISIX для последующего принятия решений на основе результата ответа.
xPluginRunner служит мостом для коммуникации с Apache APISIX и в основном реализует разбор частных протоколов данных и инкапсуляцию/деинкапсуляцию RPC-сообщений.
В настоящее время решение xPluginRunner Apache APISIX находится на относительно стабильной стадии, и мы знаем из отзывов сообщества, что некоторые предприятия начали пробовать его в производственных средах. Если вы заинтересованы в этом проекте, вы также можете участвовать в различных проектах плагинов для языков разработки.
Наконец, мы покажем вам, как разрабатывать плагины APISIX на основе Java Plugin Runner, с помощью простого примера на Java.
Пример Java Plugin Runner
Прежде всего, при разработке плагина нам нужно реализовать интерфейс PluginFilter. Метод name в интерфейсе в основном используется для идентификации и извлечения имени плагина, а метод filter используется для фильтрации запроса (то есть выполнения основной логики плагина).
Один дополнительный момент, на который стоит обратить внимание, это то, что параметры request и response, появляющиеся в вышеуказанном коде, имеют фиксированную логику в раннере (все раннеры применяются):
- Если вы хотите, чтобы запрос продолжал пересылаться и только выполнял некоторые настройки политик (например, переписывание параметров запроса, заголовков и т.д.), вы можете просто манипулировать объектом
request. - Если вы хотите завершить запрос, вы можете сделать это с объектом
response(например, установить тело ответа, заголовки ответа, коды состояния и т.д.).
APISIX завершит текущий запрос, как только обнаружит, что объект response в раннере был изменен.
После завершения разработки плагина наступает время практического применения в APISIX.
Сначала скомпилируйте раннер и плагины в проекте в jar-файлы и настройте абсолютный путь к jar-файлам в основном конфигурационном файле APISIX следующим образом.
Наконец, перезапустите Apache APISIX, и вы готовы к настройке маршрутов и плагинов, а также к проверке запросов.
Итог
Эта статья представляет вам предстоящий выпуск фреймворка xRPC для Apache APISIX и связанные детали, а также подробную демонстрацию поддержки мультиязычной разработки в Apache APISIX.
Статья также показывает детали поддержки мультиязычной разработки в Apache APISIX. Она демонстрирует усилия Apache APISIX, ориентированные на экосистему, с двух точек зрения: многопротокольное проксирование и поддержка мультиязычности.
Не стесняйтесь начать обсуждение в GitHub Discussions или общаться через список рассылки.