Frontend Micro-Service Mesh: Mestring af Service Discovery og Load Balancing for Globale Applikationer

I det hurtigt udviklende landskab af webudvikling er vedtagelsen af microservices blevet en hjørnesten for at bygge skalerbare, robuste og vedligeholdelige applikationer. Selvom microservices traditionelt har været en backend-bekymring, bringer fremkomsten af microfrontend arkitekturer lignende principper til frontenden. Dette skift introducerer et nyt sæt af udfordringer, især omkring hvordan disse uafhængige frontend-enheder, eller microfrontends, effektivt kan kommunikere og samarbejde. Indtast konceptet med en frontend micro-service mesh, som udnytter principper fra backend service meshes til at administrere disse distribuerede frontend-komponenter. Centralt for denne mesh er to kritiske funktioner: service discovery og load balancing. Denne omfattende guide vil dykke ned i disse koncepter og udforske deres betydning, implementeringsstrategier og bedste praksis for at bygge robuste globale frontend-applikationer.

Forståelse af Frontend Micro-Service Mesh

Før du dykker ned i service discovery og load balancing, er det afgørende at forstå, hvad en frontend micro-service mesh indebærer. I modsætning til traditionelle monolitfrontender, opdeler en microfrontend-arkitektur brugergrænsefladen i mindre, uafhængigt deploybare stykker, ofte organiseret omkring forretningsfunktioner eller brugerrejser. Disse stykker kan udvikles, implementeres og skaleres selvstændigt af forskellige teams. En frontend micro-service mesh fungerer som et abstraktionslag eller en orkestreringsramme, der letter interaktionen, kommunikationen og styringen af disse distribuerede frontend-enheder.

Nøglekomponenter og koncepter i en frontend micro-service mesh inkluderer ofte:

• Microfrontends: De individuelle, selvstændige frontend-applikationer eller -komponenter.
• Containerisering: Bruges ofte til at pakke og implementere microfrontends konsekvent (f.eks. ved hjælp af Docker).
• Orkestrering: Platforme som Kubernetes kan administrere implementeringen og livscyklussen for microfrontend-containere.
• API Gateway / Edge Service: Et fælles indgangspunkt for brugeranmodninger, der dirigerer dem til den relevante microfrontend eller backend-tjeneste.
• Service Discovery: Mekanismen, hvorved microfrontends finder og kommunikerer med hinanden eller med backend-tjenester.
• Load Balancing: Fordeling af indgående trafik på tværs af flere instanser af en microfrontend eller backend-tjeneste for at sikre tilgængelighed og ydeevne.
• Observabilitet: Værktøjer til overvågning, logning og sporing af adfærden af microfrontends.

Målet med en frontend micro-service mesh er at levere infrastrukturen og værktøjerne til at styre kompleksiteten, der opstår fra denne distribuerede natur, og sikre problemfrie brugeroplevelser selv i meget dynamiske miljøer.

Den Afgørende Rolle for Service Discovery

I et distribueret system som en microfrontend-arkitektur skal tjenester (i dette tilfælde microfrontends og deres tilknyttede backend-tjenester) kunne lokalisere og kommunikere med hinanden dynamisk. Tjenester startes, skaleres ned eller genudrulles ofte, hvilket betyder, at deres netværksplaceringer (IP-adresser og porte) kan ændre sig hyppigt. Service discovery er den proces, der gør det muligt for en tjeneste at finde netværksplaceringen af en anden tjeneste, den har brug for at interagere med, uden at kræve manuel konfiguration eller hardcoding.

Hvorfor er Service Discovery afgørende for Frontend Microservices?

• Dynamiske Miljøer: Cloud-native implementeringer er i sagens natur dynamiske. Containere er flygtige, og autoskalering kan ændre antallet af kørende instanser af en tjeneste hvert øjeblik. Manuel IP/port-administration er ikke mulig.
• Afkobling: Microfrontends skal være uafhængige. Service discovery afkobler forbrugeren af en tjeneste fra dens producent, hvilket giver producenterne mulighed for at ændre deres placering eller antal instanser uden at påvirke forbrugerne.
• Modstandsdygtighed: Hvis en instans af en tjeneste bliver usund, kan service discovery hjælpe forbrugere med at finde et sundt alternativ.
• Skalerbarhed: Efterhånden som trafikken stiger, kan nye instanser af en microfrontend eller backend-tjeneste startes. Service discovery gør det muligt at registrere disse nye instanser og straks gøre dem tilgængelige for forbrug.
• Teamautonomi: Teams kan implementere og skalere deres tjenester uafhængigt og vide, at andre tjenester kan finde dem.

