streamalism.org

1. Prehľad

V tomto tutoriáli pochopíme dvanásťfaktorovú metodológiu aplikácií.

Pochopíme tiež, ako vyvinúť mikroslužbu pomocou Spring Boot. V tomto procese uvidíme, ako uplatniť dvanásťfaktorovú metodiku na vývoj takejto mikroslužby.

2. Čo je metodológia dvanástich faktorov?

Dvanásťfaktorová metodika je súborom dvanástich najlepších postupov na vývoj aplikácií vyvinutých pre prevádzku ako služba. Pôvodne to spoločnosť Heroku navrhla pre aplikácie nasadené ako služby na ich cloudovej platforme ešte v roku 2011. Postupom času sa to ukázalo ako dostatočne všeobecné na akýkoľvek vývoj softvéru ako služby (SaaS).

Čo teda máme na mysli pod pojmom softvér ako služba? Tradične navrhujeme, vyvíjame, nasadzujeme a udržiavame softvérové ​​riešenia, aby sme z nich odvodili obchodnú hodnotu. Nemusíme sa však zapojiť do tohto procesu, aby sme nevyhnutne dosiahli rovnaký výsledok. Napríklad výpočet príslušnej dane je všeobecnou funkciou v mnohých doménach.

Teraz sa môžeme rozhodnúť, že si túto službu vybudujeme a spravujeme sami alebo prihlásiť sa na odber ponuky komerčných služieb. Taký ponuky služieb sú to, čo poznáme ako softvér ako služba.

Zatiaľ čo softvér ako služba nezavádza žiadne obmedzenia na architektúre, na ktorej je vyvinutý; je celkom užitočné prijať niektoré osvedčené postupy.

Ak navrhujeme náš softvér tak, aby bol modulárny, prenosný a škálovateľný na moderných cloudových platformách, je celkom vhodný pre naše ponuky služieb. Tu pomáha dvanásťfaktorová metodika. Uvidíme ich v akcii neskôr v tutoriále.

3. Mikroslužba s jarným zavádzaním

Microservice je architektonický štýl vyvíjajúci softvér ako voľne spojené služby. Kľúčovou požiadavkou je, aby: služby by mali byť organizované okolo hraníc obchodných domén. Toto je často najťažšie identifikovateľné.

Okrem toho má služba tu výlučné oprávnenie nad svojimi údajmi a vystavuje operácie iným službám. Komunikácia medzi službami je zvyčajne vedená cez ľahké protokoly, ako je HTTP. Výsledkom sú nezávisle nasaditeľné a škálovateľné služby.

Teraz nie sú architektúra mikroslužby a softvér ako služba navzájom závislé. Nie je však ťažké pochopiť, kedy vývoj softvéru ako služby, využitie architektúry mikroslužby je celkom prospešné. Pomáha dosiahnuť veľa cieľov, o ktorých sme už hovorili, ako napríklad modularita a škálovateľnosť.

Spring Boot je aplikačný rámec založený na Spring, ktorý odoberá veľa štandardov spojených s vývojom podnikovej aplikácie. Poskytuje nám vysoko hodnotenú, ale flexibilnú platformu na vývoj mikroslužieb. V tomto tutoriáli využijeme Spring Boot na poskytovanie mikroslužieb pomocou dvanásťfaktorovej metodiky.

4. Uplatnenie dvanásťfaktorovej metodiky

Poďme si teraz definovať jednoduchú aplikáciu, ktorú sa pokúsime vyvinúť pomocou nástrojov a postupov, o ktorých sme práve hovorili. Všetci radi pozeráme filmy, ale je náročné sledovať filmy, ktoré sme už sledovali.

Kto by teraz chcel začať s filmom a potom ho opustiť? Potrebujeme jednoduchú službu na nahrávanie a dopytovanie filmov, ktoré sme sledovali:

Toto je celkom jednoduchá a štandardná mikroslužba s úložiskom údajov a koncovými bodmi REST. Musíme definovať model, ktorý bude mapovaný aj na vytrvalosť:

@Entity public class Movie {@Id private Long id; súkromný názov reťazca; súkromný reťazcový rok; súkromné ​​hodnotenie reťazcov; // zakladatelia a zakladatelia}

Definovali sme entitu JPA s id a niekoľkými ďalšími atribútmi. Pozrime sa teraz, ako vyzerá ovládač REST:

@RestController verejná trieda 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 ("/ movies") public Long createStudent (@RequestBody Movie movie) {return movieRepository.save (movie) .getId (); }}

Toto pokrýva základňu našej jednoduchej služby. Zvyškom aplikácie prejdeme, keď si v nasledujúcich pododdieloch povieme, ako implementujeme dvanásťfaktorovú metodiku.

4.1. zdrojový kód

Prvým najlepším postupom dvanásťfaktorových aplikácií je sledovanie v systéme riadenia verzií. Git je najpopulárnejší systém na správu verzií, ktorý sa dnes používa, a je takmer všadeprítomný. Zásada tvrdí, že aplikácia by mala byť sledovaná v jednom úložisku kódov a nesmie ju zdieľať s inými aplikáciami.

Spring Boot ponúka mnoho pohodlných spôsobov zavedenia aplikácie, vrátane nástroja príkazového riadku a webového rozhrania. Po vygenerovaní aplikácie bootstrap ju môžeme previesť na úložisko git:

git init

Tento príkaz by sa mal spustiť z koreňového adresára aplikácie. Aplikácia v tejto fáze už obsahuje súbor .gitignore, ktorý účinne obmedzuje kontrolu generovaných súborov z hľadiska verzie. Takže môžeme okamžite vytvoriť počiatočný záväzok:

git pridať. git commit -m "Pridanie bootstrapu aplikácie."

Nakoniec môžeme pridať diaľkový ovládač a ak chceme, tlačiť naše záväzky na diaľkový ovládač (nejde o prísnu požiadavku):

git remote add origin //github.com//12-factor-app.git git push -u origin master

4.2. Závislosti

Ďalej dvanásťfaktorová aplikácia by mala vždy výslovne deklarovať všetky svoje závislosti. Mali by sme to urobiť pomocou manifestu deklarácie závislosti. Java má niekoľko nástrojov na správu závislostí, ako sú Maven a Gradle. Na dosiahnutie tohto cieľa môžeme použiť jednu z nich.

Naša jednoduchá aplikácia teda závisí od niekoľkých externých knižníc, napríklad od knižnice, ktorá uľahčuje REST API a pripája sa k databáze. Pozrime sa, ako ich môžeme deklaratívne definovať pomocou Mavenu.

Maven vyžaduje, aby sme popísali závislosti projektu v súbore XML, ktorý sa zvyčajne nazýva Project Object Model (POM):

  org.springframework.boot spring-boot-starter-web com.h2database h2 runtime 

Aj keď to vyzerá jednoducho a jednoducho, tieto závislosti majú zvyčajne iné prechodné závislosti. To to do istej miery komplikuje, ale pomáha nám to dosiahnuť náš cieľ. Naša aplikácia teraz nemá priamu závislosť, ktorá nie je výslovne popísaná.

4.3. Konfigurácie

Aplikácia má zvyčajne veľa konfigurácie, z ktorých niektoré sa môžu medzi nasadeniami líšiť, zatiaľ čo iné zostávajú rovnaké.

V našom príklade máme perzistentnú databázu. Na pripojenie sa budeme potrebovať adresu a poverenia databázy. To sa s najväčšou pravdepodobnosťou zmení medzi nasadeniami.

Dvanásťfaktorová aplikácia by mala externalizovať všetky konfigurácie, ktoré sa medzi jednotlivými nasadeniami líšia. Tu sa odporúča použiť pre také konfigurácie premenné prostredia. To vedie k čistému oddeleniu konfigurácie a kódu.

Jar poskytuje konfiguračný súbor, kde môžeme tieto konfigurácie deklarovať a pripojiť k premenným prostredia:

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

Tu sme definovali adresu URL databázy a poverenia ako konfigurácie a namapovali sme skutočné hodnoty, ktoré sa majú vybrať z premennej prostredia.

V systéme Windows môžeme pred spustením aplikácie nastaviť premennú prostredia:

sada MYSQL_HOST = localhost sada MYSQL_PORT = 3306 sada MYSQL_USER = sada filmov MYSQL_PASSWORD = heslo

Na automatizáciu tohto procesu môžeme použiť nástroj na správu konfigurácie ako Ansible alebo Chef.

4.4. Sprievodné služby

