Как стать автором
Обновить

Ваши распределенные монолиты плетут козни у вас за спиной

Время на прочтение 7 мин
Количество просмотров 13K
Всего голосов 12: ↑10 и ↓2 +8
Комментарии 23

Комментарии 23

Как-то ну слишком уж для детей… Вроде ж прописная истина всех апологетов микросервисов, что в одну базу ходит 1 сервис. И очевидно, что архитектора, которому пришло в голову на постоянной лазить централизированно в базы всех микросервисов, надо гнать сс… ми тряпками. Ведь, во первых, команды не отвечают ни перед кем за схему своей базы (но это проблема команды, делающей ETL, и это описано в статье), а во-вторых, даже безобидное неблокирующее чтение может весьма неожиданно влиять на перфоманс и стабильность базы (я этого говна наелся немало: из недавнего, одна из утилит по репликации базы монго в постгрес, работающая с монго только на чтение, может укладывать кластер монго из-за бага; если через pyodbc подключится к MSSQL без autocommit=True, то сама собой открывается транзакция, и куча других приколов), и никакие автотесты и стресс тесты не помогут, ведь разработчики микросервиса, описывая тест кейсы, и подумать не могли, что какие-то уроды из вне будут непредсказуемую нагрузку создавать на базу.

Короче, статья об элегантном решении проблемы, которая в принципе не может возникнуть в компании с адекватной культурой разработки
НЛО прилетело и опубликовало эту надпись здесь
Дело не в культуре разработки — очень часто система развивается эволюционным путем и «три года назад» никто не мог предугадать в каком направлении все будет двигаться с точки зрения бизнеса. Наш монолит сегодня отлажен и способен выдержать примерно десятикратную нагрузку — поэтому никто не собирается тратить человеко-год на его переписывание. Разумеется, все новые сервисы уже не встраиваются в него а слушают генерируемый им поток событий.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Очень интересная статья, спасибо. Кстати, в mongodb слушание событий можно эффективно реализовать через Change Stream. Какие ещё есть практические способы? Хотелось бы второй части, которая была бы ближе к практике. Чтобы узнать как эффективно реализовать такие паттерны.
Брокер сообщений kafka/rabbit/activeMq
НЛО прилетело и опубликовало эту надпись здесь

С интересом почитал по ссылке. К сожалению, комментировать там не могу по сроку давности)


Но, мне кажется, что MSSQL с CCI на хорошей железке с достаточным объемом RAM и ядер (и ручным указанием maxdop) решает процентов 90 описанных проблем. Возможно, clickhouse тоже, но у меня он споткнулся на весьма простых запросах типа join таблицы на саму себя по условию, перейдя в однопоточный просчет, что совсем уж печально (возможно, я дзен не познал, или руки кривые). И, предполагаю, что Google big query тоже решает проблему, но я исторически скептик облаков)


Касательно M$:
1) очень хитрожопые группировки выполняются на таблице размером 2млрд×60 за пару минут. Если через where отсекаешь партиции, пропорционально быстрее.
2) новые столбцы добавляются мгновенно
3) на время запроса влияют только столбцы, которые в нем участвуют
4) распараллеливание реально работает
5) если работать в append-only режиме, то тысячи TPS тянет.
6) пролицензировать все ядра для мощного сервера лицензией по ядрам ОЧЕНЬ дорого, а лицензия не по ядрам позволяет задействовать 20 логических ядер, что неактуально для современного железа.


Поэтому, берется делается большая колоночная партиционированная таблица. На каждый чих добавляется по колонке. Любые коррекции пишутся, как +1 строка с дельтой, и, соответственно, почти любое чтение содержит group by id. Ну как-то так)

НЛО прилетело и опубликовало эту надпись здесь

Так а чем вызвано неприятие связки full scan + SQL?

НЛО прилетело и опубликовало эту надпись здесь
SQL это лишь способ формально описать преобразование данных. И он реально хорош, иначе бы люди не использовали SQL движки поверх hadoop, и не делали бы его поддержку в clickhouse. Если движок умеет качественно разложить запрос в мап редьюс хотя бы на все ядра одного сервера (а указанные мною MS, CH, BQ это делают весьма неплохо), то что еще нужно?

