что такое микросервисы простыми словами
Микросервисы: что это, зачем это и когда нужно их внедрять
Закон Конвея и связь между бизнесом, организацией и информационной системой
«Любая организация, которая проектирует какую-то систему (в широком смысле) получит дизайн, чья структура копирует структуру команд в этой организации»
— Melvyn Conway, 1967
На мой взгляд этот закон скорее соотносится к целесообразности организации бизнеса, нежели напрямую к информационной системе. Поясню на примере. Допустим, у нас есть достаточно стабильная бизнес возможность с жизненным циклом такой длительности, чтобы имело смысл организовать предпринятие (это не опечатка, но мне очень нравится этот термин, который я утащил) Естественно, что обеспечивающая система этого бизнеса будет организационно и процессно соответствовать этому бизнесу.
Бизнес-ориентированность информационных систем
Все течет, все изменяется или микросервисы — средство борьбы со сложностью?
Прежде чем продолжить, рассмотрим некоторые заблуждения касательно микросервисной архитектуры.
Сторонники использования микросервисного подхода часто говорят о том, что разбиение монолита на микросервисы упрощает подход к разработке за счет уменьшения кодовой базы отдельных сервисов. На мой взгляд это утверждение является полнейшим бредом. Серьезно, очевидное взаимодействие в рамках монолита и гомогенного кода кажется сложным? Если бы это действительно было так, все проекты бы изначально строились как микросервисы, в то время как практика показывает, что миграция из монолита в микросервисы является куда более распространенной. Сложность никуда не исчезает, она просто переходит из отдельных модулей в интерфейсы (будь то шины данных, RPC, API и иные протоколы) и оркестрирующие системы. И это — сложно!
Преимущество использования гетерогенного стека тоже является сомнительным. Я не буду спорить, что такое тоже возможно, но в реальности редко встречается (Забегая вперед — это должно иметь место быть — но скорее как следствие, нежели преимущество).
Жизненный цикл продукта и жизненный цикл сервиса
Взгляните еще раз на диаграмму выше. Я не случайно отметил уменьшающийся жизненный цикл отдельной версии бизнеса — в современных условиях именно ускорение перехода бизнеса между версиями является определяющим для его успеха. Успешность продукта определяется скоростью проверки бизнес-гипотез в нем. И вот здесь на мой взгляд и закопано ключевое преимущество микросервисной архитектуры. Но пойдем по порядку.
Перейдем на следующую ступень эволюции информационных систем — на сервис-ориентированную архитектуру SOA. Итак, в какой-то определенный момент мы выделили в своем продукте долгоживущие сервисы — долгоживующие в том смысле, что при переходе между версиями продукта есть шансы что жизненный цикл сервиса будет дольше, чем жизненный цикл очередной версии продукта. Логично было бы не изменять их вообще — нам важна именно скорость перехода к следующей версии. Но увы, мы вынуждены вносить постоянные изменения в сервисы — и здесь у нас все годится, и практики DevOps, и контейнеризация, и прочее — все что в голову придет. Но это все еще не микросервисы!
Микросервисы как средство борьбы со сложностью… управления конфигурацией
И вот тут мы можем наконец-то перейти к определяющей роли микросервисов — это подход, упрощающий управление конфигурацией продукта. Детальнее говоря, функция каждого микросервиса описывает именно бизнес-функцию внутри продукта согласно доменной модели — а это уже вещи, которые живут не в короткоживущей версии, а в долгоживущей бизнес-возможности. И переход к следующей версии продукта происходит буквальным образом незаметно — вы изменяете/добавляете один микросервис, а возможно и просто схему их взаимодействия и внезапно оказываетесь уже в будущем, оставляя за бортом плачущих конкурентов, продолжающих прыгать между версиями своих монолитов. Теперь представьте себе, что имеется достаточно большой объем микросервисов с заранее определенными интерфейсами и бизнес-возможностями. И вы приходите и строите структуру вашего продукта из готовых микросервисов — просто рисуя диаграмму например. Поздравляю — у вас появилась платформа — и теперь вы можете себе бизнес накликать. Мечты, мечты.
Что такое микросервисы: особенности архитектуры, примеры использования, инструменты
Авторизуйтесь
Что такое микросервисы: особенности архитектуры, примеры использования, инструменты
Архитектурный стиль микросервисов — это подход, при котором система строится как набор независимых и слабосвязанных сервисов, которые можно создавать, используя различные языки программирования и технологии хранения данных. Концепция микросервисов позволяет поддерживать слабую связанность сервисов в процессе работы над системой, что определяют паттерны Low Coupling и High Cohesion.
Подробности — в видео и текстовой расшифровке ниже.
Монолит vs микросервисы
При монолитной архитектуре система обычно состоит из 3 блоков: пользовательский интерфейс, хранилище данных и серверная часть. Серверная часть обрабатывает запросы, выполняет бизнес-логику, работает с БД, заполняет HTML-страницы. Любое изменение в системе приводит к обновлению версии серверной части приложения.
В случае с микросервисной архитектурой обновляется только изменённый сервис. Если изменения затрагивают интерфейс сервиса, это потребует координации всех его клиентов. Цель хорошей микросервисной архитектуры — максимально уменьшить необходимость координации сервисов.
Что такое контракт
Контракт — это формализация возможностей взаимодействия с микросервисом. В случае с REST API эндпоинты сервиса и схема данных являются контрактом. Первоначальная разработка архитектуры — это декомпозиция системы на слабосвязанные сервисы, создание интерфейсов и связей между ними, поддержка целостности данных без потери производительности. Помочь с решением данной задачи могут шаблоны Tolerant Reader и Consumer-Driven Contracts.
Микросервисная команда
Команда не должна включать в себя больше людей, чем можно насытить двумя пиццами. Такое правило использовала компания Amazon при распиливания своего монолита в 2002 году. Вполне допустимо и правило developer per service, то есть один разработчик на один микросервис.
25–27 ноября, Онлайн, Беcплатно
Когда большая система разбивается, часто происходит так, что образовываются команды на базе технологий. При такой ситуации команды размещают логику на тех слоях системы, к которым имеют доступ. Закон Конвея в действии:
«Любая организация, которая проектирует какую-то систему (в широком смысле) получит дизайн, чья структура копирует структуру команд в этой организации»
Микросервисный подход предполагает разбиение системы на сервисы по бизнес-требованиям. Сервисы включают в себя полный набор технологий: UI, storage, backend. Это приводит к созданию кросс-функциональных команд, имеющих достаточно компетенций для реализации всех необходимых сервисов, покрывающих 100% бизнес-функционала. Команды должны отвечать за все аспекты ПО, которое они разрабатывают, включая поддержку его в режиме 24/7. В таком случае возможность проснуться от звонка в 3 часа ночи — это очень сильный стимул писать хороший код.
Насколько большим должен быть микросервис
Логика работы сервиса должна полностью уместиться в голове одного разработчика, независимо от количества кода и людей. Проектируя систему, мы имеем выбор, как разработать каждый микросервис. Например:
Архитектура микросервиса даёт полную свободу в выборе технологий и инструменария.
Инструментарий для реализации микросервисов
В процессе реализации микросервисной архитектуры существенным упрощением будет использование систем CI/CD, системы оркестрации, Service Discovering, мониторинга и сбора логов.
Необходимо быть уверенным в том, что приложение работает правильно. Для этого запускаются автоматические тесты, при этом система разворачивается в отдельной среде (Automated Deployment).
Цепочка синхронных вызовов микросервисов приведет к ожиданию ответов от всех сервисов по очереди. Поэтому используйте правило «Один синхронный вызов на один запрос пользователя», как это сделали в The Guardian, либо полностью асинхронный API, как в Netflix. Один из способов сделать асинхронный API — использовать систему обработки очередей, например, RabbitMQ, Apache Kafka или ActiveMQ.
Микросервисы для начинающих
Оглядываясь примерно на пять лет назад в прошлое, можно заметить, насколько сильно с тех пор изменилось отношение к архитектуре микросервисов. Поначалу они были чрезвычайно популярны. После успеха Netflix, Amazon и Gilt.com разработчики решили, что де-факто разработка микросервисов не отличается от разработки приложений. Теперь же все поняли, что микросервисы представляют из себя новый архитектурный стиль, который эффективен для решения определенных задач, имеет свои плюсы и минусы.
Чтобы понять, что такое микросервисы и в каких случаях их следует использовать, мы обратились к Джейме Буэльта (Jaime Buelta), автору книги «Hands-On Docker for Microservices with Python». Он рассказал о преимуществах этой архитектуры, а также поделился рекомендациями для разработчиков, планирующих перейти на нее с монолитов.
Преимущества и риски
Традиционное монолитное приложение объединяет все свои возможности в едином связанном модуле. В случае микросервисов все наоборот. Приложение делится на более мелкие автономные службы, которые можно независимо развертывать, обновлять и заменять. Каждый микросервис создается для одной бизнес-цели и может взаимодействовать с другими микросервисами с помощью простых механизмов.
Буэльта объясняет: «Микросервисная архитектура — это способ структурирования системы, при которой несколько независимых сервисов общаются друг с другом определенным образом (обычно это происходит с помощью web-сервисов RESTful). Ключевая особенность состоит в том, что каждый микросервис способен обновляться и развертываться независимо от остальных».
Архитектура микросервисов определяет не только то, как вы создаете свое приложение, но и то, как организована ваша команда.
«Одна независимая команда может полностью отвечать за микросервис. Это позволяет организациям расти, не сталкивая разработчиков друг с другом», — объясняет Буэльта.
Одно из основных преимуществ микросервисов заключается в том, что они позволяют внедрять нововведения без особого влияния на систему в целом. С помощью микросервисов вы можете выполнять горизонтальное масштабирование, иметь четкие границы модулей, использовать разнообразные технологии и вести параллельную разработку.
На вопрос о рисках, связанных с микросервисами, Буэльта ответил: «Главная сложность при внедрении архитектуры (особенно при переходе с монолита) заключается в создании дизайна, в котором сервисы действительно будут независимыми. Если этого не удастся добиться, то межсервисные связи станут сложнее, что приведет к дополнительным расходам. Микросервисам нужны профессионалы, которые сформируют направления развития в долгосрочной перспективе. Я рекомендую организациям, которые хотят перейти на такую архитектуру, назначить кого-то ответственным за «общую картину». На микросервисы нужно смотреть более широко», — считает Джейме.
Переход от монолита к микросервисам
Мартин Фаулер, известный автор и консультант по программному обеспечению, советует придерживаться принципа «сначала — монолит». Это связано с тем, что использовать микросервисную архитектуру с самого начала разработки рискованно, поскольку в большинстве случаев она подходит только для сложных систем и больших команд разработчиков.
«Основной критерий, который должен побуждать вас к переходу на новую архитектуру — это численность вашей команды. Небольшим группам не стоит этого делать. В подобных условиях разработчики и так понимают все, что происходит с приложением, и всегда могут задать уточняющий вопрос коллеге. Монолит отлично работает в этих ситуациях, и поэтому практически каждая система начинается с него», — считает Джейме. Это подтверждает «правило двух пицц» Amazon, согласно которому команду, ответственную за один микросервис, можно прокормить двумя пиццами — иначе она слишком большая.
«По мере роста компании и увеличения команд разработчиков может потребоваться лучшая координация. Программисты начинают часто мешать друг другу. Понять цель конкретного фрагмента кода становится сложнее. В таких случаях переход на микросервисы имеет смысл — это поможет разделить обязанности и внести ясность в общую картину системы. Каждая команда может ставить свои собственные цели и работать в основном самостоятельно, выдавая понятный внешний интерфейс. Однако, чтобы такой переход имел смысл, разработчиков должно быть много», — добавляет Буэльта.
Рекомендации по переходу на микросервисы
Отвечая на вопрос о том, какие практические рекомендации могут использовать разработчики при переходе на микросервисы, Буэльта заявил: «Ключом к успешной архитектуре микросервисов является то, что каждый сервис должен быть максимально независим».
Возникает вопрос: «Как вы можете сделать сервисы независимыми?». Лучший способ обнаружить взаимозависимость системы — подумать о новых возможностях: «Если вы хотите добавить новую функцию, можно ли будет ее реализовать, изменив лишь один сервис? Какие виды функций потребуют координации нескольких микросервисов? Они будут использоваться часто или редко? Невозможно создать идеальный дизайн, но, по крайней мере, с его помощью можно принимать правильные и обоснованные решения», — объясняет Буэльта.
Джейме советует переходить на архитектуру правильно, чтобы потом все не переделывать. «После завершения перехода изменить границы микросервисов будет тяжелее. Стоит уделить побольше времени на начальную фазу проекта», — добавляет он.
Переход с одного шаблона проектирования на другой — это серьезный шаг. Мы спросили, с какими проблемами Джейме и его команда сталкивались во время миграции на микросервисы, на что он ответил:
«На деле основные трудности связаны с людьми. Эти проблемы, как правило, недооценивают, но переход на микросервисы фактически меняет способ работы разработчиков. Задача не из легких!». Он добавляет: «Я лично сталкивался с подобными проблемами. Например, мне приходилось обучать и давать советы разработчикам. Особенно важно объяснять, почему необходимы те или иные изменения. Это помогает людям понять причины внедрения всех нововведений, которые могут прийтись им не по душе.
При переходе от монолитной архитектуры много сложностей может возникнуть при развертывании приложения, которое раньше выпускалось в виде единого модуля. Оно требует более тщательного анализа для обеспечения обратной совместимости и минимизации рисков. Справиться с этой задачей порой очень нелегко».
Причины выбора Docker, Kubernetes и Python в качестве технологического стека
Мы спросили Буэльту, какие технологии он предпочитает для внедрения микросервисов. Касательно выбора языка ответ оказался прост: «Python для меня — лучший вариант. Это мой любимый язык программирования. Этот язык хорошо подходит для микросервисов. Его удобно читать и легко применять. Кроме того, Python обладает широким функционалом для веб-разработки и динамичной экосистемой сторонних модулей для любых потребностей. К этим потребностям относится подключение к другим системам, например, к базам данных, внешним API и т.д.».
Docker часто рекламируется как один из самых важных инструментов для микросервисов. Буэльта объяснил, почему:
«Docker позволяет инкапсулировать и копировать приложение в удобных стандартизированных пакетах. Это уменьшает неопределенность и сложность среды. Также это значительно упрощает переход от разработки к производству приложений. Вдобавок ко всему, уменьшается время использования оборудования. Вы можете разместить несколько контейнеров в разных средах (даже в разных операционных системах) в одной физической коробке или виртуальной машине».
«Kubernetes позволяет развертывать несколько контейнеров Docker, работающих скоординированным образом. Это заставляет разработчиков мыслить кластеризованно, помня о производственной среде. Также это позволяет определять кластер с помощью кода, чтобы новые развертывания или изменения конфигурации определялись в файлах. Все это делает возможными методы наподобие GitOps (о них я писал в своей книге), при этом сохраняя полную конфигурацию в системе управления версиями. Каждое изменение вносится определенным и обратимым образом, поскольку оно представляет из себя регулярное git-слияние. Благодаря этому можно очень легко восстанавливать или дублировать инфраструктуру».
«Придется потратить время, чтобы обучиться Docker и Kubernetes, но это того стоит. Оба инструмента очень мощные. К тому же, они поощряют вас работать таким образом, чтобы избежать проблем при производстве», — считает Буэльта.
Многоязычные микросервисы
При разработке микросервисов можно использовать разнообразные технологии, поскольку за каждый из них в идеале отвечает независимая команда. Буэльта поделился своим мнением о многоязычных микросервисах: «Многоязычные микросервисы — это здорово! Это одно из основных преимуществ архитектуры. Типичный пример многоязычного микросервиса — перенос устаревшего кода, написанного на одном языке, на новый. Микросервис может заменить собой любой другой, который предоставляет тот же внешний интерфейс. При этом его код будет совершенно иным. К примеру, я переходил со старых приложений PHP, заменяя их аналогами, написанными на Python». Джейме добавил: «Работа с двумя или более платформами одновременно поможет лучше разобраться в них и понимать, в каких случаях их лучше использовать».
Хотя возможность использовать многоязычные микросервисы — это большое преимущество архитектуры, оно также может увеличить операционные издержки. Буэльта советует: «Надо знать меру. Нет смысла каждый раз использовать новый инструмент и лишать команды возможности делиться знаниями друг с другом. Конкретные цифры могут зависеть от размера компании, но, как правило, нет смысла использовать больше двух или трех разных языков без серьезной на то причины. Не надо раздувать стек технологий — тогда разработчики смогут делиться знаниями и начнут использовать имеющиеся инструменты наиболее эффективно».
Об авторе
Джейме Буэльта (Jaime Buelta) — профессиональный программист и Python-разработчик, который за свою многолетнюю карьеру познакомился со множеством различных технологий. Он разрабатывал программное обеспечение для различных областей и отраслей, включая аэрокосмическую, сетевую и коммуникационную, а также промышленные системы SCADA, онлайн-сервисы для видеоигр и финансовые сервисы.
В составе различных компаний он имел дело с такими функциональными областями, как маркетинг, менеджмент, продажи и геймдизайн. Джейме является ярым сторонником автоматизации и хочет, чтобы всю тяжелую работу выполняли компьютеры, позволив людям сосредоточиться на более важных вещах. В настоящее время он живет в Дублине и регулярно выступает на конференциях PyCon в Ирландии.
Простым языком о микросервисной архитектуре для начинающих
Расскажем о плюсах и минусах микросервисов, а также выясним, кому подходит технология.
Что такое микросервисная архитектура
Микросервисная архитектура — распространенный подход к разработке программного обеспечения, когда приложение разбивается на небольшие автономные компоненты (микросервисы) с четко определенными интерфейсами. Именно эта архитектура характерна для cloud-native приложений, которые сейчас популярны благодаря преимуществам, что открывают для бизнеса облачные среды.
Микросервисы vs Монолит
Прежде чем начать рассказ о микросервисах, стоит вспомнить другой тип приложений, который им чаще всего противопоставляют, — монолиты. Это приложения, построенные как единое целое, где вся логика по обработке запросов помещается внутрь одного процесса. Разумеется, монолиты могут иметь модульную структуру — содержать отдельные классы, функции, namespace (в зависимости от выбранного языка программирования). Но связи между этими модулями настолько сильны, что изменение каждого из них неизбежно отражается на работе приложения в целом.
Представьте себе кирпичную стену. Она возводится из отдельных блоков. При строительстве кирпичи еще отделимы друг от друга, но со временем, когда цемент затвердевает, они становятся неразрывно связаны. Вы можете продолжить стену в одном из направлений, но для того, чтобы коренным образом изменить ранее построенное, скорее всего, придется применить кувалду.
Рассмотрим для примера типичный интернет-магазин. Монолитное приложение для него будет использовать наверняка знакомую вам трехуровневую архитектуру, включающую:
Пример монолитной архитектуры
Мы видим, что бизнес-функции приложения очень разнообразны: работа с каталогом товаров и корзиной, обработка заказов, их оплата и отслеживание статуса, ведение пользователей и так далее. Но на уровне приложения все они объединены в один монолитный блок. При разворачивании код для различных функций находится на одном сервере. Чтобы масштабировать приложение, вам необходимо запустить несколько его экземпляров на различных физических серверах.
Недостатки такой схемы монолитной архитектуры очевидны:
Даже небольшое изменение для одной из бизнес-функций будет приводить к необходимости сборки и развертывания новой версии всего приложения.
Масштабировать приходится все приложение целиком, даже если это необходимо отдельно взятому компоненту с наименьшей производительностью. В нашем примере можно предположить, что обращения к каталогу товаров будут происходить значительно чаще оформления заказов — то есть именно для этой функции стоило бы выделить дополнительные ресурсы, но в монолите это невозможно.
Отказ одного модуля чаще всего сказывается на всей работе в целом в силу тесных связей внутри приложения.
Разработчик ограничен выбранным для приложения технологическим стеком. Хотя для ряда компонентов, возможно, было бы эффективно использовать иные технологии.
Требуется большая команда, которой тяжело управлять. При этом структура команды, вероятнее всего, будет соответствовать выбранной архитектуре: отдельные специалисты по пользовательскому интерфейсу, бизнес-логике и базе данных. И каждой из этих групп потребуется владеть экспертизой по всем бизнес-функциям, что со временем будет становиться все труднее.
Так как изменения затрагивают все приложение, увеличивается время на их отладку и проверку, что приводит к редким выходам обновлений и увеличению числа выпускаемых изменений в одном релизе, а это, в свою очередь, повышает риски.
Любое изменение в базе данных будет сказываться на всем приложении и требовать значительных изменений кода.
Для небольших и редко обновляемых приложений такая архитектура может работать прекрасно. Но по мере наращивания функциональности межмодульные связи в монолите будут неизбежно увеличиваться и усложняться, изменения в одних модулях будут все больше влиять на другие — в итоге дальнейшее развитие таких систем становится крайне затруднительным. И вот тут самое время присмотреться к микросервисам.
В отличие от монолитов, в микросервисной архитектуре приложение строится как набор небольших и слабосвязанных компонентов (микросервисов), которые можно разрабатывать, развертывать и поддерживать независимо друг от друга.
Если монолитное приложение проще всего сравнить с кирпичной кладкой, то микросервисы похожи на всем знакомый конструктор Lego. У вас есть множество деталей с четкими стандартными границами для соединения друг с другом. Вы всегда можете пересобрать получившееся изделие, заменив или убрав какие-то из элементов без ущерба для остальных.
Каждый из сервисов отвечает за конкретную бизнес-задачу, имеет собственное хранилище данных и общается с другими сервисами через простые API-интерфейсы для решения более сложных задач. Так, в нашем примере можно выделить микросервисы по ведению каталога товаров, работе с корзиной, оформлению заказов, оплате и так далее.
Пример микросервисной архитектуры
Ключевые преимущества микросервисов по сравнению с монолитами
Можно развертывать только изменяющиеся микросервисы, независимо от остальной системы, что позволяет производить обновления чаще и быстрее.
Можно расширять только те сервисы, которые в этом нуждаются, то есть сервисы с наименьшей производительностью, оставляя работать остальные части системы на менее мощном оборудовании.
Отказ одного сервиса не приводит к остановке системы в целом. Когда же ошибка исправлена, необходимое изменение можно развернуть только для соответствующего сервиса — вместо повторного развертывания всего приложения. Правда, для этого еще на этапе проектирования микросервисов потребуется тщательно продумать связи между ними для достижения максимальной независимости друг от друга, а также заложить возможность корректного оповещения пользователя о временной недоступности определенного сервиса без ущерба для всей системы.
Можно подбирать различные наборы технологий, оптимальные для решения задач, стоящих перед отдельными сервисами.
При разработке микросервисов команды принято закреплять за конкретными бизнес-задачами (и сервисами, соответственно). Такие команды, как правило, показывают большую эффективность, а управлять ими легче.
Присутствует возможность повторного использования функциональности для различных целей и различными способами.
Небольшие сервисы проще заменить на более подходящую версию или удалить вовсе — это несет значительно меньше рисков по сравнению с монолитным приложением.
Каждый микросервис, как правило, использует собственное хранилище данных — поэтому изменение модели данных в одном сервисе не влияет на работу остальных.
Недостатки микросервисной архитектуры: как с ними справиться
Несмотря на множество преимуществ, микросервисы далеко не всегда оказываются оптимальным вариантом, у них есть несколько особенностей, которые стоит учитывать при выборе архитектуры.
Распределенная система
Микросервисы по своей природе распределены, а это, как известно, имеет свои недостатки: удаленные вызовы медленнее и чаще подвержены сбоям. Если ваш микросервис обращается к десятку других микросервисов, а те, в свою очередь, вызывают еще несколько, то итоговое время отклика значительно возрастает. Также по мере увеличения взаимодействий микросервисов друг с другом возрастает и число возможных точек отказа.
Известны несколько путей решения этой проблемы:
Оба метода усложняют модель программирования и увеличивают требования к квалификации.
Усложнение процессов и повышение требований к команде
Рост числа небольших независимых сервисов неизбежно увеличивает операционную сложность. Возрастает роль непрерывной интеграции и доставки, ведь невозможно обрабатывать десятки услуг без автоматизации их тестирования и развертывания. Повышаются требования к мониторингу, особенно в силу технологической разнородности сервисов.
Чтобы справиться с возросшей нагрузкой, компании нужно овладеть целым рядом новых навыков и инструментов, и важнейший из них — внедрение культуры DevOps. Необходимо обеспечить тесное сотрудничество программистов, тестировщиков, инженеров сопровождения и прочих участников разработки продукта на всех этапах его жизненного цикла. Далеко не все организации смогут справиться с таким количеством изменений. Но культурные изменения необходимы.
Необходимость поддержания согласованности приложения
Микросервисы порождают возможные проблемы с согласованностью из-за применяемого в них децентрализованного управления данными. В монолитном приложении можно выполнить множество связанных изменений за одну транзакцию, и вы будете уверены, что в случае сбоя произойдет откат и согласованность данных сохранится.
Микросервисам же требуется несколько ресурсов для выполнения цепочки изменений, распределенные транзакции не приветствуются — поэтому может возникнуть ситуация, когда при обновлении одного компонента временно перестанет отвечать другой, ожидая завершения операции на первом.
Конечно, при разработке определенных сервисов можно отдать предпочтение не согласованности, а доступности: чтобы в случае обновления или выхода из строя одного сервиса, другие продолжали работу. Но делать это нужно крайне осторожно, чтобы бизнес-логика не принимала решений на основе противоречивой информации.
То есть разработчикам необходимо всегда помнить о проблеме конечной согласованности, находить компромисс между доступностью и согласованностью и предотвращать возможные случаи рассинхронизации данных.
Таким образом, при неоправданном использовании микросервисов многие их преимущества могут быть сведены на нет. Поэтому большинство специалистов советуют начинать с монолита, поддерживая его модульность, а к микросервисам переходить при появлении потребности в них и после проведения предварительной подготовки.