Service Discovery-mønstre

Der er to primære mønstre til implementering af service discovery:

1. Klientside Discovery

I dette mønster er klienten (microfrontend eller dens koordinerende lag) ansvarlig for at forespørge et serviceregister for at finde placeringen af den tjeneste, den har brug for. Når den har en liste over tilgængelige instanser, beslutter klienten, hvilken instans den skal oprette forbindelse til.

Sådan virker det:

1. Serviceregistrering: Når en microfrontend (eller dens serverside-komponent) starter, registrerer den sin netværksplacering (IP-adresse, port) med et centraliseret serviceregister.
2. Serviceforespørgsel: Når en klient har brug for at kommunikere med en specifik tjeneste (f.eks. en 'product-catalog' microfrontend har brug for at hente data fra en 'product-api' backend-tjeneste), forespørger den serviceregistret for tilgængelige instanser af målservicen.
3. Klientside Load Balancing: Serviceregistret returnerer en liste over tilgængelige instanser. Klienten bruger derefter en klientside load balancing-algoritme (f.eks. round-robin, mindst forbindelser) til at vælge en instans og fremsætte anmodningen.

Værktøjer og Teknologier:

• Serviceregistre: Eureka (Netflix), Consul, etcd, Zookeeper.
• Klientbiblioteker: Biblioteker leveret af disse værktøjer, der integreres med din frontend-applikation eller ramme til at håndtere registrering og discovery.

Fordele ved Klientside Discovery:

• Enklere infrastruktur: Intet behov for et dedikeret proxylag til discovery.
• Direkte kommunikation: Klienter kommunikerer direkte med serviceinstanser, potentielt lavere latenstid.

Ulemper ved Klientside Discovery:

• Kompleksitet i klienten: Klientapplikationen skal implementere discovery-logik og load balancing. Dette kan være udfordrende i frontend-rammer.
• Tæt kobling med registeret: Klienten er koblet til serviceregistrets API.
• Sprog/Rammespecifik: Discovery-logik skal implementeres for hver frontend-teknologistak.

2. Serverside Discovery

I dette mønster sender klienten en anmodning til en kendt router eller load balancer. Denne router/load balancer er ansvarlig for at forespørge serviceregistret og videresende anmodningen til en passende instans af målservicen. Klienten er uvidende om de underliggende serviceinstanser.

Sådan virker det:

1. Serviceregistrering: I lighed med klientside discovery registrerer tjenester deres placeringer med et serviceregister.
2. Klientanmodning: Klienten sender en anmodning til en fast, velkendt adresse for routeren/load balanceren, der ofte specificerer målservicen efter navn (f.eks. `GET /api/products`).
3. Serverside Routing: Routeren/load balanceren modtager anmodningen, forespørger serviceregistret efter instanser af 'products'-tjenesten, vælger en instans ved hjælp af serverside load balancing og videresender anmodningen til den pågældende instans.

Værktøjer og Teknologier:

• API Gateways: Kong, Apigee, AWS API Gateway, Traefik.
• Service Mesh Proxies: Envoy Proxy (bruges i Istio, App Mesh), Linkerd.
• Cloud Load Balancers: AWS ELB, Google Cloud Load Balancing, Azure Load Balancer.

Fordele ved Serverside Discovery:

• Forenklede klienter: Frontend-applikationer behøver ikke at implementere discovery-logik. De sender bare anmodninger til et kendt slutpunkt.
• Centraliseret kontrol: Discovery- og routing-logik administreres centralt, hvilket gør opdateringer lettere.
• Sproguafhængigt: Virker uanset frontend-teknologistakken.
• Forbedret observabilitet: Centraliserede proxies kan nemt håndtere logning, sporing og metrikker.

Ulemper ved Serverside Discovery:

• Tilføjet hop: Introducerer et ekstra netværkshop gennem proxien/load balanceren, hvilket potentielt øger latenstiden.
• Infrastrukturkompleksitet: Kræver administration af en API Gateway eller proxylag.

