SA: Webservices and Architecture 2

1. Что такое SOA
2. Разница между SOA и микросервисами
3. Отличие шины от брокера
4. Монолит vs Микросервисы

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

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

Основные особенности:

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

Между SOA (Service-Oriented Architecture) и микросервисной архитектурой действительно есть сходство, так как обе архитектуры предполагают разделение приложений на независимые компоненты-сервисы. Однако между ними есть важные различия:

1. Размер и сложность сервисов:
• В SOA сервисы, как правило, крупнее и могут предоставлять широкий спектр функций. Часто они объединяют в себе несколько бизнес-функций.
• Микросервисы, напротив, более узкоспециализированы и обычно выполняют одну конкретную задачу. В итоге количество микросервисов в системе, как правило, больше.
2. Управление данными:
• В SOA может быть общая база данных, к которой имеют доступ все сервисы.
• В микросервисах каждый сервис обычно управляет своими данными, что увеличивает автономность и изолирует сервисы друг от друга.
3. Технологический стек:
• В SOA сервисы чаще всего используют общую платформу или технологический стек для обеспечения интеграции.
• В микросервисах каждый сервис может быть написан на разных языках программирования и использовать различные технологии, обеспечивая большую технологическую гибкость.
4. Шина данных (ESB):
• В SOA часто используется Enterprise Service Bus (ESB) для передачи сообщений между сервисами, что делает ESB важным связующим компонентом системы.
• Микросервисы обычно взаимодействуют напрямую или через простые протоколы вроде HTTP/REST, часто используя легковесные брокеры сообщений (например, Kafka).
5. Развертывание:
• В SOA сервисы могут развертываться и обновляться вместе, в крупном пакете.
• Микросервисы проектируются так, чтобы обновляться и развертываться независимо друг от друга.

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

1. Переиспользование у SOA
2. Одна база данных у SOA
3. 90% случаев - интеграция через шину
4. Взаимодействие между сервисами сводится к обмену данными, используя брокер сообщений. Именно к обмену данными, а не вызову методов из других сервисов как в SOA

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

Пример SOA:

Пример MSA:

MSA

Допустим, у нас есть банковская система, состоящая из нескольких сервисов, таких как "Сервис Управления Аккаунтами", "Сервис Кредитования" и "Сервис Платежей".

Сценарий: Обработка Запроса на Кредит

1. Клиент Отправляет Запрос на Кредит:
• Клиент использует мобильное приложение банка для подачи заявки на кредит.
2. Сервис Кредитования Получает Запрос:
• Запрос передается в "Сервис Кредитования", который отвечает за обработку кредитных заявок.
3. Вызов Метода Сервиса Управления Аккаунтами:
• "Сервис Кредитования" делает вызов метода в "Сервис Управления Аккаунтами" для получения информации о кредитной истории и балансе клиента. Это может быть реализовано, например, через веб-сервисный вызов SOAP.
4. Сервис Управления Аккаунтами Отвечает:
• "Сервис Управления Аккаунтами" обрабатывает запрос, извлекает необходимую информацию из базы данных и отправляет ответ обратно в "Сервис Кредитования".
5. Принятие Решения о Кредите:
• "Сервис Кредитования" анализирует полученные данные и, возможно, обращается к другим сервисам (например, к "Сервису Анализа Рисков") перед принятием решения о выдаче кредита.
6. Уведомление Клиента:
• После принятия решения клиент уведомляется через мобильное приложение о результате заявки на кредит.

В этом примере ключевым моментом является взаимодействие между "Сервисом Кредитования" и "Сервисом Управления Аккаунтами" через вызов метода. Сервисы взаимодействуют друг с другом через определенные интерфейсы, что является характерной чертой архитектуры SOA.

Давайте разберем различия между корпоративной шиной (Enterprise Service Bus, ESB), используемой в архитектуре SOA, и брокером сообщений, применяемом в микросервисной архитектуре (MSA):

Корпоративная Шина (ESB) в SOA:

1. Роль: ESB действует как централизованный посредник для управления коммуникацией и интеграцией между различными сервисами в архитектуре SOA.
2. Функциональность: ESB обычно обладает более широкой функциональностью, включая маршрутизацию сообщений, преобразование форматов данных, оркестрацию процессов, обеспечение безопасности и другие возможности по управлению сервисами.
3. Сложность: В ESB может быть встроена значительная бизнес-логика, что делает ее более мощной, но также может привести к увеличению сложности и созданию бутылочного горлышка, поскольку все взаимодействия проходят через эту централизованную точку.

Брокер Сообщений в MSA:

1. Роль: Брокер сообщений служит легковесным посредником для обмена данными между микросервисами.
2. Функциональность: Главная задача брокера сообщений - эффективно пересылать сообщения между сервисами, не добавляя дополнительной бизнес-логики. Он может поддерживать такие функции, как очереди сообщений, публикация/подписка и гарантированная доставка сообщений.
3. Простота и Распределенность: В MSA брокер сообщений обычно используется для облегчения распределенного обмена сообщениями без централизации всей логики. Это помогает избежать создания бутылочного горлышка и повышает надежность системы.

Отличия:

• Централизация против Распределенности: ESB склонна к централизации и может стать узким местом, в то время как брокер сообщений в MSA распределяет нагрузку и не становится точкой концентрации всей логики и трафика.
• Сложность: ESB обычно сложнее и многофункциональнее, в то время как брокеры сообщений предназначены быть более легковесными и ограниченными в функциях.
• Логика Обработки: ESB может включать в себя сложную логику обработки и оркестрации, тогда как брокер сообщений преимущественно занимается только пересылкой сообщений.

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

Монолитная Архитектура

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

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

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

Недостатки:

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

Микросервисная Архитектура

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

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

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

Недостатки:

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

Когда Лучше Использовать

Монолит подходит для:

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

Микросервисы подходят для:

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

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