streamalism.org

1. Pregled

U ovom ćemo uputstvu razumjeti metodologiju aplikacije od dvanaest faktora.

Također ćemo razumjeti kako razviti mikrouslugu uz pomoć Spring Boota. U tom ćemo procesu vidjeti kako primijeniti dvanaestfaktorsku metodologiju za razvoj takve mikro usluge.

2. Što je metodologija dvanaest faktora?

Metodologija od dvanaest faktora skup je dvanaest najboljih praksi za razvoj aplikacija razvijenih za rad kao usluga. Ovo je izvorno izradio Heroku za aplikacije raspoređene kao usluge na njihovoj oblačnoj platformi, još 2011. S vremenom se to pokazalo dovoljno generičkim za bilo koji razvoj softvera kao usluge (SaaS).

Dakle, što podrazumijevamo pod softverom kao uslugom? Tradicionalno dizajniramo, razvijamo, implementiramo i održavamo softverska rješenja kako bismo iz njih izvukli poslovnu vrijednost. Ali, ne moramo se uključiti u taj proces da bismo nužno postigli isti rezultat. Na primjer, izračun primjenjivog poreza generička je funkcija u mnogim domenama.

Sada bismo mogli odlučiti sami graditi i upravljati ovom uslugom ili pretplatite se na ponudu komercijalnih usluga. Takva Ponuda usluga ono je što znamo kao softver kao uslugu.

Iako softver kao usluga ne nameće nikakva ograničenja na arhitekturu na kojoj je razvijen; vrlo je korisno usvojiti neke najbolje prakse.

Ako svoj softver dizajniramo tako da bude modularan, prenosiv i skalabilan na modernim oblačnim platformama, prilično je prilagodljiv našoj ponudi usluga. Tu pomaže dvanaestofaktorska metodologija. Vidjet ćemo ih na djelu kasnije u vodiču.

3. Mikroservis s proljetnim čizmom

Microservice je arhitektonski stil za razvoj softvera kao labavo povezanih usluga. Ključni zahtjev ovdje je da usluge bi trebale biti organizirane oko granica poslovne domene. To je često najteže prepoznati.

Štoviše, usluga ovdje ima isključivu vlast nad svojim podacima i izlaže operacije drugim službama. Komunikacija između usluga obično se odvija putem laganih protokola poput HTTP-a. To rezultira neovisno raspoloživim i skalabilnim uslugama.

Sada arhitektura mikroservisa i softver kao usluga ne ovise jedni o drugima. Ali, nije teško to razumjeti, kada razvoj softvera kao usluge, koristeći arhitekturu mikro usluga vrlo je korisno. Pomaže u postizanju mnogih ciljeva o kojima smo ranije razgovarali, poput modularnosti i skalabilnosti.

Spring Boot je aplikacijski okvir zasnovan na Springu koji oduzima puno obrazaca povezanih s razvojem poslovne aplikacije. Pruža nam visoko uvjerljivu, ali fleksibilnu platformu za razvoj mikrousluga. Za ovaj ćemo vodič iskoristiti Spring Boot za isporuku mikrousluga koristeći dvanaestofaktorsku metodologiju.

4. Primjena metodologije dvanaest faktora

Ajmo sada definirati jednostavnu aplikaciju koju ćemo pokušati razviti pomoću alata i praksi o kojima smo upravo razgovarali. Svi volimo gledati filmove, ali izazovno je pratiti filmove koje smo već gledali.

Sad, tko bi želio pokrenuti film, a zatim ga napustiti kasnije? Ono što nam treba je jednostavna usluga za snimanje i ispitivanje filmova koje smo gledali:

Ovo je prilično jednostavna i standardna mikro usluga sa spremištem podataka i krajnjim točkama REST. Moramo definirati model koji će se preslikati i na ustrajnost:

