Если честно, из того, что вы сказали до сих пор, что не так много, похоже, что Hyperledger на самом деле не подходит для этого проекта.
Весь смысл в том, чтобы создать надежную систему, в которой все участники известны.Под участниками я имею в виду организации.Организация присоединяется к каналу, а затем добавляет к нему одноранговые узлы.
API-интерфейсы REST строятся вокруг одноранговых узлов, как в одном REST API на одноранговый узел.Так что да, теоретически вы можете масштабировать, просто раскрутить другого пира, создать API и т. Д., Все это можно сделать автоматически с помощью сценариев.Ваша главная проблема - знать, когда слишком много трафика и когда начинать раскручивать новые.Кроме того, вы могли бы раскрутить новую, но как ваше приложение должно знать, что доступна новая конечная точка?
Полагаю, вы могли бы построить фасадную систему, и когда ваши скрипты раскручивают новый узел и предоставляют новый API, в этот момент об этом можно сообщить приложению, чтобы оно поддерживало список доступных API, это просто звучиткак большая работа, но без прибыли.
Мне интересно, почему вы просто не создали обычный API, не поместили его в облако, не позволили автоматически масштабировать его с помощью встроенных инструментов, работа выполнена?
Все это в стороне, если уже слишком поздно, чтобы измениться, может быть, вы можете сделать это по-другому.Ваше приложение может взаимодействовать с системой очередей, и именно оно передает голоса коллегам, когда они доступны.Если он недоступен, он может подождать, это просто означает, что голоса придут чуть позже.Таким образом, ваше приложение не напрямую общается с API REST, отправляет сообщения с голосами в очередь, затем у вас есть другое приложение, которое отслеживает эту очередь и использует API REST, если они включены.Вы могли бы даже внедрить систему, в которой вы решаете, сколько голосов вы отправите за 1 балл за определенный период времени или что-то еще.Вы по-прежнему можете масштабировать свое веб-приложение, чтобы у пользователей не возникало проблем с трафиком.