Verzuimsignaal om over te stappen naar een microservice-architectuur?
5.8. Hoe zou een microservice-architectuur eruitzien in de huidige omgeving van Verzuimsignaal?
Om een beter beeld te krijgen hoe de architectuur van Verzuimsignaal er uit kan komen te zien, is onderzoek gedaan naar welke patterns gebruikt kunnen worden en welke problemen ze oplossen (zie hoofdstuk: 5.3, 5.4, 5.6 (Richardson, sd)). Van al deze verschillende patterns is een lijst opgesteld voor de mogelijke architectuur. In deze lijst staat welke pattern gebruikt wordt voor het ontwerp, waarom deze gebruikt wordt en welke pattern gebruikt gaat worden voor het prototype.
Nr. Pattern Waarom? Prototype
1. Microservice-
architecture Door gebruik te maken van microservice is de applicatie op te delen in kleinere services, die beter onderhouden kunnen worden [P1]. Daarnaast hebben de services weinig impact, waardoor de applicatie niet stil komt te liggen wanneer een service uitvalt [P2].
✔
2. Decompose
by subdomain Bij decompose by subdomain wordt de monolite opgedeeld in kleinere services. Dit is nodig om te bepalen welke onderdelen iedere service gaat beheren.
✔
3. Database per
Service Hierbij heeft iedere service een eigen database. Hierdoor wordt de data per service gescheiden en beheerd [P3].
✔
4. CQRS CQRS wordt gebruikt om het lezen en het schrijven van de data gescheiden te houden. Hierdoor kan de database geoptimaliseerd worden voor lezen en schrijven. Daarnaast kan de
performance van de database beter worden
gewaarborgd, omdat het schrijven en het lezen van elkaar gescheiden is en kan worden ingezien [P5].
✔
5. Aggregate Het aggregate-pattern wordt gebruikt om
businesslogica te verwerken in de microservice. Hierbij wordt vooraf bepaald wanneer een domainevent wordt gepubliceerd.
✔
6. Domain
events Domain events wordt gebruikt om de businesslogica van de service aan te houden. Hierbij wordt een event gepost wanneer de data wijzigt binnen de services. Hierdoor blijft de data in de service constant.
✔
7. Event-sourcin g
Event-sourcing wordt gebruikt om de data tussen de verschillende services synchroon te houden.
Hierbij wordt gebruikgemaakt van eventlogs in plaats van de huidige status. Deze keuze is
gemaakt omdat de kern van Verzuimsignaal ligt bij protocollen en het uitvoeren van taken die
hieronder vallen. Al deze taken moeten uitgevoerd worden binnen een bepaalde tijdsperiode. Dit wordt aan de gebruiker getoond als een tijdlijn. Dit is efficiënter wanneer de data al is opgeslagen in een log.
8. Messaging Messaging wordt gebruikt voor de communicatie tussen de verschillende services. Hierbij wordt gebruikgemaakt van een pub/sub-systeem.
✔
9. Self-registrati
on Er wordt gebruikgemaakt van self-registration. Hierbij zal een service zichzelf gaan registeren bij het de pub/sub-systeem.
✔
10 API-gateway Via de API-gateway is iedere service in de microservice-architectuur te benaderen.
✔
11. Access Token Door middel van Access Tokens wordt de
autorisatie van een gebruiker geregeld. Dit wordt bij de API-gateway afgehandeld.
✔
12. Service component test
De Service component test wordt gebruikt om de
service in isolatie te testen. ✔
13. Service-per-c
ontainer Er is voor Service-per-container gekozen omdat deze snel te bouwen en te deployen zijn. ✔ 14. Single service
per host Er is voor single service per host gekozen omdat het hierdoor mogelijk is meerdere van dezelfde services te hosten. Daarnaast is de performance van iedere service meetbaar (P5).
✔
15. Service deployment platform
Een voorbeeld van een service deployment platform is een Kubernetes. Hierbij zijn er mogelijkheden om de services automatisch schaalbaar te maken. Daarnaast is er een
dashboard dat de huidige status van de services bij kan houden.
✔
Tabel 2: De gekozen patterns voor het ontwerp en het prototype.
5.8.1. Microservice-architectuurplaat
De architectuur in Figuur 5 is gebouwd met de patterns die zijn toegelicht in
paragraaf 5.8. Hierbij is in acht genomen dat de huidige monolithische applicatie niet in één keer overgezet kan worden. Dit kan het beste in delen gedaan worden. Bij het ontwerpen van deze architectuur is gebruikgemaakt van (Bologna, 2018).
Figuur 5: Microservice-architectuur Verzuimsignaal.
In de toekomstige architectuur van Verzuimsignaal is de huidige applicatie opgedeeld in twee delen: de monoliet en de microservices. Dit is gedaan om de transactie van een monolithische architectuur naar een microservice-architectuur weer te geven. De user kan in dit geval gebruikmaken van de API-gateway en van de monoliet.
Wanneer de user gebruik wil maken van de microservices, moet hij een request sturen naar API-gateway. Hierbij wordt de autorisatie uitgevoerd door middel van een accestoken. De API-gateway stuurt het request door naar het REST API-point van de service. De request wordt binnen de service verwerkt. Wanneer de request een update, delete of een post is, wordt de Aggregate Root (business logica) van de service benaderd. Hierna wordt een domain-event afgevuurd om de mutatie door te zetten. Dit event komt terecht bij de pub/sub-services. Hier wordt het event
doorgestuurd naar de eventstore en wordt het in de eventstream gezet. De eventstore slaat alle events op en wordt gezien als de absolute waarheid. De eventstore kan later gebruikt worden voor een playback. Hierbij worden alle events die in de eventstore staan weer afgespeeld via de eventstream. De services kunnen deze events ontvangen door te subscriben op de verschillende channels. Bij het ontvangen van een event wordt binnen de service gekeken naar welke views geüpdatet moeten worden.
Wanneer de user de monolite gebruikt en er een mutatie van data is, moeten deze data worden gesynchroniseerd met de microservice. Dit wordt gedaan door de eventemitter in de monolite. Hierbij wordt een event gemaakt en doorgestuurd naar de pub/sub-services. Hierdoor worden de data geüpdatet in de eventstore en in de microservices. De data kunnen op twee manieren in de monolite geüpdatet worden. Het is mogelijk om de monolite te subscriben op alle events en hierdoor alle data updaten. De andere manier is om de data niet te updaten, maar gebruik te maken van de data in de microservices. Op deze manier wordt de monoliet langzaam afgebouwd en wordt meer gericht op de microservices.
Deployment platform
Iedere service in de microservice-architectuur wordt gebouwd in zijn eigen Docker-container. Dit heeft als voordeel dat het kan worden gedeployd door een deployment platform zoals Kubernetes. Kubernetes kan iedere container deployen in zijn eigen pod. Wanneer de load voor een service hoog wordt, zorgt Kubernetes ervoor dat er een pod bij wordt gezet. Hierdoor wordt auto-scalen mogelijk gemaakt in de microservice-architectuur (kubernetes, 2020). Daarnaast heeft Kubernetes monitoring zoals het Dashboard UI, waarbij de status van iedere pod wordt weergegeven.