Identifiera gränser för mikrotjänster

Arkitekter och utvecklare har svårt att definiera rätt storlek för en mikrotjänst. Vägledning betonar ofta att undvika extremiteter av för stor eller för liten, men det rådet kan vara vagt i praktiken. Men om du börjar med en noggrant utformad domänmodell kan du enklare definiera rätt storlek och omfattning för varje mikrotjänst.

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.

1. Börja med en begränsad kontext. I allmänhet bör funktionerna i en mikrotjänst inte omfatta mer än en begränsad kontext. Per definition markerar en begränsad kontext gränsen för en specifik domänmodell. Om du upptäcker att en mikrotjänst blandar olika domänmodeller kan du behöva gå tillbaka och förfina domänanalysen.

2. 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:

   • 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.

3. 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 innehåller flera mikrotjänster. Programmet Drone Delivery visar ett exempel.

4. Överväg icke-funktionella krav. Titta på faktorer som teamstorlek, datatyper, tekniker, skalbarhetskrav, tillgänglighetskrav och säkerhetskrav. Dessa faktorer kan göra att du delar upp en mikrotjänst i flera mindre tjänster. I andra fall kan de leda till att du sammanfogar flera mikrotjänster till en enda mikrotjänst.

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 tillsammans. Varje tjänst ska kunna distribueras oberoende av varandra, utan att behöva distribuera om andra.

• Tjänsterna är inte nära kopplade och kan utvecklas oberoende av varandra.

• Tjänstgränser är utformade för att undvika problem med datakonsekvens eller integritet. I vissa fall innebär upprätthållande av datakonsekvens att relaterade funktioner grupperas i en enda mikrotjänst. Stark konsekvens krävs dock inte alltid. Distribuerade system tillhandahåller strategier för att hantera eventuell konsekvens, och fördelarna med att dela upp tjänster uppväger ofta komplexiteten i att hantera den.

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

Utvecklingsteamet har tidigare identifierat de fyra aggregeringarna Leverans, Paket, Drönare och Konto samt 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 anpassat till 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 teamet inte övervägt några icke-funktionella krav. När du har utvärderat programmets dataflödesbehov skapar utvecklingsteamet en separat inmatningsmikrotjänst för att hantera 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 sedan begäranden från bufferten och implementerar arbetsflödet.

Icke-funktionella krav leder också teamet till att skapa ytterligare en tjänst. De befintliga tjänsterna fokuserar på att schemalägga och leverera paket i realtid. Systemet måste dock även lagra leveranshistorik i långsiktig lagring för dataanalys. Till en början övervägde teamet att göra den här uppgiften till en del av leveranstjänsten. Men kraven på datalagring för historisk analys skiljer sig från kraven för drift under flygning. Mer information finns i Dataöverväganden. Därför skapade teamet en separat leveranshistoriktjänst. Den här tjänsten lyssnar efter DeliveryTracking-händelser från leveranstjänsten och skriver dem till 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.

Relaterade resurser

• Arkitekturdesign för mikrotjänster
• Använda taktisk DDD för att utforma mikrotjänster
• Använda domänanalys för att modellera mikrotjänster
• Välj ett Azure-beräkningsalternativ för mikrotjänster