{"id":13654,"url":"\/distributions\/13654\/click?bit=1&hash=7a7aa21667aefd656b6233efba962ecbef616dfd5ac100a493b4b5899b23ff1f","title":"\u041c\u044b \u043f\u043e\u043f\u0440\u043e\u0441\u0438\u043b\u0438 \u0440\u043e\u0434\u0438\u0442\u0435\u043b\u0435\u0439 \u043e\u0431\u044a\u044f\u0441\u043d\u0438\u0442\u044c, \u043a\u0442\u043e \u0442\u0430\u043a\u0438\u0435 \u00ab\u043a\u0440\u0435\u0430\u0442\u043e\u0440\u00bb \u0438 \u00ab\u043f\u0440\u043e\u0434\u0430\u043a\u0442\u00bb","buttonText":"\u0421\u043c\u043e\u0442\u0440\u0435\u0442\u044c","imageUuid":"32086418-934b-5de5-a4ef-6425a84c490a","isPaidAndBannersEnabled":false}
Лысенко Андрей

Как называть топики брокеров

Любой, кто имеет дело с брокерами сообщений Kafka или RabbitMQ, задумывается, как называть топики. В интернете есть много частных мнений, но на самом деле все уже определилось как-то само собой.

Основная работа была сделана создателями спецификации асинхронного API – Async API. Эта спецификация не зависит от протокола, поэтому её можно использовать для API, которые работают по любому протоколу: AMQP, MQTT, WebSockets, Kafka, STOMP, HTTP и т. д.

Как у любого форумного топика есть свой владелец, так и у топика брокера есть свой хозяин – мастер-система (сервис или компонент), интерфейсом которой можно считать сам топик. Главный признак мастера – одиночество с какой-то стороны канала, а точнее – мастер будет находится на той стороне канала, где логически невозможно представить нахождение нескольких систем (следует из целевого назначения топика). В большинстве случаев топики это рупор, с помощью которого мастер-системы уведомляют мир …, но иногда, в силу определенных технологических удобств, топики являются микрофонами, т.е. ушами мастер-системы. Итак, первая часть имени топика должна однозначно идентифицировать мастер-систему. Пусть в наших примерах это имя будет master. Если у вас очень большое количество топиков и схожие названия сервисов, то рекомендуется вести дополнительный фрагмент – доменный префикс.

Поскольку с подлежащим мы уже определились, то во второй части названия нужно явно указать сказуемое – функциональность топика (интерфейса), т.е. описать семантику активности мастер-системы. Например, топик, направляющий сообщения к мастеру, можно назвать так …

master.receive

если мастер отправляет сообщения, то так …

master.send

если мастер уведомляет, то так …

master.notify или master.inform

Как назвать конкретно, решать вам.

Очевидно, что в третьей части названия топика должно быть собственно имя топика – описание семантики контента. Давая имя пользуйтесь теми же принципами, что вы используете для объектов API.

master.send.contract

В четвертой части названия самое банальное – номер версии сообщения (топика).

master.send.contract.0

В общем случае, рекомендуется вести словари, раскрывающие коды систем и активности в топиках. В таблице с топиками не забудьте указать (кроме прочих данных) причину, почему решение реализовано на базе брокера, а не API. Если у вас нет привычки пользоваться брокером как золотым молотком, то у вас получатся аккуратные, компактные словарики и понятные без документации названия топиков.

0
Комментарии
Читать все 0 комментариев
null