Mikro hizmetler tasarlama: Mikro hizmet sınırlarını tanımlamaDesigning microservices: Identifying microservice boundaries

Bir mikro hizmet için doğru boyutu nedir?What is the right size for a microservice? Genellikle bir şey etkisini, "çok büyük ve çok küçük" için işittiğiniz — ve, kesinlikle doğru olsa da, uygulamada çok yararlı değildir.You often hear something to the effect of, "not too big and not too small" — and while that's certainly correct, it's not very helpful in practice. Ancak, dikkatli bir şekilde tasarlanmış bir etki alanı modelden başlatırsanız, neden mikro hizmetler hakkında çok daha kolay.But if you start from a carefully designed domain model, it's much easier to reason about microservices.

Sınırlanmış Bağlamlar diyagramı

Mikro hizmet etki alanı modeliFrom domain model to microservices

İçinde önceki bölümde, sınırlanmış Bağlamlar insansız hava aracı ile teslimat uygulaması için bir dizi tanımladık.In the previous chapter, we defined a set of bounded contexts for the Drone Delivery application. Daha sonra bu sınırlanmış Bağlamlar, sevkiyat sınırlanmış bağlam birine daha yakından baktığı ve bir dizi varlık, toplamlar, tanımlanan ve etki alanı Hizmetleri söz konusu içerik sınırlanmış.Then we looked more closely at one of these bounded contexts, the Shipping bounded context, and identified a set of entities, aggregates, and domain services for that bounded context.

Artık uygulama tasarımı için etki alanı modelinden gitmek hazırız.Now we're ready to go from domain model to application design. Mikro hizmet etki alanı modelden türetmek için kullanabileceğiniz bir yaklaşım aşağıda verilmiştir.Here's an approach that you can use to derive microservices from the domain model.

  1. Sınırlanmış bağlam ile başlayın.Start with a bounded context. Genel olarak, bir mikro hizmet işlevlerini birden fazla sınırlanmış bağlam yayılacağı değil.In general, the functionality in a microservice should not span more than one bounded context. Tanımı gereği, belirli bir etki alanı modeli sınırını bir sınırlanmış bağlam işaretler.By definition, a bounded context marks the boundary of a particular domain model. Bir mikro hizmet birlikte farklı bir etki alanı modelleri karıştırır bulursanız, geri dönün ve, etki alanı analizi geliştirmek için ihtiyacınız olan bir oturum olmasıdır.If you find that a microservice mixes different domain models together, that's a sign that you may need to go back and refine your domain analysis.

  2. Ardından, etki alanı modelinizdeki toplamalar bakın.Next, look at the aggregates in your domain model. Toplamlar, mikro hizmetler için iyi adaylar çoğunlukla olur.Aggregates are often good candidates for microservices. İyi tasarlanmış bir toplama gibi birçok iyi tasarlanmış bir mikro hizmet özelliklerini gösteriyor:A well-designed aggregate exhibits many of the characteristics of a well-designed microservice, such as:

    • Veri erişimi veya Mesajlaşma gibi teknik sorunları yerine iş gereksinimlerini toplama türetilir.An aggregate is derived from business requirements, rather than technical concerns such as data access or messaging.
    • Bir toplama yüksek işlevsel Uyuma sahip olması gerekir.An aggregate should have high functional cohesion.
    • Toplama, Kalıcılık için kullanılan bir sınırıdır.An aggregate is a boundary of persistence.
    • Toplamlar gevşek bağlanmış olmalıdır.Aggregates should be loosely coupled.
  3. Etki Alanı Hizmetleri, ayrıca mikro hizmetler için iyi adaylar değildir.Domain services are also good candidates for microservices. Etki Alanı Hizmetleri durum bilgisiz, birden çok toplamları arasında işlemlerdir.Domain services are stateless operations across multiple aggregates. Birden fazla mikro hizmetler içeren bir iş akışı buna tipik bir örnektir.A typical example is a workflow that involves several microservices. İnsansız hava aracı ile teslimat uygulaması içinde bunun bir örneği göreceğiz.We'll see an example of this in the Drone Delivery application.

  4. Son olarak, işlevsel olmayan gereksinimleri göz önünde bulundurun.Finally, consider non-functional requirements. Takım boyutu, veri türleri, teknolojiler, ölçeklenebilirlik gereksinimlerini, kullanılabilirlik gereksinimlerini ve güvenlik gereksinimleri gibi faktörlere bakın.Look at factors such as team size, data types, technologies, scalability requirements, availability requirements, and security requirements. Bu etkenler, başka bir mikro hizmet, iki veya daha çok daha küçük hizmetler ayırmak veya bunun tersini yapmak ve birden fazla mikro hizmetler tek birleştirmek için neden olabilir.These factors may lead you to further decompose a microservice into two or more smaller services, or do the opposite and combine several microservices into one.

