Ek wou vir 'n lang tyd 'n artikel oor die onderwerp van mikrodiensargitektuur skryf, maar twee dinge het my bly stop - hoe verder ek in die onderwerp gedompel het, hoe meer het dit vir my gelyk of dit wat ek weet voor die hand liggend is, en wat ek doen' t weet moet bestudeer en bestudeer word. Aan die ander kant dink ek dat daar reeds iets is om onder 'n wye gehoor te bespreek. So alternatiewe menings is welkom.
Conway se wet en die verhouding tussen besigheid, organisasie en inligtingstelsel
Weereens sal ek myself toelaat om aan te haal:
"Enige organisasie wat 'n stelsel ontwerp (in die breë sin) sal 'n ontwerp ontvang waarvan die struktuur die struktuur van die spanne in daardie organisasie herhaal."
— Melvyn Conway, 1967
Na my mening sal hierdie wet meer waarskynlik verband hou met die uitvoerbaarheid om 'n besigheid te organiseer, eerder as direk met die inligtingstelsel. Kom ek verduidelik met 'n voorbeeld. Kom ons sê ons het 'n redelik stabiele besigheidsgeleentheid met 'n lewensiklus van so 'n lengte dat dit sin maak om 'n onderneming te organiseer (dit is nie 'n tikfout nie, maar ek hou baie van hierdie term wat ek gesteel het sal organisatories en prosessueel met hierdie besigheid ooreenstem.
Besigheidsoriëntering van inligtingstelsels
Kom ek verduidelik met 'n voorbeeld. Kom ons sê daar is 'n besigheidsgeleentheid om 'n besigheid te organiseer wat pizza verkoop. In die V1-weergawe (kom ons noem dit vooraf-inligting), was die maatskappy 'n pizzeria, 'n kasregister en 'n afleweringsdiens. Hierdie weergawe het lank geleef in toestande van lae omgewingsveranderlikheid. Toe kom weergawe 2 om dit te vervang - meer gevorderd en in staat om 'n inligtingstelsel in sy kern te gebruik vir besigheid met 'n monolitiese argitektuur. En hier is, myns insiens, bloot 'n verskriklike onreg in verhouding tot die monoliete - beweerde monolitiese argitektuur stem nie ooreen met die domein besigheidsmodel nie. Ja, as dit so was, sou die stelsel glad nie kon werk nie – in stryd met dieselfde Conway se wet en gesonde verstand. Nee, monolitiese argitektuur is ten volle in ooreenstemming met die sakemodel op hierdie stadium van besigheidsontwikkeling – ek bedoel natuurlik die stadium wanneer die stelsel reeds geskep en in werking gestel is. Dit is 'n absoluut wonderlike feit dat ongeag die argitektoniese benadering, beide die diensgeoriënteerde argitektuur weergawe 3 en die mikrodienste argitektuur weergawe N ewe goed sal werk. Wat is die vangs?
Alles vloei, alles verander, of is mikrodienste 'n manier om kompleksiteit te bekamp?
Voordat ons voortgaan, kom ons kyk na 'n paar wanopvattings oor mikrodiensargitektuur.
Voorstanders van die gebruik van 'n mikrodiensbenadering argumenteer dikwels dat die opbreek van 'n monoliet in mikrodienste die ontwikkelingsbenadering vereenvoudig deur die kodebasis van individuele dienste te verminder. Na my mening is hierdie stelling volslae onsin. Ernstig, die ooglopende interaksie binne 'n monoliet en homogene kode lyk ingewikkeld? As dit werklik die geval was, sou alle projekte aanvanklik as mikrodienste gebou word, terwyl die praktyk toon dat migrasie van 'n monoliet na mikrodienste baie meer algemeen is. Kompleksiteit verdwyn nie, dit beweeg bloot van individuele modules na koppelvlakke (of dit nou databusse, RPC, API's en ander protokolle is) en orkestrasiestelsels. En dit is moeilik!
Die voordeel van die gebruik van 'n heterogene stapel is ook twyfelagtig. Ek sal nie argumenteer dat dit ook moontlik is nie, maar in werklikheid kom dit selde voor (Vooruitkyk - dit behoort te gebeur - maar eerder as 'n gevolg as 'n voordeel).
Produklewensiklus en dienslewensiklus
Kyk weer na die diagram hierbo. Dit is nie toevallig dat ek die dalende lewensiklus van 'n aparte weergawe van 'n besigheid opgemerk het nie - in moderne toestande is dit die versnelling van die oorgang van 'n besigheid tussen weergawes wat deurslaggewend is vir die sukses daarvan. Die sukses van 'n produk word bepaal deur die spoed van die toets van besigheidshipoteses daarin. En hier, na my mening, lê die belangrikste voordeel van mikrodiensargitektuur. Maar kom ons gaan in volgorde.
Kom ons gaan aan na die volgende fase in die evolusie van inligtingstelsels – na die diensgeoriënteerde argitektuur van SOA. So, op 'n sekere punt het ons in ons produk uitgelig langlewende dienste - langlewend in die sin dat wanneer daar tussen weergawes van 'n produk beweeg word, daar 'n kans is dat die lewensiklus van die diens langer sal wees as die lewensiklus van die volgende weergawe van die produk. Dit sal logies wees om hulle glad nie te verander nie – ons Wat saak maak, is die spoed van oorgang na die volgende weergawe. Maar helaas, ons word gedwing om konstante veranderinge aan dienste aan te bring - en hier werk alles vir ons, DevOps-praktyke, containerisering, ensovoorts - alles wat by ons opkom. Maar dit is steeds nie mikrodienste nie!
Mikrodienste as 'n manier om kompleksiteit te bekamp ... konfigurasiebestuur
En hier kan ons uiteindelik aanbeweeg na die bepalende rol van mikrodienste - dit is 'n benadering wat produkkonfigurasiebestuur vereenvoudig. In meer besonderhede beskryf die funksie van elke mikrodiens presies die besigheidsfunksie binne die produk volgens die domeinmodel - en dit is dinge wat nie in 'n kortstondige weergawe leef nie, maar in 'n langlewende besigheidsgeleentheid. En die oorgang na die volgende weergawe van die produk gebeur letterlik ongemerk - jy verander/voeg een mikrodiens by, en dalk net die skema van hul interaksie, en skielik bevind jy jouself in die toekoms en laat huilende mededingers agter wat aanhou spring tussen weergawes van hul monoliete. Stel jou nou voor dat daar 'n redelike groot volume mikrodienste is met voorafbepaalde koppelvlakke en besigheidsvermoëns. En jy kom bou die struktuur van jou produk uit klaargemaakte mikrodienste – bloot deur byvoorbeeld ’n diagram te teken. Baie geluk - jy het 'n platform - en nou kan jy vir jouself besigheid lok. Drome Drome.
Bevindinge
- Die argitektuur van die stelsel moet bepaal word deur die lewensiklus van sy komponente. As 'n komponent binne 'n produkweergawe woon, is dit geen sin om die kompleksiteit van die stelsel te verhoog deur 'n mikrodiensbenadering te gebruik nie.
- Mikrodiensargitektuur moet op die domeinmodel gebaseer wees - want die besigheidsgeleentheid is die langlewende domein
- Afleweringspraktyke (DevOps-praktyke) en orkestrasie is een van die belangrikste vir mikrodiensargitektuur - om die rede dat die toename in die tempo van verandering van komponente verhoogde eise stel aan die spoed en kwaliteit van aflewering
Bron: will.com