Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 26
Интересная статья, если проработать каждый пункт принятия решений, получится книжка. Некоторые моменты:
Полное название - Traefik Hub API Gateway
Событийная архитектура может жить и в монолите. Так рекомендуют строить небольшие системы "на вырост", не делая их сразу распределенными.
Выбор БД зафейлен. Если уж идти по DDD, то каждый домен может иметь собственные требования к согласованности и персистентости. Движок подбирается индивидуально под домен, in-memory тоже вариант.
Жаль что не рассмотрена декомпозиция методом Event Storming. Это как раз DDD штука.
ELK все. OpenTelemetry.
ELK все. OpenTelemetry.
И какую именно часть из ELK заменяет OpenTelemetry? Правильный ответ -- никакую. OpenTelemetry занимается сбором телеметрии. Максимум -- перевалкой через неперсистентный коллектор. А куда лить, где хранить и чем смотреть/дёргать алерты -- уже выходит за рамки задач OpenTelemetry
ELK слишком жирный. Вместо ELK лучше использовать https://github.com/VictoriaMetrics/VictoriaLogs/
Полный код проекта доступен здесь.
В проекте не хватает лицензии, чтобы я смог свободно повторить все заложенные в него ошибки... Можете указать?
Правильный системный дизайн в данном случае и в остальных 99.9% - это монолит.
Я про это косвенно сказал в разделе 1.1 Обзор вариантов реализации личного сайта.
На тему того, что вы сказали, очень классно ответил Мартин Фаулер:
Практически единственная причина, по которой стоит использовать микросервисы - это если вы столкнулись со сложностями, которые делают монолит проблематичным
Выглядит это конечно вот так: "смотрите, я сделал систему с плохой архитектурой, потом написал к ней плохие тесты которые не показали проблему, а потом сделал плохие манифесты для k8s, с которыми всё начало падать"
Да, делать сервисы которые ходят в БД друг друга напрямую это плохо. Да, тесты не показывают всех проблем. Да, k8s не решает все проблемы.
Но у вас это подано так, будто именно из-за плохой архитектуры сервисов всё остальное не может работать как задумано.
Тесты в постмане показывают работает ли веб-сервис. Они и не должны показывать проблемы архитектуры и тем более подсказывать что придётся писать некрасивые конифги для docker-compose.
То что, о ужас, сервисы зависят друг от друга и их нужно запускать в определённом порядке.. ну это неизбежно. Думаете более правильные микросервисы никак друг с другом не взаимодействуют и их можно запускать в любом порядке?
То что в кубере у вас OOM - так у вас на скриншотах падали кафка и эластик.
Ходить в чужие базы плохо, это действительно большая проблема. Но проблема тут в нарушении инкапсуляции. Вам придётся дублировать код в разных сервисах, будут проблемы с миграциями т.к. один сервис изменит схему базы под себя и другой сломается.
и их можно запускать в любом порядке?
А почему нельзя? Просто работать без зависимостей не будут, но запускать, по идее, как угодно можно.
Но проблема тут в нарушении инкапсуляции.
Согласен, но нынче эту ситуация понимаю так. Пока только мы ходим ходим в бд, то это наша зависимость. Когда несколько сервисов - то общая зависимость. Общие зависимости строятся вокруг стабильного интерфейса. В случае БД этим интерфейсом становится буквально всё в БД и впадает в паралич, потому что ничего трогать нельзя, где-нибудь что-нибудь сломатся.
В то же время я видел систему, успешно работающую на общей бд, потому что сервисы только дёргали хранимки, которые по сути являлись АПИ и было не так сложно поддерживать их интерфейс. Вся остальная БД менялась как угодно.
Спасибо за проделанную работу, очень интересно и полезно
странно что на скрине в кубере падает кафка и эластик
которые не имеют отношения к плохой админке
похоже что кто то просто недодал ресурсов, чтобы показать что все плохо, а не на реальные проблемы
верно. Но тут косвенное следствие - мы создали Admin Service, который был не нужен. Он потребляет ресурсы, в том числе свой объём оперативной памяти. Получается, что ненужный сервис отбирает ресурсы у нужных сервисов (кафка и эластик) при заданных лимитах.
Нет. OOM происходит когда процессы в контейнере употребляют больше чем задано в лимите для контейнера. Если бы на ноде кубера закончилась память из-за лишнего сервиса, например от ошибки с requests, то нода бы упала целиком или начала бы вытеснять поды - не было бы статуса OOMKilled.
Эластик и кафка упали потому что конкретно им самим, без всяких админок, потребовалось больше памяти чем за дано в лимитах.
и не забудьте проверить что это все работает через 2g интернет.
Ваша «правильная» архитектура все еще не правильная.
Все можно было-бы исправит еще на стадии. Разработки, сказав что все общение идет через Kafka.
Тогда у вас сама собой получиться message oriented architecture и не будет зависимостей между сервисами.
Хот в вашем случае Кафка не нужна, она требуется когда надо гонять огромные объемы данных. Достаточно будет обычного mqtt брокера сообщений .
Хороший пример, но до правильных выводов автор как-то не довел: нужен личный сайт? Делай на JAMStack. В любом случае, нужно четкое разделение на статические ассеты и динамику. Городить огороды для статики - это главный антипаттерн. А комментировать посылай в телеграм/etc. И будет быстро, надежно и максимально гибко. И любой API можно прикрутить на любом этапе, выбрав любую архитектуру, если понадобится, в будущем.
Премного благодарен за статью. Очень интересно было почитать!
Базы данных бывают реляционные SQL и нереляционные NoSQL. У нерялиционных есть также еще свои виды для решения определенных задач: документоориетированные, ключ-значение, колоночные, графовые, векторные (для ИИ и нейросетей) и другие.
нерялиционныхнереляционных
Спасибо за статью!
Статья интересная, но мне кажется, что рассматривать домен надо шире, чем одно приложение (микросервис). Бедные сервисы - это не проблема микросервисов. Бедные сервисы я могу и в монолите сделать. И они не обязательно при этом будут нарушать принципы DDD. Просто их использование должно быть организовано так, чтобы не нарушать целостность домена.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Адский эксперимент: личный сайт на нищих микросервисах