Valg af den Rigtige Service Discovery til Frontend Microservices

For frontend microservices, især i en microfrontend-arkitektur, hvor forskellige dele af brugergrænsefladen kan udvikles af forskellige teams ved hjælp af forskellige teknologier, er serverside discovery ofte den mest praktiske og vedligeholdelsesvenlige tilgang. Dette skyldes, at:

• Rammeuafhængighed: Frontend-udviklere kan fokusere på at bygge UI-komponenter uden at bekymre sig om at integrere komplekse service discovery-klientbiblioteker.
• Centraliseret styring: Ansvaret for at opdage og dirigere til backend-tjenester eller endda andre microfrontends kan administreres af en API Gateway eller et dedikeret routinglag, som kan vedligeholdes af et platformsteam.
• Konsistens: En ensartet discovery-mekanisme på tværs af alle microfrontends sikrer ensartet adfærd og lettere fejlfinding.

Overvej et scenario, hvor din e-handelswebsted har separate microfrontends til produktliste, produktdetaljer og indkøbskurven. Disse microfrontends skal muligvis kalde forskellige backend-tjenester (f.eks. `product-service`, `inventory-service`, `cart-service`). En API Gateway kan fungere som det eneste indgangspunkt, opdage de korrekte backend-serviceinstanser for hver anmodning og dirigere dem i overensstemmelse hermed. På samme måde, hvis en microfrontend har brug for at hente data, der gengives af en anden (f.eks. viser produktprisen i produktlisten), kan et routinglag eller en BFF (Backend for Frontend) facilitere dette via service discovery.

Kunsten at Load Balancing

Når tjenester er blevet fundet, er det næste kritiske trin at fordele indgående trafik effektivt på tværs af flere instanser af en tjeneste. Load balancing er processen med at distribuere netværkstrafik eller computerarbejdsbyrder på tværs af flere computere eller et netværk af ressourcer. De primære mål for load balancing er at:

• Maksimere gennemløbet: Sørg for, at systemet kan håndtere så mange anmodninger som muligt.
• Minimere svartiden: Sørg for, at brugerne modtager hurtige svar.
• Undgå overbelastning af en enkelt ressource: Forhindre, at en enkelt instans bliver en flaskehals.
• Øge tilgængeligheden og pålideligheden: Hvis en instans fejler, kan trafikken omdirigeres til sunde instanser.

Load Balancing i en Frontend Micro-Service Mesh-kontekst

I forbindelse med frontend microservices anvendes load balancing på forskellige niveauer:

• Load Balancing API Gateway/Edge Services: Fordeling af indgående brugertrafik på tværs af flere instanser af din API Gateway eller indgangspunkterne til din microfrontend-applikation.
• Load Balancing Backend Services: Fordeling af anmodninger fra microfrontends eller API Gateways til tilgængelige instanser af backend microservices.
• Load Balancing Instances af Samme Microfrontend: Hvis en bestemt microfrontend implementeres med flere instanser for skalerbarhed, skal trafikken til disse instanser afbalanceres.

Fælles Load Balancing-algoritmer

Load balancers bruger forskellige algoritmer til at beslutte, hvilken instans der skal sende trafik til. Valget af algoritme kan påvirke ydeevnen og ressourceudnyttelsen.

1. Round Robin

Dette er en af de enkleste algoritmer. Anmodninger distribueres sekventielt til hver server på listen. Når slutningen af listen er nået, starter den igen fra begyndelsen.

Eksempel: Servere A, B, C. Anmodninger: 1->A, 2->B, 3->C, 4->A, 5->B osv.

Fordele: Enkel at implementere, fordeler belastningen jævnt, hvis servere har lignende kapacitet.

Ulemper: Tager ikke højde for serverbelastning eller svartider. En langsom server kan stadig modtage anmodninger.

2. Vægtet Round Robin

I lighed med Round Robin, men servere tildeles en 'vægt' for at angive deres relative kapacitet. En server med en højere vægt modtager flere anmodninger. Dette er nyttigt, når du har servere med forskellige hardware-specifikationer.

Eksempel: Server A (vægt 2), Server B (vægt 1). Anmodninger: A, A, B, A, A, B.

Fordele: Tager højde for forskellige serverkapaciteter.

Ulemper: Tager stadig ikke hensyn til faktisk serverbelastning eller svartider.

