Модулни приложения в Java

Модулни приложения в Java. Как? 1

24.03.17 02:54 •
jetinfosystems •
• # 324810
• Habrahabr
42 •
3800

- като Forbes, само по-добре.

OSGi на помощ

За да се създаде наистина модулна архитектура в Java може да използва OSGi (Open Gateway Инициатива Services) - спецификация, динамичен модул на системата и платформа за обслужване на Java-базирани приложения (OSGi Алианс за разработчици). Той описва модел на разработка на софтуер, в които компонентите имат три основни характеристики на модулната заявлението. Говорейки за капсулиране (всеки модул се крие изпълнението му от външната среда), лоша връзка (модули взаимодействат само с помощта на предварително сключени договори) и динамични (компоненти могат да се сменят в движение, без да спират цялото приложение). В основата на концепцията за OSGi са 2 лица: комплекти (краищата) и услуги (услуги).

За разработката на софтуер в Java, който обикновено се използва библиотеки на трети страни. Java библиотека свят са опаковани във файлове с разширение буркан (Java архив). общ ZIP-файл с Java-класа (с файлове за разширението .class). Използването на библиотеките може да бъде свързано с определени трудности.

След като започнете да използвате някоя библиотека, сте склонни да станат достъпни за всички класове в него. Факт е, че библиотеката на разработчиците няма как да се скрие класове, които се използват за реализиране на тяхната вътрешна логика. По този начин, ако използвате код, който не е предвидено за използване извън библиотеката, може да попаднете на несъвместимост с новата версия на библиотеката, или да наруши правилното му функциониране.

Друг проблем - т.нар JAR Hell, за които разработчиците са разбити много копия. Същността му е следната: след като започнете да използвате различни версии на една и съща библиотека (това се случва в големи проекти, които се развиват във времето), можете да се изправи пред факта, че един и същи клас има различни методи в различните версии на библиотеката. Java е проектиран така, че първата версия на библиотеката, която ще се използва воля клас товарач. По този начин, като се позовава на кода за всеки клас по време на изпълнение, ще получите съобщение за грешка, че методът, към която се отнасят, не съществува. Това се дължи на факта, че Java Runtime не знае нищо за версията на библиотеката, за да се използва във всеки конкретен случай.

OSGi разработчиците не са се променили структурата на JAR-файлове за модулност, и просто се добавят към тях допълнителна информация, която се използва OSGi среда. Освен това, тази информация не засяга използването на JAR-файла в обичайните Java-приложения. Така че, за да JAR-файл е станал OSGi-комплект, добавя данни за определяне на Export-пакет (набор от пакети, които са на разположение за употреба извън него) и Import-пакет (чанти други групи, необходими за този набор). Това е възможно да се определи като версия на API, който предвижда набор от други групи, както и версията или гама от версии на API, който е набор от изисквания за работата си от тях. Всички набор от класове, които не са сред вписванията за износ, не са налични извън снимачната площадка (Private). По този начин, набор от OSGi-изпълни изискването на слаба свързаност.

Днес повечето Java библиотеки вече OSGi готов, т.е. предоставяне на информация на възможността на контейнера за в-OSGi. В допълнение, има много инструменти и помощни програми, които можете да използвате за създаване на модули за OSGi обикновени JAR-файлове.

В OSGi могат лесно да бъдат избегнати JAR Hell ситуации, тъй като връзката между набори и интерфейси, осигурени от тези договорености имат ясна версия. Можете да динамично натоварване и разтоварване на нови комплекти по време на изпълнение. OSGi проследява зависимости между сериите и динамично ги решава.

Така че, с помощта на OSGi-комплекти ние можем да разработим модулни приложения, които взаимодействат чрез интерфейси (API). Но къде да се вземе един клас, който реализира необходимата интерфейс? Възможност за "добавите множество API" не е подходящо - в рамките на модулна архитектура, ние се съгласихме да не използва вътрешни класове, определени извън тези комплекти. Друго решение. приложи шаблон "фабрика" чрез прилагане на интерфейса и да го добавите към набор от API. Но това не е твърде успешна, защото да се скрие изпълнението на интерфейса ще трябва всеки път да се разработи нов клас.

