Эволюция среды обработки данных Spring

Микросервисы Архитектура Spring Facebook

Приветствую всех вОблако Tencent + сообщество, получить больше крупной технической практики Tencent по галантерее~

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

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

  • пакетная обработка: Пакетная обработка больших объемов статических данных. Этот подход обычно является распределенным и масштабируемым.
  • обработка в реальном времени: Обработка в реальном времени в основном имеет дело с непрерывными и бесконечными потоками данных. Эти потоки данных также распределены и быстры.
  • Гибридная вычислительная модель: Модель представляет собой комбинацию пакетной обработки и обработки в реальном времени, которая может обрабатывать большие объемы и высокоскоростные данные.

Разработка проектов больших данных требует много времени и требует необходимых навыков для решения проблем сбора и обработки данных, которые необходимы для большинства сценариев. Pivotal представила Spring XD и Spring Cloud Dataflow, чтобы сократить накладные расходы на проектирование больших данных. В этой статье будет кратко представлен Spring XD, а также подробно представлена ​​последняя версия технологии Spring Cloud Data Flow.

Spring XD

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

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

Архитектура Spring XD широко используется в традиционном ETL на уровне предприятия (процесс извлечения, преобразования и загрузки данных), анализе в реальном времени и создании рабочих мест для проектов по науке о данных.

Архитектура на основе Spring XD

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

Основными компонентами Spring XD являются Admin и Container.

  1. Пользовательский интерфейс администратора используется для отправки запроса на сервер для выполнения задачи, а затем сервер вызывает связанный модуль для выполнения запрошенной задачи. Здесь модуль — это один из компонентов, который создает контекст приложения Spring.
  2. Всем модулям требуется контейнер XD для запуска и выполнения связанных задач, выполняемых модулем.

Ниже приведены некоторые ключевые модули в архитектуре Spring XD.

  • Источник данных (Источник): Создание потока данных всегда начинается с создания модуля источника данных. Источник данных может получать данные с помощью механизма опроса или механизма, управляемого событиями, а затем предоставлять только вывод данных.
  • Обработчик данных (процессор): Он принимает входные сообщения и после некоторой обработки создает выходные сообщения.
  • Приемник данных (Sink): Как следует из названия, этот модуль является конечной точкой потока данных. Он отправит выходные данные на внешний ресурс, такой как HDFS.
  • Работа: этот модуль будет выполнять некоторые пакетные задания.

Требования для Spring Cloud Data Flow

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

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

Spring Cloud Data Flow

В качестве второго раунда технологических инноваций Pivotal запустила Spring Cloud Data Flow, чтобы заменить исходный Spring XD. Spring Cloud Data Flow наследует сильные стороны Spring XD и обеспечивает более масштабируемое решение за счет использования собственного облачного подхода. Spring Cloud Data Flow — это модель гибридных вычислений, объединяющая потоковую и пакетную обработку. Разработчики могут использовать Spring Cloud Data Flow для создания и управления конвейерами данных для общих процессов, таких как прием данных, аналитика в реальном времени и пакетная обработка. Spring Cloud Data Flow будет предоставлять только модель службы управления, предназначенную для оптимизации инженерных работ по проектам данных и позволяющую разработчикам сосредоточиться на конкретных проблемах и их анализе.

Архитектура Spring Cloud Data Flow

От Spring XD до Spring Cloud Data Flow произошли фундаментальные изменения в структуре функциональности и подходе к расширению приложений с помощью облачных архитектур.

Spring Cloud Data Flow перешел от традиционной архитектуры на основе компонентов к архитектуре микросервисов, управляемой сообщениями, которая больше подходит для облачных приложений. Теперь модули Spring XD заменены микросервисами, развернутыми в облаке.

В частности, Spring Cloud Data Flow претерпел некоторые серьезные изменения в следующих областях:

  • Чтобы воспользоваться преимуществами облачной платформы, Spring Cloud Data Flow представляет интерфейс поставщика услуг (SPI), который заменяет уровень среды выполнения Spring XD.
  • Пользовательский интерфейс и элементы интеграции, такие как Admin REST API, оболочка и слой пользовательского интерфейса, такие же, как Spring XD, но базовая архитектура была значительно изменена.
  • Интерфейс поставщика услуг (SPI) заменяет режим работы на основе Zookeeper. SPI теперь координирует свои действия с другими системами, такими как Pivotal Cloud Foundry или Yarn, для мониторинга и запуска приложений на основе микросервисов.

