Brug af de rigtige værktøjer og mønstre for begivenhedsstyrede arkitekturer

Begivenhedsstyrede arkitekturer understøtter effektiv produktion og forbrug af begivenheder, som kommunikerer ændringer af system- eller applikationstilstand. Disse arkitekturer aktiverer fleksible forbindelser mellem systemer og understøtter processer og næsten realtidsopdateringer, der fungerer på tværs af systemer. Selvom fordelene ved begivenhedsstyrede arkitekturer er nemme at se, er implementeringsdetaljer ikke altid så tydelige. Hvilke funktioner skal du overveje i begivenhedsstyrede arkitektoniske mønstre? Hvilke specifikke problemer løser disse mønstre? Hvilke særlige overvejelser gælder for dine løsninger, og hvad er de optimale mønstre til at håndtere dem?

Denne vejledning præsenterer mønstre, der bruges til at opbygge optimale begivenhedsstyrede arkitekturer, når du arbejder med Salesforce-teknologier. Den diskuterer også begivenhedsværktøjer, der er tilgængelige fra Salesforce, og leverer værktøjanbefalinger til et udvalg af anvendelsessituationer. Hvis du ønsker oplysninger om integrationer på dataniveau, der involverer Salesforce, kan du se vores Dataintegration Decision Guide.

• Brug begivenhedsstyrede arkitekturer til processer, der ikke kræver synkrone svar på anmodninger. De mønstre, der er skitseret i denne vejledning, er designet til dataensartethed, skalerbarhed og genbrug, hvilket hjælper med at holde teknisk gæld på et minimum, efterhånden som din organisations applikationslandskab udvikler sig. (Se Well-Architected - Throughput for at få flere oplysninger).

• Hvis MuleSoft eller en anden Enterprise Service Bus-løsning (ESB) er en del af dit eksisterende landskab, skal du bruge den, hvor det er muligt. Disse løsninger er beregnet til at understøtte begivenhedsstyrede arkitektoniske mønstre og har effektive funktioner, der gør det muligt for dig at genbruge integrationer på tværs af din virksomhed.

• Brug Pub/Sub API til fremtidige udgivelses-/abonnementsmønstre i stedet for at opbygge dine egne begivenhedshandlers ved brug af andre API'er, herunder Streaming API. Nu da Pub/Sub API generelt er tilgængelig, kan du bruge det til alle nye udgivelses-/abonnementsmønstre. Planlæg at migrere eksisterende begivenhedskommunikation ved brug af andre platforms-API'er, f.eks. Streaming API eller tilpassede Apex, til Pub/Sub API, når det er muligt at gøre det.

• Platformsbegivenheder og Change Dataregistrering (CDC) er de foretrukne mekanismer til udgivelse af registrerings- og feltændringer, der skal forbruges af andre systemer. Vi anbefaler ikke brug af PushTopic og generiske begivenheder til nye implementeringer. Salesforce vil fortsætte med at understøtte PushTopic og generiske begivenheder inden for de aktuelle funktionelle funktioner, men planlægger ikke at foretage yderligere investeringer i denne teknologi.

	Salesforce Platform er en omfattende, AI-drevet platform, der forener medarbejdere, autonome AI-agenter, firmadata og applikationer i et enkelt, betroet system for at forbedre produktiviteten og kundeoplevelsen. Den aktiverer oprettelsen af en "agentvirksomhed" ved at tilslutte Customer 360, Data Cloud og Slack til end-to-end-automatisering.
	MuleSoft er Salesforces førende integrationsplatform, der gør det muligt for organisationer at tilslutte applikationer, data og enheder på tværs af lokale og cloudmiljøer. MuleSoft er en platform, der giver it-platforme mulighed for at låse data op på tværs af systemer, udvikle skalerbare integrations- og automatiseringsstrukturer og oprette differentierede, tilsluttede oplevelser – hurtigt.

