System Design

В традиционных монолитных приложениях поддерживать согласованность данных между несколькими объектами не составляет труда. Ядра реляционных баз данных предоставляют гарантии ACID (атомарность, согласованность, изоляция, долговечность), заключенные в локальные транзакции SQL. Если размещение заказа, удержание платежа или резервирование запасов завершаются неудачей на полпути, вызов ROLLBACK мгновенно отменяет все изменения в базе данных. Однако при переходе на современную архитектуру микросервисов управление данными существенно меняется. Чтобы обеспечить автономию домена и независимую масштабируемость, каждый микросервис владеет собственной базой данных. Одна бизнес-операция, такая как обработка заказа электронной коммерции, теперь охватывает несколько границ служб и механизмов баз данных (например, PostgreSQL для заказов, DynamoDB для платежей, Redis для инвентаризации).

В современной событийно-ориентированной архитектуре микросервисов (Event-Driven Architecture) сервисы постоянно генерируют события (OrderCreated, PaymentProcessed) для асинхронного взаимодействия. Главный вызов: Как гарантировать, что обновление базы данных и публикация соответствующего события либо оба завершатся успешно, либо оба откатятся? Если микросервис обновляет локальную БД (PostgreSQL, MySQL), а затем пытается отправить сообщение брокеру (Apache Kafka, RabbitMQ) по сети, сбой сети или таймаут приведет к рассогласованию данных.

В архитектуре микросервисов сервисы образуют сеть распределенных сетевых вызовов. Хотя это позволяет командам самостоятельно создавать и масштабировать сервисы, это также означает, что общая надежность вашей системы зависит от ее самого слабого звена. Если критически важная служба выходит из строя или перестает отвечать на запросы, это может вызвать каскадный сбой, который нарушит работу всего приложения. Возврат пользователям общего сообщения «500 Internal Server Error» или пустой страницы в момент сбоя одной зависимости — это плохой пользовательский опыт. Вместо этого устойчивые системы созданы для того, чтобы плавно деградировать, когда что-то идет не так.

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

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

Ожидается, что в современных облачных системах микросервисы будут делать гораздо больше, чем просто выполнять бизнес-логику. Они должны вести журналирование, управлять сертификатами SSL/TLS, собирать метрики, реализовывать механизмы повторных попыток и координировать безопасную связь с другими службами. Если мы встроим всю эту сквозную функциональность непосредственно в кодовую базу каждого приложения, мы получим раздувание кода, тесную связь и языковую привязку.

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

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

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

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