Hallo, habr. Inskrywing vir 'n nuwe kursusstroom is tans oop by OTUS . Op die vooraand van die begin van die kursus wil ek my oorspronklike artikel met jou deel.
Inleiding
Die keuse van argitektoniese styl is een van die fundamentele tegniese besluite wanneer 'n inligtingstelsel gebou word. In hierdie reeks artikels stel ek voor om die gewildste argitektoniese style vir boutoepassings te ontleed en die vraag te beantwoord wanneer watter argitektoniese styl die meeste verkieslik is. In die proses van aanbieding sal ek probeer om 'n logiese ketting te teken wat die ontwikkeling van argitektoniese style van monoliete tot mikrodienste verduidelik.
'N bietjie geskiedenis
As jy ontwikkelaars probeer vra: "Hoekom het ons mikrodienste nodig?", sal jy 'n verskeidenheid antwoorde kry. Jy sal hoor dat mikrodienste skaalbaarheid verbeter, kode makliker maak om te verstaan, foutverdraagsaamheid verbeter, en soms sal jy hoor dat hulle jou toelaat om "jou kode skoon te maak." Kom ons kyk na die geskiedenis om die doel agter die ontstaan van mikrodienste te verstaan.
Kortom, mikrodienste in ons huidige begrip het soos volg ontstaan: in 2011 het James Lewis, deur die werk van verskeie maatskappye te ontleed, die aandag gevestig op die ontstaan van 'n nuwe "mikro-app"-patroon, wat SOA geoptimaliseer het in terme van die versnelling van die ontplooiing van dienste. Ietwat later, in 2012, by 'n argitektuurberaad, is die patroon herdoop na mikrodiens. Dus, die aanvanklike doelwit van die bekendstelling van mikrodienste was om die berugte te verbeter tyd om te bemark.
Mikrodienste was in 2015 op die hype-golf. Volgens sommige studies was nie 'n enkele konferensie voltooi sonder 'n verslag oor die onderwerp van mikrodienste nie. Boonop was sommige konferensies uitsluitlik aan mikrodienste gewy. Deesdae begin baie projekte hierdie argitektoniese styl gebruik, en as die projek tonne verouderde kode bevat, word migrasie na mikrodienste waarskynlik aktief uitgevoer.
Ten spyte van al die bogenoemde, kan 'n redelik klein aantal ontwikkelaars steeds die konsep van "mikrodiens" definieer. Maar ons sal 'n bietjie later hieroor praat ...
Monoliet
Die argitektoniese styl wat mikrodienste kontrasteer, is die monoliet (of alles-in-een). Dit maak waarskynlik nie sin om te sê wat 'n monoliet is nie, so ek sal dadelik die nadele van hierdie argitektoniese styl lys, wat die verdere ontwikkeling van argitektoniese style geïnisieer het: grootte, konnektiwiteit, ontplooiing, skaalbaarheid, betroubaarheid en rigiditeit. Hieronder stel ek voor om elkeen van die tekortkominge afsonderlik te kyk.
Grootte
Die monoliet is baie groot. En dit kommunikeer gewoonlik met 'n baie groot databasis. Die toepassing word te groot vir een ontwikkelaar om enigsins te verstaan. Slegs diegene wat baie tyd spandeer het om aan hierdie kode te werk, kan goed met die monoliet werk, terwyl beginners baie tyd sal spandeer om die monoliet te probeer uitvind en daar is geen waarborg dat hulle dit sal uitvind nie. Gewoonlik, wanneer daar met 'n monoliet gewerk word, is daar altyd 'n "voorwaardelike" senior wat die monoliet min of meer goed ken en die hande van ander nuwe ontwikkelaars binne 'n jaar en 'n half slaan. Natuurlik is so 'n voorwaardelike senior 'n enkele punt van mislukking, en sy vertrek kan lei tot die dood van die monoliet.
Verbondenheid
Die monoliet is 'n "groot modderbal", veranderinge wat tot onvoorspelbare gevolge kan lei. Deur veranderinge op een plek aan te bring, kan jy die monoliet op 'n ander beskadig (dieselfde "jy het jou oor gekrap, *@ het afgeval"). Dit is te wyte aan die feit dat die komponente in die monoliet baie komplekse en, bowenal, nie-vanselfsprekende verwantskappe het.
Ontplooiing
Die ontplooiing van 'n monoliet, as gevolg van die komplekse verhoudings tussen sy komponente, is 'n lang proses met sy eie ritueel. So 'n ritueel is gewoonlik nie heeltemal gestandaardiseer nie en word "mondeling" oorgedra.
Skaalbaarheid
Monoliet-modules kan teenstrydige hulpbronbehoeftes hê, wat vereis dat 'n kompromie aangegaan word in terme van hardeware. Stel jou voor dat jy 'n monoliet het wat bestaan uit dienste A en B. Diens A is veeleisend op die grootte van die hardeskyf, en diens B is veeleisend op RAM. In hierdie geval moet óf die masjien waarop die monoliet geïnstalleer is, die vereistes van beide dienste ondersteun, óf jy sal een van die dienste kunsmatig moet deaktiveer.
Nog 'n voorbeeld (meer klassiek): diens A is baie meer gewild as diens B, so jy wil hê daar moet 100 dienste A en 10 dienste B wees. Weereens, twee opsies: óf ons ontplooi 100 volwaardige monoliete, óf op sommige dan dienste B sal met die hand gedeaktiveer moet word.
Betroubaarheid
Aangesien alle dienste saam geleë is, as die monoliet val, val alle dienste gelyktydig. Trouens, dit is dalk nie so erg nie, daar sal ten minste geen gedeeltelike mislukkings in 'n verspreide stelsel wees nie, maar aan die ander kant, as gevolg van 'n fout in funksionaliteit wat deur 0.001% van gebruikers gebruik word, kan jy al die gebruikers verloor van jou stelsel.
Traagheid
Weens die grootte van die monoliet is dit moeilik om na nuwe tegnologieë oor te skakel. Gevolglik is die behoud van dieselfde senior 'n aparte taak. Die tegnologiestapel wat aan die begin van 'n projek gekies word, kan 'n blok word wat die ontwikkeling van die produk belemmer.
Gevolgtrekking
Volgende keer sal ons praat oor hoe mense probeer het om hierdie probleme op te los deur na komponente en SOA te beweeg.
Lees meer:
Bron: will.com