Koreografi düzeni

  • Makale
  • Okumak için 6 dakika

Sistemin her bileşeninin merkezi bir denetim noktasına güvenmek yerine bir iş işleminin iş akışıyla ilgili karar alma sürecine katılmalarını sağlar.

Bağlam ve sorun

Mikro hizmet mimarisinde genellikle bulut tabanlı bir uygulama, bir iş işlemini 1-2 4 saat boyunca işlemeye devam etmek için birlikte çalışmakta olan birkaç küçük hizmet olarak ayrılır. Hizmetler arasındaki bağlantıların daha düşük bir şekilde kapsanarak her hizmet tek bir iş işlemiyle sorumludur. Bazı avantajlar arasında daha hızlı geliştirme, daha küçük kod tabanı ve ölçeklenebilirlik vardır. Ancak verimli ve ölçeklenebilir bir iş akışı tasarlamak zor olabilir ve genellikle karmaşık hizmetler arası iletişim gerektirir.

Hizmetler iyi tanımlanmış API'leri kullanarak birbirleriyle iletişim kurar. Tek bir iş işlemi bile tüm hizmetler arasında birden çok noktadan noktaya çağrıya neden olabilir. İletişim için yaygın bir desen, orchestrator olarak hareket edecek merkezi bir hizmet kullanmaktır. Tüm gelen istekleri onaylar ve işlemleri ilgili hizmetlere devreder. Bunu yaparken, tüm iş işlemlerinin iş akışını da yönetir. Her hizmet yalnızca bir işlemi tamamlar ve genel iş akışının farkında değildir.

Orchestrator düzeni hizmetler arasındaki noktadan noktaya iletişimi azaltır, ancak orchestrator ile iş işleminin iş sürecine katılan diğer hizmetler arasındaki sıkı bağlantı nedeniyle bazı dezavantajları vardır. Görevleri sırayla yürütmek için, orchestrator'ın bu hizmetlerin sorumlulukları hakkında etki alanı bilgisi olması gerekir. Hizmetleri eklemek veya kaldırmak için mevcut mantık bozacak ve iletişim yolunun bölümlerini yeniden kablola eklemeniz gerekir. İş akışını yapılandırabilir, iyi tasarlanmış bir orchestrator ile hizmetleri kolayca ekleyebilir veya kaldırabilirsiniz, ancak böyle bir uygulama karmaşıktır ve bakımı zordur.

Merkezi bir orchestrator kullanarak istek işleme

Çözüm

Merkezi bir düzenleyiciye bağlı olmak yerine bir iş işleminin ne zaman ve nasıl işleneceğini her hizmetin belirlemesine izin verin.

Koreografi uygulamanın bir yolu, iş operasyonlarını koordine etmek için zaman uyumsuz mesajlaşma desenini kullanmaktır.

Choreographer kullanarak istek işleme

İstemci isteği iletileri bir ileti kuyruğuna yayımlar. İletiler geldiğinde, bu iletiyle ilgilenen abonelere veya hizmetlere gönderilir. Abone olunan her hizmet, işlemi ileti tarafından belirtilen şekilde yapar ve ileti kuyruğuna başarılı veya başarısız bir şekilde yanıt verir. Başarılı olması durumunda, başka bir hizmetin gerekirse iş akışına devam etmek için bir iletiyi aynı kuyruğa veya farklı bir ileti kuyruğuna geri gönderebilirsiniz. Bir işlem başarısız olursa, ileti veri verilesi bu işlemi yeniden sınlar.

Bu şekilde hizmetler, bir orchestrator'a bağımlı olmadan veya aralarında doğrudan iletişim olmadan iş akışının koreografı sağlar.

Noktadan noktaya iletişim olmadığınız için bu düzen hizmetler arasındaki bağlantının azaltılmasına yardımcı olur. Ayrıca, tüm işlemlerle başa çıkarmak zorunda olduğunda, orchestrator'ın neden olduğu performans sorunlarını da kaldırabilir.

Bu düzenin kullanılacağı durumlar

Sık sık yeni hizmetler güncelleştirmeyi, kaldırmayı veya eklemeyi bekliyorsanız koreografi desenini kullanın. Uygulamanın tamamı daha az çaba ve mevcut hizmetlerde minimum kesinti ile değiştirilebilir.

Merkezi orchestrator'da performans sorunlarıyla karşııyorsanız bu düzeni göz önünde bulundurabilirsiniz.

