Web-Kuyruk-Çalışan mimari stiliWeb-Queue-Worker architecture style

Bu mimarinin temel bileşenleri, istemci isteklerine yanıt veren bir web ön ucu ile yoğun kaynak gerektiren görevleri, uzun çalışan iş akışlarını veya toplu işleri gerçekleştiren bir çalışandır.The core components of this architecture are a web front end that serves client requests, and a worker that performs resource-intensive tasks, long-running workflows, or batch jobs. Web ön ucu, çalışanla bir ileti kuyruğu üzerinden iletişim kurar.The web front end communicates with the worker through a message queue.

Web-kuyruk-çalışan mimari stili mantıksal diyagramı

Yaygın olarak bu mimariye eklenen diğer bileşenler şunlardır:Other components that are commonly incorporated into this architecture include:

  • Bir veya daha fazla veritabanı.One or more databases.
  • Hızlı okuma için veritabanından alınan değerlerin depolanacağı bir önbellek.A cache to store values from the database for quick reads.
  • Statik içerik sunmak için CDNCDN to serve static content
  • E-posta veya SMS hizmeti gibi uzak hizmetler.Remote services, such as email or SMS service. Bunlar genellikle üçüncü taraflarca sağlanır.Often these are provided by third parties.
  • Kimlik doğrulaması için kimlik sağlayıcısı.Identity provider for authentication.

Web ve çalışan bileşenleri durum bilgisine sahip değildir.The web and worker are both stateless. Oturum durumu dağıtılmış bir önbellekte depolanabilir.Session state can be stored in a distributed cache. Uzun süre çalışan işler çalışan tarafından zaman uyumsuz olarak gerçekleştirilir.Any long-running work is done asynchronously by the worker. Çalışan, kuyruğa gönderilen mesajlarla tetiklenebilir veya toplu işlem için bir zamanlamaya göre çalıştırılabilir.The worker can be triggered by messages on the queue, or run on a schedule for batch processing. Çalışan, isteğe bağlı bir bileşendir.The worker is an optional component. Uzun süre çalışan işlemler varsa çalışan kullanılmayabilir.If there are no long-running operations, the worker can be omitted.

Ön uç bir web API'den oluşabilir.The front end might consist of a web API. İstemci tarafında, web API AJAX çağrıları yapan tek sayfalı bir uygulama tarafından veya yerel bir istemci uygulaması tarafından kullanılabilir.On the client side, the web API can be consumed by a single-page application that makes AJAX calls, or by a native client application.

Bu mimarinin kullanılacağı durumlarWhen to use this architecture

Web-Kuyruk-Çalışan mimarisi genellikle yönetilen işlem hizmetleri (Azure App Service veya Azure Cloud Services) kullanılarak uygulanır.The Web-Queue-Worker architecture is typically implemented using managed compute services, either Azure App Service or Azure Cloud Services.

Aşağıdakiler için bu mimari stilini göz önünde bulundurun:Consider this architecture style for:

  • Göreceli olarak basit bir etki alanına sahip olan uygulamalar.Applications with a relatively simple domain.
  • Uzun süre çalışan iş akışlarına veya toplu işlemlere sahip olan uygulamalar.Applications with some long-running workflows or batch operations.
  • Hizmet olarak altyapı (IaaS) yerine yönetilen hizmetler kullanmak istediğiniz durumlar.When you want to use managed services, rather than infrastructure as a service (IaaS).

AvantajlarBenefits

  • Anlaşılması kolay olan, görece basit mimari.Relatively simple architecture that is easy to understand.
  • Dağıtımı ve yönetimi kolaydır.Easy to deploy and manage.
  • Görev ayrımı nettir.Clear separation of concerns.
  • Ön uç, zaman uyumsuz mesajlaşma ile çalışandan bağımsız hale getirilir.The front end is decoupled from the worker using asynchronous messaging.
  • Ön uç ve çalışan bağımsız olarak ölçeklendirilebilir.The front end and the worker can be scaled independently.

ZorluklarChallenges

  • Tasarıma dikkat edilmemesi durumunda, ön uç ve çalışan bakımı ve güncelleştirmesi zor olan büyük ve tek parça bileşenlere dönüşebilir.Without careful design, the front end and the worker can become large, monolithic components that are difficult to maintain and update.
  • Ön uç ve çalışan aynı veri şemalarını veya kod modüllerini kullanıyorsa gizli bağımlılıklar olabilir.There may be hidden dependencies, if the front end and worker share data schemas or code modules.

En iyi uygulamalarBest practices

