Halló, Habr. Í dag held ég áfram röð rita sem ég skrifaði sérstaklega fyrir upphaf nýs straums á námskeiðinu. .
Inngangur
Val á byggingarstíl er ein af grundvallar tæknilegum ákvörðunum við smíði upplýsingakerfis. Í þessari greinaröð legg ég til að greina vinsælustu byggingarstíla fyrir byggingarforrit og svara spurningunni um hvenær hvaða byggingarstíll er æskilegastur. Í kynningarferlinu mun ég reyna að teikna rökrétta keðju sem útskýrir þróun byggingarstíla frá einlitum til örþjónustu.
Síðast ræddum við um mismunandi gerðir einliða og notkun íhluta til að byggja þá, bæði byggingarhluta og dreifingarhluta. Við skiljum þjónustumiðaðan arkitektúr.
Nú munum við loksins skilgreina helstu einkenni örþjónustuarkitektúrs.
Tengsl arkitektúra
Nauðsynlegt er að skilja að miðað við skilgreiningarnar sem gefnar eru í fyrri greinum er hvaða þjónusta sem er hluti, en ekki sérhver þjónusta er örþjónusta.
Einkenni örþjónustuarkitektúrs
Helstu eiginleikar örþjónustuarkitektúrs eru:
- Skipulagður í kringum viðskiptagetu
- Vörur ekki Projects
- Snjallir endapunktar og asnaleg rör
- Dreifð stjórnsýsla
- Dreifð gagnastjórnun
- Sjálfvirkni innviða
- Hönnun fyrir bilun
- Arkitektúr með þróunarþróun (Evolutionary Design)
1. liðurinn kemur frá þjónustumiðuðum arkitektúr vegna þess að örþjónustur eru sérstakt tilvik þjónustu. Önnur atriði verðskulda sérstaka umfjöllun.
Skipulagður í kringum viðskiptagetu
Nú er nauðsynlegt að muna lögmál Conway: stofnanir sem búa til kerfi skipuleggja arkitektúr þess, afrita uppbyggingu samskipta innan þessara stofnana. Sem dæmi getum við rifjað upp dæmið um að búa til þýðanda: sjö manna teymi þróaði sjö passa þýðanda og fimm manna teymi þróaði fimm passa þýðanda.
Ef við erum að tala um einliða og örþjónustur, þá ef þróun er skipulögð af hagnýtum deildum (bakenda, framenda, gagnagrunnsstjóra), þá fáum við klassískan einliða.
Til að fá örþjónustu verða teymi að vera skipulögð eftir viðskiptagetu (pantanir, sendingar, vörulistateymi). Þessi stofnun mun leyfa teymum að einbeita sér að því að byggja upp ákveðna hluta forritsins.
Vörur ekki Projects
Verkefnanálgun þar sem teymi flytur þróaða virkni til annarra teyma er algjörlega óhentug ef um er að ræða smáþjónustuarkitektúr. Teymið verður að styðja við kerfið allan lífsferil þess. Amazon, einn af leiðtogunum í innleiðingu örþjónustu, sagði: "þú byggir, þú rekur það." Vöruaðferðin gerir teyminu kleift að finna fyrir þörfum fyrirtækisins.
Snjallir endapunktar og asnaleg rör
SOA arkitektúr lagði mikla áherslu á samskiptaleiðir, sérstaklega Enterprise Service Bus. Sem leiðir oft til rangrar spaghettíboxs, það er að flókið einliða breytist í flókið samband milli þjónustu. Örþjónustuarkitektúr notar aðeins einfaldar samskiptaaðferðir.
Dreifð stjórnsýsla
Lykilákvarðanir um örþjónustu ættu að vera teknar af fólki sem í raun þróar örþjónustuna. Hér þýða lykilákvarðanir val
forritunarmál, dreifingaraðferðir, samningar um opinber viðmót o.s.frv.
Dreifð gagnastjórnun
Staðlaða nálgunin, þar sem forritið byggir á einum gagnagrunni, getur ekki tekið tillit til sérstakra sérstakra þjónustu. MSA felur í sér dreifða gagnastjórnun, þar á meðal notkun ýmissa tækni.
Sjálfvirkni innviða
MSA styður stöðuga dreifingu og afhendingarferli. Þetta er aðeins hægt að ná með því að gera ferla sjálfvirka. Á sama tíma lítur það ekki lengur út fyrir að vera eitthvað skelfilegt að dreifa fjölda þjónustu. Dreifingarferlið ætti að verða leiðinlegt. Annar þátturinn tengist þjónustustjórnun í vöruumhverfi. Án sjálfvirkni er ómögulegt að stjórna ferlum sem keyra í mismunandi rekstrarumhverfi.
Hönnun fyrir bilun
Fjölmargar MSA þjónustur eru viðkvæmar fyrir mistökum. Á sama tíma er villumeðferð í dreifðu kerfi ekki léttvægt verkefni. Forritaarkitektúr verður að vera þola slíkar bilanir. Rebecca Parsons telur mjög mikilvægt að við notum ekki einu sinni í ferli samskipti milli þjónustu, heldur grípum við til HTTP fyrir samskipti, sem er ekki nærri eins áreiðanlegt.
Arkitektúr með þróunarþróun (Evolutionary Design)
Arkitektúr MSA kerfisins ætti að þróast í þróun. Ráðlegt er að takmarka nauðsynlegar breytingar á mörkum einnar þjónustu. Einnig þarf að taka tillit til áhrifa á aðra þjónustu. Hefðbundin nálgun er að reyna að leysa þetta vandamál með útgáfu, en MSA leggur til að nota útgáfu í
sem síðasta úrræði.
Ályktun
Eftir allt ofangreint getum við mótað hvað örþjónustur eru. Örþjónustuarkitektúr er nálgun til að þróa eitt forrit sem safn lítilla þjónustu, sem hver keyrir í sínu eigin ferli og hefur samskipti í gegnum léttar aðferðir, oft HTTP auðlinda API. Þessar þjónustur eru byggðar á viðskiptagetu og hægt er að dreifa henni sjálfstætt með fullri notkun
sjálfvirkt dreifingarkerfi. Það er lágmarksstig miðlægrar stjórnun þessarar þjónustu, sem hægt er að skrifa á mismunandi forritunarmálum og nota mismunandi gagnageymslutækni.
Heimild: www.habr.com