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.