Mikro hizmetler uygulamanızda tanımladıktan sonra tasarımınızı karşı aşağıdaki ölçütleri doğrulayın:After you identify the microservices in your application, validate your design against the following criteria:

  • Her hizmet tek bir sorumluluğa sahiptir.Each service has a single responsibility.
  • Hizmetler arasında hiçbir geveze çağrıları vardır.There are no chatty calls between services. İki hizmet işlevlerini bölme sık iletişim kuran olmalarına neden olursa, bu işlevler aynı hizmetinde ait bir belirtisi olabilir.If splitting functionality into two services causes them to be overly chatty, it may be a symptom that these functions belong in the same service.
  • Her hizmet küçük bir takımda birbirinden bağımsız çalışan tarafından oluşturulabilir yapabileceği kadar küçüktür.Each service is small enough that it can be built by a small team working independently.
  • Kilit adımda dağıtılması için iki veya daha fazla hizmet gerektiren hiçbir arası bağımlılıkları vardır.There are no inter-dependencies that will require two or more services to be deployed in lock-step. Her zaman diğer hizmetleri yeniden dağıtmaya gerek kalmadan bir hizmeti dağıtmak olası olmalıdır.It should always be possible to deploy a service without redeploying any other services.
  • Hizmetleri değil sıkı şekilde bağlı ve bağımsız olarak geliştirebilirsiniz.Services are not tightly coupled, and can evolve independently.
  • Veri tutarlılığı veya bütünlüğü sorunlar, hizmet sınırları oluşturulmaz.Your service boundaries will not create problems with data consistency or integrity. Bazen tek bir mikro hizmet işlevselliği koyarak veri tutarlılığı sağlamak önemlidir.Sometimes it's important to maintain data consistency by putting functionality into a single microservice. Bununla birlikte, güçlü tutarlılık gerçekten ihtiyacınız olup olmadığını göz önünde bulundurun.That said, consider whether you really need strong consistency. Nihai tutarlılık, dağıtılmış bir sistemde adresleme strateji vardır ve Hizmetleri genellikle parçalama, nihai tutarlılık yönetme sorunlarından ağır basıyor.There are strategies for addressing eventual consistency in a distributed system, and the benefits of decomposing services often outweigh the challenges of managing eventual consistency.

Yukarıdaki tüm Pragmatik ve etki alanı Odaklı Tasarım yinelemeli bir işlem olduğunu unutmayın önemlidir.Above all, it's important to be pragmatic, and remember that domain-driven design is an iterative process. Emin olamadığınız durumlarda daha fazla parçalı mikro hizmet ile başlayın.When in doubt, start with more coarse-grained microservices. Bir mikro bölmeyi iki küçük hizmetler, işlevselliği varolan birçok mikro hizmetler arasında yeniden düzenleme daha kolaydır.Splitting a microservice into two smaller services is easier than refactoring functionality across several existing microservices.

İnsansız hava aracı ile teslimat: Mikro hizmet tanımlamaDrone Delivery: Defining the microservices

Geliştirme ekibi dört toplamalar tanımlanmış geri çağırma — teslim, paket, insansız hava aracı ve hesap — ve iki etki alanı Hizmetleri, Zamanlayıcı ve gözetmen.Recall that the development team had identified the four aggregates — Delivery, Package, Drone, and Account — and two domain services, Scheduler and Supervisor.

Teslim ve paket mikro hizmetlere yönelik belirgin adaylardır.Delivery and Package are obvious candidates for microservices. Zamanlayıcı ve gözetmen bu etki alanı Hizmetleri mikro hizmetler olarak uygulamak için mantıklı şekilde diğer mikro hizmetler tarafından gerçekleştirilen etkinlikleri koordine edin.The Scheduler and Supervisor coordinate the activities performed by other microservices, so it makes sense to implement these domain services as microservices.

