Когда реактивные микросервисы встречаются с микросервисами

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

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

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

Монолиты

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

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

Характеристики монолитов

Развертывается как единое целое
Единая общая база данных
Общение с помощью синхронных вызовов методов
Глубокая связь между библиотеками и компонентами
Длительное время цикла (от нескольких недель до нескольких месяцев)
Команды должны тщательно синхронизировать функции и релизы

Плюсы монолитов

Легкий кросс-модульный рефакторинг
Легче поддерживать согласованность
Единый процесс развертывания
Единый процесс мониторинга
Простая модель масштабируемости

Минусы монолитов

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

Сервис-ориентированная архитектура (SOA)

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

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

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

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

Плюсы SOA

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

Минусы SOA

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

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

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

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

Характеристики микросервисов

Подмножество сервис-ориентированной архитектуры (SOA).
Несколько независимых баз данных.
Связь может быть синхронной или асинхронной
Свободное соединение между компонентами
Быстрое развертывание

Плюсы микросервисов

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

Минусы микросервисов

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

Реактивные микросервисы

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

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

Заключение

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

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