De WSO2 API Manager heeft zowel de mogelijkheid om te werken met zogenaamde ‘failover endpoints’ als ‘load balanced endpoints’. In deze blog gaan we zelf vanuit de API Manager een API met een load balanced endpoint bouwen. We gebruiken daar de WSO2 API Manager 3.2.0 voor. Dat is op het moment dat ik deze blog schrijf de nieuwste versie van de WSO2 API Manager.
Installatie van de WSO2 API Manager
In één van onze eerdere artikelen kun je meer informatie vinden over de installatie van de WSO2 API Manager. Dat artikel begeleidt je door de stappen die je zult moeten nemen om het product te installeren. In het geval dat je een ander product gebruikt, of een andere versie van hetzelfde product, zal het onderstaande verhaal nog steeds heel relevant zijn. Ik vertrouw erop dat je het voor elkaar krijgt.
In het kort heb je het volgende nodig: je zult eerst Java moeten installeren, mocht dat nog niet geïnstalleerd zijn. Twee van de ondersteunde versies zijn Java 8 / 121 en OpenJDK 11. Na het instellen van JAVA_HOME kun je het .zip-bestand met de API Manager downloaden en uitpakken. Dit werkt zowel voor Windows als voor Linux en Mac OS. Er zijn in feite verschillende manieren waarop je de WSO2-producten kunt installeren, waaronder via installers, hoewel die onder de gelicenseerde software vallen. De open source versie kan als .zip-bestand van Github gedownload worden.
WireMock om mock API’s te maken
Om de mock API’s (een schijn API) te maken die we nodig hebben voor de failover, gebruik ik WireMock. Deployment van de mock API’s gaat standaard via poort 8080. Om het op te zetten kun je het lokaal laten draaien of op een server. Je vindt de de instructies over hoe wij WireMock draaien in dit artikel dat mijn collega Dušan Dević schreef. Daar staat ook in uitgelegd hoe het mechanisme van WireMock werkt en op welke locatie de .json-bestanden horen te staan.
Dit is de API1 (api1.json) definitie voor WireMock die reageert met een eenvoudig bericht:
{
"request": {
"method": "GET",
"url": "/api_1"
},
"response": {
"status": 200,
"body": "This is API 1",
"fixedDelayMilliseconds": 0,
"headers": {
"Content-Type": "application/json"
}
}
}Kopieer deze API-definitie naar api2.json en api3.json en verander de body tekst naar “This is API 2” en “This is API 3” voor de betreffende files. Vergeet niet ook de url per file (/api_1) te veranderen naar /api_2 en /api_3.
Maak de API vanuit de API-Publisher
We gaan de API met het load balancer endpoint vanuit de API Publisher UI maken. Start de API Manager Publisher zoals je dat normaal zou doen met https://localhost:9443/publisher. (Ik ga uit van een kant-en-klare installatie). Log in met gebruikersnaam en wachtwoord beide ‘admin’.
We gaan nu verder met het maken van een nieuwe API die “Loadbalanced” gaat heten. We kiezen de optie ‘Design New REST API’ uit het menu in de API-Publisher.
Vul de gegevens voor de API-definitie in zoals ze in de onderstaande screenshot staan:
Druk op “Create” om de API te maken en je zult dit overzicht te zien krijgen:
Er zijn een aantal gegevens die we moeten invullen. We openen daarvoor de “Design configurations” en vullen daar de benodigde gegevens in.
Ik heb een logo gemaakt en op deze pagina naar de API geüpload. Je kunt gebruik maken van het standaard logo (een eenvoudige achtergrond en symbool) dat de API Manager voorstelt of er zelf een maken. Vul de andere velden in zoals in de afbeelding hieronder. Je kunt natuurlijk ook andere dingen invullen, maar houdt er rekening mee dat wijzigingen in de ‘visibility’ en ‘access control’ invloed hebben op de API.
Klik op SAVE om de wijzigingen op te slaan.
Als je naar “Resources” gaat kun je daar alle ‘wildcard resources’ verwijderen die standaard aangemaakt worden, behalve de resource met ‘GET HTTP verb’ en ‘use URI pattern “/*”’.
Klik op SAVE om de wijzigingen op te slaan.
Op het overzichtsscherm klik je op de endpoints en voer je de volgende aanpassingen door:
Voeg twee load balance endpoints toe door de het originele endpoint te kopiëren en het achtervoegsel ‘1’ (api_1) te veranderen in de getallen 2 en 3 zoals je op de screenshot kunt zien.
Sla de wijzigingen opnieuw op.
Publiceer de API in de lifecycle definitie en ga naar het Devportal om de API te bekijken. Een link daarheen kun je in de API-Publisher vinden.
Abonneer je op de API door van de standaard applicatie gebruik te maken.
Kies PROD KEYS en genereer de Keys.
Kopieer het token met het icoontje aan de rechterkant (het papier-icoontje). Dit zit nu in je geheugen. Sluit het scherm.
We gaan de SoapUI gebruiken om de API uit te proberen.
Start SoapUI op en maak een nieuw ‘REST-project’ aan. Gebruik de http://localhost:8280/load/1.0 URI.
Als dit project gemaakt is, klik je op de Auth button.
Kies voor Oauth 2.0 het dropdownmenu als autorisatie mogelijkheid.
Kopieer het token naar het veld ‘Access Token’.
Klik vervolgens op de groene pijl.
Herhaal dit een aantal keer en zo zie je dat het load balanced endpoint prachtig het rijtje rondgaat met de aanroepen.
Conclusie
Als je een opzet wil die de belasting van je API verdeeld, dan kun je een vanuit de API-definitie zelf load balancing toepassen. Het algoritme is een eenvoudige round robin opzet die door de eindpunten heen loopt.
