Üzembe helyezési bélyegzőkDeployment stamps

Az üzembe helyezési bélyegző minta az alkalmazás-összetevők, például az adattárak több független példányának telepítését jelenti.The deployment stamp pattern involves deploying multiple independent copies of application components, including data stores. Minden egyes másolatot bélyegzőnek vagy időnként szolgáltatási egységnek vagy méretezési egységnek nevezzük.Each individual copy is called a stamp, or sometimes a service unit or scale unit. Ez a módszer javíthatja a megoldás méretezhetőségét, lehetővé teszi a példányok üzembe helyezését több régióban, és elkülöníti az ügyféladatokat.This approach can improve the scalability of your solution, allow you to deploy instances across multiple regions, and separate your customer data.

Egy alkalmazás felhőben történő üzemeltetése során bizonyos szempontokat kell figyelembe venni.When hosting an application in the cloud there are certain considerations to be made. Az egyik legfontosabb szempont az alkalmazás teljesítménye és megbízhatósága.One key thing to keep in mind is the performance and reliability of your application. Ha a megoldás egyetlen példányát futtatja, akkor a következő korlátozások vonatkoznak rá:If you host a single instance of your solution, you might be subject to the following limitations:

  • Skálázási korlátok.Scale limits. Az alkalmazás egyetlen példányának üzembe helyezése természetes skálázási korlátokat eredményezhet.Deploying a single instance of your application may result in natural scaling limits. Használhat például olyan szolgáltatásokat, amelyek korlátozzák a bejövő kapcsolatok, az állomásnevek, a TCP-szoftvercsatornák vagy más erőforrások számát.For example, you may use services that have limits on the number of inbound connections, host names, TCP sockets, or other resources.
  • Nem lineáris skálázás vagy díj.Non-linear scaling or cost. Előfordulhat, hogy a megoldás egyes összetevői nem méretezhetők lineárisan a kérelmek számával vagy az adatmennyiséggel.Some of your solution's components may not scale linearly with the number of requests or the amount of data. Ehelyett hirtelen csökkenhet a teljesítmény, vagy megnövelhető a költséghatékonyság, ha teljesülnek a küszöbértékek.Instead, there can be a sudden decrease in performance or increase in cost once a threshold has been met. Előfordulhat például, hogy egy adatbázist használ, és azt észleli, hogy a nagyobb kapacitás hozzáadásának marginális díja (felskálázás) megtiltható, és a horizontális felskálázás költséghatékonyabb stratégia.For example, you may use a database and discover that the marginal cost of adding more capacity (scaling up) becomes prohibitive, and that scaling out is a more cost-effective strategy. Hasonlóképpen, az Azure bejárati ajtónál nagyobb a tartományon belüli díjszabás, ha nagy számú egyéni tartomány van üzembe helyezve, és jobb, ha az egyéni tartományokat több ajtós példányon is át lehetne osztani.Similarly, Azure Front Door has higher per-domain pricing when a high number of custom domains are deployed, and it may be better to spread the custom domains across multiple Front Door instances.
  • Ügyfelek elkülönítése.Separation of customers. Előfordulhat, hogy bizonyos ügyfelek adatait el kell különíteni a többi ügyfél adatainak.You may need to keep certain customers' data isolated from other customers' data. Hasonlóképpen előfordulhat, hogy egyes ügyfeleknél több rendszererőforrást kell kiszolgálni, mint a többinél, és érdemes megfontolnia a különböző infrastruktúra-készletek csoportosítását.Similarly, you may have some customers that require more system resources to service than others, and consider grouping them on different sets of infrastructure.
  • Egy-és több-bérlős példányok kezelésére.Handling single- and multi-tenant instances. Lehet, hogy vannak olyan nagy ügyfelek, akiknek szükségük van a megoldás saját független példányaira.You may have some large customers who need their own independent instances of your solution. Előfordulhat, hogy a több-bérlős telepítést megosztó kisebb ügyfelek készletét is használhatja.You may also have a pool of smaller customers who can share a multi-tenant deployment.
  • Összetett üzembe helyezési követelmények.Complex deployment requirements. Előfordulhat, hogy a frissítéseket felügyelt módon kell telepítenie a szolgáltatásba, és különböző időpontokban üzembe kell helyeznie az ügyfélkör különböző részhalmazait.You may need to deploy updates to your service in a controlled manner, and to deploy to different subsets of your customer base at different times.
  • Frissítési gyakoriságUpdate frequency. Előfordulhat, hogy vannak olyan ügyfelek, akik toleránsak a rendszer gyakori frissítéseivel, míg mások idegenkedik, és a kérelmeket szolgáltató rendszernek nem gyakori frissítéseket szeretnének.You may have some customers who are tolerant of having frequent updates to your system, while others may be risk-averse and want infrequent updates to the system that services their requests. Érdemes lehet ezeket az ügyfeleket elszigetelt környezetbe telepíteni.It may make sense to have these customers deployed to isolated environments.
  • Földrajzi vagy geopolitikai korlátozások.Geographical or geopolitical restrictions. Az alacsony késésű, illetve az adatszuverenitási követelmények betartására szolgáló építész számára bizonyos régiókban üzembe helyezhet néhány ügyfelet.To architect for low latency, or to comply with data sovereignty requirements, you may deploy some of your customers into specific regions.