Záložné služby sú služby, od ktorých závisí prevádzka aplikácie. Napríklad databáza alebo sprostredkovateľ správ. Aplikácia s dvanástimi faktormi by mala všetky tieto podporné služby považovať za pripojené zdroje. To skutočne znamená, že na výmenu kompatibilnej podpornej služby by nemalo byť potrebné meniť kód. Jediná zmena by mala byť v konfiguráciách.

V našej aplikácii sme použili MySQL ako podpornú službu na zabezpečenie vytrvalosti.

Jarné JPA robí kód dosť agnostickým pre skutočného poskytovateľa databázy. Musíme iba definovať úložisko, ktoré poskytuje všetky štandardné operácie:

@Repository verejné rozhranie MovieRepository rozširuje JpaRepository {}

Ako vidíme, nie je to priamo závislé od MySQL. Jar detekuje ovládač MySQL na ceste triedy a poskytuje dynamicky implementáciu tohto rozhrania špecifickú pre MySQL. Navyše z konfigurácií priamo sťahuje ďalšie podrobnosti.

Pokiaľ teda máme prejsť z MySQL na Oracle, musíme iba vymeniť ovládač v našich závislostiach a vymeniť konfigurácie.

4.5. Zostavte, uvoľnite a spustite

Dvanásťfaktorová metodika striktne oddeľuje proces premeny kódovej základne na spustenú aplikáciu ako tri odlišné etapy:

• Zostavenie: Toto je miesto, kde vezmeme základ kódu, vykonáme statické a dynamické kontroly a potom vygenerujeme spustiteľný balík ako JAR. Pomocou nástroja ako Maven je to celkom triviálne:

 mvn čistý kompilačný testovací balíček

• Fáza vydania: Toto je fáza, keď vezmeme spustiteľný balík a skombinujeme ho so správnymi konfiguráciami. Tu môžeme použiť Packer s poskytovateľom ako Ansible na vytváranie Docker obrázkov:

 zostavovateľ balíka application.json

• Spustiť fázu: Nakoniec je to fáza, keď aplikáciu spúšťame v cieľovom prostredí vykonávania. Ak ako kontajner na vydanie našej aplikácie použijeme Docker, spustenie aplikácie môže byť dosť jednoduché:

 docker run --name -it 

Nakoniec tieto fázy nemusíme nevyhnutne vykonávať manuálne. To je miesto, kde Jenkins prichádza ako veľmi šikovný so svojím deklaratívnym pipeline.

4.6. Procesy

Očakáva sa, že dvanásťfaktorová aplikácia bude bežať v prostredí vykonávania ako procesy bez štátnej príslušnosti. Inými slovami, nemôžu medzi požiadavkami lokálne ukladať trvalý stav. Môžu generovať trvalé údaje, ktorých uloženie v jednej alebo viacerých stavových podporných službách sa vyžaduje.

V prípade nášho príkladu sme odhalili viac koncových bodov. Žiadosť o ktorýkoľvek z týchto koncových bodov je úplne nezávislá od akejkoľvek žiadosti predloženej pred ňou. Napríklad, ak sledujeme požiadavky používateľov v pamäti a tieto informácie používame na poskytovanie budúcich požiadaviek, porušuje to dvanásťfaktorovú aplikáciu.

Preto dvanásťfaktorová aplikácia nevyžaduje také obmedzenia ako lepivé sedenia. Vďaka tomu je takáto aplikácia vysoko prenosná a škálovateľná. V prostredí cloudového vykonávania, ktoré ponúka automatické škálovanie, je to od aplikácií veľmi žiaduce správanie.

4.7. Viazanie portov

Tradičná webová aplikácia v jazyku Java je vyvinutá ako WAR alebo webový archív. Toto je zvyčajne kolekcia servletov so závislosťami a očakáva sa v nej vyhovujúci runtime kontajnera, napríklad Tomcat. Dvanásťfaktorová aplikácia naopak neočakáva žiadnu takúto závislosť od behu. Je úplne samostatný a vyžaduje iba vykonávací runtime, ako je Java.

V našom prípade sme vyvinuli aplikáciu pomocou Spring Boot. Spring Boot nám okrem mnohých ďalších výhod poskytuje predvolený zabudovaný aplikačný server. Preto je JAR, ktorý sme vygenerovali skôr pomocou Mavenu, plne schopný vykonania v akomkoľvek prostredí iba pomocou kompatibilného runtime Java:

java -jar application.jar

Tu naša jednoduchá aplikácia vystavuje svoje koncové body cez väzbu HTTP na konkrétny port, napríklad 8080. Po spustení aplikácie, ako sme to urobili vyššie, by malo byť možné získať prístup k exportovaným službám, ako je HTTP.

Aplikácia môže exportovať viac služieb, ako je FTP alebo WebSocket, pripojením na viac portov.

4.8. Súbežnosť

Java ponúka Závit ako klasický model na zvládnutie súbežnosti v aplikácii. Vlákna sú ako ľahké procesy a v programe predstavujú viaceré cesty vykonania. Vlákna sú silné, ale majú obmedzenia, pokiaľ ide o to, ako veľmi môžu pomôcť škále aplikácií.

Dvanásťfaktorová metodika navrhuje, aby sa aplikácie pri škálovaní spoliehali na procesy. Čo to efektívne znamená, že aplikácie by mali byť navrhnuté tak, aby distribuovali pracovné zaťaženie do viacerých procesov. Jednotlivé procesy však môžu bezplatne využívať podobný model súbežnosti Závit vnútorne.

Aplikácia Java po spustení dostane jediný proces, ktorý je viazaný na podkladový JVM. Čo skutočne potrebujeme, je spôsob spustenia viacerých inštancií aplikácie s inteligentným rozložením záťaže medzi nimi. Pretože sme našu aplikáciu už zabalili ako kontajner Docker, Kubernetes je pre takúto orchestráciu prirodzenou voľbou.

4.9. Jednorazovosť

Aplikačné procesy je možné ukončiť zámerne alebo neočakávanou udalosťou. V každom prípade, dvanásťfaktorová aplikácia to má zvládnuť ladne. Inými slovami, proces podávania žiadosti by mal byť úplne jednorazový bez akýchkoľvek nežiaducich vedľajších účinkov. Procesy by sa navyše mali začať rýchlo

Napríklad v našej aplikácii je jedným z koncových bodov vytvorenie nového databázového záznamu pre film. Aplikácia, ktorá vybavuje takúto požiadavku, teraz môže neočakávane zlyhať. To by však nemalo mať vplyv na stav žiadosti. Keď klient znova odošle tú istú žiadosť, nemalo by to mať za následok duplicitné záznamy.

V súhrne by aplikácia mala zverejňovať idempotentné služby. Toto je ďalší veľmi žiadaný atribút služby určenej na nasadenie v cloude. To dáva flexibilitu kedykoľvek zastaviť, presunúť alebo otočiť nové služby bez akýchkoľvek ďalších úvah.

4.10. Parita pre vývoj / produkciu

Je typické, že aplikácie sa vyvíjajú na miestnych počítačoch, testujú sa v niektorých iných prostrediach a nakoniec sa nasadia do výroby. Často je to tak, keď sú tieto prostredia odlišné. Napríklad vývojový tím pracuje na počítačoch so systémom Windows, zatiaľ čo produkčné nasadenie sa deje na strojoch so systémom Linux.

Dvanásťfaktorová metodika navrhuje udržiavať rozdiel medzi vývojovým a produkčným prostredím čo najmenší. Tieto medzery môžu byť výsledkom dlhých vývojových cyklov, rôznych zapojených tímov alebo iného používaného technologického radu.

Technológie ako Spring Boot a Docker teraz túto medzeru do veľkej miery automaticky preklenujú. Očakáva sa, že kontajnerovaná aplikácia sa bude správať rovnako, bez ohľadu na to, kde ju spustíme. Musíme tiež použiť rovnaké podporné služby - ako je napríklad databáza.

Okrem toho by sme mali mať správne procesy, ako je nepretržitá integrácia a poskytovanie, ktoré by ďalej uľahčili preklenutie tejto medzery.

4.11. Záznamy

Denníky sú základné údaje, ktoré aplikácia generuje počas svojej životnosti. Poskytujú neoceniteľný prehľad o fungovaní aplikácie. Aplikácia môže zvyčajne generovať protokoly na viacerých úrovniach s rôznymi detailami a výstup ii vo viacerých rôznych formátoch.