Bu düzen, tüm hizmetlerin kısa süreli veya olay odaklı olduğu sunucusuz mimari için doğal bir modeldir. Hizmetler bir olay nedeniyle doyma, kendi görevini yapma ve görev tamamlandığında kaldırılabilir.

Sorunlar ve dikkat edilmesi gerekenler

Orchestrator'ın merkezi olmayan bir şekilde yönetilmesi, iş akışını yönetme sırasında soruna neden olabilir.

Bir hizmet bir iş işlemini tamamlayamezse, bu hatadan kurtarmak zor olabilir. Bunun bir yolu, hizmetin bir olayı işaret ederek başarısız olduğunu belirterek bunu belirtmektir. Bu başarısız olaylara abone olan başka bir hizmet, bir istekteki başarılı işlemleri geri almak için telafi işlemleri uygulama gibi gerekli eylemleri gerçekleştirmektedir. Başarısız hizmet ayrıca hata için bir olay başlatamaz. Bu durumda, bu işlemi bir hata olarak tanımak için yeniden deneme ve veya zaman out mekanizması kullanmayı göz önünde bulundurabilirsiniz. Örnek için Örnek bölümüne bakın.

Bağımsız iş operasyonlarını paralel olarak işlemeye yönelik bir iş akışı uygulamak kolaydır. Tek bir ileti veri verisi kullanabilirsiniz. Ancak, koreografinin bir dizide gerçekleşmesi gereken iş akışı karmaşık hale gelebilir. Örneğin, C Hizmeti yalnızca A Hizmeti ve B Hizmeti işlemlerini başarıyla tamamlandıktan sonra işlemi başlatabilirsiniz. Yaklaşımlardan biri, iletileri gerekli sırayla alan birden çok ileti verisi elde etmektir. Daha fazla bilgi için Örnek bölümüne bakın.

Hizmet sayısı hızla artarsa koreografi düzeni bir zorluk haline gelir. Çok sayıda bağımsız hareketli parça olduğu için hizmetler arasındaki iş akışı karmaşık hale geliyor. Ayrıca, dağıtılmış izleme zor hale gelir.

Orchestrator, iş akışının kullanılabilirlik durumunu merkezi olarak yönetir ve tek hata noktası haline gelir. Öte yandan, koreografi için rol tüm hizmetler arasında dağıtılır ve dayanıklılık daha az sağlam hale gelir.

Her hizmet yalnızca kendi işlemiyle değil aynı zamanda iş akışıyla da sorumludur. Bu sorumluluk, hizmet için zahmetli olabilir ve uygulanması zor olabilir. Gerekirse isteğin uygun bir şekilde sonlandırılmaları için her hizmetin geçici, geçici olmayan ve zaman dışı hataları yeniden denemesi gerekir. Ayrıca, diğer hizmetlerin uygun şekilde hareket etmek için hizmetin başarı veya başarısızlıkla iletişim kurma konusunda özenli olması gerekir.

Örnek

Bu örnekte İnsansız Hava Aracı ile Teslimat uygulamasıyla koreografi deseni yer amaktadır. Bir istemci teslim alma isteğinda olduğunda, uygulama bir insansız hava aracı atar ve istemciye bilgi sağlar.

GitHub logosu Bu desene örnek olarak GitHub.

Otomatik olarak oluşturulan bir harita açıklamasına yakın bir konum

Tek bir istemci iş işlemi için üç ayrı iş işlemi gerekir: paket oluşturma veya güncelleştirme, paketi teslim etmek için insansız hava aracı atama ve teslim durumunu denetleme. Bu işlemler üç mikro hizmet tarafından gerçekleştirilir: Paket, İnsansız Hava Aracı Zamanlayıcı ve Teslimat hizmetleri. Hizmetler, merkezi bir orchestrator yerine mesajlaşmayı kullanarak istek üzerinde işbirliği ve koordinasyon sağlar.

Tasarım

İş işlemi, birden çok atlama aracılığıyla bir dizi olarak işlenir. Her atlamada bir ileti veri verisi ve ilgili iş hizmeti vardır.

