Mig langaði að skrifa grein um efnið smáþjónustuarkitektúr í langan tíma, en tvennt hélt áfram að stoppa mig - því lengra sem ég steypti mér í efnið, því meira virtist mér að það sem ég veit væri augljóst og hvað ég geri' t vita þarf að rannsaka og rannsaka. Aftur á móti held ég að það sé nú þegar eitthvað til að ræða meðal breiðs áhorfenda. Svo aðrar skoðanir eru vel þegnar.
Conway's Law og tengsl viðskipta, skipulags og upplýsingakerfis
Enn og aftur ætla ég að leyfa mér að vitna í:
„Sérhver stofnun sem hannar kerfi (í víðum skilningi) mun fá hönnun sem endurspeglar uppbyggingu teymanna í þeirri stofnun.
— Melvyn Conway, 1967
Að mínu mati eru þessi lög líklegri til að tengjast hagkvæmni þess að skipuleggja fyrirtæki, frekar en beint að upplýsingakerfinu. Leyfðu mér að útskýra með dæmi. Segjum að við höfum nokkuð stöðugt viðskiptatækifæri með svo langan lífsferil að skynsamlegt sé að skipuleggja fyrirtæki (þetta er ekki innsláttarvilla, en mér líkar mjög vel við þetta hugtak sem ég stal). Auðvitað er stoðkerfi þessa fyrirtækis. mun skipulagslega og ferli samsvara þessum viðskiptum.
Viðskiptastefna upplýsingakerfa
Leyfðu mér að útskýra með dæmi. Segjum að það sé viðskiptatækifæri til að skipuleggja fyrirtæki sem selur pizzu. Í V1 útgáfunni (köllum það forupplýsingar) var fyrirtækið pítsustaður, sjóðsvél og afhendingarþjónusta. Þessi útgáfa var langlíf við aðstæður með litlum umhverfisbreytileika. Þá kom útgáfa 2 í stað hennar - fullkomnari og fær um að nota upplýsingakerfi í kjarna þess fyrir viðskipti með einhæfan arkitektúr. Og hér, að mínu mati, er einfaldlega hræðilegt óréttlæti í sambandi við einliðana - meintur einhæfur arkitektúr samsvarar ekki viðskiptamódeli lénsins. Já, ef þetta væri svo, myndi kerfið alls ekki geta virkað - í mótsögn við sömu lög og heilbrigða skynsemi Conway. Nei, einhæfur arkitektúr er í fullu samræmi við viðskiptamódelið á þessu stigi viðskiptaþróunar - ég á auðvitað við það stig þegar kerfið hefur þegar verið búið til og tekið í notkun. Það er alveg dásamleg staðreynd að burtséð frá arkitektúrfræðilegri nálgun munu bæði þjónustumiðuð arkitektúr útgáfa 3 og microservices arkitektúr útgáfa N virka jafn vel. Hver er gripurinn?
Allt flæðir, allt breytist, eða eru örþjónustur leið til að berjast gegn margbreytileika?
Áður en við höldum áfram skulum við skoða nokkrar ranghugmyndir um örþjónustuarkitektúr.
Stuðningsmenn þess að nota örþjónustunálgun halda því oft fram að það að brjóta einliða í örþjónustur einfaldaði þróunaraðferðina með því að draga úr kóðagrunni einstakra þjónustu. Að mínu mati er þessi fullyrðing algjört bull. Í alvöru, augljóst samspil innan einsleits og einsleits kóða virðist flókið? Ef þetta væri raunverulega raunin, myndu öll verkefni upphaflega byggjast upp sem örþjónustur, á meðan framkvæmd sýnir að flutningur frá einliða til örþjónustu er mun algengari. Flækjustigið hverfur ekki; það færist einfaldlega frá einstökum einingum yfir í viðmót (hvort sem það eru gagnarútur, RPC, API og aðrar samskiptareglur) og skipulagskerfi. Og þetta er erfitt!
Kosturinn við að nota ólíkan stafla er líka vafasamur. Ég ætla ekki að halda því fram að þetta sé líka mögulegt, en í raun og veru gerist það sjaldan (horft fram á veginn - þetta ætti að gerast - heldur frekar sem afleiðing frekar en kostur).
Lífsferill vöru og þjónustulífsferill
Skoðaðu aftur skýringarmyndina hér að ofan. Það er engin tilviljun að ég tók eftir minnkandi lífsferli sérstakra útgáfu fyrirtækis - við nútíma aðstæður er það hröðun á umskiptum fyrirtækis á milli útgáfur sem ræður úrslitum um velgengni þess. Árangur vöru ræðst af hraða prófunar viðskiptatilgátna í henni. Og hér, að mínu mati, liggur lykilkosturinn við örþjónustuarkitektúr. En förum í röð.
Höldum áfram á næsta stig í þróun upplýsingakerfa - í þjónustumiðaða arkitektúr SOA. Svo á einhverjum ákveðnum tímapunkti lögðum við áherslu á vöruna okkar langlífa þjónustu - langlífur í þeim skilningi að þegar farið er á milli útgáfur vöru eru líkur á að líftími þjónustunnar verði lengri en líftími næstu útgáfu vörunnar. Það væri rökrétt að breyta þeim alls ekki - við Það sem skiptir máli er hraði skipta yfir í næstu útgáfu. En því miður, við neyðumst til að gera stöðugar breytingar á þjónustu - og hér virkar allt fyrir okkur, DevOps venjur, gámavæðing og svo framvegis - allt sem kemur upp í hugann. En þetta eru samt ekki örþjónustur!
Örþjónustur sem leið til að berjast gegn flóknum... stillingastjórnun
Og hér getum við loksins haldið áfram að skilgreina hlutverk örþjónustu - þetta er nálgun sem einfaldar vörustillingarstjórnun. Nánar lýsir virkni hverrar örþjónustu nákvæmlega viðskiptaaðgerðinni inni í vörunni samkvæmt lénslíkaninu - og þetta eru hlutir sem lifa ekki í skammvinnri útgáfu, heldur í langlífu viðskiptatækifæri. Og umskiptin yfir í næstu útgáfu vörunnar gerast bókstaflega óséður - þú breytir/bætir við einni örþjónustu, og kannski bara samspili þeirra, og skyndilega finnurðu sjálfan þig í framtíðinni og skilur eftir grátandi keppinauta sem halda áfram að hoppa á milli útgáfur af einlitar þeirra. Ímyndaðu þér nú að það sé nokkuð mikið magn af örþjónustu með fyrirfram skilgreindum viðmótum og viðskiptagetu. Og þú kemur og byggir uppbyggingu vörunnar þinnar úr tilbúnum örþjónustu - einfaldlega með því að teikna skýringarmynd, til dæmis. Til hamingju - þú hefur vettvang - og nú geturðu laðað að þér fyrirtæki. Draumar Draumar.
Niðurstöður
- Arkitektúr kerfisins ætti að ráðast af líftíma íhluta þess. Ef íhlutur býr innan vöruútgáfu er ekkert vit í að auka flókið kerfi með því að nota örþjónustuaðferð.
- Örþjónustuarkitektúr ætti að byggjast á lénslíkaninu - vegna þess að viðskiptatækifærið er langlífasta lénið
- Afhendingaraðferðir (DevOps praxis) og hljómsveitarsetning eru ein mikilvægustu fyrir örþjónustuarkitektúr - af þeirri ástæðu að aukinn hraði breytinga á íhlutum gerir auknar kröfur um hraða og gæði afhendingar
Heimild: www.habr.com