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

В предыдущем посте мы обсуждали, как можно использовать BPM с открытым исходным кодом с машинным обучением в архитектуре реактивных микросервисов. Он предоставил базовый обзор машинного обучения, Kafka, H20 и объяснил подход, который полезен, когда у вас есть человеческий рабочий процесс.

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

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

Понимание проблемы

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

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

Варианты интеграции реактивных микросервисов и систем

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

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

Использование Kafka внутри в реактивной системе может быть хорошим решением:

  • Если микросервисы в вашей реактивной системе являются многоязычными по своей природе, что означает сочетание технологий (например, Spring Boot, Java, Akka).
  • Если желательно избежать привязки к определенной реактивной структуре для общения.

Kafka также можно использовать для интеграции между реактивными системами.

Использование Kafka в реактивных системах может оказаться хорошим решением:

  • Если ваши реактивные системы по своей природе многоязычны (Akka Actor Systems, Java).
  • Если желательно избежать привязки к определенной реактивной структуре для перекрестной реактивной системной коммуникации.

Вы также можете использовать возможности Akka для достижения аналогичных результатов. Akka позволяет вам создать систему актеров, которая может содержать несколько актеров. Для связи внутри реактивной системы субъекты могут общаться друг с другом через встроенные в Akka возможности обмена сообщениями (например, спрашивать, сообщать или публиковать / подписываться через конструкцию EventStream).

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

Для обмена данными между системами Akka можно использовать Akka HTTP или Akka gRPC для синхронной неблокирующей связи, а Akka Streams Kafka - для асинхронной связи. Каждый из этих подходов обеспечивает противодавление как часть потоковой передачи сообщений. Кроме того, другой конец связи может быть реализован не в Akka.

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

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

Пример реализации

Давайте рассмотрим пример того, как вы можете использовать инфраструктуру Akka, Lagom, H20, Kafka и микросервисы на основе Java для реализации решения на основе машинного обучения, использующего реактивную микросервисную архитектуру. Вы также можете найти презентацию и видео по этой теме, которые я представил со своими коллегами на конференции Reactive Summit 2018 ниже.

Интеграция машинного обучения, реактивных микросервисов и Akka с Kafka - @reactivesummit Reactive18 - Многие компании экспериментируют с машинным обучением, чтобы увидеть, как они могут лучше предсказывать будущее… www. reactivesummit.org

В этом примере мы создаем решение для прогнозирования мошеннической транзакции по кредитной карте. 28 числовых характеристик рассчитываются и вводятся в модель H20, которая выполняет прогноз. В моем предыдущем посте мы представили обзор Akka, H20 и Kafka. Новая технологическая составляющая, о которой мы раньше не говорили, - Лагом. Lagom - это фреймворк с открытым исходным кодом, который упрощает соединение микросервисов вместе (например, он может предоставлять Akka Actors как RESTful API). В нашем примере мы используем его, чтобы обеспечить загрузочный ремень для Kafka. Теперь давайте посмотрим на предлагаемую архитектуру, использующую все эти компоненты. Мы повторно используем ряд тех же компонентов из примера BPM с открытым исходным кодом, пожалуйста, посмотрите этот пост для подробного изучения компонента H20.

Вышеупомянутое решение использует как команды, так и события. Вы увидите систему Akka с участниками Akka, которые используют встроенный обмен сообщениями Akka (спросить / сообщить), а также опубликовать и подписаться на Kafka для взаимодействия с микросервисами на основе Java. Ключевые микросервисы этого решения включают:

  • Kafka Producer (не показан выше) - микросервис на основе Java, используемый для имитации системного потока путем размещения команды «Calc Features» в теме card.transaction Kafka.
  • Saga Actor - актер Akka на основе Java, который подписывается на тему card.transaction на Kafka. Реагирует на событие «Features Calculated» и отправляет команду через «ask» в RunModelMS Actor, используя встроенную возможность обмена сообщениями Akka, передавая 28 входных данных модели.
  • CalcFeaturesMS - микросервис на основе Java, который подписывается на тему card.transaction в Kafka. Реагирует на команду «Расчет характеристик», вычисляя 28 числовых характеристик и публикуя их обратно в тему Kafka с событием «Рассчитанные характеристики».
  • RunModelMS - основанный на Java Akka Actor, который является оболочкой для кода модели H20 на основе Java. Получает команду от актера саги запустить модель H20. Запускает модель и публикует выходные данные с событием «Транзакция ОК» или «Мошенническая транзакция» в теме Kafka card.transaction.

