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.