API Gateway для Web3: Как APISIX усиливает Hyperchain

August 9, 2021

Case Study

Обзор

Как ведущий мировой поставщик инфраструктуры консорциумного блокчейна уровня предприятия и поставщик решений, Hyperchain Technologies стремится создавать инновационную инфраструктуру и способствовать цифровому развитию общества. В процессе своего быстрого роста Hyperchain столкнулась с множеством проблем при создании своей блокчейн-платформы Hyperchain, таких как:

  • Отсутствие стандартизированного управления трафиком с потенциальным риском сбоя системы
  • Неполный контроль безопасности и управления аутентификацией
  • Неудобное управление правами доступа
  • Высокая стоимость публичных IP-адресов
  • Нестабильность узлов блокчейна: уязвимость одного узла к атакам
  • Отсутствие единого управления множеством протоколов

Hyperchain пробовала использовать Kong и NGINX, но, к сожалению, они не смогли удовлетворить бизнес-сценарии Hyperchain. Однако после внедрения Apache APISIX все вышеупомянутые проблемы были решены, что придало блокчейн-платформе Hyperchain новую жизненную силу.

О блокчейн-платформе Hyperchain

Блокчейн-платформа Hyperchain подразумевает встраивание блокчейн-фреймворка в облачную платформу, используя преимущества инфраструктуры облачных сервисов для развертывания и управления. Это открытая блокчейн-платформа, которая может предоставить разработчикам удобную и высокопроизводительную экосистему блокчейна и связанные с ней сервисы поддержки, а также поддержать расширение и эксплуатацию бизнеса разработчиков в web3.

Блокчейн-платформа Hyperchain позволяет быстро и гибко создавать блокчейн-сети. С помощью платформы предприятия могут единообразно управлять блокчейн-бизнесом. Например, через платформу можно подписывать контракты в интегрированной среде разработки, а затем развертывать их в созданной блокчейн-сети. Верхний сервисный модуль может вызывать связанные с блокчейном контракты для продолжения бизнес-процесса.

Поскольку в цепи много узлов, от десятков до тысяч, становится сложно отслеживать и поддерживать работу цепи без поддержки платформы. Используя блокчейн-платформу Hyperchain, пользователи могут не только сэкономить затраты, но и более удобно управлять блокчейном, а также повысить безопасность всей системы.

Давайте рассмотрим на примере Hyperchain, как и почему блокчейн-компании должны выбирать Apache APISIX среди множества API-шлюзов. Ниже мы проанализируем применение APISIX как в блокчейн-платформе Hyperchain, так и в узле блокчейна.

Применение APISIX в блокчейн-платформе Hyperchain

Ниже приведена диаграмма взаимодействия приложений APISIX в блокчейн-платформе Hyperchain. Серверная служба регистрирует информацию о службе в etcd в соответствии с ее бизнес-характеристиками, а затем регистрирует службу в APISIX через модуль регистрации маршрутов.

APISIX работает как единый вход для внутренних микросервисов в системе. Внешние запросы сначала отправляются в APISIX; затем они проходят через API к уровню доступа после прохождения аутентификации и далее к основным сервисам через RPC (удаленный вызов процедур).

Диаграмма взаимодействия приложений Hyperchain

Переадресация маршрутов

Иногда API должны быть доступны под одним доменным именем. В этом случае мы можем добавить некоторые префиксы к пути API одной службы, например /baas-core или /baas-other. Когда клиент запрашивает эти API, API-шлюз должен удалить добавленные префиксы, а затем перенаправить запрос на серверную службу. Плагин proxy-rewrite APISIX может помочь нам удобно справляться с такими случаями.

Например: При посещении: http://apisix:8080/baas-{service}/api/v1/… Запрос может быть перенаправлен на http://{service}/api/v1/… с помощью регулярного выражения: ^/baas-core/(.*)$,/$1

Редактирование плагина proxy-rewrite

Управление ограничением трафика

Пользователи могут выбирать консорциумные блокчейны в соответствии со своими потребностями, не только Hyperchain, но и IBM Data Fabric, Baidu XuperChain и т.д. Поэтому Hyperchain необходимо управлять жизненным циклом всех консорциумных блокчейнов в системе.

При создании консорциумной цепи Hyperchain нужно только написать жесткий код на блокчейн-платформе и загрузить подключаемые драйверные компоненты на блокчейн-платформу для вызова, чтобы создать консорциумную цепь. В некоторых случаях частного развертывания подключаемые драйверные компоненты могут поддерживать быстрое создание.

Каждый вызов драйверных компонентов — это процесс, который необходимо ограничивать, особенно когда количество вызовов велико. Следовательно, плагин limit-req APISIX может быть полезен для ограничения входящего и исходящего трафика платформы, чтобы обеспечить ее стабильность.

Плагин limit-req позволяет настраивать скорость и всплески.

Модель плагина limit-req

Контроль безопасности и управление правами доступа

Для сотрудничества с APISIX Hyperchain разработала плагин для случаев частного развертывания. Заказчик часто предпочитает использовать свои службы аутентификации или систему учетных записей. Когда фронтенд-трафик посещает сайт, он сначала проходит через плагин Access-auth, и только после успешной аутентификации он может получить доступ к серверной части BFF (Backend for Frontend).

