Skapa mikrotjänster på AzureBuilding microservices on Azure

Mikrotjänster har blivit en populär arkitekturstil för att skapa molnprogram som är elastiska, mycket skalbara, kan distribueras oberoende av varandra och som kan utvecklas snabbt.Microservices are a popular architectural style for building applications that are resilient, highly scalable, independently deployable, and able to evolve quickly. Men för en lyckad mikrotjänstarkitektur krävs en annan metod för att utforma och skapa program.But a successful microservices architecture requires a different approach to designing and building applications.

En arkitektur för mikrotjänster består av en samling små, autonoma tjänster.A microservices architecture consists of a collection of small, autonomous services. Varje tjänst är självständig och ska implementera en enda verksamhetsfunktion.Each service is self-contained and should implement a single business capability.

Logiskt diagram för format för arkitektur för mikrotjänster

Vad är mikrotjänster?What are microservices?

  • Mikrotjänster är små, oberoende och löst kopplade.Microservices are small, independent, and loosely coupled. En liten grupp utvecklare ska kunna skriva och underhålla en sådan tjänst.A single small team of developers can write and maintain a service.

  • Varje tjänst utgör en separat kodbas som kan hanteras av ett litet utvecklingsteam.Each service is a separate codebase, which can be managed by a small development team.

  • Tjänster kan distribueras oberoende av varandra.Services can be deployed independently. Ett team kan uppdatera en befintlig tjänst utan att bygga om och omdistribuera hela programmet.A team can update an existing service without rebuilding and redeploying the entire application.

  • Tjänsterna svarar för att spara sina egna data eller externa tillstånd.Services are responsible for persisting their own data or external state. Detta skiljer sig från den traditionella modellen, där ett separat datalager hanterar datapersistensen.This differs from the traditional model, where a separate data layer handles data persistence.

  • Tjänster kommunicerar med varandra med hjälp av väldefinierade API:er.Services communicate with each other by using well-defined APIs. Interna implementeringsdetaljer för varje tjänst är dolda från andra tjänster.Internal implementation details of each service are hidden from other services.

  • Tjänsterna behöver inte dela samma teknikstack, bibliotek eller ramverk.Services don't need to share the same technology stack, libraries, or frameworks.

Förutom tjänsterna själva visas vissa andra komponenter i en typisk mikrotjänstarkitektur:Besides for the services themselves, some other components appear in a typical microservices architecture:

Hantering/orkestrering.Management/orchestration. Den här komponenten ansvarar för att placera tjänster på noder, identifiera fel, ombalansera tjänster över flera noder och så vidare.This component is responsible for placing services on nodes, identifying failures, rebalancing services across nodes, and so forth. Den här komponenten består vanligtvis av en startklar teknik, till exempel Kubernetes, i stället för något som är anpassat.Typically this component is an off-the-shelf technology such as Kubernetes, rather than something custom built.

API-gateway.API Gateway. API-gatewayen är startpunkten för klienterna.The API gateway is the entry point for clients. I stället för att anropa tjänsten direkt anropar klienten API-gatewayen, som vidarebefordrar anropet till rätt tjänster på serverdelen.Instead of calling services directly, clients call the API gateway, which forwards the call to the appropriate services on the back end.

Fördelarna med att använda en API-gateway är bland annat följande:Advantages of using an API gateway include:

  • Den frikopplar klienter från tjänster.It decouples clients from services. Tjänsterna kan versionshanteras eller omstruktureras utan att alla klienter behöver uppdateras.Services can be versioned or refactored without needing to update all of the clients.

  • Tjänsterna kan använda meddelandeprotokoll som inte är webbvänliga, till exempel AMQP.Services can use messaging protocols that are not web friendly, such as AMQP.

  • API-gatewayen kan utföra andra övergripande funktioner, till exempel autentisering, loggning, SSL-avslutning och belastningsutjämning.The API Gateway can perform other cross-cutting functions such as authentication, logging, SSL termination, and load balancing.

FördelarBenefits

  • Smidighet.Agility. Eftersom mikrotjänster distribueras oberoende är det enklare att hantera felkorrigeringar och kommande versioner.Because microservices are deployed independently, it's easier to manage bug fixes and feature releases. Du kan uppdatera en tjänst utan att omdistribuera hela programmet, och återställa en uppdatering om något blir fel.You can update a service without redeploying the entire application, and roll back an update if something goes wrong. Om ett fel hittas i en del av programmet kan detta i många traditionella program blockera hela lanseringen.In many traditional applications, if a bug is found in one part of the application, it can block the entire release process. Nya funktioner kan därför skjutas upp medan en felkorrigering integreras, testas och publiceras.New features may be held up waiting for a bug fix to be integrated, tested, and published.

  • Små, fokuserade team.Small, focused teams. En mikrotjänst bör vara så liten att ett enda funktionsteam ska kunna skapa, testa och distribuera den.A microservice should be small enough that a single feature team can build, test, and deploy it. Små teamstorlekar främjar mer flexibilitet.Small team sizes promote greater agility. Stora grupper tenderar att vara mindre produktiva eftersom kommunikationen är långsammare, hanteringskostnaderna ökar och flexibiliteten minskar.Large teams tend be less productive, because communication is slower, management overhead goes up, and agility diminishes.

  • Liten kodbas.Small code base. I ett monolitiskt program finns det en tendens att kodberoenden trasslar till sig med tiden. Det innebär att man måste ändra koden på många olika ställen för att lägga till en ny funktion.In a monolithic application, there is a tendency over time for code dependencies to become tangled Adding a new feature requires touching code in a lot of places. Eftersom en arkitektur för mikrotjänster inte delar kod eller datalager minimeras beroenden, vilket gör det enklare att lägga till nya funktioner.By not sharing code or data stores, a microservices architecture minimizes dependencies, and that makes it easier to add new features.

  • Blandning av tekniker.Mix of technologies. Team kan välja den teknik som bäst passar deras tjänst med en blandning av teknikstackar efter behov.Teams can pick the technology that best fits their service, using a mix of technology stacks as appropriate.

  • Felisolering.Fault isolation. Om en enskild mikrotjänst blir otillgänglig stör den inte hela programmet så länge överordnade mikrotjänster är utformade för att hantera fel på rätt sätt (till exempel via implementering av kretsnedbrytning).If an individual microservice becomes unavailable, it won't disrupt the entire application, as long as any upstream microservices are designed to handle faults correctly (for example, by implementing circuit breaking).

  • Skalbarhet.Scalability. Tjänsterna kan skalas oberoende av varandra, vilket gör att du kan skala ut delsystem som kräver mer resurser utan att skala ut hela programmet.Services can be scaled independently, letting you scale out subsystems that require more resources, without scaling out the entire application. Med hjälp av en initierare som Kubernetes eller Service Fabric kan du också placera tjänster med högre densitet i en enda värd, vilket effektiviserar utnyttjandet av resurser.Using an orchestrator such as Kubernetes or Service Fabric, you can pack a higher density of services onto a single host, which allows for more efficient utilization of resources.

  • Dataisolering.Data isolation. Det är mycket enklare att utföra schemauppdateringar eftersom endast en mikrotjänst påverkas.It is much easier to perform schema updates, because only a single microservice is affected. I ett monolitiskt program kan schemauppdateringar utgöra en stor utmaning. Det beror på att olika delar av programmet kan beröra samma data, vilket gör det riskfyllt att ändra något i schemat.In a monolithic application, schema updates can become very challenging, because different parts of the application may all touch the same data, making any alterations to the schema risky.

UtmaningarChallenges

Fördelarna med mikrotjänster är dock inte gratis.The benefits of microservices don't come for free. Här är några av utmaningar du bör tänka på när du väljer en arkitektur för dina mikrotjänster.Here are some of the challenges to consider before embarking on a microservices architecture.

  • Komplexitet.Complexity. Ett mikrotjänstprogram har fler rörliga delar än motsvarande monolitiska program.A microservices application has more moving parts than the equivalent monolithic application. Varje enskilt tjänst är enklare, men systemet som helhet är mer komplext.Each service is simpler, but the entire system as a whole is more complex.

  • Utveckling och testning.Development and testing. Att skriva en liten tjänst som använder andra beroende tjänster kräver en annan metod än att skriva ett traditionellt monolitiskt eller flernivåsprogram.Writing a small service that relies on other dependent services requires a different approach than a writing a traditional monolithic or layered application. Befintliga verktyg är inte alltid utformade för att fungera med tjänstberoenden.Existing tools are not always designed to work with service dependencies. Omstrukturering över tjänstegränserna kan vara svårt.Refactoring across service boundaries can be difficult. Det är också svårt för att testa tjänstens beroenden, i synnerhet när programmet utvecklas snabbt.It is also challenging to test service dependencies, especially when the application is evolving quickly.

  • Brist på styrning.Lack of governance. Den decentraliserade lösningen för att skapa mikrotjänster har fördelar, men den kan också leda till problem.The decentralized approach to building microservices has advantages, but it can also lead to problems. Du kan få många olika språk och ramverk att programmet blir svårt att underhålla.You may end up with so many different languages and frameworks that the application becomes hard to maintain. Det kan vara praktiskt att införa vissa projektövergripande standarder, utan att alltför begränsa teamets flexibilitet alltför mycket.It may be useful to put some project-wide standards in place, without overly restricting teams' flexibility. Detta gäller särskilt för övergripande funktioner, till exempel loggning.This especially applies to cross-cutting functionality such as logging.

  • Nätverksbelastning och svarstid.Network congestion and latency. Användningen av många små, detaljerade tjänster kan leda till ökad kommunikation mellan tjänsterna.The use of many small, granular services can result in more interservice communication. Även om kedjan av tjänsteberoenden blir för lång (tjänst A anropar B, som anropar C osv.), kan den förlängda svarstiden bli ett problem.Also, if the chain of service dependencies gets too long (service A calls B, which calls C...), the additional latency can become a problem. Du behöver designa API:erna noggrant.You will need to design APIs carefully. Undvik alltför trafikintensiva API:er genom att tänka på serialiseringsformatet och titta efter platser där asynkrona kommunikationsmönster kan användas.Avoid overly chatty APIs, think about serialization formats, and look for places to use asynchronous communication patterns.

  • Dataintegritet.Data integrity. Med varje mikrotjänst som ansvarar för den egna datapersistensen.With each microservice responsible for its own data persistence. Datakonsekvens kan därför utgöra en utmaning.As a result, data consistency can be a challenge. Tänk på den slutliga konsekvensen där det är möjligt.Embrace eventual consistency where possible.

  • Hantering.Management. För att lyckas med mikrotjänster krävs en mogen DevOps-kultur.To be successful with microservices requires a mature DevOps culture. Korrelerad loggning för flera tjänster kan vara en utmaning.Correlated logging across services can be challenging. Normalt måste loggningen samordna flera tjänstanrop för en enskild användaråtgärd.Typically, logging must correlate multiple service calls for a single user operation.

  • Versionshantering.Versioning. Uppdateringar av en tjänst får inte påverka tjänster som är beroende av den på ett negativt sätt.Updates to a service must not break services that depend on it. Flera tjänster kan uppdateras när som helst, så utan noggrann design kan du få problem med bakåt- eller framåtkompatibilitet.Multiple services could be updated at any given time, so without careful design, you might have problems with backward or forward compatibility.

  • Kompetens.Skillset. Mikrotjänster är högdistribuerade system.Microservices are highly distributed systems. Utvärdera noggrant om teamet har de kunskaper och erfarenheter som krävs för att lyckas.Carefully evaluate whether the team has the skills and experience to be successful.

Process för att utforma en arkitektur för mikrotjänsterProcess for building a microservices architecture

Artiklarna i den här listan visar en strukturerad metod för att utforma, skapa och driva en arkitektur för mikrotjänster.The articles listed here present a structured approach for designing, building, and operating a microservices architecture.

Domänanalys.Domain analysis. För att undvika en del vanliga fallgropar när du skapar mikrotjänster kan du använda domänanalys för att definiera mikrotjänsternas gränser.To avoid some common pitfalls when designing microservices, use domain analysis to define your microservice boundaries. Följ de här stegen:Follow these steps:

  1. Använda domänanalys för att utforma mikrotjänstmodeller.Use domain analysis to model microservices.
  2. Använda taktisk DDD för att utforma mikrotjänster.Use tactical DDD to design microservices.
  3. Identifiera gränser för mikrotjänster.Identify microservice boundaries.

Utforma tjänsterna.Design the services. Mikrotjänster kräver en annan metod än när du utformar och skapar program.Microservices require a different approach to designing and building applications. Mer information hittar du i Utforma en arkitektur för mikrotjänster.For more information, see Designing a microservices architecture.

Bearbeta i produktionen.Operate in production. Eftersom arkitekturer för mikrotjänster distribueras måste du ha robusta åtgärder för distribution och övervakning.Because microservices architectures are distributed, you must have robust operations for deployment and monitoring.