Mikroszolgáltatások az Oracle Helidonnal

1. Áttekintés

A Helidon az új Java mikroszolgáltatási keretrendszer, amelyet az utóbbi időben nyitott meg az Oracle. Belsőleg használták az Oracle projektekben J4C (Java for Cloud) néven.

Ebben az oktatóanyagban kitérünk a keretrendszer fő koncepcióira, majd elmozdulunk egy Helidon alapú mikroszolgáltatás felépítéséhez és futtatásához.

2. Programozási modell

Jelenleg a keretrendszer két programozási modellt támogat a mikroszolgáltatások írásához: Helidon SE és Helidon MP.

Míg a Helidon SE úgy lett kialakítva, hogy a reaktív programozási modellt támogató mikrokeret legyen, addig a Helidon MP viszont egy Eclipse MicroProfile futásidejű, amely lehetővé teszi a Jakarta EE közösség számára, hogy a mikroszolgáltatásokat hordozható módon futtassa.

Mindkét esetben a Helidon mikroszolgáltatás egy Java SE alkalmazás, amely egy ónos HTTP szervert indít el a fő módszerből.

3. Helidon SE

Ebben a részben részletesebben felfedezzük a Helidon SE fő összetevőit: WebServer, Config és Security.

3.1. A WebServer beállítása

Kezdeni a WebServer API, hozzá kell adnunk a szükséges Maven-függőséget a pom.xml fájl:

 io.helidon.webserver helidon-webszerver 0.10.4 

Egyszerű webalkalmazáshoz a következő készítő módszerek egyikét használhatjuk: WebServer.create (serverConfig, útválasztás) vagy csak WebServer.create (útválasztás). Az utolsó egy alapértelmezett szerverkonfigurációt tesz lehetővé, amely lehetővé teszi a szerver véletlenszerű porton történő futtatását.

Itt van egy egyszerű webalkalmazás, amely egy előre meghatározott porton fut. Regisztráltunk egy egyszerű kezelőt is, amely üdvözlő üzenettel válaszol minden HTTP-kérelemre a „/üdvözöl' út és KAP Módszer:

public static void main (String ... args) dobja a Kivételt {ServerConfiguration serverConfig = ServerConfiguration.builder () .port (9001) .build (); Routing routing = Routing.builder () .get ("/ greet", (request, response) -> response.send ("Hello World!")). Build (); WebServer.create (serverConfig, routing) .start () .thenAccept (ws -> System.out.println ("A kiszolgáló itt kezdődött: // localhost:" + ws.port ())); }

Az utolsó sor a szerver indítása és a HTTP kérések kiszolgálásának megvárása. De ha ezt a mintakódot futtatjuk a fő módszerben, akkor a hibát kapjuk:

Kivétel a "main" szálban java.lang.IllegalStateException: Nem található implementáció az SPI-hez: io.helidon.webserver.spi.WebServerFactory

A Web szerver valójában egy SPI, és futásidejű megvalósítást kell biztosítanunk. Jelenleg Helidon biztosítja a NettyWebServer végrehajtás amely a Netty Core-ra épül.

Itt van a megvalósítás Maven-függősége:

 io.helidon.webserver helidon-webserver-netty 0.10.4 futásidejű 

Most futtathatjuk a fő alkalmazást és ellenőrizhetjük, hogy működik-e a konfigurált végpont meghívásával:

// localhost: 9001 / üdvözlet

Ebben a példában mind a portot, mind az elérési utat az építő mintával konfiguráltuk.

A Helidon SE lehetővé teszi egy konfigurációs minta használatát is, ahol a konfigurációs adatokat a Konfig API. Ez a következő szakasz tárgya.

3.2. A Konfig API

A Konfig Az API eszközöket kínál a konfigurációs adatok kiolvasásához egy konfigurációs forrásból.

