Как и зачем переходить от сервис-ориентированной архитектуры к микросервисам

    Здравствуйте, меня зовут Алексей, я главный IT-архитектор банка «Ренессанс Кредит». Лет десять назад мы, как и многие компании, ускорили свое развитие благодаря сервис-ориентированной архитектуре (SOA). Но со временем требования к архитектуре менялись, и к данной парадигме стали возникать серьезные вопросы. В конце концов мы решили перейти от интеграционной шины ESB к микросервисам. На нашем примере я расскажу, почему стоит задуматься об эффективности SOA и что можно предпринять, если эта модель вас тоже не устраивает.



    Новые проблемы ESB


    Все началось с того, что мы оценили структуру нашей интеграционной шины. На схеме представлена типовая ситуация с интеграционными потоками для ESB.



    Таких блоков может насчитываться нескольких десятков (вплоть до сотни!), и они тесно переплетены между собой. Если потребуется сделать новый продукт и внести какие-то изменения, то на переработку этого здоровенного монолита не хватит никаких ресурсов. И это только общий взгляд. Мы изучили SOA со всех сторон и всего выделили семь основных проблем:

    • Акцент на повторном использовании сервисов. Это правило было краеугольным камнем SOA, но в итоге оно привело к тому, что все команды (фронт, бэк и интеграция) оказались настолько плотно связаны, что любое обновление интеграции требовало регрессионной проверки практически всей шины!
    • Тяжелый технологический стек. Вначале единый контейнер ESB был преимуществом, и это позволяло нам быстро разворачивать сервисы. Но сегодня ограниченный стек технологий, библиотек и языков программирования уже заметно мешает развитию.
    • Превращение ESB в «бутылочное горлышко» для всех процессов. Со временем шина обрастает функциями и превращается в полноценную информационную систему банка, с waterfall-подходом и «нарезанием» интеграционных потоков. Загрузка команды ESB сильно возрастает, что тормозит работу остальных команд развития.
    • DataSilo. В SOA интерфейсы сервисов отделены от имплементации. Но насколько отделены друг от друга данные, которые используются сервисами? Один сервис обращается к данным другого, используется механизм dblink’ов, возникает путаница и «силосная башня данных».
    • Смешение шаблонов интеграции. Строго говоря, для SOA их два: классический MessageBroker, где между системами ходят сообщения для обмена порциями данных, и хаб сервисов, где мы размещаем какие-то сервисы, которые «некуда больше приткнуть». При смешении этих шаблонов ESB превращается в абсолютно «черный ящик».
    • Формирование «теневых IT». Бизнес-заказчики зачастую формируют собственные IT-команды для развития критически важных для себя систем, но при этом использовать шину для интеграции не могут. Так растет число «левых» подключений к информационным системам.
    • Отсутствие поддержки ITSec (информационной безопасности) на уровне концепции. Здесь нужно сделать небольшое пояснение: во-первых, вполне «западная» концепция ESB не учитывает особенности российского законодательства (например, защиту персональных данных при передаче из источника в приемник), а во-вторых – контейнер ESB представляет собой периметр, который эффективно работает, когда внутри него уже не требуется соблюдение специальных требований ITSec.  

    Новые потребности заказчиков


    Традиционная сервисная шина, ориентированная на waterfall, со своими сложными и медленными процессами никак не вписывается в условия рынка. Сегодня заказчики знают о гибких методологиях разработки. Они могут не знать различий между agile и waterfall, но хотят получать первые результаты — от появления идеи до прототипа в эксплуатации — не через 6-8, а через 2-3 месяца, а лучше вообще через один. Пусть это будет MVP, но заказчику важно как можно быстрее проверить бизнес-идею, понять, что решение «взлетит».

    В таких условиях традиционные, горизонтально ориентированные команды уступают вертикально ориентированным, которые работают со всеми составляющими продукта — от канала взаимодействия до бэк-энда. Ребром встает вопрос: как поступить с интеграционной шиной, превратившейся из-за повторного использования сервисов в монолит? Нужен новый технологический подход.

    Фундамент нового подхода


    Мы начали прорабатывать альтернативу SOA с формулировки основных требований:

    1. Возможность быстрого пилотирования идей. Для этого потребуется простая (регулярная, повторяющаяся) структура связей между системами, быстрое развертывание и версионирование.
    2. Поддержка гибкой разработки. Легкое подключение новых, вертикальных команд, выход на уровень «фабрики разработки», с автоматизацией рутинных задач.
    3. Наличие экосистемы с командами разработки разных типов: внутренние, внешние, партнерские. Предоставление интерфейсов для внешнего доступа, контроль этого доступа и биллинг.

    Пирамида технологий


    В соответствии с требованиями мы сформировали пирамиду технологий:


    Теперь о составляющих каждого уровня в отдельности:

    1. Уровень методологии

    • Agile. Гибкий подход сейчас вызывает массу эмоций и противоположных мнений (на тему применимости в организациях разного масштаба). Для себя мы сформулировали главное: этот подход является основой для структурирования требований, быстрого прототипирования и создания MVP – проверки идей продуктов.
    • DevOps. Эта парадигма требует максимальной автоматизации и «размывания границ» между разработкой и сопровождением систем. Она позволяет избежать потерь времени на рутинных операциях развертывания и сопровождения.
    • Фабрика разработки. Движение артефактов от стадии аналитики до развертывания и эксплуатации созданного продукта должно быть непрерывным, без повторного создания артефактов на каждом следующем этап. Например, не должно быть ситуации, когда интерфейс сервиса сначала описывается в каком-то формате аналитиком, а затем разработчик вручную создает тот же интерфейс заново, но уже в другом инструменте.

    2. Уровень инфраструктуры

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

    3. Прикладная архитектура

    • Микросервисная архитектура (MSA). Вопрос о точном определении микросервиса до сих пор открыт. Но для полноценного развития архитектур интеграции и систем мы определили следующие ключевые свойства микросервисов:

    Свойство
    Пояснение
    1
    Разделение интерфейса и имплементации сервиса
    Данное свойство унаследовано от SOA и требует, чтобы изменение реализации не требовало изменения интерфейса. А вызов сервиса требовал только знания интерфейса, без понимания тонкостей реализации сервиса.
    2
    Хорошая гранулярность
    Микросервисы должны быть относительно небольшими («правило двух пицц») и отделены друг от друга так, чтобы изменения функциональности в какой-либо предметной области концентрировались максимально в одном микросервисе.
    3
    Разделение сервисов на всех уровнях
    Микросервисы должны быть полностью отделены друг от друга. На уровне интерфейсов и на уровне исполнения — каждому свой контейнер исполнения. На уровне данных — микросервис имеет доступ только к «своим» данным и ничего не знает об особенностях БД соседнего микросервиса.
    4
    Унифицированное взаимодействие
    Если микросервису требуются данные, доступ к которым обеспечивает другой микросервис, должен работать именно вызов интерфейса. Ни в коем случае не доступ через БД в соседнюю схему.

    Обратите внимание: для MSA нет обязательного требования повторного использования!

    4. Уровень модели данных

    • DDD (Domain Driven Design). Один из самых сложных вопросов — тот набор правил, по которым создаются микросервисы, и обеспечение их связи с более ранними этапами аналитической проработки ПО. Мы попытались оттолкнуться от концепции DDD с двумя основными целями. Во-первых, это позволяет сформировать домены в предметной области и удачно связать их с продуктовыми командами (agile!). Во-вторых, помогает формировать микросервис как API работы с определенным бизнес-объектом — соответствуя ресурсу для RESTful сервиса.
    • Домены соответствуют продуктам банка. Это позволяет отойти от классического разделения на фронт, бэк и интеграцию, прийти к единству с продуктовыми командами.

    5. Уровень интеграции.

    • API Management и подход API First. Интеграция с использованием шины подразумевает «нарезание» интеграционных потоков от фронта к бэку с повторным использованием сервисов. В новом же варианте мы ориентируемся на подход «API First». Бэковые системы готовят максимально общие API. Интеграция строится по принципу базового кристалла: разработчики фронтальных систем выбирают нужные им вызовы API, опубликованные на портале API Management.
    • Open API. Open API подразумевает использование системы API Management для организации доступа и работы принципиально разных категорий разработчиков — внешних, внутренних, партнерских участников экосистемы. Фактически, мы получаем публичное API организации.

    Изменения в архитектуре


    Исходя из нового сочетания технологий, мы представили то, к чему хотим прийти. На рисунке ниже — схема нашей нынешней инфраструктуры с интеграционной шиной. Рядом — та схема, к которой мы стремимся.



    Что меняется? Изначально на уровне бэк-офиса любая АБС имеет бизнес-логику и источник данных. Мы стремимся к тому, чтобы бэк-офисные системы свелись исключительно к хранению и «ядерному» функционалу, где изменения были бы редкими. А продуктовая логика ушла на уровень микросервисов, позволяющих гибко менять и создавать продукты, разделенные по доменам.

    В масштабах канала мы планируем на основе микросервисов сформировать и управлять логикой, «размазанной» по слою фронт-энда. В итоге сами фронтальные приложения будут содержать только канальную логику, то есть нативные приложения для автоматизации нужных каналов обслуживания запросов.

    Все управление доступом будет осуществляться через портал API Management, где будут описаны и опубликованы все API. Здесь любой разработчик сможет получить о них всю информацию и включиться в фабрику разработки. В ней с помощью технологий GitLab организован непрерывный цикл работы — планирование, разработка, тестирование, выпуск и эксплуатация.


    Схема API Management и Open API

    Что дальше?


    Изменения такого масштаба не проходят без сложностей. В основном они связаны с разбиванием на микросервисы монолитных коробочных систем, а также с восстановлением связей в «черных ящиках» нашей ESB и Data Silo. С моделью микросервисов заметно теряет актуальность использование  BPM-движка для построения бизнес-процессов. И сейчас для нас очень важным становится вопрос его альтернативы — event-driven-архитектуры и хореография. Мы также планируем перейти от чистого DevOps к DevSecOps, который будет включать требования ITSec, и разделить наш Data Silo в рамках доменов. Выполнение этих задач потребует активно собирать опыт для проверки и максимально эффективного использования описанных концепций.
    Банк «Ренессанс Кредит»
    21,00
    Компания
    Поделиться публикацией

    Комментарии 54

      +6
      Извините, а для кого эта статья?
        +8
        Для эффективных менеджеров наверное. Отчет о проделанной работе? Мне тоже интересно что это и для кого, навыдергивать идей из книг и никакой конкретики.
        +4

        Классно, но, ваши проблемы с esb от того, что все хотят быть "архитекторами", а думать и за "дисциплиной" следить некому.


        И с этой точки зрения "а давайте микросервисы теперь!" — ровно тоже самое что "а давайте все перепишем!", но проблемы ваши не решит.
        Вы точно так же "намесите" и с микросервисами и придёте ровно к тем же проблемам (правда это случится не сразу и скорее всего ура-реформаторы успеют покинуть проект с повышением)

          +2
          Полностью согласен.
          Перегруженная «логикой» шина и ETL функциями — не повод уходить из SOA в MSA.
          Перегруженные логикой бэки — аналогично, зачем ж вы изначально туда её в таком количестве погрузили?
          MSA вообще достаточно спорная тема. Всем известен предмет, преимущества… Но не смысл.

          Конечно (тут спору нет) проще делать с нуля и красиво, чем исправлять. Но правильнее ли?
          Разделяем шины на Транспорт с ограниченным ETL (например, по объёму и количеству потоков) и BPM часть {тут если говорить именно о SOA и работе с ESB} и уже видим снижение нагрузки и управляемость.

          Полный регресс — хорошо, да. А как насчёт автотестов? Они решат и эту проблему.

          ИМХО, для каждой из описанных проблем есть решение. элегантное и красивое.
          Провести полную перестройку ландшафта под этим флагом можно. Но нужно ли?
          вопрос необходимости.
            +1
            Перегруженные логикой бэки — аналогично, зачем ж вы изначально туда её в таком количестве погрузили?

            Сам работаю в банке и не раз задавался данным вопросом, даже задавал его руководителям различных профильных департаментов… Если усреднить ответ, то он звучал: «Так исторически сложилось.»
              +1
              Стоп, давайте-ка разберёмся.
              В данном контексте «бэк» — это бэк-офисная система. И логика там должна быть и есть — это как «отче наш». Или предлагается РКО, РЦ, ГК делать на «хипстерских» механизмах? :)

              Если же вы имеете в виду, что бизнес-логику запихнули в шину (ESB), то это действительно исторически сложилось, потому что даже в 15-м году ещё маститые гуру советовали её в ESB заносить. На тот момент ESB никто как только транспорт не рассматривал. Она потому и называлась «Сервисная шина предприятия», что выполняла:
              — транспортную функцию;
              — оркестровку сервисов;
              — хореографию сервисов;
              — у многих (даже OpenSource) ESB-решений были встроенные BPM-компоненты;

              То есть ESB подавалась как «серебрянная пуля», решающая все проблемы связности остальных инфраструктурных компонент и систем.

              Это чуть позже выяснилось, что:
              — в таком режиме она ресурсы жрёт как не в себя;
              — не сильно много специалистов умеют ESB готовить;
              — специфичные фреймворки.
              — и т.п.

              Столкнувшись с этим начали искать выходы. Одним из которых и является МСА.
              Главное не делать из МСА той же самой «серебрянной пули» и всё будет нормально.
              Каждому овощу — своё место.

              Чем мне и понравилось решение ребят из РК — чувствуется сбалансированный подход.
            +2
            Вы точно так же «намесите» и с микросервисами и придёте ровно к тем же проблемам
            Скорее всего, проблемы даже усугубятся.
            +2
            По поводу обновления доработок сервисов SOA, согласен. Порой требуется регрессить все процессы. На сколько я знаю, шина на ренессансе под IBM websphere. У нас на проекте оракл soa suite. анализ транзакцтй все же проще. Но с микросервисами на сколько я знаю, возникают сложности анализа транзакций.
              0
              Хорошая статья, спасибо.
              На мой взгляд грамотно продуманная стратегия и хороший вариант TO BE. Безусловно есть ряд спорных, на мой взгляд, моментов.
              Например:
              Что меняется? Изначально на уровне бэк-офиса любая АБС имеет бизнес-логику и источник данных. Мы стремимся к тому, чтобы бэк-офисные системы свелись исключительно к хранению и «ядерному» функционалу, где изменения были бы редкими. А продуктовая логика ушла на уровень микросервисов, позволяющих гибко менять и создавать продукты, разделенные по доменам.

              Как в этом случае будет осуществляться сопровождение продуктов в АБС? То есть да — TTM по продукту Вы минимизируете, будете их довольно быстро выбрасывать на рынок. А дальше? Бэк не начнёт плакать горючими слезами на таких раскладах? :)
              Они же неповоротливые, и им на взятие выпущенного за неделю и (предположим) хорошо и широко проданного продукта на сопровождение к примеру в Core АБС может потребоваться квартал, а то и полгода :)

              Вот это:
              Домены соответствуют продуктам банка. Это позволяет отойти от классического разделения на фронт, бэк и интеграцию, прийти к единству с продуктовыми командами.

              — очень хорошо. Но вижу опять проблемы с бэком, если только не подвязывать к каждому продукту свою АБС :)
                0
                А это всё решается легко путём внедрения продуктового каталога.
                  0
                  Вот прямо так легко и прямо решается? :)
                  Вынужден не согласиться, так как наблюдал как минимум три СУПП, которые не могли решить данный вопрос никоим образом.

                  Вариант продуктового домена — казалось бы ведёт к решению данной темы. Но:
                  1. Резко увеличивает ТТМ.
                  2. Вносит рассогласованность в изменения, вносимые в core АБС.
                  3. Требует наличия арбитража по междоменным изменениям.

                  И продуктовый каталог тут почти никаким боком, если только перечень продуктов банка показать :)
                    –2
                    Не совсем так. Но всю логику раскрывать не буду, нужен ещё 1 сервис «сбоку» :) и ТТМ уменьшится, не будет рассинхрона по логике обработки и прочему.
                    Не будем раскрывать все тайны.

                    Да и увы, идеальной архитектуры не существует. Проблемы всегда будут. И для их решения всегда будут нужны хорошие умы.

                    Алексею — спасибо за статью :)
                      0
                      Тайны никогда не стоит раскрывать :)

                      Я там чуть про другое писал — дело не в ОБРАБОТКЕ, это как раз решаемо.
                      Дело в организации.
                      Детализирую:
                      1. Проактивный бизнес придумал новый кредитный продукт. «Просто бомба! Нужно завтра на рынок!»
                      2. Хипстеры :) на продающем фронте его реализовали вот на раз два (на самом деле за неделю, но это не важно :)).
                      3. Бэк-энд тоже поднапрягся, за пару недель напилил сервисов, реализующих логику и конвейер.
                      4. И вот тут мы приходим в core АБС (пусть даже мы умные и красивые, и пришли прямо в п.1), а они нам — «парни, да вы что? нам чтобы реализовать обслуживание такого кредита как вы нарисовали нужно полгода! да и ресурсов у нас сейчас нет, вон МФСО-9 на носу». И всё — скандал в благородном семействе :)

                      P.S. Присоединяюсь к благодарности в адрес Алексея.
                        0
                        Ну тут видишь ещё что — agile рулит(да, но с корректировками), DevOps как пилоты… и классический waterfall как фабрика.
                        замес :) лишних «артефактов» и неиспользуемых микросервисов будет просто тьма.
                        +нужен будет эксперт по «всем версиям микросервиса НомерДва» (если мы говорим о модели переиспользования с корректировками). А уйди он куда (ну схантили эксперта) и всё, кирдык. Классический чёрный ящик.
                          0
                          Больше трэша! :)
                          Описанный процесс имеет отрицательную сходимость, а в разработку в части АБС agile не заходит от слова совсем.

                          Касаемо микросервисов — не всё так печально, ибо капитализм есть учёт и контроль. Так что если:
                          а) Архитектура всей системы контролируется из одной точки.
                          б) Выстроен процесс сохранения артефактов проектов и разработки.
                          в) В agile-командах есть пишущие архитекторы.
                          то не всё так смертельно. МСА может жить и будет жить лучше чем пакет из полтыщи сервисов на ESB. Которая однозначно становится узким местом в большинстве случаев.
                            0
                            Мы, надеюсь, оба понимаем что выполнение этих Если — трудоёмкий вопрос.
                            Ну и собстно если бы эти Если были в рамках создания текущей SOA модели, то многих проблем бы и не было. Наверное.
                              0
                              Легко только пивко после бани трескать да советы давать, как говорил мой хороший знакомый :)

                              Естественно, что выстраивание процесса управления изменениями в системах такого уровня это не прогулка по набережной :)

                              В модели SOA эти «Если» вряд-ли помогут, так как там всё очень по-своему и весьма своеобразно.
                              Всё-таки разработка под ESB намного ближе к разработке для АБС. Это полноценный конвейер, фабрика. С очередями, приоритетами, нехваткой ресурсов и сопутствующей нервотрёпкой. Даже если мы туда не запихнули бизнес-логику, то есть «от большого ума» не используем её как BPM.
                              И в этом случае бизнеса начинают стонать: «наше ИТ такое плохое, медленное, у них всё криво».
                              Следующий шаг: «мы вот тут нашли клёвых стартаперов, они нам занедораХа на php напилили клёвый продукт! Берите его на сопровождение!». У вменяемого CIO при таком заходе либо просыпается внутренний зверь, либо волосы встают дыбом в различных местах организма.

                              Но задача дать бизнесу короткий ТТМ — есть, наш CIO это понимает и поэтому начинает вытаскивать из ESB-спагетти то что можно и отдавать в те самые домены. Под чутким контролем ДИТ или как оно называется в РК. Не самое плохое решение, хочу заметить.

                              При этом решается вопрос с дефицитными специалистами под WS или иной какой дюжий энтерпрайс. Так как при соблюдении контракта взаимодействия, микросервисы можно делать хоть на питоне :)
                                0
                                А вот про Питон сейчас обидно было :)
                                  0
                                  Да ни боже мой :)
                                  Питон — отличный интерпретируемый язык и замечательно справляется со своими задачами.
                                  И таки да — на нём вполне можно писать микросервисы. Если у вас продуманная архитектура и описаны контракты взаимодействия между м/с.

                +2
                Не существует идеальной технологии управления сложностью, в одних случаях надо логику переносить ближе к данным (в БД), в другом выносить на уровень пользовательского интерфейса. С шиной у Вас были одни проблемы (бутылочное горлышко), а с кучей микросервисов появятся другие (например дублирование алгоритмов). Посмотрите в человеческое тело — например сердечная мышца управляется нейронами, имплементированными прямо в мышцу, хотя по всем методичкам — субъект управления должен быть отделен от объекта, но тогда при ударе по голове человек бы умирал от гипоксии :)
                  –1
                  Вот про логику на уровне пользовательского интерфейса — категорически не согласен. Нечего ей там делать.
                    –1
                    Опять плюсик. Фронт это Фронт.
                    отделять мух от котлет — норм затея.
                      0
                      ERP-система, пользовательские контроли (поля по умолчанию, взаимосвязи ссылочных атрибутов) — что в DAX, что в 1C реализованы на формах, SAP не смотрел. Технически это проще сделать, так как при установки какой-нибудь галочки приходится открывать часть полей, другую часть скрывать, и обновлять лукап-списки. При запихивании в модель придется писать кучу интерфейсов.
                        0
                        Это всё решается SPA и грамотным бэк-эндом.
                        На интерфейсе может быть только простейшая валидация и исполнение контракта безопасности. Ну и «скрыть поля при установке галочки» (что в принципе относится к той же валидации). Это не логика, это просто модель поведения формы.
                          0
                          Добавляем ролевую модель доступа и вуаля элегантность.
                            0
                            Скорее не саму ролевую модель, а её отображение и исполнение.
                            Фронт должен в этом плане быть «простым как выстрел» :)
                            Да, он должен быть красивым, удобным, с максимальным юзабилити.
                            Но — с минимум логики, а лучше вообще без неё.
                            Ибо с точки зрения СИБ — недоверенный контур.
                              0
                              Простой вопрос — где нужно проверять ключевание счетов по БИК — на фронте или в бэке (сервере приложений)?
                              Правильный ответ — и там, и там.
                              На фронте, что бы пользователь сразу видел ошибку.
                              В бэке, чтобы не доверять фронту.
                                0
                                Ну давайте углубимся в тему :)
                                Введённый на форме фронта счёт, на мой взгляд, не должен там же и проходить проверку на ключевание (хотя технически безусловно может), а должен передать (при смене фокуса формы или по иному событию) введённое значение в бэк, в единый сервис проверки ключа. Который должен естественно при этом быть максимально отзывчивым.
                                Таким образом мы убиваем следующих зайцев:
                                — уменьшаем сложность фронта (проверка на ключевание не такой уж простой алгоритм);
                                — имеем единый механизм проверки ключа счёта для всех компонент системы;
                                — упрощаем логику или даже совсем убираем с фронта не свойственную ему логику.

                                А вот простая валидация безусловно должна быть на фронте (проверка на число, разрядность, даты и т.п.)

                                «Я так думаю» (С) :)
                                  0
                                  Во-первых, очевидно, что тем самым вы грузите бэк логикой интерфейса.
                                  Во-вторых, даже проверив при смене фокуса формы, эту же проверку придется выполнять бэку при сохранении всего документа.
                                  В-третьих, простую валидацию (проверка на число, разрядность, даты и т.п.) в силу предыдущего пункта, также придется выполнять на бэке.
                                    0
                                    Во-первых, очевидно, что тем самым вы грузите бэк логикой интерфейса.

                                    Не уверен, что именно так. Проверка введённых значений на соответствие логическим критериям, а не формальным — это занятие для бэка. Пример:
                                    — проверка что в форму для числа введено число, а не срока — это чистый фронт;
                                    — проверка по КЛАДР -однозначный бэк;
                                    Как и ключевание. Зачем тиражировать единый алгоритм проверки в нескольких местах?

                                    NB: Кстати, возможно мы с вами по разному трактуем понятие бэк-энда :). Например в случае node.js понятно что модуль проверки ключа может быть на нём. И дёргаться тоже и разных мест, включая и из бэк-сервисов.

                                    Во-вторых, даже проверив при смене фокуса формы, эту же проверку придется выполнять бэку при сохранении всего документа.


                                    Вопрос доверия. Если у нас есть чёткий контракт взаимодействия фронт — бэк, то бэк может доверять фронту в части как минимум того, что проведена первичная валидация. Обычно доверяют. Ну после того как наловят ошибок на тестировании :)

                                    В-третьих, простую валидацию (проверка на число, разрядность, даты и т.п.) в силу предыдущего пункта, также придется выполнять на бэке.


                                    Зачем?
                                      0
                                      Зачем?

                                      Не верю фронту. Самое простое для злоумышленников — внедриться во фронт, или сэмулировать посылку запроса от фронта.

                                      Как и ключевание. Зачем тиражировать единый алгоритм проверки в нескольких местах?

                                      А почему нет? Он простой, не намного сложнее валидации даты.
                                        0
                                        Тут недоверие скорее не злоумышленникам, а разработчикам фронта — накосячат с типами передаваемых в вызов данных легко и непринуждённо :)
                                        А если злоумышленники, то это приводит нас к тому, чтобы вообще убрать всю логику с фронта.
                                        О чём я и говорил :)

                                        P.S. Именно поэтому весь банковский СИБ сейчас стоит на ушах и требует при МСА взаимодействие только по https минимум.
                                          0
                                          А если злоумышленники, то это приводит нас к тому, чтобы вообще убрать всю логику с фронта.

                                          Нет, это приводит нас к немного другому выводу — что логику необходимо иметь в бэке.
                    0
                    микросервисы полезны иногда, но переводить всё на микросервисы бред, разве что это поможет технически запретить делать некоторые действия которые программисты могут начать делать в монолитном куске, но тут сразу возникает куча других проблем, например перформанс, вот надо мне загрузить и переделать 100 мегов данных из базы, эти данные могут пройти через 3-4 микросервиса, а потом вернуться обратно, затраты по трафику, памяти и процессорному времени будут довольно большие да и медленно это всё, а если таких запросов много да и надо чтоб меньше секунды на обработку пошло, получается надо опять в одну кучу всё пихать, если только нельзя распаралелить, но всё равно надо железо мощнее да и писать это сложнее, вот и получается, что архитектура которая должна была упростить, всё усложняет в монолитном куске можно одни и теже куски передавать между разными участками кода и это будет моментально
                    не скажу что микросервисы плохи, они от слова «микро» то и должны работать с маленькими независимыми кусочками данных, с ними они идеально справляются и легко маштабировать
                      +1
                      Когда смотрю на микросервисную архитектуру, меня одолевают вопросы. Вот самые острые.

                      1. Как в микросервисной архитектуре обеспечивается атомарность/транзакционность?
                      Если моя задача подразумевает три действия в разных сервисах, то как мне добиться чего-то похожего на ACID? Чтобы в случае неудачи в третьем сервисе, я не оставил хвосты в первых двух. И чтобы мои изменения не были видны остальным до завершения задачи?

                      2. Что делать, если нужно осуществлять выборки по критериям, находящимся в разных сервисах? А если там ещё и логика типа = CASE WHEN?
                        –1
                        Вот этот комментарий. Микросервиси не могут в ACID. Люди делали базы данных десятки лет и тут вуаля, и мы отказываемся от ACID чтобы сделать его вручную.

                          0
                          Мне тяжело понять ваш текст.
                          Причём здесь базы данных и десятки лет, если вопрос был про микросервисы, которые не обязаны использовать общее хранилище (и даже один и тот же движок).
                          Или это сарказм и механизм таки есть, но вам что-то мешает его озвучить?
                            0

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


                            А конда мы её сделали, мы получили общее хранилище, только написанное нами вместо того, чтобы взять готовое.


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

                              0

                              Общее хранилище в MSA антипаттерн :)

                                0
                                Не шарю в микросервисах, но это логично.
                                Для разных задач — свои хранилища. Где-то SQL, где-то elasticsearch, где-то Redis.
                                Даже в монолите мы используем то, что лучше подходит.
                                Но у нас вопрос поддержки транзакций не стоит, т.к. основное хранилище одно (SQL). А остальные либо импортируют из него, либо экспортируют в него.
                            0
                            Люди десятки лет делали CA, но оказалось, что P может оказаться важнее C или P.
                              0
                              *последнее A конечно
                            +1
                            Есть такая вещь как распределенная транзакция. Но это требует определеногго подхода и при проектировании хранилища. Идея в том, что сервис сохраняет текущее состояние, и ждет подтверждения от другого сервиса(кому было передано сообщение), что и он отработал успешно. Если такое подтверждение получено не будет то будет послано новое сообщение, которое отменяет предыдущее действие. Есть и специальные паттерны для выполнения таких транзакций, например Saga.
                              0
                              Благодарю.
                              habrahabr.ru/post/146429 — речь о чём-то схожем? Это оно?
                                0
                                Если вы про организацию хранилища, то да, это EventSourcing. Тут правда надо понимать что хранилищем может быть и обычная SQL база, тут дело в самом подходе его организации. Насчет Saga паттерна можно почитать здесь.
                                0
                                А про второй пункт что скажете?
                                В монолите движок СУБД во-первых по статистике поймёт в каком порядке фильтровать, во-вторых, все данные — рядом и сложную фильтрацию можно осуществить на самом низком уровне.
                                Как эти пенальти преодолевают микросервисы?

                                Заголовок спойлера
                                Я про случай типа отобрать клиентов из региона Х, у которых была активность в саппорте (добавить по вкусу фин. анкету клиента и проч).
                                Ведь вручную выполнять фильтрацию по каждому сервису и джойнить в памяти будет не оптимально.

                                  0
                                  Ну про СУБД вы немного заблуждаетесь, на малых объемах данные её возможно будет достаточно, но как только данные станут более существенны прибегают к созданию ещё одной подобной БД — OLAP. При этом проектируют её оптимизированной под специальные запросы.
                                  Ну если вам надо дергать данные с разных хранилищ, то тут ничего не поделаешь, придется делать несколько запросов. Есть конечно вариант хранить все же данные в SQL, но тут необходимо придерживаться нескольких правил, не должно быть связей между таблицами по вторичному ключу у разных сервисов, а также они должны быть с разными схемами. Так можно будет легко разделить данный на две различный базы, если того потребуется.
                                    0
                                    Перечитал описание задачи, да, выглядит похоже на OLAP (но в нашем случае это обычный запрос над живыми данными и тут или запрос по «Live» Olap, который всё равно в БД полезет в попытке узнать факты или облом, потому что старые данные нам не нужны, это не отчёт, это процедура).
                                    Но давайте тогда другой пример, тоже из нашей повседневной практики (я всё на себя эти микросервисы примеряю).
                                    Есть система полномочий, ограничивающая область видимости клиентов по регионам для менеджеров (на самом деле таких критериев несколько и они не задаются при проектировании системы, а появляются с новыми бизнес-требованиями).
                                    Как быть в случае микросервисов? Перед каждым запросом делать выборку доступных ID клиентов из сервиса с адресами и гнать эту выборку в качестве аргумента сервису Х? Или раздавать всем сервисам данные о регионе клиента? Но тогда как следить за их синхронизацией между всеми сервисами?
                                      0
                                      Не совсем понял суть задачи. Если дело в организации хранения, то было бы неплохо организовать хранение всех менеджеров пучками(группами). Из моей практики, выглядит как довольно подходящий кейс для использования AzureTable. Там как раз можно организовать такое хранение. Плохо то, что там индекс как таковой, только один, и он распространяется на PartionKey, что в данном случае является регионом. А если у вас критерии организации данных постоянно меняются, то это точно не ваш случай. А и зачем вам два микросервиса? Один достает данные другой обрабатывает?
                                        0
                                        Скорее второе. Во всех сервисах, имеющих косвенную географическо- административную привязку (например, онлайн операции привязываются к месту первичной верификации) эта привязка явно дублируется, классическая денормализация. Но дублирование исключительно мастер-слейв, не мастер-мастер. Только один микросервис имеет право вносить изменения в конкретные данные, остальные их только потребляют, или запрашивая как клиент у сервера, или подписываясь на изменения.
                                    0

                                    Об этом и речь. Зачем тратить деньги инвестора на определенный подход в проектировании хранилища, когда это уже потратили разработчики БД?


                                    Микросервисы очень специфичный инструмент, сильно требовательный к расходу денег, но дающий прибыль только в очень специфических кейсах.


                                    Кроме того в рамках одного компьютера разные модули программной системы можно рассматривать как те же микросервисы, просто дергаются они по указателю, а не через rest + горячая перезагрузка кода и мы получаем для программиста очень незначительные различия относительно монолита.


                                    Представим что в каком нибудь спринг 7 напихали еще абстракций и теперь мы можем открывать распределенную транзакцию как будто мы открываем локальную и вообще писать код как локально, не занимаясь конфигурацией сераисов по N часов. Вместо виртуальных таблиц указателей компилятор будет формировать сервис-роутер и прочую обвязку. И в итоге получим мы тоже самое программирование, и те же проблемы какие были без микросервисов.


                                    Мы получим только — 1) горячая перезагрузка кода
                                    2) хорошее масштабирование именного того, что жрет ресурсы.


                                    Но компетенции отдела разработки должны быть сильно выше для всего этого

                                  +1
                                  Merrimac

                                  Акцент на повторном использовании сервисов. Это правило было краеугольным камнем SOA, но в итоге оно привело к тому, что все команды (фронт, бэк и интеграция) оказались настолько плотно связаны, что любое обновление интеграции требовало регрессионной проверки практически всей шины!


                                  Два вопроса:
                                  1) Почему регрессионная проверка почти всей шины — это проблема? Это ведь можно по разному организовать.
                                  2) Имхо, и вы можете меня поправить, здесь проблема может быть не столько в факте повторного использования, сколько в неудачной композиции.

                                  Поддержка гибкой разработки. Легкое подключение новых, вертикальных команд, выход на уровень «фабрики разработки», с автоматизацией рутинных задач.


                                  Назовите, пожалуйста, топ-3 причины, по которым вы считаете, что гибкая разработка в системе SOA/ESB невозможна.
                                    0
                                    Скажите, а чем конкретно вы решили заменить BPM в связке микросервисов?
                                      0
                                      Ключевое: Жадность --> ведёт к банкротству.

                                      Open-source — не халява, а аналог «дизеля» который даёт взаймы/кредит на старте, но с ростом придется заплатить и возможно даже больше чем за IBM/Oracle.

                                      Если для Вас специалист по «IBM ESB» — дорого, то обратите внимание на price специалистов 80-99 level в open source. И задайте себе вопрос — на чём в том числе зарабатывает Open-source.

                                      IBM websphere ESB — больше не продадут, теперь в сад (в IBM Cloud), но по закону не положено, или замена на Broker, но тут опять можно наступить на аналогичные грабли.
                                      www-01.ibm.com/software/support/lifecycleapp/PLCDetail.wss?from=spf&synkey=B112118W91756Y91

                                      Работать на не поддерживаемом продукте видно не очень хочется.
                                      В этот раз желают подобрать что-то более «долгоиграющие» и не столь монолитное с возможностью обновления, модернизации по частям, а главное поддержкой не от одной компании (ожидая обновление EE многие уже «стухли», да и сама java — бежит к модульности с более частыми релизами/все по кругу в этом мире :) ).

                                      Что-то в схеме в статье явно не хватает (впрочем об этом уже сказали).
                                      Ключевое ACID, хранение состояния --> реализация распределенных транзакций, выполнение/сохранение прежних требований к отклику сервиса, необходимость увеличения в разы пропускной способности сети,…

                                      Также интересно посмотреть/почитать какой выбрали инструмент для выполнения задач Orchestration всего этого зоопарка.

                                      И главное — есть ли у «stockholder» понимание, что содержание такой архитектуры обойдётся поболее чем готовый продукт от IBM.
                                      IBM — предоставлять курсы/литературу — ввести нового человека не так уж и сложно.
                                      Это не одно и тоже, чтобы «вкурить» разнородную систему/архитектуру в целом.
                                      Так, работу по «IBM — предоставлять курсы/литературу» от части придется выполнять/поддерживать в актуальном состоянии самим.





                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое