Waarom een microservices benadering voor het ontwikkelen van toepassingen?Why a microservices approach to building applications?

Software-ontwikkelaars zijn er geen nieuwe functies in onze verwachting over waarbij een toepassing in onderdelen.As software developers, there is nothing new in how we think about factoring an application into component parts. Het is het centrale paradigma stand object software abstracties en componentization.It is the central paradigm of object orientation, software abstractions, and componentization. Vandaag de dag doorgaans dit factoriseren de vorm van klassen en interfaces tussen gedeelde bibliotheken en lagen van de technologie.Today, this factorization tends to take the form of classes and interfaces between shared libraries and technology layers. Normaal gesproken wordt een gelaagde benadering gemaakt met een back-end-winkel, bedrijfslogica middelste laag en een front-gebruikersinterface (UI).Typically, a tiered approach is taken with a back-end store, middle-tier business logic, and a front-end user interface (UI). Wat heeft gewijzigd in de afgelopen jaren is dat we, ontwikkelaars, bouwt gedistribueerde toepassingen die voor de cloud en aangedreven door het bedrijf.What has changed over the last few years is that we, as developers, are building distributed applications that are for the cloud and driven by the business.

De veranderende bedrijfsbehoeften zijn:The changing business needs are:

  • Een service die gebouwd en werkt op grote schaal om klanten te bereiken in de nieuwe geografische regio's (bijvoorbeeld).A service that's built and operates at scale to reach customers in new geographical regions (for example).
  • Snellere levering van functies en mogelijkheden om te kunnen reageren op verzoeken van klanten in een flexibele manier.Faster delivery of features and capabilities to be able to respond to customer demands in an agile way.
  • Verbeterde Resourcegebruik om kosten te verlagen.Improved resource utilization to reduce costs.

Deze bedrijfsbehoeften van invloed zijn op hoe we bij het ontwikkelen van toepassingen.These business needs are affecting how we build applications.

Lees voor meer informatie over de aanpak van Azure naar microservices Microservices: een toepassing revolution aangedreven door de cloud.For more information about the approach of Azure to microservices, read Microservices: An application revolution powered by the cloud.

Monolithische versus microservice ontwerpbenaderingMonolithic vs. microservice design approach

Alle toepassingen ontwikkelen gedurende een bepaalde periode.All applications evolve over time. Succesvolle toepassingen ontwikkelen door handig voor gebruikers.Successful applications evolve by being useful to people. Mislukte toepassingen niet doen evolueren en uiteindelijk zijn afgeschaft.Unsuccessful applications do not evolve and eventually are deprecated. De volgende vraag: hoeveel u weet over de vereisten van uw vandaag en wat ze worden in de toekomst?The question becomes: How much do you know about your requirements today, and what will they be in the future? Stel dat dat u een reporting-toepassing voor een afdeling wilt maken.For example, let's say that you are building a reporting application for a department. U bent ervoor dat de toepassing binnen het bereik van uw bedrijf blijft en dat de rapporten tijdelijke.You are sure that the application remains within the scope of your company and that the reports are short-lived. Uw keuze van benadering wijkt af van, spreken, video-inhoud tientallen miljoenen klanten bouwen van een service die biedt.Your choice of approach is different from, say, building a service that delivers video content to tens of millions of customers.

Soms iets uit de deur krijgen als bewijs van het concept is de aangedreven factor terwijl u weet dat de toepassing later kan worden aangepast.Sometimes, getting something out the door as proof of concept is the driving factor, while you know that the application can be redesigned later. Er is weinig punt in iets te veel engineering die nooit wordt gebruikt.There is little point in over-engineering something that never gets used. Het is de gebruikelijke engineering verhouding.It’s the usual engineering trade-off. Wanneer bedrijven over bouwen voor de cloud praten, is de verwachting aan de andere kant groei en informatie over het gebruik.On the other hand, when companies talk about building for the cloud, the expectation is growth and usage. Het probleem is dat groei en schaal onvoorspelbaar zijn.The issue is that growth and scale are unpredictable. We willen mogelijk prototype snel achterhoofd ook dat er zich op een pad bevinden naar het omgaan met succes in de toekomst.We would like to be able to prototype quickly while also knowing that we are on a path to deal with future success. Dit is het starten van de lean benadering: bouwen, te meten, informatie over en herhalen.This is the lean startup approach: build, measure, learn, and iterate.

Tijdens de era client / server-doorgaans we ligt de nadruk op gelaagde toepassingen bouwen met behulp van specifieke technologieën in elke laag.During the client-server era, we tended to focus on building tiered applications by using specific technologies in each tier. De term monolithische toepassing geworden dat voor deze methoden.The term monolithic application has emerged for these approaches. De interfaces doorgaans tussen de lagen en het ontwerp van een meer nauw gekoppeld tussen onderdelen binnen elke laag is gebruikt.The interfaces tended to be between the tiers, and a more tightly coupled design was used between components within each tier. Ontwikkelaars ontworpen en meeberekend klassen die zijn gecompileerd in bibliotheken en aan elkaar gekoppeld in een paar uitvoerbare programma's en dll-bestanden.Developers designed and factored classes that were compiled into libraries and linked together into a few executables and DLLs.

Er zijn voordelen voor dergelijke monolithische ontwerpplan.There are benefits to such a monolithic design approach. Het is vaak eenvoudiger te ontwerpen en biedt sneller aanroepen tussen onderdelen, omdat deze aanroepen vaak via IPC (interprocess communication zijn).It's often simpler to design, and it has faster calls between components, because these calls are often over interprocess communication (IPC). Bovendien iedereen één product dat meer mensen resources efficiënt worden doorgaans wordt getest.Also, everyone tests a single product, which tends to be more people-resource efficient. Het nadeel is dat er een nauwe koppeling tussen gelaagde lagen, en u kunt geen afzonderlijke onderdelen schalen.The downside is that there's a tight coupling between tiered layers, and you cannot scale individual components. Als u uitvoeren voor oplossingen of upgrades wilt, hebt u wachten tot andere klaar bent met testen.If you need to perform fixes or upgrades, you have to wait for others to finish their testing. Het is moeilijker te flexibel zijn.It is more difficult to be agile.

Microservices adres deze nadelen en meer nauw uitgelijnd met de voorgaande zakelijke vereisten, maar ze hebben ook zowel voordelen en verplichtingen.Microservices address these downsides and more closely align with the preceding business requirements, but they also have both benefits and liabilities. De voordelen van microservices zijn dat elk criterium doorgaans eenvoudiger business functionaliteit, zodat u omhoog of omlaag test schalen, implementeren en beheren onafhankelijk ingekapseld.The benefits of microservices are that each one typically encapsulates simpler business functionality, which you scale up or down, test, deploy, and manage independently. Een belangrijk voordeel van een microservice-benadering is dat teams meer bedrijfsscenario's dan wordt aangestuurd door technologie, waardoor de gelaagde benadering.One important benefit of a microservice approach is that teams are driven more by business scenarios than by technology, which the tiered approach encourages. In de praktijk kleinere teams een microservice op basis van een klant-scenario ontwikkelen en eventuele technologieën die ze gebruiken.In practice, smaller teams develop a microservice based on a customer scenario and use any technologies they choose.

Met andere woorden, hoeft de organisatie niet tech om bij te houden microservice-toepassingen te standaardiseren.In other words, the organization doesn’t need to standardize tech to maintain microservice applications. Afzonderlijke teams dat eigen services doen kunnen wat zinvol voor toe op basis van het team expertise of wat is het meest geschikt is voor het oplossen van het probleem.Individual teams that own services can do what makes sense for them based on team expertise or what’s most appropriate to solve the problem. In de praktijk kan een reeks aanbevolen technologieën, zoals een bepaald NoSQL opslaan of web-toepassingsframework, verdient de voorkeur.In practice, a set of recommended technologies, such as a particular NoSQL store or web application framework, is preferable.

Het nadeel van microservices wordt geleverd in het beheren van het toegenomen aantal afzonderlijke entiteiten en omgaan met complexere implementaties en versiebeheer.The downside of microservices comes in managing the increased number of separate entities and dealing with more complex deployments and versioning. Netwerkverkeer tussen de microservices wordt verhoogd en de bijbehorende netwerkvertragingen.Network traffic between the microservices increases as well as the corresponding network latencies. Veel chatty, gedetailleerde services zijn een recept voor een nachtmerrie prestaties.Lots of chatty, granular services are a recipe for a performance nightmare. Zonder hulpmiddelen voor het weergeven deze afhankelijkheden, is het moeilijk te 'Zie"van het gehele systeem.Without tools to help view these dependencies, it is hard to “see” the whole system.

Standaarden maken de aanpak microservice werk door afspreken communiceren en fouttolerante alleen de bewerkingen die u nodig van een service hebt wordt in plaats van rigid contracten.Standards make the microservice approach work by agreeing on how to communicate and being tolerant of only the things you need from a service, rather than rigid contracts. Het is belangrijk deze contracten vooraf definiëren in het ontwerp voor services bijwerken onafhankelijk van elkaar.It is important to define these contracts up front in the design, because services update independently of each other. Een andere beschrijving lang geleden bedacht voor het ontwerpen van een benadering microservices is ' fijnmazig service oriented architecture (SOA).'Another description coined for designing with a microservices approach is “fine-grained service-oriented architecture (SOA).”

De eenvoudigste is de ontwerpbenadering microservices over een ontkoppelde federation Services met onafhankelijke wijzigingen aan elk en overeengekomen standaarden voor communicatie.At its simplest, the microservices design approach is about a decoupled federation of services, with independent changes to each, and agreed-upon standards for communication.

Als u meer cloud-apps worden geproduceerd, detecteren mensen dat deze afbreken van de algehele app in onafhankelijke, scenario gerichte services een beter op lange termijn benadering is.As more cloud apps are produced, people discover that this decomposition of the overall app into independent, scenario-focused services is a better long-term approach.

Vergelijking tussen toepassingsontwikkeling nadertComparison between application development approaches

Toepassingsontwikkeling service Fabric-platform

1) Een monolithisch app domeinspecifieke functionaliteit bevat en normaal wordt gedeeld door functionele lagen, zoals web en business gegevens.A monolithic app contains domain-specific functionality and is normally divided by functional layers, such as web, business, and data.

2) U een monolithisch app schalen door het klonen op meerdere servers/virtuele machines/containers.You scale a monolithic app by cloning it on multiple servers/virtual machines/containers.

3) Een toepassing microservice scheidt functionaliteit in afzonderlijke kleinere services.A microservice application separates functionality into separate smaller services.

4) De microservices benadering schalen uit door het implementeren van elke service afzonderlijk, exemplaren van deze services te maken tussen servers/virtuele machines/containers.The microservices approach scales out by deploying each service independently, creating instances of these services across servers/virtual machines/containers.

Met een microservice ontwerpen benadering is niet een wondermiddel voor alle projecten, maar deze zijn afgestemd nauwkeuriger de zakelijke doelstellingen die eerder zijn beschreven.Designing with a microservice approach is not a panacea for all projects, but it does align more closely with the business objectives described earlier. Beginnen met een monolithisch benadering wellicht acceptabel als u weet dat u hebt de mogelijkheid hoger herzien van de code in het ontwerp van een microservices.Starting with a monolithic approach might be acceptable if you know that you will have the opportunity to rework the code later into a microservices design. Vaker voorkomt, begint met een monolithisch toepassing en langzaam splits deze in fasen verlopen, beginnen met de modules die moeten worden meer schaalbare of flexibele.More commonly, you begin with a monolithic application and slowly break it up in stages, starting with the functional areas that need to be more scalable or agile.

Om samen te vatten, is de microservice-benadering voor het opstellen van uw toepassing van veel kleine services.To summarize, the microservice approach is to compose your application of many small services. De services worden uitgevoerd in de containers die zijn geïmplementeerd op een cluster van machines.The services run in containers that are deployed across a cluster of machines. Kleinere teams ontwikkelen van een service die is gericht op een scenario onafhankelijk, versie testen, implementeren en schalen van elke service, zodat de gehele toepassing kunt ontwikkelen.Smaller teams develop a service that focuses on a scenario and independently test, version, deploy, and scale each service so that the entire application can evolve.

Wat is een microservice?What is a microservice?

Er zijn verschillende definities van microservices.There are different definitions of microservices. Als u Internet zoekt, vindt u veel nuttige informatiebronnen die hun eigen standpunten en definities bieden.If you search the Internet, you'll find many useful resources that provide their own viewpoints and definitions. Echter, de meeste van de volgende kenmerken van microservices zijn algemeen overeengekomen:However, most of the following characteristics of microservices are widely agreed upon:

  • Een klant of zakelijke scenario inkapselen.Encapsulate a customer or business scenario. Wat is het probleem dat u het oplossen van?What is the problem you are solving?
  • Ontwikkeld door een klein engineering team.Developed by a small engineering team.
  • Geschreven in elke programmeertaal en elk framework gebruiken.Written in any programming language and use any framework.
  • Bestaan uit de code en (optioneel) state, die beide zijn onafhankelijk samengestelde geïmplementeerd en geschaald.Consist of code and (optionally) state, both of which are independently versioned, deployed, and scaled.
  • Communiceren met andere microservices via goed gedefinieerde interfaces en protocollen.Interact with other microservices over well-defined interfaces and protocols.
  • Unieke namen (URL's) gebruikt voor het omzetten van de locatie hebben.Have unique names (URLs) used to resolve their location.
  • Blijven consistent en beschikbaar is in geval van problemen.Remain consistent and available in the presence of failures.

U kunt deze kenmerken in samenvatten:You can summarize these characteristics into:

Microservice-toepassingen bestaan uit kleine, onafhankelijk van elkaar samengestelde en schaalbare klantgerichte services die via standaardprotocollen met goed gedefinieerde interfaces met elkaar communiceren.Microservice applications are composed of small, independently versioned, and scalable customer-focused services that communicate with each other over standard protocols with well-defined interfaces.

We de eerste twee punten in de vorige sectie besproken en nu we uitvouwt op en de andere verduidelijken.We covered the first two points in the preceding section, and now we expand on and clarify the others.

Geschreven in elke programmeertaal en elk framework gebruikenWritten in any programming language and use any framework

Ontwikkelaars moeten we kiezen een taal of elk framework dat we, afhankelijk van onze vaardigheden of de behoeften van de service willen.As developers, we should be free to choose a language or framework that we want, depending on our skills or the needs of the service. In sommige services mogelijk u prestatievoordelen van C++ boven alle andere waarde.In some services, you might value the performance benefits of C++ above all else. In andere services, kan het gemak van beheerde-ontwikkeling in C# of Java zeer belangrijk zijn.In other services, the ease of managed development in C# or Java might be most important. In sommige gevallen moet u wellicht een specifieke partner-bibliotheek, technologie voor gegevensopslag of wijze van het blootstellen van de service voor clients gebruiken.In some cases, you may need to use a specific partner library, data storage technology, or means of exposing the service to clients.

Nadat u hebt ervoor gekozen een technologie u keert u naar de operationele of lifecycle management en schalen van de service.After you have chosen a technology, you come to the operational or lifecycle management and scaling of the service.

Kan code en status als onafhankelijk samengestelde geïmplementeerd en geschaaldAllows code and state to be independently versioned, deployed, and scaled

U wilt echter schrijven van uw microservices, de code en eventueel de status moeten onafhankelijk implementeren, bijwerken en schalen.However you choose to write your microservices, the code and optionally the state should independently deploy, upgrade, and scale. Dit is daadwerkelijk een van de problemen moeilijker om op te lossen, omdat het afkomstig niet actief voor uw keuze van technologieën is.This is actually one of the harder problems to solve, because it comes down to your choice of technologies. Voor vergroten/verkleinen, begrijpen hoe partitie (of shard) de code en de status is lastig.For scaling, understanding how to partition (or shard) both the code and state is challenging. Wanneer de code en de status van afzonderlijke technologieën die algemene vandaag, moeten de implementatiescripts voor uw microservice kunnen omgaan met beide schalen.When the code and state use separate technologies, which is common today, the deployment scripts for your microservice need to be able to cope with scaling them both. Dit is ook over wendbaarheid en flexibiliteit, zodat u enkele van de microservices bijwerken kunt zonder dat ze allemaal in één keer te upgraden.This is also about agility and flexibility, so you can upgrade some of the microservices without having to upgrade all of them at once.

Wordt teruggezonden naar de monolithische versus microservice benadering even, toont het volgende diagram de verschillen in de aanpak voor het opslaan van status.Returning to the monolithic versus microservice approach for a moment, the following diagram shows the differences in the approach to storing state.

Status opslag tussen toepassing stijlenState storage between application styles

Service Fabric-platform status opslag

De monolithische aanpak aan de linkerkant heeft een individuele database en lagen van specifieke technologieën.The monolithic approach on the left has a single database and tiers of specific technologies.

De methode microservices aan de rechterkant biedt een grafiek van onderling verbonden microservices waarin staat doorgaans is afgestemd op de microservice en verschillende technologieën worden gebruikt.The microservices approach on the right has a graph of interconnected microservices where state is typically scoped to the microservice and various technologies are used.

In een monolithisch benadering, doorgaans de toepassing gebruikt een individuele database.In a monolithic approach, typically the application uses a single database. Het voordeel is dat er één locatie, waardoor u eenvoudig te implementeren.The advantage is that it is a single location, which makes it easy to deploy. Elk onderdeel kan één tabel voor het opslaan van de status hebben.Each component can have a single table to store its state. Teams moeten strikt staat die moeilijk te scheiden.Teams need to strictly separate state, which is a challenge. Er zijn onvermijdelijk temptations een nieuwe kolom toevoegen aan een bestaande klantentabel, een koppeling tussen tabellen en afhankelijkheden in de opslaglaag maken.Inevitably there are temptations to add a new column to an existing customer table, do a join between tables, and create dependencies at the storage layer. Nadat dit gebeurt, kunt u afzonderlijke onderdelen kan niet schalen.After this happens, you can't scale individual components.

In de methode microservices, elke service beheert en slaat de eigen staat.In the microservices approach, each service manages and stores its own state. Elke service is verantwoordelijk voor het schalen van zowel de code en de status samen om te voldoen aan de vereisten van de service.Each service is responsible for scaling both code and state together to meet the demands of the service. Een nadeel is wanneer een hoeft te maken van weergaven of query's van de gegevens van uw toepassing, moet u een query in uiteenlopende status winkels.A downside is that when there is a need to create views, or queries, of your application’s data, you need to query across disparate state stores. Dit is meestal opgelost door een afzonderlijke microservice die een weergave in een verzameling microservices voortbouwt.Typically, this is solved by having a separate microservice that builds a view across a collection of microservices. Als u meerdere ad hoc query's uitvoeren op de gegevens wilt, moet elke microservice rekening houden met de gegevens schrijven naar een gegevensservice magazijnbeheer voor offline analyses.If you need to perform multiple impromptu queries on the data, each microservice should consider writing its data to a data warehousing service for offline analytics.

Versiebeheer is specifiek voor de geïmplementeerde versie van een microservice zodanig dat meerdere verschillende versies implementeren en naast elkaar uitvoeren.Versioning is specific to the deployed version of a microservice so that multiple, different versions deploy and run side by side. Versiebeheer voor onderdelen heeft betrekking op de scenario's waarbij een nieuwere versie van een microservice mislukt tijdens de upgrade en moet terugkeren naar een eerdere versie.Versioning addresses the scenarios where a newer version of a microservice fails during upgrade and needs to roll back to an earlier version. Het andere scenario voor versiebeheer is bezig met testen van A/B-stijl, waarbij verschillende gebruikers verschillende versies van de service ondervindt.The other scenario for versioning is performing A/B-style testing, where different users experience different versions of the service. Bijvoorbeeld, wordt het meestal een microservice voor een specifieke set klanten nieuwe functionaliteit te testen voordat u veel meer rolling upgrade.For example, it is common to upgrade a microservice for a specific set of customers to test new functionality before rolling it out more widely. Na het levenscyclusbeheer van microservices biedt deze nu ons voor de communicatie ertussen.After lifecycle management of microservices, this now brings us to communication between them.

Interactie met andere microservices via goed gedefinieerde interfaces en protocollenInteracts with other microservices over well-defined interfaces and protocols

In dit onderwerp aandacht weinig hier, omdat uitgebreide documentatie over service oriented architecture die is gepubliceerd in de afgelopen 10 jaar communicatiepatronen beschrijft.This topic needs little attention here, because extensive literature about service-oriented architecture that has been published over the past 10 years describes communication patterns. Servicecommunicatie gebruikt in het algemeen een REST-benadering met HTTP- en TCP-protocollen en XML- of JSON als de serialisatie-indeling.Generally, service communication uses a REST approach with HTTP and TCP protocols and XML or JSON as the serialization format. Vanuit het perspectief van een interface wordt de ontwerpbenadering web gaan hanteren.From an interface perspective, it is about embracing the web design approach. Maar niets u voorkomt met binaire protocollen of uw eigen gegevensindelingen.But nothing stops you from using binary protocols or your own data formats. Worden voorbereid voor gebruikers lastiger tegelijk met uw microservices als deze protocollen en indelingen niet openbaar beschikbaar zijn.Be prepared for people to have a harder time using your microservices if these protocols and formats are not openly available.

Heeft een unieke naam (URL) gebruikt voor het omzetten van de locatieHas a unique name (URL) used to resolve its location

Houd er rekening mee hoe we houden zeggen dat de aanpak microservice lijkt op het web?Remember how we keep saying that the microservice approach is like the web? Zoals het web moet uw microservice adresseerbare waar deze wordt uitgevoerd.Like the web, your microservice needs to be addressable wherever it is running. Als u denkt u over virtuele machines en welke een bepaalde microservice wordt uitgevoerd, gaan dingen onjuiste snel.If you are thinking about machines and which one is running a particular microservice, things go bad quickly.

Op dezelfde manier dat DNS worden omgezet in een bepaalde URL een bepaalde machine, moet uw microservice een unieke naam hebben, zodat de huidige locatie kan worden gedetecteerd.In the same way that DNS resolves a particular URL to a particular machine, your microservice needs to have a unique name so that its current location is discoverable. Microservices moet adresseerbare namen zodat ze onafhankelijk van de infrastructuur die ze worden uitgevoerd.Microservices need addressable names that make them independent from the infrastructure that they are running on. Dit betekent dat er een interactie tussen hoe uw service wordt geïmplementeerd en hoe deze wordt gedetecteerd, is omdat er moet een register service zijn.This implies that there is an interaction between how your service is deployed and how it is discovered, because there needs to be a service registry. Evenredig, wanneer een machine is mislukt, de registry-service moet laat u weten waar de service wordt nu uitgevoerd.Equally, when a machine fails, the registry service must tell you where the service is now running.

Hiermee beschikt u over ons naar het volgende onderwerp: herstelmogelijkheden en consistentie.This brings us to the next topic: resilience and consistency.

Blijft consistent en beschikbaar is in geval van problemenRemains consistent and available in the presence of failures

Omgaan met onverwachte fouten is een van de moeilijkst problemen kunt oplossen, met name in een gedistribueerde systemen.Dealing with unexpected failures is one of the hardest problems to solve, especially in a distributed system. Veel van de code die we als ontwikkelaars schrijven is afhandeling van uitzonderingen en dit is ook waar de meeste tijd is besteed aan het testen.Much of the code that we write as developers is handling exceptions, and this is also where the most time is spent in testing. Het probleem is meer dan het schrijven van code voor het afhandelen van fouten die zijn betrokken.The problem is more involved than writing code to handle failures. Wat gebeurt er wanneer de computer waarop de microservice wordt uitgevoerd mislukt?What happens when the machine where the microservice is running fails? Niet alleen moet u deze microservice-fout (een vaste probleem zelf) te detecteren, maar u moet ook iets opnieuw opstarten van uw microservice.Not only do you need to detect this microservice failure (a hard problem on its own), but you also need something to restart your microservice.

Een microservice moet netwerkfouten fouten en opnieuw opstarten vaak op een andere computer omwille van de beschikbaarheid.A microservice needs to be resilient to failures and restart often on another machine for availability reasons. Dit wordt ook geleverd omlaag naar de status die is opgeslagen namens de microservice wanneer deze status uit door de microservice kunt herstellen, en of de microservice kunnen starten met succes is.This also comes down to the state that was saved on behalf of the microservice, where the microservice can recover this state from, and whether the microservice is able to restart successfully. Met andere woorden, moet er herstelmogelijkheden in de berekening (het proces opnieuw opgestart), evenals de herstelmogelijkheden in de status of de gegevens (zonder verlies van gegevens en de gegevens consistent blijven).In other words, there needs to be resilience in the compute (the process restarts) as well as resilience in the state or data (no data loss and the data remains consistent).

De problemen van de tolerantie zijn samengesteld tijdens andere scenario's, zoals wanneer fouten tijdens een upgrade van de toepassing optreden.The problems of resiliency are compounded during other scenarios, such as when failures happen during an application upgrade. De microservice, werken met het implementatiesysteem hoeft niet te herstellen.The microservice, working with the deployment system, doesn't need to recover. Ook moet deze vervolgens beslissen of u kunt doorgaan verder gaan naar de nieuwere versie of in plaats daarvan terugdraaien naar een eerdere versie te onderhouden van een consistente status.It also needs to then decide whether it can continue to move forward to the newer version or instead roll back to a previous version to maintain a consistent state. Vragen zoals of voldoende machines zijn beschikbaar voor het doorsturen zwevend houden en het herstellen van eerdere versies van de microservice moeten worden overwogen.Questions such as whether enough machines are available to keep moving forward and how to recover previous versions of the microservice need to be considered. Hiervoor moet de microservice statusgegevens om deze beslissingen te kunnen verzenden.This requires the microservice to emit health information to be able to make these decisions.

Rapporten status en diagnoseReports health and diagnostics

Het lijkt misschien duidelijk, en wordt vaak wordt overgeslagen, maar een microservice de status en diagnose moet rapporteren.It may seem obvious, and it is often overlooked, but a microservice must report its health and diagnostics. Anders is er weinig inzicht vanuit het perspectief van een bewerkingen.Otherwise, there is little insight from an operations perspective. Correleren van diagnostische gebeurtenissen in een set onafhankelijke services en omgaan met machine klok laat gevoel de volgorde van de gebeurtenis is lastig.Correlating diagnostic events across a set of independent services and dealing with machine clock skews to make sense of the event order is challenging. Op dezelfde manier die u met een microservice via overeengekomen protocollen en gegevensopmaak werken, ontstaat er naar standaardisering in hoe u zich aanmeldt gezondheid en diagnostische gebeurtenissen die uiteindelijk in een archief van de gebeurtenis terechtkomen voor het uitvoeren van query's en weergeven.In the same way that you interact with a microservice over agreed-upon protocols and data formats, there emerges a need for standardization in how to log health and diagnostic events that ultimately end up in an event store for querying and viewing. In een benadering microservices is deze sleutel verschillende teams overeenstemming worden bereikt over een één-indeling.In a microservices approach, it is key that different teams agree on a single logging format. Er moet een consistente benadering van diagnostische gebeurtenissen weergeven in de toepassing als geheel.There needs to be a consistent approach to viewing diagnostic events in the application as a whole.

Health wijkt af van diagnostische gegevens.Health is different from diagnostics. De status is over de microservice rapportage van de huidige status juiste acties te ondernemen.Health is about the microservice reporting its current state to take appropriate actions. Een goed voorbeeld werkt samen met upgrade- en implementatie mechanismen om beschikbaarheid te houden.A good example is working with upgrade and deployment mechanisms to maintain availability. Hoewel een service is mogelijk momenteel beschadigd vanwege het vastlopen van een proces of opnieuw opstarten van de computer, de service nog steeds mogelijk operationeel.Although a service may be currently unhealthy due to a process crash or machine reboot, the service might still be operational. Het laatste wat dat u nodig is om dit te slechter door het uitvoeren van een upgrade.The last thing you need is to make this worse by performing an upgrade. De aanbevolen aanpak is het onderzoek doen eerst of er voldoende tijd uittrekken om de microservice te herstellen.The best approach is to do an investigation first or allow time for the microservice to recover. Gebeurtenissen van de status van een microservice helpt ons gefundeerde beslissingen te nemen en van kracht te zelfherstellende services maken.Health events from a microservice help us make informed decisions and, in effect, help create self-healing services.

Service Fabric als microservices platformService Fabric as a microservices platform

Azure Service Fabric ontstaan uit een overgang door Microsoft in het vak-producten, doorgaans monolithische in stijl zijn, bij het leveren van services af te leveren.Azure Service Fabric emerged from a transition by Microsoft from delivering box products, which were typically monolithic in style, to delivering services. De ervaring van gebouw en grote services, zoals Azure SQL Database en Azure Cosmos DB besturingssysteem in de vorm van Service Fabric.The experience of building and operating large services, such as Azure SQL Database and Azure Cosmos DB, shaped Service Fabric. Het platform ontwikkeld na verloop van tijd meer services wordt aangenomen.The platform evolved over time as more and more services adopted it. Houd voor ogen dat hadden Service Fabric uitgevoerd moeten niet alleen in Azure, maar ook in implementaties met zelfstandige Windows Server.Importantly, Service Fabric had to run not only in Azure but also in standalone Windows Server deployments.

Het doel van de Service Fabric is het oplossen van problemen met vaste bouwen en uitvoeren van een service en infrastructuur bronnen efficiënt gebruiken zodat teams met behulp van een benadering microservices bedrijfsproblemen kunnen oplossen.The aim of Service Fabric is to solve the hard problems of building and running a service and utilize infrastructure resources efficiently, so that teams can solve business problems using a microservices approach.

Service Fabric bevat drie brede gebieden te maken van toepassingen die gebruikmaken van een benadering microservices:Service Fabric provides three broad areas to help you build applications that use a microservices approach:

  • Een platform waarmee systeemservices te implementeren en bijwerken, detecteren, en mislukte services opnieuw starten, services detecteren, routeren van berichten, status beheren en controleren status.A platform that provides system services to deploy, upgrade, detect, and restart failed services, discover services, route messages, manage state, and monitor health. Deze systeemservices kunnen van kracht veel van de kenmerken van microservices die eerder is beschreven.These system services in effect enable many of the characteristics of microservices previously described.
  • De mogelijkheid om toepassingen te implementeren ofwel in containers of als processen die wordt uitgevoerd.Ability to deploy applications either running in containers or as processes. Service Fabric is een container en een proces orchestrator.Service Fabric is a container and process orchestrator.
  • Productief programming API's voor hulp bij het ontwikkelen van toepassingen als microservices: ASP.NET Core, Reliable Actors en Reliable Services.Productive programming APIs, to help you build applications as microservices: ASP.NET Core, Reliable Actors, and Reliable Services. U kunt de code voor het bouwen van uw microservice.You can choose any code to build your microservice. Maar maak deze API's van de taak eenvoudiger en ze met het platform op een dieper niveau integreren.But these APIs make the job more straightforward, and they integrate with the platform at a deeper level. Op deze manier bijvoorbeeld, status en diagnose informatie kunt u vinden, of kunt u profiteren van de ingebouwde hoge beschikbaarheid.This way, for example, you can get health and diagnostics information, or you can take advantage of built-in high availability.

Service Fabric is agnostisch op hoe het bouwen van uw service en kunt u elke technologie. Dit biedt echter ingebouwde programming API's waarmee het eenvoudiger om microservices samen te stellen.Service Fabric is agnostic on how you build your service, and you can use any technology. However, it does provide built-in programming APIs that make it easier to build microservices.

Migreren van bestaande toepassingen naar Service FabricMigrating existing applications to Service Fabric

Een sleutel benadering van Service Fabric is het hergebruiken van bestaande code, die vervolgens kan worden modernized met nieuwe microservices.A key approach to Service Fabric is to reuse existing code, which can then be modernized with new microservices. Er zijn vijf fasen toepassing modernisering en u kunt starten en stoppen op een van de fasen.There are five stages to application modernization, and you can start and stop at any of the stages. Dit zijn;These are;

1) Een traditionele monolithische toepassingTake a traditional monolithic application
2) Lift- en Shift - containers of Gast uitvoerbare bestanden gebruiken voor het hosten van bestaande code in Service Fabric.Lift and Shift - Use containers or guest executables to host existing code in Service Fabric.
3) Modernisering - nieuwe microservices toegevoegd naast de bestaande beperkte code.Modernization - New microservices added alongside existing containerized code.
4) Innoveren - de monolithische opsplitsen microservices alleen is gebaseerd op nodig.Innovate - Break the monolithic into microservices purely based on need.
5) Omgezet in microservices - de transformatie van bestaande monolithische toepassingen of het ontwikkelen van nieuwe greenfield toepassingen.Transformed into microservices - the transformation of existing monolithic applications or building new greenfield applications.

Migratie naar Microservices

Het is belangrijk om te benadrukken opnieuw kunt u starten en stoppen op een van deze fasen.It is important to emphasize again that you can start and stop at any of these stages. U bent niet verplicht tot de volgende fase.You are not compelled to progress to the next stage. We gaan nu kijken voorbeelden voor elk van deze fasen.Let's now look at examples for each of these stages.

Lift- en verschuiven -grote aantallen van bedrijven zijn op te heffen en bestaande monolithische toepassingen in containers verschuiving van twee redenen;Lift and Shift - large numbers of companies are lifting and shifting existing monolithic applications into containers for two reasons;

  • Kosten vermindering ofwel vanwege consolidatie en verwijderen van bestaande hardware of met toepassingen met hogere dichtheid.Cost reduction either due to consolidation and removal of existing hardware or running applications at higher density.
  • Consistente implementatie contract tussen ontwikkel- en bewerkingen.Consistent deployment contract between development and operations.

Kosten kortingen zijn te begrijpen, en binnen Microsoft grote aantallen van bestaande toepassingen zijn wordt beperkte gewoon om op te slaan miljoenen bedragen.Cost reductions are understandable, and within Microsoft, large numbers of existing applications are being containerized simply to save millions of dollars. Consistente distributie is moeilijker te evalueren, maar als belangrijk.Consistent deployment is harder to evaluate, but equally as important. Wordt aangegeven dat ontwikkelaars nog steeds gratis worden kunnen kiezen de technologie die past bij, maar de bewerkingen slechts één methode accepteert te implementeren en beheren van deze toepassingen.It says that developers can still be free to choose the technology that suits them, however the operations will only accept a single way to deploy and manage these applications. Dit vermindert de bewerkingen van hoeven te maken met de complexiteit van veel verschillende technologieën of ontwikkelaars kunnen alleen bepaalde objecten kiezen om te dwingen.It alleviates the operations from having to deal with the complexity of many different technologies or forcing developers to only choose certain ones. In wezen elke toepassing is beperkte in zelfstandige implementatie-installatiekopieën.Essentially every application is containerized into self-contained deployment images.

Veel organisaties stoppen hier.Many organizations stop here. Al heeft, de voordelen van containers en Service Fabric bevat de volledige beheerervaring van implementatie, upgrades, versiebeheer, Rollback, health monitoring enzovoort.They already have the benefits of containers and Service Fabric provides the complete management experience from deployment, upgrades, versioning, rollbacks, health monitoring etc.

Modernisering -is de toevoeging van nieuwe services samen met de bestaande beperkte code.Modernization - is the addition of new services alongside existing containerized code. Als u nieuwe code te schrijven, is het raadzaam te besluiten te nemen kleine stappen omlaag het pad microservices.If you are going to write new code, it is best to decide to take small steps down the microservices path. Dit kan een nieuw REST-API-eindpunt, of een nieuwe bedrijfsregels worden toevoegt.This could be adding a new REST API endpoint, or new business logic. Op deze manier die u start op het traject van nieuwe microservices gebouw en praktijken ontwikkelen en implementeren.This way, you start on the journey of building new microservices and practice developing and deploying them.

Innoveren -Vergeet niet de oorspronkelijke veranderende bedrijfsbehoeften aan het begin van dit artikel, die de aanpak microservices genereren toeneemt?Innovate - remember those original changing business needs at the start of this article, that are driving the microservices approach? Dit gebeurt op mijn huidige toepassing in deze fase de beslissing wordt, en zo ja, ik wil de monoliet splitsen of vernieuwing starten.At this stage the decision is, are these happening to my current application and if so, I need to start splitting the monolith, or innovating. Hier een voorbeeld is wanneer een database een knelpunt verwerken wordt omdat deze wordt gebruikt als een werkstroom wachtrij.An example here is when a database becomes a processing bottleneck, since it is being used as a workflow queue. Als het aantal werkstroom moeten aanvragen verhogen van het werk voor schaal worden gedistribueerd.As the number of workflow requests increasing the work needs to be distributed for scale. Voor die bepaald onderdeel van de toepassing die niet schalen, of u moet dus vaker bijgewerkt, wordt dit uit te splitsen in een microservice en innoveren.So for that particular piece of the application that is not scaling, or you need to update more frequently, split this out into a microservice and innovate.

Omgezet in microservices -waar uw toepassing is het volledig samengesteld uit (of ontleed in) microservices.Transformed into microservices - this is where your application is fully composed of (or decomposed into) microservices. Hier is bereikt, kunt u het traject microservices hebt aangebracht.To reach here, you have made the microservices journey. Begin hier, maar u kunt dit doen zonder een microservices platform om u te helpen een aanzienlijke investering is.You can start here, but to do this without a microservices platform to help you is a significant investment.

Microservices zijn geschikt voor mijn toepassing?Are microservices right for my application?

Misschien.Maybe. We heeft ondergaan is veel van deze voordelen van een benadering microservice-achtige duurt mogelijk als er steeds meer teams in Microsoft begon te bouwen voor de cloud voor zakelijke redenen, gerealiseerde.What we experienced was that as more and more teams in Microsoft began to build for the cloud for business reasons, many of them realized the benefits of taking a microservice-like approach. Bing, bijvoorbeeld heeft is de ontwikkeling van microservices in zoeken naar jaar.Bing, for example, has been developing microservices in search for years. De microservices aanpak is voor andere teams nieuwe.For other teams, the microservices approach was new. Teams vastgesteld dat er vaste problemen oplossen buiten hun belangrijkste gebieden van kracht zijn.Teams found that there were hard problems to solve outside of their core areas of strength. Dit is de reden waarom de Service Fabric tractie ervaring als de technologie van keuze voor het bouwen van services.This is why Service Fabric gained traction as the technology of choice for building services.

Het doel van Service Fabric is het verminderen van de complexiteit van het bouwen van toepassingen met een benadering microservice, zodat er geen te doorlopen als veel dure redesigns.The objective of Service Fabric is to reduce the complexities of building applications with a microservice approach, so that you do not have to go through as many costly redesigns. Begin klein, indien nodig worden geschaald, afschaffen services, nieuwe toevoegen en ontwikkelen met klant gebruik van de aanpak is.Start small, scale when needed, deprecate services, add new ones, and evolve with customer usage is the approach. We ook weten dat er veel problemen nog moet worden opgelost zijn zodat microservices meer toegankelijk voor de meeste ontwikkelaars.We also know that there are many other problems yet to be solved to make microservices more approachable for most developers. Containers en het programmeermodel actor zijn voorbeelden van kleine stappen in deze richting en er zeker van te zijn dat er meer innovaties ontstaan te vergemakkelijken zijn.Containers and the actor programming model are examples of small steps in that direction, and we are sure that more innovations will emerge to make this easier.

Volgende stappenNext steps