Service Fabric Services ölçeklenebilirliği | Microsoft Docs
Service Fabric ölçeklendirmeScaling in Service Fabric
Azure Service Fabric, bir kümenin düğümlerinde Hizmetleri, bölümleri ve çoğaltmaları yöneterek ölçeklenebilir uygulamalar oluşturmayı kolaylaştırır.Azure Service Fabric makes it easy to build scalable applications by managing the services, partitions, and replicas on the nodes of a cluster. Aynı donanımda birçok iş yükünün çalıştırılması maksimum kaynak kullanımını sağlar, ancak aynı zamanda iş yüklerinizi ölçeklendirmeye nasıl seçeceğiniz konusunda esneklik sağlar.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. Bu Channel 9 videosu, ölçeklenebilir mikro hizmet uygulamaları oluşturmayı açıklar:This Channel 9 video describes how you can build scalable microservices applications:
Service Fabric ölçeklendirme birkaç farklı şekilde gerçekleştirilir:Scaling in Service Fabric is accomplished several different ways:
Durum bilgisi olmayan hizmet örnekleri oluşturarak veya kaldırarak ölçeklemeScaling by creating or removing stateless service instances
Yeni adlandırılmış hizmetler oluşturarak veya kaldırarak ölçeklemeScaling by creating or removing new named services
Yeni adlandırılmış uygulama örnekleri oluşturarak veya kaldırarak ölçeklemeScaling by creating or removing new named application instances
Bölümlenmiş Hizmetleri kullanarak ölçeklendirmeScaling by using partitioned services
Kümeden düğüm ekleyerek ve kaldırarak ölçeklemeScaling by adding and removing nodes from the cluster
Küme Kaynak Yöneticisi ölçümlerini kullanarak ölçeklendirmeScaling by using Cluster Resource Manager metrics
Service Fabric içinde ölçeklendirmenin en basit yöntemlerinden biri, durum bilgisi olmayan hizmetlerle birlikte çalışmaktadır.One of the simplest ways to scale within Service Fabric works with stateless services. Durum bilgisi olmayan bir hizmet oluşturduğunuzda, tanımlama InstanceCountşansı elde edersiniz.When you create a stateless service, you get a chance to define an InstanceCount. InstanceCounthizmet başlatıldığında hizmetin kodunun kaç tane çalışan kopyasının oluşturulduğunu tanımlar.InstanceCount defines how many running copies of that service's code are created when the service starts up. Örneğin, kümede 100 düğüm olduğunu varsayalım.Let's say, for example, that there are 100 nodes in the cluster. Ayrıca, 10 ' un bir InstanceCount hizmetin oluşturulduğunu de söylayalım.Let's also say that a service is created with an InstanceCount of 10. Çalışma zamanı sırasında kodun çalışan 10 kopyası hepsi çok meşgul hale gelebilir (veya yeterince meşgul olmayabilir).During runtime, those 10 running copies of the code could all become too busy (or could be not busy enough). Bu iş yükünü ölçeklendirmenin bir yolu, örnek sayısını değiştirmektir.One way to scale that workload is to change the number of instances. Örneğin, bazı izleme veya yönetim kodu parçaları, iş yükünün yük temelinde ölçeklendirilmesine veya kullanıma hazır olmasına bağlı olarak, mevcut örnek sayısını 50 veya 5 olarak değiştirebilir.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.
Dinamik örnek sayısı kullanmaUsing Dynamic Instance Count
Özel durum bilgisi olmayan hizmetler için, Service Fabric örnek sayısını değiştirmek için otomatik bir yol sunar.Specifically for stateless services, Service Fabric offers an automatic way to change the instance count. Bu, hizmetin kullanılabilir düğüm sayısıyla dinamik olarak ölçeklendirilmesine olanak tanır.This allows the service to scale dynamically with the number of nodes that are available. Bu davranışı kabul etmenin yolu, örnek sayısı =-1 ' i ayarlamanıza olanak sağlar.The way to opt into this behavior is to set the instance count = -1. InstanceCount =-1, "Bu durum bilgisiz hizmeti her düğümde Çalıştır" diyen Service Fabric bir yönergedir.InstanceCount = -1 is an instruction to Service Fabric that says "Run this stateless service on every node." Düğüm sayısı değişirse Service Fabric, hizmetin tüm geçerli düğümlerde çalıştığından emin olmak için örnek sayısını eşleşecek şekilde otomatik olarak değiştirir.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.
Adlandırılmış bir hizmet örneği, kümedeki bazı adlandırılmış uygulama örnekleri içinde hizmet türünün belirli bir örneğidir (bkz. uygulama yaşam döngüsü 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.
Hizmetler daha fazla veya daha az hale geldiği için yeni adlandırılmış hizmet örnekleri oluşturulabilir (veya kaldırılabilir).New named service instances can be created (or removed) as services become more or less busy. Bu, isteklerin daha fazla hizmet örneğine yayılmasını sağlar, genellikle mevcut hizmetlerde yükün azaltılmasına izin verir.This allows requests to be spread across more service instances, usually allowing load on existing services to decrease. Hizmet oluştururken, Service Fabric kümesi Kaynak Yöneticisi Hizmetleri dağıtılmış bir biçimde kümeye koyar.When creating services, the Service Fabric Cluster Resource Manager places the services in the cluster in a distributed fashion. Tam kararlar, kümedeki ölçümlere ve diğer yerleştirme kurallarına tabidir.The exact decisions are governed by the metrics in the cluster and other placement rules. Hizmetler birkaç farklı şekilde oluşturulabilir, ancak en yaygın olarak, biri çağıran New-ServiceFabricServiceya da kod çağırarak CreateServiceAsyncyönetim eylemleridir.Services 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, kümede çalışan diğer hizmetlerden da çağrılabilir.CreateServiceAsync can even be called from within other services running in the cluster.
Hizmetlerin dinamik olarak oluşturulması, her tür senaryoda kullanılabilir ve ortak bir modeldir.Creating services dynamically can be used in all sorts of scenarios, and is a common pattern. Örneğin, belirli bir iş akışını temsil eden bir durum bilgisi olan hizmeti düşünün.For example, consider a stateful service that represents a particular workflow. İşi temsil eden çağrılar bu hizmete kadar görünür ve bu hizmet bu iş akışına yönelik adımları yürütecek ve ilerlemeyi kaydetmeye devam etmektedir.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.
Bu belirli hizmet ölçeğini nasıl yaparsınız?How would you make this particular service scale? Hizmet, bazı bir biçimde birden çok kiracı olabilir ve aynı iş akışının birçok farklı örneği için aynı anda birden çok farklı örnek için çağrıları kabul edebilir ve adımları başlatabilir.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. Ancak, artık aynı iş akışının birçok farklı örneğine, farklı aşamalara ve farklı müşterilere kadar endişelenmek zorunda olduğundan, bu kodu daha karmaşık hale getirebilirsiniz.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. Aynı zamanda birden çok iş akışını aynı anda işlemek, ölçek sorununu çözmez.Also, handling multiple workflows at the same time doesn't solve the scale problem. Bunun nedeni, bazı bir noktada bu hizmetin belirli bir makineye sığması için çok fazla kaynak tüketmesi olacaktır.This is because at some point this service will consume too many resources to fit on a particular machine. İlk yerde bu model için derlenmedi birçok hizmet, kendi kodlarında bazı ilgili performans veya yavaşlama nedeniyle zorluk gösterebilir.Many services not built for this pattern in the first place also experience difficulty due to some inherent bottleneck or slowdown in their code. Bu tür sorunlar, bir hizmetin, izlenen eşzamanlı iş akışı sayısı daha büyük olduğunda da çalışmamasına neden olur.These types of issues cause the service not to work as well when the number of concurrent workflows it is tracking gets larger.
Bir çözüm, izlemek istediğiniz iş akışının her farklı örneği için bu hizmetin bir örneğini oluşturmaktır. Bu harika bir modeldir ve hizmetin durum bilgisiz veya durum bilgisi olup olmadığı konusunda çalışmaktadır.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. Bu düzenin çalışması için genellikle "Iş yükü Yöneticisi hizmeti" olarak davranan başka bir hizmet vardır.For this pattern to work, there's usually another service that acts as a "Workload Manager Service". Bu hizmetin işi istekleri almak ve bu istekleri diğer hizmetlere yönlendirmekte.The job of this service is to receive requests and to route those requests to other services. Yönetici iletiyi aldığında iş yükü hizmetinin bir örneğini dinamik olarak oluşturabilir ve istekleri bu hizmetlere geçirebilir.The manager can dynamically create an instance of the workload service when it receives the message, and then pass on requests to those services. Belirli bir iş akışı hizmeti işini tamamladığında, yönetici hizmeti de geri çağrılar alabilir.The manager service could also receive callbacks when a given workflow service completes its job. Yönetici bu geri çağırmaları aldığında, iş akışı hizmetinin bu örneğini silebilir veya daha fazla çağrı bekleniyorsa onu bırakabilirsiniz.When the manager receives these callbacks it could delete that instance of the workflow service, or leave it if more calls are expected.
Bu tür bir yöneticinin gelişmiş sürümleri, yönettiği hizmetlerin havuzlarını bile oluşturabilir.Advanced versions of this type of manager can even create pools of the services that it manages. Havuz, yeni bir istek geldiğinde hizmetin dönmesini beklemek zorunda olmadığından emin olmanıza yardımcı olur.The pool helps ensure that when a new request comes in it doesn't have to wait for the service to spin up. Bunun yerine, yönetici yalnızca havuzdan meşgul olmayan bir iş akışı hizmeti seçebilir ya da rastgele yol açabilir.Instead, the manager can just pick a workflow service that is not currently busy from the pool, or route randomly. Bir hizmet havuzunun kullanılabilir tutulması, isteğin yeni bir hizmetin sonlanmasını beklemek gerektiğinden, yeni istekleri daha hızlı işlemesini sağlar.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. Yeni hizmetler oluşturmak hızlı, ancak ücretsiz veya anlık değildir.Creating new services is quick, but not free or instantaneous. Havuz, isteğin hizmet vermeden önce beklemesi gereken süreyi en aza indirmenize yardımcı olur.The pool helps minimize the amount of time the request has to wait before being serviced. En çok yanıt süresi en fazla olduğunda bu yöneticiyi ve havuz modelini görürsünüz.You'll often see this manager and pool pattern when response times matter the most. İsteği kuyruğa alma ve hizmeti arka planda oluşturma ve daha sonra , hizmetin Şu anda bekleyen iş miktarının bir izlemeye göre hizmetleri oluşturup silen gibi popüler bir yönetici de vardır.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.
Tüm uygulama örneklerinin oluşturulması ve silinmesi, hizmet oluşturma ve silme düzenine benzer.Creating and deleting whole application instances is similar to the pattern of creating and deleting services. Bu model için, görmekte olan isteklere ve küme içindeki diğer hizmetlerden aldığı bilgilere göre karar veren bir yönetici hizmeti vardır.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.
Ne zaman var olan bir uygulamada yeni bir adlandırılmış hizmet örnekleri oluşturmak yerine yeni bir adlandırılmış uygulama örneği oluşturulması gerekir?When should creating a new named application instance be used instead of creating a new named service instances in some already existing application? Birkaç durum vardır:There's a few cases:
Yeni uygulama örneği, kodu belirli bir kimlik veya güvenlik ayarları altında çalışması gereken bir müşteri içindir.The new application instance is for a customer whose code needs to run under some particular identity or security settings.
Service Fabric, farklı kod paketlerinin belirli kimlikler altında çalışacak şekilde tanımlanmasını sağlar.Service Fabric allows defining different code packages to run under particular identities. Farklı kimlikler altında aynı kod paketini başlatmak için, etkinleştirmelerin farklı uygulama örneklerinde gerçekleşmesi gerekir.In order to launch the same code package under different identities, the activations need to occur in different application instances. Mevcut bir müşterinin iş yüklerinin dağıtıldığı bir durumu göz önünde bulundurun.Consider a case where you have an existing customer's workloads deployed. Bunlar, uzak veritabanları veya diğer sistemler gibi diğer kaynaklara erişimi izleyip denetleyebilmeniz için belirli bir kimlik altında çalışıyor olabilir.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. Bu durumda, yeni bir müşteri kaydolduğunda, büyük olasılıkla kodlarını aynı bağlamda (işlem alanı) etkinleştirmek istemezsiniz.In this case, when a new customer signs up, you probably don't want to activate their code in the same context (process space). Mümkün olsa da, bu, servis kodunuzun belirli bir kimlik bağlamı dahilinde çalışmasını zorlaştırır.While you could, this makes it harder for your service code to act within the context of a particular identity. Genellikle daha fazla güvenlik, yalıtım ve kimlik yönetim kodu olmalıdır.You typically must have more security, isolation, and identity management code. Aynı uygulama örneği içinde farklı adlandırılmış hizmet örnekleri kullanmak ve bu nedenle aynı işlem alanına sahip olmak yerine farklı adlandırılmış Service Fabric uygulama örnekleri kullanabilirsiniz.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. Bu, farklı kimlik bağlamlarının tanımlanması kolaylaşır.This makes it easier to define different identity contexts.
Yeni uygulama örneği aynı zamanda bir yapılandırma yolu görevi görürThe new application instance also serves as a means of configuration
Varsayılan olarak, bir uygulama örneği içindeki belirli bir hizmet türünün tüm adlandırılmış hizmet örnekleri, belirli bir düğümdeki aynı işlemde çalışır.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. Bunun anlamı, her bir hizmet örneğini farklı şekilde yapılandırabilirken, bu durum karmaşıktır.What this means is that while you can configure each service instance differently, doing so is complicated. Hizmetlerin bir yapılandırma paketi içinde yapılandırmalarını aramak için kullandıkları bazı belirteçleri olmalıdır.Services must have some token they use to look up their config within a configuration package. Genellikle bu yalnızca hizmetin adıdır.Usually this is just the service's name. Bu sorunsuz bir şekilde çalışıyor, ancak yapılandırmayı bu uygulama örneği içindeki bireysel adlandırılmış hizmet örneklerinin adlarına bağar.This works fine, but it couples the configuration to the names of the individual named service instances within that application instance. Yapılandırma normalde uygulama örneğine özgü değerlerle tasarım zamanı yapıtı olduğundan, bu kafa karıştırıcı ve yönetimi zor olabilir.This can be confusing and hard to manage since configuration is normally a design time artifact with application instance specific values. Her zaman daha fazla hizmet oluşturmak, yapılandırma paketlerindeki bilgileri değiştirmek veya yeni hizmetlerin belirli bilgilerini aramak üzere yenilerini dağıtmak için daha fazla uygulama yükseltmesi anlamına gelir.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. Yeni bir adlandırılmış uygulama örneğinin tümüyle oluşturulması genellikle daha kolay.It's often easier to create a whole new named application instance. Ardından, hizmetler için hangi yapılandırmanın gerekli olduğunu ayarlamak üzere uygulama parametrelerini kullanabilirsiniz.Then you can use the application parameters to set whatever configuration is necessary for the services. Bu şekilde, bu adlandırılmış uygulama örneği içinde oluşturulan tüm hizmetler belirli yapılandırma ayarlarını alabilir.This way all of the services that are created within that named application instance can inherit particular configuration settings. Örneğin, her müşterinin gizli dizi ayarları ve özelleştirmeleri gibi tek bir yapılandırma dosyasına sahip olmak yerine, bu ayarlara sahip her müşteri için farklı bir uygulama örneği olması gerekir. geçersiz kılınan.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.
Yeni uygulama bir yükseltme sınırı görevi görürThe new application serves as an upgrade boundary
Service Fabric içinde farklı adlandırılmış uygulama örnekleri yükseltme için sınır olarak görev yapar.Within Service Fabric, different named application instances serve as boundaries for upgrade. Adlandırılmış bir uygulama örneğinin bir yükseltmesi, başka bir adlandırılmış uygulama örneğinin çalıştırıldığı kodu etkilemez.An upgrade of one named application instance will not impact the code that another named application instance is running. Farklı uygulamalar aynı düğümlerin farklı sürümlerini aynı düğümlerde çalıştırmaya sona acaktır.The different applications will end up running different versions of the same code on the same nodes. Yeni kodun başka bir hizmet ile aynı yükseltmelere göre izlenmesi gerekip gerekmediğini seçebilmeniz için bir ölçeklendirme kararı oluşturmanız gerektiğinde bu bir etken olabilir.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. Örneğin, bir çağrının, belirli bir müşterinin iş yüklerini ölçeklendirmekten sorumlu Yönetim hizmetine, Hizmetleri dinamik olarak oluşturup silerek sorumlu olduğunu varsayalım.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. Ancak bu durumda, çağrı Yeni bir müşteriyle ilişkili bir iş yüküne yöneliktir.In this case however, the call is for a workload associated with a new customer. Çoğu müşteri, yalnızca daha önce listelenen güvenlik ve yapılandırma nedenleriyle değil, ancak yazılımın belirli sürümlerini çalıştırmanın ve ne zaman yükseltildikleri gibi daha fazla esneklik sağladığından daha fazla esneklik sağladığından daha fazla esneklik sağlar.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. Ayrıca, bir yükseltmenin dokunmasına yönelik hizmetlerinizin miktarını daha fazla bölümlemek için yeni bir uygulama örneği oluşturabilir ve bu hizmeti oluşturabilirsiniz.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. Ayrı uygulama örnekleri, uygulama yükseltmeleri yaparken daha fazla ayrıntı düzeyi sağlar ve ayrıca bir/B testini ve mavi/yeşil dağıtımları etkinleştirir.Separate application instances provide greater granularity when doing application upgrades, and also enable A/B testing and Blue/Green deployments.
Mevcut uygulama örneği doluThe existing application instance is full
Service Fabric, uygulama kapasitesi , belirli uygulama örnekleri için kullanılabilir kaynak miktarını denetlemek için kullanabileceğiniz bir kavramdır.In Service Fabric, application capacity is a concept that you can use to control the amount of resources available for particular application instances. Örneğin, belirli bir hizmetin ölçeklendirmek için başka bir örneğin oluşturulmasını gerektiren bir hizmet olduğuna karar verebilirsiniz.For example, you may decide that a given service needs to have another instance created in order to scale. Ancak, bu uygulama örneği belirli bir ölçüm için kapasite dışında.However, this application instance is out of capacity for a certain metric. Bu müşteriye veya iş yüküne hala daha fazla kaynak verilmesi gerekiyorsa, bu uygulama için mevcut kapasiteyi artırabilir ya da yeni bir uygulama oluşturabilirsiniz.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.
Bölüm düzeyinde ölçeklemeScaling at the partition level
Service Fabric bölümlemeyi destekler.Service Fabric supports partitioning. Bölümlendirme bir hizmeti, her biri bağımsız olarak çalışan birkaç mantıksal ve fiziksel bölüme ayırır.Partitioning splits a service into several logical and physical sections, each of which operates independently. Tek bir çoğaltma kümesinin tüm çağrıları işlemesi ve tüm durumu tek seferde işlemesi gerektiğinden, bu durum bilgisi olmayan hizmetlerle yararlıdır.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. Bölümlendirme genel bakışı , desteklenen bölümleme şemaları türleri hakkında bilgi sağlar.The partitioning overview provides information on the types of partitioning schemes that are supported. Her bölümün çoğaltmaları bir kümedeki düğümlere yayılır, bu hizmetin yükü dağıtılır ve hizmetin tamamı ya da herhangi bir bölüm için tek bir hata noktası olmadığı doğrulanıyor.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.
Düşük anahtar 0, yüksek bir 99 ve bölüm sayısı 4 olan bir ranşlı bölümlendirme şeması kullanan bir hizmet düşünün.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. Üç düğümlü bir kümede, hizmet burada gösterildiği gibi her bir düğümdeki kaynakları paylaşan dört çoğaltmalarla Genişletilebilir:In a three-node cluster, the service might be laid out with four replicas that share the resources on each node as shown here:
![Partition layout with three nodes](./media/service-fabric-concepts-scalability/layout-three-nodes.png)
Düğüm sayısını artırdıysanız, Service Fabric var olan çoğaltmalardan bazılarını buraya taşıyacaktır.If you increase the number of nodes, Service Fabric will move some of the existing replicas there. Örneğin, düğüm sayısının dört olarak arttığını ve çoğaltmaların yeniden dağıtılması gerektiğini varsayalım.For example, let's say the number of nodes increases to four and the replicas get redistributed. Artık hizmette, her biri farklı bölüme ait olan her düğüm üzerinde çalışan üç çoğaltma vardır.Now the service now has three replicas running on each node, each belonging to different partitions. Bu, yeni düğüm soğuk olmadığından daha iyi kaynak kullanımına olanak tanır.This allows better resource utilization since the new node isn't cold. Genellikle, her bir hizmetin kullanılabilir kaynakları daha fazla kaynağa sahip olduğu için performansı de artırır.Typically, it also improves performance as each service has more resources available to it.
![Partition layout with four nodes](./media/service-fabric-concepts-scalability/layout-four-nodes.png)
Service Fabric kümesi Kaynak Yöneticisi ve ölçümleri kullanarak ölçeklendirmeScaling by using the Service Fabric Cluster Resource Manager and metrics
Ölçümler , hizmetlerin kaynak tüketimini Service Fabric için nasıl ifade edin.Metrics are how services express their resource consumption to Service Fabric. Ölçüm kullanımı, kümenin yerleşimini yeniden düzenlemek ve iyileştirmek için bir fırsat Kaynak Yöneticisi sağlar.Using metrics gives the Cluster Resource Manager an opportunity to reorganize and optimize the layout of the cluster. Örneğin, kümede çok fazla kaynak olabilir, ancak şu anda iş yapmakta olan hizmetlere ayrılmayabilir.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. Ölçüm kullanımı, hizmetlerin kullanılabilir kaynaklara erişiminin olduğundan emin olmak için kümeyi yeniden düzenleyecek Kaynak Yöneticisi sağlar.Using metrics allows the Cluster Resource Manager to reorganize the cluster to ensure that services have access to the available resources.
Service Fabric ile ölçeklendirmeye yönelik başka bir seçenek de kümenin boyutunu değiştirir.Another option for scaling with Service Fabric is to change the size of the cluster. Küme boyutunun değiştirilmesi, kümedeki düğüm türlerinin bir veya daha fazlası için düğüm ekleme veya kaldırma anlamına gelir.Changing the size of the cluster means adding or removing nodes for one or more of the node types in the cluster. Örneğin, kümedeki tüm düğümlerin etkin olduğu bir durumu göz önünde bulundurun.For example, consider a case where all of the nodes in the cluster are hot. Bu, kümenin kaynaklarının neredeyse hepsi tüketildiği anlamına gelir.This means that the cluster's resources are almost all consumed. Bu durumda, ölçeklendirmek için en iyi yol, kümeye daha fazla düğüm eklemektir.In this case, adding more nodes to the cluster is the best way to scale. Yeni düğümler kümeye katılırsanız Service Fabric kümesi Kaynak Yöneticisi Hizmetleri bunlara taşıdıkça, mevcut düğümlerde daha az toplam yük elde edilir.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. Örnek sayısı =-1 olan durum bilgisi olmayan hizmetler için, daha fazla hizmet örneği otomatik olarak oluşturulur.For stateless services with instance count = -1, more service instances are automatically created. Bu, bazı çağrıların varolan düğümlerden yeni düğümlere taşınmasını sağlar.This allows some calls to move from the existing nodes to the new nodes.
Daha fazla bilgi için bkz. küme ölçeklendirme.For more information, see cluster scaling.
Platform seçmeChoosing a platform
İşletim sistemleri arasındaki uygulama farklılıkları nedeniyle, Windows veya Linux ile Service Fabric kullanmayı seçme, uygulamanızı ölçeklendirmenin önemli bir parçası olabilir.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. Olası bir engel, aşamalı günlüğün gerçekleştirilme şekli olur.One potential barrier is how staged logging is performed. Windows üzerinde Service Fabric, durum bilgisi olan hizmet çoğaltmaları arasında paylaşılan bir makine başına günlük için çekirdek sürücü kullanır.Service Fabric on Windows uses a kernel driver for a one-per-machine log, shared between stateful service replicas. Bu günlük, yaklaşık 8 GB ile ücretlendirilir.This log weighs in at about 8 GB. Linux, diğer yandan her bir çoğaltma için 256 MB 'lik bir hazırlama günlüğü kullanır ve bu, belirli bir düğümde çalışan hafif hizmet çoğaltmaları sayısını en üst düzeye çıkarmak isteyen uygulamalar için daha az ideal hale getirir.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. Geçici depolama gereksinimlerindeki bu farklılıklar, Service Fabric küme dağıtımı için istenen platformu bilgilendirebilecek.These differences in temporary storage requirements could potentially inform the desired platform for Service Fabric cluster deployment.
Hepsini bir araya getirmePutting it all together
Burada tartışıldığı ve bir örnek ile konuşduğumuz tüm fikirleri inceleyelim.Let's take all the ideas that we've discussed here and talk through an example. Aşağıdaki hizmeti göz önünde bulundurun: adres defteri olarak davranan, adlara ve iletişim bilgilerine sahip bir hizmet oluşturmaya çalışıyorsunuz.Consider the following service: you are trying to build a service that acts as an address book, holding on to names and contact information.
Sağ tarafta, ölçeklendirmeye ilişkin bir dizi sorunuz var: Kaç Kullanıcı var?Right up front you have a bunch of questions related to scale: How many users are you going to have? Her Kullanıcı için kaç kişi depolanacak?How many contacts will each user store? Hizmetinizi ilk kez doldururken bu tümünü belirlemeye çalışmak zordur.Trying to figure this all out when you are standing up your service for the first time is difficult. Belirli bir bölüm sayısı ile tek bir statik hizmetle gideceğim diyelim.Let's say you were going to go with a single static service with a specific partition count. Yanlış bölüm sayısını kaldırmanın sonuçları, daha sonra ölçek sorunları oluşmasına neden olabilir.The consequences of picking the wrong partition count could cause you to have scale issues later. Benzer şekilde, doğru sayıyı seçmiş olsanız bile, ihtiyacınız olan tüm bilgilere sahip olmayabilirsiniz.Similarly, even if you pick the right count you might not have all the information you need. Örneğin, küme boyutunun önüne, hem düğüm sayısı hem de boyutlarına göre karar vermeniz gerekir.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. Genellikle bir hizmetin yaşam süresi boyunca tüketmesi için kaç kaynak olduğunu tahmin etmek zordur.It's usually hard to predict how many resources a service is going to consume over its lifetime. Ayrıca, hizmetin gerçekten gördüğü trafik deseninin önünde haberdar olmak zor olabilir.It can also be hard to know ahead of time the traffic pattern that the service actually sees. Örneğin, insanlar kişileri yalnızca sabah ilk bir kez ekleyebilir ve kaldırabilir ya da gün boyunca eşit olarak dağıtılır.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. Bunu temel alarak, dinamik olarak ve dinamik olarak ölçeklendirmeniz gerekebilir.Based on this you might need to scale out and in dynamically. Büyük olasılıkla, ne zaman ölçeği, ne kadar ölçeklendirmeniz gerektiğini, ancak hizmetinize göre kaynak tüketimini değiştirmeye yanıt vermek için ne kadar iyi bir şekilde bilgi edinebilirsiniz.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. Bu, mevcut kaynakların kullanımını yeniden düzenleme yeterli olmadığında daha fazla kaynak sağlamak için kümenin boyutunun değiştirilmesini içerebilir.This can involve changing the size of the cluster in order to provide more resources when reorganizing use of existing resources isn't enough.
Ancak neden tüm kullanıcılar için tek bir bölüm düzeni seçmeyi denemenize de çalışıyor?But why even try to pick a single partition scheme out for all users? Neden tek bir hizmetle ve tek bir statik kümeyle sınırlandırım?Why limit yourself to one service and one static cluster? Gerçek durum genellikle daha dinamik bir durumdur.The real situation is usually more dynamic.
Ölçek için derleme yaparken, aşağıdaki dinamik kalıbı göz önünde bulundurun.When building for scale, consider the following dynamic pattern. Durumunuza uyarlamanız gerekebilir:You may need to adapt it to your situation:
Herkes için bir bölümleme şeması seçmeyi denemek yerine "Yönetici hizmeti" oluşturun.Instead of trying to pick a partitioning scheme for everyone up front, build a "manager service".
Yönetici hizmeti 'nin işi, hizmetinize kaydolduklarında müşteri bilgilerine bakabilmenizdir.The job of the manager service is to look at customer information when they sign up for your service. Daha sonra bu bilgilere bağlı olarak, yönetici hizmeti gerçek iletişim depolama hizmetinizin bir örneğini oluşturur.Then depending on that information the manager service create an instance of your actual contact-storage service just for that customer. Belirli yapılandırma, yalıtım veya yükseltmeler gerektiriyorsa, bu müşteri için bir uygulama örneği çalıştırmaya da karar verebilirsiniz.If they require particular configuration, isolation, or upgrades, you can also decide to spin up an Application instance for this customer.
Bu dinamik oluşturma deseninin birçok avantajı:This dynamic creation pattern many benefits:
Tüm kullanıcılar için doğru bölüm sayısını tahmin etmeye veya kendi kendine sınırsız bir şekilde ölçeklenebilir tek bir hizmet oluşturmaya çalışmayız.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.
Farklı kullanıcıların aynı bölüm sayısı, çoğaltma sayısı, yerleştirme kısıtlamaları, ölçümler, varsayılan Yüklemeler, hizmet adları, DNS ayarları veya hizmet veya uygulama düzeyinde belirtilen diğer özelliklerden herhangi biri olması gerekmez.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.
Ek veri segmentlemesini elde edersiniz.You gain additional data segmentation. Her müşterinin hizmetin bir kopyası vardırEach customer has their own copy of the service
Her müşteri hizmeti farklı şekilde yapılandırılabilir ve beklenen ölçeğe bağlı olarak daha fazla veya daha az bölüm ya da çoğaltmalarla daha fazla veya daha az kaynak vermiş olabilir.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.
Örneğin, müşterinin "altın" katman için ödendiğini varsayalım. daha fazla çoğaltma veya daha fazla bölüm sayısı ve potansiyel kaynaklar ölçüm ve uygulama kapasiteleri aracılığıyla hizmetlerine ayrılmıştır.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.
Ya da gerek duydukları kişilerin sayısını belirten bilgileri "küçük" olarak belirttiğinizi varsayalım. yalnızca birkaç bölüm alırlar veya diğer müşterilerle paylaşılan bir hizmet havuzuna de yerleştirilebilir.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.
Müşterilerin gösterilmesini beklerken bir veya daha fazla hizmet örneği veya çoğaltması çalıştırılıyorsunuzYou're not running a bunch of service instances or replicas while you're waiting for customers to show up
Bir müşteri ayrıldıktan sonra, kendi bilgilerini hizmetinizden kaldırmak, yöneticinin oluşturduğu hizmeti veya uygulamayı silmesini sağlayan basit bir işlemdir.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.
Service Fabric Hizmetleri bölümlendirmePartitioning Service Fabric services