Moduláris alkalmazások java
Moduláris alkalmazások Java. Hogyan? 1
- 24.03.17 02:54 •
- jetinfosystems •
- • # 324810
- • Habrahabr
- 42 •
- 3800
- mint a Forbes, csak jobb.
OSGi a mentő
Ahhoz, hogy hozzon létre egy valóban moduláris felépítésű Java használhatja az OSGi (Open Services Gateway Initiative) - dinamikus modul rendszer specifikációja és szolgáltatási platform Java-alapú alkalmazások (OSGi Alliance Developer). Leírja a modell a szoftverfejlesztés, amelyben a komponensek három alapvető jellemzője a moduláris alkalmazás. Beszél a tokozás (minden modul elrejti annak végrehajtását a külső környezet), a rossz kapcsolat (modulok kölcsönhatásba csak a segítségével előre megkötött szerződések) és dinamikus (komponensek lehet cserélni menet közben megállás nélkül a teljes alkalmazás). A koncepció alapján az OSGi 2 szervezetek: készletek (csomagok) és a szolgáltatások (Services).
Szoftverfejlesztés Java, jellemzően harmadik fél könyvtárak. A Java-könyvtári világban vannak csomagolva kiterjesztésű fájlok JAR (Java Archive). közös ZIP-fájlt, amely tartalmazza a Java-osztály (.class kiterjesztésű fájlok). A könyvtárhasználati társítható bizonyos nehézségek.
Ha elkezdi használni minden könyvtárat, akkor inkább elérhetővé válik az összes osztály benne. A tény az, hogy a könyvtár a fejlesztők nem lehet elrejteni osztályok végrehajtására használják a belső logika. Így, ha ön használ egy kód, ami nem tervezett kívüli használatra a könyvtár, akkor találkozhat inkompatibilitás az új verzió a könyvtár, vagy megzavarják a helyes működés.
A másik probléma - az úgynevezett JAR pokol, amiről a fejlesztők törve a sok példányban. Ennek lényege a következő: ha egyszer elkezdi használni a különböző változatai ugyanabban a könyvtárban (ez történik a nagy projektek, amelyek idővel változhatnak), akkor szembe a tény, hogy egy és ugyanazon osztályba tartozó különböző módszereket a különböző változatai a könyvtárban. Java úgy van kialakítva, hogy az első változat a könyvtár, amely osztálybetöltője kerül felhasználásra. Így, utalva a kódot minden osztályban futási időben, akkor kap egy hiba, hogy az eljárás, amelyre utalnak, nem létezik. Ez annak a ténynek köszönhető, hogy a Java futtatási nem tudni semmit a könyvtár verzióját kell használni egy adott ügyben.
OSGi fejlesztők nem változott a szerkezet JAR-fájlok modularitás, és egyszerűen adjuk nekik további információkat, amelyekkel a OSGi környezetben. Sőt, ez az információ nem befolyásolja a használatát, a JAR-fájlt a szokásos Java-alkalmazások. Tehát, hogy a JAR-fájl vált OSGi-set, teszi hozzá adatok alapján határozza meg az Export-csomag (egy sor csomagok állnak rendelkezésre használható rajta kívül), valamint az Import-Package (táskák egyéb készletek ehhez szükséges készlet). Lehetőség van beállítva, mint egy API verzió, amely egy sor egyéb készletek, és a változat vagy tartomány API-verziók, amelyek egy sor igények munkájuk tőlük is. Minden sor osztályok, amelyek nem az export részén nem állnak rendelkezésre kívül meg (Private). Ily módon egy sor OSGi-felelnie a gyenge kapcsolat.
Ma a legtöbb Java-könyvtár már készen OSGi, azaz információt szolgáltat a lehetőségét, hogy a be-OSGi konténer. Ezen kívül sok eszközök és segédprogramok, amelyek segítségével modulok létrehozására irányuló OSGi rendes JAR-fájlokat.
A OSGi könnyen elkerülhető JAR Pokol helyzeteket, mert a kapcsolat a készletek és interfészek, amelyeket ezek a rendelkezések világos verziót. Dinamikusan és berakodása az új készlet futásidőben. OSGi pályák közötti függőségeket készletek és dinamikusan megoldja őket.
Tehát ha OSGi-készletek tudjuk fejleszteni a moduláris alkalmazások, amelyek kölcsönhatásba lépnek át (API). De hol, hogy egy osztály, amely megvalósítja a szükséges felület? Lehetőség, hogy „add meg az API-set” nem megfelelő - keretében a moduláris felépítés, már megállapodtak abban, hogy nem használja belső osztályok n kívül ezeket a csomagokat. Egy másik megoldás. alkalmazni a sablon „gyári” végrehajtása a felület és hozzá egy sor API-t. De ez nem túl sikeres, mert hogy elrejtse a végrehajtását egy felület lesz minden alkalommal, hogy dolgozzon ki egy új osztályt.
Keresés interfész megvalósítása az OSGi szolgáltatást a nyilvántartásba. Ez a nyilvántartás set regisztrálhat végrehajtás leírja a felületet. Set, amely egy felületet egy másik lehet találni a szükséges végrehajtását a kívánt felület azt a registry. Jellemzően a készlet voltak rögzítve Start szolgáltatások a OSGi-tartályba. Plus regisztrációs szolgáltatások lehet azonos regisztrált felületek különböző implementációk és további azonosító adatokat. A szűrők használata, a kit válassza ki a legmegfelelőbb a registry-ben a bemutatott szolgáltatásokat.
Mikroservisy Java Virtual Machine
Mikroservisnaya építészet egy sor független modulok - az egyes alkalmazások. A kölcsönhatás közöttük keresztül történik jól definiált interfészek könnyű protokoll (REST, protokollbufferekkel, MQ, stb.) Tény, hogy minden modul - ez mikroservis meghatározott feladatot teljesítő, és amely, mint általában, a minimális kódot. Az előnye ennek a megközelítésnek, hogy a szoftverfejlesztés:
- A világosság (fejlesztési mikroservisa már csak egy része a funkció a program).
- megkönnyítik a csere (ha a szolgáltatást nem végzi a dolgát, akkor átírható, és helyére egy új változata a szoftver megállás nélkül).
- újra (mikroservis lehet újra, ahol ez alkalmas).
A fejlesztők a moduláris alkalmazások OSGi régóta élvezte Mindezen előnyök, de csak a Java virtuális gép. Mindegyik készlet OSGi, amely közzéteszi a szolgáltatást a nyilvántartás, az mikroservisom belül a Java Virtual Machine, JVM (a világon a OSGi nevezik mikroservisy μServices).
Red Hat JBoss Fuse
Mi vagyunk a „Jet” használja az összes előnyeit OSGi szoftverfejlesztés a távközlési szolgáltatók, biztosítók, a feldolgozó vállalatok. Ahhoz, hogy ezt elérjük, a Red Hat JBoss Fuse (Fuse Fabric konfiguráció). Ez a platform egy rugalmas környezet OSGi teljesítményű moduláris alkalmazásokat.
Alkalmazásának folyamatosságát, könnyen méretezés, könnyű telepítés, a rendelkezésre álló klaszter menedzsment eszközök cluster szoftver - mindezek a funkciók elérhetők a Fuse szövet. A technológia lehetővé teszi, hogy telepíteni több példányát a Red Hat JBoss Fuse és összekapcsolják őket egy klaszter és központosított irányítási eszköz kapott környezetben.
Ennek része a Fuse Fabric, a következő absztrakció:
Jellemzők (jellemzők) - a készlet a OSGi-halmazt végre olyan funkcionalitást.
Profiles (profilok) - a szolgáltatásokhoz, amelyek el kell végezni egy tartályban, és konfigurációs beállításokat határozza meg, hogy szerepelnek a funkciót.
Konténerek (tartályok) - egyéni JVM-folyamatok futnak egy adott csomóponton klaszter Fuse Fabric Red Hat JBoss Fuse tartályba.
Bármely szoftver alapú biztosíték Fabric technológia abból áll, az OSGi-készletek, amelyek vannak csoportosítva funkciók és telepített részeként bármely egyedi, a JVM folyamat egy vagy több a fürt csomópontjai, összhangban egy előre meghatározott profilt.
Szerda Fuse Fabric számos eszközt könnyű kezelése a klaszterek kapunk. Profilokat hozhat létre (és ezek alapján. Konténerek), hozzon létre / törlés / start / stop a konténerek bármely host a fürt, csatlakoztassa az új csomópontok stb És ez az összes online - működésének megszakítása nélkül más a fürt csomópontjai. Ez lehet tárolni több változatát profilok, funkciók, OSGi-készletek.
Keresztül Elosztott OSGi technológia kapott közepes OSGi-készletek egymásra mind egyes, mind a különböző konténerek, sőt a különböző házigazdák. Extrák (minimális fejlesztési költségek), minden szolgáltatás, amely OSGi-set lehet alakítani REST / web-szolgáltatás, amelyet nevezhetünk külső rendszereket.
Így, a Fuse szövet, mi is létrehozhatunk mikroservisnuyu architektúra, amely elősegíti a könnyű konfigurációt és telepítését, az izolált szolgáltatások teljesítése belül JVM-folyamatok (specifikus beállítások, például, különböző beállításokat a szemétgyűjtő), a szolgáltatások kölcsönhatásba egymással hálózat segítségével egy könnyű protokoll.
mert Red Hat JBoss Fuse termék alapja a nyílt forráskódú technológia verem Apache ServiceMix, a rendelkezésünkre álló, vannak erős technológiák, mint például az Apache ActiveMQ (végrehajtása a JMS leírás), Apache Camel (végrehajtása Enterprise Integration Patterns), Apache CXF (könyvtár REST / webfejlesztés -Service), Blueprint (előírja függőség injekció képességek), Spring, stb Mivel ezek a technológiák zökkenőmentesen integrálható egymással Red Hat JBoss Fuse, ez jelentősen csökkenti a fejlesztési időt kívánt funkciókat.
Anyaga szakértők által készített, a központ szoftver megoldások „Jet Infosystems”.
De érdekes módon, ahogy az összes elindulnak devmode? Normál program build-pack telepíthető? Vagy egy plug-in kezelhető?
És nekem úgy tűnik, ez nem azt állította, moduláris alkalmazásokat. Belsőleg - igen, van értelme kód és a tesztet. De tekintve deploya jobb, ha van egy tárgy helyett egy halom dzharnikov.
Ha szükséges modularitás, véleményem, hogy jobb lenne, hogy megtörje az alkalmazás a mikroservisy és elkezd minden külön JVM / konténer, ahogy azt most. Az egyetlen forgatókönyv, ami eszébe jut - a platform a különböző alkalmazások és deploya mikroservisov különböző fejlesztési ciklusban. Olyasmi, mint ESB és AppServer. Tény, hogy ő osnosnom és használják.
Az a kérdés, hogy mi a jobb, a konténer vagy egy halom mikroservisov - ő egy nagy és megérdemel egy külön cikket. Én már régóta akartam írni, de még mindig szükség van mérlegelés.
Az én esetemben ez nem egy alkalmazás, hanem egy sor modulok egymáshoz viszonylag független. Mindegyik egy külön tartályban? És miért? Nos, ez egy költői kérdés, már tudom, amit - Csak azt szeretném megjegyezni, hogy nem mindig a kedvéért csinál valamit mikroservisy helye van az életben.
Igen, egyetértek. Ebben az esetben a OSGi sokat segít, mint egy egységes platform deploya ha van egy nagy számú, többé-kevésbé független modulokat.
Én magam nem vagyok nagy rajongója a konténerek és mikroservisov mert a Java önmagában már beépített jó a virtualizáció. Konténerek nagyon megnehezítené az építészet és telepíteni, és olyankor kell alkalmazni, csak ha szükség van rá, és nem hívási mód. Ugyancsak nincs értelme, hogy mesterségesen szét a kérelmet mikroservisy ha egységes funkcionalitást és fejlesztési ciklusban.
És igen, ez általában az ESB (busz). Ie fejlesztési ciklusok nagyon különböző, és együtt soha deployatsya, hanem az azonos kibocsátás 10 százaléka a legjobb.
Ja, és mellesleg a kérdés: mi még mindig jobb, hogy osztható mikroservisy? Nos, jobb, ha nem törik, megpróbálom megfogalmazni:
* Központi konfiguráció (például 100 egységek mennyisége körülbelül 20 különböző adatbázisokat, és abban az esetben, mikroservisov azt be kell állítani az url / bejelentkezés
jelszó 20 különböző homályos helyeken, és így egy helyen vannak.
* Központi felügyeleti (egy példányt a JMX, és egy Hawtio konzolt, amely megmutatja az összes).
* A telepítés és menedzsment egy helyen
* Egy sor port, kilóg minden tíz web / pihenés szolgáltatásokat. Vagy inkább egy portot és egy http https. És egy másik tanúsítványok egy helyen.
* Kiemeltem összes szolgáltatást mondjuk 16Gb, és ők élnek ott, mert az általuk fogyasztott memória általában különböző időpontokban és különböző módokon. Nem az a tény, hogy jó volt, de ennek ellenére - 100 különálló JVM kellene hangolni a paramétereket minden.
> Az szempontból deploya jobb, ha van egy tárgy helyett egy halom dzharnikov.
By the way, karaf ereklyét - ez többek között egy jellemző (lásd fent az azonos üzenet.) Más szóval - ez xml függőségeket.
Ie karaf egyszerűen deploit mint itt állítja jar-ok, az egymással. Például írhat, hogy szükség van olyan funkció «rugós JMS», például, amely telepítése mellett a készülék, és húzza a tranzitív függőségeket. Nos írja a Maven, csak a OSGi futás közben. És mégis, az úton, a pom.xml segítségével karaf maven plugin erőfeszítés nélkül.
Tehát a szempontból deploya karaf ... mert ez elég, nem érdekel.