在 Service Fabric 中进行缩放Scaling in Service Fabric

Azure Service Fabric 通过管理服务、分区以及群集的节点上的副本,让生成可缩放的应用程序更简单。Azure Service Fabric makes it easy to build scalable applications by managing the services, partitions, and replicas on the nodes of a cluster. 在同一硬件上运行多个工作负荷不仅可实现最大资源使用率,还可提供在如何选择缩放工作负荷方面的灵活性。Running many workloads on the same hardware enables maximum resource utilization, but also provides flexibility in terms of how you choose to scale your workloads.

在 Service Fabric 中进行缩放可通过多种不同方式实现:Scaling in Service Fabric is accomplished several different ways:

  1. 通过创建或删除无状态服务实例进行缩放Scaling by creating or removing stateless service instances
  2. 通过创建或删除新命名服务进行缩放Scaling by creating or removing new named services
  3. 通过创建或删除新命名应用程序实例进行缩放Scaling by creating or removing new named application instances
  4. 通过使用分区服务进行缩放Scaling by using partitioned services
  5. 通过在群集中添加节点和从群集删除节点进行缩放Scaling by adding and removing nodes from the cluster
  6. 通过使用群集资源管理器指标进行缩放Scaling by using Cluster Resource Manager metrics

通过创建或删除无状态服务实例进行缩放Scaling by creating or removing stateless service instances

在 Service Fabric 中进行缩放的最简单方式之一是结合无状态服务。One of the simplest ways to scale within Service Fabric works with stateless services. 创建无状态服务时,会获得定义 InstanceCount 的机会。When you create a stateless service, you get a chance to define an InstanceCount. InstanceCount 定义服务启动时创建的该服务代码的运行副本数量。InstanceCount defines how many running copies of that service's code are created when the service starts up. 例如,假设群集中有 100 个节点。Let's say, for example, that there are 100 nodes in the cluster. 再假设该服务使用 InstanceCount 值 10 进行创建。Let's also say that a service is created with an InstanceCount of 10. 运行时期间,代码的这 10 个运行副本可能全部都会变得过度繁忙(或可能不够繁忙)。During runtime, those 10 running copies of the code could all become too busy (or could be not busy enough). 缩放该工作负荷的一种方式是更改实例数量。One way to scale that workload is to change the number of instances. 例如,某些监视或管理代码可将现有实例数量更改为 50 或 5,具体取决于根据负载,工作负荷需要缩小还是扩大。For example, some piece of monitoring or management code can change the existing number of instances to 50, or to 5, depending on whether the workload needs to scale in or out based on the load.

C#:C#:

StatelessServiceUpdateDescription updateDescription = new StatelessServiceUpdateDescription(); 
updateDescription.InstanceCount = 50;
await fabricClient.ServiceManager.UpdateServiceAsync(new Uri("fabric:/app/service"), updateDescription);

Powershell:Powershell:

Update-ServiceFabricService -Stateless -ServiceName $serviceName -InstanceCount 50

使用动态实例计数Using Dynamic Instance Count

专门针对无状态服务,Service Fabric 提供了一种自动的方法来更改实例计数。Specifically for stateless services, Service Fabric offers an automatic way to change the instance count. 这使服务能够通过可用的节点数动态地进行缩放。This allows the service to scale dynamically with the number of nodes that are available. 选择加入此行为的方法是将实例计数设为 1。The way to opt into this behavior is to set the instance count = -1. InstanceCount = -1 是一条 Service Fabric 指令,表示“在每个节点上运行此无状态服务”。InstanceCount = -1 is an instruction to Service Fabric that says "Run this stateless service on every node." 如果节点数发生更改,Service Fabric 会自动更改实例计数进行匹配,确保在所有有效的节点上运行该服务。If the number of nodes changes, Service Fabric automatically changes the instance count to match, ensuring that the service is running on all valid nodes.

C#:C#:

StatelessServiceDescription serviceDescription = new StatelessServiceDescription();
//Set other service properties necessary for creation....
serviceDescription.InstanceCount = -1;
await fc.ServiceManager.CreateServiceAsync(serviceDescription);

Powershell:Powershell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName -Stateless -PartitionSchemeSingleton -InstanceCount "-1"

通过创建或删除新命名服务进行缩放Scaling by creating or removing new named services

命名服务实例是群集中某命名应用程序实例内的服务类型的特定实例(请参阅 Service Fabric 应用程序生命周期)。A named service instance is a specific instance of a service type (see Service Fabric application life cycle) within some named application instance in the cluster.

新的命名服务实例可在服务变得更繁忙或不繁忙时进行创建(或删除)。New named service instances can be created (or removed) as services become more or less busy. 这使请求可在更多服务实例中进行传播,通常允许减少现有服务上的负载。This allows requests to be spread across more service instances, usually allowing load on existing services to decrease. 创建服务时,Service Fabric 群集资源管理器会以分布式方式放置群集中的服务。When creating services, the Service Fabric Cluster Resource Manager places the services in the cluster in a distributed fashion. 确切的决策受群集中的指标和其他放置规则约束。The exact decisions are governed by the metrics in the cluster and other placement rules. 服务可以通过多种不同方式创建,但最常见的是通过管理操作(如用户调用 New-ServiceFabricService)或通过代码调用 CreateServiceAsyncServices can be created several different ways, but the most common are either through administrative actions like someone calling New-ServiceFabricService, or by code calling CreateServiceAsync. CreateServiceAsync 甚至可从正在群集中运行的其他服务内进行调用。CreateServiceAsync can even be called from within other services running in the cluster.

动态创建服务可用于各种方案,属于通用模式。Creating services dynamically can be used in all sorts of scenarios, and is a common pattern. 例如,请想一想代表特定工作流的有状态服务。For example, consider a stateful service that represents a particular workflow. 表示工作的调用将向此服务显示,且此服务会执行该工作流的步骤并记录进度。Calls representing work are going to show up to this service, and this service is going to execute the steps to that workflow and record progress.

将如何对此特定服务进行缩放?How would you make this particular service scale? 服务可以是某种形式的多租户,并一次性接受同一工作流的多个不同实例的调用和启动步骤。The service could be multi-tenant in some form, and accept calls and kick off steps for many different instances of the same workflow all at once. 但是,这可能使代码更复杂,因为现在它需要考虑同一工作流的多个不同实例,所有实例处于不同的阶段,来自不同的客户。However, that can make the code more complex, since now it has to worry about many different instances of the same workflow, all at different stages and from different customers. 此外,同时处理多个工作流不能解决缩放问题。Also, handling multiple workflows at the same time doesn't solve the scale problem. 这是因为此服务在某个时间点会占用过多资源,以适应特定计算机。This is because at some point this service will consume too many resources to fit on a particular machine. 许多最初并不是针对此模式生成的服务也会因其代码中的一些固有瓶颈或速度减慢而遇到困难。Many services not built for this pattern in the first place also experience difficulty due to some inherent bottleneck or slowdown in their code. 这些类型的问题会导致服务跟踪的并发工作流数量增多时,服务无法正常运行。These types of issues cause the service not to work as well when the number of concurrent workflows it is tracking gets larger.

一种解决方案是为想要跟踪的工作流的每个不同实例创建一个此服务的实例。这是一种很好的模式,无论服务是无状态还是有状态均能正常运行。A solution is to create an instance of this service for every different instance of the workflow you want to track. This is a great pattern and works whether the service is stateless or stateful. 为使此模式正常运行,通常会使用用作“工作负荷管理器服务”的另一服务。For this pattern to work, there's usually another service that acts as a "Workload Manager Service". 此服务的功能是接收请求,并将这些请求路由到其他服务。The job of this service is to receive requests and to route those requests to other services. 管理器在收到消息时可动态创建工作负荷服务的实例,并将请求传递到这些服务。The manager can dynamically create an instance of the workload service when it receives the message, and then pass on requests to those services. 给定的工作流服务完成其作业后,管理器服务也可接收回调。The manager service could also receive callbacks when a given workflow service completes its job. 管理器接收这些回调后,可删除工作流服务的该实例,或者如果需要更多调用,可将其保留。When the manager receives these callbacks it could delete that instance of the workflow service, or leave it if more calls are expected.

这种管理器的高级版本甚至可以创建它所管理的服务的池。Advanced versions of this type of manager can even create pools of the services that it manages. 池有助于确保在传入新请求时,无需等待服务启动。The pool helps ensure that when a new request comes in it doesn't have to wait for the service to spin up. 管理器可以从池中只选取当前不繁忙的工作流服务,或随机路由。Instead, the manager can just pick a workflow service that is not currently busy from the pool, or route randomly. 保持服务池可用性可更快速处理新请求,因为请求不太可能必须等待新服务启动。Keeping a pool of services available makes handling new requests faster, since it is less likely that the request has to wait for a new service to be spun up. 创建新服务很快,但也不是免费或瞬时完成。Creating new services is quick, but not free or instantaneous. 池有助于最大程度减少请求在维护之前需要等待的时间。The pool helps minimize the amount of time the request has to wait before being serviced. 当响应时间是最重要因素时,经常使用此管理器和池模式。You'll often see this manager and pool pattern when response times matter the most. 请求排队,并在后台创建服务,然后将其传递也是一种常用的管理器模式,如同基于服务当前挂起的工作量的一些跟踪,创建和删除服务。 Queuing the request and creating the service in the background and then passing it on is also a popular manager pattern, as is creating and deleting services based on some tracking of the amount of work that service currently has pending.

通过创建或删除新命名应用程序实例进行缩放Scaling by creating or removing new named application instances

创建和删除整个应用程序实例类似于创建和删除服务的模式。Creating and deleting whole application instances is similar to the pattern of creating and deleting services. 对于此模式,一些管理器服务基于其查看的请求和从群集内其他服务接收的信息,制定决策。For this pattern, there's some manager service that is making the decision based on the requests that it is seeing and the information it is receiving from the other services inside the cluster.

