Когда речь заходит об архитектуре микросервисов, большинство людей думают о сети служб без состояния, которые обмениваются данными через HTTP (можно назвать это RESTful или нет, в зависимости от того, насколько вы придирчивы). Но есть и другой способ, который может оказаться более подходящим в зависимости от конкретного варианта использования. Я говорю о микросервисах, управляемых событиями, где в дополнение к классическому шаблону запроса-ответа службы публикуют сообщения, которые представляют события (факты) и подписываются на темы (или очереди в зависимости от используемой терминологии) для получения событий/сообщений. Полностью понять и принять эту новую парадигму разработки программного обеспечения непросто но это того стоит (по крайней мере, изучить его). Существует несколько взаимосвязанных концепций, которые необходимо изучить, чтобы выявить преимущества событийно-ориентированного проектирования и эволюционный путь, который привел к нему, например:
- Журнал (включая механизм хранения данных со структурой журналов и журнал предварительной записи)
- Материализованный Вид
- Источник событий
- Разделение ответственности за командный запрос (CQRS)
- Потоковая обработка
- ” наизнанку ” базы данных (также известные как ” разделенные
Я хотел бы указать вам на следующие книги, чтобы ознакомиться с этими темами:
- Проектирование приложений с интенсивным использованием данных Мартин Клеппманн – это очень всеобъемлющая книга, в ней сначала рассматриваются концепции приложений с одним узлом, затем распределенные системы и, наконец, пакетная и потоковая обработка.
- Проектирование систем, управляемых событиями Бен Стопфорд – в нем основное внимание уделяется Apache Kafka как основе систем, управляемых событиями.
- Кафка: Окончательное руководство Неха Нархеде, Гвен Шапира и др. – более практичная книга, чем две другие.
Я прочитал эти три книги, а затем начал создавать простой PoC, так как изучение новых дизайнерских идей – это здорово но это не будет завершено до тех пор, пока вы также не примените их на практике. Кроме того, я не был доволен примерами приложений/сервисов, управляемых событиями, доступных онлайн, я нашел их слишком упрощенными и неправильно объясненными, поэтому я решил создать один из них.
Доказательство концепции
Исходный код разделен на два репозитория GitHub (в соответствии с Чистой архитектурой ):
- transfers_api → содержит объекты Java и файлы определения данных Avro
- transfers_recording_service → содержит бизнес-логику и код, связанный с Kafka
Служба подтверждения концепции отслеживает баланс, доступный на банковских счетах (например, в бухгалтерской книге). Он прослушивает Transfer сообщения в теме Kafka и при получении одного из них обновляет баланс соответствующей учетной записи, публикуя новое accountBalance сообщение в другой теме Kafka.
Пожалуйста, обратите внимание, что каждый тип сущности представлен двумя разными классами:
- один из них генерируется Apache Avro и используется для сериализации и десериализации (чтобы их можно было отправлять и получать из Kafka) → см. avro каталог.
- другой – POJO, который может содержать некоторые удобные конструкторы и не зависит от Avro = см. net.dev action.entity package.
Пакет net.deviation.kafka.avro.util содержит преобразователи для перехода от одного представления данных к другому и обратно. Вначале Apache Kafka может показаться ошеломляющим, хотя он напоминает классический брокер обмена сообщениями, такой как ActiveMQ или RabbitMQ, это гораздо больше, чем это, и внутри он работает совсем по-другому. Кроме того, существует несколько клиентских API-интерфейсов Kafka, что еще больше запутывает учащегося. Мы собираемся сосредоточиться на следующих трех:
- API-интерфейс производителя и Потребительский API
- API-интерфейс Streams
API-интерфейсы производителя и потребителя находятся на более низком уровне, а API Streams построен поверх них. Оба набора API имеют свои преимущества и недостатки. API производителя/потребителя обеспечивает более точный контроль разработчику приложения за счет более высокой сложности. С другой стороны, Streams API не такой гибкий, но он позволяет легче выполнять некоторые стандартные операции и требует гораздо меньше кода.
Пример|PoC службы ” transfers recording |/” может быть запущен в одном из следующих двух режимов:
- (Явный) режим опроса , который использует API производителя, API потребителя, а также API потоков (для создания материализованного представления с возможностью запроса, поддерживаемого локальным хранилищем данных, подробнее об этом позже) → посмотреть TransfersRecordingServicePolling.java
- Режим ” присоединиться к потокам “, который использует только Streams API → см. Режим “
Эти два режима обеспечивают совершенно одинаковую функциональность, что весьма удобно для целей сравнения.
(Явный) режим опроса
Он состоит из четырех основных компонентов:
- /| Потребитель , который слушает тему “переводы” → см. TransferConsumer.java A
- Хранилище значений ключей только для чтения (который является частью Streams API) для материализации данных раздела “балансы учетных записей” в доступном для запроса представлении, чтобы мы могли использовать значение AccountId для получения последнего/текущего баланса конкретной учетной записи → см. AccountBalanceRetrieverImpl.java . Пожалуйста, обратите внимание, что значение AccountId извлекается из сообщения данных “ transfer “, полученного потребителем. Бизнес-логика, которая создает новую/обновленную
- Сущность баланса счета объект из полученной Сущности передачи объекта и текущего AccountBalanceEntity , присутствующего в Kafka → см. NewAccountBalanceProvider.java /| Производитель
- , который публикует обновленный баланс, отправив сообщение в раздел ” балансы счетов ” →, и локальное хранилище данных будет обновлено соответствующим образом.
Режим “присоединиться к потокам”
Как мы уже говорили ранее, этот второй режим работы использует только Streams API/DSL, и, используя его преимущества, мы можем кодировать на более высоком уровне абстракции:
- Вместо/| consumer мы используем Stream → см. Вместо/| consumer мы используем
- Stream → см. Вместо/| Хранилище значений ключей только для чтения , мы используем KTable → см. TransfersRecordingServiceJoinStreams.java
- снова. Бизнес-логика остается прежней но теперь мы вызываем его из ValueJoiner → посмотреть
- → посмотреть Вместо/| producer мы перенаправляем вывод соединения потоков в нужную тему (т.е. “балансы счетов”). → посмотреть
Мы видим, что код намного компактнее, чем в предыдущем режиме. Нам не нужно явно сопоставлять ключ KStream с ключом KTable
Диаграмма
Схема приложения example/PoC Kafka Streams
Запуск кода
Для создания и запуска приложения PoC, в дополнение к Maven и Java, нам также нужен брокер Kafka. Я решил установить платформу Confluent , которая включает в себя брокер Kafka (или кластер в зависимости от выбранной конфигурации) с некоторыми примерами тем и предварительно настроенной интеграцией с ElasticSearch и Kibana. Но что еще более важно, он также включает в себя веб-интерфейс администратора с именем Control Center что очень удобно.
Я столкнулся с несколькими проблемами при первом запуске платформы Confluent на моем компьютере Fedora 30. А именно, мне пришлось вручную установить пару программных пакетов (т.Е. ” jot ” и ” jq “). И мне пришлось отдельно установить Confluent CLI . Мне также пришлось внести несколько изменений в некоторые файлы свойств и сценарии bash, чтобы иметь возможность запускать платформу Confluent с использованием пользователя, не являющегося root, здесь приведены изменения, пожалуйста, измените значения конфигурации в соответствии с вашей средой.
Смотрите следующее Видео на YouTube чтобы получить все подробности, включая запуск платформы Confluent и запуск приложения example Streams:
Оригинал: “https://dev.to/victorgil/using-apache-kafka-to-implement-event-driven-microservices-af2”