streamalism.org

1. Áttekintés

Ebben az oktatóanyagban megértjük a tizenkét faktoros alkalmazásmódszertant.

Megértjük azt is, hogyan lehet mikroszolgáltatást fejleszteni a Spring Boot segítségével. A folyamat során meglátjuk, hogyan kell alkalmazni a tizenkét faktoros módszertant egy ilyen mikroszolgáltatás fejlesztésére.

2. Mi a tizenkét faktoros módszertan?

A tizenkét tényezős módszertan tizenkét legjobb gyakorlat összessége a szolgáltatásként kifejlesztett alkalmazások fejlesztésére. Ezt eredetileg a Heroku tervezte a felhőalapú szolgáltatásként szolgáltatásként telepített alkalmazások számára, még 2011-ben. Idővel ez elég általánosnak bizonyult minden szoftver-szolgáltatásként (SaaS) fejlesztéshez.

Tehát mit értünk szoftver-szolgáltatásként? Hagyományosan szoftveres megoldásokat tervezünk, fejlesztünk, telepítünk és tartunk fenn, hogy üzleti értéket nyerjünk belőle. De nem kell részt vennünk ebben a folyamatban, hogy szükségképpen ugyanazt az eredményt érjük el. Például az alkalmazandó adó kiszámítása számos területen általános funkció.

Most dönthetünk úgy, hogy felépítjük és kezeljük ezt a szolgáltatást feliratkozni egy kereskedelmi szolgáltatási ajánlatra. Ilyen a szolgáltatás-kínálat az, amit szoftver-szolgáltatásként ismerünk.

Míg a szoftver-szolgáltatásként semmilyen korlátozást nem szab az általa kifejlesztett architektúrára; nagyon hasznos néhány bevált gyakorlatot alkalmazni.

Ha szoftverünket modulárisnak, hordozhatónak és a modern felhőalapú platformokon méretezhetőnek tervezzük, akkor ez szolgáltatásainknak nagyon megfelel. Ebben segít a tizenkét faktoros módszertan. A későbbiekben az oktatóanyagban látni fogjuk őket.

3. Mikroszolgáltatás rugós csomagtartóval

A Microservice építészeti stílus a szoftverek, mint lazán összekapcsolt szolgáltatások kifejlesztésére. A legfontosabb követelmény itt az, hogy a szolgáltatásokat az üzleti területek határai köré kell szervezni. Ezt gyakran a legnehezebb azonosítani.

Ezenkívül egy itteni szolgáltatás kizárólagos hatáskörrel rendelkezik az adatai felett, és a műveleteket más szolgáltatásoknak teszi ki. A szolgáltatások közötti kommunikáció általában könnyű protokollokon, például HTTP-n keresztül zajlik. Ez önállóan telepíthető és méretezhető szolgáltatásokat eredményez.

Most a mikroszolgáltatás architektúrája és a szoftver-mint-szolgáltatás nem függ egymástól. De ezt nem nehéz megérteni, mikor a szoftver-szolgáltatás fejlesztése, a mikroszolgáltatás architektúrájának kihasználása meglehetősen előnyös. Ez segít sok olyan cél elérésében, amelyet korábban megbeszéltünk, például a modularitás és a skálázhatóság.

A Spring Boot egy Spring-en alapuló alkalmazás-keretrendszer, amely sok vállalati alkalmazás fejlesztésével járó kazánt vesz el. Ez egy nagy véleményű, de rugalmas platformot nyújt számunkra a mikroszolgáltatások fejlesztésére. Ehhez az oktatóanyaghoz felhasználjuk a Spring Boot programot, hogy mikroszolgáltatást nyújtsunk a tizenkét faktoros módszer segítségével.

4. Tizenkét faktoros módszertan alkalmazása

Most definiáljunk egy egyszerű alkalmazást, amelyet megpróbálunk fejleszteni az imént tárgyalt eszközökkel és gyakorlatokkal. Mindannyian szeretjük a filmnézést, de kihívást jelent nyomon követni a már megnézett filmeket.

