Skip to content

kotkovkirill/prototest

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

2 Commits
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Тестовое задание: Необходимо реализовать клиентскую и серверную часть. Клиент и сервер асинхронно обмениваются между собой сообщениями в формате protobuf. Максимальный размер пакета при передаче 50 байт. Объем одного сообщения при передаче может быть от 30 байт до 1кб. Сообщения передаются со скоростью 1кб/сек. Клиент и сервер авторизовываются по протоколу OAuth 2.0 . Необходимо обеспечить достоверную доставку сообщений в случае потери связи, потери цепочки сообщений и др. сбоев. Клиентская часть на netty, серверная spring либо тоже netty Давай сделаем так, вначале ты декомпозируешь задачу, сделаешь оценку. Мне так же интересно какие юнит тесты ты реализуешь и в целом как будешь тестировать систему, мониторинг того что необходимо и как ты реализуешь его для наблюдения и анализа сбоев системы

Комментарий к решению:

https://github.com/kotkovkirill/prototest.git (можно клонировать отсюда, запускается с mvn spring-boot:run)

  • Общее описание Клиент и сервер на netty, обернутые в spring boot (для удобства запуска помещены в один spring контекст и запускаются в одном application), клиент отправляет серверу protobuf сообщения по tcp, сервер в случае получения корректного сообщения отправляет protobuf ответ.

  • Гарантированная доставка Перед отправкой сообщения клиент сохраняет их в персистентный хешмап из библиотеки mapdb, отправка сообщения происходит из хранилища (для этих целей можно использовать любое хранилище с константным временем доступа к данным по ключу, использовал то, что легче подключается и имеет меньше зависимостей). Сообщение удаляется из хранилища в случае получения ответа от сервера SUCCESS. Так же нужно отметить, что для полноценной гарантированной доставки сообщений сервер должен иметь возможность определять повторы сообщений, которые уже были успешно обработаны и отвечать на них SUCCESS. Обычно обработка сообщений сервером предполагает сохранение следов о них в какой-нибудь базе, поэтому такое поведение несложно имплементировать. В данном прототипе этот момент опущен.

  • Целостность сообщений Для гарантирования целостности сообщений кроме стандартных механизмов tcp подключено шифрование трафика с помощью ssl. Для демонстрации работы данные между клиентом и сервером ходят через прокси на netty, который с определенной вероятностью подменяет данные в пакете. Это приводит к появлению эксепшенов SslHandler'а при обработке сообщений на сервере, что, в свою очередь, приводит к срабатыванию механизма гарантированной доставки. В случае если по причинам, связанным с производительностью, использование ssl не подходит, для проверки целостности сообщений нужно считать хеш сумму protobuf сообщения на клиенте, записывать ее первыми байтами сообщения и проверять на сервере.

  • Ограничения по ширине канала По умолчанию выключено, для подключения можно запустить приложение с client.enable_taffic_shaping=true в application.properties . При запуске в таком режиме можно наблюдать, как из за механизма гарантированной доставки сообщения "копятся" на клиенте. Для обработки такой ситуации можно добавить счетчик попыток отправки к каждому сообщению и игнорировать сообщения, которые были отправлены на сервер более N раз.

  • Аутентификация Не совсем понял, как и зачем делать server-to-server аутентификацию по oauth2, выяснил, что формально oauth2 поддерживает Resource Owner Password Credentials Grant (https://oauth2.thephpleague.com/authorization-server/resource-owner-password-credentials-grant/), но по своей сути он ничем не отличается от обычной аутентификации с помощью пароля, поэтому сделал так. Детали можно посмотреть в классе PrototestServerAuthHandler.

-Юнит тестирование Написал юнит тесты для клиентской и серверной части(ClientTest, ServerTest). Так же хотел написать интеграционный тест для проверки гарантирования целостности сообщений с помощью ssl, но на EmbeddedChannel'ах это сделать не удалось, думаю что можно сделать это если поднять полноценные клиент и сервер.

  • Соображения по мониторингу работы системы в real-time
  1. Мониторинг состояния хранилищ сообщений на клиентах с помощью jmx или другим подобным образом, если речь идет о server-to-server интеграции
  2. Сбор и сопоставление логов клиента и сервера об отправленных и полученных сообщениях с помощью elasticsearch-logstash-kibana

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages