ArchConf, dag 2 - Reactive Architecture Patterns

12 December 2017 // Andreas Tell

Efter en heldag med olika workshops började idag själva konferensen ArchConf 2017.

Här kommer en sammanfattning av “Reactive Architecture Patterns” med Mark Richards.

Föreläsningen började med en resumé av Reactive Manifesto och dess mål att skapa responsiva, skalbara och feltoleranta system. Han förtydligade också på ett bra sätt hur reaktiv programmering inte är samma sak som reaktiva system och fokus för denna föreläsning var, som namnet antyder, det senare.

Karaktäristiskt för reaktiva system är att de är meddelandebaserade och asynkrona vilket föranleder att man använder någon form av meddelandetjänst. Mark använde sig av RabbitMQ med AMQP i sina exempel (men principerna i sig är generellt applicerbara).

Efter introduktionen gick han igenom ett antal mönster vilka alla hade det övergripande syftet att upprätthålla konsekvent prestanda vid varierande lastförhållanden;

Channel Monitor Pattern

Fundamentalt mönster som helt enkelt går ut på att man läser av ködjup för att avgöra nuvarande last på systemet. Bygger på en ”event monitor” som övervakar antal meddelande och antal konsumenter för en kö. Visade sig inte vara helt enkelt i praktiken speciellt inte med standard JMS.

Consumer Supervisor Pattern

Detta mönstret används för att reglera antal meddelandekonsumenter vid ett givet tillfälle genom “programmatisk lastbalansering”. Användbart för att hantera lastspikar. En sak man måste ha under kontroll är dock antalet trådar för att inte dränera resurser (minne/cpu). Om man slår i taket vad gäller resurser återstår att starta upp ytterligare en systeminstans via en “Super Supervisor” vilket skulle kunna vara någon form av container-orkestrerare (ex. Kubernetes).

Workflow event pattern

Detta mönster syftar till att hantera felsituationer utan att avbryta pågående transaktioner. Felhantering delegeras till en “Workflow processor” vilken ansvarar för att försöka åtgärda felaktiga meddelande (möjligt i begränsade fall) och lägga tillbaka dem på inkommande kö alt. skicka meddelade som inte kan åtgärdas till någon form av system för att manuellt hantera dessa meddelanden.

Thread delegate pattern

Detta mönster syftar till att säkerställa konsekvent responstid när ett systems konstanta, kontinuerliga last växer (dvs. ej lastspikar) och dessutom säkerställa meddelandeordning/sekvens. När meddelandeordning är viktigt kan endast en en consumer användas och man får istället hantera meddelanden i trådar. Påminner om “Consumer Supervisor Pattern” men ger bättre prestanda och klarar av att garantera sekvens.

Threshold adjust pattern

Används för att i realtid mäta responstid och justera ex timeout dynamiskt. Kräver således att konfiguration är externaliserad i någon typ av konfigurationsserver. Mark visade en algoritm “Bracket algorithm” för att justera timeoutvärdet baserat på flera observationer.

Producer control flow pattern.

För att sakta ner producenter när meddelandesystemet överlastas, dvs när systemet inte kan bearbeta meddelanden i samma takt som det kommer in nya i systemet. En ”flow monitor” övervakar ett gränsvärde för ködjup. Om det överskrids meddelar denna producenterna att sakta ner genom att skicka ett meddelande på en speciell kö. När systemet kommit ikapp meddelas producenterna att systemet är tillbaka i normalläge och dessa kan återgå till sin normala takt.

Slutligen …

Sammanfattningsvis kan jag rekommendera både ämnet och talaren. Mark varvade teori med demos och höll ett passionerat, humoristiskt föredrag med högt tempo. Kodexempel till denna presentation återfinns på https://github.com/wmr513/reactive