Търсене изпълнение интерфейс в служба OSGi с помощта на системния регистър. Този регистър комплект могат да се регистрират изпълнение с описвайки му интерфейс. Комплект, който използва интерфейс от друга група може да се постигне изискваното изпълнение на желания интерфейс, за да го в системния регистър. Обикновено, декорите са регистрирани в началото услуги в OSGi-контейнера. Плюс регистър услуги могат да бъдат регистрирани на същите интерфейси с различни приложения и допълнителни данни за самоличност. Използване на филтри, комплектът може да избере най-подходящите в регистъра на представените услуги.

Mikroservisy Java Virtual Machine

Mikroservisnaya архитектура е съвкупност от независими модула - за отделните приложения. Взаимодействието между тях се осъществява чрез добре дефинирани интерфейси с лек протокол (почивка, Протокол буфери, MQ и т.н.). В действителност, всеки модул - това mikroservis извършването на конкретна задача, и съдържащ, като правило, минималният размер на код. Предимствата на този подход за разработка на софтуер:

лекота (mikroservisa на развитие реализира само една част от функционалността на програмата).
облекчаване на замяна (ако услугата не си върши работата, тя може да бъде пренаписана и заменена с нова версия на този софтуер, без спиране).
повторна употреба (mikroservis могат да бъдат използвани там, където е подходящо).

Разработчиците на модулни приложения, използващи OSGi отдавна се радва на всички тези предимства, но само в рамките на виртуалната машина на Java. Всеки комплект с OSGi, която публикува на услугата до регистъра, е mikroservisom в рамките на Java Virtual Machine, JVM (в света на OSGi се наричат mikroservisy μServices).

Red Hat JBoss Fuse

Ние сме в "Jet" използват всички предимства на OSGi за разработка на софтуер за телекомуникационни оператори, застрахователни компании за обработка на компании. За да направите това, ние използваме Red Hat JBoss Fuse (Fuse Fabric конфигурация). Тази платформа предоставя гъвкава среда за OSGi-производителни модулни приложения.

Приемствеността на подаване на заявлението, лесно мащабиране, лесно използване, инструменти за управление на наличности клъстер за клъстер софтуер - всички тези функции са на разположение в Fuse плат. Технологията позволява да се разположи няколко екземпляра на Red Hat JBoss Fuse и да ги комбинира в един клъстер и осигурява централизиран инструмент за управление в резултат на околната среда.

Като част от Fuse материала следващите черпене:

Функции (функции) - набор от най-OSGi набори, които прилагат никакви функции.
Профили (профили) - набор от функции, които трябва да се извършат в един контейнер, както и настройки за конфигурация за сетове, които са включени в тази функция.
Контейнери (съдове) - индивидуални JVM-процеси се изпълняват за конкретен възел клъстер Предпазител Fabric използвате Red Hat JBoss Предпазител контейнер.

Всеки софтуер, базиран на предпазител Fabric технология се състои от OSGi-комплекти, които са групирани в функции и разположени в рамките на всеки отделен процес на JVM на един или повече възли в клъстера, в съответствие с предварително определен профил.

Сряда Fuse Fabric предоставя множество инструменти за лесно управление на клъстерите получени. Можете да създавате профили (и въз основа на тях. Контейнерите), създаване / изтриване / пускане / спиране на контейнерите за всеки хост в клъстера, свържете новия клъстер възли и т.н. И всичко това е на линия - без да се прекъсва работата на други възли в клъстера. Възможно е да се съхранява няколко версии на профили, функции OSGi-комплекти.

Чрез Разпределени OSGi технологии в получените средни OSGi набори могат да си взаимодействат в двете единични и различни контейнери и дори различни гостоприемници. Екстри (с минимални разходи за развитие), като всяка услуга, която предоставя OSGi-комплект могат да бъдат превърнати в REST / уеб-услуга, която може да бъде наречена от външни системи.

По този начин, с помощта на Fuse плат, можем да създадем mikroservisnuyu архитектура, която поддържа лесно конфигуриране и внедряване, изолираната извършването на услуги в рамките на своите JVM-процеси (с техните специфични настройки, например, различни настройки на събирачът), услугите, взаимодействат помежду си по мрежа с помощта на лек протокол.