@ Entity public class Movie {@Id private Long id; privatni naslov niza; privatna gudačka godina; ocjena privatnog niza; // geteri i postavljači}

Definirali smo JPA entitet s ID-om i nekoliko drugih atributa. Pogledajmo sada kako izgleda REST kontroler:

@RestController javna klasa MovieController {@Autowired privatni MovieRepository movieRepository; @GetMapping ("/ movies") javni popis retrieveAllStudents () {return movieRepository.findAll (); } @GetMapping ("/ movies / {id}") javni film retrieveStudent (@PathVariable Long id) {return movieRepository.findById (id) .get (); } @PostMapping ("/ movies") javni Long createStudent (@RequestBody Movie movie) {return movieRepository.save (film) .getId (); }}

Ovo pokriva bazu naše jednostavne usluge. Proći ćemo kroz ostatak aplikacije dok ćemo raspravljati o tome kako provodimo dvanaestfaktorsku metodologiju u sljedećim pododjeljcima.

4.1. Kodna baza

Prva najbolja praksa aplikacija s dvanaest faktora je praćenje u sustavu za upravljanje verzijama. Git je najpopularniji sustav za upravljanje verzijama koji se danas koristi i gotovo je sveprisutan. Princip navodi da aplikacija bi se trebala pratiti u jednom spremištu koda i ne smije je dijeliti s drugim aplikacijama.

Spring Boot nudi mnoge prikladne načine za pokretanje aplikacije, uključujući alat za naredbene retke i web sučelje. Jednom kada generiramo bootstrap aplikaciju, to možemo pretvoriti u git spremište:

git init

Ovu naredbu treba pokrenuti iz korijena aplikacije. Aplikacija u ovoj fazi već sadrži datoteku .gitignore koja učinkovito ograničava kontrolu nad generiranim datotekama. Dakle, možemo odmah stvoriti početni predaj:

git dodaj. git commit -m "Dodavanje bootstrapa aplikacije."

Konačno, možemo dodati daljinski upravljač i pogurati svoje obveze na daljinski ako to želimo (to nije strog zahtjev):

git daljinsko dodavanje podrijetla //github.com//12-factor-app.git git push -u master master

4.2. Ovisnosti

Dalje, aplikacija od dvanaest faktora uvijek bi trebala izričito navesti sve svoje ovisnosti. To bismo trebali učiniti pomoću manifesta izjave o ovisnosti. Java ima više alata za upravljanje ovisnostima kao što su Maven i Gradle. Jednog od njih možemo koristiti za postizanje ovog cilja.

Dakle, naša jednostavna aplikacija ovisi o nekoliko vanjskih knjižnica, poput knjižnice za olakšavanje REST API-ja i povezivanje s bazom podataka. Pogledajmo kako ih možemo deklarativno definirati pomoću Mavena.

Maven od nas traži da u XML datoteci, obično poznatoj kao objektni objektni model (POM), opišemo ovisnosti projekta:

  org.springframework.boot spring-boot-starter-web com.h2database h2 vrijeme izvođenja 

Iako ovo izgleda jednostavno i jednostavno, ove ovisnosti obično imaju i druge prijelazne ovisnosti. To je do neke mjere komplicira, ali pomaže nam u postizanju cilja. Sada naša aplikacija nema izravnu ovisnost koja nije izričito opisana.

4.3. Konfiguracije

Aplikacija obično ima puno konfiguracije, od kojih se neke mogu razlikovati između implementacija, dok druge ostaju iste.

U našem primjeru imamo postojanu bazu podataka. Trebat će nam adresa i vjerodajnice baze podataka za povezivanje. To će se najvjerojatnije promijeniti između postavljanja.

Aplikacija od dvanaest faktora trebala bi eksternalizirati sve takve konfiguracije koje se razlikuju od implementacije. Ovdje je preporuka koristiti varijable okoline za takve konfiguracije. To dovodi do čistog razdvajanja konfiguracije i koda.

Spring pruža konfiguracijsku datoteku u kojoj možemo deklarirati takve konfiguracije i priložiti je varijablama okoline:

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

Ovdje smo definirali URL baze podataka i vjerodajnice kao konfiguracije i mapirali smo stvarne vrijednosti koje treba odabrati iz varijable okoline.

U sustavu Windows možemo postaviti varijablu okruženja prije pokretanja aplikacije:

set MYSQL_HOST = localhost set MYSQL_PORT = 3306 set MYSQL_USER = filmovi set MYSQL_PASSWORD = lozinka

Za automatizaciju ovog postupka možemo koristiti alat za upravljanje konfiguracijama poput Ansible ili Chef.

4.4. Usluge potpore

Usluge sigurnosne kopije su usluge o kojima aplikacija ovisi za rad. Na primjer baza podataka ili posrednik poruka. Aplikacija od dvanaest faktora trebala bi tretirati sve takve usluge podrške kao povezane resurse. To zapravo znači da ne bi trebala zahtijevati promjenu koda za zamjenu kompatibilne sigurnosne usluge. Jedina promjena trebala bi biti u konfiguracijama.

U našoj smo aplikaciji MySQL koristili kao pomoćnu uslugu kako bismo osigurali postojanost.

Spring JPA čini kod prilično agnostičkim za stvarnog pružatelja baze podataka. Trebamo definirati samo spremište koje pruža sve standardne operacije:

@Repository javno sučelje MovieRepository proširuje JpaRepository {}

Kao što vidimo, ovo ne ovisi izravno o MySQL-u. Spring otkriva MySQL pokretački program na stazi i dinamički pruža implementaciju ovog sučelja specifičnu za MySQL. Štoviše, iz pojedinih konfiguracija izravno povlači ostale detalje.

Dakle, ako moramo iz MySQL-a prijeći u Oracle, sve što trebamo je zamijeniti upravljački program u našim ovisnostima i zamijeniti konfiguracije.

4.5. Izgradite, pustite i pokrenite

Dvanaestofaktorska metodologija strogo odvaja postupak pretvaranja baze koda u pokrenutu aplikaciju kao tri različita stupnja:

• Faza izgradnje: Ovdje uzimamo bazu koda, vršimo statičke i dinamičke provjere, a zatim generiramo izvršni paket poput JAR-a. Korištenje alata poput Mavena ovo je prilično trivijalno:

 mvn clean compile test paket

• Release Stage: Ovo je faza u kojoj uzimamo izvršni paket i kombiniramo ga s pravim konfiguracijama. Ovdje možemo koristiti Packer s dobavljačem poput Ansible za stvaranje Dockerovih slika:

 packer build application.json

• Pokreni faza: Napokon, ovo je faza u kojoj pokrećemo aplikaciju u ciljanom okruženju izvršenja. Ako koristimo Docker kao spremnik za puštanje naše aplikacije, pokretanje aplikacije može biti dovoljno jednostavno:

 izvršavanje dockera --name -it 

Konačno, ne moramo nužno ručno izvoditi ove faze. Tu Jenkins dolazi prilično zgodan s njihovim deklarativnim cjevovodom.

4.6. Procesi

Očekuje se da će aplikacija od dvanaest faktora raditi u izvršnom okruženju kao procesi bez državljanstva. Drugim riječima, ne mogu lokalno pohraniti postojano stanje između zahtjeva. Oni mogu generirati trajne podatke koji su potrebni za pohranu u jednoj ili više sigurnosnih usluga s podacima.

U slučaju našeg primjera, izloženo je više krajnjih točaka. Zahtjev za bilo kojom od ovih krajnjih točaka potpuno je neovisan o bilo kojem zahtjevu podnesenom prije njega. Na primjer, ako pratimo korisničke zahtjeve u memoriji i koristimo te podatke za posluživanje budućih zahtjeva, to krši aplikaciju od dvanaest faktora.

Stoga aplikacija od dvanaest faktora ne nameće takva ograničenja poput ljepljivih sesija. To takvu aplikaciju čini vrlo prenosivom i skalabilnom. U okruženju izvršavanja u oblaku koje nudi automatizirano skaliranje, prilično je poželjno ponašanje aplikacija.

4.7. Povezivanje luka

Tradicionalna web aplikacija na Javi razvijena je kao WAR ili web arhiva. Ovo je obično zbirka servleta s ovisnostima i očekuje usklađeno vrijeme izvođenja spremnika poput Tomcata. Aplikacija od dvanaest faktora, naprotiv, ne očekuje takvu ovisnost o vremenu izvođenja. Potpuno je samostalan i zahtijeva samo vrijeme izvršavanja poput Jave.

U našem smo slučaju razvili aplikaciju pomoću Spring Boota. Spring Boot, osim mnogih drugih pogodnosti, pruža nam zadani ugrađeni poslužitelj aplikacija. Dakle, JAR koji smo ranije generirali koristeći Maven u potpunosti je sposoban za izvršavanje u bilo kojem okruženju samo kompatibilnim Java runtimeom:

prijava java -jar.jar

Ovdje naša jednostavna aplikacija izlaže svoje krajnje točke preko HTTP vezanja na određeni priključak poput 8080. Nakon pokretanja aplikacije, kao što smo učinili gore, trebao bi biti moguć pristup izvoženim uslugama poput HTTP-a.

Aplikacija može izvesti više usluga poput FTP-a ili WebSocket-a tako da se veže na više portova.

4.8. Konkurencija

Java nudi Nit kao klasični model za rukovanje istodobnošću u aplikaciji. Niti su poput laganih procesa i predstavljaju višestruke staze izvođenja u programu. Teme su moćne, ali imaju ograničenja u pogledu toga koliko mogu pomoći skali aplikacije.

Metodologija od dvanaest faktora sugerira aplikacijama da se oslanjaju na procese za skaliranje. To učinkovito znači da bi aplikacije trebale biti dizajnirane za raspodjelu radnog opterećenja kroz više procesa. Pojedinačni su procesi, međutim, slobodni iskoristiti paralelni model poput Nit iznutra.

Java aplikacija, kada se pokrene, dobiva jedan proces koji je vezan za temeljni JVM. Ono što nam zapravo treba jest način za pokretanje više instanci aplikacije s inteligentnom raspodjelom opterećenja između njih. Budući da smo svoju aplikaciju već zapakirali kao Docker spremnik, Kubernetes je prirodan izbor za takvu orkestraciju.

4.9. Jednokratnost

Procesi prijave mogu se zaustaviti namjerno ili zbog neočekivanog događaja. U svakom slučaju, aplikacija od dvanaest faktora trebala bi se graciozno nositi s tim. Drugim riječima, postupak prijave trebao bi biti jednokratni, bez neželjenih nuspojava. Štoviše, procesi bi trebali brzo započeti

Primjerice, u našoj je aplikaciji jedna od krajnjih točaka stvaranje novog zapisa baze podataka za film. Sada se aplikacija koja obrađuje takav zahtjev može neočekivano srušiti. To, međutim, ne bi trebalo utjecati na stanje prijave. Kad klijent ponovno pošalje isti zahtjev, to ne bi trebalo rezultirati duplikatima zapisa.

Ukratko, aplikacija bi trebala izložiti idempotentne usluge. Ovo je još jedan vrlo poželjan atribut usluge namijenjene postavljanju u oblak. To daje fleksibilnost zaustavljanja, premještanja ili vrtnje novih usluga u bilo kojem trenutku bez ikakvih drugih razmatranja.

4.10. Razvoj / Prod. Paritet

Tipično je za programe koji se razvijaju na lokalnim strojevima, testiraju u nekim drugim okruženjima i konačno implementiraju u proizvodnju. Čest je slučaj kada se ta okruženja razlikuju. Na primjer, razvojni tim radi na Windows računalima, dok se produkcijska implementacija događa na Linux računalima.

Metodologija od dvanaest faktora predlaže da se jaz između razvoja i proizvodnog okruženja održi što je moguće manjim. Te praznine mogu proizaći iz dugih razvojnih ciklusa, različitih uključenih timova ili različitih tehnologija u uporabi.

Sada, tehnologija poput Spring Boot i Docker automatski u velikoj mjeri prevladava ovaj jaz. Očekuje se da se kontejnerizirana aplikacija ponaša isto, bez obzira gdje je pokrenuli. Moramo koristiti iste sigurnosne usluge - poput baze podataka - također.

Štoviše, trebali bismo imati ispravne procese poput kontinuirane integracije i isporuke kako bismo olakšali daljnje premošćavanje ovog jaza.

4.11. Trupci

Evidencije su ključni podaci koje aplikacija generira tijekom svog životnog vijeka. Pružaju neprocjenjive uvide u rad aplikacije. Aplikacija obično može generirati zapisnike na više razina s različitim detaljima i izlaziti ii u više različitih formata.

Aplikacija od dvanaest faktora, međutim, odvaja se od stvaranja dnevnika i njegove obrade. Za takvu aplikaciju zapisnici nisu ništa drugo do vremenski raspoređeni tok događaja. Te događaje samo zapisuje na standardni izlaz okruženja za izvršavanje. Hvatanjem, pohranjivanjem, čuvanjem i arhiviranjem takvog toka trebalo bi se baviti okruženje izvršenja.

U tu svrhu imamo na raspolaganju nekoliko alata. Za početak možemo koristiti SLF4J za apstraktno rukovanje prijavom unutar naše aplikacije. Štoviše, možemo koristiti alat kao što je Fluentd za prikupljanje toka dnevnika iz aplikacija i usluga podrške.

To možemo dodati u Elasticsearch za pohranu i indeksiranje. Napokon, možemo stvoriti značajne nadzorne ploče za vizualizaciju u Kibani.

4.12. Administratorski procesi

Često moramo izvršiti neke jednokratne zadatke ili rutinske postupke sa svojim stanjem prijave. Na primjer, popravljanje loših zapisa. Postoje različiti načini na koje to možemo postići. Budući da ga često ne trebamo, možemo napisati malu skriptu kako bismo ga pokrenuli odvojeno od drugog okruženja.

Sada, metodologija od dvanaest faktora snažno sugerira držanje takvih administrativnih skripti zajedno s bazom kodova aplikacije. Pritom bi trebao slijediti ista načela kao što se primjenjujemo na glavnu bazu kodova aplikacije. Također je poželjno koristiti ugrađeni alat REPL u izvršnom okruženju za pokretanje takvih skripti na produkcijskim poslužiteljima.

U našem primjeru, kako postaviti svoju prijavu na već gledane filmove do sada? Iako možemo koristiti svoju slatku malu krajnju točku, ali to se može činiti nepraktičnim. Ono što nam treba je skripta za jednokratno učitavanje. Možemo napisati malu Java funkciju za čitanje popisa filmova iz datoteke i njihovo skupno spremanje u bazu podataka.

Štoviše, možemo koristiti Groovy integriran s Java runtimeom za pokretanje takvih procesa.

5. Praktična primjena

Dakle, sada smo vidjeli sve čimbenike predložene od dvanaestofaktorske metodologije. Razvoj aplikacije koja će biti aplikacija od dvanaest faktora sigurno ima svoje prednosti, pogotovo kada ih želimo rasporediti kao usluge u oblaku. Ali, kao i sve ostale smjernice, okviri, obrasci, moramo se zapitati, je li ovo srebrni metak?

Iskreno, niti jedna metodologija u dizajnu i razvoju softvera ne tvrdi da je srebrni metak. Metodologija od dvanaest faktora nije iznimka. Dok neki od ovih čimbenika prilično su intuitivni, i najvjerojatnije ih već radimo, drugi se možda ne odnose na nas. Bitno je procijeniti ove čimbenike u pozadini naših ciljeva, a zatim pametno odabrati.

Važno je napomenuti da su svi ovi čimbenici tu da nam pomogne u razvoju aplikacije koja je modularna, neovisna, prijenosna, skalabilna i vidljiva. Ovisno o aplikaciji, možda ćemo ih moći postići na druge načine bolje. Također nije potrebno usvojiti sve čimbenike zajedno, usvajanje čak i nekih od njih može nas učiniti boljima nego što smo bili.

Napokon, ovi su čimbenici prilično jednostavni i elegantni. Oni imaju veću važnost u doba u kojem zahtijevamo da naše aplikacije imaju veću propusnost i nižu latenciju, gotovo bez zastoja i kvarova. Usvajanje ovih čimbenika daje nam pravi početak od početka. U kombinaciji s mikroservisnom arhitekturom i kontejnerizacijom aplikacija, čini se da su pogodili pravo mjesto.

6. Zaključak

U ovom smo tutorijalu prošli kroz koncepte dvanaestofaktorske metodologije. Razgovarali smo o tome kako iskoristiti arhitekturu mikro usluga s Spring Bootom kako bi ih učinkovito isporučili. Nadalje, detaljno smo istražili svaki čimbenik i kako ih primijeniti na našu aplikaciju. Također smo istražili nekoliko alata za uspješnu primjenu ovih pojedinačnih čimbenika.