Комментарии 8
Получается, что вы осознано выбираете более худшую архитектуру и жертвуете качеством ради быстрого добавления новых фич. А увеличение численности команды модуля "Accounts" не ускорит разработку?
Бизнес развивается и растёт довольно стремительно. Причина этого – быстрорастущие потребности конечных клиентов. На наш взгляд, удовлетворение этих потребностей должно быть построено на основании максимально оптимальных и доступных решений, которые позволят достигнуть цели, «не раздувая» штат сотрудников.
Как показывает практика, большое количество разработчиков – это не панацея. Как правило, увеличение штата разработчиков в команде почти всегда влечёт за собой необходимость найма дополнительных единиц QA и других ИТ-специалистов в команду, что может быть затруднительно.
"Каждый получает сам"
Обычно всё, что отображается, всегда приходит из "источника правды" (source of truth) - это всегда тот bounded context, который владеет данными и всеми бизнесс-правилами, которые оперируют над этими данными. Только так можно избежать неактуальность данных на экране. Поэтому UI в случае с распределёнными системами должен всегда строится исходя из принципов composite UI - все критические данные всегда отображаются UI компонентами которые логически принадлежат к модулям / bounded contexts, где эти данные "живут". Все данные, чьей согласованностью (? consistency) можно либо пренебречь, либо же вообще построить UI таким образом, чтобы эти данные были не нужны, могут быть загружены с кэшированой модели, которую каждый bounded context создает под свои нужды используя сообщения получаемые от других bounded contexts / aggregates через service bus.
Исходя же из требований по минимизации соединений с backend, тут встаёт вопрос оптимизации - наверняка вы рассматривали фасады, которые на стороне сервера могут получить и скомпоновать данные из разных bounded context, тем самым уменьшая количество запросов с клиента.
Единый источник правды позволяет показывать актуальный остаток по счетам, май эсс!
Между тем, при работе с веб-интерейсом Сбера приходится после каждого чиха вылогиниваться и логиниться заново.
Почему, возможно спросите вы?
Потому что при переводе денег операции выполняются мгновенно, а соответствующие остатки по счетам/картам в интерфейсе не обновляются. Из-за этого интерфейс не позволяет этими деньгами воспользоваться, уверяет, что их там нет, хотя они там есть. И прозревает интерфейс только после повторного входа (Вовочка, выйди и зайди правильно).
Вот я зашёл в веб-версию. Перевел с одного своего счета/карты на другой свой счет/карту немного денег (консолидировал финансы, так сказать). Операция выполняется мгновенно, СМС-подтверждение, все дела. Обновляю страницу — балансы счетов/карт не изменились. Идут минуты, жмётся F5, когда пореже, когда почаще. Жмется кнопка рефреша мышкой. Выполняются бессмысленные шатания между вкладками — Главная, Платежи, История, Главная… Не показывает интерфейс, что деньги переместились, и всё тут.
В какой-то момент (не сразу, да) операция перевода даже появляется в "Истории". На интерфейс это не влияет никак. Остатки по счетам не изменяются.
Пытаюсь начать оплату с карты, куда переводил — думаю, может проморгается интерфейс, когда надо будет генерировать тот дропдаун с остатками по разным картам, который "выберите карту, с которой платить"? Нет, ни фига, в дропдауне по-прежнему старый баланс всех карт.
А платить-то надо сейчас.
Вздыхаю, перелогиниваюсь, и вот они, актуальные остатки по всем картам. И теперь интерфейс позволяет мне начать операцию оплаты, а не говорит, что на карте недостаточно денег, как раньше.
При переводах иными способами (с участием чужих счетов/СПБ) ситуация ровно такая же.
Если 1 Middleware App = 1 CRUD Service, то зачем их вообще делить? Либо схема некорректная, либо имеется лишнее звено в цепи. Да и даже если запросы ходят из одного Middleware в несколько CRUD, то кажется, что-то пошло не так, так как вы родили еще один API GW, вернее, в вашем случае несколько API GW. Либо я что-то не так понял ¯\_(ツ)_/¯
Вообще, кажется, идет борьба с симптомами болезни, а не с причиной. На мой взгляд один модуль фронта должен ходить к одному набору методов API, сосредоточенных в одном микросервисе, под которым лежит одна БД (ладно, БД может быть несколько, но это прям редкость), откуда берутся данные. И вся эта конструкция "1 модуль FE + 1 микросервис БЕ + 1 БД" представляют собой 1 бизнес-сервис (можно еще навернуть кэш, хранилище медиаконтента и тд по необходимости). Его можно изолированно крутить, поддерживать и развивать одной независимой командой.
Для объединения нескольких сервисов в продукт их можно обернуть неким максимально глупым API Gateway, обеспечивающим, максимум аутентификацию и авторизацию, но по вызовам он должен быть тупой проксей (также как и в Smart Clients Dumb Pipes, хотя там не совсем про то, но смысл тот же)
Если возникает потребность одному бизнес-сервису ходить к другому за данными, то 2 варианта:
контексты бизнес-сервисов (домены) нарезаны не очень корректно и стоит их пересмотреть
Если с пунктом 1 точно все ок, то не бояться продублировать какие-то данные из одного бизнес-сервиса в другие путем фоновой их передачи (Event Driven Architecture в помощь, как вариант). В случае, если с п.1 ок, то таких данных должно быть минимальное количество и они будут нужны просто справочно.
С пунктом 2 главное не путать где мастер-данные, а где справочные. Чтобы 10 сервисов не обновляли одни и те же данные, а потом гемор с мержом всего этого безобразия. Ну и в мастер-сервисе должна быть скорее всего нормализация данных, а вот в потребителях можно легко хранить все в денормализованном виде, чтоб не мучаться
Если же вы по запросам пользователя в онлайне ходите из N сервисов в M других, то это ужасная связанность и нарушение Low Coupling High Cohesion. По сути вы рождаете распределенный монолит со всеми вытекающими.
Я понимаю, что реальность сурова и так или иначе придется сделать сетевой онлайн вызов одного сервиса другим, но это должно быть скорее исключение, нежели правило
В этой схеме мы видим проблемы разработки «узкого горлышка» — кросс-продуктового модуля Accounts. Ведь у разных бизнес-функциональностей есть свои потребности по работе со счетами: фильтрация по определённым признакам, добавление новых атрибутов к счетам и т. д. Всё это должно выполняться в рамках CR (change request) на команду, которая отвечает за разработку модуля счетов. То есть другим командам придётся становиться в очередь и ожидать выполнения доработки. Я бы назвал эту схему «проблема замедления T2M новой фичи».
А во втором случае не возникает ровно той же проблемы только уже на уровне Accounts Middle Ware?)
Привет! Спасибо за комментарий!
Давайте начнём с вопроса «Зачем их вообще делить».
Архитектура сегмента ЮЛ (и ФЛ, кстати, тоже) построена на использовании цифровой платформы Сбера. Платформа – набор компонентов (сервисов) с выделенным API, который позволяет эффективно создавать бизнес-приложения с требуемым уровнем надёжности, безопасности и масштабируемости.
Крупными мазками постараюсь объяснить. Например, под Middleware на схеме в статье понимается «Единая фронтальная система» (ЕФС), задача которой – обеспечить взаимодействие с сервисами банка в одном или нескольких каналах обслуживания. Канал обслуживания – это способ взаимодействия клиента с банком, например, мобильное приложение СберБизнес. Если упростить, то ЕФС реализует бизнес-логику для фронтального сценария клиента в канале (здесь может показаться, что ЕФС – это фронтэнд, но нет, у неё есть свой фронт и бэк), и бизнес-приложение в ЕФС не выполняет сложных вычислений, не агрегирует данные, изредка выполняет оркестрацию и так далее. А вот под CRUD Service на схеме понимается ППРБ (Платформа поддержки развития бизнеса, это и есть бэкенд). Не буду сильно углубляться в архитектуру ППРБ, скажу лишь, что здесь реализуется множество технологических сервисов, слой хранения данных и работы с ними, сложная бизнес-логика, вычисления, оркестрация, взаимодействие с прикладными сервисами (например, единый профиль клиента, справочники и так далее).
Таким образом, под CRUD service в этом случае понимается сложная платформа, которая и выделена в отдельную компоненту, так как решает задачи другого рода, чем ЕФС.
Как мы строим архитектуру микросервисов для мобильного приложения СберБизнес