Общий поток можно визуализировать на диаграмме ниже.

Теперь давайте подробнее рассмотрим новые фрагменты кода в этом примере. Функциональность Kafka Producer реализуется классом TestKafkaProducer, который расширяет класс ProducerExample. ProducerExample создает систему акторов, которая подключается к локальному экземпляру Kafka. TestKafkaProducer передает команду «Calc Features» в теме card.transaction Kafka.

Наш Актер саги реализован посредством серии из четырех отдельных компонентов. Первый - application.conf, который находится в корне пути к классам и используется для передачи информации о конфигурации для Akka экземпляру ActorSystem. Наш файл application.conf указывает на Saga Actor, который мы называем CorrespondenceModule.

play.modules.enabled + = com.capitalone.acc.impl.CorrespondenceModule

CorrespondenceModule.java - это место, где происходит привязка с Kafka вместе с классом реализации службы:

Класс реализации службы создает экземпляр Saga Actor и StartEventCmd.

StartEventCmd в Saga Actor получает сообщение и отправляет сообщение Tell в RunModelMS (в этом случае называется ProcessAppActor).

RunModelMS (известная в коде как ProcessAppActor) проверяет сообщение, чтобы узнать, были ли рассчитаны функции.

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

Обработка сбоев

На этом этапе у вас может возникнуть вопрос: как я могу справляться с отказами в такой распределенной архитектуре? Есть несколько подходов, которые можно использовать на уровне приложения. Давайте рассмотрим несколько ниже.

  • Используйте блоки try / catch для перехвата исключений. Обратите внимание, что мы сделали это при выполнении модели H20, описанной выше.
  • Сделайте свой процессинг идемпотентным. Это означает, что проектируйте свою обработку так, чтобы ей не нужно было запоминать, где возникла ошибка, скорее, вы можете начать все сначала и обработать заново. Этот подход может быть отличным способом упростить ваш дизайн, но не всегда может быть возможным в зависимости от варианта использования.
  • Используйте группы потребителей Kafka и фиксируйте смещение только в том случае, если вы знаете, что обработка прошла успешно. С группами потребителей Kafka Zookeeper отслеживает смещение, которое является текущей точкой в ​​потоке сообщений, которую нужно использовать. Потребители могут управлять фиксацией смещения или автоматической фиксацией после прочтения сообщения. Контролируя, когда фиксировать смещение, потребитель может дождаться наступления определенного условия успеха. Если процесс потребителя упал, а сообщения продолжали формироваться в Kafka, когда потребитель вернется к работе, он сможет обработать любые незафиксированные сообщения.
  • Используйте Akka Persistence, поскольку это обеспечивает отказоустойчивость за счет сохранения внутреннего состояния актера. Это позволяет восстановить состояние актера в случае его сбоя. Вы можете найти более подробную информацию об этом в моем предыдущем сообщении в блоге.

Резюме

Объединение возможностей Akka, Lagom, H20 и Kafka в реактивной микросервисной архитектуре может вывести ваши сценарии использования машинного обучения на новый уровень. Он обеспечивает способ разделения ваших внутренних компонентов, обеспечивая асинхронную обработку, а также поддерживает интеграцию с различными реактивными системами полиглотов через возможности публикации и подписки. Этот шаблон хорошо подходит для взаимодействия системного типа (нечеловеческий рабочий процесс). Я надеюсь, что этот пост окажется для вас полезным, и спасибо за ваше время!

РАСКРЫТИЕ ИНФОРМАЦИИ: это мнение автора. Если в этом посте не указано иное, Capital One не является аффилированным лицом и не поддерживается ни одной из упомянутых компаний. Все используемые или отображаемые товарные знаки и другая интеллектуальная собственность являются собственностью соответствующих владельцев. Эта статья принадлежит © 2019 Capital One.

Связанный:

РАСКРЫТИЕ ИНФОРМАЦИИ: © 2019 Capital One. Мнения принадлежат отдельному автору. Если в этом посте не указано иное, Capital One не является аффилированным лицом и не поддерживается ни одной из упомянутых компаний. Все используемые или отображаемые товарные знаки и другая интеллектуальная собственность являются собственностью соответствующих владельцев.