3. Mindst Forbindelse

Denne algoritme dirigerer trafik til den server med færrest aktive forbindelser. Det er en mere dynamisk tilgang, der tager hensyn til den aktuelle belastning på serverne.

Eksempel: Hvis server A har 5 forbindelser, og server B har 2, går en ny anmodning til server B.

Fordele: Mere effektiv til at distribuere belastningen baseret på den aktuelle serveraktivitet.

Ulemper: Kræver sporing af aktive forbindelser for hver server, hvilket tilføjer overhead.

4. Vægtet Mindst Forbindelse

Kombinerer Mindst Forbindelse med servervægte. Den server med færrest aktive forbindelser i forhold til sin vægt modtager den næste anmodning.

Fordele: Bedst af begge verdener – tager hensyn til serverkapacitet og aktuel belastning.

Ulemper: Mest komplekse at implementere og administrere.

5. IP Hash

Denne metode bruger en hash af klientens IP-adresse til at afgøre, hvilken server der modtager anmodningen. Dette sikrer, at alle anmodninger fra en bestemt klient-IP-adresse konsekvent sendes til den samme server. Dette er nyttigt for applikationer, der opretholder sessionstilstand på serveren.

Eksempel: Klient IP 192.168.1.100 hashes til Server A. Alle efterfølgende anmodninger fra denne IP går til Server A.

Fordele: Sikrer sessionpersistens for stateful applikationer.

Ulemper: Hvis mange klienter deler en enkelt IP (f.eks. bag en NAT-gateway eller proxy), kan belastningsfordelingen blive ujævn. Hvis en server går ned, vil alle klienter, der er tildelt den, blive berørt.

6. Mindst Svartid

Dirigerer trafik til den server med færrest aktive forbindelser og den laveste gennemsnitlige svartid. Dette sigter mod at optimere for både belastning og responsivitet.

Fordele: Fokuserer på at levere det hurtigste svar til brugerne.

Ulemper: Kræver mere sofistikeret overvågning af svartider.

Load Balancing på Forskellige Lag

Lag 4 (Transportlag) Load Balancing

Opererer på transportlaget (TCP/UDP). Det videresender trafik baseret på IP-adresse og port. Det er hurtigt og effektivt, men inspicerer ikke indholdet af trafikken.

Eksempel: En netværksload balancer, der distribuerer TCP-forbindelser til forskellige instanser af en backend-tjeneste.

Lag 7 (Applikationslag) Load Balancing

Opererer på applikationslaget (HTTP/HTTPS). Det kan inspicere indholdet af trafikken, såsom HTTP-headere, URL'er, cookies osv., for at træffe mere intelligente routingbeslutninger. Dette bruges ofte af API Gateways.

Eksempel: En API Gateway, der router `/api/products`-anmodninger til produkt-tjenesteinstanserne og `/api/cart`-anmodninger til indkøbskurv-tjenesteinstanserne baseret på URL-stien.

Implementering af Load Balancing i Praksis

1. Load Balancers fra Cloud-udbydere:

Store cloud-udbydere (AWS, Azure, GCP) tilbyder administrerede load balancing-tjenester. Disse er meget skalerbare, pålidelige og integreres problemfrit med deres computertjenester (f.eks. EC2, AKS, GKE).

• AWS: Elastic Load Balancing (ELB) - Application Load Balancer (ALB), Network Load Balancer (NLB), Gateway Load Balancer (GLB). ALB'er er Lag 7 og bruges almindeligvis til HTTP/S-trafik.
• Azure: Azure Load Balancer, Application Gateway.
• GCP: Cloud Load Balancing (HTTP(S) Load Balancing, TCP/SSL Proxy Load Balancing).

Disse tjenester tilbyder ofte indbyggede sundhedskontroller, SSL-afslutning og understøttelse af forskellige load balancing-algoritmer.

2. API Gateways:

API Gateways som Kong, Traefik eller Apigee indeholder ofte load balancing-funktioner. De kan dirigere trafik til backend-tjenester baseret på definerede regler og distribuere den blandt tilgængelige instanser.

Eksempel: Et microfrontend-team kan konfigurere deres API Gateway til at dirigere alle anmodninger til `api.example.com/users` til `user-service`-klyngen. Gatewayen, der er opmærksom på de sunde instanser af `user-service` (gennem service discovery), vil derefter load balance indgående anmodninger på tværs af dem ved hjælp af en valgt algoritme.

