Это гостевая запись в блоге Джейми Гудиера ( blog , @icbts ). Он является сторонником открытого кода, разработчиком Apache и аналитиком компьютерных систем в Savoir Technologies ; он проектировал, критиковал и поддерживал архитектуры для крупных организаций по всему миру. Он получил степень бакалавра наук в области компьютерных наук в Университете Мемориала в Ньюфаундленде.
Джейми работал в области системного администрирования, обеспечения качества программного обеспечения и в качестве старшего разработчика программного обеспечения для предприятий, начиная от небольших стартапов и заканчивая международными корпорациями. Он получил статус коммиттера в Apache Karaf, ServiceMix, и Феликс, член комитета по управлению проектами в Apache Karaf, и является членом Apache Software Foundation. Его первой печатной публикацией было соавторство Instant OSGi Starter, Packt Publishing, с Йоханом Эдстромом, за которым следуют Apache Karaf, Packt Publishing, с Йоханом Эдстромом и Хитом Кеслером. Его третья и последняя публикация — « Поваренная книга Apache Karaf» , «Packt Publishing», с Йоханом Эдстромом, Хитом Кеслером и Ахимом Нирбеком.
Мне нравятся микро сервисные архитектуры.
Существует много описаний того, что представляет собой микро-сервис, и множество спецификаций, которые можно описать как следующие шаблону. Короче говоря, я склонен описывать их как наименьшую единицу работы, которую приложение может выполнять в качестве службы для других. Объединяя эти сервисы, мы можем создавать более крупные архитектуры, которые являются модульными, легкими и устойчивыми к изменениям.
С точки зрения современной системной архитектуры возможность предоставления небольшим приложениям полного контроля жизненного цикла является нашей идеальной платформой. Операторам нужно только развернуть нужные им сервисы, обновить их на месте, раскрутить дополнительные экземпляры по мере необходимости. Другой способ описать это как Приложения как Сервис (AaaS). Возьмите определенные небольшие сервисы, такие как маршруты Apache Camel или конечные точки Apache CXF, и поднимайте их вверх и вниз, не разрушая всего приложения. Apache Karaf — платформа для предоставления микро-услуг.
Чтобы упростить микроуслуги, Караф предоставляет множество полезных функций прямо из коробки;
- Коллекция хорошо протестированных библиотек и фреймворков, которые помогут вам догадаться о сборке платформы для ваших приложений.
- Предоставление библиотек или приложений с помощью различных механизмов, таких как Apache Maven.
- Дескрипторы функций для совместного развертывания связанных служб и ресурсов.
- Консольные и веб-команды, облегчающие тонкое управление, и
- Упрощенное интеграционное тестирование через экзамен Pax.
Один из моих любимых шаблонов микросервисов — использование Apache Camel с фабрикой управляемых сервисов (MSF) на Apache Karaf. Camel предоставляет простой DSL для соединения шаблонов корпоративной интеграции, например, для перемещения данных из конечной точки A в конечную точку B. Фабрика управляемых услуг — это модульная модель для конфигураций, основанных на развертывании ваших микро-сервисов — она связывает вместе ConfigAdmin, реестр служб OSGi и код нашего приложения.
Например, пользователь может создать конфигурацию для подключения своего маршрута Camel, используя MSF, для каждой конфигурации будут созданы уникальные PID. Эта модель действительно мощная. Создайте 100 конфигураций, и будут созданы 100 соответствующих микросервисов (верблюжьи маршруты). Однако требуется только один набор кода.
Давайте внимательно рассмотрим реализацию фабрики управляемых услуг. ManagedServiceFactory отвечает за управление экземплярами (configurationPid), создание или обновление значений созданных экземпляров служб и, наконец, очистку после создания экземпляров служб. Узнайте больше об API ManagedServiceFactory .
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
|
public class HelloFactory implements ManagedServiceFactory { @Override public String getName() { return configurationPid; } @Override public void updated(String pid, Dictionary dict) throws ConfigurationException { // Create a dispatching engine for given configuration. } @Override public void deleted(String pid) { // Delete corresponding dispatch engine for given configuration. } //We wire in blueprint public void init() {} public void destroy() {} public void setConfigurationPid(String configurationPid) {} public void setBundleContext(BundleContext bContext) {} public void setCamelContext(CamelContext camelContext) {}} |
Мы переопределяем данный интерфейс ManageServiceFactory для работы с DispatchEngines. DispatchEngine — это простой класс, содержащий код для создания экземпляра маршрута Camel с использованием заданной конфигурации.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
|
public class HelloDispatcher { public void start() { // Create routeBuilder using configuration, add to CamelContext. // Here ‘greeting’ and ‘name’ comes from configuration file. from(“timer://helloTimer?fixedRate=true.=1000"). routeId("Hello " + name). log(greeting + " " + name); } public void stop() { // remove route from CamelContext. } } |
Когда мы разворачиваем эти классы как пакет в Karaf, мы получаем особенно мощное приложение как сервис. Каждая конфигурация, которую мы предоставляем сервису, создает новый маршрутизатор Camel (эти файлы конфигурации просто состоят из приветствия и имени). Команды Camel Karaf позволяют точно контролировать эти маршруты, обеспечивая оператору простое управление.
Полный код для приведенного выше примера доступен через github и подробно рассмотрен в Apache Karaf Cookbook от Packt Publishing.
Микросервисные архитектуры, такие как описанные выше, раскрывают возможности OSGi для обычных приложений, таких как маршрут Camel или конечная точка CXF. Однако это не единственные приложения, которые приносят пользу. Я хотел бы поделиться одной из наших историй успеха Karaf, в которой рассказывается о том, как Apache Karaf помог создать структуру в существующем крупномасштабном проекте, основанном на микросервисах.
Представьте себе, что сотни пакетов распределены по десяткам взаимосвязанных проектов, по сути, развернутых в простом ядре OSGi и оставленных на удачу для успешной загрузки. Именно в такой ситуации OpenDaylight, платформа для SDN и NFV, оказалась несколько месяцев назад.
Используя дескрипторы Karaf Feature, каждый проект смог организовать свои зависимости, пакеты и другие ресурсы в последовательные структуры. Пользовательские команды были разработаны для взаимодействия с их основными службами. Интеграционное тестирование каждого проекта в целом проекта было автоматизировано. Наконец, все эти проекты были интегрированы в собственные дистрибутивы.
Их первый релиз на базе Karaf, Helium, должен выйти очень скоро. Мы все с нетерпением ждем возможности приветствовать сообщество SDN & NFV в Karaf.
В то время как линия Apache Karaf 3.0.x остается нашей основной производственной целью, сообщество, как никогда, занимается разработкой следующего поколения контейнеров Karaf.
Линия 4.0.x будет поставляться с поддержкой OSGi Rev5 через Felix 4.4.1 и Equinox 3.9.1-v20140110-1610, а также полностью переработанной внутренней структурой, основанной на декларативных сервисах вместо Blueprint. С точки зрения пользователей эти изменения приведут к меньшему, более эффективному ядру Karaf. В Karaf будет присутствовать функция Blueprint, чтобы вы могли легко устанавливать приложения на основе Blueprint. Вы всегда сможете использовать Blueprint в Karaf. Таким образом, основное отличие от точки зрения пользователя заключается в том, что вам нужно зависеть от службы Blueprint, если вам это нужно.
Это был очень краткий обзор микросервисных архитектур по Apache Karaf и будущему направлению Karaf. Я бы посоветовал всем, кто интересуется Micro Services, посетить сайт OSGi Alliance и присоединиться к сообществу Apache Karaf . Для тех, кому хотелось бы погрузиться в продвинутый пользовательский дистрибутив Karaf, загляните в Aetos . Apache Karaf также является частью JBoss Fuse .
| Ссылка: | Будущее за Micro Service Architecture на Apache Karaf от нашего партнера по JCG Маркуса Эйзела (Markus Eisele) из блога « Разработка программного обеспечения для предприятий с использованием Java» . |