Azure App Service’te Web-Kuyruk-ÇalışanWeb-Queue-Worker on Azure App Service

Bu bölümde, Azure App Service kullanan, önerilen bir Web-Kuyruk-Çalışan mimarisi açıklanmaktadır.This section describes a recommended Web-Queue-Worker architecture that uses Azure App Service.

Web-kuyruk-çalışan mimari stili fiziksel diyagramı

Ön uç bir Azure App Service web uygulaması olarak, çalışan ise bir WebJob olarak uygulanır.The front end is implemented as an Azure App Service web app, and the worker is implemented as a WebJob. Hem web uygulaması hem de WebJob, VM örnekleri sağlayan bir App Service planıyla ilişkilidir.The web app and the WebJob are both associated with an App Service plan that provides the VM instances.

Mesaj kuyruğu için Azure Service Bus veya Azure Depolama kuyruklarını kullanabilirsiniz.You can use either Azure Service Bus or Azure Storage queues for the message queue. (Diyagramda bir Azure depolama kuyruğu gösterilmektedir.)(The diagram shows an Azure Storage queue.)

Oturum durumu ve düşük gecikme süreli erişim gerektiren diğer veriler Azure Redis Cache tarafından depolanır.Azure Redis Cache stores session state and other data that needs low latency access.

Görüntüler, CSS ya da HTML gibi statik içeriklerin önbelleğe alınması için Azure CDN kullanılır.Azure CDN is used to cache static content such as images, CSS, or HTML.

Depolama için uygulamanızın gereksinimlerine en uygun depolama teknolojilerini seçin.For storage, choose the storage technologies that best fit the needs of the application. Birden çok depolama teknolojisi (çok yönlü kalıcılık) kullanabilirsiniz.You might use multiple storage technologies (polyglot persistence). Bu fikri göstermek için diyagramda Azure SQL Veritabanı ve Azure Cosmos DB gösterilmektedir.To illustrate this idea, the diagram shows Azure SQL Database and Azure Cosmos DB.

Daha ayrıntılı bilgi için bkz. App Service web uygulaması başvuru mimarisi.For more details, see App Service web application reference architecture.

Diğer konularAdditional considerations

  • Her işlemin çalışan ve kuyruk üzerinden depolamaya gitmesi gerekmez.Not every transaction has to go through the queue and worker to storage. Web ön ucu doğrudan basit okuma/yazma işlemleri gerçekleştirebilir.The web front end can perform simple read/write operations directly. Çalışanlar, yoğun kaynak gerektiren görevler veya uzun süre çalışan iş akışları için tasarlanmıştır.Workers are designed for resource-intensive tasks or long-running workflows. Bazı durumlarda çalışana gereksinim bile duymayabilirsiniz.In some cases, you might not need a worker at all.

  • VM örnek sayısının ölçeğini genişletmek için App Service’te yerleşik olarak sunulan otomatik ölçeklendirme özelliğini kullanın.Use the built-in autoscale feature of App Service to scale out the number of VM instances. Uygulama üzerindeki yük tahmin edilebilir düzenleri izliyorsa zamanlama tabanlı otomatik ölçeklendirme kullanın.If the load on the application follows predictable patterns, use schedule-based autoscale. Yükü tahmin edilebilir değilse, ölçüm tabanlı otomatik ölçeklendirme kurallarını kullanın.If the load is unpredictable, use metrics-based autoscaling rules.

  • Web uygulamasını ve WebJob’ı ayrı App Service planlarına yerleştirmeyi düşünün.Consider putting the web app and the WebJob into separate App Service plans. Bu şekilde, bunlar ayrı VM örneklerinde barındırılır ve bağımsız olarak ölçeklendirilebilir.That way, they are hosted on separate VM instances and can be scaled independently.

  • Üretim ve test için ayrı App Service planları kullanın.Use separate App Service plans for production and testing. Bunun yerine üretim ve test için aynı planı kullanırsanız, testleriniz üretim VM'lerinde çalıştırılır.Otherwise, if you use the same plan for production and testing, it means your tests are running on your production VMs.

  • Dağıtımları yönetmek için dağıtım yuvaları kullanın.Use deployment slots to manage deployments. Bu, önce güncel bir sürümü hazırlık yuvasına dağıtıp sonra yeni sürüme geçmenize imkan tanır.This lets you to deploy an updated version to a staging slot, then swap over to the new version. Ayrıca, güncelleştirmeyle ilgili bir sorun olması durumunda önceki sürüme dönmenize de imkan tanır.It also lets you swap back to the previous version, if there was a problem with the update.