3. Service Mesh Proxies (f.eks. Envoy, Linkerd):

Når du bruger en fuld service mesh (som Istio eller Linkerd), håndterer service mesh data planet (bestående af proxies som Envoy) både service discovery og load balancing automatisk. Proxien opfanger al udgående trafik fra en tjeneste og dirigerer den intelligent til den passende destination og udfører load balancing på vegne af applikationen.

Eksempel: En microfrontend, der fremsætter en HTTP-anmodning til en anden tjeneste. Envoy-proxien, der er indsat sammen med microfrontend, løser tjenestens adresse via service discovery-mekanismen (ofte Kubernetes DNS eller et brugerdefineret register) og anvender derefter en load balancing-politik (konfigureret i service mesh control planet) til at vælge en sund instans af målservicen.

Integrering af Service Discovery og Load Balancing

Kraften i en frontend micro-service mesh kommer fra den problemfri integration af service discovery og load balancing. De er ikke uafhængige funktioner, men snarere komplementære mekanismer, der arbejder sammen.

Det Typiske Flow:

1. Serviceregistrering: Microfrontend-instanser og backend-serviceinstanser registrerer sig selv med et centralt Serviceregister (f.eks. Kubernetes DNS, Consul, Eureka).
2. Discovery: En anmodning skal fremsættes. En mellemliggende komponent (API Gateway, Service Proxy eller Klientsideopløser) forespørger Serviceregistret for at få en liste over tilgængelige netværksplaceringer for målservicen.
3. Load Balancing-beslutning: Baseret på den forespurgte liste og den konfigurerede Load Balancing-algoritme vælger den mellemliggende komponent en bestemt instans.
4. Videresendelse af anmodning: Anmodningen sendes til den valgte instans.
5. Sundhedskontroller: Load balanceren eller serviceregistret udfører løbende sundhedskontroller på registrerede instanser. Usunde instanser fjernes fra puljen af tilgængelige mål, hvilket forhindrer, at anmodninger sendes til dem.

Eksempelscenario: Global E-handelsplatform

Forestil dig en global e-handelsplatform bygget med microfrontends og microservices:

• Brugeroplevelse: En bruger i Europa får adgang til produktkataloget. Deres anmodning rammer først en global load balancer, som dirigerer dem til det nærmeste tilgængelige indgangspunkt (f.eks. en europæisk API Gateway).
• API Gateway: Den europæiske API Gateway modtager anmodningen om produktdata.
• Service Discovery: API Gateway (der fungerer som en serverside discovery-klient) forespørger serviceregistret (f.eks. Kubernetes-klyngens DNS) for at finde tilgængelige instanser af `product-catalog-service` (som muligvis er implementeret i europæiske datacentre).
• Load Balancing: API Gateway anvender en load balancing-algoritme (f.eks. Mindst Forbindelse) til at vælge den bedste instans af `product-catalog-service` til at betjene anmodningen og sikre en jævn fordeling på tværs af tilgængelige europæiske instanser.
• Backend-kommunikation: `product-catalog-service` skal muligvis igen kalde en `pricing-service`. Den udfører sin egen service discovery og load balancing for at oprette forbindelse til en sund `pricing-service`-instans.

Denne distribuerede, men alligevel orkestrerede tilgang sikrer, at brugere over hele verden får hurtig, pålidelig adgang til applikationens funktioner, uanset hvor de er placeret, eller hvor mange instanser af hver tjeneste der kører.

Udfordringer og Overvejelser for Frontend Microservices

Selvom principperne ligner backend service meshes, introducerer anvendelsen af dem på frontenden unikke udfordringer:

• Klientsidekompleksitet: Implementering af klientside service discovery og load balancing direkte i frontend-rammer (som React, Angular, Vue) kan være besværligt og tilføje betydelig overhead til klientapplikationen. Dette fører ofte til at favorisere serverside discovery.
• Statushåndtering: Hvis microfrontends er afhængige af delt tilstand eller sessionsoplysninger, bliver det afgørende at sikre, at denne tilstand håndteres korrekt på tværs af distribuerede instanser. IP Hash load balancing kan hjælpe med sessionpersistens, hvis tilstanden er serverbundet.
• Inter-Frontend-kommunikation: Microfrontends skal muligvis kommunikere med hinanden. Orkestrering af denne kommunikation, potentielt via en BFF eller en eventbus, kræver omhyggeligt design og kan udnytte service discovery til at lokalisere kommunikationsslutpunkter.
• Værktøjer og Infrastruktur: Opsætning og administration af den nødvendige infrastruktur (API Gateways, serviceregistre, proxies) kræver specialiserede færdigheder og kan øge den operationelle kompleksitet.
• Ydelsesindvirkning: Hvert lag af indirektion (f.eks. API Gateway, proxy) kan introducere latenstid. Det er afgørende at optimere routing- og discovery-processen.
• Sikkerhed: Det er altafgørende at sikre kommunikationen mellem microfrontends og backend-tjenester samt at sikre selve discovery- og load balancing-infrastrukturen.

Bedste Praksis for en Robust Frontend Micro-Service Mesh

For effektivt at implementere service discovery og load balancing for dine frontend microservices skal du overveje disse bedste praksis:

• Prioriter Serverside Discovery: For de fleste frontend microservice-arkitekturer forenkler udnyttelse af en API Gateway eller et dedikeret routinglag til service discovery og load balancing frontend-koden og centraliserer styringen.
• Automatiser Registrering og Afregistrering: Sørg for, at tjenester automatisk registrerer, når de starter, og afregistrerer sig elegant, når de lukker ned for at holde serviceregistret nøjagtigt. Containerorkestreringsplatforme håndterer ofte dette automatisk.
• Implementer Robuste Sundhedskontroller: Konfigurer hyppige og nøjagtige sundhedskontroller for alle serviceinstanser. Load balancere og serviceregistre er afhængige af disse for kun at dirigere trafik til sunde instanser.
• Vælg passende Load Balancing-algoritmer: Vælg algoritmer, der bedst matcher din applikations behov, og overvej faktorer som serverkapacitet, aktuel belastning og krav til sessionpersistens. Start simpelt (f.eks. Round Robin) og udvikl dig efter behov.
• Udnyt en Service Mesh: For komplekse microfrontend-implementeringer kan vedtagelse af en fuld service mesh-løsning (som Istio eller Linkerd) levere et omfattende sæt af muligheder, herunder avanceret trafikstyring, sikkerhed og observabilitet, ofte ved at udnytte Envoy- eller Linkerd-proxies.
• Design til Observabilitet: Sørg for, at du har omfattende logning, metrikker og sporing for alle dine microservices og den infrastruktur, der administrerer dem. Dette er afgørende for fejlfinding og forståelse af flaskehalse i ydeevnen.
• Sikr din Infrastruktur: Implementer godkendelse og autorisation for kommunikation mellem tjenester og sikker adgang til dit serviceregister og dine load balancere.
• Overvej Regionale Implementeringer: For globale applikationer skal du implementere dine microservices og understøttende infrastruktur (API Gateways, load balancere) i flere geografiske regioner for at minimere latenstiden for brugere over hele verden og forbedre fejltolerancen.
• Gentag og Optimer: Overvåg løbende ydeevnen og adfærden af din distribuerede frontend. Vær forberedt på at justere load balancing-algoritmer, service discovery-konfigurationer og infrastruktur, efterhånden som din applikation skaleres og udvikler sig.

Konklusion

Konceptet med en frontend micro-service mesh, drevet af effektiv service discovery og load balancing, er afgørende for organisationer, der bygger moderne, skalerbare og robuste globale webapplikationer. Ved at abstrahere kompleksiteten af dynamiske serviceplaceringer og distribuere trafik intelligent, gør disse mekanismer det muligt for teams at bygge og implementere uafhængige frontend-komponenter med tillid.

Mens klientside discovery har sin plads, er fordelene ved serverside discovery, ofte orkestreret af API Gateways eller integreret i en service mesh, overbevisende for microfrontend-arkitekturer. Kombineret med intelligente load balancing-strategier sikrer denne tilgang, at din applikation forbliver effektiv, tilgængelig og tilpasningsdygtig til de stadigt skiftende krav i det globale digitale landskab. Ved at omfavne disse principper vil du bane vejen for mere smidig udvikling, forbedret systemrobusthed og en overlegen brugeroplevelse for dit internationale publikum.