İnsansız hava aracı ile hesap için başka bir sınırlanmış Bağlamlar ait oldukları için ilginç.Drone and Account are interesting because they belong to other bounded contexts. Zamanlayıcı insansız hava aracı ile çağırmak bir seçenektir ve hesap bağlamları doğrudan sınırlanmış.One option is for the Scheduler to call the Drone and Account bounded contexts directly. Başka bir seçenek sevkiyat sınırlanmış bağlam içinde mikro hizmetler insansız hava aracı ve hesabı oluşturmaktır.Another option is to create Drone and Account microservices inside the Shipping bounded context. Bu mikro hizmetler, nakliye bağlamına daha uygun olan API'leri veya veri şemalarını gösterme tarafından sınırlanmış Bağlamlar arasında aktarmak.These microservices would mediate between the bounded contexts, by exposing APIs or data schemas that are more suited to the Shipping context.

İnsansız hava aracı ve sınırlanmış hesap ayrıntılarını başvuru uygulamamızda sahte Hizmetleri için bunları oluşturduğumuz için bağlamları olan bu kılavuzun kapsamı dışındadır.The details of the Drone and Account bounded contexts are beyond the scope of this guidance, so we created mock services for them in our reference implementation. Ancak bu durumda dikkate alınacak bazı faktörler şunlardır:But here are some factors to consider in this situation:

  • Ağ yükünü başka bir sınırlanmış bağlam doğrudan çağırma nedir?What is the network overhead of calling directly into the other bounded context?

  • Veri şemasını diğer sınırlanmış bağlam için bu bağlam için uygundur ve daha iyi bu sınırlanmış bağlam için uyarlanmış bir şemaya sahip olduğu?Is the data schema for the other bounded context suitable for this context, or is it better to have a schema that's tailored to this bounded context?

  • Başka bir sınırlanmış bağlam, eski sistem mi?Is the other bounded context a legacy system? Bu nedenle, olarak davranan bir hizmeti oluşturabilir, bir bozulma önleyici katman modern uygulama ile eski sistem arasında çeviri yapmak için.If so, you might create a service that acts as an anti-corruption layer to translate between the legacy system and the modern application.

  • Takım yapısı nedir?What is the team structure? Diğer sınırlanmış bağlam için sorumlu bir ekip ile iletişim kurmak kolay mı?Is it easy to communicate with the team that's responsible for the other bounded context? Aksi durumda, iki bağlamları arasında aracılık bir hizmet oluşturma takımlar arası iletişimi maliyetini azaltmaya yardımcı olabilir.If not, creating a service that mediates between the two contexts can help to mitigate the cost of cross-team communication.

Şu ana kadar işlevsel olmayan gereksinimlere dikkate henüz.So far, we haven't considered any non-functional requirements. Uygulamanın aktarım hızı gereksinimleri hakkında düşünmek, geliştirme ekibi istemci isteklerini almak için sorumlu ayrı bir alma mikro hizmet oluşturmayı kararlaştırdı.Thinking about the application's throughput requirements, the development team decided to create a separate Ingestion microservice that is responsible for ingesting client requests. Bu mikro hizmet uygulayacak Yük Dengeleme gelen istekleri işlemek için arabellek içine koyarak.This microservice will implement load leveling by putting incoming requests into a buffer for processing. Zamanlayıcı arabellek okuma istekleri ve iş akışı yürütme.The Scheduler will read the requests from the buffer and execute the workflow.

İşlevsel olmayan gereksinimler, ek bir hizmet oluşturmak için takım gerektiriyordu.Non-functional requirements led the team to create one additional service. Şu ana kadar tüm hizmetleri, zamanlama ve paketleri gerçek zamanlı olarak teslim işlemini hakkında olmuştur.All of the services so far have been about the process of scheduling and delivering packages in real time. Ancak sistem, uzun vadeli depolama için veri analizi her teslim geçmişini depolamak de gerekir.But the system also needs to store the history of every delivery in long-term storage for data analysis. Takım, bu teslim hizmeti sorumluluğu yapmadan kabul edilir.The team considered making this the responsibility of the Delivery service. Ancak, veri depolama gereksinimleri oldukça farklı geçmişe dönük analiz karşı yürütülen işlemler (bkz veri konuları).However, the data storage requirements are quite different for historical analysis versus in-flight operations (see Data considerations). Bu nedenle, takımın teslim hizmeti DeliveryTracking olayları dinler ve uzun süreli depolama alanına olayları yazma ayrı bir teslim geçmişi hizmet oluşturmayı kararlaştırdı.Therefore, the team decided to create a separate Delivery History service, which will listen for DeliveryTracking events from the Delivery service and write the events into long-term storage.

Aşağıdaki diyagramda, bu noktada tasarım gösterilmektedir:The following diagram shows the design at this point:

Tasarım diyagramı

