Mikro hizmetler için Interservice iletişimi tasarlama

Mikro hizmetler arasındaki iletişimin etkili ve dayanıklı olması gerekir. Tek bir iş etkinliğini tamamlamaya yönelik çok sayıda küçük hizmet sayesinde bu bir sorun olabilir. Bu makalede, zaman uyumsuz mesajlaşma ve zaman uyumlu API 'Ler arasındaki avantajları inceleyeceğiz. Daha sonra dayanıklı bir Interservice iletişimi tasarlama konusundaki bazı güçlükleri inceleyeceğiz.

Zorluklar

Hizmetten hizmete iletişimden kaynaklanan önemli güçlüklerden bazıları aşağıda verilmiştir. Bu makalenin ilerleyen kısımlarında açıklanan hizmet kafesleri, bu güçlüklerin çoğunu işleyecek şekilde tasarlanmıştır.

Dayanıklılık. Belirli bir mikro hizmetin onlarca ya da yüzlerce örneği olabilir. Bir örnek herhangi bir sayıda nedenden dolayı başarısız olabilir. Donanım arızası veya VM yeniden başlatma gibi düğüm düzeyinde bir hata olabilir. Bir örnek kilitlenebilir veya isteklerle başa çıkabilir ve yeni istekleri işleyemeyebilir. Bu olaylardan herhangi biri ağ çağrısının başarısız olmasına neden olabilir. Hizmetten hizmete ağ aramalarını daha dayanıklı hale getirmenize yardımcı olabilecek iki tasarım deseni vardır:

• Yeniden deneyin. Bir ağ çağrısı, kendi kendine giden geçici bir hata nedeniyle başarısız olabilir. Başarısız olmak yerine, çağıran genellikle işlemi belirli sayıda kez yeniden dener veya yapılandırılmış bir zaman aşımı süresi sona erdiğinde yeniden dener. Ancak, bir işlem ıdempotent değilse, yeniden denemeler istenmeyen yan etkilere neden olabilir. Özgün çağrı başarılı olur, ancak çağrı hiçbir şekilde yanıt vermez. Çağıran yeniden denemeler yaparsanız, işlem iki kez çağrılabilir. Genellikle, POST veya PATCH yöntemlerini yeniden denemek güvenli değildir, çünkü bunlar ıdempotent olarak garanti edilmez.

• Devre kesici. Bekleyen istekler kuyrukta biriktikçe, çok fazla başarısız istek soruna neden olabilir. Bu engellenen isteklerde bellek, iş parçacıkları, veritabanı bağlantıları ve benzeri önemli sistem kaynakları bulunabilir ve bu durum da zincirleme hatalara neden olabilir. Devre kesici stili, bir hizmetin başarısız olma olasılığı olan bir işlemi tekrar tekrar denemesinin önlemesine engel olabilir.

Yük Dengeleme. "A" hizmeti "B" hizmetini çağırdığında, istek "B" hizmetinin çalışan bir örneğine ulaşmalıdır. Kubernetes 'te Service kaynak türü, bir grup düğüm için kararlı BIR IP adresi sağlar. Hizmetin IP adresine olan ağ trafiği, iptable kuralları aracılığıyla Pod 'a iletilir. Varsayılan olarak, rastgele bir pod seçilir. Bir hizmet ağı (aşağıya bakın), gözlemlenen gecikme süresine veya diğer ölçümlere göre daha akıllı Yük Dengeleme algoritmaları sağlayabilir.

Dağıtılmış izleme. Tek bir işlem, birden fazla hizmete yayılabilir. Bu, sistemin genel performansını ve sistem durumunu izlemeyi zorlaştırır. Her hizmet, günlükleri ve ölçümleri bir araya getirmenin bir yolu olmadan bile oluşturuyor olsa da, bunların sınırlı kullanımı vardır. Günlüğe kaydetme ve izleme makalesi, dağıtılmış izleme hakkında daha fazla bilgi sunuyor, ancak burada bir zorluk duyuyoruz.

Hizmet sürümü oluşturma. Bir ekip, bir hizmetin yeni bir sürümünü dağıttığında, bunlara bağımlı olan diğer hizmetleri veya dış istemcileri bozmaktan kaçınmalıdır. Ayrıca, bir hizmetin birden çok sürümünü yan yana çalıştırmak ve istekleri belirli bir sürüme yönlendirmek isteyebilirsiniz. Bu sorunla ilgili daha fazla bilgi için bkz. API sürüm oluşturma .

TLS şifreleme ve KARŞıLıKLı TLS kimlik doğrulaması. Güvenlik nedenleriyle, TLS ile hizmetler arasında trafiği şifrelemek ve arayanların kimliğini doğrulamak için karşılıklı TLS kimlik doğrulamasını kullanmak isteyebilirsiniz.

Zaman uyumlu ve zaman uyumsuz mesajlaşma

Mikro hizmetlerin diğer mikro hizmetlerle iletişim kurmak için kullanabileceği iki temel ileti deseni vardır.

1. Zaman uyumlu iletişim. Bu düzende, bir hizmet, HTTP veya gRPC gibi bir protokol kullanarak başka bir hizmetin sunduğu bir API 'yi çağırır. Çağıran alıcıdan yanıt beklediği için bu seçenek, zaman uyumlu bir mesajlaşma modelidir.

2. Zaman uyumsuz ileti geçiliyor. Bu düzende, bir hizmet yanıt beklemeden ileti gönderir ve bir veya daha fazla hizmet iletiyi zaman uyumsuz olarak işler.

Zaman uyumsuz g/ç ve zaman uyumsuz protokol arasında ayrım yapmak önemlidir. Zaman uyumsuz g/ç, g/ç tamamlanırken çağıran iş parçacığının engellenmediği anlamına gelir. Bu, performans açısından önemlidir, ancak mimari açısından bir uygulama ayrıntısıyla yapılır. Zaman uyumsuz protokol, gönderenin yanıt bekmeyeceği anlamına gelir. Http istemcisi bir istek gönderdiğinde zaman uyumsuz g/ç kullanabilir olsa bile, HTTP zaman uyumlu bir protokoldür.

Her bir düzende bir denge vardır. İstek/yanıt iyi anlaşılmış bir paradigdığı için bir API tasarlamak, bir mesajlaşma sistemi tasarlamadan daha doğal olabilir. Ancak, zaman uyumsuz mesajlaşma, mikro hizmetler mimarisinde yararlı olabilecek bazı avantajlar sunar:

• Daha az kuponu. İleti göndericisinin tüketici hakkında bilgi sahibi olması gerekmez.

• Birden çok abone. Bir yayın/alt model kullanarak, birden çok tüketici olay almak için abone olabilir. Bkz. olay odaklı mimari stili.

• Hata yalıtımı. Tüketici başarısız olursa, gönderici ileti gönderebilmeye devam edebilir. Bu iletiler, tüketici kurtarıldığında alınacaktır. Bu özellik özellikle bir mikro hizmet mimarisinde yararlı olduğundan, her hizmetin kendi yaşam döngüsü vardır. Bir hizmet kullanılamaz hale gelebilir veya belirli bir zamanda daha yeni bir sürümle değiştirilebilir. Zaman uyumsuz mesajlaşma, zaman aralıklı kapalı kalma süresini işleyebilir. Diğer yandan zaman uyumlu API 'Ler, aşağı akış hizmetinin kullanılabilir olmasını veya işlemin başarısız olmasını gerektirir.

• Yanıt verme. Aşağı akış hizmeti, aşağı akış Hizmetleri beklemez durumunda daha hızlı yanıt verebilir. Bu, özellikle bir mikro hizmet mimarisinde yararlı olur. Hizmet bağımlılıklarının zinciri varsa (a çağrısı B, C çağrısı, vb.), zaman uyumlu çağrıların beklenmesi kabul edilemez gecikme süresi ekleyebilir.

• Yük Dengeleme. Bir kuyruk iş yükünü dengelemenize yönelik bir arabellek görevi görebilir, böylece alıcıların iletileri kendi ücretlerinde işleyebilir.

• Iş akışları. Kuyruklar, iş akışındaki her adımdan sonra iletiye işaret ederek bir iş akışını yönetmek için kullanılabilir.

Ancak, zaman uyumsuz mesajlaşma 'yı etkin bir şekilde kullanmaya yönelik bazı sorunlar da vardır.

• İleti altyapısı ilebağlantısı. Belirli bir mesajlaşma altyapısının kullanılması, bu altyapıyla sıkı bir şekilde eşlenmesine neden olabilir. Daha sonra başka bir mesajlaşma altyapısına geçmek zor olacaktır.

• Gecikme süresi. İleti kuyrukları doldurultuğunda bir işlem için uçtan uca gecikme süresi yüksek olabilir.

• Maliyet. Yüksek Through, mesajlaşma altyapısının parasal maliyeti önemli olabilir.

• Karmaşıklık. Zaman uyumsuz mesajlaşma işleme, önemsiz bir görev değildir. Örneğin, yinelenen iletileri ya da çoğaltma yaparak veya Operations ıdempotent yaparak işlemeniz gerekir. Ayrıca, zaman uyumsuz mesajlaşma kullanarak istek-yanıt semantiğini uygulamak da zordur. Yanıt göndermek için, başka bir kuyruğa ve istek ve yanıt iletilerini ilişkilendirmek için bir yol gerekir.

• İşleme hızı. İletiler sıra semantiğinigerektiriyorsa, kuyruk sistemde performans sorunlarına yol açabilir. Her ileti en az bir kuyruk işlemi ve bir sıra çıkarma işlemi gerektirir. Üstelik, sıra semantiği genellikle mesajlaşma altyapısının içinde bazı tür kilitleme gerektirir. Sıra yönetilen bir hizmetse, sıranın kümenin sanal ağı dışında olması nedeniyle ek gecikme olabilir. İletileri toplu olarak oluşturarak bu sorunları azaltabilirsiniz, ancak kodu karmaşıklaştırın. İletiler sıra semantiği gerektirmiyorsa, kuyruk yerine bir olay akışı kullanabilirsiniz. Daha fazla bilgi için bkz. Olay odaklı mimari stili.

İnsansız Hava Aracı ile Teslimat: Mesajlaşma desenlerini seçme

Geliştirme ekibi, bu konuları göz önünde bulundurarak İnsansız Hava Aracı ile Teslimat uygulaması için aşağıdaki tasarım seçimlerini yaptı

• Ingestion hizmeti, istemci uygulamalarının REST API, güncelleştirmek veya iptal etmek için kullanabileceği genel bir hizmet sunar.

• Veri Alımı hizmeti, Event Hubs zamanlayıcı hizmetine zaman uyumsuz iletiler göndermek için Event Hubs hizmetini kullanır. Zaman uyumsuz iletiler, veri alımı için gereken yük dengelemeyi uygulamak için gereklidir.

• Hesap, Teslim, Paket, İnsansız Hava Aracı ve Üçüncü Taraf Taşıma hizmetlerinin hepsi dahili REST API'lerini ortaya çıkarır. Scheduler hizmeti bir kullanıcı isteği yapmak için bu API'leri çağırıyor. Zaman uyumlu API'leri kullanmanın nedenlerinden biri, Zamanlayıcı'nın aşağı akış hizmetlerinin her biri için bir yanıt almak zorunda olmasıdır. Aşağı akış hizmetlerden herhangi birsinde hata, tüm işlem başarısız olduğu anlamına gelir. Ancak olası bir sorun, arka uç hizmetleri çağrılarak ortaya konu olan gecikme süresidir.

• Herhangi bir aşağı akış hizmeti geçişsiz bir hataya sahipse, tüm işlem başarısız olarak işaretlenir. Bu durumu işlemek için Zamanlayıcı hizmeti, Gözetmen'in telafi işlemleri zamanlaması için Gözetmen'e zaman uyumsuz bir ileti gönderir.

• Teslim hizmeti, istemcilerin teslim durumunu almak için kullanabileceği genel bir API'yi gösterir. API ağ geçidi makalesinde,bir API ağ geçidinin temel alınan hizmetleri istemciden nasıl gizleyebilirsiniz? bu nedenle istemcinin hangi hizmetlerin hangi API'leri ortaya çıkartır?

• İnsansız hava aracı uçuştayken İnsansız Hava Aracı hizmeti, insansız hava aracının geçerli konumunu ve durumunu içeren olayları gönderir. Teslim hizmeti, bir teslimatın durumunu izlemek için bu olayları dinler.

• Teslimin durumu değişirse, Teslim hizmeti veya gibi bir teslim durumu olayı DeliveryCreatedDeliveryCompleted gönderir. Herhangi bir hizmet bu olaylara abone olabilir. Geçerli tasarımda tek abone Teslim Geçmişi hizmetidir, ancak daha sonra başka aboneler de olabilir. Örneğin, olaylar gerçek zamanlı bir analiz hizmetine gidebilir. Scheduler'ın yanıt beklemesi gerekmaysa da, daha fazla abone eklemek ana iş akışı yolunu etkilemez.

Teslimat durumu olaylarının insansız hava aracı konumu olaylarından türetilenlere dikkat olun. Örneğin bir insansız hava aracı bir teslimat konuma ulaştığında ve paketi teslim etmek için teslim hizmeti bunu DeliveryCompleted olayına çevirir. Bu, etki alanı modelleri açısından bir düşünce örneğidir. Daha önce açıklandığı gibi İnsansız Hava Aracı Yönetimi ayrı bir sınırlayıcı bağlamda yer almaktadır. İnsansız hava aracı olayları bir insansız hava aracının fiziksel konumunu iletir. Öte yandan teslim olayları, farklı bir iş varlığı olan teslimat durumundaki değişiklikleri temsil eder.

Hizmet ağı kullanma

Hizmet ağı, hizmet-hizmet iletişimini ele alan bir yazılım katmanıdır. Hizmet paylaşımları, önceki bölümde listelenen endişelerin çoğunu ele almak ve bu endişelerin sorumluluğunu mikro hizmetlerden ve paylaşılan bir katmana taşımak için tasarlanmıştır. Hizmet ağı, kümede mikro hizmetler arasındaki ağ iletişimini kesen bir ara sunucu olarak davranır. Şu anda hizmet ağı kavramı sunucusuz mimariler yerine kapsayıcı orchestrator'ları için geçerlidir.

Şu anda Kubernetes'te hizmet ağı için temel seçenekler linkerd veIstio'larıdır. Bu teknolojilerin ikisi de hızla gelişmektedir. Ancak hem linkerd hem de Istio'nun ortak özellikleri şunlardır:

• Gözlemlenen gecikme sürelerine veya bekleyen istek sayısına bağlı olarak oturum düzeyinde yük dengeleme. Bu, Kubernetes tarafından sağlanan katman 4 yük dengelemesi üzerinde performansı geliştirebilir.

• URL yolu, Konak üst bilgisi, API sürümü veya diğer uygulama düzeyi kurallarına göre katman 7 yönlendirmesi.

• Başarısız istekleri yeniden deneyin. Hizmet ağı HTTP hata kodlarını anlar ve başarısız istekleri otomatik olarak yeniden sınlar. En fazla yeniden deneme sayısını ve maksimum gecikme süresini sınırlayıcı bir zaman aşımı süresiyle birlikte yapılandırabilirsiniz.

• Bağlantı hattı kesılıyor. Bir örnek sürekli olarak isteklerde başarısız olursa hizmet ağı geçici olarak kullanılamaz olarak işaretlemektedir. Geri dönme süresi sonra örneği yeniden dener. Devre kesiciyi ardışık hata sayısı gibi çeşitli ölçütlere göre yapılandırabilirsiniz,

• Service Mesh istek hacmi, gecikme süresi, hata ve başarı oranları ve yanıt boyutları gibi hizmetler arası çağrılarla ilgili ölçümleri yakalar. Hizmet ağı ayrıca bir istekte her atlama için bağıntı bilgileri ekleyerek dağıtılmış izleme sağlar.

• Hizmet-hizmet çağrıları için karşılıklı TLS Kimlik Doğrulaması.

Hizmet ağı gerekiyor mu? Duruma göre değişir. Hizmet ağı olmadan, bu makalenin başında bahsedilen zorlukların her biri göz önünde bulundurabilirsiniz. Hizmet ağı olmadan yeniden deneme, devre kesici ve dağıtılmış izleme gibi sorunları çözebilirsiniz, ancak bir hizmet ağı bu endişeleri tek tek hizmetlerden ve ayrılmış bir katmana taşır. Öte yandan hizmet ağı, kümenin kurulumuna ve yapılandırmasına karmaşıklık ekler. Performans üzerindeki etkileri olabilir çünkü istekler artık hizmet ağı ara sunucusu üzerinden yönlendirildi ve kümedeki her düğümde fazladan hizmetler çalışıyor. Üretimde bir hizmet ağı dağıtmadan önce kapsamlı performans ve yük testi uygulamanız gerekir.