Most ki szeretne filmet indítani, majd később elhagyni? Amire szükségünk van, az egy egyszerű szolgáltatás a nézett filmek rögzítésére és lekérdezésére:

Ez meglehetősen egyszerű és szabványos mikroszolgáltatás adattárral és REST végpontokkal. Meg kell határoznunk egy modellt, amely a kitartást is feltérképezi:

@Entity public class Movie {@Id private Long id; privát húr cím; magán String év; privát String minősítés; // szerelők és beállítók}

Meghatároztunk egy JPA entitást azonosítóval és néhány egyéb attribútummal. Most nézzük meg, hogy néz ki a REST vezérlő:

@RestController public class MovieController {@Autowired private MovieRepository movieRepository; @GetMapping ("/ movies") public list retrieveAllStudents () {return movieRepository.findAll (); } @GetMapping ("/ movies / {id}") public Movie retrieveStudent (@PathVariable Long id) {return movieRepository.findById (id) .get (); } @ PostMapping ("/ filmek") public Hosszú createStudent (@RequestBody Movie movie) {return movieRepository.save (movie) .getId (); }}

Ez lefedi egyszerű szolgáltatásunk alapját. Végigmegyünk az alkalmazás többi részén, amikor megvitatjuk, hogyan valósítjuk meg a tizenkét faktoros módszertant a következő alfejezetekben.

4.1. Codebase

A tizenkét faktoros alkalmazások első bevált gyakorlata az, hogy nyomon követik azt egy verziókezelő rendszerben. A Git a legnépszerűbb verzióvezérlő rendszer, amelyet ma használnak, és szinte mindenütt jelen van. Az elv kimondja, hogy egy alkalmazást egyetlen kódtárban kell követni, és azt nem szabad megosztani más alkalmazásokkal.

A Spring Boot számos kényelmes módot kínál egy alkalmazás indításához, beleértve a parancssori eszközt és a webes felületet. Miután létrehoztuk a bootstrap alkalmazást, ezt konvertálhatjuk git tárolóvá:

git init

Ezt a parancsot az alkalmazás gyökérzetéből kell futtatni. Az alkalmazás ebben a szakaszban már tartalmaz egy .gitignore fájlt, amely hatékonyan korlátozza a generált fájlok verzió-vezérlését. Tehát azonnal létrehozhatunk egy kezdeti elkötelezettséget:

git add. git comm -m "Az alkalmazás bootstrapjának hozzáadása."

Végül felvehetünk egy távvezérlőt, és ha akarjuk, a távvezérlő felé tolhatjuk el az elkötelezettségünket (ez nem szigorú követelmény):

git remote add origin //github.com//12-factor-app.git git push -u origó mester

4.2. Függőségek

Ezután a a tizenkét faktoros alkalmazásnak mindig kifejezetten nyilatkoznia kell minden függőségéről. Ezt egy függőségi nyilatkozat használatával kell megtenni. A Java több függőségkezelő eszközzel rendelkezik, mint például a Maven és a Gradle. Az egyiket felhasználhatjuk e cél elérésére.

Tehát egyszerű alkalmazásunk néhány külső könyvtártól függ, például egy könyvtártól, amely megkönnyíti a REST API-kat és csatlakozik egy adatbázishoz. Nézzük meg, hogyan definiálhatjuk őket deklaratívan Maven használatával.

Maven megköveteli, hogy írjuk le a projekt függőségeit egy XML fájlban, amelyet általában Project Object Model (POM) néven ismerünk:

  org.springframework.boot spring-boot-starter-web com.h2database h2 futásidejű 

Bár ez egyszerűnek és egyszerűnek tűnik, ezeknek a függőségeknek általában más transzitív függőségeik is vannak. Ez bizonyos mértékben bonyolítja, de segít elérni célunkat. Az alkalmazásunknak nincs közvetlen függősége, amelyet nem írtak le kifejezetten.

4.3. Konfigurációk

Egy alkalmazás általában sok konfigurációval rendelkezik, amelyek némelyike ​​telepítésenként változhat, míg mások változatlanok maradnak.

Példánkban van egy állandó adatbázisunk. A csatlakozáshoz szükségünk lesz az adatbázis címére és hitelesítő adataira. Ez nagy valószínűséggel változik a telepítések között.

Egy tizenkét tényezővel rendelkező alkalmazásnak ki kell küldenie az összes olyan konfigurációt, amely a telepítésenként eltérő lehet. Az ajánlás a környezeti változók használata az ilyen konfigurációkhoz. Ez a konfiguráció és a kód tiszta elválasztásához vezet.

A Spring egy konfigurációs fájlt biztosít, ahol deklarálhatjuk az ilyen konfigurációkat, és csatolhatjuk a környezeti változókhoz:

spring.datasource.url = jdbc: mysql: // $ {MYSQL_HOST}: $ {MYSQL_PORT} / filmek spring.datasource.username = $ {MYSQL_USER} spring.datasource.password = $ {MYSQL_PASSWORD}

Itt konfigurációként definiáltuk az adatbázis URL-jét és a hitelesítő adatait, és feltérképeztük a környezeti változóból kiválasztandó tényleges értékeket.

Windows rendszeren beállíthatjuk a környezeti változót az alkalmazás elindítása előtt:

set MYSQL_HOST = localhost set MYSQL_PORT = 3306 set MYSQL_USER = filmek set MYSQL_PASSWORD = jelszó

Használhatunk egy konfigurációkezelő eszközt, mint például az Ansible vagy a Chef a folyamat automatizálásához.

4.4. Támogatási szolgáltatások

A háttérszolgáltatások olyan szolgáltatások, amelyek működésétől függ az alkalmazás. Például egy adatbázis vagy egy üzenetközvetítő. A tizenkét faktoros alkalmazásnak az összes ilyen támogatási szolgáltatást csatolt erőforrásként kell kezelnie. Ez tulajdonképpen azt jelenti, hogy nem igényel semmilyen kódváltást egy kompatibilis háttérszolgáltatás cseréjéhez. Az egyetlen változás a konfigurációkban történhet.

Alkalmazásunkban a MySQL-t használtuk háttérszolgáltatásként a kitartás biztosítása érdekében.

A tavaszi JPA meglehetősen agnosztikussá teszi a kódot a tényleges adatbázis-szolgáltató számára. Csak egy olyan tárolót kell meghatároznunk, amely az összes szokásos műveletet biztosítja:

@Repository nyilvános felület A MovieRepository kiterjeszti a JpaRepository {}

Mint láthatjuk, ez nem függ közvetlenül a MySQL-től. Spring észleli a MySQL illesztőprogramot az osztályúton, és dinamikusan biztosítja a felület MySQL-specifikus megvalósítását. Ezenkívül más részleteket is közvetlenül kihúz a konfigurációkból.

Tehát, ha a MySQL-ről az Oracle-re kell váltanunk, akkor csak annyit kell tennünk, hogy kicseréljük az illesztőprogramot a függőségeinkben, és kicseréljük a konfigurációkat.

4.5. Építsd, engedd el és futtasd

A tizenkét faktoros módszertan szigorúan elkülöníti a kódbázis futó alkalmazássá történő átalakításának folyamatát három különálló szakaszként:

• Build szakasz: Itt vesszük meg a kódbázist, végezzünk statikus és dinamikus ellenőrzéseket, majd generálunk egy futtatható csomagot, mint egy JAR. Olyan eszközzel, mint a Maven, ez elég triviális:

 mvn tiszta fordító tesztcsomag

• Kiadási szakasz: Ebben a szakaszban vesszük a futtatható csomagot, és ezt kombináljuk a megfelelő konfigurációkkal. Itt használhatjuk a Packert egy olyan előkészítővel, mint az Ansible a Docker képek létrehozásához:

 packer build alkalmazás.json

• Futtatási szakasz: Végül ez az a szakasz, amikor az alkalmazást egy futtatási környezetben futtatjuk. Ha a Dockert tárolóként használjuk az alkalmazásunk kiadásához, az alkalmazás futtatása elég egyszerű lehet:

 docker run --name -it 

Végül nem feltétlenül kell manuálisan elvégeznünk ezeket a szakaszokat. Ez az a pont, ahol Jenkins nagyon hasznos a deklaratív csővezetékével.

4.6. Folyamatok

Egy tizenkét faktoros alkalmazás várhatóan hontalan folyamatként fut egy végrehajtási környezetben. Más szavakkal, nem tudják helyben tárolni a tartós állapotot a kérések között. Létrehozhatnak állandó adatokat, amelyeket egy vagy több állapotot támogató szolgáltatásban kell tárolni.

Példánk esetében több végpontot is kitettünk. Ezen végpontok bármelyikére vonatkozó kérés teljesen független az előtte benyújtott kérelmektől. Például, ha nyomon követjük a memóriában lévő felhasználói kéréseket, és ezeket az információkat a jövőbeni kérések kiszolgálására használjuk, akkor ez tizenkét tényezővel rendelkező alkalmazást sért.

Ezért egy tizenkét faktoros alkalmazás nem ír elő ilyen korlátozást, mint a ragadós munkamenetek. Ez egy ilyen alkalmazást nagyon hordozhatóvá és méretezhetővé tesz. Az automatizált méretezést kínáló felhőfuttatási környezetben ez az alkalmazások számára kívánatos viselkedés.

4.7. Port Kötés

A hagyományos webes Java alkalmazásokat WAR vagy webarchívumként fejlesztik ki. Ez általában függőségekkel rendelkező Servlet-gyűjtemény, és olyan megfelelő tároló futási időt vár, mint a Tomcat. Egy tizenkét faktoros alkalmazás éppen ellenkezőleg, nem számít ilyen futásidejű függőségre. Teljesen önálló, és csak olyan végrehajtási futást igényel, mint a Java.

Esetünkben kifejlesztettünk egy alkalmazást a Spring Boot segítségével. A Spring Boot, számos egyéb előnyön kívül, alapértelmezett beágyazott alkalmazásszervert biztosít számunkra. Ezért a korábban a Maven használatával létrehozott JAR teljes mértékben képes bármilyen környezetben végrehajtani, csak kompatibilis Java futási idővel:

java -jar alkalmazás.jar

Itt az egyszerű alkalmazásunk egy HTTP-összerendelésen keresztül teszi közzé végpontjait egy adott porthoz, például a 8080-hoz. Az alkalmazás elindításakor, ahogy fentebb tettük, lehetővé kell tenni az exportált szolgáltatások, például a HTTP elérését.

Egy alkalmazás több szolgáltatást is exportálhat, mint például az FTP vagy a WebSocket, több portra kötve.

4.8. Egyidejűség

Java kínál cérna klasszikus modellként az alkalmazás párhuzamosságának kezelésére. A szálak olyanok, mint a könnyű folyamatok, és a program több végrehajtási útvonalát képviselik. A szálak nagy teljesítményűek, de korlátozottak abban, hogy mennyiben segíthet az alkalmazás méretarányában.

A tizenkét faktoros módszertan azt javasolja az alkalmazásoknak, hogy támaszkodjanak a méretezés folyamataira. Ez gyakorlatilag azt jelenti, hogy az alkalmazásokat úgy kell megtervezni, hogy a munkaterhelést több folyamatra osszák szét. Az egyes folyamatok azonban szabadon felhasználhatják az egyidejűségi modellt cérna belsőleg.

A Java alkalmazás indításakor egyetlen folyamatot kap, amely az alapul szolgáló JVM-hez van kötve. Amire valójában szükségünk van, az alkalmazás több példányának elindítása intelligens terheléselosztással közöttük. Mivel alkalmazásunkat már Docker konténerként csomagoltuk, a Kubernetes természetes választás az ilyen hangszereléshez.

4.9. Eldobhatóság

Az alkalmazás folyamatait szándékosan vagy váratlan események révén le lehet állítani. Bármelyik esetben, egy tizenkét faktoros alkalmazás állítólag kecsesen kezeli. Más szavakkal, az alkalmazási folyamatnak teljesen eldobhatónak kell lennie, nem kívánt mellékhatások nélkül. Sőt, a folyamatoknak gyorsan meg kell kezdődniük

Például alkalmazásunkban az egyik végpont egy új adatbázis-rekord létrehozása egy film számára. Most egy ilyen kérést kezelő alkalmazás váratlanul összeomolhat. Ez azonban nem befolyásolhatja az alkalmazás állapotát. Amikor egy ügyfél újra elküldi ugyanazt a kérést, akkor az nem eredményezhet ismétlődő rekordokat.

Összefoglalva: az alkalmazásnak ki kell tárnia az idempotens szolgáltatásokat. Ez egy másik nagyon kívánatos attribútum a felhőalapú telepítésekre szánt szolgáltatás számára. Ez rugalmasságot biztosít az új szolgáltatások bármikor történő leállításához, áthelyezéséhez vagy megpörgetéséhez minden más szempont nélkül.

4.10. Dev / Prod paritás

Jellemző az alkalmazásokra, amelyeket helyi gépeken fejlesztenek ki, más környezetben tesztelnek és végül a gyártásba telepítenek. Gyakran előfordul, hogy ezek a környezetek eltérőek. Például a fejlesztői csapat Windows gépeken dolgozik, míg a gyártási telepítés Linux gépeken történik.

A tizenkét faktoros módszertan azt javasolja, hogy a fejlesztési és a termelési környezet közötti szakadék a lehető legkisebb legyen. Ezek a hiányosságok hosszú fejlesztési ciklusokból, különböző érintett csapatokból vagy különböző technológiai halmazokból származhatnak.

Most az olyan technológia, mint a Spring Boot és a Docker, automatikusan nagy mértékben áthidalja ezt a különbséget. Egy konténeres alkalmazás várhatóan ugyanúgy fog viselkedni, függetlenül attól, hogy hol futtatjuk. Ugyanazokat a támogatási szolgáltatásokat kell használnunk - például az adatbázist.

Ezenfelül megfelelő folyamatokkal kell rendelkeznünk, például folyamatos integrációval és megvalósítással, hogy megkönnyítsük ennek a hiánynak az áthidalását.

4.11. Naplók

A naplók alapvető adatok, amelyeket egy alkalmazás az élettartama során generál. Felbecsülhetetlen betekintést nyújtanak az alkalmazás működésébe. Általában egy alkalmazás több szinten készíthet naplókat, különböző részletekkel, és az ii kimenetet több különböző formátumban.

Egy tizenkét faktoros alkalmazás azonban elválasztja magát a napló létrehozásától és annak feldolgozásától. Egy ilyen alkalmazás esetében a naplók nem más, mint egy időben rendezett eseményfolyam. Ezeket az eseményeket csupán a végrehajtási környezet szabványos kimenetébe írja. Az ilyen adatfolyam rögzítését, tárolását, kezelését és archiválását a végrehajtási környezetnek kell kezelnie.

Számos eszköz áll rendelkezésünkre erre a célra. Először is, az SLF4J segítségével absztrakt módon kezelhetjük a naplózást az alkalmazásunkon belül. Ezenkívül olyan eszközzel is használhatjuk a Fluentd-t, hogy összegyűjtsük a naplók adatfolyamát az alkalmazásokból és a támogatási szolgáltatásokból.

Ezt betáplálhatjuk az Elasticsearch-be tárolás és indexelés céljából. Végül értelmes irányítópultokat generálhatunk a megjelenítéshez Kibanában.

4.12. Adminisztrációs folyamatok

Gyakran el kell végeznünk néhány egyszeri feladatot vagy rutineljárást az alkalmazás állapotával. Például a rossz rekordok javítása. Most különféle módokon érhetjük el ezt. Mivel nem biztos, hogy gyakran szükségünk van rá, írhatunk egy kis parancsfájlt, hogy külön futtassuk egy másik környezettől.

Most, a tizenkét faktoros módszertan határozottan azt javasolja, hogy az ilyen rendszergazdai parancsfájlokat az alkalmazás kódbázisával együtt tartsák meg. Ennek során ugyanazokat az elveket kell követnie, mint amelyeket a fő alkalmazáskódra alkalmazunk. Az ilyen szkriptek futtatásához termelési kiszolgálókon is célszerű a végrehajtási környezet beépített REPL eszközét használni.

Példánkban hogyan vetjük be az alkalmazásunkat az eddig már megnézett filmekkel? Bár használhatjuk édes kis végpontunkat, de ez praktikának tűnhet. Amire szükségünk van, az egyszeri betöltéshez szkript. Írhatunk egy kis Java-függvényt, amellyel felolvashatjuk a filmek listáját egy fájlból, és kötegenként elmenthetjük az adatbázisba.

Ezenkívül használhatjuk a Java futásidejével integrált Groovyt az ilyen folyamatok elindításához.

5. Gyakorlati alkalmazások

Tehát most megláttuk a tizenkét faktoros módszertan által javasolt összes tényezőt. Alkalmazás fejlesztése a a tizenkét tényezőből álló alkalmazásnak minden bizonnyal megvannak a maga előnyei, különösen, ha szolgáltatásként szeretnénk őket telepíteni a felhőbe. De, mint minden más irányelvnek, keretnek, mintának, meg kell kérdeznünk, ez ez a golyó?

Őszintén szólva a szoftver tervezésében és fejlesztésében egyetlen módszer sem állítja, hogy ezüst golyó lenne. A tizenkét faktoros módszertan nem kivétel. Míg e tényezők egy része meglehetősen intuitívés valószínűleg már csináljuk őket, mások nem vonatkozhatnak ránk. Elengedhetetlen, hogy ezeket a tényezőket célkitűzéseink hátterében értékeljük, majd okosan válasszunk.

Fontos megjegyezni, hogy mindezek a tényezők igen segítségünkre van egy moduláris, független, hordozható, méretezhető és megfigyelhető alkalmazás fejlesztésében. Az alkalmazástól függően más eszközökkel is jobban elérhetjük ezeket. Nem szükséges az összes tényező együttes elfogadása, ezek közül néhány elfogadásával jobbak lehetünk, mint voltunk.

Végül ezek a tényezők meglehetősen egyszerűek és elegánsak. Nagyobb jelentőséget tulajdonítanak egy olyan korban, amikor azt követeljük, hogy alkalmazásaink nagyobb áteresztőképességűek és alacsonyabb késleltetésűek legyenek, gyakorlatilag leállás és meghibásodás nélkül. Ezeknek a tényezőknek az elfogadása a kezdetektől megfelelő kezdetet nyújt. Mikroszolgáltatási architektúrával és az alkalmazások tárolásával együtt úgy tűnik, hogy csak a megfelelő helyre jutnak.

6. Következtetés

Ebben az oktatóanyagban áttekintettük a tizenkét faktoros módszertan fogalmait. Megbeszéltük, hogyan lehet kihasználni a mikroszolgáltatási architektúrát a Spring Boot segítségével a hatékony szállítás érdekében. Továbbá részletesen megvizsgáltuk az egyes tényezőket és az alkalmazásunkra való alkalmazás módját. Több eszközt is feltártunk ezen egyedi tényezők hatékony, eredményes alkalmazásához.