Koordinasyon gereksinimini olabildiğince azaltmaMinimize coordination

Ölçeklenebilirlik elde etmek için uygulama hizmetleri arasında koordinasyon gereksinimini olabildiğince azaltınMinimize coordination between application services to achieve scalability

Çoğu bulut uygulaması; web ön uçları, veritabanları, iş süreçleri, raporlama ve analiz gibi birden fazla uygulama hizmetinden oluşur.Most cloud applications consist of multiple application services — web front ends, databases, business processes, reporting and analysis, and so on. Ölçeklenebilirlik ve güvenilirlik elde etmek için bu hizmetlerin her birini birden çok örnek üzerinde çalıştırmanız gerekir.To achieve scalability and reliability, each of those services should run on multiple instances.

İki örnek, paylaşılan bir durumu etkileyen eşzamanlı işlemler gerçekleştirmeye çalıştığında ne olur?What happens when two instances try to perform concurrent operations that affect some shared state? Bazı durumlarda, örneğin, ACID garantilerini korumak için düğümlerde koordinasyon olmalıdır.In some cases, there must be coordination across nodes, for example to preserve ACID guarantees. Bu diyagramda Node2, Node1 düğümünün bir veritabanı kilidini açmasını bekliyor:In this diagram, Node2 is waiting for Node1 to release a database lock:

Veritabanı kilit diyagramı

Koordinasyon, yatay ölçek avantajlarını sınırlar ve performans sorunları oluşturur.Coordination limits the benefits of horizontal scale and creates bottlenecks. Bu örnekte, siz uygulamanın ölçeğini genişletip daha fazla örnek ekledikçe artan bir kilit çakışması görüyorsunuz.In this example, as you scale out the application and add more instances, you'll see increased lock contention. En kötü durumda; ön uç örnekleri, zamanlarının çoğunu kilitler için bekleyerek geçirir.In the worst case, the front-end instances will spend most of their time waiting on locks.

"Kesinlikle bir kerelik" semantik, koordinasyonun sık kullanılan diğer bir kaynağıdır."Exactly once" semantics are another frequent source of coordination. Örneğin, bir siparişin kesinlikle bir kerelik işlenmesi gerekir.For example, an order must be processed exactly once. İki çalışan, yeni siparişleri dinliyor.Two workers are listening for new orders. Worker1, işleme için bir sipariş seçer.Worker1 picks up an order for processing. Uygulama, işin Worker2 tarafından çoğaltılmamasını ancak aynı zamanda, Worker1 kilitlenirse siparişin düşmemesini de sağlaması gerekir.The application must ensure that Worker2 doesn't duplicate the work, but also if Worker1 crashes, the order isn't dropped.

Koordinasyon diyagramı

Çalışanlar arasında koordinasyon sağlamak için Zamanlayıcı Aracısı Gözetmeni gibi bir düzeni kullanabilirsiniz, ancak bu durumda işin bölümlenmesi daha iyi bir yaklaşım olabilir.You can use a pattern such as Scheduler Agent Supervisor to coordinate between the workers, but in this case a better approach might be to partition the work. Her çalışana belirli bir kapsama (örneğin, fatura bölgesi) göre siparişler atanır.Each worker is assigned a certain range of orders (say, by billing region). Bir çalışanın kilitlenmesi durumunda, önceki örneğin kaldığı yerden yeni bir örnek devam eder ancak birden fazla örnek çakışmaz.If a worker crashes, a new instance picks up where the previous instance left off, but multiple instances aren't contending.

ÖnerilerRecommendations

Nihai tutarlılık yaklaşımını benimseyin.Embrace eventual consistency. Veriler dağıtıldığında güçlü tutarlılık garantilerinin uygulanması için koordinasyon gerekir.When data is distributed, it takes coordination to enforce strong consistency guarantees. Örneğin, bir işlemin, iki veritabanını güncelleştirdiğini varsayalım.For example, suppose an operation updates two databases. Bunu tek bir işlem kapsamına almak yerine sistemin bir hatadan sonra işlemi mantıksal olarak geri almak için Telafi İşlemi düzenini kullanarak nihai tutarlılığa olanak tanıyabilmesi daha uygundur.Instead of putting it into a single transaction scope, it's better if the system can accommodate eventual consistency, perhaps by using the Compensating Transaction pattern to logically roll back after a failure.

Durumu eşitlemek için etki alanı olaylarını kullanın.Use domain events to synchronize state. Etki alanı olayı, etki alanı içinde önemli bir durum ortaya çıktığında bunu kaydeden bir olaydır.A domain event is an event that records when something happens that has significance within the domain. İlgili hizmetler, birden çok hizmet arasında koordinasyon sağlamak için genel bir işlem kullanmak yerine söz konusu olayı dinleyebilir.Interested services can listen for the event, rather than using a global transaction to coordinate across multiple services. Bu yaklaşımın kullanılması durumunda sistemin nihai tutarlılığa tolerans göstermesi gerekir (bir önceki öğeye bakın).If this approach is used, the system must tolerate eventual consistency (see previous item).

CQRS ve olay kaynağını belirleme gibi düzenleri deneyin.Consider patterns such as CQRS and event sourcing. Bu iki düzen, okuma iş yükleri ile yazma iş yükleri arasındaki çakışmanın azaltılmasına yardımcı olabilir.These two patterns can help to reduce contention between read workloads and write workloads.

  • CQRS düzeni, okuma işlemlerini yazma işlemlerinden ayırır.The CQRS pattern separates read operations from write operations. Bazı uygulamalarda okuma verileri, yazma verilerinden fiziksel olarak ayrılır.In some implementations, the read data is physically separated from the write data.

  • Olay Kaynağını Belirleme düzeninde durum değişiklikleri yalnızca ekleme yapılabilen bir veri deposuna bir dizi olay olarak kaydedilir.In the Event Sourcing pattern, state changes are recorded as a series of events to an append-only data store. Akışa olay eklemek otomatik bir işlemdir ve mümkün olduğunca az kilitleme gerektirir.Appending an event to the stream is an atomic operation, requiring minimal locking.

Bu iki düzen birbirini tamamlar.These two patterns complement each other. CQRS deki yalnızca yazılabilen depo, olay kaynağı belirleme düzenini kullanıyorsa salt okunur depo aynı olayları kullanarak geçerli durumun sorgular için en iyi duruma getirilmiş okunabilir bir ekran görüntüsünü oluşturabilir.If the write-only store in CQRS uses event sourcing, the read-only store can listen for the same events to create a readable snapshot of the current state, optimized for queries. Ancak CQRS veya olay kaynağını belirleme düzenini kullanmadan önce bu yaklaşımın zorluklarını dikkate alın.Before adopting CQRS or event sourcing, however, be aware of the challenges of this approach. Daha fazla bilgi için bkz. CQRS mimarisi stili.For more information, see CQRS architecture style.

Verileri bölümleme.Partition data. Tüm verilerinizi birden çok uygulama hizmetinde paylaşılan bir veri şemasına eklemekten kaçının.Avoid putting all of your data into one data schema that is shared across many application services. Mikro hizmetler mimarisi her hizmeti kendi veri deposundan sorumlu hale getirerek bu ilkeyi zorlar.A microservices architecture enforces this principle by making each service responsible for its own data store. Bir parçaya yazan bir hizmet, farklı bir parçaya yazan bir hizmeti etkilemediğinden, tek bir veritabanı içinde verilerin parçalara ayrılması eşzamanlılığı artırabilir.Within a single database, partitioning the data into shards can improve concurrency, because a service writing to one shard does not affect a service writing to a different shard.

Bir kere etkili olan işlemler tasarlayın.Design idempotent operations. Mümkünse, işlemleri bir kere etkili olacak şekilde tasarlayın.When possible, design operations to be idempotent. Böylece bunlar, en az bir kez semantik kullanılarak işlenebilir.That way, they can be handled using at-least-once semantics. Örneğin, iş öğelerini bir kuyruğa koyabilirsiniz.For example, you can put work items on a queue. Bir çalışanın, işlemin ortasında kilitlenmesi durumunda iş öğesini başka bir çalışanın seçmesi yeterlidir.If a worker crashes in the middle of an operation, another worker simply picks up the work item.

Zaman uyumsuz paralel işlemeyi kullanın.Use asynchronous parallel processing. Bir işlem için zaman uyumsuz olarak (uzak hizmet çağrıları gibi) gerçekleştirilen birden çok adım gerekiyorsa bunları paralel olarak çağırıp sonuçları toplayabilirsiniz.If an operation requires multiple steps that are performed asynchronously (such as remote service calls), you might be able to call them in parallel, and then aggregate the results. Bu yaklaşım, adımlardan hiçbirinin bir önceki adıma ait sonuçlara bağımlı olmadığını varsayar.This approach assumes that each step does not depend on the results of the previous step.

Mümkün olduğunca iyimser eşzamanlılığı kullanın.Use optimistic concurrency when possible. Kötümser eşzamanlılık denetimi, çakışmaları önlemek için veritabanı kilitlerini kullanır.Pessimistic concurrency control uses database locks to prevent conflicts. Bu, yetersiz bir performans düzeyine neden olabilir ve kullanılabilirliği azaltabilir.This can cause poor performance and reduce availability. İyimser eşzamanlılık denetimi ile her işlem, verilerin bir kopyasını veya anlık görüntüsünü değiştirir.With optimistic concurrency control, each transaction modifies a copy or snapshot of the data. İşlem tamamlandığında veritabanı altyapısı, işlemi doğrular ve veritabanı tutarlılığını etkileyecek tüm işlemleri reddeder.When the transaction is committed, the database engine validates the transaction and rejects any transactions that would affect database consistency.

Azure SQL Veritabanı ve SQL Server desteği için anlık görüntü yalıtımı ile iyimser eşzamanlılık.Azure SQL Database and SQL Server support optimistic concurrency through snapshot isolation. Bazı Azure depolama hizmetleri, Azure Cosmos DB ve Azure Depolama da dahil olmak üzere ETag’ler kullanılarak iyimser eşzamanlama sağlanmasını destekler.Some Azure storage services support optimistic concurrency through the use of Etags, including Azure Cosmos DB and Azure Storage.

MapReduce’u veya diğer paralel, dağıtılmış algoritmaları deneyin.Consider MapReduce or other parallel, distributed algorithms. Verilere ve gerçekleştirilecek işin türüne göre; işi, paralel olarak çalışan birden fazla düğümün gerçekleştirebileceği bağımsız görevlere bölebilirsiniz.Depending on the data and type of work to be performed, you may be able to split the work into independent tasks that can be performed by multiple nodes working in parallel. Bkz. Büyük işlem mimarisi stili.See Big compute architecture style.

Koordinasyon için öncü seçimi kullanın.Use leader election for coordination. İşlemleri koordine etmeniz gerektiği durumlarda koordinatörün uygulamadaki tek hata noktası haline gelmediğinden emin olun.In cases where you need to coordinate operations, make sure the coordinator does not become a single point of failure in the application. Öncü Seçimi düzeni kullanıldığında her zaman tek bir örnek öncüdür ve koordinatör işlevi görür.Using the Leader Election pattern, one instance is the leader at any time, and acts as the coordinator. Öncü başarısız olursa öncü olacak yeni bir örnek seçilir.If the leader fails, a new instance is elected to be the leader.