Dvanásťfaktorová aplikácia sa však oddeľuje od generovania protokolov a ich spracovania. Pre takúto aplikáciu nie sú protokoly nič iné ako časovo usporiadaný prúd udalostí. Tieto udalosti iba zapisuje na štandardný výstup z prostredia vykonávania. Zachytávanie, ukladanie, liečenie a archivácia takéhoto toku by malo byť spravované prostredím spustenia.

Na tento účel máme k dispozícii pomerne veľa nástrojov. Na začiatok môžeme použiť aplikáciu SLF4J na abstraktné spracovanie protokolovania v rámci našej aplikácie. Ďalej môžeme použiť nástroj ako Fluentd na zhromažďovanie toku protokolov z aplikácií a podporných služieb.

To môžeme vložiť do Elasticsearch na ukladanie a indexovanie. Na záver môžeme vygenerovať zmysluplné dashboardy pre vizualizáciu v Kibane.

4.12. Správcovské procesy

V stave aplikácie často potrebujeme vykonať nejaké jednorazové úlohy alebo rutinný postup. Napríklad oprava zlých záznamov. Teraz to môžeme dosiahnuť rôznymi spôsobmi. Pretože to nemusíme často vyžadovať, môžeme napísať malý skript, aby sme ho spustili oddelene od iného prostredia.

Teraz, dvanásťfaktorová metodika dôrazne navrhuje ponechať tieto administračné skripty spolu s kódovou základňou aplikácie. Pritom by sa malo riadiť rovnakými zásadami, aké platíme pre hlavnú databázu kódov aplikácií. Na spustenie takýchto skriptov na produkčných serveroch je tiež vhodné použiť vstavaný nástroj REPL vykonávacieho prostredia.

Ako v našom príklade naočkujeme našu aplikáciu na doteraz pozreté filmy? Môžeme síce použiť náš malý sladký koncový bod, ale to sa môže javiť ako nepraktické. Potrebujeme skript na jednorazové načítanie. Môžeme napísať malú funkciu Java, aby sme prečítali zoznam filmov zo súboru a hromadne ich uložili do databázy.

Na spustenie týchto procesov môžeme navyše použiť program Groovy integrovaný s runtime Java.

5. Praktické aplikácie

Teraz sme teda videli všetky faktory, ktoré navrhuje dvanásťfaktorová metodika. Rozvoj aplikácie bude a dvanásťfaktorová aplikácia má určite svoje výhody, najmä keď ich chceme nasadiť ako služby v cloude. Musíme sa však, rovnako ako všetky ostatné usmernenia, rámec, vzory, pýtať, je to strieborná guľka?

Úprimne, žiadna jediná metodika v oblasti návrhu a vývoja softvéru netvrdí, že je striebornou guľkou. Výnimkou nie je ani dvanásťfaktorová metodika. Zatiaľ čo niektoré z týchto faktorov sú celkom intuitívnea s najväčšou pravdepodobnosťou ich už robíme, iné sa nás nemusia týkať. Je nevyhnutné vyhodnotiť tieto faktory na pozadí našich cieľov a potom zvoliť rozumne.

Je dôležité poznamenať, že všetky tieto faktory sú pomôže nám vyvinúť aplikáciu, ktorá je modulárna, nezávislá, prenosná, škálovateľná a pozorovateľná. V závislosti od aplikácie ich možno budeme môcť dosiahnuť inými prostriedkami lepšie. Rovnako nie je potrebné prijímať všetky faktory spoločne, dokonca aj keď sa niektoré z nich stanú lepšími, ako sme boli.

Nakoniec sú tieto faktory celkom jednoduché a elegantné. Majú väčšiu dôležitosť vo veku, keď požadujeme, aby naše aplikácie mali vyššiu priepustnosť a nižšiu latenciu prakticky bez výpadkov a zlyhaní. Prijatie týchto faktorov nám dáva správny začiatok od začiatku. V kombinácii s architektúrou mikroslužieb a kontajnerizáciou aplikácií sa zdá, že zasiahli správne miesto.

6. Záver

V tomto tutoriáli sme si prešli koncepty dvanásťfaktorovej metodiky. Diskutovali sme o tom, ako využiť architektúru mikroslužieb pomocou Spring Boot na ich efektívne dodanie. Ďalej sme podrobne preskúmali každý faktor a ako ich použiť v našej aplikácii. Preskúmali sme tiež niekoľko nástrojov na úspešné efektívne použitie týchto jednotlivých faktorov.