Что такое apache karaf

Будущее за микросервисными архитектурами на Apache Karaf

Мне нравятся микро сервисные архитектуры.

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

С точки зрения современной системной архитектуры возможность предоставления небольшим приложениям полного контроля жизненного цикла является нашей идеальной платформой. Операторам нужно только развернуть нужные им сервисы, обновить их на месте, раскрутить дополнительные экземпляры по мере необходимости. Другой способ описать это как Приложения как Сервис (AaaS). Возьмите определенные небольшие сервисы, такие как маршруты Apache Camel или конечные точки Apache CXF, и поднимайте их вверх и вниз, не разрушая всего приложения. Apache Karaf — платформа для предоставления микро-услуг.

Чтобы упростить микроуслуги, Караф предоставляет множество полезных функций прямо из коробки;

Один из моих любимых шаблонов микросервисов — использование Apache Camel с фабрикой управляемых сервисов (MSF) на Apache Karaf. Camel предоставляет простой DSL для соединения шаблонов корпоративной интеграции, например, для перемещения данных из конечной точки A в конечную точку B. Фабрика управляемых услуг — это модульная модель для конфигураций, основанных на развертывании ваших микро-сервисов — она ​​связывает вместе ConfigAdmin, реестр служб OSGi и код нашего приложения.

Например, пользователь может создать конфигурацию для подключения своего маршрута Camel, используя MSF, для каждой конфигурации будут созданы уникальные PID. Эта модель действительно мощная. Создайте 100 конфигураций, и будут созданы 100 соответствующих микросервисов (верблюжьи маршруты). Однако требуется только один набор кода.

Источник

Русские Блоги

【Введение в Караф Апач】

Во-первых, Apache Karaf введение

Apache Karaf is a modern and polymorphic container.

Караф можно использовать как отдельный контейнер или загрузчик Караф как пусковую установку.

It’s a lightweight, powerful, and enterprise ready container powered by OSGi.

You can deploy different kind of applications in Karaf, OSGi or non-OSGi.

With this flexibility, Karaf is the perfect container for microservices, systems integration, big data, and much more.

Apache Karaf uses either the Apache Felix or Eclipse Equinox OSGi frameworks, providing additional features on top of the framework.

Apache Karaf can be scaled from a very lightweight container to a fully featured enterprise service: it’s a very flexible and extensible container, covering all the major needs.

II. Apache Karaf собственности

Here is a short list of provided features:

1)Hot deployment : simply drop a file in the deploy directory, Apache Karaf will detect the type of the file and

2)Complete Console: Apache Karaf provides a complete Unix-like console where you can completely manage the container.

3)Dynamic Configuration : Apache Karaf provides a set of commands focused on managing its own configuration.

All configuration files are centralized in the etc folder. Any change in a configuration file is noticed and reloaded.

4)Advanced Logging System : Apache Karaf supports all the popular logging frameworks (slf4j, log4j, etc). Whichever

logging framework you use, Apache Karaf centralizes the configuration in one file.

5)Provisioning: Apache Karaf supports a large set of URLs where you can install your applications (Maven repository, HTTP,

file, etc). It also provides the concept of «Karaf Features» which is a way to describe your application.

6)Management: Apache Karaf is an enterprise-ready container, providing many management indicators and operations

7)Remote: Apache Karaf embeds an SSHd server allowing you to use the console remotely. The management layer is also

8)Security: Apache Karaf provides a complete security framework (based on JAAS), and provides a RBAC (Role-Based Access

Control) mechanism for console and JMX access.

9)Instances: multiple instances of Apache Karaf can be managed directly from a main instance (root).

10)OSGi frameworks: Apache Karaf is not tightly coupled to one OSGi framework. By default, Apache Karaf runs with the Apache Felix

Framework, but you can easily switch to Equinox (just change one property in a configuration file).

Караф имеет следующие характеристики:

Горячее развертывание Вы можете напрямую перетащить свое приложение в папку развертывания karaf, вы можете выполнить автоматическое развертывание, пользователи также могут реализовать собственный развертыватель.

Динамическая конфигурация: Все конфигурации, включая сам karaf и конфигурацию приложения, находятся в папке karaf и т. Д. Изменения в файле конфигурации вступят в силу немедленно, без перезапуска.

Лог-система: karaf использует централизованный бэкэнд журналов и поддерживает множество популярных каркасов логов, таких как log4j, slf4j, logback и т. д.

