Проектирование систем: Монолиты и микросервисы


Монолиты

Монолит — это самодостаточное и независимое приложение. Оно создается как единое целое и отвечает не только за конкретную задачу, но и может выполнять все действия, необходимые для удовлетворения бизнес-потребностей.

Преимущества

Ниже перечислены некоторые преимущества монолитов:

  • Простота разработки и отладки.
  • Быстрая и надежная связь.
  • Легкий мониторинг и тестирование.
  • Поддерживает транзакции ACID.

Недостатки

К общим недостаткам монолитов относятся:

  • Сопровождение становится трудным по мере роста кодовой базы.
  • Жестко связанное приложение, трудно расширяемое.
  • Требуется приверженность определенному технологическому стеку.
  • При каждом обновлении все приложение развертывается заново.
  • Сниженная надежность, поскольку одна ошибка может вывести из строя всю систему.
  • Сложно масштабировать или внедрять новые технологии.

Модульные монолиты

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

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

Микросервисы

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

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

Сервисы отвечают за сохранение своих собственных данных или внешнего состояния (база данных для каждого сервиса). Это отличается от традиционной модели, в которой за сохранение данных отвечает отдельный слой данных.

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

Архитектурный стиль микросервисов имеет следующие характеристики:

  • Свободная связь: Сервисы должны быть слабо связаны друг с другом, чтобы их можно было независимо развертывать и масштабировать. Это приведет к децентрализации команд разработчиков и, таким образом, позволит им быстрее разрабатывать и внедрять с минимальными ограничениями и операционными зависимостями.
  • Небольшой, но целенаправленный: Речь идет о масштабе и ответственности, а не о размере, услуга должна быть сфокусирована на конкретной проблеме. По сути, «он делает одно дело и делает его хорошо». В идеале, они могут быть независимы от базовой архитектуры.
  • Созданы для бизнеса: Архитектура микросервисов обычно строится вокруг возможностей и приоритетов бизнеса.
  • Устойчивость и отказоустойчивость: Сервисы должны быть спроектированы таким образом, чтобы они продолжали функционировать в случае сбоев или ошибок. В средах с независимо развертываемыми сервисами отказоустойчивость имеет первостепенное значение.
  • Высокая ремонтопригодность: Сервис должен быть легко обслуживаемым и тестируемым, поскольку сервисы, которые невозможно обслуживать, будут переписаны.

Преимущества

Вот некоторые преимущества архитектуры микросервисов:

  • Свободно связанные сервисы.
  • Сервисы могут быть развернуты независимо друг от друга.
  • Высокая гибкость для нескольких команд разработчиков.
  • Повышение отказоустойчивости и изоляции данных.
  • Лучшая масштабируемость, поскольку каждый сервис может быть масштабирован независимо.
  • Исключает любые долгосрочные обязательства в отношении определенного технологического стека.

Недостатки

Архитектура микросервисов несет в себе целый ряд проблем:

  • Сложность распределенной системы.
  • Более сложное тестирование.
  • Дорогостоящее обслуживание (отдельные серверы, базы данных и т.д.).
  • Межсервисное взаимодействие имеет свои проблемы.
  • Целостность и непротиворечивость данных.
  • Перегруженность сети и задержки.

Лучшие практики

Давайте обсудим некоторые лучшие практики микросервисов:

  • Моделируйте сервисы вокруг бизнес-домена.
  • Сервисы должны иметь свободную связь и высокую функциональную согласованность.
  • Изолируйте отказы и используйте стратегии отказоустойчивости для предотвращения каскадного распространения отказов внутри сервиса.
  • Сервисы должны взаимодействовать только через хорошо спроектированные API. Избегайте утечки деталей реализации.
  • Хранение данных должно быть закрытым для сервиса, которому принадлежат данные.
  • Избегайте сцепления между сервисами. Причинами сцепления являются общие схемы баз данных и жесткие протоколы связи.
  • Децентрализуйте все. Отдельные команды отвечают за проектирование и создание сервисов. Избегайте совместного использования кода или схем данных.
  • Отказывайте быстро, используя автоматический выключатель для достижения отказоустойчивости.
  • Обеспечьте обратную совместимость изменений API.