bir istemci bir HTTP uç noktası üzerinden teslim isteği gönderdiğinde, Veri Alımı hizmeti bu isteği alır, bir işlem olayı gönderir ve bir ileti veri veri yoluyla gönderir. Bus, abone olunan iş hizmetini çağırır ve olayı bir POST isteğinde gönderir. Olayı aldıktan sonra, iş hizmeti işlemi başarıyla, başarısızlıkla tamamlar veya istek zaman zaman uzamaz. Başarılı olursa, hizmet veri yolunda Tamam durum koduyla yanıt verir, yeni bir işlem olayı gönderir ve sonraki atlamanın ileti veri yolunda gönderir. Bir hata veya zaman kesintisi durumunda hizmet, badRequest kodunu özgün POST isteğini gönderen ileti veri yollus'a göndererek başarısız olduğunu raporlar. İleti veri verilesi, yeniden deneme ilkesine göre işlemi yeniden denentir. Bu süre dolduktan sonra ileti veri verilesi başarısız işlemi bayrakla gösterir ve isteğin tamamının daha fazla işlemesi durur.

Bu iş akışı isteğin tamamı işlenene kadar devam eder.

Tasarım, iş işleminin tamamını işlemesi için birden çok ileti veri verisi kullanır. Microsoft Azure Event Grid hizmeti sağlar. Uygulama, aynı podda Azure Kubernetes Service kapsayıcısı olan bir Azure Kubernetes Service (AKS)kümesinde dağıtılır. Bir kapsayıcı, bir iş hizmeti Event Grid ile etkileşime geçen büyükelçiyi çalıştırır. Aynı podda iki kapsayıcıya sahip olan yaklaşım, performansı ve ölçeklenebilirliği artırır. Büyükelçi ve iş hizmeti aynı ağı paylaşarak düşük gecikme süresine ve yüksek aktarım hızına olanak sağlar.

Birden çok çabaya neden olan yeniden deneme işlemlerinin basamaklı olarak yeniden denenmelerini önlemek Event Grid yalnızca iş hizmeti yerine işlemi yeniden denemez. Bir ileti göndererek başarısız bir isteği ileti kuyruğuna (DLQ) gönderir.

Yeniden deneme işlemlerinin yinelenen kaynaklara neden olduğundan emin olmak için iş hizmetleri her zaman aynı gücü kullanır. Örneğin Paket hizmeti, veri deposuna veri eklemek için upsert işlemlerini kullanır.

Örnek, tüm hizmetler ve farklı atlamalar arasındaki çağrıların arasında ilişki oluşturmak için özel Event Grid uygulanır.

Tüm iş hizmetleri arasındaki koreografi desenini gösteren bir kod örneği burada veremektedir. İnsansız Hava Aracı ile Teslimat uygulaması işlemlerinin iş akışını gösterir. Daha fazla bilgi için özel durum işleme ve günlüğe kaydetme kodu kaldırıldı.

[HttpPost]
[Route("/api/[controller]/operation")]
[ProducesResponseType(typeof(void), 200)]
[ProducesResponseType(typeof(void), 400)]
[ProducesResponseType(typeof(void), 500)]

public async Task<IActionResult> Post([FromBody] EventGridEvent[] events)
{

   if (events == null)
   {
       return BadRequest("No Event for Choreography");
   }

   foreach(var e in events)
   {

        List<EventGridEvent> listEvents = new List<EventGridEvent>();
        e.Topic = eventRepository.GetTopic();
        e.EventTime = DateTime.Now;
        switch (e.EventType)
        {
            case Operations.ChoreographyOperation.ScheduleDelivery:
            {
                var packageGen = await packageServiceCaller.UpsertPackageAsync(delivery.PackageInfo).ConfigureAwait(false);
                if (packageGen is null)
                {
                    //BadRequest allows the event to be reprocessed by Event Grid
                    return BadRequest("Package creation failed.");
                }

                //we set the event type to the next choreography step
                e.EventType = Operations.ChoreographyOperation.CreatePackage;
                listEvents.Add(e);
                await eventRepository.SendEventAsync(listEvents);
                return Ok("Created Package Completed");
            }
            case Operations.ChoreographyOperation.CreatePackage:
            {
                var droneId = await droneSchedulerServiceCaller.GetDroneIdAsync(delivery).ConfigureAwait(false);
                if (droneId is null)
                {
                    //BadRequest allows the event to be reprocessed by Event Grid
                    return BadRequest("could not get a drone id");
                }
                e.Subject = droneId;
                e.EventType = Operations.ChoreographyOperation.GetDrone;
                listEvents.Add(e);
                await eventRepository.SendEventAsync(listEvents);
                return Ok("Drone Completed");
            }
            case Operations.ChoreographyOperation.GetDrone:
            {
                var deliverySchedule = await deliveryServiceCaller.ScheduleDeliveryAsync(delivery, e.Subject);
                return Ok("Delivery Completed");
            }
            return BadRequest();
    }
}

Koreografi tasarımında bu desenleri göz önünde bulundurarak.