Provisioning： karaf предоставляет способ предоставления приложений, называемых функциями karaf

консоль : Karaf предоставляет полную unix-подобную консоль, которую пользователи могут использовать для управления контейнерами и приложениями.Эта консоль поддерживает неполную контекстную справку, сочетания клавиш и т. Д.

Удаленное управление: В karaf есть встроенный ssh-сервер, который позволяет удаленно подключаться с помощью ssh-клиента. Кроме того, karaf также предоставляет сервис JMX MBean, который позволяет вам управлять контейнерами с помощью JMX-клиента.

WEB консоль : Обеспечивает управление контейнерами через веб-консоль karaf

Безопасность: Karaf полностью поддерживает основанную на JAAS систему безопасности. Он также поддерживает управление RBAC для команд оболочки и объектов JMX. Пользователи могут использовать уровень безопасности Карафа непосредственно в приложении

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

три 、 Архитектура Apache Karaf

Внутривенно Apache K araf Структура каталогов установки

Структура каталога установки Karaf выглядит следующим образом:

/ bin: скрипт запуска

/ etc: файл инициализации

/ data: рабочий каталог

/ cache: кеш пакетов OSGi Framework

/ generate-bundles: временная папка для развертывания

/ deploy: каталог горячего развертывания

/ instances: каталог, содержащий дочерние экземпляры

/ lib: содержит загрузочную библиотеку

/ lib / ext: каталог расширений JRE

/ lib / одобрено: согласен с каталогом библиотеки

/ system: библиотека пакетов OSGi, как хранилище Maven2

Папка Data содержит все рабочие файлы karaf и временные файлы.Если вы хотите перезагрузить компьютер из начального состояния, вы можете очистить этот каталог, что имеет тот же эффект, что и «Восстановить начальные настройки».

Источник

Русские Блоги

Apache Karaf Research

I. Терминология

(A) OSGi

Разработано на основе Spring DM.

Основные цели использования OSGi: высокомодульная, сильно отделенная, SOA и простота обслуживания.

Наиболее важные особенности OSGi:

ClassLoader является очень важной концепцией в Java, и все знают, что сама JVM не предоставляет очень мощных функций в ClassLoader, таких как разработка модулей очень важна Изоляция модуля Механизм ClassLoader, механизм загрузки версий и т. Д. OSGI использует JVM ClassLoader для формирования модуля для изоляции механизма ClassLoader, а также расширяет различные функции ClassLoader, такие как загрузка по версии и атрибуты фильтрации.

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

(Б) Караф

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

(Три) Связка

Модули в ОСГИ. Это заканчивается как упаковка фляги в контейнере karaf. Один пакет соответствует одному OSGi ClassLoader.

Разделение классов между Пакетами:

(Четыре) модули

Модуль должен иметь следующие 3 характеристики:

Файл Jar языка Java не может полностью реализовать три характеристики модуля, в основном он сталкивается со следующими тремя проблемами:

(5) особенность

То есть набор связок с определенными функциями.

(VI) План

Инфраструктура DI OSGi или стандарт внедрения OSGi, очень похожий на контекст Spring. Сборка приложений в XML. Он используется для обработки сборки объектов POJO, которые могут достигать объектов через связки. Опубликуйте xxService в качестве службы OSGi, используя контекст проекта.

Он имеет две конкретные реализации: Овен Apache, Близнецы Eclipse.

Включены под-теги: bean, service, reference, reference-list и т. Д.

(7) Конфигурация администратора

Контейнер OSGi содержит очень хорошую спецификацию конфигурации: службу Config Admin из спецификации уровня предприятия. Файлы конфигурации могут быть автоматически развернуты в комплекте.

(Восемь) CXF

Инфраструктура CXF представляет собой инфраструктуру разработки приложений SOA, основанную на технологии сервлетов.Для запуска корпоративного приложения, разработанного на основе инфраструктуры приложений CXF, в дополнение к самой платформе CXF также требуется поддержка контейнеров JDK и сервлетов.

CXF наследует лучшие из двух проектов с открытым исходным кодом Celtix и XFire, обеспечиваяJAX-WSКомплексная поддержка, а также поддержка различных типов Binding, DataBinding, Transport и различных форматов. В зависимости от потребностей конкретного проекта вы можете использовать Code First или WSDL First для простой реализации Web-сервисов. Выпуск и использование.

Во-вторых, Караф часто используемые команды

(1) Просмотр состояния запуска всех пакетов

(Два)Посмотреть список всех профилей

(Три) изменить конфигурацию

(D) начать

(5) Стоп

(6) Получить помощь

(7) Просмотр журнала

(Н)Добавить, установить и развернуть функциональные приложения

(Ix)Остановите и удалите приложения

(Х)Посмотреть список всех http сервисов

В-третьих, структура каталогов

В-четвертых, характеристики Карафа

Выдающиеся характеристики Карафа:

Все эти функции делают разработку серверных приложений OSGi почти такой же простой, как и обычные приложения Java.

Пять, создать и установить небольшое приложение OSGi

Пример расположения источника списка задач проекта:

Пример списка задач содержит 4 подпроекта:

Moudle

описание

Сервисные интерфейсы и классы задач

Простая, постоянная реализация, которая обеспечивает TaskService

Сервлет, использующий TaskService для отображения списка задач

Характеристика приложения, поэтому установка в Караф будет легкой

(A) родительский пом и общие настройки проекта

Он также экспортирует все пакеты, которые не содержат строку impl или internal. В нашем случае мы хотим импортировать пакет модели, а не пакет persistence.impl. Благодаря соглашению об именах нам не требуется дополнительная настройка.

(Два) Tasklist-модель

Этот проект содержит модель, в нашем случае это класс Task и интерфейс TaskService. И Tasklist-Persistence и TaskList-UI используют эту модель. Любой пользователь TaskService нуждается только в этой модели. Так что он никогда не будет напрямую связан с нашей текущей реализацией.

(Три) Список задач-постоянство

Очень простая постоянная реализация TaskServiceImpl управляет задачами в простой HashMap. Этот класс использует аннотацию @Singleton, чтобы представить класс в виде bean-компонента.

Аннотация @Service представляет компонент в качестве службы OSGi, а атрибут properties позволяет добавлять атрибуты службы. В нашем примере свойство service.exported.interfaces, которое мы устанавливаем, может использоваться CXF-DOSGi, мы представим его в следующем уроке. Для этого урока вы также можете удалить атрибуты.

blueprint-maven-plugin Обработает вышеприведенный класс и автоматически создаст соответствующий шаблон XML, что избавляет нас от необходимости вручную писать проект XML.
Вы можете найти автоматически созданный проект xml в target / generate-resources.

Автоматически сгенерированный xml:

(4) Tasklist-UI

Проект пользовательского интерфейса содержит небольшой сервлет TaskServlet для отображения списка задач и отдельных задач. Для обработки задач сервлетам нужен TaskService. Мы используем аннотацию @Inject для внедрения TaskService, аннотация @Inject может внедрять любой компонент по типу, а аннотация @Service создает ссылку на проект службы OSGi данного типа.
Весь класс предоставляется в качестве службы OSGi интерфейса java.http.Servlet со специальным атрибутом osgi.http.whiteboard.servlet.pattern = / tasklist. Это вызовет расширение доски pax web, которое будет извлекать службу и экспортировать ее в виде сервлета в относительный URL / список задач.

Фрагмент соответствующего кода:

Автоматически сгенерированный xml:

(5) Tasklist-функции

Последний проект только установил дескриптор функции для репозитория maven, поэтому мы можем легко установить его в Karaf. Дескриптор определяет функцию под названием tasklist и пакеты, которые нужно установить из репозитория maven.

features.xml：

Функция может содержать другие функции, которые должны быть установлены, и связывать пакеты для установки. Связки обычно используют URL-адреса mvn. Это означает, что они загружаются из настроенного репозитория maven или локального репозитория maven в

(Шесть) установки приложений

Команда Караф:

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

(VII) Дополнительное резюме

1.pom.xml конфигурация

Родительский и функциональный проект pom.xml указывают:

TaskList-модель, TaskList-постоянство, TaskList-UI спецификации проекта:

2.Maven связанная конфигурация плагина

maven-bundle-plugin Создайте банку с помощью OSGi Manifest.

blueprint-maven-plugin Соответствующий blueprint xml будет автоматически создан для классов с аннотациями blueprint, что избавляет нас от необходимости писать blueprint xml вручную.

Шесть, автоматически развернуть файлы конфигурации в комплекте

Пример расположения исходного кода configadmin проекта:

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

2 способа обработки изменений файла конфигурации:

Пока контекст проекта находится в каталоге OSGI-INF / blueprint и загружается расширитель проекта, контекст проекта просто активируется.

Определяет cm:property-placeholder Элементы. Функция обработки атрибутов-заполнителей файла аналогична, но здесь происходит обработка службы Config Admin. Нам нужно предоставить настроенный PID и стратегию обновления. Для стратегии обновления мы выбираем «перезагрузить». Это означает, что после изменения конфигурации контекст проекта перезагружается или изменяется для отражения. Мы также устанавливаем свойства по умолчанию. Эти значения по умолчанию будут использоваться, когда настроенный PID не может быть найден или свойство не существует.

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

Семь других

Следующие разделы Karaf опущены в этом документе:

OSGi в чайнике

(I) Связанные предметы

Проект сборки pentaho-karaf содержит компоненты Karaf и два подмодуля, активаторы проекта pentaho-blueprint и функции pentaho-karaf.

pentaho-karaf-features Содержит файлы функций Pentaho Karaf для Open (стандарт) и EE (предприятие). Каждый файл объектов публикуется с использованием собственного классификатора pentaho-karaf-features- [классификатор].

pentaho-blueprint-activators Содержит определения с компонентами активации OSGI Blueprint Файл. На них ссылаются функции Pentaho и они предназначены для управления функциональной средой. Каждый файл публикуется с использованием собственного классификатора, поэтому артефакт представляет собой pentaho-blueprint-activators- [классификатор]. Добавьте активаторы по мере необходимости для поддержки ваших функций. Однако, если функция включает в себя пакет Pentaho, который может содержать файл активатора, сделайте это вместо добавления здесь.

Основная сборка сначала строит функциональные и активаторные модули.

(Два) PDI-OSGi Bridge

Как следует из названия, «мост» выступает в качестве посредника между PluginRegistry PDI и OSGI. Мост может найти любые классы подключаемых модулей PDI, опубликованные пакетом OSGI в Реестре служб. Поскольку OSGI является динамической системой, которая может устанавливать и удалять пакеты в любое время во время выполнения программы, в PluginRegistry была добавлена ​​новая функция для прослушивания этих событий плагина. Например, пользовательский интерфейс Spoon обновляет шаги по мере их добавления или удаления.

Разработчикам плагинов, которые хотят воспользоваться преимуществами технологии OSGI, не нужно разбираться во внутренних деталях Bridge, им нужно только понимать, как разрабатывать пакеты OSGI и как их развертывать в среде PDI.

(3) почему выбирают OSGi

Фактически, переход на OSGI не заменял одну систему плагинов на другую. Вместо этого он переходит к архитектуре, которая вообще не требует подключаемой системы.

(D) Процесс запуска чайника и процесс загрузки плагина

На следующем рисунке показан скрипт запуска Kettle:

Анализируя скрипт studio.bat, нетрудно найти загрузочный пакет Kettle launcher.jar.

Файл launcher.jar является производным от проекта component / pentaho-common / pentaho-application-launcher, поэтому, если вы хотите начать с компиляции всего проекта Kettle, сначала необходимо скомпилировать компонент, а затем скомпилировать основной.

Для отладки добавьте приведенный выше оператор отладки.

Прочитайте файл launcher.properties, загрузите и запустите метод main класса Spoon в соответствии с его конфигурацией. Содержимое файла выглядит следующим образом:

1. Созданы некоторые файлы журналов или другие каталоги;

2. Запустите пул потоков и зарегистрируйте плагин;

Класс KettleEnVironment содержит все конфигурации Kettle для чтения, а также может регистрировать различные плагины следующим образом:

Источник

Обзор ESB-систем ServiceMix и Fuse

Представляю вашему вниманию небольшой обзор систем ESB (Enterprise Service Bus) на основе Apache Camel: Apache ServiceMix и Red Hat JBoss Fuse. Эти две системы построены на одних и тех же компонентах и обладают схожими возможностями. Более того, в большинстве случаев, они взаимозаменяемы. Apache ServiceMix разрабатывается open-source сообществом, Red Hat JBoss Fuse компанией Red Hat. По большей части, это одни и те же люди.

Для начала, разберемся что такое ESB и зачем системы такого класса используются в информационной инфраструктуре предприятий. На современных предприятиях используется всё большей приложений различного класса: ERP, CRM, BPM, DWH, ECM и ещё множество трех-буквенных аббревиатур. Все эти приложения используют для интеграции различные протоколы и различные форматы данных. Для того чтобы связать все эти системы между собой и используется ESB.

