Bewerken

Delen via

Microservicearchitectuur in Azure Service Fabric

Azure API Management
Azure Key Vault
Azure Monitor
Azure Pipelines
Azure Service Fabric

Deze referentiearchitectuur toont een microservicesarchitectuur die is geïmplementeerd in Azure Service Fabric. Hier ziet u een basisclusterconfiguratie die het startpunt kan zijn voor de meeste implementaties.

GitHub-logo Er is een referentie-implementatie van deze architectuur beschikbaar op GitHub.

Architectuur

Diagram met de Service Fabric-referentiearchitectuur.

Een Visio-bestand van deze architectuur downloaden.

Notitie

Dit artikel is gericht op het Reliable Services-programmeermodel voor Service Fabric. Het gebruik van Service Fabric voor het implementeren en beheren van containers valt buiten het bereik van dit artikel.

Workflow

De architectuur bestaat uit de volgende onderdelen. Zie het overzicht van Service Fabric-terminologie voor andere termen.

  • Service Fabric-cluster. Een cluster is een met het netwerk verbonden set virtuele machines (VM's) waarin u uw microservices implementeert en beheert.

  • Virtuele-machineschaalsets. Met virtuele-machineschaalsets kunt u een groep identieke vm's met gelijke taakverdeling en automatische schaalaanpassing maken en beheren. Deze rekenresources bieden ook de fout- en upgradedomeinen.

  • Knooppunten. De knooppunten zijn de VM's die deel uitmaken van het Service Fabric-cluster.

  • Knooppunttypen. Een knooppunttype vertegenwoordigt een virtuele-machineschaalset waarmee een verzameling knooppunten wordt geïmplementeerd. Een Service Fabric-cluster heeft ten minste één knooppunttype.

    In een cluster met meerdere knooppunttypen moet één het primaire knooppunttype worden gedeclareerd. Het primaire knooppunttype in het cluster voert de Service Fabric-systeemservices uit. Deze services bieden de platformmogelijkheden van Service Fabric. Het primaire knooppunttype fungeert ook als de seed-knooppunten, de knooppunten die de beschikbaarheid van het onderliggende cluster behouden.

    Configureer aanvullende knooppunttypen om uw services uit te voeren.

  • Services. Een service voert een zelfstandige functie uit die onafhankelijk van andere services kan worden gestart en uitgevoerd. Exemplaren van services worden geïmplementeerd op knooppunten in het cluster. Er zijn twee soorten services in Service Fabric:

    • Stateless service. Een staatloze service onderhoudt de status niet binnen de service. Als statuspersistentie vereist is, wordt de status geschreven naar en opgehaald uit een extern archief, zoals Azure Cosmos DB.
    • Stateful service. De servicestatus wordt bewaard binnen de service zelf. De meeste stateful services implementeren dit via Reliable Collections in Service Fabric.

  • Service Fabric Explorer. Service Fabric Explorer is een opensource-hulpprogramma voor het inspecteren en beheren van Service Fabric-clusters.

  • Azure Pipelines. Azure Pipelines maakt deel uit van Azure DevOps Services en voert geautomatiseerde builds, tests en implementaties uit. U kunt ook oplossingen voor continue integratie en continue levering (CI/CD) van derden gebruiken, zoals Jenkins.

  • Azure Monitor. Met Azure Monitor worden metrische gegevens en logboeken verzameld en opgeslagen, inclusief metrische platformgegevens voor de Azure-services in de oplossing en toepassingstelemetrie. Gebruik deze gegevens om de toepassing te bewaken, waarschuwingen en dashboards in te stellen en hoofdoorzaakanalyse van fouten uit te voeren. Azure Monitor kan worden geïntegreerd met Service Fabric voor het verzamelen van metrische gegevens van controllers, knooppunten en containers, samen met container- en knooppuntlogboeken.

  • Azure Key Vault. Gebruik Key Vault om toepassingsgeheimen op te slaan die door de microservices worden gebruikt, zoals verbindingsreeks s.

  • Azure API Management. In deze architectuur fungeert API Management als een API-gateway die aanvragen van clients accepteert en deze doorstuurt naar uw services.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen voor het verbeteren van de kwaliteit van een workload.

Ontwerpoverwegingen

Deze referentiearchitectuur is gericht op microservicesarchitecturen. Een microservice is een kleine, onafhankelijk versie-eenheid van code. Het kan worden gedetecteerd via mechanismen voor servicedetectie en kan communiceren met andere services via API's. Elke service staat op zichzelf en is bedoeld voor de implementatie van één bedrijfsvoorziening. Zie Domeinanalyse gebruiken om microservices te modelleren voor meer informatie over hoe u uw toepassingsdomein kunt opscomponeren in microservices.

Service Fabric biedt een infrastructuur voor het efficiënt bouwen, implementeren en upgraden van microservices. Het biedt ook opties voor automatisch schalen, het beheren van de status, het bewaken van de status en het opnieuw opstarten van services in geval van een storing.

Service Fabric volgt een toepassingsmodel waarbij een toepassing een verzameling microservices is. De toepassing wordt beschreven in een manifestbestand van de toepassing . Dit bestand definieert de typen services die de toepassing bevat, samen met aanwijzers naar de onafhankelijke servicepakketten.

Het toepassingspakket bevat meestal ook parameters die dienen als onderdrukkingen voor bepaalde instellingen die door de services worden gebruikt. Elk servicepakket heeft een manifestbestand dat de fysieke bestanden en mappen beschrijft die nodig zijn om die service uit te voeren, inclusief binaire bestanden, configuratiebestanden en alleen-lezengegevens. Services en toepassingen zijn onafhankelijk van elkaar geversied en kunnen worden bijgewerkt.

Optioneel kan het toepassingsmanifest services beschrijven die automatisch worden ingericht wanneer een exemplaar van de toepassing wordt gemaakt. Deze worden standaardservices genoemd. In dit geval beschrijft het toepassingsmanifest ook hoe deze services moeten worden gemaakt. Deze informatie omvat de naam van de service, het aantal exemplaren, het beveiligings- of isolatiebeleid en de plaatsingsbeperkingen.

Notitie

Vermijd het gebruik van standaardservices als u de levensduur van uw services wilt beheren. Standaardservices worden gemaakt wanneer de toepassing wordt gemaakt en worden uitgevoerd zolang de toepassing wordt uitgevoerd.

Zie Voor meer informatie, zodat u meer wilt weten over Service Fabric?.

Toepassings-naar-service-verpakkingsmodel

Een tenet van microservices is dat elke service onafhankelijk kan worden geïmplementeerd. Als u in Service Fabric al uw services in één toepassingspakket groeperen en één service niet kan worden geüpgraded, wordt de volledige toepassingsupgrade teruggedraaid. Met deze terugdraaiactie voorkomt u dat andere services worden geüpgraded.

Daarom raden we in een microservicesarchitectuur aan om meerdere toepassingspakketten te gebruiken. Plaats een of meer gerelateerde servicetypen in één toepassingstype. Plaats bijvoorbeeld servicetypen in hetzelfde toepassingstype als uw team verantwoordelijk is voor een set services met een van deze kenmerken:

  • Ze worden voor dezelfde duur uitgevoerd en moeten tegelijkertijd worden bijgewerkt.
  • Ze hebben dezelfde levenscyclus.
  • Ze delen resources, zoals afhankelijkheden of configuratie.

Service Fabric-programmeermodellen

Wanneer u een microservice toevoegt aan een Service Fabric-toepassing, moet u bepalen of deze status of gegevens bevat die maximaal beschikbaar en betrouwbaar moeten worden gemaakt. Zo ja, kan het gegevens extern opslaan of zijn de gegevens opgenomen als onderdeel van de service? Kies een staatloze service als u geen gegevens hoeft op te slaan of als u gegevens in externe opslag wilt opslaan. Overweeg om een stateful service te kiezen als een van deze instructies van toepassing is:

  • U wilt status of gegevens behouden als onderdeel van de service. U hebt bijvoorbeeld nodig dat de gegevens zich in het geheugen bevinden dicht bij de code.
  • U kunt een afhankelijkheid van een extern archief niet tolereren.

Als u bestaande code hebt die u wilt uitvoeren in Service Fabric, kunt u deze uitvoeren als een uitvoerbaar gastbestand: een willekeurig uitvoerbaar bestand dat als een service wordt uitgevoerd. U kunt ook het uitvoerbare bestand verpakken in een container met alle afhankelijkheden die u nodig hebt voor implementatie.

Service Fabric modelleert zowel containers als uitvoerbare gastbestanden als stateless services. Zie het overzicht van het Service Fabric-programmeermodel voor hulp bij het kiezen van een model.

U bent verantwoordelijk voor het onderhouden van de omgeving waarin een uitvoerbaar gastbestand wordt uitgevoerd. Stel dat voor een uitvoerbaar gastbestand Python is vereist. Als het uitvoerbare bestand niet zelfstandig is, moet u ervoor zorgen dat de vereiste versie van Python vooraf is geïnstalleerd in de omgeving. Service Fabric beheert de omgeving niet. Azure biedt meerdere mechanismen voor het instellen van de omgeving, waaronder aangepaste installatiekopieën en extensies van virtuele machines.

Als u toegang wilt krijgen tot een uitvoerbaar gastbestand via een omgekeerde proxy, moet u ervoor zorgen dat u het UriScheme kenmerk hebt toegevoegd aan het element in het Endpoint servicemanifest van het uitvoerbare gastbestand.

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" UriScheme="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

Als de service extra routes heeft, geeft u de routes in de PathSuffix waarde op. De waarde mag niet worden voorafgegaan door een slash (/). Een andere manier is om de route toe te voegen aan de servicenaam.

    <Endpoints>
      <Endpoint Name="MyGuestExeTypeEndpoint" Port="8090" Protocol="http" PathSuffix="api" Type="Input"/>
    </Endpoints>

Zie voor meer informatie:

API-gateway

Een API-gateway (inkomend verkeer) bevindt zich tussen externe clients en de microservices. Het fungeert als een omgekeerde proxy, routeringsaanvragen van clients naar microservices. Het kan ook kruislingse taken uitvoeren, zoals verificatie, SSL-beëindiging en snelheidsbeperking.

We raden Azure API Management aan voor de meeste scenario's, maar Traefik is een populair opensource-alternatief. Beide technologieopties zijn geïntegreerd met Service Fabric.

  • API Management. Toont een openbaar IP-adres en routeert verkeer naar uw services. Het wordt uitgevoerd in een toegewezen subnet in hetzelfde virtuele netwerk als het Service Fabric-cluster.

    API Management heeft toegang tot services in een knooppunttype dat beschikbaar wordt gesteld via een load balancer met een privé-IP-adres. Deze optie is alleen beschikbaar in de Premium- en Developer-lagen van API Management. Gebruik de Premium-laag voor productieworkloads. Prijsinformatie wordt beschreven in API Management-prijzen.

    Zie het overzicht van Service Fabric met Azure API Management voor meer informatie.

  • Traefik. Ondersteunt functies zoals routering, tracering, logboeken en metrische gegevens. Traefik wordt uitgevoerd als een stateless service in het Service Fabric-cluster. Serviceversiebeheer kan worden ondersteund via routering.

    Zie Azure Service Fabric Provider op de Traefik-website voor informatie over het instellen van Traefik voor inkomend verkeer en als de omgekeerde proxy in het cluster. Zie het blogbericht Intelligente routering op Service Fabric met Traefik voor meer informatie over het gebruik van Traefik met Service Fabric.

Traefik heeft, in tegenstelling tot Azure API Management, geen functionaliteit om de partitie van een stateful service (met meer dan één partitie) op te lossen waarnaar een aanvraag wordt gerouteerd. Zie Een matcher toevoegen voor partitioneringsservices voor meer informatie.

Andere OPTIES voor API-beheer zijn Azure-toepassing Gateway en Azure Front Door. U kunt deze services gebruiken in combinatie met API Management om taken uit te voeren, zoals routering, SSL-beëindiging en firewall.

Communicatie tussen services

Houd rekening met de volgende aanbevelingen om service-naar-servicecommunicatie te vergemakkelijken:

  • Communicatieprotocol. In een microservicesarchitectuur moeten services met elkaar communiceren met minimale koppeling tijdens runtime. Om taalagnostische communicatie mogelijk te maken, is HTTP een industriestandaard met een breed scala aan hulpprogramma's en HTTP-servers die beschikbaar zijn in verschillende talen. Service Fabric ondersteunt al deze hulpprogramma's en servers.

    Voor de meeste workloads raden we u aan HTTP te gebruiken in plaats van de externe service die is ingebouwd in Service Fabric.

  • Servicedetectie. Als u wilt communiceren met andere services binnen een cluster, moet een clientservice de huidige locatie van de doelservice oplossen. In Service Fabric kunnen services tussen knooppunten schakelen en ervoor zorgen dat de service-eindpunten dynamisch worden gewijzigd.

    Als u verbindingen met verouderde eindpunten wilt voorkomen, kunt u de naamgevingsservice in Service Fabric gebruiken om bijgewerkte eindpuntgegevens op te halen. Service Fabric biedt echter ook een ingebouwde omgekeerde proxyservice waarmee de naamgevingsservice wordt geabstraheerd. We raden deze optie aan voor servicedetectie als basislijn voor de meeste scenario's, omdat het eenvoudiger te gebruiken is en resulteert in eenvoudigere code.

Andere opties voor communicatie tussen services zijn:

  • Traefik voor geavanceerde routering.
  • DNS voor compatibiliteitsscenario's waarin een service verwacht DNS te gebruiken.
  • De klasse ServicePartitionClient<TCommunicationClient> , waarin service-eindpunten worden opgeslagen. Het kan betere prestaties mogelijk maken, omdat oproepen rechtstreeks tussen services zonder tussenpersonen of aangepaste protocollen gaan.

Schaalbaarheid

Service Fabric ondersteunt het schalen van deze clusterentiteiten:

  • Het aantal knooppunten voor elk knooppunttype schalen
  • Services schalen

Deze sectie is gericht op automatisch schalen. U kunt ervoor kiezen om handmatig te schalen in situaties waarin dit geschikt is. Handmatige interventie kan bijvoorbeeld vereist zijn om het aantal exemplaren in te stellen.

Initiële clusterconfiguratie voor schaalbaarheid

Wanneer u een Service Fabric-cluster maakt, richt u de knooppunttypen in op basis van uw beveiligings- en schaalbaarheidsbehoeften. Elk knooppunttype wordt toegewezen aan een virtuele-machineschaalset en kan onafhankelijk worden geschaald.

  • Maak een knooppunttype voor elke groep services met verschillende schaalbaarheids- of resourcevereisten. Begin met het inrichten van een knooppunttype (dat het primaire knooppunttype wordt) voor de Service Fabric-systeemservices. Maak afzonderlijke knooppunttypen om uw openbare of front-endservices uit te voeren. Maak indien nodig andere knooppunttypen voor uw back-end en privé- of geïsoleerde services. Geef plaatsingsbeperkingen op, zodat de services alleen worden geïmplementeerd op de beoogde knooppunttypen.
  • Geef de duurzaamheidslaag voor elk knooppunttype op. De duurzaamheidslaag vertegenwoordigt de mogelijkheid van Service Fabric om updates en onderhoudsbewerkingen in virtuele-machineschaalsets te beïnvloeden. Kies voor productieworkloads een Silver- of hogere duurzaamheidslaag. Zie Duurzaamheidskenmerken van het cluster voor meer informatie over elke laag.
  • Als u de duurzaamheidslaag Brons gebruikt, zijn voor bepaalde bewerkingen handmatige stappen vereist. Voor knooppunttypen met de bronzen duurzaamheidslaag zijn extra stappen vereist tijdens het inschalen. Zie deze handleiding voor meer informatie over schaalbewerkingen.

Knooppunten schalen

Service Fabric biedt ondersteuning voor automatisch schalen voor in- en uitschalen. U kunt elk knooppunttype afzonderlijk configureren voor automatisch schalen.

Elk knooppunttype kan maximaal 100 knooppunten bevatten. Begin met een kleinere set knooppunten en voeg meer knooppunten toe, afhankelijk van uw belasting. Als u meer dan 100 knooppunten in een knooppunttype nodig hebt, moet u meer knooppunttypen toevoegen. Zie Overwegingen voor capaciteitsplanning voor Service Fabric-clusters voor meer informatie. Een virtuele-machineschaalset schaalt niet onmiddellijk, dus houd rekening met deze factor wanneer u regels voor automatisch schalen instelt.

Als u automatische inschalen wilt ondersteunen, configureert u het knooppunttype voor de duurzaamheidslaag Silver of Gold. Deze configuratie zorgt ervoor dat inschalen is vertraagd totdat Service Fabric klaar is met het verplaatsen van services. Het zorgt er ook voor dat de virtuele-machineschaalsets Service Fabric informeren dat de VM's worden verwijderd, niet alleen tijdelijk omlaag.

Zie Azure Service Fabric-clusters schalen voor meer informatie over schalen op knooppunt- of clusterniveau.

Services schalen

Staatloze en stateful services passen verschillende benaderingen toe om te schalen.

Voor een stateless service (automatisch schalen):

  • Gebruik de gemiddelde trigger voor het laden van partities. Deze trigger bepaalt wanneer de service wordt ingeschaald of uitgeschaald, op basis van een drempelwaarde voor belasting die is opgegeven in het schaalbeleid. U kunt ook instellen hoe vaak de trigger wordt gecontroleerd. Zie De trigger gemiddelde partitiebelasting met schaalaanpassing op basis van een exemplaar. Met deze aanpak kunt u omhoog schalen naar het aantal beschikbare knooppunten.
  • Ingesteld InstanceCount op -1 in het servicemanifest, waarmee Service Fabric een exemplaar van de service op elk knooppunt moet uitvoeren. Met deze benadering kan de service dynamisch worden geschaald naarmate het cluster wordt geschaald. Naarmate het aantal knooppunten in het cluster verandert, worden service-exemplaren automatisch door Service Fabric gemaakt en verwijderd.

Notitie

In sommige gevallen wilt u uw service mogelijk handmatig schalen. Als u bijvoorbeeld een service hebt die wordt gelezen uit Azure Event Hubs, wilt u mogelijk een toegewezen exemplaar lezen uit elke Event Hub-partitie. Op die manier kunt u gelijktijdige toegang tot de partitie voorkomen.

Voor een stateful service wordt schalen bepaald door het aantal partities, de grootte van elke partitie en het aantal partities of replica's dat op een computer wordt uitgevoerd:

  • Als u gepartitioneerde services maakt, moet u ervoor zorgen dat elk knooppunt voldoende replica's krijgt voor zelfs de distributie van de workload zonder dat er resourceconflicten ontstaan. Als u meer knooppunten toevoegt, distribueert Service Fabric de workloads standaard naar de nieuwe machines. Als er bijvoorbeeld vijf knooppunten en 10 partities zijn, plaatst Service Fabric standaard twee primaire replica's op elk knooppunt. Als u de knooppunten uitschaalt, kunt u betere prestaties bereiken omdat het werk gelijkmatig over meer resources wordt verdeeld.

    Zie Schalen in Service Fabric voor informatie over scenario's die gebruikmaken van deze strategie.

  • Het toevoegen of verwijderen van partities wordt niet goed ondersteund. Een andere optie die vaak wordt gebruikt om te schalen, is het dynamisch maken of verwijderen van services of hele toepassingsexemplaren. Een voorbeeld van dat patroon wordt beschreven in Schalen door nieuwe benoemde services te maken of te verwijderen.

Zie voor meer informatie:

Metrische gegevens gebruiken om de belasting te verdelen

Afhankelijk van hoe u de partitie ontwerpt, hebt u mogelijk knooppunten met replica's die meer verkeer krijgen dan andere. Om deze situatie te voorkomen, moet u de servicestatus partitioneren zodat deze over alle partities wordt verdeeld. Gebruik het bereikpartitioneringsschema met een goed hash-algoritme. Zie Aan de slag met partitioneren.

Service Fabric maakt gebruik van metrische gegevens om te weten hoe u services binnen een cluster kunt plaatsen en verdelen. U kunt een standaardbelasting opgeven voor elke metrische waarde die is gekoppeld aan een service wanneer die service wordt gemaakt. Service Fabric houdt vervolgens rekening met die belasting bij het plaatsen van de service, of wanneer de service moet worden verplaatst (bijvoorbeeld tijdens upgrades), om de knooppunten in het cluster te verdelen.

De in eerste instantie opgegeven standaardbelasting voor een service wordt niet gewijzigd gedurende de levensduur van de service. Als u het wijzigen van metrische gegevens voor een service wilt vastleggen, raden we u aan uw service te bewaken en vervolgens de belasting dynamisch te rapporteren. Met deze aanpak kan Service Fabric de toewijzing aanpassen op basis van de gerapporteerde belasting op een bepaald moment. Gebruik de methode IServicePartition.ReportLoad om aangepaste metrische gegevens te rapporteren. Zie Dynamische belasting voor meer informatie.

Beschikbaarheid

Plaats uw services in een ander knooppunttype dan het primaire knooppunttype. De Service Fabric-systeemservices worden altijd geïmplementeerd op het primaire knooppunttype. Als uw services worden geïmplementeerd op het primaire knooppunttype, kunnen ze concurreren met systeemservices (en verstoren) voor resources. Als een knooppunttype stateful services host, moet u ervoor zorgen dat er ten minste vijf knooppuntexemplaren zijn en dat u de duurzaamheidslaag Silver of Gold selecteert.

Overweeg de resources van uw services te beperken. Zie het mechanisme voor resourcebeheer.

Hier volgen veelvoorkomende overwegingen:

  • Combineer geen services die worden beheerd door resources en services die niet op hetzelfde knooppunttype worden beheerd. De niet-beheerde services verbruiken mogelijk te veel resources en zijn van invloed op de beheerde services. Geef plaatsingsbeperkingen op om ervoor te zorgen dat deze typen services niet worden uitgevoerd op dezelfde set knooppunten. (Dit is een voorbeeld van de Schotpatroon.)
  • Geef de CPU-kernen en het geheugen op die moeten worden gereserveerd voor een service-exemplaar. Zie Resourcebeheer voor informatie over het gebruik en de beperkingen van het resourcebeheerbeleid.

Als u een SINGLE Point of Failure (SPOF) wilt voorkomen, moet u ervoor zorgen dat het doelexemplaren of het aantal replica's van elke service groter is dan één. Het grootste getal dat u als service-exemplaar of replicaaantal kunt gebruiken, is gelijk aan het aantal knooppunten dat de service beperkt.

Zorg ervoor dat elke stateful service ten minste twee actieve secundaire replica's heeft. We raden vijf replica's aan voor productieworkloads.

Zie Beschikbaarheid van Service Fabric-services voor meer informatie.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.

Hier volgen enkele belangrijke punten voor het beveiligen van uw toepassing in Service Fabric.

Virtueel netwerk

Overweeg subnetgrenzen te definiëren voor elke virtuele-machineschaalset om de communicatiestroom te beheren. Elk knooppunttype heeft een eigen virtuele-machineschaalset in een subnet in het virtuele netwerk van het Service Fabric-cluster. U kunt netwerkbeveiligingsgroepen (NSG's) toevoegen aan de subnetten om netwerkverkeer toe te staan of te weigeren. Met front-end- en back-endknooppunttypen kunt u bijvoorbeeld een NSG toevoegen aan het back-endsubnet om alleen inkomend verkeer van het front-endsubnet te accepteren.

Wanneer u externe Azure-services vanuit het cluster aanroept, gebruikt u service-eindpunten voor virtuele netwerken als de Azure-service dit ondersteunt. Het gebruik van een service-eindpunt beveiligt de service alleen naar het virtuele netwerk van het cluster.

Als u bijvoorbeeld Azure Cosmos DB gebruikt om gegevens op te slaan, configureert u het Azure Cosmos DB-account met een service-eindpunt om alleen toegang vanuit een specifiek subnet toe te staan. Zie Toegang tot Azure Cosmos DB-resources vanuit virtuele netwerken.

Eindpunten en communicatie tussen services

Maak geen onbeveiligd Service Fabric-cluster. Als het cluster beheereindpunten beschikbaar maakt voor het openbare internet, kunnen anonieme gebruikers er verbinding mee maken. Niet-beveiligde clusters worden niet ondersteund voor productieworkloads. Bekijk beveiligingsscenario's voor Service Fabric-clusters.

Uw communicatie tussen services beveiligen:

  • Overweeg HTTPS-eindpunten in te schakelen in uw ASP.NET Core- of Java-webservices.
  • Maak een beveiligde verbinding tussen de omgekeerde proxy en services. Zie Verbinding maken met een beveiligde service voor meer informatie.

Als u een API-gateway gebruikt, kunt u verificatie naar de gateway offloaden. Zorg ervoor dat de afzonderlijke services niet rechtstreeks kunnen worden bereikt (zonder de API-gateway), tenzij er extra beveiliging is om berichten te verifiëren.

Maak de omgekeerde Service Fabric-proxy niet openbaar beschikbaar. Dit zorgt ervoor dat alle services die HTTP-eindpunten beschikbaar maken, adresseerbaar zijn van buiten het cluster. Hierdoor worden beveiligingsproblemen geïntroduceerd en worden mogelijk extra informatie buiten het cluster onnodig beschikbaar gesteld. Als u openbaar toegang wilt krijgen tot een service, gebruikt u een API-gateway. In de sectie API-gateway verderop in dit artikel worden enkele opties vermeld.

Extern bureaublad is handig voor diagnostische gegevens en probleemoplossing, maar zorg ervoor dat u het sluit. Als u het open laat, ontstaat er een beveiligingsgat.

Geheimen en certificaten

Sla geheimen, zoals verbindingsreeks s naar gegevensarchieven, op in een sleutelkluis. De sleutelkluis moet zich in dezelfde regio bevinden als de virtuele-machineschaalset. Een sleutelkluis gebruiken:

  1. Verifieer de toegang van de service tot de sleutelkluis.

    Schakel beheerde identiteit in op de virtuele-machineschaalset die als host fungeert voor de service.

  2. Sla uw geheimen op in de sleutelkluis.

    Voeg geheimen toe in een indeling die kan worden vertaald naar een sleutel/waardepaar. Gebruik bijvoorbeeld CosmosDB--AuthKey. Wanneer de configuratie is gebouwd, wordt het dubbele afbreekstreepje (--) geconverteerd naar een dubbele punt (:).

  3. Toegang tot deze geheimen in uw service.

    Voeg de sleutelkluis-URI toe aan uw appSettings.json-bestand . Voeg in uw service de configuratieprovider toe die uit de sleutelkluis leest, de configuratie bouwt en het geheim opent vanuit de ingebouwde configuratie.

Hier volgt een voorbeeld waarin de werkstroomservice een geheim opslaat in de sleutelkluis in de indeling CosmosDB--Database.

namespace Fabrikam.Workflow.Service
{
    public class ServiceStartup
    {
        public static void ConfigureServices(StatelessServiceContext context, IServiceCollection services)
        {
            var preConfig = new ConfigurationBuilder()
                …
                .AddJsonFile(context, "appsettings.json");

            var config = preConfig.Build();

            if (config["AzureKeyVault:KeyVaultUri"] is var keyVaultUri && !string.IsNullOrWhiteSpace(keyVaultUri))
            {
                preConfig.AddAzureKeyVault(keyVaultUri);
                config = preConfig.Build();
            }
    }
}

Als u toegang wilt krijgen tot het geheim, geeft u de geheime naam op in de ingebouwde configuratie.

       if(builtConfig["CosmosDB:Database"] is var database && !string.IsNullOrEmpty(database))
       {
            // Use the secret.
       }

Gebruik geen clientcertificaten voor toegang tot Service Fabric Explorer. Gebruik in plaats daarvan Microsoft Entra-id. Zie Azure-services die ondersteuning bieden voor Microsoft Entra-verificatie.

Gebruik geen zelfondertekende certificaten voor productie.

Beveiliging van data-at-rest

Als u gegevensschijven hebt gekoppeld aan de virtuele-machineschaalsets van het Service Fabric-cluster en uw services gegevens op die schijven opslaan, moet u de schijven versleutelen. Zie Besturingssysteem en gekoppelde gegevensschijven versleutelen in een virtuele-machineschaalset met Azure PowerShell (preview) voor meer informatie.

Zie voor meer informatie over het beveiligen van Service Fabric:

Tolerantie

Als u fouten wilt herstellen en een volledig functionerende status wilt behouden, moet de toepassing bepaalde tolerantiepatronen implementeren. Hier volgen enkele veelvoorkomende patronen:

  • Opnieuw proberen: als u fouten wilt afhandelen die u verwacht tijdelijk te gebruiken, zoals resources die tijdelijk niet beschikbaar zijn.
  • Circuitonderbreker: om fouten op te lossen die langer kunnen duren om het probleem op te lossen.
  • Schot: Resources isoleren voor elke service.

Deze referentie-implementatie maakt gebruik van Polly, een opensource-optie, om al deze patronen te implementeren.

Controleren

Voordat u de bewakingsopties verkent, raden we u aan dit artikel te lezen over het diagnosticeren van veelvoorkomende scenario's met Service Fabric. U kunt gegevens in deze sets controleren:

Dit zijn de twee belangrijkste opties voor het analyseren van die gegevens:

  • Analyses van toepassingen
  • Log Analytics

U kunt Azure Monitor gebruiken om dashboards in te stellen voor bewaking en om waarschuwingen naar operators te verzenden. Sommige bewakingshulpprogramma's van derden zijn ook geïntegreerd met Service Fabric, zoals Dynatrace. Zie Azure Service Fabric-bewakingspartners voor meer informatie.

Metrische gegevens en logboeken van toepassingen

Toepassingstelemetrie biedt gegevens waarmee u de status van uw service kunt bewaken en problemen kunt identificeren. Traceringen en gebeurtenissen toevoegen in uw service:

Application Insights biedt veel ingebouwde telemetrie: aanvragen, traceringen, gebeurtenissen, uitzonderingen, metrische gegevens, afhankelijkheden. Als uw service HTTP-eindpunten beschikbaar maakt, schakelt u Application Insights in door de UseApplicationInsights extensiemethode aan te roepen voor Microsoft.AspNetCore.Hosting.IWebHostBuilder. Zie de volgende artikelen voor informatie over het instrumenteren van uw service voor Application Insights:

Als u de traceringen en gebeurtenislogboeken wilt weergeven, gebruikt u Application Insights als een van de sinks voor gestructureerde logboekregistratie. Configureer Application Insights met uw instrumentatiesleutel door de AddApplicationInsights extensiemethode aan te roepen. In dit voorbeeld wordt de instrumentatiesleutel opgeslagen als een geheim in de sleutelkluis.

    .ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddApplicationInsights(hostingContext.Configuration ["ApplicationInsights:InstrumentationKey"]);
        })

Als uw service geen HTTP-eindpunten beschikbaar maakt, moet u een aangepaste extensie schrijven waarmee traceringen naar Application Insights worden verzonden. Zie de werkstroomservice in de referentie-implementatie voor een voorbeeld.

ASP.NET Core-services maken gebruik van de ILogger-interface voor toepassingslogboekregistratie. Als u deze toepassingslogboeken beschikbaar wilt maken in Azure Monitor, verzendt u de ILogger gebeurtenissen naar Application Insights. Application Insights kan correlatie-eigenschappen toevoegen aan ILogger gebeurtenissen, wat handig is voor het visualiseren van gedistribueerde tracering.

Zie voor meer informatie:

Service Fabric-status- en gebeurtenisgegevens

Service Fabric-telemetrie bevat metrische statusgegevens en gebeurtenissen over de werking en prestaties van een Service Fabric-cluster en de bijbehorende entiteiten: de knooppunten, toepassingen, services, partities en replica's. Status- en gebeurtenisgegevens kunnen afkomstig zijn van:

  • EventStore. Deze stateful systeemservice verzamelt gebeurtenissen met betrekking tot het cluster en de bijbehorende entiteiten. Service Fabric gebruikt EventStore om Service Fabric-gebeurtenissen te schrijven om informatie over uw cluster te bieden voor statusupdates, probleemoplossing en bewaking. EventStore kan ook gebeurtenissen van verschillende entiteiten op een bepaald moment correleren om problemen in het cluster te identificeren. De service maakt deze gebeurtenissen beschikbaar via een REST API.

    Zie Query EventStore-API's voor clusterevenementen voor informatie over het uitvoeren van query's op de EventStore-API's. U kunt de gebeurtenissen uit EventStore in Log Analytics bekijken door uw cluster te configureren met de Azure Diagnostics-extensie voor Windows (WAD).

  • HealthStore. Deze stateful service biedt een momentopname van de huidige status van het cluster. Hiermee worden alle statusgegevens geaggregeerd die door entiteiten in een hiërarchie worden gerapporteerd. De gegevens worden gevisualiseerd in Service Fabric Explorer. HealthStore bewaakt ook toepassingsupgrades. U kunt statusquery's gebruiken in PowerShell, een .NET-toepassing of REST API's. Zie Inleiding tot Service Fabric-statuscontrole.

  • Aangepaste statusrapporten. Overweeg om interne watchdog-services te implementeren die periodiek aangepaste statusgegevens kunnen rapporteren, zoals foutieve statussen van actieve services. U kunt de statusrapporten lezen in Service Fabric Explorer.

Metrische gegevens en logboeken van infrastructuur

Metrische infrastructuurgegevens helpen u inzicht te hebben in resourcetoewijzing in het cluster. Hier volgen de belangrijkste opties voor het verzamelen van deze informatie:

  • WAD. Verzamel logboeken en metrische gegevens op knooppuntniveau in Windows. U kunt WAD gebruiken door de IaaSDiagnostics VM-extensie te configureren op elke virtuele-machineschaalset die is toegewezen aan een knooppunttype om diagnostische gebeurtenissen te verzamelen. Deze gebeurtenissen kunnen bestaan uit Windows-gebeurtenislogboeken, prestatiemeteritems, ETW/manifestsysteem en operationele gebeurtenissen en aangepaste logboeken.
  • Log Analytics-agent. Configureer de VM-extensie MicrosoftMonitoringAgent voor het verzenden van Windows-gebeurtenislogboeken, prestatiemeteritems en aangepaste logboeken naar Log Analytics.

Er zijn enkele overlappingen in de typen metrische gegevens die worden verzameld via de voorgaande mechanismen, zoals prestatiemeteritems. Als er overlap is, raden we u aan om de Log Analytics-agent te gebruiken. Omdat de Log Analytics-agent geen gebruik maakt van Azure Storage, is de latentie laag. Bovendien kunnen de prestatiemeteritems in IaaSDiagnostics niet eenvoudig worden ingevoerd in Log Analytics.

Diagram met infrastructuurbewaking in Service Fabric.

Zie extensies en functies van virtuele Azure-machines voor meer informatie over het gebruik van VM-extensies.

Als u de gegevens wilt weergeven, configureert u Log Analytics om de gegevens weer te geven die zijn verzameld via WAD. Zie Log Analytics instellen voor een cluster voor informatie over het configureren van Log Analytics voor het lezen van gebeurtenissen uit een opslagaccount.

U kunt ook prestatielogboeken en telemetriegegevens weergeven die betrekking hebben op een Service Fabric-cluster, workloads, netwerkverkeer, wachtende updates en meer. Zie Prestatiebewaking met Log Analytics.

De oplossing Servicetoewijzing in Log Analytics bevat informatie over de topologie van het cluster (dat wil gezegd de processen die in elk knooppunt worden uitgevoerd). Verzend de gegevens in het opslagaccount naar Application Insights. Er kan enige vertraging optreden bij het ophalen van gegevens in Application Insights. Als u de gegevens in realtime wilt zien, kunt u Overwegen Event Hubs te configureren met behulp van sinks en kanalen. Zie Gebeurtenisaggregatie en verzameling met behulp van WAD voor meer informatie.

Metrische gegevens van afhankelijke services

  • Toepassingsoverzicht in Application Insights biedt de topologie van de toepassing met behulp van HTTP-afhankelijkheidsaanroepen tussen services, met de geïnstalleerde Application Insights-SDK.
  • Serviceoverzicht in Log Analytics biedt informatie over inkomend en uitgaand verkeer van en naar externe services. Serviceoverzicht kan worden geïntegreerd met andere oplossingen, zoals updates of beveiliging.
  • Aangepaste watchdogs kunnen foutvoorwaarden voor externe services rapporteren. De service kan bijvoorbeeld een foutstatusrapport opgeven als deze geen toegang heeft tot een externe service of gegevensopslag (Azure Cosmos DB).

Gedistribueerde tracering

In een microservicesarchitectuur nemen verschillende services vaak deel aan het voltooien van een taak. De telemetrie van elk van deze services wordt gecorreleerd via contextvelden (zoals bewerkings-id en aanvraag-id) in een gedistribueerde trace.

Met behulp van toepassingsoverzicht in Application Insights kunt u de weergave van gedistribueerde logische bewerkingen bouwen en de volledige servicegrafiek van uw toepassing visualiseren. U kunt ook transactiediagnose in Application Insights gebruiken om telemetrie aan serverzijde te correleren. Zie Unified Cross-Component Transaction Diagnostics voor meer informatie.

Het is ook belangrijk om taken die asynchroon worden verzonden, te correleren met behulp van een wachtrij. Zie Wachtrij-instrumentatie voor meer informatie over het verzenden van correlatietelemetrie in een wachtrijbericht.

Zie voor meer informatie:

Waarschuwingen en dashboards

Application Insights en Log Analytics ondersteunen een uitgebreide querytaal (Kusto-querytaal) waarmee u logboekgegevens kunt ophalen en analyseren. Gebruik de query's om gegevenssets te maken en deze te visualiseren in diagnostische dashboards.

Gebruik Azure Monitor-waarschuwingen om systeembeheerders op de hoogte te stellen wanneer bepaalde voorwaarden optreden in specifieke resources. De melding kan bijvoorbeeld een e-mail, een Azure-functie of een webhook zijn. Zie Waarschuwingen in Azure Monitor voor meer informatie.

Met waarschuwingsregels voor zoeken in logboeken kunt u met regelmatige tussenpozen een Kusto-query definiëren en uitvoeren op een Log Analytics-werkruimte. Er wordt een waarschuwing gemaakt als het queryresultaat overeenkomt met een bepaalde voorwaarde.

Kostenoptimalisatie

Gebruik de Azure-prijscalculator om een schatting van de kosten te maken. Andere overwegingen worden beschreven in de pijler kostenoptimalisatie van het Microsoft Azure Well-Architected Framework.

Hier volgen enkele punten om rekening mee te houden voor sommige van de services die in deze architectuur worden gebruikt.

Azure Service Fabric

Er worden kosten in rekening gebracht voor de rekeninstanties, opslag, netwerkresources en IP-adressen die u kiest bij het maken van een Service Fabric-cluster. Er zijn implementatiekosten voor Service Fabric.

Virtuele-machineschaalsets

In deze architectuur worden microservices geïmplementeerd in knooppunten die virtuele-machineschaalsets zijn. Er worden kosten in rekening gebracht voor de Azure-VM's die worden geïmplementeerd als onderdeel van het cluster en onderliggende infrastructuurresources, zoals opslag en netwerken. Er zijn geen incrementele kosten voor de virtuele-machineschaalsets zelf.

Azure API Management

Azure API Management is een gateway om de aanvragen van clients naar uw services in het cluster te routeren.

Er zijn verschillende prijsopties. De optie Verbruik wordt in rekening gebracht op basis van betalen per gebruik en bevat een gatewayonderdeel. Kies op basis van uw workload een optie die wordt beschreven in prijzen voor API Management.

Analyses van toepassingen

U kunt Application Insights gebruiken om telemetrie te verzamelen voor alle services en om de traceringen en gebeurtenislogboeken op een gestructureerde manier weer te geven. De prijzen voor Application Insights zijn een model voor betalen per gebruik dat is gebaseerd op opgenomen gegevensvolume en opties voor gegevensretentie. Zie Gebruik en kosten voor Application Insights beheren voor meer informatie.

Azure Monitor

Voor Azure Monitor Log Analytics worden kosten in rekening gebracht voor gegevensopname en -retentie. Zie prijzen voor Azure Monitor voor meer informatie.

Azure Key Vault

U gebruikt Azure Key Vault om de instrumentatiesleutel voor Application Insights als geheim op te slaan. Azure biedt Key Vault in twee servicelagen. Als u geen met HSM beveiligde sleutels nodig hebt, kiest u de Standard-laag. Zie De prijzen van Key Vault voor informatie over de functies in elke laag.

Azure DevOps Services

Deze referentiearchitectuur maakt gebruik van Azure Pipelines voor implementatie. De Azure Pipelines-service biedt een gratis door Microsoft gehoste taak met 1800 minuten per maand voor CI/CD en één zelf-hostende taak met onbeperkte minuten per maand. Extra taken hebben kosten. Zie prijzen voor Azure DevOps Services voor meer informatie.

Zie CI/CD voor microservices voor overwegingen in een microservicesarchitectuur.

Zie deze zelfstudie voor meer informatie over het implementeren van een containertoepassing met CI/CD in een Service Fabric-cluster.

Dit scenario implementeren

Volg de stappen in de GitHub-opslagplaats om de referentie-implementatie voor deze architectuur te implementeren.

Volgende stappen