在一些现有应用程序中,什么情况下应使用创建新命名应用程序实例,而不是使用创建新命名服务实例?When should creating a new named application instance be used instead of creating a new named service instances in some already existing application? 存在一些情况:There's a few cases:

  • 新应用程序实例适用于其代码需要在某些特定标识或安全设置下运行的客户。The new application instance is for a customer whose code needs to run under some particular identity or security settings.
    • Service Fabric 允许定义不同的代码包在特定标识下运行。Service Fabric allows defining different code packages to run under particular identities. 若要在不同标识下启动相同的代码包,需要在不同应用程序实例中进行激活。In order to launch the same code package under different identities, the activations need to occur in different application instances. 请想一想已部署现有客户的工作负荷的情况。Consider a case where you have an existing customer's workloads deployed. 这些可能在特定标识下运行,以便用户监视并控制其对其他资源(如远程数据库或其他系统)的访问。These may be running under a particular identity so you can monitor and control their access to other resources, such as remote databases or other systems. 在这种情况下,新客户注册时,你可能不希望在相同的上下文(进程空间)中激活其代码。In this case, when a new customer signs up, you probably don't want to activate their code in the same context (process space). 尽管可以这么做,但这会使服务代码难以在特定标识的上下文中执行。While you could, this makes it harder for your service code to act within the context of a particular identity. 通常,必须具有多个安全、隔离和标识管理代码。You typically must have more security, isolation, and identity management code. 可以使用不同的命名 Service Fabric 应用程序实例,而不是在相同的应用程序实例和相同的进程空间中使用不同的命名服务实例。Instead of using different named service instances within the same application instance and hence the same process space, you can use different named Service Fabric Application instances. 这样可使定义不同的标识上下文更容易。This makes it easier to define different identity contexts.
  • 新的应用程序实例也会作为配置的一种方式The new application instance also serves as a means of configuration
    • 默认情况下,应用程序实例内的特定服务类型的所有命名服务实例会在给定节点的同一进程中运行。By default, all of the named service instances of a particular service type within an application instance will run in the same process on a given node. 这意味着,虽然可以不同的方式配置每个服务实例,但此操作很复杂。What this means is that while you can configure each service instance differently, doing so is complicated. 服务必须具有用于在配置包中查找其配置的特定令牌。Services must have some token they use to look up their config within a configuration package. 通常这就是服务的名称。Usually this is just the service's name. 这可正常使用,但它会将配置连接到应用程序实例中的单个命名服务实例的名称中。This works fine, but it couples the configuration to the names of the individual named service instances within that application instance. 这可能令人困惑且难以管理,因为配置通常是具有特定于应用程序实例的值的设计时项目。This can be confusing and hard to manage since configuration is normally a design time artifact with application instance specific values. 创建更多的服务总是意味着更多的应用程序升级,以更改配置包内的信息,或者部署新的配置包,使新服务可查找其特定信息。Creating more services always means more application upgrades to change the information within the config packages or to deploy new ones so that the new services can look up their specific information. 通常较简单的方式是创建全新的命名应用程序实例。It's often easier to create a whole new named application instance. 然后,可以使用应用程序参数设置服务所需的任何配置。Then you can use the application parameters to set whatever configuration is necessary for the services. 这样一来,在该命名应用程序实例中创建的所有服务均可继承特定的配置设置。This way all of the services that are created within that named application instance can inherit particular configuration settings. 例如,可为每个客户创建不同的应用程序实例(替代所有设置),而不是为每个客户创建包含设置和自定义(如机密或每个客户的资源限制)的单个配置文件。For example, instead of having a single configuration file with the settings and customizations for every customer, such as secrets or per customer resource limits, you'd instead have a different application instance for each customer with these settings overridden.
  • 新的应用程序用作升级边界The new application serves as an upgrade boundary
    • 在 Service Fabric 中,不同的命名应用程序实例会用作升级边界。Within Service Fabric, different named application instances serve as boundaries for upgrade. 升级一个命名应用程序实例不会影响正在运行的另一命名应用程序实例的代码。An upgrade of one named application instance will not impact the code that another named application instance is running. 不同的应用程序最后会在相同的节点上运行相同代码的不同版本。The different applications will end up running different versions of the same code on the same nodes. 在需要做出缩放决策时,这可以是一个考虑因素,因为可以选择新代码是否应遵循与另一服务相同的升级。This can be a factor when you need to make a scaling decision because you can choose whether the new code should follow the same upgrades as another service or not. 例如,假设调用到达负责通过动态创建和删除服务来缩放特定客户的工作负荷的管理器服务。For example, say that a call arrives at the manager service that is responsible for scaling a particular customer's workloads by creating and deleting services dynamically. 然而,在这种情况下,调用针对与新客户关联的工作负荷 。In this case however, the call is for a workload associated with a new customer. 大多数客户希望保持相互独立,不仅是因为之前列出的安全性和配置原因,也因为这可在运行特定版本软件和选择升级时间方面提供更高的灵活性。Most customers like being isolated from each other not just for the security and configuration reasons listed previously, but because it provides more flexibility in terms of running specific versions of the software and choosing when they get upgraded. 此外,还可以创建新的应用程序实例,并在其中创建服务,对任何升级可能涉及的服务量进行进一步分区。You may also create a new application instance and create the service there simply to further partition the amount of your services that any one upgrade will touch. 执行应用程序升级时,单独的应用程序实例可提供更高的粒度,也支持 A/B 测试和蓝/绿部署。Separate application instances provide greater granularity when doing application upgrades, and also enable A/B testing and Blue/Green deployments.
  • 现有的应用程序实例已满The existing application instance is full
    • 在 Service Fabric 中,应用程序容量是可用于控制特定应用程序实例可用资源量的一个概念。In Service Fabric, application capacity is a concept that you can use to control the amount of resources available for particular application instances. 例如,我们判断给定的服务需要创建另一实例,以便进行缩放。For example, you may decide that a given service needs to have another instance created in order to scale. 但是,此应用程序实例的某些指标容量已超。However, this application instance is out of capacity for a certain metric. 如果仍应向此特定客户或工作负荷授予更多资源,则可以增加该应用程序的现有容量或创建新的应用程序。If this particular customer or workload should still be granted more resources, then you could either increase the existing capacity for that application or create a new application.

在分区级别进行缩放Scaling at the partition level

Service Fabric 支持分区。Service Fabric supports partitioning. 分区可将服务拆分成若干逻辑和物理部分,每个部分均可单独运行。Partitioning splits a service into several logical and physical sections, each of which operates independently. 这对有状态服务十分有用,因为没有任何副本集需要一次性处理所有调用并操纵所有状态。This is useful with stateful services, since no one set of replicas has to handle all the calls and manipulate all of the state at once. 分区概述 提供了有关受支持分区方案类型的信息。The partitioning overview provides information on the types of partitioning schemes that are supported. 每个分区的副本跨群集的节点传播,分发该服务的负载并确保整个服务或任何分区均没有故障点。The replicas of each partition are spread across the nodes in a cluster, distributing that service's load and ensuring that neither the service as a whole or any partition has a single point of failure.

考虑一下这样一项服务:使用范围分区方案,低键为 0,高键为 99,分区计数为 4。Consider a service that uses a ranged partitioning scheme with a low key of 0, a high key of 99, and a partition count of 4. 在包含三个节点的群集中,该服务可能如此处所示,按四个副本共享每个节点上的资源的方式进行布局:In a three-node cluster, the service might be laid out with four replicas that share the resources on each node as shown here:

三节点式分区布局

如果增加节点数目,Service Fabric 会移动其中的一些现有副本。If you increase the number of nodes, Service Fabric will move some of the existing replicas there. 例如,假设节点数增加到 4,且已重新分发副本。For example, let's say the number of nodes increases to four and the replicas get redistributed. 现在,服务在每个节点上有 3 个正在运行的副本,每个副本均属于不同的分区。Now the service now has three replicas running on each node, each belonging to different partitions. 这可以实现更高的资源利用率,因为新节点不冷。This allows better resource utilization since the new node isn't cold. 通常情况下,这还可提高性能,因为每项服务均有更多可用资源。Typically, it also improves performance as each service has more resources available to it.

四节点式分区布局

使用 Service Fabric 群集资源管理器和指标进行缩放Scaling by using the Service Fabric Cluster Resource Manager and metrics

指标是服务向 Service Fabric 表示其资源消耗的方式。Metrics are how services express their resource consumption to Service Fabric. 使用指标可使群集资源管理器重新组织和优化群集布局。Using metrics gives the Cluster Resource Manager an opportunity to reorganize and optimize the layout of the cluster. 例如,群集中可能有充足的资源,但可能未向当前执行操作的服务分配这些资源。For example, there may be plenty of resources in the cluster, but they might not be allocated to the services that are currently doing work. 通过使用指标,群集资源管理器可重新组织群集,确保服务有权访问可用资源。Using metrics allows the Cluster Resource Manager to reorganize the cluster to ensure that services have access to the available resources.

通过在群集中添加节点和从群集删除节点进行缩放Scaling by adding and removing nodes from the cluster

