Реализовано приложение (на основе Java + Spring Boot + Gradle), состоящее из двух частей - сервера (который замеряет форматы сериализации) и прокси (API Gateway для серверов). В принципе, части можно было разделить на разные приложения, но они переиспользуют вспомогательный код и конфигурацию сборки.

Выбор роли и подстройка происходит через стандартный механизм configuration properties в Spring boot, это позволяет переопределять их как на уровне сборки образа (директива ENV в докерфайле), так и при запуске. Я использовал второй подход, так как на мой звгляд он логичней: нет смысла определять при сборке настройки, влияющие только на рантайи. Многие повторяющиеся настройки, имеющие смысл в качестве дефолтных, вынес в application-*.properties, чтобы уменьшить копипасту в конфиге compose и не раздувать Dockerfile.

Каждый сервер поддерживает все форматы (по команде get_result_by_name XXX), но только один считает дефолтным и обрабатывает командой get_result. Поддерживаемые форматы:

• Native (встроенная сериализация Java-объектов)
• Json (через Jackson)
• XML (через Jackson)
• YAML (через Jackson)
• MsgPack (через Jackson)
• Protobuf (официальная реализация)
• Avro (официальная реализация)

Непосредственно бенчмарк состоит в том, что объект класса com.example.demo.formats.EnterpriseLevelCustomer многократно подвергается сериализации или десериализации. Для повышения точности перед замером делаются прогревочные итерации. Также вставлены несколько костылей, которые призваны снизить шанс, что оптимизатор уберет цикл или иным образом сломает бенчмарк.

Прокси при старте делает discovery всех серверов с помощью служебной команды hello (причем эта процедура не требует конкретного порядка запуска контейнеров), после чего обслуживает команды get_result X в виде unicast или multicast запросов get_result к нужным серверам.

Все взаимодействие происходит по UDP (т.к. объем передаваемых данных небольшой, он легко влезает в одну датаграмму).

Как сервер, так и прокси многопоточные и должны эффективно поддерживать конкурентные запросы (используется механизм Virtual Threads aka Project Loom). Однако это не тестировалось, как и обработка сетевых ошибок.

В репозиторий включен скрипт push.sh, который собирает и публикует образ. Сборка происходит комбинацией gradle + docker (jar-ник собирается вне докера, чтобы добиться максимальной эффективности сборки). Для хранения образов выбрал Yandex Container Registry, потому что он у меня уже настроен и работает.

Для кодогеренации protobuf используется официальный плагин, для avro исходники сгенерированы ручным запуском java -jar /tmp/avro-tools-1.11.1.jar compile schema ./src/main/avro/customer.avsc ./src/main/java/.

Запуск происходит простой командой docker compose pull && docker compose up.