Begivenhedsstyrede arkitekturer (EDA'er) anbefales til scenarier, der kræver adviseringer i næsten realtid, distribution af behandlingsbelastning for højvolumen eller komplekse meddelelser og integration af systemer som IoT og mobilenheder, der kræver forbindelsesstabilitet gennem kø. EDA'er bør dog ikke implementeres for processer, der kræver øjeblikkelige, synkrone menneskelige svar, da de er designet til asynkron kørsel. De passer heller ikke godt, hvis kildedata ændres så sjældent, at et enklere mønster som batchbehandling ville være tilstrækkeligt.

Her er der flere almindelige scenarier, der ofte passer godt til en begivenhedsstyret arkitektur:

De fleste store organisationer har komplekse it-landskaber, der har en kombination af systemer med forskellige funktioner. Det er muligt, eller måske sandsynligt, at din organisation har forældede systemer, der ikke understøtter begivenhedsstyrede integrationer. Du kan også have anvendelsessituationer, hvor begivenhedsstyrede integrationer ikke giver mening, selvom systemerne understøtter dem (f.eks. SFTP-filoverførsler fra tredjeparter). Hvis du tager et skridt tilbage og ser på din organisations it-landskab som helhed, er det sandsynligt – ligesom med andre arkitektoniske løsninger – at du anvender en blanding af mønstre til at understøtte forskellige scenarier. Når du beslutter at gøre begivenhedsstyret til din foretrukne tilgang til integrationer, kan du tænke på det som et andet værktøj i din værktøjskasse. Det kan og bør bruges i de rigtige scenarier, men det er ikke en tilgang, der skal håndhæves på alle systemer. Udvikling af en omfattende integrationsstrategi vil hjælpe dig med at bestemme, hvornår de mønstre, der er beskrevet i denne vejledning, kan eller kan ikke være relevante.

Mange scenarier kræver begivenhedsstyrede arkitekturer, og i nogle scenarier vil begivenhedsstyrede arkitekturer fungere, selvom de ikke passer bedst. Men i nogle scenarier skal begivenhedsstyrede arkitekturer ganske enkelt ikke bruges. Her er nogle spørgsmål for beslutningspunkter, der kan hjælpe dig med at identificere disse scenarier:

Der findes en række begivenhedsstyrede arkitekturmønstre. Nogle er generelle formålsmønstre, der kan anvendes i anvendelsessituationer, der ikke har nogen særlige krav udover at være begivenhedsstyret; se f.eks. Velarkitekt - interoperabilitet. Andre mønstre er gældende for de specifikke anvendelsessituationer, der er diskuteret her, f.eks. integrationer, der involverer store datamængder, eller scenarier, der kræver længere meddelelsesbevarelse.

Tabellen nedenfor sammenligner attributter for de mønstre, der er skitseret i dette dokument. Brug den som en hurtig reference, når du har brug for at identificere potentielle mønstre for en given anvendelsessituation.

Salesforce tilbyder flere værktøjer til at hjælpe dig med at håndtere dine begivenhedsstyrede anvendelsessituationer. Denne tabel indeholder en oversigt over tilgængelige værktøjer på højt niveau.

Når en kritisk registrering ændrer tilstand i en kerneapplikation – f.eks. flytter en bestillings status fra "Behandler" til "Forsendt" – kræver flere andre systemer sandsynligvis en advisering næsten i realtid for at udføre deres respektive opgaver. Der opstår et specifikt forretningsbehov, når mængden af disse ændringer er høj, og meddelelserne er komplekse, hvilket gør traditionelle punkt-til-punkt-integrationer besværlige og vanskelige at vedligeholde. Etablering af skrøbelige, tilpassede forbindelser for hver afhængig applikation fører til teknisk gæld og forhindrer organisationens mulighed for at skalere hurtigt. Der kræves en robust integrationstilgang til at administrere disse hyppige datasynkroniseringer uden at knytte kildesystemet direkte til hvert forbrugersystem.

Diagrammet nedenfor viser et typisk udgivelses-/abonnementsmønster med flere udgivere og abonnenter, der deler data gennem en begivenhedsbus. Dette grundlæggende mønster udgør grundlaget for de mere specifikke mønstre, der kan findes i resten af denne vejledning. Nogle nøgleegenskaber for dette mønster er:

• Der er ingen direkte forbindelse mellem udgivere og abonnenter. Udgivere sender ganske enkelt meddelelser til en begivenhedsbus, som udsender dem til ethvert andet system, der ønsker at lytte til dem.

• Det samme system kan være både en udgiver og en abonnent.

• Systemer kan udgive eller abonnere på flere typer af begivenheder.

• Som med alle mønstre i denne vejledning falder udgiv / abonnere mønsteret i en generel integration mønster kategori kendt som fjernprocedure kald (RPI) eller simpelthen "fire og glemme."

Når en organisation har brug for at sende øjeblikkelige opdateringer til et stort antal klientapplikationer, f.eks. push-adviseringer eller sms-meddelelser til mobilenheder, bliver den traditionelle proces med at oprette entydige transmissioner for hver enkelt modtager hurtigt til en flaskehalse med skalerbarhed. Kerneforretningsbehovet i dette tilfælde er den hurtige, højtydende distribution af et enkelt stykke oplysninger – f.eks. en kontoadvarsel eller en kritisk serviceændringsadvisering – til adskillige slutpunktsapplikationer samtidigt. En strømlinet tilgang til at opfylde dette krav involverer distribution af alle meddelelser gennem en enkelt kø, der fungerer som det centrale punkt for begivenhedsoplysninger for alle forbrugersystemer. Denne tilgang forbedrer ydeevnen ved at eliminere behovet for at administrere mange separate meddelelseskopier.

Med udløbsmønsteret leveres meddelelser til en eller flere destinationer (dvs. lytter klienter eller abonnenter) gennem en enkelt meddelelseskø. Abonnenter henter den samme meddelelse fra køen i stedet for deres egen entydige kopi. (Bemærk, at selvom dette forbedrer ydeevnen, kan det også gøre det vanskeligere at bekræfte, om en bestemt abonnent har modtaget meddelelsen).

Nogle begivenhedsscenarier er kendetegnet ved en væsentlig tilstrømning af meddelelsesvolumen, der truer med at overvælde kapaciteten af synkronisering og transformationsprocesser, eller ved kompleks logik med flere trin, der kræves for at behandle og transformere begivenhedsdata.

Nogle eksempler omfatter:

• Sæsonudsving: Der kan være spidser i mængden, som online detailhandlere oplever, når et udvalg af deres produkter er "i sæson". Når et stort antal kunder foretager køb samtidigt, kan antallet af genererede begivenheder midlertidigt overstige kapaciteten af synkronisering og transformationsprocesser. Se Well-Architected - Data Handling for at få flere oplysninger.

• Sag eller skadesstyring: Servicebaserede firmaer kan opleve stigninger i antallet af sager eller skader under afbrydelser.

• Komplekse datatransformationer: Organisationer, der kræver kompleks logik for at transformere meddelelser, er ofte bekymrede over, at begivenheder genereres hurtigere, end de kan transformeres.

Dette mønster håndterer udfordringen ved meddelelser, der genereres hurtigere, end de kan transformeres. Den sikrer, at store mængder meddelelser og påkrævede datamanipulationer kan håndteres pålideligt ved at indarbejde en streamingmeddelelsesplatform og segmentere meddelelseshåndteringslogik i dedikerede komponenter.

Mønsteret Videregivne meddelelser fungerer ved at segmentere meddelelseshåndteringslogik i flere komponenter:

• En komponent håndterer meddelelsesdistribution og bestemmer de krævede transformationer og den endelige destination.

• Et separat sæt komponenter håndterer forskellige lag af meddelelsestransformation (f.eks. felttilknytninger, objektrelationer osv.).

• Den sidste komponent skriver den endelige, redigerede meddelelse ud.

Nogle producenter genererer en kontinuerlig stream af begivenheder. Et almindeligt eksempel er mediestrømning, som involverer brugerinteraktioner, der naturligt forekommer som særskilte begivenheder. Flere systemer skal reagere på den samme brugeradfærd samtidigt uden at blokere kerne streamingoplevelsen.

Overvej begivenhederne for en musikstreamingplatform. Disse kan inkludere:

• Spor startede/pausede/sprungne begivenheder

• Lytning af sessionsbegivenheder med tidsstempler

• Afspilningslisteoprettelse/ændringer

• Sociale delingsbegivenheder

• Download til offline lytte

I streamingmønsteret får abonnenter adgang til hver begivenhedsstream og behandler begivenhederne i den nøjagtige rækkefølge, som de modtages i. Unikke kopier af hver meddelelsesstream sendes til hver abonnent, hvilket gør det muligt at levere abonnentspecifikt indhold og at identificere, hvilke abonnenter der modtager hvilke streams.

Hvis en stream skal give mening, skal alle dens begivenheder og deres tilknyttede meddelelser være i den korrekte rækkefølge. Hvis du kører data i en stream fra andre systemer, skal du indarbejde yderligere bestillingslogik som en del af designprocessen.

Køanvendelsessituationer findes overalt. Eksempler omfatter:

• Internetforbindelser af lav kvalitet: Field Service-organisationer eller andre organisationer, hvor teams med mobilenheder har brug for at arbejde i områder med lav kvalitet eller intermitterende internetadgang, drager fordel af køen, da applikationer på disse enheder kan oprette forbindelse til deres køer og hente relevante meddelelser, når forbindelsen gendannes.

• Meddelelsesbuffer: Når meddelelsesvolumen lejlighedsvist overskrider en abonnents behandlingskapacitet, og øget forsinkelse ikke vil skabe yderligere problemer, kan køer være en buffer til at lagre overskydende meddelelser og forhindre datatab.

• Transportstyring: Logistiske organisationer, der har brug for at overvåge deres flåde, kan bruge dette mønster til at se de ruter, som hvert køretøj tager i næsten realtid, og sikre, at chauffører er så effektive som muligt.

• IoT-enheder: Producenter bruger ofte systemer, der genererer hurtige datastreams, og disse streams kan have downstream-effekter på yderligere systemer. Dette mønster kan bruges til at identificere sekvenser af begivenheder, der kræver menneskelig intervention, før der forekommer katastrofale fejl, der strækker sig over flere systemer.

I kømønsteret sender producenter meddelelser til køer, som bevarer meddelelserne, indtil abonnenter henter dem. De fleste meddelelseskøer følger First In, First Out-rækkefølgen (FIFO) og sletter hver meddelelse, når den hentes. Hver abonnent har en entydig kø, som kræver yderligere opsætningstrin, men gør det muligt at garantere levering og identificere, hvilke abonnenter der modtog hvilke meddelelser.

På grund af den asynkrone karakter af kømønsteret kan der være en lang forsinkelse mellem en meddelelse, der føjes til en kø, og den meddelelse, der hentes. Køer kræver hukommelse eller lagerplads for at indeholde deres meddelelser, så de ikke kan vokse uendeligt, hvilket betyder, at en abonnent, der er offline uendeligt, kan forårsage en fejl, hvis der opbygges nok meddelelser i køen. Meddelelsesbuffering kan have den samme effekt, hvis abonnentbehandlingstider bliver for lange, hvilket medfører, at der opbygges store mængder meddelelser i deres køer. For at reducere disse risici skal du udføre en grundig analyse af lagerkravene for alle meddelelseskøer og om nødvendigt designe processer, der vil fjerne og inaktivere køer, hvis meddelelser ikke hentes inden for en angivet mængde tid, eller når de når en foruddefineret mængde.

Selvom du er fuldt overbevist om, at en begivenhedsstyret arkitektur er det rigtige for din organisation, starter du måske med et landskab, der allerede har et stort antal punkt-til-punkt-integrationer. Det kan være vanskeligt at få finansiering til et projekt for at erstatte alle dine integrationer på en gang, og det kan endda ikke være muligt at bruge en begivenhedsstyret arkitektur direkte med nogle ældre systemer. I disse scenarier kan du tage en trinvis tilgang til at migrere til en mere løst tilknyttet arkitektur ved først at konvertere de mest forretningskritiske applikationer og derefter konvertere andre systemer, efterhånden som de opdateres eller erstattes i fremtidige projekter. Denne tilgang gør det nemt at føje nye applikationer til begivenhedsbussen og gør det muligt for dit generelle it-landskab at forblive skalerbart og fleksibelt, efterhånden som systemer fortsætter med at blive tilføjet over tid.

Som arkitekter ved vi, at enhver arkitektur leveres med afvejninger. En begivenhedsstyret arkitektur er ingen undtagelse. Mens et landskab fuld af løst sammenkoblede systemer er meget skalerbart og fleksibelt, er der også nogle afvejninger, du skal overveje:

• Generel integrationsstrategi: Uanset hvilke værktøjer og mønstre, du beslutter at bruge, er det vigtigt at starte med at oprette en strategi for, hvordan data deles på tværs af de forskellige systemer i din organisations landskab. Denne strategi bør inkludere din organisations mål for dens data, hvordan data kan deles og mønstre bruges, samt datakilder, mål, strukturer og ejerskab og adgangskrav.

• Support af ældre systemer: Din organisation har muligvis forældede systemer, der ganske enkelt ikke understøtter begivenhedsstyrede arkitekturmønstre. Selvom det kan være muligt at opbygge alternative løsninger (f.eks. med en proces, der fungerer som en gennemgang ved at abonnere på begivenheder og derefter sende outputtet til målsystemet via en anden metode til dataoverførsel), vil du måske overveje andre integrationsmetoder i denne situation.

• Strukturelle ændringer af meddelelser: Når den indledende meddelelsesstruktur er defineret og aftalt mellem udgivere og abonnenter, kan det være vanskeligt at ændre, især hvis abonnenterne er eksterne. Der er flere måder, hvorpå du kan håndtere dette problem. Du kan bruge versionerede slutpunkter, men sørg for at definere og kommunikere en tydelig livscyklus for hver version, så dine udviklere ikke behøver at vedligeholde for mange versioner samtidigt. Hvis Apache Kafka på Heroku er en del af dit landskab, kan du også overveje et skemaregister eller lignende værktøj, men sørg for, at de andre systemer i dit landskab understøtter det (og bruger det) også.

• Fravær af synlighed mellem udgivere og abonnenter: I de fleste begivenhedsstyrede arkitektoniske mønstre er udgivere ikke klar over deres abonnenters status. Så hvis en udgiver sender en vigtig meddelelse, mens alle abonnenter er offline, bliver meddelelsen muligvis aldrig leveret. Du kan håndtere dette problem ved at gøre brug af afspilningsfunktionalitet eller tilføje overflødige abonnenter, der kører på separate servere for alle vigtige meddelelser.

• Ydeevne flaskehalse: Efterhånden som en begivenhedsstyret arkitektur skaleres, kan begivenhedsbussen blive en flaskehals for meddelelseslevering, hvis den bliver overvældet med for mange udgivere, der forsøger at sende meddelelser til for mange abonnenter samtidigt. Du kan håndtere dette ved at øge hukommelsen og behandlingsressourcerne, der er tildelt til begivenhedsbussen, eller ved at bruge flere begivenhedsbusse til at behandle forskellige typer meddelelser parallelt.

Før du implementerer en begivenhedsstyret arkitektur, skal du overveje, om du virkelig skal bruge en. Det forrige afsnit beskriver almindelige forretningsscenarier, der passer godt til hvert begivenhedsstyret arkitekturmønster. Du kan læse mere i Well-Architected - Interoperability. Gennemse Udfordringer, du bør overveje, når du implementerer begivenhedsstyrede arkitekturer for at bestemme, om de mønstre, du har i tankerne, er de bedste til dine specifikke anvendelsessituationer.

Bemærk, at mens de fleste scenarier, der er dækket i denne vejledning, involverer integrationer, kan begivenhedsstyrede arkitekturer også bruges til at sende meddelelser i en enkelt Salesforce-organisation gennem brug af f.eks. platformsbegivenheder. Husk på eventuelle gældende begivenhedstildelingsgrænser, når du designer processer, der bruger platformsbegivenheder som et internt meddelelsessystem.

Anti-mønstre omkring begivenhedsstyrede arkitekturer kommer ofte fra brug af begivenheder som en løsning for intern kommunikation i en Salesforce-organisation. Almindelige anti-mønstre inkluderer:

• Udgivelse af begivenheder fra Apex-udløsere, der er tilknyttet det samme begivenhedsobjekt: Dette resulterer i en uendelig udløserløbe.

• Udgivelse af begivenheder fra Apex, før en DML-transaktion fuldføres: Hvis en transaktion mislykkes og ruller tilbage, vil eventuelle udgivne begivenheder, der har adfærden Udgiv straks ikke blive inkluderet i tilbagerulningsadfærden.

• Udgivelse af begivenheder i forløbet for at orkestrere efterfølgende automatisering: Den bedste måde at koordinere logik på tværs af flere automatiseringer er at bruge underforløb eller Flow Orchestrator.

• Oprettelse af kørselsafhængigheder: Udgiv ikke begivenheder for at lette kommunikationen mellem pakker uden at tage de rigtige trin til at fjerne kørselsafhængigheder.

• Unødvendigt store nyttelast: Når du foretager anmodninger, er det bedst at sende og modtage den mindste mængde data, der er mulig i dataene. Hver handling fra en bruger kan potentielt udløse flere anmodninger, og det er vigtigt, at disse behandles effektivt. Afsendelse af flere data end nødvendigt kan bidrage til langsom transport og øget behandlingstid.

• Uvalgt håndtering af ansøgningsbegivenheder: Når der er flere komponenter, der lytter til en applikationsbegivenhed, skal udviklere sikre, at begivenhedshandleren kun udføres, når den faktisk er ønsket og nyttig. I Lightning Console kan f.eks. komponenter, der er indeholdt på faner, der ikke er fokuserede, stadig lytte, selvom de ikke er synlige. En udvikler kan bruge forskellige teknikker, f.eks. brug af et element i baggrundshjælpeprogrammet som den eneste lytter, eller kald getEnclosingTabId() for at bestemme, om denne forekomst af komponenten er omgivet af den fokuserede fane for at sikre, at hver begivenhed kun håndteres, når den er tiltænkt.

• Brug af platformsbegivenheder udgiver adfærd forkert: Platformsbegivenheder har to udgivelsesadfærd – Udgiv straks og Udgiv efter bekræftelse. Det kan være nyttigt at bruge platformsbegivenheder i realtid til anvendelsessituationer som Logføring, hvor du ønsker at udgive logføringsbegivenheden, uanset om transaktionen lykkes og bekræftes. Men brug Udgiv straks meget omhyggeligt med platformsbegivenheder i realtid. Begivenheder kan forbruges af abonnenter inden for den samme transaktion og forårsage rækkespærringer eller andre løbstilstande.

Når du implementerer en begivenhedsstyret arkitektur, er en af nøglerne til succes at angive standarder for, hvordan selve begivenhederne er designet. Specifikationer vil variere afhængigt af din organisations anvendelsessituationer, men her er nogle generelle retningslinjer:

• Bestem den optimale struktur for dine begivenhedsdata. Mens mindre meddelelsesstørrelser reducerer behandlingstider, kan bombardement af abonnenter med massive mængder af meddelelser forårsage ydeevneflaskehalse. Du skal muligvis gentage på dine data og strukturer for at finde den rigtige balance. MuleSoft og lignende ESB-værktøjer giver mulighed for at designe tilpassede data i de meddelelser, der er tilknyttet dine begivenheder, hvilket kan hjælpe dig med at visualisere datastrukturer for at forbedre ydeevnen på abonnentsiden. (Se Well-Architected - API Management for at få flere oplysninger).

• Tænk over dine processer end-to-end. Sørg for, at du ikke opretter nogen "endeløse løkke"-scenarier, som kan være vanskelige at spore, når integrationerne er udrullet. Et eksempel på dette ville være to systemer, der udgiver begivenheder, når registreringer opdateres, mens de også lytter til hinandens begivenheder, som udløser yderligere udgivne begivenheder, når de behandles.

  Du kan rette denne type anti-mønster ved at føje logik til begge systemer, der sikrer, at ændringer, der er foretaget som et resultat af en begivenhed, der forbruges, ikke resulterer i udgivelse af en ny begivenhed. Du bør også sørge for at dokumentere alle dine begivenheder, deres tilknyttede udløsere og de downstream-systemer, der kan blive påvirket. Brug denne dokumentation som en reference under designsessioner for at hjælpe med at fange endeløse løkker og lignende scenarier så tidligt som muligt. (Se Well-Architected - Process Design for at få flere oplysninger).

• Brug fælles navngivningskonventioner på tværs af systemer. Ensartede navnekonventioner er en bedste fremgangsmåde for al softwareudvikling, herunder begivenhedsstyrede arkitekturer. Brug tid på at dokumentere et sæt standarder for begivenhedsnavne, strukturer, tilknyttede objekter og fejlhåndteringsprocesser for at sikre ensartethed på tværs af systemer. (Se Well-Architected - Design Standards for at få flere oplysninger.)