У Григория Добрякова классный (и очень холиварный, ух как у многих от него пригорело!) пост про шины и брокеры: как вы их используете — как шину данных, или как шину сообщений? Процитирую самую суть:
"Из-за мелких различий в трактовке паттерна в интернетах и литературе вы можете найти дюжину интерпретаций. Вот ета самая шина — ето што? В зависимости от личных симпатий команды это может быть, как минимум:
1. Событийный брокер (кафка, раббит) с честным потоком событий.
2. Событийный брокер, в который все ходят как в БД (клиенты работают выборкой по хранящимся сообщениям в произвольном доступе).
3. Симбиоз событийного брокера и БД с трансформациями, когда вы кладёте в шину данные в одном виде, а достаёте их в другом (например, в денормализованном или наоборот в компактифицированном).
4. Просто тупо одна большая БД, в которой хранится абсолютно каждый объект в его последнем состоянии. То есть shared state, который все читают и все меняют, ага.
5. Некий http-шлюз, в который ты посылаешь данные post-запросом, а он проксирует этот запрос в целевую систему. Ну или наоборот get-ом так же получаешь данные.
6. Какая-то абсолютная дичь в симбиозе http и событийного брокера, когда приходящее сообщение в кафке инициирует http-запрос в систему-получатель и фактически запихивает в него данные.
7. Всевозможные мостики-трансляторы из http в хранимую процедуру в БД.
Но есть как минимум одно фундаментальное различие, которое морочит голову абсолютно всем: это использование шины событий как шины данных. И беда в том, что кафка это поощряет.
Предназначение событийной шины — пересылать события о данных, А НЕ сами данные. Если у вас, например, заказ перешёл в статус «оплачен», то это событие, ценной информации в котором фактически только два поля — это id заказа и наименование статуса.
[...]
В программировании — то же самое. В идеальной ситуации достаточно обмениваться только дельтами, чтобы поддерживать в консистентности даже самую огромную систему. В реальной жизни, конечно, такая система моментально разъедется во всех данных.
Поэтому передают объекты целиком. "
Пост, как я уже говорил, максимально провокационный (на самом деле там даже три поста и куча обсуждений). Но заставляет много о чем задуматься. В первую очередь — о трезво принятых решениях и о решениях, которые просто так появились, без анализа и оценки. У архитекторов есть такая практика — ADR, Architecture Decision Records, журнал принятых архитектурных решений, с обоснованиями, развилками и компромиссами, или Trade-Offs — что мы выигрываем, а что теряем при каждом решении. Аналитики обычно такие записи не ведут, а очень зря — так принятые решения проходят мимо анализа, "ну потому что всегда так делается же", и приводят иногда к неожиданным отдаленным последствиям.
Вот как в случае с Кафкой — ну поставили, а как вы её дальше используете? По какому из описанных выше паттернов? Какие trade offs были при этом учтены, и к чему всё это может привести? (Отдельно замечу, что вопрос "как правильно" вообще не имеет смысла в этом случае. Правильно так, как максимально полезно в имеющихся и возможных в будущем условиях).
"Из-за мелких различий в трактовке паттерна в интернетах и литературе вы можете найти дюжину интерпретаций. Вот ета самая шина — ето што? В зависимости от личных симпатий команды это может быть, как минимум:
1. Событийный брокер (кафка, раббит) с честным потоком событий.
2. Событийный брокер, в который все ходят как в БД (клиенты работают выборкой по хранящимся сообщениям в произвольном доступе).
3. Симбиоз событийного брокера и БД с трансформациями, когда вы кладёте в шину данные в одном виде, а достаёте их в другом (например, в денормализованном или наоборот в компактифицированном).
4. Просто тупо одна большая БД, в которой хранится абсолютно каждый объект в его последнем состоянии. То есть shared state, который все читают и все меняют, ага.
5. Некий http-шлюз, в который ты посылаешь данные post-запросом, а он проксирует этот запрос в целевую систему. Ну или наоборот get-ом так же получаешь данные.
6. Какая-то абсолютная дичь в симбиозе http и событийного брокера, когда приходящее сообщение в кафке инициирует http-запрос в систему-получатель и фактически запихивает в него данные.
7. Всевозможные мостики-трансляторы из http в хранимую процедуру в БД.
Но есть как минимум одно фундаментальное различие, которое морочит голову абсолютно всем: это использование шины событий как шины данных. И беда в том, что кафка это поощряет.
Предназначение событийной шины — пересылать события о данных, А НЕ сами данные. Если у вас, например, заказ перешёл в статус «оплачен», то это событие, ценной информации в котором фактически только два поля — это id заказа и наименование статуса.
[...]
В программировании — то же самое. В идеальной ситуации достаточно обмениваться только дельтами, чтобы поддерживать в консистентности даже самую огромную систему. В реальной жизни, конечно, такая система моментально разъедется во всех данных.
Поэтому передают объекты целиком. "
Пост, как я уже говорил, максимально провокационный (на самом деле там даже три поста и куча обсуждений). Но заставляет много о чем задуматься. В первую очередь — о трезво принятых решениях и о решениях, которые просто так появились, без анализа и оценки. У архитекторов есть такая практика — ADR, Architecture Decision Records, журнал принятых архитектурных решений, с обоснованиями, развилками и компромиссами, или Trade-Offs — что мы выигрываем, а что теряем при каждом решении. Аналитики обычно такие записи не ведут, а очень зря — так принятые решения проходят мимо анализа, "ну потому что всегда так делается же", и приводят иногда к неожиданным отдаленным последствиям.
Вот как в случае с Кафкой — ну поставили, а как вы её дальше используете? По какому из описанных выше паттернов? Какие trade offs были при этом учтены, и к чему всё это может привести? (Отдельно замечу, что вопрос "как правильно" вообще не имеет смысла в этом случае. Правильно так, как максимально полезно в имеющихся и возможных в будущем условиях).