От микросервисного монолита к оркестратору бизнес-сервисов

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


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

    Этап №1. Монолит


    1.1 Характеристики


    Обычно монолитную архитектуру можно описать так:


    1. Единая точка разработки и деплоя
    2. Единая база данных
    3. Единый цикл релиза для всех изменений
    4. В одной системе реализовано несколько бизнес-задач


    Погружение в контекст:


    1. Pattern: Monolithic Architecture
    2. Бизнес-гибкость через микросервисную архитектуру
    3. Don’t start with a monolith

    1.2 Проблемы


    1. Система единая, при этом решает много разных бизнес-задач. Разные бизнес-задачи развивают разные подразделения компании и двигаются с разной скоростью. Отсюда возникает проблема с взаимозависимыми релизами разных подразделений, когда все ждут самого медленного.
    2. Сложно масштабировать бизнес-приложения, которые объединяет монолит. Это приводит к тому, что не учитываются особенности каждого приложения, и масштабирование делается неэффективно.
    3. При выборе технологического стека для новой бизнес-задачи приходится подстраиваться под среду разработки монолита, хотя этот выбор не всегда является наилучшим.
    4. Система уходит в релиз целиком, поэтому должна быть протестирована целиком. Это приводит к сложному регрессионному тестированию, затягиванию процесса тестирования и репотинга багов всем поставщикам изменений, замедлению скорости релизов, и, соответственно, увеличению времени time-to-market.
    5. Последнее ведет к тому, что бизнесу тяжело быстро собрать обратную связь от рынка.

    1.3 Как перейти на следующий этап


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



    В дополнение к SRP есть подход от любителей Domain-Driven Design: микросервис ограничивается одним или несколькими Bounded Context.

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



    Погружение в контекст:

    1. Переход от монолитной архитектуры к распределенной
    2. How to break a Monolith into Microservices
    3. Command and Query Responsibility Segregation (CQRS) на практике
    4. Работа с унаследованным кодом: Риски, анализ проекта и стратегии работы
    5. StranglerFigApplication

    При создании микросервисной архитектуры полезно периодически проверять себя по чеклисту The Microservice Architecture Assessment, чтобы не упустить какую-то важную деталь.



    Этап №2. Микросервисный монолит


    2.1 Характеристики


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



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



    Получается, что все части монолита распались на микросервисы, а их обратно соединили паутиной синхронных и асинхронных интеграций:





    По факту, получился тот же монолит, но с большим количеством новых проблем.

    2.2 Проблемы


    1. Прямые связи между микросервисами усложняют анализ проблем. Например, запрос может пройти через 5 микросервисов, прежде, чем вернуться с ответом. Что если на третьем микросервисе запрос завис? Что если там была ошибка? Что если на втором шаге должно было создаться сообщение в очередь, но оно не появилось? Возникает сложность с разбором проблем.
    2. Предыдущий пункт усложняется, если у микросервиса много экземпляров. Тогда возникает ситуация, что запрос пришел на экземпляр, который завис.
    3. Архитектуру сложно понять и, чем больше сервисов вы добавляете, тем запутанней всё становится. В целом, добавление новых сервисов нелинейно повышает сложность архитектуры.
    4. Неизвестно, кто потребители вашего API, что добавляет сложности в проектировании API и его изменении.
    Если на пути рефакторинга монолита вы остановитесь на этом этапе, то, вполне резонно, сделаете вывод, что с монолитом было лучше и дешевле.

    2.3 Как перейти на следующий этап


    Основные идеи: локализовать точки интеграции и контролировать все потоки данных. Чтобы этого добиться, надо использовать:

    1. API Gateway для локализации синхронных взаимодействий и мониторинг/логирование трафика между микросервисами. В идеале, надо иметь визуализацию трассировки любого запроса.
    2. Service Discovery для отслеживания работоспособности экземпляров микросервиса и перенаправление трафика на «живые» экземпляры.
    3. Запретить прямые вызовы между микросервисами.
    Чтобы избежать типовых проблем и упростить разработку, рекомендую взять на вооружение подходы по повышению отказоустойчивости:

    1. Circuit Breaker
    2. Tolerant Reader
    3. Embracing Failure
    4. The Timeout AntiPattern
    5. Graceful Degradation
    6. Use versioning only as a last resort

    Этап №3. Микросервисы


    3.1 Характеристики


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



    Становится заметна главная черта хорошей архитектуры: сложность системы растет линейно с увеличением количества микросервисов.





    Погружение в контекст:


    1. Pattern: Microservice Architecture
    2. Microsoft Dev School — Микросервисы, чистый PaaS и конкурс мисс Россия
    3. Microservices, a definition of this new architectural term

    3.2 Проблемы


    На этом этапе сложные технические задачи решены, поэтому начинаются проблемы на уровне бизнес-задач:


    1. Среди сотен микросервисов и разных API бизнес не может понять, какие инструменты есть у него в руках. Пазл складывается в стройные картинки только у энтерпрайз архитекторов, а их, как известно, очень мало на Земле.
    2. Бизнес хочет увидеть лес за деревьями, чтобы понимать, какие есть детали и как из них можно собирать новые продукты, не прибегая к разработке.
    3. Сборку новых продуктов из существующих кубиков, хочется совместить с продуктовой разработкой, чтобы Владелец продукта сам ориентировался, какие ему доступны ресурсы.

    3.3 Как перейти на следующий этап


    Многие компании не идут дальше, потому что на текущем этапе бизнес-задачи могут решаться уже достаточно быстро и эффективно. Тем, кто решают двигаться дальше:


    1. Изучите концепцию Citizen Integrator. Для наглядного примера заведите себе пару процессов в Zapier.
    2. Опишите микросервисы в виде блоков, решающих бизнес-задачу, и сделайте из них конструктор. Это можно сделать: 1) на готовых инструментах, 2) обернуть BPM-движки типа Camunda, 3) написать всё самим с нуля. Все три подхода жизнеспособны. Выбор подхода зависит от стратегии вашей компании и наличии у вас ИТ-архитекторов и хороших программистов.





    Погружение в контекст:


    1. The Microservices Workflow Automation Cheat Sheet
    2. Clouds, iPaaS, Citizen Integrator and Why India’s Outsourcing Is Losing Money

    Этап №4. Оркестратор бизнес-сервисов


    4.1 Характеристики


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



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





    4.2 Проблемы


    1. Создание, внедрение и развитие оркестратора бизнес-процессов является дорогим удовольствием.
    2. Если ослабить архитектурный контроль, оркестратор может превратиться в узкое место систем, созданных на нем.
    3. Чем больше систем создается на оркестраторе, тем больше бизнес зависит от этого решения. В целом, это начинает напоминать проблемы монолита.

    4.3 Как перейти на следующий этап


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



    Заключение


    Эти четыре этапа показывают, как мне кажется, естественный ход вещей:


    1. Вначале приложение небольшое и решает одну бизнес-задачу. Со временем в него добавляют много всего и оно превращается в неповоротливый монолит.
    2. При первой попытке разделить монолит многие команды не готовы к возрастающей сложности. Монолит делится на много микросервисов, но из-за большого количество взаимосвязей получается тот же монолит, только с новыми проблемами: простейшие задачи типа трейсинга запроса или мониторинга инфраструктуры становятся вызовом для команды разработки.
    3. Когда сложности решаются, получается стройная и масштабируемая архитектура. Добавление новых микросервисов линейно повышает сложность.
    4. На последнем этапе приходит бизнес и резонно говорит, что раз есть готовые решения бизнес-задач, то давайте делать новые продукты без разработки. Будем соединять готовые независимые блоки в новые бизнес-процессы через оркестратор.

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      +3
      На последнем этапе приходит бизнес и резонно говорит, что раз есть готовые решения бизнес-задач, то давайте делать новые продукты без разработки. Будем соединять готовые независимые блоки в новые бизнес-процессы через оркестратор.


      Этап 4 — ненаучная фантастика.
        0
        Я вижу это на практике. Например, в Леруа Мерлен есть такая платформа.
          +1

          Пример, который работает и с которым я работал https://lm-tech.ru/platformeco/

          +19
          У вас стрелочки не хватает.
          image
            0
            Я на нее намекнул в описании проблем в п.4, но это не всегда так. Бывает, что скатываются к монолиту, бывает, что нет. Всё зависит от уровня специалистов в компании.
              0

              Почему вы утверждаете, что монолит — это плохо и к нему можно только "скатиться" имея недостаточно хороших специалистов?

                +1
                Я описал проблемы, которые возникают при монолитной архитектуре. Если для бизнеса они критичны, значит «монолит это плохо». Если для бизнеса эти проблемы не критичны, значит монолит это не плохо
            +5
            Не совсем понятно как решились проблемы на этапе 2 Микросервисный монолит, при переходе к Микросервисам.
            Архитектуру сложно понять и, чем больше сервисов вы добавляете, тем запутанней всё становится. В целом, добавление новых сервисов нелинейно повышает сложность архитектуры.

            Добавили gateway, service discovery и чего? Архитектуру все также сложно понять. И от того, что сервисы вызывают друг друга через gateway с использованием service discovery линейности не прибавилось.
            Что если на третьем микросервисе запрос завис? Что если там была ошибка? Что если на втором шаге должно было создаться сообщение в очередь, но оно не появилось?

            И как нам тут поможет то, что мы делали в п.2.3? Предложенные паттерны (типа Circuit Breaker) могут помочь, но это большая и непростая работа по их внедрению и об этом ни слова.
              0
              При работе через API Gateway видно кто и как кого вызывает. Управляемость и наглядность повышаются в сравнении с беспорядочными запросами между микросервисами напрямую.

              По поводу внедрения все этого. Это очень сложно и довольно дорого. Переписывание монолита на микросервисы обходится примерно как стоимость самого монолита. При этом есть риск сделать еще хуже, потому что компетенции нужны довольно высокие. Компании идут на этот шаг, если проблемы монолита становятся критичны для их бизнеса.
                +1
                При работе через API Gateway видно кто и как кого вызывает. Управляемость и наглядность повышаются в сравнении с беспорядочными запросами между микросервисами напрямую.

                Порядка в запросах же не прибавилось. Если сервису А нужно вызвать сервис B, получить от него ответ, и в зависимости от ответа вызвать или сервис C или сервис D и опять что-то сделать, то вот вся эта цепочка останется и никуда не денется с гейтвеем или без. Чем тут gateway поможет?
                Еще, нужно понимать, что делая gateway, вы создаете бутылочное горлышко по сути и вам его придется масштабировать. И тут уже без инструментов трассировки запросов не обойтись. А если применять инструменты трассировки запросов, то в принципе все равно что отслеживать запросы с гейтвеем что без него.
                  –1
                  С точки зрения сервиса А действительно ничего не поменяется. Но представьте, что вам нужно понять, кто вызывает сервис А. Или нужно понять, где у сервиса А лежит API. API Gateway хорошо структурирует связи.
                    +2
                    Или нужно понять, где у сервиса А лежит API

                    Не совсем понял что это значит.

                    API Gateway хорошо структурирует связи.

                    А также умножает кол-во всех запросов на 2…
                  0
                  не рассматривали для этого варианты с Service Mesh?
                    0
                    «управляемость» не повышает потому что не появляется из воздуха и соответственно добавление прокси между вызовами само по себе управляемости не добавит.
                    Да и визуализация межсервисных вызовов- есть широкий ассортимент инструментов трассировки.
                    Не обязательно вводить доп.нагрузку и точку отказа для этого.

                    В остальном — судя потому куда ветер дует сейчас — в service mesh — это в некотором смысле происходит «под капотом».
                  +1

                  Четвертый этап, который тут описан — это давно известный SOA, который провалился чуть менее, чем везде.

                    +2
                    Из этой идеи мне не нравится:
                    1) Бизнес схемы. Сама механика использования бизнес схем — имхо, неудачная. Это выглядит красиво только на простых задачах, но превращается в ад, когда количество блоков в схеме приближается к 100, добавляются условные операторы, подобие циклов. Ни на один монитор это не влезает, поэтому начинают придумывать «группы блоков», которые можно свернуть/развернуть — но даже с ними быстро понять «код» — непросто. В классическом программировании уже давно этот вопрос решен: разделением на функции/классы ООП.
                    2) сама идея «программирования не-айтишниками». О нее уже многие набили шишки. Для не-айтишников приходится максимально упрощать апи, а для этого часто в жертву приходится принести производительность. Причем речь часто идет о потере производительности на порядки. А это быстро сводит на ноль идею масштабирования — ибо масштабированием мы пытаемся повысить производительность, а повышать ее перед этим убив в 10-100 раз — так себе идея.
                    3) отладка. В монолите мы ставим точку останова и смотрим, что передается. Легко по шагам проходим. Подобных инструментов для микросервисов пока не придумано. В микросервисах, я так понимаю, мы откатываемся назад в развитии средств отладки — по сути до «отладки принтом» — т.е. анализом километров избыточных логов, да еще и разбросанных по разным сервисам.
                      0
                      Логи должны быть аггрегированы в одном месте и связаны через CorrelationId. Не очень понятно в чем здесь идейная разница с монолитом
                        +2
                        Идейная разница в том, что в монолите можно пользоваться отладчиком, а не только логами. Это в разы быстрее и удобнее.
                          +3

                          А еще лучше писать тестируемый код, грамотно декомпозировать и писать качественные логи — тогда и отладчик будет не нужен.
                          Я лично практически не пользуюсь отладчиков — мне вполне достаточно логов.

                            0
                            Тестируемый код, хорошая архитектура и качественные логи — они всегда хороши. В любой ситуации.
                            Реальность же чаще такова, что есть код какого-то уровня легаси, часть из него вообще нельзя менять и где-то там произошел затык. И надо бы определить где и почему. И у меня стойкое ощущение, что с отладчиком это в разы быстрее, чем по логам. Просто потому, что (очень условно) отладчик позволяет «детализировать/обощать» информацию вплоть до функции. А с логами чаще всего в проектах лишь одна настройка уровня логов на весь проект. Бывает, что у каждого компонента своя настройка уровня логов, но я ни разу не видел возможностей задать для каждой функции свой уровень логов.
                              +2

                              У вас потоки есть в монолите? Или всё в один ствол?
                              Принципиально, нет никакой разницы, монолит у вас с сообщениями между потоками или сервисы.
                              Что там, что там, дебажить что-то сложное будет одинаково трудно.
                              Что логи, что дебаггер будут влиять на поведение компонента, притом, логи в гораздо меньшей степени. Я вижу возможности делать разную детализацию логов для разных модулей даже в самописных логгерах, зачем гранулярность до функций — непонятно.

                                0
                                зачем гранулярность до функций — непонятно

                                Допустим, потому, что не все ф-ции pure и где-то она (ф-ция) "стреляет в колено" и нужно смотреть на то самое изменение состояния через дебаггер

                            0
                            Я не то чтобы за микросервисы, но справедливость дороже.
                            что в монолите можно пользоваться отладчиком,

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

                              Отладчик на продакшене — ну-ну. А вот в тестовой среде отлаживать можно, только вот поведение может быть не то. Именно поэтому становятся популярны всяческие решения типа APM/tracing — они позволяют именно на продакшене отлавливать проблемы.

                                0
                                Отладчик на продакшене — ну-ну.

                                Кто сказал, что на продакшене?
                                Почитайте внимательно, выше было о том, что в монолите удобно дебажить, а в микросервисах, вроде как, нет.
                                  0

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

                                0
                                часто микросервисы пишутся на разных языках, это добавляет сложности в отладке.
                                т.е. чтобы дойти до бага, нужно пройти 3-4 сервиса на разных стеках.
                                  0
                                  часто микросервисы пишутся на разных языках, это добавляет сложности в отладке.

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

                                  С чего это? А как они друг друга вызывают?
                                  Вы же сами дальше пишете
                                  позволяют увидеть кол граф между сервисами
                                    0
                                    Я имел ввиду, что можно увидеть все, что происходило в системе по определенному correlationId. Куда и какой запрос прилетел изначально, какие события он затригерил, какие доп данные из других сервисов были вытянуты ApiGateway-ем.
                              0
                              1) К сожалению, люди из бизнеса не могут заглянуть в код и порадоваться, что «классическом программировании уже давно этот вопрос решен». Использовать квадратики, когда их много тоже не очень удобно, но это всё равно удобней, чем вглядываться в кодовую базу сотни сервисов.
                              2) Вопрос производительности имеет место быть, но он решаем при грамотном проектировании.
                              3) Да, в монолите в этом плане намного проще :) Микросервисы добавляют сложности, как я написал, в обнаружении проблем и понимании как проходит запрос и какие события при этом создаются.
                                –1

                                3). Не особо вижу отличий микро-сервисов от многопоточности в монолите. Если у вас в монолите асинхронное взаимодействие — ваши потоки фактически становятся сервисами. Да, разница может быть в том, что можно всех одновременно убить при ошибке, а так — одно и то же. Разве что, отладчику чуть проще работать в одном процессе, но это очень зависит.
                                Понимание логики и событий нужно и в случае монолита, при этом, как я уже писал, ошибка в его случае стоит гораздо больше, чем в случае микросервиса.

                                  0
                                  Микросервис можно раскатать на 150 машин и он будет работать быстрее, а в монолите рано или поздно будет достигнут предел вертикального масштабирования
                                    +1

                                    Как будто монолит (с костылями и велосипедами) не умеет работать в распределенном режиме......

                                      0
                                      Может, но иногда с большим оверхедом. Когда вместо того, чтобы масштабировать узкое место, мы добавляем ноду с целым экземпляром монолита.
                                        +1

                                        Ценность масштабирования сильно преувеличена — как примеры:


                                        1. упираемся в БД — как будем масштабироваться? Надо сначала корневую причину ограничения в БД решить (шардирование, репликация и пр. — что достаточно серьезно)
                                        2. разворачиваемся на своем железе — все равно прыгнуть выше головы не сможем и задействовать ресурсы, которых нет.

                                        Конечно, можно двигать в облако… но это реально дорого. И все равно софт к этому должен быть "готов"

                                          0
                                          разворачиваемся на своем железе — все равно прыгнуть выше головы не сможем и задействовать ресурсы, которых нет

                                          Если нет ресурсов, то тут никакая архитектура не поможет, увы. Но, речь, если что, о горизонтальном масштабировании, которое зачастую дешевле вертикального.
                                          Конечно, можно двигать в облако… но это реально дорого.

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

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

                                              0

                                              Статьи по запросу «scale up scale out comparison» говорят об обратном. Если коротко, то супер-машина с 100ГБ оперативки стоит дороже, чем 10 машин с 10ГБ оперативки

                                                0
                                                В смысле — теоретически у вертикального масштабирования сначала цена ниже, потом есть некая точка перегиба и потом только оно становится дороже
                                      +1
                                      а если монолит масштабирован горизонтально, он уже не монолит?
                                +1

                                Чем в вашем представлении отличается приложение, которое решает одну бизнес-задачу от микросервиса?

                                  0
                                  Если приложение решает одну бизнес-задачу (соответствует SRP), то оно и есть микросервис
                                    0
                                    В целом это хорошее отделение, но стоит уточнить:
                                    Приложение пилит одна команда. Приоритеты по развитию приложения определяет один человек.
                                  +1
                                  Сложность при переходе на микросервисы никуда не девается, она просто переходит в отладку и мониторинг, поддержку и эксплуатацию.
                                  Иллюзия дешевизны и простоты испаряется при начале эксплуатации, поиске кадров и координации разработки при выкатке разных версий микросервисов.
                                    +1
                                    Иллюзия дешевизны и простоты

                                    Это ошибочная иллюзия. Если у бизнеса есть цель уйти от проблем монолита, то за это придется платить. Тут дело в том, что если ваши конкуренты смогли перейти на микросервисы и получить ускорение, то вам тоже придется это сделать, потому что захочется не отставать в скорости.
                                    +4
                                    Иногда нужно задаться вопросом: а зачем разбивать монолит и плодить DevOps?
                                    Может обычный decoupling достаточен?
                                    Зачастую продукту и не требуется горизонтальная масштабируемость (нагрузки небольшие) и микросервисы не выгодны как архитектурное решение для поставленной задачи.

                                    В зависимости от взаимодействий отделов, другой отдел вполне может использовать либо коробочное приложение 3-ей фирмы, либо создать другое самодостаточное приложение.
                                    Главное, чтоб решало задачи, выдерживало пиковые нагрузки, интегрировалось и могло прорабоать х лет без серьезных вложений в доработку и обслуживание.

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

                                    На случай pushback: 25+ лет использую разные архитектуры для разных задач, включая описанные автором решения.
                                    Суть: разным задачам разная архитектура.
                                      +1
                                      Я согласен, что делать микросервисы ради моды нет смысла, потому что такая архитектура дороже в реализации и развитии
                                      +1
                                      Спасибо!
                                        +2
                                        Во всех архитектурах микросервисов и подобных решений не хватает дополнительных метрик связанными с жизненными циклами бизнес логики. Нужно понимать, что сформировавшийся логике легче может жить в вакууме, чем новым идеям, которые могут переписываться хоть каждую неделю.

                                        В своей практике делаю два условных слоя: Сервисы и Бизнес логика. Также есть их этапы эволюции:

                                        1. Монолит. Сервисы отвечают за свою предметную область и вначале предоставляют просто CRUD, Бизнес Логика же использует эти сервисы под свои потребности. Если бизнес логика повторяется в нескольких местах, то я оставляю дубликат кода, так как логика может поменять в одном из мест достаточно быстро.

                                        2. Монолит. При формировании уже устойчивой бизнес логики можно анализировать дубликаты кода для определённой предметной области и выносит в соответствующий Сервис. Тем самым мы уменьшаем код в Бизнес Логики и начинаем наращивать сервисы устойчивой логикой уменьшая вариативность их использования.

                                        3. Микросервисы. После формирования Сервисов с решением своей задачи в предметной области(а не CRUD), можно выносит такие Сервисы в отдельные узлы со своими техническими особенностями при необходимости. При этом у нас остаётся оркестрация в виде Бизнес Логики.

                                        Описанный выше подход не использует триггеры и эвенты, Сервисы не общаются между собой никак, вся логика вызовов строится внутри Бизнес Логики, на то это и оркестрация. Если посередине Процесса-1 одного сервиса нужно вызвать Процесс-2 другого сервиса, то Процесс-1 просто разбивается на два отдельных Процесса и Бизнес логика вызывает их по порядку передавая данные между ними.

                                        Также это очень хорошо ложится под паттерн Saga и вопрос с распределёнными транзакциями.

                                        P.S.
                                        В 2012 году наткнулся на блог Александра, даже задавал вопросы по архитектуре, состоял в .net рассылке. Спасибо большое, Вы внесли большой вклад в моё развитие. Рад, что спустя такое количество времени нахожу общие идеи и могу понимать все эти решения.
                                          0

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


                                          P.s. Рад, что как-то вам помог :)

                                          –1
                                          во всех этих архитектурных концепциях, которые так сладки уху бизнеса, главный компонент — собрать все лавры и идти дальше прежде чем начнутся последствия этих решений

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

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