A Helidon SE számos konfigurációs forrás megvalósítását biztosítja. Az alapértelmezett megvalósítást a helidon-config ahol a konfigurációs forrás egy alkalmazás.tulajdonságok az osztályútvonal alatt található fájl:

 io.helidon.config helidon-config 0.10.4 

A konfigurációs adatok kiolvasásához csak az alapértelmezett készítőt kell használnunk, amely alapértelmezés szerint a konfigurációs adatokat veszi fel application.properties:

Config config = Config.builder (). Build ();

Hozzunk létre egy alkalmazás.tulajdonságok fájl a src / main / resource könyvtár a következő tartalommal:

server.port = 9080 web.debug = true web.page-size = 15 user.home = C: / Felhasználók / alkalmazás

Az értékek kiolvasásához használhatjuk a Config.get () módszer majd kényelmes átküldés a megfelelő Java típusokra:

int port = config.get ("server.port"). asInt (); int pageSize = config.get ("web.page-size"). asInt (); logikai hibakeresés = config.get ("web.debug"). asBoolean (); Karakterlánc userHome = config.get ("user.home"). AsString ();

Valójában az alapértelmezett készítő az első megtalált fájlt ebben a prioritási sorrendben tölti be: application.yaml, application.conf, application.json és application.properties. Az utolsó három formátumnak további kapcsolódó konfigurációs függőségre van szüksége. Például a YAML formátum használatához hozzá kell adnunk a kapcsolódó YAML konfigurációs függőséget:

 io.helidon.config helidon-config-yaml 0.10.4 

És akkor hozzáadunk egy alkalmazás.yml:

szerver: port: 9080 web: debug: true page-size: 15 user: home: C: / Users / app

Hasonlóképpen, a CONF, azaz JSON egyszerűsített formátum, vagy JSON formátumok használatához hozzá kell adnunk a helidon-config-hocon függőséget.

Vegye figyelembe, hogy ezekben a fájlokban a konfigurációs adatokat felülírhatják a környezeti változók és a Java rendszer tulajdonságai.

Szabályozhatjuk az alapértelmezett készítői viselkedést is a környezeti változó és a rendszer tulajdonságainak letiltásával vagy a konfigurációs forrás egyértelmű megadásával:

ConfigSource configSource = ConfigSources.classpath ("application.yaml"). Build (); Config config = Config.builder () .disableSystemPropertiesSource () .disableEnvironmentVariablesSource () .sources (configSource) .build ();

Amellett, hogy a konfigurációs adatokat leolvassuk az osztályútról, használhatunk két külső forráskonfigurációt is, vagyis a git és az etcd konfigurációkat. Ehhez szükségünk van a helidon-config-git és a helidon-git-etcd függőségekre.

Végül, ha mindezek a konfigurációs források nem elégítik ki igényünket, a Helidon lehetővé teszi számunkra, hogy megvalósítást biztosítsunk a konfigurációs forrásunkhoz. Például olyan megvalósítást nyújthatunk, amely kiolvassa a konfigurációs adatokat egy adatbázisból.

3.3. A útvonalválasztás API

A útvonalválasztás Az API biztosítja azt a mechanizmust, amellyel a HTTP kéréseket a Java módszerekhez kötjük. Ezt úgy érhetjük el, hogy a kérés metódusát és elérési útját használjuk egyező kritériumként vagy a RequestPredicate objektum további kritériumok használatára.

Tehát az útvonal konfigurálásához csak a HTTP metódust használhatjuk kritériumként:

Routing routing = Routing.builder () .get ((kérés, válasz) -> {});

Vagy kombinálhatjuk a HTTP metódust a kérés elérési útjával:

Routing routing = Routing.builder () .get ("/ path", (kérés, válasz) -> {});

Használhatjuk a RequestPredicate a nagyobb ellenőrzés érdekében. Például ellenőrizhetünk meglévő fejlécet vagy tartalomtípust:

Routing routing = Routing.builder () .post ("/ save", RequestPredicate.whenRequest () .containsHeader ("header1") .containsCookie ("cookie1") .accepts (MediaType.APPLICATION_JSON) .containsQueryParameter ("param1"). hasContentType ("application / json") .thenApply ((kérés, válasz) -> {}). Egyébként ((kérés, válasz) -> {})) .build ();

Eddig funkcionális stílusban láttuk el a kezelőket. Használhatjuk a Szolgáltatás osztály, amely kifinomultabb formában teszi lehetővé az írókezelőket.

Tehát először hozzunk létre egy modellt az objektumhoz, amellyel dolgozunk, a Könyv osztály:

public class Könyv {private String id; privát karakterlánc neve; magánhúr-szerző; privát egész oldalak; // ...}

Hozhatunk létre REST szolgáltatásokat a Könyv osztály megvalósításával Service.update () módszer. Ez lehetővé teszi ugyanazon erőforrás alútjainak konfigurálását:

public class BookResource megvalósítja a {private BookManager bookManager = new BookManager () szolgáltatást; @Orride public void update (Routing.Rules rules) {rules .get ("/", this :: books) .get ("/ {id}", this :: bookById); } private void bookById (ServerRequest serverRequest, ServerResponse serverResponse) {String id = serverRequest.path (). param ("id"); Könyvkönyv = bookManager.get (id); JsonObject jsonObject = from (könyv); serverResponse.send (jsonObject); } private void books (ServerRequest serverRequest, ServerResponse serverResponse) {Könyvek listája = bookManager.getAll (); JsonArray jsonArray = from (könyvek); serverResponse.send (jsonArray); } // ...}

A médiatípust JSON-nak is konfiguráltuk, ezért erre a célra szükségünk van a helidon-webserver-json függőségre:

 io.helidon.webserver helidon-webserver-json 0.10.4 

Végül, használjuk a Regisztráció() módszere útvonalválasztás a gyökér elérési útját az erőforráshoz. Ebben az esetben, Útvonalak A szolgáltatás által konfigurált előtagok a gyökér elérési útja:

Útválasztási útválasztás = Routing.builder () .register (JsonSupport.get ()) .register ("/ books", new BookResource ()) .build ();

Most elindíthatjuk a kiszolgálót, és ellenőrizhetjük a végpontokat:

// localhost: 9080 / books // localhost: 9080 / books / 0001-201810

3.4. Biztonság

Ebben a részben, az erőforrásainkat a Biztonsági modul segítségével fogjuk biztosítani.

Kezdjük az összes szükséges függőség deklarálásával:

 io.helidon.security helidon-security 0.10.4 io.helidon.security helidon-security-szolgáltató-http-auth 0.10.4 io.helidon.security helidon-security -integration-webszerver 0.10.4 

A helidon-security, a helidon-security-szolgáltató-http-auth és a helidon-security -integration-webszerver függőségek a Maven Central webhelyén érhetők el.

A biztonsági modul számos szolgáltató számára kínál hitelesítést és hitelesítést. Ebben a példában a HTTP alap hitelesítés szolgáltatót fogjuk használni mivel meglehetősen egyszerű, de a többi szolgáltató folyamata szinte ugyanaz.

Az első tennivaló a létrehozása Biztonság példa. Az egyszerűség kedvéért akár programszerűen is megtehetjük:

Map users = // ... UserStore store = user -> Optional.ofNullable (users.get (user)); HttpBasicAuthProvider httpBasicAuthProvider = HttpBasicAuthProvider.builder () .realm ("myRealm") .subjectType (SubjectType.USER) .userStore (store) .build (); Biztonsági biztonság = Security.builder () .addAuthenticationProvider (httpBasicAuthProvider) .build ();

Vagy használhatunk konfigurációs megközelítést.

Ebben az esetben az összes biztonsági konfigurációt deklaráljuk a alkalmazás.yml fájl, amelyet a Konfig API:

#Config 4 Security ==> Biztonsági objektumok biztonsága: szolgáltatók: - http-basic-auth: realm: "helidon" fő típus: USER # Lehet USER vagy SERVICE, alapértelmezettként USER felhasználók: - login: "user" jelszó: "felhasználói" szerepkörök: ["ROLE_USER"] - bejelentkezés: "rendszergazda" jelszó: "rendszergazda" szerepkörök: ["ROLE_USER", "ROLE_ADMIN"] #Config 4 biztonsági webkiszolgáló integráció ==> Átalakítva a WebSecurity Object web- szerver: securityDefaults: hitelesítés: true paths: - elérési út: "/ user" módszerek: ["get"] szerepkörök engedélyezve: ["ROLE_USER", "ROLE_ADMIN"] - elérési út: "/ admin" módszerek: ["get"] szerepkörök engedélyezve: ["ROLE_ADMIN"]

A betöltéshez pedig csak létre kell hoznunk a Konfig objektumot, majd meghívjuk a Security.fromConfig () módszer:

Config config = Config.create (); Biztonsági biztonság = Security.fromConfig (config);

Ha megvan a Biztonság például először regisztrálnunk kell a Web szerver használni a WebSecurity.from () módszer:

Útválasztási útválasztás = Routing.builder () .register (WebSecurity.from (security) .securityDefaults (WebSecurity.authenticate ())) .build ();

Hozhatunk létre a Webbiztonság példány közvetlenül a config megközelítéssel, amellyel mind a biztonságot, mind a webkiszolgáló konfigurációját betöltjük:

Routing routing = Routing.builder () .register (WebSecurity.from (config)) .build ();

Most hozzáadhatunk néhány kezelőt a / felhasználó és / admin elérési utakat, indítsa el a szervert, és próbálja meg elérni őket:

Routing routing = Routing.builder () .register (WebSecurity.from (config)) .get ("/ user", (kérés, válasz) -> response.send ("Hello, Helidon SE vagyok") .get ("/ admin", (kérés, válasz) -> response.send ("Hello, Helidon SE vagyok")) .build ();

4. Helidon képviselő

A Helidon MP az Eclipse MicroProfile megvalósítása és futásidőt is biztosít a MicroProfile alapú mikroszolgáltatások futtatásához.

Mivel már van cikkünk az Eclipse MicroProfile-ról, megnézzük ezt a forráskódot és módosítjuk, hogy a Helidon MP-n fusson.

A kód ellenőrzése után eltávolítjuk az összes függőséget és beépülő modult, és hozzáadjuk a Helidon MP függőségeket a POM fájlhoz:

 io.helidon.microprofile.csomagok helidon-microprofile-1.2 0.10.4 org.glassfish.jersey.media jersey-media-json-binding 2.26 

A helidon-mikroprofil-1.2 és a mez-media-json-kötés függőségek a Maven Central-tól kaphatók.

Következő, hozzáadjuk a bab.xml fájl a src / main / resource / META-INF Könyvtár ezzel a tartalommal:

Ban,-ben LibraryApplication osztály, felülírja getClasses () metódust, hogy a szerver ne keressen erőforrásokat:

@Orride public Set getClasses () {return CollectionsHelper.setOf (BookEndpoint.class); }

Végül hozzon létre egy fő módszert, és adja hozzá ezt a kódrészletet:

public static void main (String ... args) {Kiszolgáló szerver = Kiszolgáló.építő () .addApplication (Könyvtáralkalmazás.osztály) .port (9080) .build (); server.start (); }

És ez az. Mostantól képesek leszünk felhasználni az összes könyvforrást.

5. Következtetés

Ebben a cikkben feltártuk a Helidon fő összetevőit, bemutatva a Helidon SE és az MP beállításának módját is. Mivel a Helidon MP csak egy Eclipse MicroProfile futtatókörnyezet, bármilyen meglévő MicroProfile alapú mikroszolgáltatást futtathatunk vele.

Mint mindig, az összes fenti példa kódja megtalálható a GitHubon.


$config[zx-auto] not found$config[zx-overlay] not found