защото Red Hat JBoss Fuse продукт е базиран на отворен код технология стека Apache ServiceMix, с които разполагаме, има мощни технологии, като Apache ActiveMQ (прилагане на спецификацията JMS), Apache Camel (внедряване на Enterprise интеграция Patterns), Apache CXF (библиотека за REST / уеб програмиране -Service), Blueprint (предоставя възможности зависимост инжектиране), пружина и т.н. Тъй като тези технологии безпроблемно интегрирани един с друг в Red Hat JBoss предпазител, това значително намалява времето за развитие изисква функционалност.

Материал, изготвен от експерти на Центъра за софтуерни решения "Jet Infosystems".

Но интересното е, че тъй като всичко, което стартира в devmode? Стандартна схема натрупване пакет разгръщане? Или приставка се използва?
И струва ми се, че не се твърди, модулни приложения. Вътрешно - да, има смисъл да се код и тест. Но от гледна точка на deploya по-добре да има един артефакт, а не купчина dzharnikov.
Ако е необходимо модулност, по мое мнение, че би било по-добре да се прекъсне вашата кандидатура в mikroservisy и да започне всеки в отделна JVM / контейнер, както се прави в момента. Единственият сценарий, който идва на ум - платформа за различни приложения и deploya mikroservisov с различен цикъл на развитие. Нещо като ESB и AppServer. В действителност, има той osnosnom и се използва.

Въпросът за това какво е по-добре, контейнер или купчина mikroservisov - той е велик и заслужава отделна статия. Аз отдавна исках да го напиша, но тя все още се нуждае обсъждане.

В моя случай, това не е приложение, но набор от модули един до друг относително независими. Всеки в отделен контейнер? И за какво? Е, това е е риторичен въпрос, аз вече знам за какво - аз просто искам да се отбележи, че не винаги в името на това нещо mikroservisy има място в живота.

Да, съгласен съм. В този случай, OSGi наистина помага като единна платформа за deploya ако има голям брой повече или по-малко независими модули.

Самият аз не съм голям фен на контейнери и mikroservisov защото самата Java вече изградена добра виртуализация. Контейнери значително усложняват архитектурата и разгръщане, и трябва да се прилагат само когато това е наистина необходимо, а не режим на разговор. Той също така няма смисъл да се разделя изкуствено до прилагането на mikroservisy ако той обединени функционалност и цикъл на развитие.

И да, това е, като цяло, е ESB (Bus). Т.е. развитие цикли са много различни, и заедно те никога не deployatsya, а в една и съща версия, 10% в най-добрия.

О, и между другото, един въпрос: какво е все още по-добре да бъде разделен на mikroservisy? Е, по-добре да не се счупи, ще се опитам да формулирам:

* Централизирано конфигурация (например 100 единици имат сметки за около 20 различни бази данни, както и в случай на mikroservisov аз ще трябва да се коригира URL / вход
парола в 20 различни неясни места, и така те са на едно място.
* Централизирано наблюдение (по един екземпляр от JMX и един Hawtio конзола, която показва всички).
* Монтаж и управление от едно място
* Един набор от портове, стърчат, всички десетки уеб услуги / почивка. Или по-скоро, един порт и един HTTP HTTPS. И още един набор от сертификати на едно място.
* Аз подчертаха всички услуги, казват 16Gb, и те живеят там, защото те консумират памет обикновено по различно време и по различни начини. Не е фактът, че беше добро, но все пак - 100 отделни JVM ще трябва да настроите параметрите за всеки.

> От гледна точка на deploya по-добре от да има един артефакт, а не купчина dzharnikov.

Между другото, за karaf артефакт - той се включва функция (виж по-горе, с една и съща длъжност.) С други думи - Този XML зависимости.

Т.е. karaf просто да deploit като тук определя буркан-ите, свързани помежду си с друг. Например, можете да напишете, че имате нужда от функция «пролетно-JMS», например, който е инсталиран заедно с устройството, и плъзнете с транзитни зависимости. Ами напишете като Maven, само в Времетраене OSGi. И това е така, между другото, от pom.xml използване karaf Maven плъгин, без усилие.

Така че от гледна точка на deploya karaf на ... за него съвсем не е грижа.