Технический Проект, тема 2 #13
Conversation
There was a problem hiding this comment.
Здравствуйте!
Ознакомился с работой!
Это хорошо, что есть adr, они понятны и последовательны. Также схемы самодостаточны и понятны без дополнительных комментариев. Отличная работа!
Однако, есть небольшие замечания, которые нужно исправить:
- adr это скорее лог принятие решений, основной документ все-таки
notificator/software_architecture_document.md, который должен самодостаточно содержать текущее состояние системы, с описанием компонент, их взаимодействия, а также требования об ожидаемой нагрузки на основании чего можно будет делать предположения - еще можно добавить в adr к компонентам системы ссылки на материалы об особенностях, особенно с имплементацией выбранных паттернов
- на основании схемы и описания будут строить систему, поэтому необходимы критерии оценки прототипа
- внешние пользовали обращаются напрямую в систему, без прослоек, например, масштабировать такое решение выглядит сложным
Также стоит проработать такую ситуацию: часто сервисы, которые предоставляют услуги отправки пушей предоставляют отправку сразу нескольких сообщений, но сильно ограничивают количество запросов в единицу времени.
Напоминаю, что работа не может быть принята без исправления всех критических ошибок! Желаю удачи!
notificator/adr/adr_1.md
Outdated
| Использовать Nginx API Gateway в качестве reverse-proxy. | ||
|
|
||
| #### Контекст: | ||
| Мы хотим ограничить доступ к нашему API, а также иметь возможность масштабировать систему. Остановились на Nginx для этой задачи в связи с высоким качеством документации и распространенностью технологии. |
There was a problem hiding this comment.
у коллег, которые начнут ознакамливаться с системой возникнут вопросы, почему не что-то другое, рынок сейчас достаточно богат, поэтому нужно проводить исследования и составлять сравнительный анализ решений
There was a problem hiding this comment.
Если мы не отталкиваемся от существующей команды (что, конечно, чит-код в этой домашке:)), есть ли некий порядок действий по сравнению нескольких +- аналогичных решений? Кроме очевидного "Окей гугл, что лучше..."
There was a problem hiding this comment.
составляются критерии по выбору, потом проверяются аналоги по этим критериям и выбирается конкретный либо приводится перечень на выбор уже команде разработке
| #### Положительные: | ||
| * Простота в использовании | ||
| * Подробная документация | ||
| * По сравнению с ActiveMQ, чуть выигрывает в перфомансе: https://digitalscholarship.unlv.edu/cgi/viewcontent.cgi?article=4749&context=thesesdissertations |
There was a problem hiding this comment.
хороший поинт, но нет оценки по ожидаемой нагрузке, поэтому больше выглядит как просто будет лучше, потому что быстрее
There was a problem hiding this comment.
Почему это плохо?) Мне кажется это выглядит один из объективных плюсов решения безотносительно нагрузки
There was a problem hiding this comment.
если у команды нет опыта в этом продукте, но есть альтернативы, которые покрывают требования. Какой-то продукт просто удобнее использовать и легче сопровождать и поэтому можно пренебречь его меньшим перфомансом. Согласитесь, тогда бы не использовали никакой другой язык кроме c или assembler
notificator/adr/adr_4.md
Outdated
| * Подробная документация | ||
| * По сравнению с ActiveMQ, чуть выигрывает в перфомансе: https://digitalscholarship.unlv.edu/cgi/viewcontent.cgi?article=4749&context=thesesdissertations | ||
| #### Отрицательные: | ||
| * Могут возникнуть проблемы с горизонтальным масштабированием |
There was a problem hiding this comment.
еще не стоит забывать, что это все нужно еще поддерживать и сопровождать
| Как я вижу, здесь подойдет любая достаточно распространенная современная технология, способная к масштабированию и интеграции с технологиями смежных контейнеров. В нашем случае это интеграции с MongoDB и RabbitMQ: | ||
| 1. https://github.com/mongodb/mongo-go-driver | ||
| 2. https://github.com/rabbitmq/amqp091-go | ||
| Разумеется, исходим из предположения, что у абстрактной команды разработки есть соответствующая экспертиза. |
There was a problem hiding this comment.
Действительно, навыки команды тоже ресурс, который стоит учитывать. Отличная работа!
| * Быстрое реагирование в случае падения системы | ||
| #### Отрицательные: | ||
| * Требуется дополнительное время на внедрение | ||
| * Ошибки больше нельзя просто игнорировать |
There was a problem hiding this comment.
Это скорее шутка) А если серьезно, такое решение нам поможет при интеграционном тестировании прототипа. Документ обновил
|
Спасибо за подробное ревью! Замечания учел, только прошу пояснить поподробнее по двум моментам:
Типа ссылок на доку? Или статей а-ля хабр "Как мы реализовали X на Y через Z"?
Тут не очень понимаю как это аффектит конечную архитектуру. Мы хотим иметь доп. контроллер между очередью и шлюзами доставки уведомлений? |
|
There was a problem hiding this comment.
Видно, что вы вложили усилия в это задание, это несомненно. Однако есть несколько аспектов, которые можно улучшить:
- c4 модели, указал на неточность в комментарии
- не нашел краткое описание паттернов и их имплементации
Но по остальным пунктам у меня все, отлично! Важно помнить, что развитие требует времени и усилий. Продолжайте работать над своими навыками, и вы обязательно добьетесь лучших результатов.
Давайте доработаем и можем идти дальше
| Предусмотреть хранилище для уведомлений, упавших на отправке, чтобы вернуть их в очередь для повторной попытки. | ||
|
|
||
| #### Контекст: | ||
| Мы не можем гарантировать 100% успеха по доставке уведомлений с первой попытки. Что мы можем предпринять: хранить упавшие уведомления и отправлять их обратно в очередь до N раз. Точное число выясним при интеграционном тестировании прототипа. |
There was a problem hiding this comment.
есть гарантия, что мы прочитали сообщение, не смогли его отправить и не смогли сохранить, то
оно не потеряется?
|
|
||
| Были рассмотрены три кандидата: Kafka, RabbitMQ и ActiveMQ. | ||
|
|
||
| Kafka не реализует маршрутизацию сообщений из коробки, поэтому от этого решения отказываемся. В конечном счете остановились на RabbitMQ. Мотивацию см. ниже. Последствия даны в сравнении с ActiveMQ. |
There was a problem hiding this comment.
все так, а какого рода маршрутизация вам тут нужна? в кафке есть топики, создать топики на каждый тип сообщения вполне себе можно
There was a problem hiding this comment.
на схеме еще не представлены слушатели из очередей, которые непосредственно отправляют во внешние шлюзы или складывает в хранилище неотправленных.
Но в таком случае коллекция в монго ставновится горячим хранилищем в которое и пишется и читается одновременно, но в документе adr такой сценарий не рассмотрен
No description provided.