Монолитные и микросервисные архитектуры

Завершено

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

Что такое монолитная архитектура?

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

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

Все службы содержатся в одном модуле. Это соглашение приводит к проблемам, так как их бизнес, а также последующие системные нагрузки, растет. Ниже приведены некоторые из следующих проблем:

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

Эти проблемы можно решить, взглянув на альтернативные архитектуры, такие как архитектура микрослужб.

Что такое архитектура микрослужб?

Архитектура микрослужб состоит из служб, которые являются небольшими, независимыми и слабо связаны. Каждая служба может быть развернута и масштабирована независимо.

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

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

Так как каждая служба является независимой, они могут использовать различные стеки технологий, платформы и пакеты SDK. Обычно службы используют вызовы REST для обмена данными между службами с помощью хорошо определенных API вместо удаленных вызовов процедур (RPCs) или других пользовательских методов связи.

Архитектуры микрослужб являются независимыми от технологий, но часто используются контейнеры или бессерверные технологии для их реализации. Непрерывное развертывание и непрерывная интеграция (CI/CD) часто используются для повышения скорости и качества действий разработки.

Преимущества архитектуры микрослужб

Почему вы выбрали архитектуру микрослужб? Существует несколько основных преимуществ архитектуры микрослужб:

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

Подвижность

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

Небольшой код, небольшие команды

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

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

Сочетание технологий

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

Упругость

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

Масштабируемость

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

Изоляция данных

Архитектура микрослужб повышает способность выполнять обновления схемы данных, так как затрагивается только одна микрослужба. В монолитном приложении обновления схемы могут стать сложными. Различные части приложения могут касаться одинаковых данных, что делает любые изменения схемы рискованными. С помощью архитектуры микрослужб можно обновить схему, но сохранить поверхность API нетронутой. Затем потребители служб имеют тот же интерфейс независимо от базовой архитектуры данных.

Потенциальные проблемы архитектуры микрослужб

Существует множество преимуществ архитектуры микросервисов, но это не универсальное решение. Архитектура микрослужб имеет собственный набор проблем:

• Сложность
• Разработка и тестирование
• Отсутствие управления
• Перегрузка сети и задержка
• Целостность данных
• Управление
• Управление версиями
• Набор навыков

Сложность

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

Разработка и тестирование

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

Отсутствие управления

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

Перегрузка сети и задержка

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

Целостность данных

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

Управление

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

Управление версиями

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

Набор навыков

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

Когда следует выбрать архитектуру микрослужб?

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

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