Итак ESB-системы выполняют следующие основные функции:

Apache Camel реализует непосредственно функции ESB на основе паттернов EIP (Enterprise Integration Patterns). Apache Camel имеет свой DSL для задач интеграции. Существует несколько его реализаций: Spring DSL, Blueprint DSL, Java DSL, Groovy DSL, Scala DSL. Так же, в состав Apache Camel входит более 100 компонент отвечающих за подключение по различным протоколам и преобразование данных.

Apache ActiveMQ — система очередей сообщений. Реализуется различные функции обмена сообщениями: обмен сообщениями по моделям отправитель-получатель (sender-receiver), издатель-подписчик (publish-subscribe), синхронный обмен (request-response), персистентные сообщения (persistent message), поддержку транзакций, включая распределенные XA-транзакции.

Apache CXF — библиотека, реализующая функции веб-сервисов, включая SOAP и REST.

Apache Karaf — платформа для запуска приложений на основе OSGi. OSGi позволяет устанавливать, удалять и обновлять различные модули (bundle) без перезапуска всей системы и без остановки зависимых модулей. Это особенно важно в корпоративной инфраструктуре, где остановки компонент крайне нежелательны, так как могут привести к прямым финансовым потерям. В системах на основе OSGi всё является модулем (bundle): библиотеки, маршруты интеграции, подключения к ресурсам.

Для Red Hat JBoss Fuse существует альтернативный вариант запуска. Вместо Apache Karaf можно использовать Red Hat JBoss EAP.

Обе системы поддерживают отказоустойчивую (failover) конфигурацию по модели master-slave.

Встает резонный вопрос, если Apache ServiceMix и Red Hat JBoss Fuse состоят из одних и тех же компонент, реализуют одну и ту же функциональность, разрабатываются одними и теми же людьми, то зачем платить больше? Кроме указанных выше компонентов, Red Hat JBoss Fuse включает несколько дополнительных, упрощающих работу администратора и позволяющих управлять кластером.

Hawtio — графическая консоль управления, позволяющая подключать различные плагины, в том числе для управления Apache Camel, Apache ActiveMQ, Fuse Fabric и т.д… Несмотря на то что Hawtio не входит в состав Apache ServiceMix, она может быть установлена на любую версию Apache ServiceMix двумя командами.

Fuse Fabric — система управления кластером на основе Fabric8. Позволяет управлять конфигурациями узлов кластера группами или по отдельности. Поддерживает версионирование конфигурации. Так же как и Hawtio, Fabric8 может быть легко установлена на Apache ServiceMix. Кроме того, для Apache ServiceMix имеется альтернативный способ управления кластером на основе Apache Karaf Cellar.

При приобретении подписки Red Hat JBoss Fuse вы получаете поддержку от компании Red Hat и возможность использовать инструмент мониторинга Red Hat JBoss Operation Network. Для Apache ServiceMix можно использовать RHQ, open-source аналог Red Hat JBoss Operation Network. Как альтернатива, для целей мониторинга Apache ServiceMix может быть использован Apache Karaf Decanter.

Apache ServiceMix’у тоже есть чем похвастаться. В состав последних версий Apache ServiceMix входит движок бизнес-процессов Activiti, который позволяет реализовывать персистентные интеграционные процессы. Apache Camel не предназначен для реализации интеграционных взаимодействий разнесенных по времени. Если при использовании Apache Camel без Activiti происходит сбой, то все не отправленные данные будут потеряны, все транзакции откатятся. В то же время, с использованием Activiti мы можем сохранить состояние процесса в БД. Red Hat для решения подобных задач предлагает использовать Red Hat JBoss BPM Suite.

Основным преимуществом Apache ServiceMix перед Red Hat JBoss Fuse является то что Apache ServiceMix включает более новые версии компонент.

Что выбрать? Универсального ответа нет. Если у вас есть команда профессионалов, имеющих опыт работы с Apache ServiceMix или Red Hat JBoss Fuse, то можно задействовать все преимущества Apache ServiceMix и заплатить при этом меньше. Если же опыт отсутствует, то поддержка от компании Red Hat не будет лишней.

Кроме рассмотренных систем, на основе Apache Camel существует Talend ESB. Но я не имел практического опыта работы с ней, поэтому в обзор она не включена.

Источник