Dağıtılmış işlemler

Mikro hizmetlerde yaygın olarak karşılaşılan bir zorluk, birden çok hizmeti kapsayan işlemlerin doğru şekilde işlenmesidir. Bu senaryoda genellikle bir işlem başarılı olur veya hiçbir şey olmaz; katılan hizmetlerden biri başarısız olursa tüm işlem başarısız olur.

Göz önünde bulundurarak iki durum vardır:

• Bir hizmet, ağ zaman aşımı gibi geçici bir hatayla karşı ilgili olabilir. Bu hatalar genellikle çağrı yeniden denenerek çözülebilir. İşlem belirli sayıda denemeden sonra da başarısız olursa, geçişsiz bir hata olarak kabul edilir.

• Geçişsiz bir hata, tek başına gitme ihtimali düşük olan herhangi bir hatadır. Geçişsiz hatalar, geçersiz giriş gibi normal hata koşullarını içerir. Bunlar, uygulama kodunda veya işlem kilitlenmesinde işlanmamış özel durumlar da içerir. Bu tür bir hata oluşursa, iş işlemlerinin tamamı bir hata olarak işaretlenir. Aynı işlemde zaten başarılı olan diğer adımları geri almak gerekebilir.

Geçişsiz bir hatadan sonra, geçerli işlem kısmen başarısız durumda olabilir ve burada bir veya daha fazla adım zaten başarıyla tamamlanmıştır. Örneğin, İnsansız Hava Aracı hizmeti zaten bir insansız hava aracı zamanlanmışsa, insansız hava aracının iptal edilmesi gerekir. Bu durumda, uygulamanın telafi işlemi kullanarak başarılı olan adımları geri almaları gerekir. Bazı durumlarda, bu işlem bir dış sistem veya el ile yapılan bir işlem tarafından yapılması gerekir.

Telafi işlemleri mantığı karmaşıksa, bu işlemden sorumlu ayrı bir hizmet oluşturmayı göz önünde bulundurabilirsiniz. İnsansız Hava Aracı ile Teslimat uygulamasında Scheduler hizmeti başarısız işlemleri ayrılmış bir kuyruğa koyar. Gözetmen adlı ayrı bir mikro hizmet, bu kuyruktan okur ve dengelemesi gereken hizmetler üzerinde bir iptal API'si çağrır. Bu, Zamanlayıcı Aracısı Gözetmen deseninin bir çeşididir. Gözetmen hizmeti, kullanıcıya metin veya e-posta ile bildirim gönderme veya bir işlem panosuna uyarı gönderme gibi başka eylemler de gerçekleştirebilirsiniz.

Zamanlayıcı hizmetinin kendisi başarısız olabilir (örneğin, bir düğüm kilitleniyor). Bu durumda, yeni bir örnek uzer ve bunu alır. Ancak, devam eden tüm işlemlerin sürdürül olması gerekir.

Yaklaşımlardan biri, iş akışındaki her adım tamamlandıktan sonra denetim noktasını dayanıklı bir depoya kaydetmektir. Scheduler hizmetinin bir örneği bir işlem ortasında kilitleniyorsa, yeni bir örnek denetim noktasını kullanarak önceki örneğin kaldığı yerden devam edebilir. Ancak, denetim noktaları yazmak bir performans yükü oluşturabilir.

Bir diğer seçenek de tüm işlemleri bir etkili olacak şekilde tasarlamaktır. bir işlem, ilk çağrıdan sonra ek yan etkiler üretmeden birden çok kez çağrılsa bir kez etkili olur. Temel olarak, aşağı akış hizmeti yinelenen çağrıları yoksayarak hizmetin yinelenen çağrıları algılayabilecek olması anlamına gelir. Bire bir etkili yöntemleri uygulamak her zaman kolay değildir. Daha fazla bilgi için bkz. Bir kez etkili işlemler.

Sonraki adımlar

Doğrudan birbirlerine bağlı mikro hizmetler için iyi tasarlanmış API'ler oluşturmak önemlidir.