ImplementálásImplementation

A problémák elkerülése érdekében érdemes lehet a megoldás összetevőinek példányait többször is üzembe helyezni.To avoid these issues, consider deploying copies of your solution's components multiple times. A bélyegek egymástól függetlenül működnek, és egymástól függetlenül üzembe helyezhetők és frissíthetők.Stamps operate independently of each other and can be deployed and updated independently. Egyetlen földrajzi régió tartalmazhat egyetlen bélyegzőt, vagy több bélyegzőt is tartalmazhat, amelyek lehetővé teszik a horizontális felskálázást a régión belül.A single geographical region may contain a single stamp, or may contain multiple stamps to allow for horizontal scale-out within the region. A bélyegek az ügyfelek egy részhalmazát tartalmazzák.Stamps contain a subset of your customers.

Telepítési bélyegzők egy példája

Az üzembe helyezési bélyegek alkalmazhatók arra, hogy a megoldás a szolgáltatásként nyújtott infrastruktúrát (IaaS) vagy a platform as Service (Pásti) összetevőit használja-e, vagy mindkettőt.Deployment stamps can apply whether your solution uses infrastructure as a service (IaaS) or platform as a service (PaaS) components, or a mixture of both. Általában a IaaS számítási feladatokhoz nagyobb beavatkozásra van szükség a méretezéshez, így a minta hasznos lehet a IaaS-alapú munkaterhelések számára, hogy lehetővé váljon a horizontális felskálázás.Typically IaaS workloads require more intervention to scale, so the pattern may be useful for IaaS-heavy workloads to allow for scaling out.

Az üzembe helyezési gyűrűkmegvalósításához bélyegzőket lehet használni.Stamps can be used to implement deployment rings. Ha a különböző ügyfelek különböző gyakoriságú szolgáltatási frissítéseket szeretnének fogadni, különböző bélyegzők szerint csoportosíthatók, és az egyes bélyegzők különböző ritmusokban telepíthetik a frissítéseket.If different customers want to receive service updates at different frequencies, they can be grouped onto different stamps, and each stamp could have updates deployed at different cadences.

Mivel a bélyegzők egymástól függetlenül futnak, az adatok implicit módon vannak felosztva.Because stamps run independently from each other, data is implicitly sharded. Emellett az egyetlen bélyegző további horizontális felskálázást tesz lehetővé a méretezhetőség és a rugalmasság érdekében a bélyegzőn belül.Furthermore, a single stamp can make use of further sharding to internally allow for scalability and elasticity within the stamp.

Az üzembe helyezési Stamp mintát számos Azure-szolgáltatás, például a app Service, a Azure stackés az Azure Storageis használja.The deployment stamp pattern is used internally by many Azure services, including App Service, Azure Stack, and Azure Storage.

Az üzembe helyezési bélyegzők a következőhöz kapcsolódnak:, de nem különböznek a geodes.Deployment stamps are related to, but distinct from, geodes. Az üzembe helyezési bélyegző architektúrájában a rendszer több független példányát helyezi üzembe, és az ügyfelek és a felhasználók egy részhalmazát tartalmazza.In a deployment stamp architecture, multiple independent instances of your system are deployed and contain a subset of your customers and users. A geodes minden példánya bármely felhasználótól kérheti a kérelmeket, de ez az architektúra gyakran bonyolultabb a tervezéshez és a létrehozáshoz.In geodes, all instances can serve requests from any users, but this architecture is often more complex to design and build. Egy megoldáson belül érdemes megfontolni a két minta összekeverését is; az alább ismertetett forgalom-útválasztási módszer példa erre a hibrid forgatókönyvre.You may also consider mixing the two patterns within one solution; the traffic routing approach described below is an example of such a hybrid scenario.

Üzembe helyezésDeployment

Az azonos összetevők azonos példányainak üzembe helyezéséhez szükséges összetettség miatt a helyes DevOps eljárások kritikus fontosságúak a minta megvalósításának sikeressége érdekében.Because of the complexity that is involved in deploying identical copies of the same components, good DevOps practices are critical to ensure success when implementing this pattern. Vegye fontolóra az infrastruktúra kódként való leírását, például Azure Resource Manager sablonok és parancsfájlok használatával.Consider describing your infrastructure as code, such as using Azure Resource Manager templates and scripts. Ezzel a módszerrel biztosíthatja, hogy az egyes bélyegzők üzembe helyezése kiszámítható legyen.With this approach, you can ensure that the deployment of each stamp is predictable. Emellett csökkenti az emberi hibák valószínűségét is, például véletlen eltéréseket a bélyegek közötti konfigurációban.It also reduces the likelihood of human errors such as accidental mismatches in configuration between stamps.

A frissítéseket automatikusan telepítheti az összes bélyegre párhuzamosan, ebben az esetben érdemes lehet olyan technológiákat is fontolóra venni, mint például a Resource Manager-sablonok vagy az Azure Deployment Manager az infrastruktúra és az alkalmazások üzembe helyezésének koordinálására.You can deploy updates automatically to all stamps in parallel, in which case you might consider technologies like Resource Manager templates or Azure Deployment Manager to coordinate the deployment of your infrastructure and applications. Dönthet úgy is, hogy a frissítéseket fokozatosan kivezeti néhány bélyegzőhöz, majd fokozatosan mások számára.Alternatively, you may decide to gradually roll out updates to some stamps first, and then progressively to others. Az Azure Deployment Manager is kezelhetik az ilyen típusú szakaszos bevezetést, vagy érdemes lehet olyan kiadás-felügyeleti eszközt használni, mint például az Azure-folyamatok , amelyekkel az egyes bélyegzőket üzembe helyezheti.Azure Deployment Manager can also manage this type of staged rollout, or you could consider using a release management tool like Azure Pipelines to orchestrate deployments to each stamp.

Körültekintően vegye figyelembe az Azure-előfizetések és-erőforráscsoportok topológiáját az üzemelő példányokhoz:Carefully consider the topology of the Azure subscriptions and resource groups for your deployments:

  • Általában egy előfizetés egyetlen megoldás összes erőforrását fogja tartalmazni, ezért általánosságban érdemes egyetlen előfizetést használni az összes bélyegzőhöz.Typically a subscription will contain all resources for a single solution, so in general consider using a single subscription for all stamps. Bizonyos Azure-szolgáltatások azonban az előfizetésre vonatkozó kvótákat írnak elő, így ha ezt a mintát használja a nagyfokú kibővítés lehetővé tételéhez, előfordulhat, hogy a bélyegeket különböző előfizetésekben kell telepíteni.However, some Azure services impose subscription-wide quotas, so if you are using this pattern to allow for a high degree of scale-out, you may need to consider deploying stamps across different subscriptions.
  • Az erőforráscsoportok általában az azonos életciklusú összetevők telepítéséhez használatosak.Resource groups are generally used to deploy components with the same lifecycle. Ha úgy tervezi, hogy egyszerre telepíti az összes bélyegző frissítését, érdemes lehet egyetlen erőforráscsoportot használni, hogy az összes Stamp összetevőjét tartalmazza, és az erőforrás-elnevezési konvenciók és címkék használatával azonosítsa az egyes bélyegzőhöz tartozó összetevőket.If you plan to deploy updates to all of your stamps at once, consider using a single resource group to contain all of the components for all of your stamps, and use resource naming conventions and tags to identify the components that belong to each stamp. Ha úgy tervezi, hogy az egyes bélyegzőket egymástól függetlenül telepíti, akkor az egyes bélyegzőket a saját erőforráscsoporthoz kell telepítenie.Alternatively, if you plan to deploy updates to each stamp independently, consider deploying each stamp into its own resource group.

KapacitástervezésCapacity planning

A terhelés és a teljesítmény tesztelésével meghatározhatja, hogy egy adott bélyegző milyen hozzávetőleges terhelést tud kielégíteni.Use load and performance testing to determine the approximate load that a given stamp can accommodate. A betöltési mérőszámok az olyan ügyfelek/bérlők számán alapulnak, amelyek egyetlen bélyegzővel rendelkezhetnek, vagy olyan mérőszámokat a szolgáltatásokból, amelyeket a bélyegzőn belüli összetevők bocsátanak ki.Load metrics may be based on the number of customers/tenants that a single stamp can accommodate, or metrics from the services that the components within the stamp emit. Győződjön meg arról, hogy elegendő rendszerállapottal rendelkezik ahhoz, hogy egy adott bélyegző megközelítse a kapacitását, és hogy az új bélyegek gyorsan üzembe helyezhetők az igények kielégítése érdekében.Ensure that you have sufficient instrumentation to measure when a given stamp is approaching its capacity, and the ability to deploy new stamps quickly to respond to demand.

Forgalom útválasztásaTraffic routing

Az üzembe helyezési bélyegző mintázata jól működik, ha az egyes bélyegzők egymástól függetlenül vannak címezve.The Deployment Stamp pattern works well if each stamp is addressed independently. Ha például a contoso ugyanazt az API-alkalmazást telepíti több bélyegzőn keresztül, érdemes lehet a DNS használatával átirányítani a forgalmat a megfelelő bélyegzőre:For example, if Contoso deploys the same API application across multiple stamps, they might consider using DNS to route traffic to the relevant stamp:

  • unit1.aus.myapi.contoso.com átirányítja a forgalmat unit1 egy ausztráliai régióban lévő bélyegzőbe.unit1.aus.myapi.contoso.com routes traffic to stamp unit1 within an Australian region.
  • unit2.aus.myapi.contoso.com átirányítja a forgalmat unit2 egy ausztráliai régióban lévő bélyegzőbe.unit2.aus.myapi.contoso.com routes traffic to stamp unit2 within an Australian region.
  • unit1.eu.myapi.contoso.com átirányítja a forgalmat unit1 egy európai régión belüli bélyegzőre.unit1.eu.myapi.contoso.com routes traffic to stamp unit1 within a European region.

Ezután az ügyfelek felelősek a megfelelő bélyegzőhöz való csatlakozásért.Clients are then responsible for connecting to the correct stamp.

Ha egyetlen belépési pontra van szükség az összes forgalomhoz, a forgalmi útválasztási szolgáltatás felhasználható egy adott kérelem, ügyfél vagy bérlő stampének feloldására.If a single ingress point for all traffic is required, a traffic routing service may be used to resolve the stamp for a given request, customer, or tenant. A forgalom-útválasztási szolgáltatás vagy az ügyfelet a bélyegző megfelelő URL-címére irányítja (például HTTP 302 Response állapotkód használatával), vagy fordított proxyként működhet, és továbbítja a forgalmat a megfelelő bélyegzőre anélkül, hogy az ügyfél tisztában lenne.The traffic routing service either directs the client to the relevant URL for the stamp (for example, using an HTTP 302 response status code), or may act as a reverse proxy and forward the traffic to the relevant stamp without the client being aware.

