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

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

1. Шаблон шлюза API

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

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

✓ Централизованное управление обработкой запросов/ответов.

✓ Упрощает взаимодействие на стороне клиента за счет абстрагирования внутренней сложности микросервиса.

✓ Упрощает реализацию безопасности, кэширования и регулирования.

Пример:

Использование Express.js в Node.js для создания базового шлюза API:

import express from 'express';
import proxy from 'express-http-proxy';

const app = express();

// Forward requests to microservice A
app.use('/serviceA', proxy('http://serviceA-url'));

// Forward requests to microservice B
app.use('/serviceB', proxy('http://serviceB-url'));

app.listen(3000, () => {
  console.log('API Gateway running on port 3000');
});

2. Схема автоматического выключателя

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

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

✓ Защищает от общесистемных сбоев.

✓ Обеспечивает запасной вариант или альтернативные меры реагирования в случае сбоев.

✓ Повышает надежность микросервисной архитектуры.

Пример:

Использование библиотеки опоссума в Node.js для автоматического выключателя:

import CircuitBreaker from 'opossum';
import axios from 'axios';

const options = {
  timeout: 5000,
  errorThresholdPercentage: 50,
  resetTimeout: 30000,
};

const circuitBreaker = new CircuitBreaker(() => axios.get('http://serviceB-url'), options);

circuitBreaker.fire()
  .then(response => console.log(response.data))
  .catch(err => console.log('Service B is down. Circuit is open.'));

3. База данных по шаблону службы

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

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

✓ Уменьшает зависимость и конфликты между сервисами.

✓ Облегчает независимое масштабирование и эволюцию схемы.

✓ Изолирует владение данными и ответственность.

4. Узор «Сага»

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

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

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

✓ Поддерживает конечную согласованность между микросервисами.

✓ При необходимости включает откат незавершенных операций.

Пример:

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

5. Шаблон источника событий

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

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

✓ Обеспечивает четкий контроль всех изменений.

✓ Позволяет проводить исторический анализ, воспроизводя прошлые события.

✓ Облегчает восстановление состояния при необходимости.

Пример:

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

6. Шаблон CQRS (разделение ответственности за командный запрос)

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

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

✓ Оптимизирует производительность за счет разделения задач чтения и записи.

✓ Поддерживает различные стратегии масштабирования для чтения и записи.

✓ Позволяет создавать гибкие модели, адаптированные к конкретным задачам.

7. Узор из инжира-душителя

Шаблон Strangler Fig — это стратегия постепенной миграции, которая позволяет выполнять рефакторинг или заменять части монолита микросервисами. По мере добавления новых функций они создаются как микросервис. Со временем монолит заменяется сервис за сервисом, не нарушая работу всей системы сразу.

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

✓ Обеспечивает непрерывный путь перехода от монолитов к микросервисам.

✓ Снижает риск полной перезаписи системы.

✓ Обеспечивает постепенное улучшение и рефакторинг.

Пример:

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

Заключение

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