Компоненты Spring Cloud Data Flow:

На приведенной выше диаграмме показан типичный поток данных, созданный с использованием модели Spring Cloud Data Flow.

Поскольку микросервисы Spring Boot, источники данных, задания, приемники данных и процессоры данных могут быть развернуты в кластерах Cloud Foundry, Lattice или Yarn. Используя эти микросервисы, развернутые на собственных облачных платформах, мы можем создавать конвейеры данных и передавать их в цели на основе Yarn, Lattice или Cloud Foundry. SPI (интерфейсы поставщиков услуг) для конкретных платформ используются для обнаружения и привязки микросервисов, а также для привязки каналов на основе платформы разработки.

Пример

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

С таким же успехом мы могли бы создать такой вариант использования, чтобы увидеть изменения Spring Cloud Data Flow на высоком уровне: создать полный поток данных без собственного модуля источника данных, например, создать поток данных для данных Facebook для анализа поста потока данных Facebook. . В этом случае мы не можем использовать модуль источника данных Facebook, который можно случайно использовать в модуле Spring Cloud Data Flow, поэтому нам нужно создать собственный модуль для источника данных Facebook. Для создания потока данных требуются три основных микросервиса: источник данных, обработчик данных и приемник данных. Все три микросервиса имеют соответствующие классы интерфейса.

Пример кода микросервиса для источника и приемника данных конвейера данных Facebook:

Источник данных Facebook:

@SpringBootApplication
@ComponentScan(.class)
public class SourceApplication {
    public static void main(String[] args) {
        SpringApplication.run(SourceApplication.class, args);
    }
}

@Configuration
@EnableBinding(Source.class)
public class FBSource {
    @Value("${format}")
    private String format;
    
    @Bean
    @InboundChannelAdapter(value = Source.OUTPUT, poller = @Poller(fixedDelay = "${fixedDelay}", maxMessagesPerPoll = "1"))
    public PostSource<String> FBPostSource() {
        // 一些从 Facebook 获取帖子的逻辑
        return // Facebook 帖子列表
    }
}

@EnableBindings(Source.class)Аннотация проверит, существует ли соответствующая реализация класса интерфейса в качестве привязываемого компонента (чтобы установить в пути к классам приложения, см. Redis), а затем этот компонент создаст соответствующие адаптеры канала (адаптеры канала). Все микросервисы превращаются в приложения Spring Boot для более простого управления зависимостями.

Получатель данных Facebook:

@SpringBootApplication
@EnableBinding(Sink.class)
@ComponentScan(.class)
public class SinkApplication {
    public static void main(String[] args) {
        SpringApplication.run(SinkApplication.class, args);
    }
}

@Configuration
public class FBSink {
    private static Logger logger = LoggerFactory.getLogger(LogSink.class);
    
    @ServiceActivator(Source.INPUT)
    public void loggerSink(Object payload) {
        logger.info("Received: " + payload);
    }
}

Приведенный выше код получает данные из потока Facebook и записывает их в консоль.Sink.classпередается в качестве параметра@EnableBindingаннотация. Кроме того@ServiceActivatorподключит модуль ввода данных к консоли конечной точки в приведенном выше примере.

Некоторые микросервисы, которые действуют как обработчики данных, будут фильтровать сообщения Facebook из микросервиса FBSource на основе входного выражения SPEL, а выходные данные микросервиса обработчика данных будут входными данными микросервиса FBSink.

в заключении

Spring Cloud Data Flow использует модуль потока Spring Cloud. Мы можем использовать последний для создания и запуска микросервисов обмена сообщениями в виде приложений Spring Boot, чтобы их можно было развертывать на разных платформах, запускать независимо и взаимодействовать друг с другом. Spring Cloud Data Flow может действовать как клей при создании конвейеров данных с использованием модуля потока Spring Cloud.

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

вопросы и ответы
Как Spring Boot настраивает порты?
Связанное Чтение
АОП-идея серии фреймворков Spring
Знакомство с фреймворком Spring Boot
Введение в основы управления транзакциями Spring Резюме

Эта статья была разрешена автором для публикации сообщества Tencent Cloud +, исходная ссылка: https://cloud.tencent.com/developer/article/1128177?fromSource=waitui.


Категории