6 причин, по которым вам нужно использовать Event Sourcing в микросервисах
Микросервисы играют жизненно важную роль при переходе от монолитных приложений. Они помогают улучшить масштабируемость, управляемость, гибкость и скорость доставки приложений.
Однако при использовании микросервисов возникают некоторые проблемы, например обработка состояния. Нам, разработчикам, необходимо знать, как преодолеть эти проблемы, чтобы получить максимальную отдачу от микросервисов.
Использование источника событий — отличное решение для большинства этих проблем. Итак, в этой статье я расскажу, почему мы должны использовать источник событий с микросервисами и преимущества его использования.
Что такое источник событий
Event Sourcing — это альтернативный способ сохранения данных. По сравнению с другими методами сохранения состояния, такими как сохраняемость, ориентированная на состояние, источник событий сохраняет все мутации состояния в виде отдельной записи, называемой событием.
Например, когда покупатель кладет товары в корзину на платформе онлайн-покупок, система поиска событий сохраняет все изменения состояния в корзине в виде списка событий, изменяющих состояние. Всякий раз, когда состояние сущности изменяется, к списку событий добавляется новое событие.
1. Плавный переход от дизайна, ориентированного на предметную область
Когда дело доходит до этапа разработки проекта, разработчики и дизайнеры анализируют предметную область и проводят штурм событий/моделирование событий. Цель здесь состоит в том, чтобы идентифицировать проект с точки зрения чистого дизайна.
Тем не менее, часть разговора очень ориентирована на события. Таким образом, результатом усилий являются микросервисы, которые создадут разработчики. Поэтому команды и события попадают в эти разные микросервисы.
Источники событий находятся в стадии реализации. Во-первых, код и поток данных системы реализованы с использованием источников событий, поскольку дизайн был выполнен с учетом событий.
2. Уменьшение связи
Предположим сценарий, в котором два микросервиса слабо связаны. Если в одном микросервисе происходит изменение дизайна, реализации или поведения, это не приведет к другим изменениям.
Однако, когда дело доходит до микросервисов, связь может возникнуть. Например, если в микрослужбу внесено изменение, это приведет к тому, что все остальные микрослужбы будут прямо или косвенно сотрудничать с первой.
3. Оптимизирует узкое место производительности чтения и записи
Представьте себе типичную систему с множеством операций, которые, вероятно, создавались годами и управляются единой базой данных. Однако базу данных можно оптимизировать для чтения и записи при выполнении операций CRUD.
Но это всегда компромисс. Если вы оптимизируете для чтения, это происходит за счет записи. Если вы оптимизируете для записи, это приведет к дорогостоящему чтению. Таким образом, происходят очевидные и значительные компромиссы.
Однако источник событий решает проблему. Когда дело доходит до источников событий, используется отдельная сохраняемость. То есть у нас есть хранилище событий, которое вставляет события. Все операции CRUD становятся просто хранилищем и событиями. Все эти события объединяются в это текущее состояние операции, которое необходимо выполнить разработчикам.
Реальным преимуществом хранилища событий здесь являются расходы пользователя, а узкое место операций чтения-записи уменьшится.
4. Поднимите барьер параллелизма
Существует большая вероятность получить всплеск трафика в крупных корпоративных приложениях. Такие сценарии могут повлиять на базу данных приложения, и их решение может быть болезненным.
Да, эти вопросы можно решить, потратив три-четыре недели. Но вы все равно можете столкнуться с ситуацией, когда база данных просто доведена до предела.
Это еще одна причина, по которой поиск источников событий становится все более популярным подходом. Источники событий решают эту проблему, записывая и вставляя записи пика в журнал событий и не позволяя стороне чтения ждать.
5. Упростите и усложните обмен сообщениями
Семантику обмена сообщениями в микросервисах можно разделить на три категории.
- В большинстве случаев — случаи, когда сообщение может не быть доставлено, и вы потеряете сообщения при определенных обстоятельствах. Если подумать о микросервисе, который мы создаем, это неприемлемая функция.
- По крайней мере один раз – эту категорию проще всего внедрить. В этом случае сообщение может быть доставлено хотя бы один раз. С другой стороны, определенное сообщение может быть доставлено более двух раз.
- Ровно один раз. Достаточно мифический метод, который трудно реализовать, но все же выполнимый с точки зрения потребителя.
В некоторых случаях сообщения не доставляются с первого раза. Таким образом, решение будет реализовывать логику повторных попыток.
Когда разработчики реализуют логику повторных попыток, они должны начать думать о таких случаях, как службы-производители, пытающиеся опубликовать данные. Он должен быть в состоянии находиться в том режиме, когда некоторые сообщения не были доставлены.
Кроме того, такие дела, как обслуживание, падают. И когда эта служба возвращается, может ли она продолжить с того места, где остановилась, и продолжить повторную попытку отправки этих сообщений? Такие ситуации создают большие сложности для производителя.
Кроме того, представьте себе сценарий, в котором служба сначала выполняет транзакцию базы данных, а затем вызывает Kafka. Поскольку это две отдельные транзакции, сначала будет выполнена транзакция базы данных. Однако сообщение в Кафке не пройдет. Так что это утечка в трубе, и потребители потенциально уязвимы. Когда служба отключается в течение этого периода воздействия, сообщения будут потеряны.
При использовании источника событий разработчикам не нужно беспокоиться о неудачных сообщениях. Так что здесь сообщения не передаются потребителям Kafka. Потребители Kafka вытягивают, и реализовать этот шаблон вытягивания проще.
6. Устранение связанности сервисов
Представьте ситуацию, когда у нас есть служба поддержки клиентов, помогающая нескольким другим службам. Если обслуживание клиентов упадет, дополнительные услуги также упадут.
При использовании источника событий подход заключается в том, что клиент публикует, а другие службы потребляют. В таком случае, если служба поддержки клиентов уходит, нет никакого вреда, пока она не вернется.
Заключение
Архитектура микросервисов — одна из наиболее часто используемых архитектур в серверной разработке. Тем не менее, очень важно знать, как использовать его максимально оптимизированным и беспроблемным образом.
В этой статье я объяснил 06 причин, по которым вам следует использовать источник событий с микросервисом, чтобы избежать распространенных ошибок.
Я надеюсь, что эта статья поможет вам разрабатывать микросервисы гораздо более оптимизированным способом. Спасибо за чтение.
Бит: почувствуйте мощь компонентно-ориентированной разработки
Скажи привет Bit. Это инструмент №1 для разработки приложений на основе компонентов.
С помощью Bit вы можете создать любую часть своего приложения в виде «компонента», который можно компоновать и использовать повторно. Вы и ваша команда можете совместно использовать набор компонентов для более быстрой и последовательной совместной разработки большего количества приложений.
- Создавайте и компонуйте «строительные блоки приложения»: элементы пользовательского интерфейса, полные функции, страницы, приложения, бессерверные или микросервисы. С любым стеком JS.
- С легкостью делитесь и повторно используйте компоненты в команде.
- Быстро обновляйте компоненты в разных проектах.
- Делайте сложные вещи простыми: Монорепо, дизайн-системы и микрофронтенды.
Попробуйте Bit бесплатно и с открытым исходным кодом→