İşlem seçeneği tercihiChoosing a compute option

İşlem terimi, uygulamanızın üzerinde çalıştığı işlem kaynakları için barındırma modelini ifade eder.The term compute refers to the hosting model for the computing resources that your application runs on. Bir mikro hizmet mimarisi için iki yaklaşım özellikle olarak popüler şunlardır:For a microservices architecture, two approaches are especially popular:

  • Adanmış düğümler (VM'ler) üzerinde çalışan hizmetleri yöneten bir hizmet Düzenleyici.A service orchestrator that manages services running on dedicated nodes (VMs).
  • (FaaS) hizmet olarak işlevleri kullanarak sunucusuz bir mimari.A serverless architecture using functions as a service (FaaS).

Bu seçenekler yalnızca değildir, ancak mikro hizmetler oluşturmaya yönelik kanıtlanmış her iki yaklaşım değildirler.While these aren't the only options, they are both proven approaches to building microservices. Bir uygulamanın her iki yaklaşım içerebilir.An application might include both approaches.

Hizmet düzenleyicileriService orchestrators

Bir orchestrator Hizmetleri kümesi yönetme ve dağıtma ile ilgili görevleri işler.An orchestrator handles tasks related to deploying and managing a set of services. Bu görevler hizmetleri yeniden iyi durumda olmayan hizmetler, hizmetlerin durumunu izleme düğümlerinde yerleştirme dahil, hizmet bulma, bir hizmetin örnek sayısında ölçeklendirme ve uygulama hizmet örnekleri arasında ağ trafiği Dengeleme yükleme Yapılandırma güncelleştirmeleri.These tasks include placing services on nodes, monitoring the health of services, restarting unhealthy services, load balancing network traffic across service instances, service discovery, scaling the number of instances of a service, and applying configuration updates. Kubernetes, Service Fabric, DC/OS ve Docker Swarm popüler düzenleyicilerle içerir.Popular orchestrators include Kubernetes, Service Fabric, DC/OS, and Docker Swarm.

Azure platformunda, aşağıdaki seçenekleri göz önünde bulundurun:On the Azure platform, consider the following options:

  • Azure Kubernetes hizmeti (AKS), yönetilen bir Kubernetes hizmeti.Azure Kubernetes Service (AKS) is a managed Kubernetes service. Kubernetes ve Kubernetes API uç noktalarını kullanıma sunar, ancak barındıran ve Kubernetes denetim düzlemi, Otomatik yükseltme gerçekleştirme yönetir AKS hükümlerine otomatik olarak düzeltme eki uygulama, otomatik ölçeklendirme ve diğer yönetim görevleri.AKS provisions Kubernetes and exposes the Kubernetes API endpoints, but hosts and manages the Kubernetes control plane, performing automated upgrades, automated patching, autoscaling, and other management tasks. "Hizmet olarak Kubernetes API." olacak şekilde AKS düşünebilirsiniz.You can think of AKS as being "Kubernetes APIs as a service."

  • Service Fabric paketleme, dağıtma ve mikro hizmetleri yönetmek için bir dağıtılmış sistemler platformudur.Service Fabric is a distributed systems platform for packaging, deploying, and managing microservices. Mikro hizmetler kapsayıcılar, ikili yürütülebilir dosyalar veya olarak Service Fabric'e dağıtılabilir Reliable Services.Microservices can be deployed to Service Fabric as containers, as binary executables, or as Reliable Services. Reliable Services programlama modeli kullanarak, hizmetleri, doğrudan Service Fabric programlama sorgu rapor sistem durumu, sistem, yapılandırma ve kod değişiklikleri hakkında bildirim almak ve diğer hizmetleri bulmanıza API'leri kullanabilirsiniz.Using the Reliable Services programming model, services can directly use Service Fabric programming APIs to query the system, report health, receive notifications about configuration and code changes, and discover other services. Güçlü odağı kullanarak durum bilgisi olan hizmetler oluşturmaya odaklanmasıdır Service Fabric olan güvenilir koleksiyonlar.A key differentiation with Service Fabric is its strong focus on building stateful services using Reliable Collections.

  • Azure Container Service (ACS), üretime hazır DC/OS, Docker Swarm veya Kubernetes kümesi dağıtma olanak sağlayan bir Azure hizmetidir.Azure Container Service (ACS) is an Azure service that lets you deploy a production-ready DC/OS, Docker Swarm, or Kubernetes cluster.

    Not

    Kubernetes ACS tarafından karşın, AKS Kubernetes Azure üzerinde çalıştırmak için önerilir.Although Kubernetes is supported by ACS, we recommended AKS for running Kubernetes on Azure. AKS, Gelişmiş yönetim özelliklerini ve maliyet avantajları sağlar.AKS provides enhanced management capabilities and cost benefits.

KapsayıcılarContainers

Bazen aynı şeyi değilmiş gibi kişiler kapsayıcıları ve mikro hizmetler hakkında konuşun.Sometimes people talk about containers and microservices as if they were the same thing. True değil — kapsayıcılar, mikro hizmetler oluşturmak için ihtiyacınız olmayan — kapsayıcılar mikro hizmetler için özellikle ilgili gibi bazı avantajlar içerir:While that's not true — you don't need containers to build microservices — containers do have some benefits that are particularly relevant to microservices, such as:

  • Taşınabilirlik.Portability. Bir kapsayıcı görüntüsü kitaplıkları veya diğer bağımlılıkları yüklemeniz gerekmeden çalıştıran tek başına bir pakettir.A container image is a standalone package that runs without needing to install libraries or other dependencies. Bunları dağıtmak kolaylaştırır.That makes them easy to deploy. Kapsayıcıları kullanmaya ve daha fazla yükü işlemek için veya düğüm arızasına karşı kurtarmak için yeni örnekleri çalıştırabileceğinizi için hızlı bir şekilde durduruldu.Containers can be started and stopped quickly, so you can spin up new instances to handle more load or to recover from node failures.

  • Yoğunluk.Density. Kapsayıcılar, çünkü bunlar işletim sistemi kaynakları paylaşır çalıştıran bir sanal makine ile karşılaştırıldığında hafif nesnelerdir.Containers are lightweight compared with running a virtual machine, because they share OS resources. Bu, birden çok kapsayıcılarının uygulaması birçok küçük hizmetten oluşuyorsa, özellikle yararlı olan tek bir düğüm paketi mümkün kılar.That makes it possible to pack multiple containers onto a single node, which is especially useful when the application consists of many small services.

  • Kaynak yalıtımı.Resource isolation. Bellek ve kaçan bir işlem konak kaynaklarını tüketebilir değil emin olmaya yardım etmek bir kapsayıcı için kullanılabilir CPU miktarını sınırlayabilirsiniz.You can limit the amount of memory and CPU that is available to a container, which can help to ensure that a runaway process doesn't exhaust the host resources. Bkz: bölme perdesi düzeni daha fazla bilgi için.See the Bulkhead pattern for more information.

Sunucusuz (hizmet olarak işlevler)Serverless (Functions as a Service)

İle bir sunucusuz mimarisi, Vm'leri ya da sanal ağ altyapısını yönetmek yok.With a serverless architecture, you don't manage the VMs or the virtual network infrastructure. Bunun yerine, kodu ve kodun bir VM yerleştirme ve yürütme barındırma hizmeti tutamaçları dağıtın.Instead, you deploy code and the hosting service handles putting that code onto a VM and executing it. Bu yaklaşım, olay tabanlı Tetikleyicileri kullanarak eşgüdümlüdür küçük ayrıntılı işlevleri favor eğilimindedir.This approach tends to favor small granular functions that are coordinated using event-based triggers. Örneğin, bir sıra yerleştirilen bir ileti kuyruktan okuyan ve bu iletiyi işleyen bir işlev tetikleyebilir.For example, a message being placed onto a queue might trigger a function that reads from the queue and processes the message.

[Azure işlevleri] functions , HTTP isteklerini, Service Bus kuyrukları ve Event Hubs olayları dahil olmak üzere çeşitli işlevi tetikleyicilerini destekleyen bir sunucusuz işlem hizmetidir.Azure Functions is a serverless compute service that supports various function triggers, including HTTP requests, Service Bus queues, and Event Hubs events. Tam bir listesi için bkz. Azure işlevleri Tetikleyicileri ve bağlamaları kavramları.For a complete list, see Azure Functions triggers and bindings concepts. Ayrıca göz önünde bulundurun Azure Event Grid, yönetilen bir olay yönlendirme hizmetidir azure'da olduğu.Also consider Azure Event Grid, which is a managed event routing service in Azure.

Orchestrator ya da sunucusuz?Orchestrator or serverless?

Bir orchestrator yaklaşım ve sunucusuz bir yaklaşım arasında seçim yapılırken dikkate alınacak bazı faktörler aşağıda verilmiştir.Here are some factors to consider when choosing between an orchestrator approach and a serverless approach.

Yönetilebilirlik sunucusuz bir uygulama, tüm platform yönettiğinden yönetmek kolay, bilgi işlem kaynaklarını.Manageability A serverless application is easy to manage, because the platform manages all the of compute resources for you. Bir orchestrator soyutlayan bazı yönlerini yönetmek ve bir küme yapılandırma karşın, temel alınan sanal makinelerin tamamen gizlemez.While an orchestrator abstracts some aspects of managing and configuring a cluster, it does not completely hide the underlying VMs. Bir orchestrator ile Yük Dengeleme, CPU ve bellek kullanımı ve ağ gibi sorunlara dikkat etmeniz gerekir.With an orchestrator, you will need to think about issues such as load balancing, CPU and memory usage, and networking.

Esneklik ve Denetim.Flexibility and control. Bir orchestrator büyük ölçüde hizmetlerinizi ve kümeyi yönetme ve yapılandırma denetim sağlar.An orchestrator gives you a great deal of control over configuring and managing your services and the cluster. Karmaşıklık düşüş olur.The tradeoff is additional complexity. Bu ayrıntıları soyutlanır çünkü sunucusuz bir mimariyle bazı ve kontrol derecesi verin.With a serverless architecture, you give up some degree of control because these details are abstracted.

Taşınabilirlik.Portability. Burada listelenen Düzenleyicileri (Kubernetes, DC/OS, Docker Swarm ve Service Fabric) tüm şirket içi çalıştırabilirsiniz veya birden çok genel bulutlarda.All of the orchestrators listed here (Kubernetes, DC/OS, Docker Swarm, and Service Fabric) can run on-premises or in multiple public clouds.

Uygulama Tümleştirme.Application integration. Bu sunucusuz bir mimari kullanarak karmaşık bir uygulama oluşturmak için zor olabilir.It can be challenging to build a complex application using a serverless architecture. Azure'da bir seçenek kullanmaktır Azure Logic Apps Azure işlevleri bir dizi koordine etmek için.One option in Azure is to use Azure Logic Apps to coordinate a set of Azure Functions. Bu yaklaşımın bir örneği için bkz Azure Logic Apps ile tümleşen bir işlev oluşturma.For an example of this approach, see Create a function that integrates with Azure Logic Apps.

Maliyet.Cost. Bir orchestrator ile kümede çalışan sanal makineler için ödeme yaparsınız.With an orchestrator, you pay for the VMs that are running in the cluster. Sunucusuz bir uygulama ile birlikte yalnızca kullanılan gerçek işlem kaynakları için ödeme yaparsınız.With a serverless application, you pay only for the actual compute resources consumed. Her iki durumda da, depolama, veritabanları ve mesajlaşma Hizmetleri gibi ek hizmetlerin maliyet faktörü gerekir.In both cases, you need to factor in the cost of any additional services, such as storage, databases, and messaging services.

Ölçeklendirilebilirlik.Scalability. Otomatik olarak gelen olayların sayısına göre talebi karşılamak için azure işlevleri ölçeklendirir.Azure Functions scales automatically to meet demand, based on the number of incoming events. Bir orchestrator ile kümede çalışan hizmet örneklerinin sayısını artırarak ölçeği genişletebilirsiniz.With an orchestrator, you can scale out by increasing the number of service instances running in the cluster. Ayrıca, ek sanal makineler kümeye ekleyerek de ölçeklendirebilirsiniz.You can also scale by adding additional VMs to the cluster.

Başvuru uygulamamızda öncelikle Kubernetes kullanır, ancak Azure işlevleri bir hizmet, yani teslim geçmişi hizmet kullanmadı.Our reference implementation primarily uses Kubernetes, but we did use Azure Functions for one service, namely the Delivery History service. Azure işlevleri, olduğundan bu belirli bir hizmet için uygun olan bir olay temelli iş yüküdür.Azure Functions was a good fit for this particular service, because it's is an event-driven workload. Hizmet işlevi çağırmak için bir olay hub'ları tetikleyicisini kullanarak en az miktarda kod gerekli.By using an Event Hubs trigger to invoke the function, the service needed a minimal amount of code. Kubernetes kümesi dışında çalışan uçtan uca gecikme süresi, kullanıcı tarafından başlatılan işlemleri etkilemez için Ayrıca, teslim geçmişi hizmet ana iş akışının bir parçası değil.Also, the Delivery History service is not part of the main workflow, so running it outside of the Kubernetes cluster doesn't affect the end-to-end latency of user-initiated operations.