• От монолита к микросервисам: ускорили банковские релизы в 15 раз
    0
    Добрый день! Ответили выше на ваш комментарий, посмотрите, пожалуйста.
  • От монолита к микросервисам: ускорили банковские релизы в 15 раз
    0
    — В идеальном мире, конечно же, хочется видеть сразу актуальные данные на момент входа. В реальном мире можно использовать, например, систему push уведомлений, которая сообщит мобильному приложению, что счета на сервере обновились и их можно оперативно подгрузить.
    — Что касается №3, нам бы это решение не подошло, как минимум из-за единой точки отказа.
  • От монолита к микросервисам: ускорили банковские релизы в 15 раз
    0
    NDA накладывает на нас определенные ограничения. Нам очень жаль, что мы не можем раскрыть подробности в достаточной степени для более детального обсуждения. Огромное спасибо за проявленный интерес и ваши комментарии. Желаем вам интересных проектов и вызовов в работе!
  • От монолита к микросервисам: ускорили банковские релизы в 15 раз
    0
    1. Таких кейсов не удалось вспомнить, поэтому подсказать, к сожалению, не можем.
    2. Разные версии сервисов имеют разный API, соответственно МП работает со «своим» сервисом.
    Здесь вопрос доработки таблиц базы данных для разных версий. В большинстве кейсов разные версии одного сервиса работают с одной таблицей. Есть кейсы, когда новый сервис будет использовать новые поля. Мы добавляем их в таблицу. Старый сервис продолжит только считывать данные и отправлять их пользователю. А новый сервис будет обновлять данные. Принцип немного похож на CQRS.
  • От монолита к микросервисам: ускорили банковские релизы в 15 раз
    0
    Как и обещали, мы уточнили эти вопросы с командой, постараемся ответить по пунктам.
    1. Новый бэк пока используем только для нового мобильного приложения.
    2. Мобильное приложение завязывается на определенный протокол взаимодействия с API сервера. На gateway указывается, какие версии сервисов соответствуют этому протоколу. Таким образом backend может релизить новые версии сервисов по их готовности, а когда мобилка, в свою очередь, готова с ними работать, мы выпускаем новый протокол.
    3. Не совсем понятен вопрос, вы не могли бы конкретизировать?
    4. Есть сервис, ответственный за данные клиента, который получает из АБС актуальные данные и хранит у себя в БД. При недоступности АБС данные могут браться из БД сервиса, если мы понимаем, что они актуальные (обновлялись недавно).
    5. Есть несколько стендов, в том числе тест/предпрод. Такие ошибки выявляются на этапе тестирования.
    6. К сожалению, не можем раскрыть эти подробности о проекте.
  • От монолита к микросервисам: ускорили банковские релизы в 15 раз
    0
    Спасибо за фидбек всем, кто читает и комментирует. Как отметили выше, комментарии подсветили ряд важных вопросов, которые мы не затрагивали в материале. Над проектом работала большая команда, уточним некоторые вопросы, чтобы описать подробнее. Просим простить за задержку, обязательно постараемся всем ответить)
  • От монолита к микросервисам: ускорили банковские релизы в 15 раз
    0
    Спасибо за ваши вопросы, уточним некоторые данные и вернемся с ответом.
    Сразу отметим, что базы данных для микросервисов изолированы друг от друга, что позволяет конфигурировать серверы баз данных для обеспечения требуемой доступности и скорости работы. Просим извинить, если по тексту сложилось другое впечатление.
  • От монолита к микросервисам: ускорили банковские релизы в 15 раз
    0
    Базы данных для микросервисов изолированы друг от друга, что позволяет конфигурировать серверы баз данных для обеспечения требуемой доступности и скорости работы. Просим извинить, если по тексту сложилось другое впечатление
  • От монолита к микросервисам: ускорили банковские релизы в 15 раз
    0
    Все верно, если команда одна, состоит из мидл+ профессионалов, а область не очень сложная, то монолит будет идеальным решением — и раскатывать можно достаточно часто.

    Когда команд много, то сложно уследить за каждой. А в нашем случае было и вовсе невозможно. В такой ситуации микросервисы снижают риск написать некачественный код. Но даже если такое произойдет, то переписать 1 микросервис легче, чем распутывать цепочку связей в монолите.

    Этот вопрос не был в полной мере освещен в статье, поскольку не относится к технике, больше к бизнесу.
  • От монолита к микросервисам: ускорили банковские релизы в 15 раз
    0
    Если мы правильно поняли ваш посыл, речь идет о коробке, которая обслуживает много банков. Безусловно, облачные технологии заставляют нас использовать другие подходы и другие архитектурные решения. Но рассматриваемый случай к ним не относится. В нашем случае коробочное приложение крутилось на серверах клиента и в общем случае обслуживало даже не один, а всего лишь часть банка. Это было одной из причин изменения архитектуры.
  • От монолита к микросервисам: ускорили банковские релизы в 15 раз
    0
    Добрый день, обязательно постараемся на все ответить! У вас было много важных вопросов, некоторые из них мы решили уточнить с командой для более полного описания.
  • От монолита к микросервисам: ускорили банковские релизы в 15 раз
    0
    Запас прочности нужен всем, но на практике встречается не так уж часто. У нас достаточно много проектов в работе, и зачастую на старте новых проектов мы находим те или иные недочеты в архитектуре. На ее закладку может не хватать знаний, времени, иногда опыта. Так что считаем, что об этом надо помнить и говорить)