A központosított forgalom-útválasztási szolgáltatás összetett összetevő lehet a tervezéshez, különösen akkor, ha egy megoldás több régióban fut.A centralized traffic routing service can be a complex component to design, especially when a solution runs across multiple regions. Érdemes lehet a forgalom-útválasztási szolgáltatást több régióba telepíteni (például minden olyan régiót, amelyben a bélyegek üzembe helyezése történik), majd gondoskodni kell arról, hogy a rendszer szinkronizálja az adattárat (a bérlőket a bélyegek leképezésére).Consider deploying the traffic routing service into multiple regions (potentially including every region that stamps are deployed into), and then ensuring the data store (mapping tenants to stamps) is synchronized. A forgalom-útválasztási összetevő maga is rendelkezhet a geodéziai mintaegy példányával.The traffic routing component may itself by an instance of the geode pattern.

Például az Azure API Management üzembe helyezhető a Traffic Routing szolgáltatás szerepkörben.For example, Azure API Management could be deployed to act in the traffic routing service role. Meghatározhatja a kérelem megfelelő bélyegzőjét úgy, hogy megkeresi a bérlők és a bélyegek közötti leképezést tároló Cosmos db gyűjteményben lévő adatokat.It can determine the appropriate stamp for a request by looking up data in a Cosmos DB collection storing the mapping between tenants and stamps. A API Management Ezután dinamikusan állíthatja be a háttérbeli URL-címet a megfelelő Stamp API-szolgáltatásához.API Management can then dynamically set the back-end URL to the relevant stamp's API service.

A kérések földrajzi eloszlásának és a forgalom-útválasztási szolgáltatás földrajzi redundanciának engedélyezéséhez API Management több régióban is üzembehelyezhetők, vagy az Azure-beli bejárati ajtó használatával a legközelebbi példányra irányíthatja a forgalmat.To enable geo-distribution of requests and geo-redundancy of the traffic routing service, API Management can be deployed across multiple regions, or Azure Front Door can be used to direct traffic to the closest instance. A bejárati ajtókat háttér-készlettellehet konfigurálni, amely lehetővé teszi, hogy a kérések a legközelebbi elérhető API Management-példányhoz legyenek irányítva.Front Door can be configured with a backend pool, enabling requests to be directed to the closest available API Management instance. A Cosmos db globális terjesztési funkciói segítségével megtarthatja a leképezési adatok frissítését az egyes régiók között.The global distribution features of Cosmos DB can be used to keep the mapping information updated across each region.

Példa forgalmi útválasztási architektúrára

Ha egy forgalom-útválasztási szolgáltatás szerepel a megoldásban, gondolja át, hogy átjáróként működik-e, ezért a szolgáltatásokhoz, például a jogkivonat-ellenőrzéshez, a szabályozáshoz és az engedélyezéshez hajthat végre átjáró-kiszervezést .If a traffic routing service is included in your solution, consider whether it acts as a gateway and could therefore perform gateway offloading for services such as token validation, throttling, and authorization.

Problémák és megfontolandó szempontokIssues and considerations

A minta megvalósítása során az alábbi pontokat vegye figyelembe:You should consider the following points when deciding how to implement this pattern:

  • Üzembe helyezési folyamat.Deployment process. Több bélyegző üzembe helyezésekor erősen ajánlott az automatizált és teljes mértékben ismételhető üzembe helyezési folyamatok használata.When deploying multiple stamps, it is highly advisable to have automated and fully repeatable deployment processes. Érdemes lehet Resource Manager-sablonokat vagy Terraform-sablonokat használni a bélyegzők deklaratív definiálásához.Consider using Resource Manager templates or Terraform templates to declaratively define the stamp.
  • Több Stamp művelet.Cross-stamp operations. Ha a megoldás több bélyegen egymástól függetlenül van üzembe helyezve, például "hány ügyfelünk van az összes bélyegen?"When your solution is deployed independently across multiple stamps, questions like "how many customers do we have across all of our stamps?" összetettebb lehet a válaszadáshoz.can become more complex to answer. Előfordulhat, hogy a lekérdezéseket az egyes bélyegzők és az összesített eredmények alapján kell végrehajtani.Queries may need to be executed against each stamp and the results aggregated. Azt is megteheti, hogy az összes Stamp az adatokat egy központi adattárházba teszi közzé konszolidált jelentéskészítés céljából.Alternatively, consider having all of the stamps publish data into a centralized data warehouse for consolidated reporting.
  • Kibővíthető házirendek meghatározása.Determining scale-out policies. A bélyegek véges kapacitással rendelkeznek, amely a proxy metrikájának használatával definiálható, például a bélyegzőbe helyezhető bérlők száma.Stamps have a finite capacity, which might be defined using a proxy metric such as the number of tenants that can be deployed to the stamp. Fontos, hogy figyelje a rendelkezésre álló kapacitást és a felhasznált kapacitást az egyes bélyegzők esetében, és proaktív módon helyezzen üzembe további bélyegzőket, hogy az új bérlők átirányítsák őket.It is important to monitor the available capacity and used capacity for each stamp, and to proactively deploy additional stamps to allow for new tenants to be directed to them.
  • Költségek.Cost. Az üzembe helyezési bélyegző minta magában foglalja az infrastruktúra-összetevő több példányának telepítését, ami valószínűleg jelentős növekedést eredményez a megoldás üzemeltetése során.The Deployment Stamp pattern involves deploying multiple copies of your infrastructure component, which will likely involve a substantial increase in the cost of operating your solution.
  • Bélyegek közötti áthelyezés.Moving between stamps. Mivel az egyes bélyegzők telepítése és működtetése egymástól függetlenül történik, nehéz lehet a bélyegek közötti bérlők áthelyezése.As each stamp is deployed and operated independently, moving tenants between stamps can be difficult. Az alkalmazásnak egyéni logikára van szüksége ahhoz, hogy egy adott ügyfél adatait egy másik bélyegzőre továbbítsa, majd a bérlő adatait az eredeti bélyegzőből távolítsa el.Your application would need custom logic to transmit the information about a given customer to a different stamp, and then to remove the tenant's information from the original stamp. Ehhez a folyamathoz szükség lehet a bélyegek közötti kommunikációra, így tovább növelheti a teljes megoldás összetettségét.This process may require a backplane for communication between stamps, further increasing the complexity of the overall solution.
  • Forgalom útválasztása.Traffic routing. A fentiekben leírtak szerint az adott kérelemhez tartozó megfelelő bélyegzőre való átirányításhoz egy további összetevőre lehet szükség a bérlők stampek általi feloldásához.As described above, routing traffic to the correct stamp for a given request can require an additional component to resolve tenants to stamps. Ezt az összetevőt viszont szükség lehet a rendelkezésre állásra.This component, in turn, may need to be made highly available.
  • Megosztott összetevők.Shared components. Lehet, hogy vannak olyan összetevők, amelyek megoszthatók a bélyegek között.You may have some components that can be shared across stamps. Ha például közös egyoldalas alkalmazást használ az összes bérlőhöz, érdemes lehet az egyik régióba telepíteni, és a Azure CDN használatával replikálni globálisan.For example, if you have a shared single-page app for all tenants, consider deploying that into one region and using Azure CDN to replicate it globally.

Mikor kell használni a telepítési bélyegzőketWhen to use deployment stamps

