Connectoren performantie
Concept
Performantie is een overkoepelende term die vier verschillende mechanismen beschrijft die ervoor zorgen dat de verbinding met externe services robuust en betrouwbaar blijft, zelfs bij storingen. Deze mechanismen zijn via Resilience4j opgezet voor het merendeel van de connectoren.
Mechanismen
Circuit Breaking: detecteert problemen met de externe service en onderbreekt tijdelijk de verbinding. Het zorgt ervoor dat de applicatie niet blijft proberen te communiceren met een falende service. Na een tijdelijke pauze wordt de verbinding gecontroleerd hersteld.
Rate Limiting: beperkt het totale aantal verzoeken dat naar de externe service gestuurd mag worden binnen een vooraf gedefinieerde tijdseenheid. Dit voorkomt overbelasting van de service en zorgt ervoor dat deze niet wordt overspoeld door een te hoge frequentie van aanvragen.
Bulkhead: gericht op het beperken van het aantal gelijktijdige verzoeken naar de externe service. Door een maximum aantal parallelle aanvragen te stellen, wordt voorkomen dat de service overbelast raakt en kunnen andere onderdelen van het systeem verder functioneren, zelfs als één service een probleem ondervindt.
Retry: Bij een mislukte aanvraag bepaalt dit mechanisme het aantal pogingen om de call opnieuw uit te voeren voordat de verbinding als gefaald wordt gemarkeerd en een foutmelding wordt gegenereerd. Dit biedt extra veerkracht door tijdelijke netwerk- of servicefouten te omzeilen.
Resilience4j
Resilience4j is de technologie die we binnen Skryv gebruiken om de performantie en veerkracht van bepaalde connectors te waarborgen. Het is een lichte en modulair opgebouwde library die eenvoudig geïntegreerd kan worden in een Java-project.
Configuratie resilience4j
Het configureren gebeurt via applicatie eigenschappen die specifiek gerelateerd zijn aan resilience4j. Er zijn default configuraties die voor het grootste stuk overgenomen zijn uit de default resilience4j library.
Defaults
Onderstaand overzicht toont de default configuraties. Indien je hiermee akkoord bent, dan hoef je deze niet op te nemen binnen je applicatie eigenschappen. Indien je één of meerdere defaults wil aanpassen, dan moet je deze wel expliciteren.
Circuit breaking
Volgens onderstaande default instellingen voorkomt de circuit breaker dat er voortdurend requests naar een externe service worden gestuurd die mogelijk niet beschikbaar is door de service tijdelijk te ‘onderbreken’ (open toestand) als het percentage mislukte requests boven de 50% komt. Na 60 seconden in de open toestand, probeert de circuit breaker over te schakelen naar de half-open toestand en laat maximaal 10 calls toe. Als 50% of meer van deze requests faalt, blijft de circuit breaker in de open toestand; als ze slagen, gaat de circuit breaker naar de gesloten toestand.
Eigenschap | Beschrijving |
|---|---|
| Het drempelpercentage van mislukte requests dat bepaalt wanneer de circuit breaker open gaat. Volgens de default, als 50% of meer van de requests in een bepaalde periode falen, schakelt de circuit breaker naar de open toestand. |
| Het aantal toegestane requests dat wordt uitgevoerd wanneer de circuit breaker in de half-open toestand verkeert. Volgens de default worden er 10 requests uitgevoerd om te testen of de service hersteld is. |
| Het aantal requests dat wordt gevolgd in de sliding window van de circuit breaker. Volgens de default worden de uitkomsten van de laatste 100 requests gebruikt om te bepalen of de drempel voor mislukte verzoeken wordt overschreden. |
| De tijd (in milliseconden) die de circuit breaker in de open toestand blijft, voordat hij probeert over te schakelen naar de half-open toestand. Default is dit dus 60 seconden. |
Rate limiting
Volgens onderstaande default instellingen beperkt de rate limiter het aantal calls naar een externe service door maximaal 8 verzoeken per 1 seconde toe te staan. Als er meer dan 8 verzoeken in de periode van 1 seconde worden gedaan, wacht de applicatie maximaal 5 seconden op een beschikbare permit. Als na deze tijd nog geen permit beschikbaar is, wordt de call afgebroken met een exception.
Eigenschap | Beschrijving |
|---|---|
| Maximaal aantal calls per periode. |
| Lengte van de periode in milliseconden. 1000 milliseconden staat gelijk aan 1 seconde. |
| Aantal seconden dat de applicatie wacht bij overschrijding van de rate limit per periode. Indien het daarna nog steeds een overbelasting vaststelt, dan wordt een exception gegooid en faalt de call. |
Bulk head
De bulkhead voorkomt dat een grote hoeveelheid gelijktijdige requests de service overbelast door een limiet van 25 gelijktijdige oproepen in te stellen. Als de limiet van 25 gelijktijdige requests wordt bereikt, wordt de wachttijd voor extra requests ingesteld op 0 seconden, wat betekent dat extra requests onmiddellijk worden afgewezen zonder dat ze wachten.
Eigenschap | Beschrijving |
|---|---|
| Het maximum aantal gelijktijdige requests dat de bulkhead toestaat. In dit geval kunnen er 25 gelijktijdige requests naar de service worden gestuurd. Als dit aantal wordt bereikt, worden extra requests geblokkeerd of moeten wachten totdat er ruimte is. |
| De maximale tijd (in milliseconden) dat een thread wacht om toegang te krijgen tot de bulkhead wanneer deze vol is. In dit geval is de waarde 0, wat betekent dat een thread niet wacht, maar onmiddellijk wordt afgewezen als de bulkhead verzadigd is. |
Retry
De retry zorgt ervoor dat een mislukte call 3 keer opnieuw wordt geprobeerd, met een wachttijd van 500 ms tussen de pogingen. Aangezien Camunda automatisch ook 3 retries uitvoert, betekent dit dat een mislukte call uiteindelijk 9 keer opnieuw wordt geprobeerd voordat hij definitief faalt.
Eigenschap | Beschrijving |
|---|---|
| Het maximum aantal pogingen (inclusief de eerste poging) dat wordt gedaan om een mislukte call opnieuw te proberen. In dit geval worden er maximaal 3 pogingen gedaan, waarbij de initiële call als de eerste poging telt. |
| De wachttijd (in milliseconden) tussen opeenvolgende pogingen om de mislukte call opnieuw te doen. In dit geval bedraagt de wachttijd 500 milliseconden tussen elke poging. |
Connector specifiek
Wil je deze defaults overschrijven voor een specifieke connector binnen je applicatie? Kopieer dan de betrokken default en vervang je configs.default door instances.{naam}. De naam verwijst naar de connector als geheel (bijvoorbeeld adressenregister).
Voorbeeld 1
Default:
resilience4j.ratelimiter.configs.default.limit-for-period=8
Specifiek voor de adressenregister connector wordt dit dan:
resilience4j.ratelimiter.instances.adressenregister.limit-for-period=1
Deze moet je dus toevoegen binnen de applicatie eigenschappen.
Voorbeeld 2
Voor een uitgebreide connector zoals magda zijn er bijkomend fault-tolerance groups opgezet. Zo kan je de resilience4j functionaliteit specifiek voor een subset van services binnen de magda connector gaan configureren.
resilience4j.retry.instances.magda-{faulttolerancegroup}.key=value
resilience4j.retry.instances.magda-rijksregister.max-attempts=5Magda faulttolerance group | Gerelateerde services |
|---|---|
dosis | REGISTREER_DOSSIER |
kbo |
|
ebox |
|
kadaster | ZOEK_EIGENDOMSTOESTANDEN |
rijksregister |
|
fin | GEEF_PERSONAL_INCOME_TAX |
ksz |
|
led |
|