使用 Service Fabric 进行缩放的另一种方法是更改群集大小。Another option for scaling with Service Fabric is to change the size of the cluster. 更改群集的大小意味着添加或删除群集中的一个或多个节点类型的节点。Changing the size of the cluster means adding or removing nodes for one or more of the node types in the cluster. 例如,想一想群集中的所有节点均为热的情况。For example, consider a case where all of the nodes in the cluster are hot. 这意味着群集的资源几乎全部耗尽。This means that the cluster's resources are almost all consumed. 在这种情况下,缩放的最佳方法是将更多节点添加到群集中。In this case, adding more nodes to the cluster is the best way to scale. 新节点联接群集后,Service Fabric 群集资源管理器将服务移到其中,导致现有节点上的总负载减少。Once the new nodes join the cluster the Service Fabric Cluster Resource Manager moves services to them, resulting in less total load on the existing nodes. 对于实例计数为 -1 的无状态服务,会自动创建更多服务实例。For stateless services with instance count = -1, more service instances are automatically created. 这会使某些调用从现有节点移到新节点。This allows some calls to move from the existing nodes to the new nodes.

有关详细信息,请参阅群集缩放For more information, see cluster scaling.

选择平台Choosing a platform

由于操作系统之间的实现差异,选择在 Windows 或 Linux 上使用 Service Fabric 可能是缩放应用程序的重要部分。Due to implementation differences between operating systems, choosing to use Service Fabric with Windows or Linux can be a vital part of scaling your application. 一个潜在的障碍是如何执行分段日志记录。One potential barrier is how staged logging is performed. Windows 上的 Service Fabric 使用内核驱动程序来实现每台机器一个日志,在有状态服务副本之间共享。Service Fabric on Windows uses a kernel driver for a one-per-machine log, shared between stateful service replicas. 此日志的大小约为 8 GB。This log weighs in at about 8 GB. 另一方面,Linux 为每个副本使用 256 MB 的暂存日志,因此对于希望最大化在给定节点上运行的轻量级服务副本数量的应用程序而言,Linux 不太理想。Linux, on the other hand, uses a 256 MB staging log for each replica, making it less ideal for applications that want to maximize the number of lightweight service replicas running on a given node. 临时存储要求的这些差异可能会潜在地通知所需的 Service Fabric 群集部署平台。These differences in temporary storage requirements could potentially inform the desired platform for Service Fabric cluster deployment.

汇总Putting it all together

让我们汇总已在此文中讨论的所有观点,并讨论一个示例。Let's take all the ideas that we've discussed here and talk through an example. 请考虑以下服务:要生成一个充当通讯簿的服务,其中保存名称和联系信息。Consider the following service: you are trying to build a service that acts as an address book, holding on to names and contact information.

首先,需要考虑多个与缩放相关的问题:会有多少用户?Right up front you have a bunch of questions related to scale: How many users are you going to have? 每个用户会存储多少个联系人?How many contacts will each user store? 如果要在第一次构建服务时解决所有问题,这会很难。Trying to figure this all out when you are standing up your service for the first time is difficult. 假设要处理具有特定分区计数的单个静态服务。Let's say you were going to go with a single static service with a specific partition count. 如果选取错误的分区计数,以后可能会存在规模问题。The consequences of picking the wrong partition count could cause you to have scale issues later. 同样,即使选对计数,也可能并没有所需的所有信息。Similarly, even if you pick the right count you might not have all the information you need. 例如,还需要首先决定群集的大小(节点数和其大小)。For example, you also have to decide the size of the cluster up front, both in terms of the number of nodes and their sizes. 通常难以预测服务在其生存期内使用的资源数。It's usually hard to predict how many resources a service is going to consume over its lifetime. 也可能很难提前知道服务实际看到的流量模式。It can also be hard to know ahead of time the traffic pattern that the service actually sees. 例如,可能人们只在早上首先添加和删除其联系人,或者也可能在一天中均匀分布。For example, maybe people add and remove their contacts only first thing in the morning, or maybe it's distributed evenly over the course of the day. 基于此,可能需要动态地扩大和缩小服务。Based on this you might need to scale out and in dynamically. 也许可以学习预测何时需要扩大和缩小服务,但无论哪种方式,可能都需要应对服务不断变化的资源消耗情况。Maybe you can learn to predict when you're going to need to scale out and in, but either way you're probably going to need to react to changing resource consumption by your service. 这可能涉及更改群集的大小,以在重新组织现有资源的使用不足以解决问题时提供更多资源。This can involve changing the size of the cluster in order to provide more resources when reorganizing use of existing resources isn't enough.

