Hallo, Habr. Vandag gaan ek voort met 'n reeks publikasies wat ek spesifiek geskryf het vir die begin van 'n nuwe stroom van die kursus. .
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.
В ons het met die monoliet gehandel en tot die gevolgtrekking gekom dat die monoliet 'n aantal probleme het: grootte, konnektiwiteit, ontplooiing, skaalbaarheid, betroubaarheid en rigiditeit.
Hierdie keer stel ek voor om te praat oor die moontlikhede om 'n stelsel te organiseer as 'n stel modules/biblioteke (komponent-georiënteerde argitektuur) of dienste (diensgerigte argitektuur).
Komponent-georiënteerde argitektuur
Komponent-georiënteerde argitektuur behels die uitvoering van 'n stelsel as 'n stel komponente wat in beide huidige en toekomstige projekte gebruik kan word. Wanneer 'n stelsel in komponente afgebreek word, word die volgende in ag geneem: hul herbruikbaarheid, hul vervangbaarheid, konteksonafhanklikheid, uitbreidbaarheid, inkapseling en onafhanklikheid.
Met behoorlike gebruik van komponente word die probleem van die "groot bal van vuil" (groot grootte + hoë koppeling) opgelos, en die komponente self kan beide samestellingseenhede (modules, biblioteke) en ontplooiingseenhede (dienste) verteenwoordig. Ontplooiingseenhede word nie altyd na die lopende proses gekarteer nie: 'n webtoepassing en 'n databasis word byvoorbeeld saam ontplooi.
Meestal word monoliete ontwikkel as 'n stel modules. Hierdie benadering lei tot onafhanklike ontwikkeling, maar die probleme van onafhanklike skaal en ontplooiing, foutverdraagsaamheid en onafhanklikheid van die algehele tegnologiestapel bly. Daarom is die module 'n gedeeltelik onafhanklike komponent.
Die grootste probleem met so 'n monoliet is dat die verdeling in modules suiwer logies is en maklik deur ontwikkelaars geskend kan word. 'n Kernmodule kan verskyn, wat geleidelik in 'n vullishoop verander, die grafiek van afhanklikhede tussen modules kan groei, ensovoorts. Om sulke probleme te vermy, moet ontwikkeling uitgevoer word óf deur 'n baie volwasse span, óf onder leiding van 'n "argitek" wat besig is met voltydse kodehersiening en die hande slaan van ontwikkelaars wat die logiese struktuur oortree.
Die "ideale" monoliet is 'n stel logies geskei modules, wat elkeen in sy eie databasis kyk.
Diensgerigte argitektuur
As die stelsel veronderstel is om georganiseer te word in die vorm van 'n stel dienste, dan praat ons van 'n diensgeoriënteerde argitektuur. Die beginsels daarvan is gebruikergesentreerde toepassingsinteroperabiliteit, besigheidsdienshergebruik, tegnologiestapel-onafhanklikheid en outonomie (onafhanklike evolusie, skaalbaarheid en ontplooiing).
Diensgeoriënteerde argitektuur (SOA = diensgeoriënteerde argitektuur) los al die geïdentifiseerde probleme van 'n monoliet op: slegs een diens word geraak wanneer 'n verandering plaasvind, en 'n goed gedefinieerde API ondersteun goeie inkapseling van komponente.
Maar nie alles is so glad nie: SOA skep nuwe probleme. Afgeleë oproepe is duurder as plaaslike, en die herverdeling van verantwoordelikhede tussen komponente het aansienlik duurder geword.
Terloops, die moontlikheid van onafhanklike ontplooiing is 'n baie belangrike kenmerk van die diens. Indien dienste saam of boonop in 'n sekere volgorde ontplooi moet word, kan die stelsel nie as diensgeoriënteerd beskou word nie. In hierdie geval praat hulle van 'n verspreide monoliet (beskou as 'n anti-patroon nie net vanuit die oogpunt van SOA nie, maar ook vanuit die oogpunt van mikrodiensargitektuur).
Diensgeoriënteerde argitektuur word goed ondersteun deur die argitektoniese gemeenskap en verskaffers. Dit impliseer die teenwoordigheid van baie kursusse en sertifisering, goed ontwikkelde patrone. Laasgenoemde sluit byvoorbeeld die bekende ondernemingsdiensbus (ESB = ondernemingsdiensbus) in. Terselfdertyd is ESB 'n bagasie van verskaffers; dit hoef nie noodwendig in SOA gebruik te word nie.
Die gewildheid van diensgerigte argitektuur het 'n hoogtepunt bereik rondom 2008, waarna dit begin afneem het, wat aansienlik meer dramaties geword het ná die koms van mikrodienste (~2015).
Gevolgtrekking
Nadat ons die moontlikhede bespreek het om inligtingstelsels in die vorm van dienste en modules te organiseer, stel ek voor om uiteindelik oor te gaan na die beginsels van mikrodiensargitektuur en veral in die volgende deel aandag te gee aan die verskil tussen mikrodiensargitektuur en diensgeoriënteerde argitektuur.
Bron: will.com