И да, из документных только монго приходит на ум, и делать на нем аналитику — это для любителей бдсм) Да и вообще, из реального опыта, мерзкая вещь для почти всех сценариев кроме 2-3 специфических.
НЛО прилетело и опубликовало эту надпись здесь
Ну ок, значит мы поняли друг друга)

Описанное — это только первый шаг. Вы уже поняли, почему плохо лазить напрямую в БД другого сервиса — это хорошо.


Теперь вы решили заняться репликацией БД другого сервиса через поток событий содержащих полные данные… как говорится, сложные проблемы всегда имеют простые, легкие для понимания неправильные решения. Но — попробуйте делать как запланировали, некоторое время это решение проработает, как проработало предыдущее с чтением из чужих БД.


Потом вы осознаете, почему дублировать полностью все изменения БД одного сервиса в публичный лог событий предназначенный для других сервисов — плохо, и сделаете следующий шаг: будете стараться включать в события только тип события и ID связанной с событием сущности, добавив каждому сервису API, позволяющее получить практически сырые данные из его БД по этому ID.


А ещё через некоторое время, наконец, поймёте, что все эти подходы "в лоб, грубой силой", с микросервисами не работают, и начнёте учиться тому, как надо определять границы между микросервисами, чтобы получить не распределённый монолит и много-много боли в нагрузку, а настоящую микросервисную архитектуру.


Уже много-много раз говорилось: микросервисная архитектура просто переносит часть сложности из кода сервисов на архитектора, чем сильно повышает требования к квалификации архитектора. Если у вас пока нет действительно сильного архитектора, с серьёзным опытом разработки микросервисных архитектур, то лучше бы вам не мучить свой проект, а постараться вернуть его в состояние монолита, и для масштабирования использовать более традиционные для монолитов подходы (шардинг, вынесение тяжёлых операций во внешние сервисы-воркеры, etc.).


В качестве хорошего примера, как надо подходить к разработке микросервисной архитектуры, посмотрите на ютубе выступления Udi Dahan. Например (правда, это не для начинающих), очень показательный кейс с медициной, как иллюстрацию ситуации в которой традиционные подходы не работают, и как при этом приходится выкручиваться: Finding Service Boundaries – illustrated in healthcare by Udi Dahan.

С вашего позволения, продолжу цепочку про высококвалифицированного архитектора системы. Без толкового и въедчивого бизнес-аналитика, даже высококлассный архитектор может не увидеть полной картины автоматизируемых процессов. Это может быть одно лицо. По моему мнению, процессов проектирования и предъявляемых к ним требованиям никто не отменял.

Это так, но Вы несколько расширили контекст, и мы так докатимся до вывода, что все участники проекта, от заказчика до бета-тестеров, должны быть супер профи, и вот тогда всё будет хорошо.


Бизнес-аналитику не важно, используется ли монолит или микросервисы. Кроме того, даже если архитектор видит "полную картину", это не сильно облегчает ему жизнь — требования постоянно меняются, и эта "полная картина" через месяц-два может сильно мутировать, так что требовать от бизнес-аналитика супер точную и полную картину менее полезно, чем быть готовым адаптировать архитектуру под новые требования.

требовать от бизнес-аналитика супер точную и полную картину менее полезно

Команда либо есть, либо ее нет, а от нее зависит очень многое. На одном мастерстве архитектора в прямой постановке вопроса, далеко не уедешь, максимум плавание по течению.

Ну, микросервисы повышают требования к квалификации архитектора, но, в то же время, снижают требования к квалификации разработчиков. Просто немного другой баланс.

НЛО прилетело и опубликовало эту надпись здесь
Переход на события не полностью решает описанные проблемы:
1. Часто для обработки события нужно иметь дополнительную информацию об измененной сущности, что влечет «уточняющие» запросы подписчиков к API микросервиса
2. Желание решить предыдущую проблему добавлением в событие всей нужной информации вызывает перегрузку сети бесполезно передаваемыми данными
3. Важно понимать что события это тоже API, поэтому менять их семантику или содержание нужно с теми же самыми предосторожностями (версионирование, обратная совместимость и т.п.)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий