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

При проектировании архитектуры микросервисов нам необходимо соблюдать определенный процесс. Мы не должны забывать, что проектирование архитектуры микросервисов должно быть методичным. Худшее, что может случиться при проектировании архитектуры микросервисов, – это броситься в разработку. Это должно быть похоже на «Планируйте больше, кодируйте меньше».

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

И, конечно, чем меньше мы кодируем, тем меньше ошибок мы создаем и тем меньше у нас обслуживания.

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

1. Сопоставьте компоненты
2. Определите шаблон общения
3. Выбрать стек технологий
4. Дизайн архитектуры

Сопоставление компонентов

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

Что это?

На этом этапе мы определяем различные компоненты системы. Другими словами, мы сопоставляем различные части системы, которые, работая вместе, составляют всю систему.

Когда мы говорим о компонентах в архитектуре микросервисов, мы в основном говорим о сервисах.

Как мы решаем, какие у нас компоненты?

Отображение компонентов должно основываться на нескольких факторах:

1. Бизнес-требования.
2. Функциональная автономия.
3. Сущности данных.
4. Автономность данных.

Бизнес-требования

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

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

Функциональная автономия

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

Объекты данных

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

Автономность данных

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

Это демонстрируется атрибутом микросервисов «Организовано вокруг бизнес-возможностей».

Для небольшого примера возьмем изображение ниже.

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

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

Мы можем думать о трех способах,

Дублирование данных

Запрос на обслуживание

Служба агрегации

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

Определение шаблонов общения

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

Есть 3 основных шаблона,

1. 1-к-1 синхронизация
2. 1-к-1 асинхронный
3. Pub-Sub или Event Driven

1-к-1 синхронизация

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

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

Плюсы

1. Немедленный ответ
2. Обработка ошибок проста
3. Легко реализовать

Минусы

1. Производительность может быть проблемой

1-к-1 асинхронный

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

Плюсы

1. Производительность хорошая

Минусы

1. Требуется дополнительная настройка (большую часть времени необходимо использовать очередь)
2. Обработка ошибок сложна

Pub-Sub / Event Driven

В этом шаблоне служба хочет уведомить о чем-то другие службы. Обратите внимание на множественное число «Услуги». Сервис не знает, сколько сервисов слушает. В асинхронном режиме «1 к 1» служба обычно направляет сообщение определенной службе, даже если у нее нет прямых контактов с ней. С помощью pub-sub или опубликовано / подписано, служба публикует сообщение, и другие службы, которые подписываются на этот тип сообщения, будут получать. Это то же самое, что и асинхронный режим 1-к-1, и он будет реализован в шаблоне «выстрелил и забыл».

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

Плюсы

1. Хорошее исполнение
2. Уведомлять сразу несколько служб

Минусы

1. Требуется дополнительная настройка (требуется использовать очередь)
2. Обработка ошибок сложна
3. Может вызвать нагрузку на систему (в зависимости от количества сообщений в очереди)

Выбор стека технологий

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

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

Вот краткий обзор платформ Back-end разработки, которые мы обычно используем.

Хранилище данных

Есть 4 хранилища данных. Я не буду останавливаться на фактах выбора хранилища данных, это должно быть обсуждено в отдельной статье. Четыре типа:

1. Реляционная база данных (MySQL, PostgreSQL, MS SQL Server)
2. База данных NoSQL (MongoDB, Couchbase, Amazon Dynamodb)
3. Кеш (Redis)
4. Магазин объектов (Amazon S3, блог Azure, MiniO)

Дизайн Архитектуры

Это не будет сильно отличаться от обычного архитектурного процесса программного обеспечения. Идеи и постижения / практики такие же.

Слои

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

UI / SI (Сервисный интерфейс)

1. Разоблачить API
2. Обработка JSON (или другого формата)
3. Auth

Бизнес-логика (BL)

1. Проверка
2. Обогащение
3. Расчеты

Уровень доступа к данным (DAL)

1. Обработка соединения
2. Запрос / сохранение данных
3. Обработка транзакций

Заключение

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

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

Перевод