Hvorfor mikrotjenester har brug for begivenhedsdrevet arkitektur

0
180

Joe McKendrickSkrevet af Joe McKendrick, bidragyder Joe McKendrick Joe McKendrick Bidragyder

Joe McKendrick er forfatter og uafhængig analytiker.

Fuld biografi Udgivet i Service Oriented den 11. februar 2022 | Emne: Enterprise Software

Mikrotjenester lover at hjælpe med at nedbryde monolitiske applikationer og muliggøre ensartet levering af tjenester. Men de kan ikke klare opgaven uden hjælp. Det er her begivenhedsdrevet arkitektur (EDA) kommer i spil.

cityscape-the-vessel-hudson-yards-nyc-dec-2021-photo-by-joe-mckendrick.jpg

Foto: Joe McKendrick

I følgende spørgsmål og svar giver Jonathan Schabowsky, Field CTO i Solace, større indsigt i voksende konvergens af mikrotjenester med EDA. og hævder, at en sand forståelse af det vil være afgørende for organisationer, der ønsker at få mest muligt ud af deres mikroservice-baserede forretningsapplikationer.

Spørgsmål: Hvordan ser du industrien med hensyn til indførelse af mikrotjenester?

Schabowsky: Vi ser, at flere mikrotjenester bliver bygget ind i transformationsprojekter, der nedbryder monolitiske applikationer til selvstændige, uafhængigt implementerede tjenester. Den seneste O'Reilly-undersøgelse viser, at 61 % af virksomhederne har taget mikrotjenester til sig. Efter min erfaring er det dog kun en lille delmængde af disse virksomheder, der har været i stand til at inkorporere begivenhedsdrevne mikrotjenester i det arbejde.

Spørgsmål: Undersøgelsen tyder også på, at tæt på 40 % endnu ikke har taget mikrotjenester til sig på en dybtgående måde. Hvad er der tale om?

Schabowsky:  Anvendelsen af ​​mikrotjenester er selvfølgelig mere kompleks, end man kan se. Faktisk bringer det en masse problemer med sig – det kan være skrøbeligt og ikke falde godt sammen med eksisterende gamle økosystemer. Ikke alle mikrotjenester er identiske og leverer ikke altid den forbedrede skalerbarhed og smidighed, der er lovet.

En stor barriere er tjenestenedbrydningsparadokset – jo mindre mikrotjenesterne er, jo flere tjenester kræves, hvilket fører til stabilitets- og ydeevneproblemer på grund af typiske distribuerede systemproblemer såsom netværksforsinkelse. På grund af dette kan brugeroplevelsen også lide. Der er en balance mellem dekomponering og en arkitektur, der minimerer latens og maksimerer ydeevnen.

Sp: Er ældre integration en udfordring for at opfylde en mikroservicearkitektur?

Schabowsky:  Her er afbrydelsen – mange eksisterende systemer lever på stedet, mens mikrotjenester kan leve i private og offentlige skyer. Evnen for data til at transitere wide area networks, som ofte er ustabile og uforudsigelige, kan være vanskelig og tidskrævende. Læg dertil de udfordringer, der skabes af tingenes internet, big data, mobile enheder. Dette skaber betydelige risici for mikroserviceinitiativer.

Ældre systemer er ikke hurtige og nemme at opdatere, men på bagsiden skal mikrotjenester være hurtige og fleksible. Ældre implementeringer er afhængige af aldrende kommunikationsprotokoller, mens mikrotjenester er afhængige af API'er og åbne protokoller. De fleste ældre systemer vil blive implementeret på stedet, mens de fleste mikrotjenester lever i skyen. Nyere systemer såsom IoT-netværk bruger højt specialiserede protokoller, men de fleste mikrotjenesters API'er og rammer understøtter dem ikke som standard. Hændelsesdrevet arkitektur løser disse uoverensstemmelser mellem ældre systemer og mikrotjenester.

Sp: Beskriv venligst, hvordan en hændelsesdrevet arkitektur fungerer i en mikroservice-indstilling.

Schabowsky:  EDA tager data fra at være statiske til flydende. For eksempel sidder fast i hvile i en database, der er låst under et API, for at være fuldt i bevægelse – forbrugsdygtig, da forretningskritiske begivenheder sker i realtid. RESTful Microservices alene er ikke nok.

Sp: Giv os et eksempel på en begivenhedsdrevet arkitektur på arbejde.

Schabowsky: Forestil dig at implementere en marketingkampagne for et nyt bankudbudt kreditkort. Med en EDA kan du nemmere fordøje kontooprettelsesbegivenheder – såsom åbningssaldi og adresser – og bruge metadataene i opfølgende marketingindsatser. Andre virksomheder kan ved at kombinere EDA og mikrotjenester bygge højt distribuerede, skalerbare, tilgængelige, fejltolerante og udvidelige systemer, der er i stand til at forbruge, behandle, aggregere og korrelere store mængder begivenheder eller information i realtid.< br>
Moderne begivenhedsplatforme skal også assistere DevOps-automatisering og levere en næsten udelukkende selvbetjeningsproces for udviklere. Virksomheder skal være i stand til at følge strømmen i en verden i hastig forandring. De har brug for applikationer, der kan tilpasse sig deres behov, og begivenhedsdrevne mikrotjenester muliggør det.

Sp: Hvad med værktøjet til begivenhedsdrevne mikrotjenester? Er den klar?

Schabowsky:  Værktøjet er på plads til synkrone anmodnings-/svar-mikrotjenester, men dataindsamling og kommunikation er desværre blevet stærkt forsømt, hvilket har betydet, at værktøjet til asynkrone hændelsesdrevne interaktioner mellem mikrotjenester nu halter alvorligt bagefter. Mange gateways og servicemasker eller API-administrationsløsninger har fokuseret på synkrone anmodnings-/svarudvekslingsmønstre. Fangsten er, at disse værktøjer ikke integreres med ældre systemer.

De begivenheds-/meddelelsesværktøjer, vi historisk set har set derude, er ikke kompatible med nutidens agile udviklingstilgange og fungerer ikke godt inden for DevOps eller selvbetjeningsmiljøer. Men det er eventing/messaging, der håndterer karakteristikaene ved distribueret computing bedst. Den mangel på begivenheds-/meddelelsesværktøjer afholder organisationer fra at omfavne begivenhedsdrevet tænkning og bruge begivenhedsdrevet arkitektur til at frigøre potentialet i mikroservicearkitektur.

Sp: Er det her, orkestrering kommer ind?< /strong>

Schabowsky: Som jeg nævnte med tjenestenedbrydningsparadokset, jo mindre tjenesten er, jo mindre værdi tilbyder den diskret slutbrugeren. Den sande værdi kommer fra orkestrering af disse mikrotjenester. Tænk på komponister, der skaber noder, der involverer en bred vifte af instrumenter. Tænk derefter på hvert partitur og musiker som en mikroservice, som en del af en kompleks symfoni. En sådan orkestrering er påkrævet i en virksomhed med mange komplekse applikationer. En mikrotjeneste kan producere en begivenhed, men kontrollerer ikke, hvornår den vil blive behandlet – dette er op til andre tjenester. Dette kræver orkestrering af mikrotjenester.

Datacentre | Sky | Big Data Analytics | Innovation | Teknik og arbejde | Samarbejde