Как мы пишем микросервисы и почему не делаем этого быстро

[jehy]

Полностью согласен, ротация обязательно должна быть — при этом в целом нет никакой разницы, какой архитектурой вы пользуетесь. Если вкратце:

1) Увеличивается bus factor;
2) Разные команды тащат свои лучшие практики;
3) Часто каждый следующий участник, который не понимает, как работает написанный до него код, разбирается и делает его проще;
4) Добавляется документация, становятся проще тесты, деплой и запуск;
5) Все разработчики получают знания о каких-то инструментах, которые применяют другие команды.

Главное — принять, что не существует какого-то сакрального знания, из-за которого над конкретным проектом должен работать только конкретный человек.

При этом, правда, у нас остаётся понятие code owners — это те ребята, которые готовы подхватить сервис в случае срочных проблем, и следят, чтобы другая команда не сделала код хуже.

[akuranda]

Тут согласен, в любой архитектуре такой подход важен. У нас если 1 микросервис ~ 1 разработчик не означает, что он пилится в одно лицо. Код ревью обязателен в любом случае, code owners даже более расширен — там девопсы и инфосеки смотрят обязательно.

[ultrasport]

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

[fougasse]

А если требования поменяются, или так у взрослых не бывает?

[xfg]

Как поддерживаете консистентность данных если бизнес-операция охватывает несколько микросервисов?

[akuranda]

Есть один микросервис, который отвечает за хранение состояний, а также обеспечивает гарантии — атомарность, тотал ордеринг, изоляцию.

[xfg]

Спасибо за ответ. Может быть подумаете о статье на эту тему? Было бы интересно почитать.

[ApeCoder]

Статьи, книжки, теоремы и саги уже написаны :) осталось их нагуглить

[xfg]

Да, сам использую saga orchestration. Но в русскоязычных докладах на тему "Как мы внедрили микросервисы" — это почти всегда не так и даже интересно как и зачем люди пытаются изобрести ACID в распределенной системе и почему уверены, что их решение действительно работает верно.

[akuranda]

ок, напишу

[alhimik45]

Есть один микросервис, который отвечает за хранение состояний

Разве это не противоречит высказыванию

отсутствие единой точки отказа

[akuranda]

Ага, это вы очень верно подметили. Он у нас долгое время был синглтоном и его отказ означал отказ всего сервиса. Сейчас это распределенный сервис, синхронизация по рафту, отказ одной ноды означает временную недоступность конечных автоматов, но и они в итоге переползут на активную ноду.

[ggo]

Один сервис, отвечающий за хранение состояний — не бывает.
Простейший случай — платеж на фронте (да, он должен где-то сохраниться на фронте), и дальше тот же платеж в бэке (тут вся жесть связанная с бухгалтерией).
И начинаем потихоньку накидывать — различные посредники/агрегаторы платежей, различные каналы (кто-то всегда ходит в фронт/бэк, кто-то хочет получать пуши), различные сопутствующие артефакты с которыми тоже нужна консистентность (sms, взаиморасчеты, активация услуг и т.д.)
В итоге получаем с десяток мест, где хранится состояние.

[akuranda]

Ну даже не знаю что вам ответить. Мы не храним платежи на фронте, да и не накидываем различные сущности. Вы нас, наверное с каким-то банком или обычной платежкой путаете, а мы — не такие.

[ggo]

Вам повезло. Всем прочим приходится воевать за консистентность.

[akuranda]

Вы всегда можете поставить себе процессинг от РБК и стать как мы. Правда, это только про платежи.

[elegorod]

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

Я вот не один год на проекте и чувствую, что это даёт ощутимое преимущество. Когда проблема на лайве, обычно сразу понимаю, в какой файл смотреть и что может быть причиной. Если кто-то поменял код в одном месте, я пишу в ревью, что нужно поменять во втором и третьем, чтобы система работала одинаково (или просто чтобы ничего не сломалось).

[Vilaine]

Если кто-то поменял код в одном месте, я пишу в ревью, что нужно поменять во втором и третьем, чтобы система работала одинаково

В статье про уникальную экспертизу особенностей работы кода написано. Не знаю подробностей, но вашу ситуацию можно назвать high coupling, я думаю.

[shuron]

Мы поспешили лишь однажды, когда наложился джекпот — суперзаказчик и крайне срочные дедлайны, как раз создавали наш Wallet. Тогда да, мы чууууток спустили рукава и сделали все быстрее, чем планировали (и хуже, чем хотели, да). В идеале все задумывалось как кучка аккуратных микросервисов. Получился такой себе кусочек монолита. Плюсы ситуации в том, что мы еще разок для себя поняли, что спешить не надо. А сам сервис уже потихоньку растаскиваем на отдельные микросервисы, как и хотели.

Помоему очень прагматичный и гибкий (Аджайл ;) ) понимание у вашей организации.
Вы ответили на запрос клиета когда это пришлось, взяв технический долг, но у вас есть вобзможность или свобода оплатить его!

[akuranda]

Ваши слова как бальзам на душу, спасибо)

[Mad_Butcher]

Но когда заказчик понимает, что получил быстро и криво, может и репутация пострадать...

[shuron]

Кто сказал что криво?

[Mad_Butcher]

По мне так, если нет ротации, то должны работать очень толковые люди. За свою карьеру встречал таких мало-мало. Поэтому полностью поддерживаю идею ротации.