Диаграмма процесса аутентификации

Согласно трем ключевым факторам спецификации Restful (информация об аутентификации, путь Restful и HTTP-глаголы, такие как GET, POST, PUT, DELETE, PATCH и т.д.), выполняется аутентификация учетной записи-роли-прав. Если аутентификация пройдена, информация о пользователе возвращается в заголовке; если нет, возвращается код 403.

Путь аутентификации API

Горячая перезагрузка

APISIX предлагает горячую перезагрузку плагинов, разработанных внутри компании. Это экономит время в процессе разработки и позволяет пользователям изменять части своего кода без перезапуска всего плагина. Таким образом, разработчики могут вносить изменения в интерфейс на серверной стороне, которые вступают в силу немедленно, что удобно и дружелюбно для онлайн-релиза.

Почему не Kong?

Hyperchain использовала Kong ранее, но в итоге заменила его на Apache APISIX, в основном из-за:

  • Высокая стоимость развертывания и обслуживания

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

  • Увеличение сложности системы и частоты сбоев

    Блокчейн-платформа Hyperchain использует базу данных MySQL, что приводит к наличию двух реляционных баз данных в системе при использовании Kong, что усложняет систему. Это также увеличивает частоту сбоев при улучшении совместимости между двумя наборами баз данных.

Применение APISIX в узле блокчейна

Диаграмма блокчейна Hyperchain

Экономия затрат на публичные IP-адреса

Пользователь приобретает блокчейны через блокчейн-платформу Hyperchain. Затем верхнеуровневые бизнесы и клиенты разработчиков могут подключаться к узлам. Сервисы могут подключаться к одному или нескольким узлам, и пользователи могут получать доступ к одному или нескольким узлам, что создает проблему: почти все узлы будут посещаться, что увеличивает нагрузку на посещение одного узла.

Это относительно легко решить в некоторых частных средах развертывания. Однако для систем, ориентированных на интернет-пользователей, требуется слишком много узлов и публичных IP-адресов. Цена каждого публичного IP-адреса с 4 мегабайтами трафика может достигать почти 200 CNY в месяц. На платформе Hyperchain тысячи узлов, что приводит к высоким затратам на публичные IP-адреса.

APISIX управляет всеми запросами на посещение и распределяет трафик на соответствующие узлы блокчейна. Таким образом, Hyperchain сэкономила значительные затраты.

Режим Hyperchain с APISIX

Удобное управление правами доступа

На блокчейн-платформе Hyperchain существует множество блокчейнов, и каждая цепь имеет сложное управление правами доступа RBAC. Поэтому на стороне клиента необходимо добавлять различные сертификаты, такие как TLS-сертификаты, что также вызывает затруднения у пользователей.

В настоящее время плагин key-auth APISIX может эффективно решить эту проблему. Авторизованные пользователи могут напрямую получать доступ к блокчейну, не беспокоясь о настройке прав доступа, так как APISIX унифицирует базовую цепь.

Кластеризация повышает стабильность узлов

Как упоминалось выше, узлы часто посещаются. Высокая конкуренция существует у большинства пользователей банков, так как TPS (транзакций в секунду) может достигать 40,000-50,000.

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

Hyperchain развернула Apache APISIX на K8s с использованием Horizontal Pod Autoscaler. Поскольку APISIX использует etcd с хорошей динамической масштабируемостью, он может эффективно решать проблему влияния трафика на одну точку.

Поддержка множества протоколов

Протоколы гетерогенных цепей на блокчейн-платформе Hyperchain разнообразны, такие как HTTP, Websocket, gRPC, TCP, UDP и т.д.

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

Почему не NGINX?

Казалось бы, Hyperchain может использовать NGINX для решения своих проблем. Однако после испытаний Hyperchain отказалась от него, потому что:

  • Не подходит для динамического расширения

    Hyperchain необходимо часто добавлять и удалять узлы на блокчейн-платформе, что вступает в силу только после перезапуска, что неудобно для разработчиков. Кроме того, разработчики должны писать сложный код правил для плагинов в файле конфигурации NGINX.

  • Сложность кластеризации

    NGINX не поддерживает кластеризацию, что относительно сложно и неудобно для пользователей.

  • Отсутствие прямой поддержки TCP и UDP

    NGINX может проксировать только 7-уровневый протокол, а не 4-уровневый, и не может напрямую поддерживать протоколы TCP и UDP. Кроме того, модуль не компилируется по умолчанию, что требует дополнительной обработки.

  • Отсутствие панели управления

    В NGINX нет визуализированного интерфейса, что затрудняет управление множеством узлов для разработчиков и операторов.

Итог

Из вышеизложенного мы видим, что Apache APISIX — это динамический API-шлюз, который может применяться в области блокчейна. Более того, Apache APISIX предоставляет богатые функции управления трафиком, такие как балансировка нагрузки, динамические апстримы, канареечные релизы, разрыв цепи, аутентификация, наблюдаемость и т.д.

Мы надеемся, что APISIX сможет поддержать больше блокчейн-компаний в их развитии. Добро пожаловать узнать больше о Apache APISIX. Вы можете связаться с нами по адресу https://api7.ai/contact.

Tags: