Записи с ArchDays теперь доступны и в vkvideo
https://vkvideo.ru/playlist/-184472537_4

Давно не писал, накину холивар.

Архитектура – это про решения, про выбор. Когда kafka не просто не нужна, но может быть плохим выбором и источником костылей?)

- например, в логировании или когда сообщения приходят редко, то есть нет потребности в в высокой пропускной способности; тут можно посмотреть на rabbit, redis.
- нужная очень низкая latency (1-5ms), например в чатах, на биржах, – здесь альтернативами могут быть nats, zeromq, rabbit
- не нужно долго хранить сообщения (например, для истории), например, в уведомлениях, – можно тот же redis streams взять (но тут есть нюансы)
- одно из моих любимых – когда нет (и не предвидится) квалифицированых кадров для настройки и поддержки, тоже можно взять попроще – nats, redis; часто следствие этой проблемы – это попытка закрыть не оптимальные настройки и инфраструктуру техническими решениями в сервисах, в коде приложений
- нужна динамическая маршрутизация (и вообще реализация EIP из коробки для снижения уровня сложности реализации всей системы), здесь rabbit или nats подходят лучше. приходилось видеть и в живую и на выступлениях, как брали кафку, а потом сообщения проходили через несколько «служебных» сервисов, которые в себе содержали реализацию тех самых интеграционных шаблонов и это сильно сильно повышает сложность всей системы в целом

То есть kafka идеально вписывается при высокой нагрузке с долговременным храением сообщений и потоковой обработкой, но, очевидно, такие требования предъявляется не то, чтобы всегда 🙂

Call for papers на ArchDays, ждем ваших заявок на выступления, подавать тут: http://archdays.ru

Я сейчас активно применяю AI в PDLC, так как канал архитектурный, поделюсь наблюдениями в части архитектуры на основе проектов с клиентами.

1. Мусор на входе - мусор на выходе. AI анализирует данные и здесь очень большая проблема. Сейчас же только ленивый не идет в AI и с чем сталкивается сразу на входе? Либо данных нет, либо они в ужасном состоянии, либо они с огромными пробелами, разбросаны, в итоге мы получаем фрагментированный и непригодный контекст. Если раньше можно было отложить на второй план управление тех долгом, не уделять должного внимания документации, то теперь, если вы хотите получить преимущество от использования AI, придется эти долги отдавать, иначе он выдает какую-то глупость. А отдать этого долг AI никак не помогает, у него просто нет входной иформации. И вот мы начинаем проводить event storming, архитектурые воркшопы, архитектурную базу знаний (структуру документации), чтобы ее можно было начать использовать с AI и только после этого (не совсем только) получить значительный эффект.
2. Для архитектуры очень важен бизнес-контекст, а он обычно тоже слабо описан. Структурированное описание бизнес-требований, с метриками и бизнес-архитектурой тоже становятся достаточно важными. Еще очень важным становится качественный discovery-цикл. AI может прекрасно обрабатывать со всех сторон результаты интервью клиентов, но если интервью проведено плохо – ничего не поможет, поэтому навык проведения интервью (а тут уже AI особо не поможет) тоже достаточно важен. Опрос AI в некоторой роли тоже не сильно помогает, потому что у каждой компании свой контекст, который публично не транслируется за пределы компании того, с кем проводите интервью.
3. Все-таки AI в ближайшее время на заменит архитектора, политику никто не отменял. Он даст гипотезы, подсказки, кучу материалов, но окончательное решение, валидация и ответственность будет все равно за архитектором, поэтому развитие архитектурных скилов критически важно (да, и навык критисеского мышления становится еще более важным, потому что AI порой выдает очень уверенно и обоснованно чепуху). Сильного архитектора, если у него в материалах порядок и у бизнеса в материалах порядок AI действительно очень сильно усиливает, проверено.

В общем, очень похоже на микросервисы. Микросервисы - это архитектурный стиль, один из многих. Чтобы спроектировать хорошее микросервисное решение, нужно хорошо понимать фундамент архитектуры, проектирования распределенных систем и DevOps и микросервисы тогда становятся всего лишь одним из стилей в арсеналей архитектора. С AI выглядит точно так же. Так что потребность в базе никуда не делась, а, видимо, стала даже более важной, иначе мы рискуем получить тысячи нерабочих решений и экспоненциальный рост техдолга.

Мы продолжаем набор спикеров на конференцию ArchDays!

Это первая в РФ конференция по архитектуре, получившая достаточно серьезное признание за 6 лет проведения.

Мы ждем интересные выступление по темам проектирования, корпоративной архитектуре, использовании AI, в том числе построении систем на их базе.

Уверен, компаниям участников этого чата есть чем поделиться.

Конференция пройдет 7 ноября в Москве, подаваться на сайте: http://archdays.ru

Если нужны пояснения, то можно написать мне в ЛС.

Сегодня опубликуем первые включенные в программу выступления

Есть такая теорема – BAC (Backup, Availability, Consistency), по аналогии с CAP.
Она звучит так: при резервном копировании всей системы микросервисов нельзя одновременно обеспечить и доступность, и согласованность.

Чтобы раскрыть суть, стоит посмотреть на бэкапы с позиции архитектурных компромиссов:
◼︎ Бэкапить сервисы по отдельности – но тогда при восстановлении данные могут быть несогласованными (например, один сервис сохранил событие, а другой нет)
◼︎ Согласованный бэкап – все сервисы бэкапятся одновременно, но в это время система становится недоступной для изменений
◼︎ Не делать резервных копий – сохраняются доступность и согласованность, но без бэкапов

И даже в такой, казалось бы, банальной вещи, как бэкапы для микросервисов все немного усложняется, в итоге:
◼︎ Приходится выбирать, где важнее согласованность, а где доступность (и обосновывать это)
◼︎ Выбирать стратегии под конкретные сервисы, например, где нужна строгая согласованность (вроде платежей) - кооринированные бэкапы, а где согласованность не так критична, вроде ленты новостей, условных лайков или статитики просмотров, – индивидуальные бэкапи + реплей событий.

Поделитесь в комментариях, как бэкапите решения на MSA, с какими проблемами сталкиваетесь, как решаете

Почитать подробнее тут: https://design.inf.usi.ch/sites/default/files/biblio/bac-theorem.pdf