Identifiera gränser för mikrotjänster
Vilken är rätt storlek för en mikrotjänst? Du hör ofta något till effekten av, "inte för stor och inte för liten" - och även om det verkligen är korrekt, är det inte till stor hjälp i praktiken. Men om du börjar med en noggrant utformad domänmodell är det mycket enklare att resonera om mikrotjänster.
Den här artikeln använder en tjänst för drönarleverans som ett exempel som körs. Du kan läsa mer om scenariot och motsvarande referensimplementering här.
Från domänmodell till mikrotjänster
I föregående artikel definierade vi en uppsättning avgränsade kontexter för ett drone delivery-program. Sedan tittade vi närmare på en av dessa begränsade kontexter, den leveransbundna kontexten, och identifierade en uppsättning entiteter, aggregeringar och domäntjänster för den avgränsade kontexten.
Nu är vi redo att gå från domänmodell till programdesign. Här är en metod som du kan använda för att härleda mikrotjänster från domänmodellen.
Börja med en begränsad kontext. I allmänhet bör funktionerna i en mikrotjänst inte sträcka sig över mer än en begränsad kontext. Per definition markerar en avgränsad kontext gränsen för en viss domänmodell. Om du upptäcker att en mikrotjänst blandar olika domänmodeller tillsammans är det ett tecken på att du kan behöva gå tillbaka och förfina domänanalysen.
Titta sedan på aggregeringarna i din domänmodell. Aggregeringar är ofta bra kandidater för mikrotjänster. En väl utformad aggregering uppvisar många av egenskaperna hos en väl utformad mikrotjänst, till exempel:
- En aggregering härleds från affärskrav snarare än tekniska problem som dataåtkomst eller meddelanden.
- En aggregering bör ha hög funktionell sammanhållning.
- En aggregering är en gräns för beständighet.
- Aggregaten ska vara löst kopplade.
Domäntjänster är också bra kandidater för mikrotjänster. Domäntjänster är tillståndslösa operationer över flera aggregat. Ett vanligt exempel är ett arbetsflöde som omfattar flera mikrotjänster. Vi ser ett exempel på detta i programmet Drönarleverans.
Tänk slutligen på icke-funktionella krav. Titta på faktorer som teamstorlek, datatyper, tekniker, skalbarhetskrav, tillgänglighetskrav och säkerhetskrav. Dessa faktorer kan leda till att du ytterligare delar upp en mikrotjänst i två eller flera mindre tjänster, eller gör det motsatta och kombinerar flera mikrotjänster till en.
När du har identifierat mikrotjänsterna i ditt program verifierar du din design mot följande kriterier:
- Varje tjänst har ett enda ansvar.
- Det finns inga pratsamma samtal mellan tjänster. Om uppdelningen av funktioner i två tjänster gör att de blir alltför pratsamma kan det vara ett symptom på att dessa funktioner hör hemma i samma tjänst.
- Varje tjänst är så liten att den kan byggas av ett litet team som arbetar oberoende av varandra.
- Det finns inga beroenden som kräver att två eller flera tjänster distribueras i låssteg. Det bör alltid vara möjligt att distribuera en tjänst utan att distribuera om några andra tjänster.
- Tjänsterna är inte nära kopplade och kan utvecklas oberoende av varandra.
- Dina tjänstgränser skapar inte problem med datakonsekvens eller integritet. Ibland är det viktigt att upprätthålla datakonsekvens genom att placera funktioner i en enda mikrotjänst. Med det sagt, fundera på om du verkligen behöver stark konsekvens. Det finns strategier för att hantera eventuell konsekvens i ett distribuerat system, och fördelarna med att dela upp tjänster överväger ofta utmaningarna med att hantera eventuell konsekvens.
Framför allt är det viktigt att vara pragmatisk och komma ihåg att domändriven design är en iterativ process. När du är osäker börjar du med mer grova mikrotjänster. Att dela upp en mikrotjänst i två mindre tjänster är enklare än att omstrukturera funktioner i flera befintliga mikrotjänster.
Exempel: Definiera mikrotjänster för drone delivery-programmet
Kom ihåg att utvecklingsteamet hade identifierat de fyra aggregeringarna – Leverans, Paket, Drönare och Konto – och två domäntjänster, Scheduler och Supervisor.
Leverans och paket är självklara kandidater för mikrotjänster. Scheduler och Supervisor samordnar de aktiviteter som utförs av andra mikrotjänster, så det är klokt att implementera dessa domäntjänster som mikrotjänster.
Drönare och konto är intressanta eftersom de tillhör andra avgränsade kontexter. Ett alternativ är att Scheduler anropar kontexterna Drone och Account bounded direkt. Ett annat alternativ är att skapa mikrotjänster för drönare och konton i kontexten Leveransavgränsad. Dessa mikrotjänster skulle förmedlas mellan de avgränsade kontexterna genom att exponera API:er eller datascheman som är mer lämpade för leveranskontexten.
Informationen om de avgränsade kontexterna drone och konto ligger utanför den här vägledningens omfång, så vi skapade falska tjänster för dem i vår referensimplementering. Men här är några faktorer att tänka på i den här situationen:
Vad är nätverkskostnaderna för att anropa direkt i den andra begränsade kontexten?
Är dataschemat för den andra avgränsade kontexten lämpligt för den här kontexten, eller är det bättre att ha ett schema som är skräddarsytt för den här avgränsade kontexten?
Är den andra avgränsade kontexten ett äldre system? I så fall kan du skapa en tjänst som fungerar som ett lager mot korruption för att översätta mellan det äldre systemet och det moderna programmet.
Vad är teamstrukturen? Är det enkelt att kommunicera med teamet som ansvarar för den andra avgränsade kontexten? Om inte kan du skapa en tjänst som förmedlar mellan de två kontexterna för att minska kostnaderna för kommunikation mellan team.
Hittills har vi inte övervägt några icke-funktionella krav. När utvecklingsteamet tänkte på programmets dataflödeskrav bestämde de sig för att skapa en separat inmatningsmikrotjänst som ansvarar för att mata in klientbegäranden. Den här mikrotjänsten implementerar belastningsutjämning genom att placera inkommande begäranden i en buffert för bearbetning. Scheduler läser begäranden från bufferten och kör arbetsflödet.
Icke-funktionella krav ledde till att teamet skapade ytterligare en tjänst. Alla tjänster har hittills gått ut på att schemalägga och leverera paket i realtid. Men systemet måste också lagra historiken för varje leverans i långsiktig lagring för dataanalys. Teamet övervägde att göra detta till leveranstjänstens ansvar. Kraven på datalagring är dock helt olika för historisk analys jämfört med drift under flygning (se Dataöverväganden). Därför bestämde sig teamet för att skapa en separat leveranshistoriktjänst som lyssnar efter DeliveryTracking-händelser från leveranstjänsten och skriver händelserna i långsiktig lagring.
Följande diagram visar designen just nu:
Ladda ned en Visio-fil av den här arkitekturen.
Nästa steg
Nu bör du ha en tydlig förståelse för syftet med och funktionerna för varje mikrotjänst i din design. Nu kan du skapa systemet.