NL 
EN Hoewel veel bedrijven nog steeds worstelen met de betekenis en essentie van een microservice-architectuur, nemen de voorbeelden van succesvolle implementaties toe. Vanaf nul beginnen of migreren vanuit een monolithische architectuur, beide hebben hun eigen uitdagingen en kunnen erg tijdrovend zijn. Voordat u aan uw eigen uitdaging begint, moet u nagaan of een microservicearchitectuur de juiste weg is voor uw bedrijf. In deze blog geven we een aantal praktische tips en lichten we concept toe.
Microservices: 2 manieren van communicatie
Microservices hebben alles te maken met het scheiden van belangen en het loskoppelen van onafhankelijke services. Maar hoe werkt de communicatie tussen die diensten? In een microservice-architectuur worden grofweg twee manieren van communicatie tussen de microservices onderscheiden:
- Synchroon – een microservice roept rechtstreeks de andere microservice op en vereist een onmiddellijke reactie, wat resulteert in afhankelijkheid tussen de services.
- Asynchroon – een microservice roept direct / indirect de andere microservice op en ontvangt een niet-onmiddellijke reactie in een nieuwe transactie. Verzoeken tussen de corresponderende services worden in message queues geplaatst. De verantwoordelijke microservice neemt alle verzoeken, verwerkt deze en stuurt het resultaat asynchroon terug naar de beller. Lokale berichtenwachtrijen kunnen voor dit doel worden gebruikt, maar vaak bieden messaging-frameworks zoals Apache Kafka, Apache ActiveMQ, RabbitMQ of een andere schaalbare messaging-oplossing de beste mogelijkheden om gegarandeerde levering te bereiken.
Creër jouw microservice architectuur: kies de juist vorm van communicatie
Beide manieren van communicatie hebben hun eigen voor- en nadelen, maar het kiezen van de juiste hangt volledig af van uw gebruik en zakelijke / technische vereisten. Maar waarom is dit relevant? Omdat uw keuze vele implicaties heeft en elke keer dat u aan een nieuwe microservice denkt, duikt de vraag op of u voor synchrone of asynchrone communicatie moet kiezen. Zonder het te beseffen maken we tijdens ons dagelijkse werk constant de keuze voor de juiste communicatiestijl. Als u bijvoorbeeld contact wilt opnemen met een collega of teamlid om een vraag te stellen, welke communicatiemethode heeft uw voorkeur? Heeft u direct hulp nodig en geeft u de voorkeur aan een telefoontje, dat uiteraard synchroon verloopt omdat iemand direct op uw telefoontje moet reageren? Of geeft u de voorkeur aan een asynchrone methode zoals e-mail of uw favoriete samenwerkingstool op kantoor, omdat u geen onmiddellijke reactie nodig heeft en wachten op een antwoord mogelijk is? Net als in het normale leven geldt hetzelfde voor systeem-naar-systeemcommunicatie. Als uw verzoek dringend is en u een direct antwoord nodig heeft, is synchrone communicatie nodig. In bijna alle andere gevallen is asynchrone communicatie geschikter, omdat er geen urgentie is en geen behoefte aan directe respons.
In een microservice-architectuur wisselen systemen / applicaties / services voortdurend informatie met elkaar uit. Het ontwerpen van een nieuwe microservice- of microservice-architectuur leidt onvermijdelijk tot de vraag welke communicatiestijl gekozen moet worden. Tegenwoordig is er veel aandacht voor synchrone communicatie als de enige manier om te gaan in een microservice-architectuur. Het lijkt er bijna op dat microservices en synchrone communicatiestijlen zoals REST / HTTP / RPC synoniemen zijn, maar eigenlijk is er meer dan dat. Asynchrone communicatie is nog steeds vooral de beste manier als data / informatie niet direct nodig is in een microservice-architectuur en in veel gevallen is deze best practice van toepassing.
Source: Communication in a microservice architecture
Enterprise integratie patronen
Het combineren van synchrone en asynchrone communicatie binnen een microservicearchitectuur leidt tot betere resultaten dan het strikt gebruiken van één type communicatie. Daarom wil ik u graag wegwijs maken in de wereld van integratiepatronen voor ondernemingen. Deze uitstekende bron geeft een overzicht van vele best practices en meer dan 65 integratiepatronen, verzameld uit integratiepraktijken in echte projecten. Sommige patronen zijn in veel gevallen nuttig, maar passen ook expliciet in een microservice-architectuur, dus heb ik ze in de onderstaande tabel gemarkeerd:
| Pattern | Direction | Asynchronous | Multi-Message | Termination | Error Handling |
|---|---|---|---|---|---|
| Fire-and-Forget | unidirectional | provider | single | implicit | none |
| Asynchronous Request-Response | bidirectional | provider | two | implicit | none |
| Request-Response with Retry | bidirectional | provider | multiple | implicit | retry |
| Polling | bidirectional | provider | multiple | implicit | none |
| Subscribe-Notify | bidirectional | consumer and provider | multiple | explicit | none |
| Quick acknowledgement | bidirectional | provider | three | implicit | none |
Deze bewezen patronen maken het mogelijk om de bezorging van berichten te garanderen, wat nodig is in een microservice-architectuur met onafhankelijke services. Asynchrone, op gebeurtenissen gebaseerde architecturen kunnen je helpen bij je omschakeling van traditionele monolitische benadering naar een servicegericht of microservice-architectuur. Hoewel er geen wondermiddel is, kan het lezen over de ervaringen van andere bedrijven u helpen de juiste richting te vinden die het meest geschikt is voor uw bedrijfsgrootte.
Bedankt voor het lezen van deze blog over loosely coupled applicaties in een microservice-architectuur.
Door Samet Kaya, Software Delivery Manager @ eMagiz