但为什么要尝试为所有用户选择出单个分区方案?But why even try to pick a single partition scheme out for all users? 为什么局限于一项服务和一个静态群集?Why limit yourself to one service and one static cluster? 实际情况通常更具动态。The real situation is usually more dynamic.

通过生成进行缩放时,请考虑以下动态模式。When building for scale, consider the following dynamic pattern. 可能需要使其适应具体的情况:You may need to adapt it to your situation:

  1. 生成一项“管理器服务”,而不是尝试为所有人预先选取一个分区方案。Instead of trying to pick a partitioning scheme for everyone up front, build a "manager service".
  2. 管理器服务作业的目标是在客户注册服务时,查看客户信息。The job of the manager service is to look at customer information when they sign up for your service. 根据该信息,管理器服务只为该客户创建实际联系人存储服务的实例 。Then depending on that information the manager service creates an instance of your actual contact-storage service just for that customer. 如果需要特定配置、隔离或升级,还可决定为此客户启动应用程序实例。If they require particular configuration, isolation, or upgrades, you can also decide to spin up an Application instance for this customer.

此动态创建模式有多种好处:This dynamic creation pattern many benefits:

  • 无需提前猜测所有用户的正确分区计数,或者自行生成可无限缩放的单一服务。You're not trying to guess the correct partition count for all users up front or build a single service that is infinitely scalable all on its own.
  • 不同的用户无需具有相同的分区计数、副本计数、替换约束、指标、默认负载、服务名称、DNS 设置或在服务或应用程序级别指定的任何其他属性。Different users don't have to have the same partition count, replica count, placement constraints, metrics, default loads, service names, dns settings, or any of the other properties specified at the service or application level.
  • 你将获得更多的数据段。You gain additional data segmentation. 每个客户都有自己的服务副本Each customer has their own copy of the service
    • 可以通过不同方式配置每个客户服务,且授予其更多或更少资源,并且可以根据需要基于客户预期的规模,增加或减少包含的分区或副本数。Each customer service can be configured differently and granted more or fewer resources, with more or fewer partitions or replicas as necessary based on their expected scale.
      • 例如,假设客户支付了“黄金”层 - 他们可以获取更多副本或更高分区计数,以及通过指标和应用程序容量专用于其服务的资源。For example, say the customer paid for the "Gold" tier - they could get more replicas or greater partition count, and potentially resources dedicated to their services via metrics and application capacities.
      • 或者假设客户提供的信息指示他们需要的联系人数为“Small”- 则会只得到几个分区,或者甚至可能与其他客户一起放置到共享服务池中。Or say they provided information indicating the number of contacts they needed was "Small" - they would get only a few partitions, or could even be put into a shared service pool with other customers.
  • 不需在等待客户出现时运行多个服务实例或副本You're not running a bunch of service instances or replicas while you're waiting for customers to show up
  • 如果某个客户要离开,则从服务中删除其信息非常简单,就像让管理器删除它创建的服务或应用程序一样。If a customer ever leaves, then removing their information from your service is as simple as having the manager delete that service or application that it created.

后续步骤Next steps

有关 Service Fabric 概念的详细信息,请参阅以下文章:For more information on Service Fabric concepts, see the following articles: