ArchConf 2017 - uträtning av frågetecken inom microservice-arkitektur.

21 December 2017 // Johan Zetterström

Jag spenderade första dagen av ArchConf på en heldags workshop med Mark Richards. Ämnet var ”Microservice architecture and design”. Det blev en mycket givande dag där flera av de frågetecken jag har haft kring microservicearkitektur rätades ut.

Workshopen hade ett mycket omfattande innehåll, indelat på “core concepts” och “design and data techniques”. Följande är exempel på områden som behandlades.

Microservice core concepts

• Distributed architecture. Allmänna egenskaper i en distribuerad arkitektur. Latency, transaktionshantering, loggning.
• Bounded context. Microservices är en “share nothing architecture”, vilket innebär ett totalt annorlunda sätt att tänka jämfört med SOA, som kan beskrivas som en “share everything architecture”.
• Drivers and advantages. Exemplifiering av hur ett antal egenskaper förändras när man rör sig på skalan från monoliter till microservices.
• API layer overview. Användning av ett API-lager för hantering av klientanrop, och exempel på produkter i olika kategorier.
• Hybrid architectures. Drivers och designprinciper för mindre granulära tjänstekomponenter (macro services).
• Migration patterns. Principer för refaktorering av monoliter till macro- eller microservices.

Design and data techniques

• Service identification. Metodik för identifiering av tjänster.
• Event-driven services. Egenskaper hos asynkron och synkron kommunikation, inom områden som transaktionshantering, broadcast-lösningar och lastbalansering.
• Service communication. Kommunikation tjänster emellan, och från klient till tjänst. Användning av API gatway och mönster kring detta.
• Distributed loggning. Konsolidering av loggar, strömmade loggar, generering av id som identifierar request.
• Remote access error handling. Timeout-hantering, circuit breaker pattern.
• Creating data domains. Metodik för att bryta ned en befintlig databas till mindre domäner.
• Handling common data. Lösningar via anrop mellan tjänster eller distribuerad cache.

Flera av de saker som togs upp på workshopen återkom i mer detalj i andra dragningar som Mark höll under konferensen, och har avhandlats i andra inlägg på denna blogg.

Vi ska nu titta närmare på ett par mönster för som troligen är bekanta för många med erfarenhet inom tjänstebaserad integration. De tillämpas även i klassisk SOA-arkitektur men lösningarna är annorlunda i en microservice-arkitektur. De påverkas av skillnader mellan den roll en ESB har inom SOA och den roll vi vill tilldela en API-gateway.

Hop on the bus anti-pattern

Detta anti-pattern, som Hans beskrev i sitt blogginlägg om microservice anti-patterns, kan sägas var moder till de mönster jag kommer att ta upp (en analogi som dock haltar något då modern i detta fall är yngre än sina barn). ”Hop on the bus” beskriver vilka förmågor man bör undvika att implementera i sin API-gateway i en microservice- eller tjänstebaserad arkitektur, och vilka som hör hemma där. Syftet är att skapa en mer lättrörlig arkitektur där integrationshubben inte blir en flaskhals.

Service orchestration pattern

Detta mönster, som beskriver hur anrop till flera fingranulära tjänster hålls ihop av en “orkestrator” som kan leverera ett tjänstegränssnitt som bättre möter klienternas önskemål, är väl bekant från SOA. Men tillämpningen är annorlunda i det att orkestratorn byggs som en egen tjänst, inte en kapabilitet i en API-gateway. Mark Richards förordar att messaging används för inter-servicekommunikation (vilket alltså inkluderar detta fall, inte bara mellan tjänster på underliggande nivå), och att realisering sker med hjälp av Apache Camel.

Källa: Mark Richards presentation

Service aggregation pattern

I en microservicearkitektur uppstår ibland behov av att aggregera information, till exempel för att skapa en söktjänst. Motiv för detta kan vara att en sökning annars skulle resultera i anrop av ett så stort antal tjänster att svarstiderna blir för höga, eller att vilka tjänster som behöver anropas är att betrakta som ett rörligt mål. En förutsättning är att söktjänsten inte kräver 100% realtidsinformation. I dessa fall kan söktjänsten implementeras enligt service aggregation pattern. De tjänster som behöver göra data tillgängligt skickar den via asynkrona meddelanden till aggregatorn, som lagrar informationen i sin egen datakälla. Aggregatorn bör inte vara medveten om vilka som skickar information. Klienters sök-requests kan sedan betjänas på ett effektivt sätt.

Källa: Mark Richards presentation

Mönstret medför att data dupliceras, vilket får ses som en arkitekturell trade-off väl värd att göra i ett dylikt sammanhang.

Service gateway pattern

De gamla backendtjänsterna, de som inte kan anpassas till att leverera tjänster via aktuella protokoll, blir man inte kvitt i första taget. De måste kunna införlivas även i vår nya arkitektur, där klienterna ska kunna interagera med alla tjänster via samma protokoll. Poängen här är inte att tjänsterna helt plötsligt ska ses som microservices, men att de kan döljas bakom en fasad med ett microservice-liknande gränssnitt. Klienterna ska dock inte behöva bry sig om skillnaden. Istället för att modellera en tjänst som implementerar protokollkonverteringen efter det befintliga gränssnittet bör om-modellering utföras så att gränssnittet delas upp på separata tjänster enligt microservice-prinicper. Resultatet blir microservice gateways. Migrering från legacy-systemet till riktiga microservices kan sedan göras stegvis utan att gränssnitten förändras

Källa: Mark Richards presentation

Med dessa mönster säkrar vi att alla delar av vår arkitektur är skalbara, och möjliggör migrering av legacy-system utan påverkan på klienterna.