Ez a minta akkor lehet hasznos, ha:This pattern is useful when you have:

  • A méretezhetőségre vonatkozó természetes korlátok.Natural limits on scalability. Ha például néhány összetevő nem tud vagy nem méretezhető bizonyos számú ügyféllel vagy kéréssel, érdemes lehet a bélyegek használatával felskálázást végezni.For example, if some components cannot or should not scale beyond a certain number of customers or requests, consider scaling out using stamps.
  • Bizonyos bérlők elkülönítésének követelménye másoktól.A requirement to separate certain tenants from others. Ha olyan ügyfelekkel rendelkezik, akik biztonsági okokból nem telepíthetnek több-bérlős bélyegzőbe más ügyfeleket, a saját elkülönített bélyegzőn is üzembe helyezhetők.If you have customers that cannot be deployed into a multi-tenant stamp with other customers due to security concerns, they can be deployed onto their own isolated stamp.
  • A megoldás különböző verzióin egy időben kell megadnia a bérlőket.A need to have some tenants on different versions of your solution at the same time.
  • Többrégiós alkalmazások, amelyekben a bérlői adatokat és a forgalmat egy adott régióra kell irányítani.Multi-region applications where each tenant's data and traffic should be directed to a specific region.
  • A rugalmasság elérése az kimaradások során.A desire to achieve resiliency during outages. Mivel a bélyegek egymástól függetlenek, ha a leállás egyetlen bélyegzőt érint, akkor a más bélyegekre telepített bérlőket nem kell érinteni.As stamps are independent of one another, if an outage affects a single stamp then the tenants deployed to other stamps should not be affected. Ez az elkülönítés segít az incidensek vagy kimaradások "Blast sugarának" tárolásában.This isolation helps to contain the 'blast radius' of an incident or outage.

Ez a minta nem alkalmas a következőhöz:This pattern is not suitable for:

  • Olyan egyszerű megoldások, amelyeknek nem kell nagy mértékben méretezniük.Simple solutions that do not need to scale to a high degree.
  • Azok a rendszerek, amelyek egyszerűen méretezhetők vagy akár akár egyetlen példányon belül is, például az alkalmazás rétegének méretének növelésével vagy az adatbázisok és a tárolási réteg fenntartott kapacitásának növelésével.Systems that can be easily scaled out or up within a single instance, such as by increasing the size of the application layer or by increasing the reserved capacity for databases and the storage tier.
  • Azok a megoldások, amelyekben az összes telepített példányban replikálni kell az adatfájlokat.Solutions in which data should be replicated across all deployed instances. Vegye figyelembe a forgatókönyv geodéziai mintáját .Consider the geode pattern for this scenario.
  • Olyan megoldások, amelyekben csak néhány összetevőt kell méretezni, másokat azonban nem.Solutions in which only some components need to be scaled, but not others. Tegyük fel például, hogy a megoldás méretezhető-e az adattár skálázásával ahelyett, hogy a megoldás összes összetevőjének új példányát telepítené.For example, consider whether your solution could be scaled by sharding the data store rather than deploying a new copy of all of the solution components.
  • Kizárólag statikus tartalomból, például előtér-JavaScript-alkalmazásból álló megoldások.Solutions comprised solely of static content, such as a front-end JavaScript application. Érdemes lehet ilyen tartalmat tárolni egy Storage-fiókban és Azure CDNhasználatával.Consider storing such content in a storage account and using Azure CDN.

Támogató technológiákSupporting technologies

  • Infrastruktúra mint kód.Infrastructure as code. Például: Resource Manager-sablonok, Azure CLI, Terraform, PowerShell, bash.For example, Resource Manager templates, Azure CLI, Terraform, PowerShell, Bash.
  • Deployment Manager, amely összehangolja a megoldások üzembe helyezéseit több bélyegzőn keresztül.Deployment Manager, which can orchestrate deployments of a solution across multiple stamps.
  • Az Azure bevezető ajtaja, amely egy adott bélyegzőre vagy egy forgalom-útválasztási szolgáltatásra irányítja a forgalmat.Azure Front Door, which can route traffic to a specific stamp or to a traffic routing service.

PéldaExample

A következő példa több bélyeget helyez üzembe egy egyszerű, egy app Service-szel és egy SQL Database az egyes bélyegzők esetében.The following example deploys multiple stamps of a simple PaaS solution, with an app service and a SQL Database in each stamp. Míg a bélyegek bármely olyan régióban konfigurálhatók, amely támogatja a sablonban üzembe helyezett szolgáltatásokat, illusztrációs célokra ez a sablon két bélyeget helyez üzembe az USA nyugati régiójában 2 régióban, valamint egy további bélyeget a Nyugat-európai régióban.While stamps can be configured in any region that support the services deployed in the template, for illustration purposes this template deploys two stamps within the West US 2 region and a further stamp in the West Europe region. Az App Service egy bélyegzőn belül fogadja a saját nyilvános DNS-gazdagépét, és az összes többi bélyegzőtől függetlenül tud kapcsolatokat fogadni.Within a stamp, the app service receives its own public DNS hostname and it can receive connections independently of all other stamps.

Figyelmeztetés

Az alábbi példa egy SQL Server rendszergazdai fiókot használ.The example below uses a SQL Server administrator account. Általában nem célszerű rendszergazdai fiókot használni az alkalmazásból.It's generally not a good practice to use an administrative account from your application. Egy valós alkalmazás esetében érdemes felügyelt identitást használni az alkalmazásból egy SQL-adatbázishoz való kapcsolódáshoz, vagy a legkevésbé jogosultságú fiók használatát.For a real application, consider using a managed identity to connect from your application to a SQL database, or use a least-privilege account.

A megoldás üzembe helyezéséhez kattintson az alábbi hivatkozásra.Click the link below to deploy the solution.

Üzembe helyezés az Azure-banDeploy to Azure

Megjegyzés

A stampek Resource Manager-sablonnal történő üzembe helyezésének alternatív módszerei, beleértve a beágyazott sablonok vagy csatolt sablonok használatát is, hogy leválasztsa az egyes bélyegzők definícióját a több példány üzembe helyezéséhez szükséges iterációból.There are alternative approaches to deploying stamps with a Resource Manager template, including using nested templates or linked templates to decouple the definition of each stamp from the iteration required to deploy multiple copies.

Példa forgalmi útválasztási megközelítésreExample traffic routing approach

A következő példa egy olyan forgalom-útválasztási megoldás megvalósítását helyezi üzembe, amely egy feltételezett API-alkalmazás üzembe helyezési bélyegzői készletével használható.The following example deploys an implementation of a traffic routing solution that could be used with a set of deployment stamps for a hypothetical API application. A bejövő kérések földrajzi eloszlásának engedélyezéséhez a bejárati ajtót a API Management több példánya is alkalmazza a felhasználási szinten.To allow for geographical distribution of incoming requests, Front Door is deployed alongside multiple instances of API Management on the consumption tier. Minden API Management példány beolvassa a bérlő AZONOSÍTÓját a kérelem URL-címéből, majd megkeresi a kéréshez tartozó bélyegzőt egy földrajzilag elosztott Cosmos DB-adattárból.Each API Management instance reads the tenant ID from the request URL and then looks up the relevant stamp for the request from a geo-distributed Cosmos DB data store. A rendszer ezután továbbítja a kérést a megfelelő háttérbeli bélyegzőre.The request is then forwarded to the relevant back-end stamp.

A megoldás üzembe helyezéséhez kattintson az alábbi hivatkozásra.Click the link below to deploy the solution.

Üzembe helyezés az Azure-banDeploy to Azure

Következő lépésekNext steps

  • A horizontális skálázás egy másik, egyszerűbb, az adatszinteket kibővítő megközelítéssel is használható.Sharding can be used as another, simpler, approach to scale out your data tier. A bélyegek implicit módon felosztják az adatokat, de a horizontális Skálázáshoz nincs szükség központi telepítési bélyegzőre.Stamps implicitly shard their data, but sharding does not require a Deployment Stamp. További információ: horizontális skálázási minta.For more information, see Sharding Pattern.
  • Ha egy forgalom-útválasztási szolgáltatás telepítve van, az átjáró útválasztási és átjáró-kiszervezési mintázatai együtt használhatók az összetevő legjobb kihasználásához.If a traffic routing service is deployed, the Gateway Routing and Gateway Offloading patterns can be used together to make the best use of this component.