Подводные камни

Ниже перечислены некоторые распространенные подводные камни архитектуры микросервисов:

  • Границы сервисов не основаны на бизнес-сфере.
  • Недооценка того, насколько сложно построить распределенную систему.
  • Общая база данных или общие зависимости между службами.
  • Отсутствие согласованности действий.
  • Отсутствие четкой ответственности.
  • Отсутствие идемпотентности.
  • Попытка сделать все ACID вместо BASE.
  • Отсутствие проектирования для обеспечения отказоустойчивости может привести к каскадным отказам.

Остерегайтесь распределенного монолита

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

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

  • Требуются коммуникации с низкой задержкой.
  • Сервисы нелегко масштабируются.
  • Зависимость между сервисами.
  • Совместное использование одних и тех же ресурсов, таких как базы данных.
  • Жестко связанные системы.

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

Микросервисы против сервис-ориентированной архитектуры (SOA)

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

Сервис-ориентированная архитектура (SOA) определяет способ сделать программные компоненты многократно используемыми с помощью интерфейсов сервисов. Эти интерфейсы используют общие стандарты связи и нацелены на максимальное повторное использование сервисов приложения, в то время как микросервисы строятся как набор различных мелких независимых сервисных единиц, ориентированных на автономность команды и развязку.

Почему вам не нужны микросервисы

Итак, вы, возможно, задаетесь вопросом, монолиты кажутся плохой идеей, почему кто-то должен использовать это?

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

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

  • «Не слишком ли велика команда, чтобы эффективно работать над общей кодовой базой?».
  • «Блокируются ли команды другими командами?»
  • «Обеспечивают ли микросервисы явную бизнес-ценность для нас?».
  • «Является ли мой бизнес достаточно зрелым для использования микросервисов?».
  • «Ограничивает ли нас наша текущая архитектура коммуникационными накладными расходами?».

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

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

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


Эта статья является частью моего открытого курса по проектированию систем, доступного на Github.

karanpratapsingh / system-design

Узнайте, как проектировать системы в масштабе и подготовиться к собеседованиям по проектированию систем

Курс по проектированию систем

Привет, добро пожаловать на курс. Я надеюсь, что этот курс обеспечит вам отличный опыт обучения.

Оглавление

  • Начало

    • Что такое проектирование систем?
  • Глава I

    • IP
    • Модель OSI
    • TCP и UDP
    • Система доменных имен (DNS)
    • Балансировка нагрузки
    • Кластеризация
    • Кэширование
    • Сеть доставки контента (CDN)
    • Прокси
    • Доступность
    • Масштабируемость
    • Хранение
  • Глава II

    • Базы данных и СУБД
    • Базы данных SQL
    • Базы данных NoSQL
    • Базы данных SQL против баз данных NoSQL
    • Репликация баз данных
    • Индексы
    • Нормализация и денормализация
    • Модели согласованности ACID и BASE
    • Теорема CAP
    • Теорема PACELC
    • Транзакции
    • Распределенные транзакции
    • Шардинг
    • Последовательное хэширование
    • Федерация баз данных
  • Глава III

    • N-уровневая архитектура
    • Брокеры сообщений
    • Очереди сообщений
    • Publish-Subscribe
    • Корпоративная сервисная шина (ESB)
    • Монолиты и микросервисы
    • Архитектура, управляемая событиями (EDA)
    • Сорсинг событий
    • Разделение ответственности команд и запросов (CQRS)
    • API-шлюз
    • REST, GraphQL, gRPC
    • Длительный опрос, WebSockets, события, отправляемые сервером (SSE)
  • Глава IV

    • Геохашинг и квадтрики
    • Прерыватель цепи
Посмотреть на GitHub

Оцените статью
devanswers.ru
Добавить комментарий