REST mikro hizmetlerindeki işlemler?

Diyelim ki bir Kullanıcı, Cüzdan REST mikro hizmetimiz ve işleri birbirine yapıştıran bir API ağ geçidimiz var. Bob web sitemize kaydolduğunda, API ağ geçidimizin Kullanıcı mikro hizmeti aracılığıyla bir kullanıcı ve Cüzdan mikro hizmeti üzerinden bir cüzdan oluşturması gerekir.

Şimdi işlerin yanlış gidebileceği birkaç senaryo:

• Kullanıcı Bob oluşturma başarısız: sorun değil, sadece Bob'a bir hata mesajı döndürüyoruz. SQL işlemlerini kullanıyoruz, bu yüzden hiç kimse sistemde Bob'u görmedi. Her şey güzel :)

• Kullanıcı Bob oluşturulur, ancak Cüzdanımız oluşturulmadan önce API ağ geçidimiz kilitlenir. Artık cüzdanı olmayan bir Kullanıcı var (tutarsız veriler).

• Bob Kullanıcısı oluşturulur ve Cüzdan'ı oluştururken HTTP bağlantısı kesilir. Cüzdan oluşturma başarılı olmuş olabilir veya olmayabilir.

Bu tür veri tutarsızlıklarının olmasını önlemek için hangi çözümler mevcuttur? İşlemlerin birden fazla REST isteğine yayılmasına izin veren kalıplar var mı? Bu konuya değinen iki aşamalı kesinleştirme hakkındaki Wikipedia sayfasını okudum ancak pratikte nasıl uygulanacağından emin değilim. Bu Atomik Dağıtılmış İşlemler: RESTful tasarım kağıdı da henüz okumamış olsam da ilginç görünüyor.

Alternatif olarak, REST'in bu kullanım durumu için uygun olmayabileceğini biliyorum. Belki de REST'i tamamen bırakmak ve bir mesaj kuyruğu sistemi gibi farklı bir iletişim protokolü kullanmak için bu durumu ele almanın doğru yolu olabilir mi? Yoksa uygulama kodumda tutarlılığı zorunlu kılmalı mıyım (örneğin, tutarsızlıkları algılayan ve bunları düzelten bir arka plan işine veya Kullanıcı modelimde "oluşturma", "oluşturulan" değerler vb. İle "durum" özelliğine sahip olarak)?

Ne mantıklı değil:

• REST hizmetleri ile dağıtılmış işlemler . REST hizmetleri tanım gereği vatansızdır, bu nedenle birden fazla hizmeti kapsayan bir işlem sınırında katılımcı olmamalıdırlar. Kullanıcı kaydı kullanım senaryosunuz mantıklıdır, ancak Kullanıcı ve Cüzdan verileri oluşturmak için REST mikro hizmetlerine sahip tasarım iyi değildir.

Size baş ağrısı verecek ne:

• Dağıtılmış işlemlere sahip EJB'ler . Teoride çalışan ama pratikte olmayan şeylerden biri. Şu anda uzak EJB'ler için JBoss EAP 6.3 örneklerinde dağıtılmış bir işlem yapmaya çalışıyorum. RedHat desteğiyle haftalardır konuşuyoruz ve henüz çalışmadı.
• Genel olarak iki fazlı taahhüt çözümleri . 2PC protokolünün harika bir algoritma olduğunu düşünüyorum (yıllar önce RPC ile C'ye uyguladım). Yeniden denemeler, durum deposu, vb. İle kapsamlı arıza kurtarma mekanizmaları gerektirir. Tüm karmaşıklık, işlem çerçevesi içinde gizlenir (örn. JBoss Arjuna). Ancak, 2PC başarısız kanıtı değildir. İşlemin tamamlayamadığı durumlar vardır. Ardından, veritabanı tutarsızlıklarını manuel olarak tanımlamanız ve düzeltmeniz gerekir. Şanslıysanız milyon işlemde bir kez olabilir, ancak platformunuza ve senaryonuza bağlı olarak her 100 işlemde bir kez olabilir.
• Sagas (Telafi işlemleri) . Telafi edici operasyonlar yaratmanın uygulama yükü ve sonunda telafiyi etkinleştirmek için koordinasyon mekanizması vardır. Ancak tazminat da başarısızlığa dayanıklı değildir. Hala tutarsızlıklarla karşılaşabilirsiniz (= biraz baş ağrısı).

Muhtemelen en iyi alternatif nedir:

• Nihai tutarlılık . Ne ACID benzeri dağıtılmış işlemler ne de telafi işlemleri başarısızlığa dayanıklı değildir ve her ikisi de tutarsızlıklara yol açabilir. Nihai tutarlılık genellikle "zaman zaman tutarsızlık" tan daha iyidir. Farklı tasarım çözümleri vardır, örneğin:
  • Eşzamansız iletişimi kullanarak daha sağlam bir çözüm oluşturabilirsiniz. Senaryonuzda, Bob kaydolduğunda, API ağ geçidi bir NewUser kuyruğuna mesaj gönderebilir ve kullanıcıya "Hesap oluşturulduğunu onaylamak için bir e-posta alacaksınız" diyen hemen cevap verebilir. Bir kuyruk tüketici hizmeti, iletiyi işleyebilir, veritabanı değişikliklerini tek bir işlemde gerçekleştirebilir ve hesap oluşturmayı bildirmek için e-postayı Bob'a gönderebilir.
  • Kullanıcı mikro hizmeti , aynı veritabanında kullanıcı kaydını ve bir cüzdan kaydını oluşturur . Bu durumda, Kullanıcı mikro hizmetindeki cüzdan mağazası, yalnızca Cüzdan mikro hizmetinde görünen ana cüzdan mağazasının bir kopyasıdır. Çoğaltmadan master'a veri değişiklikleri (ör. Yeni cüzdanlar) göndermek için tetikleyici tabanlı veya periyodik olarak devreye giren bir veri senkronizasyon mekanizması vardır.

Peki eşzamanlı yanıtlara ihtiyacınız varsa ne olacak?

• Mikro hizmetleri yeniden düzenleyin . Hizmet tüketicisinin hemen bir yanıta ihtiyacı olduğu için kuyruktaki çözüm işe yaramazsa, dağıtılmış işlemlerden kaçınmak için Kullanıcı ve Cüzdan işlevselliğinin aynı hizmette (veya en azından aynı VM'de) konumlandırılmasını tercih ederim ). Evet, mikro hizmetlerden daha uzak ve monolite daha yakın bir adım, ancak sizi baş ağrısından kurtaracak.

Bu son zamanlarda bir röportaj sırasında sordum klasik bir soru Nasıl birden fazla web hizmetleri aramak ve hala görev ortasında bir tür hata işleme korumak. Bugün, yüksek performanslı hesaplamada, iki aşamalı taahhütlerden kaçınırız. Yıllar önce işlemler için "Starbuck modeli" olarak adlandırılan şey hakkında bir makale okudum: Starbuck'ta sipariş ettiğiniz kahveyi sipariş etme, ödeme, hazırlama ve alma sürecini düşünün ... Bir şeyleri basitleştiririm ama iki aşamalı bir taahhüt modeli tüm işlemin, kahvenizi alana kadar tüm adımlar için tek bir sarma işlemi olmasını öneririz. Bununla birlikte, bu modelle, tüm çalışanlar kahvenizi alana kadar bekler ve çalışmayı bırakır. Resmi görüyor musun?

Bunun yerine, "Starbuck modeli", "en iyi çaba" modelini izleyerek ve süreçteki hataları telafi ederek daha verimlidir. İlk olarak, ödeme emin olun! Ardından, siparişiniz bardağa eklenmiş mesaj kuyrukları vardır. Süreçte bir şeyler ters giderse, kahvenizi almadıysanız, sipariş ettiğiniz şey değildir, vb., Tazminat sürecine gireriz ve istediğinizi aldığınızdan veya size geri ödeme yaptığınızdan emin oluruz, Bu en verimli modeldir artan verimlilik için.

Bazen, starbuck bir kahve harcıyor, ancak genel süreç verimli. Web hizmetlerinizi, istediğiniz zaman çağrılabilecek şekilde tasarlama ve yine de aynı sonucu verebilme gibi tasarlarken düşünmeniz gereken başka numaralar da vardır. Benim tavsiyem:

• Web hizmetlerinizi tanımlarken çok iyi olmayın (bu günlerde meydana gelen mikro-hizmet abartısı konusunda ikna olmadım: çok ileri gitme riski çok fazla);

• Async performansı artırır, bu nedenle async olmayı tercih edin, mümkün olduğunda e-postayla bildirim gönderin.

• Her adımda iş kurallarını doğrulayarak, sonuna kadar alttan üste doğru sıralamayı izleyecek bir kullanıcı kimliği veya görev kimliği ile işleyerek onları istediğiniz kadar "yeniden doldurulabilir" hale getirmek için daha akıllı hizmetler oluşturun;

• İleti kuyruklarını (JMS veya diğerleri) kullanın ve ters işlemleri uygulayarak "geri alma" işlemlerini uygulayacak olan hata işleme işlemcilerine yönlendirme yapın; bu arada, zaman uyumsuz siparişle çalışmak, işlemin geçerli durumunu doğrulamak için bir tür kuyruk gerektirir, bu yüzden düşünün;

• Son çare olarak, (sık sık olmayabileceğinden), hataların manuel olarak işlenmesi için bir sıraya koyun.

Gönderilen ilk sorunla geri dönelim. Bir hesap oluşturun ve bir cüzdan oluşturun ve her şeyin yapıldığından emin olun.

Diyelim ki tüm operasyonu düzenlemek için bir web servisi çağrıldı.

Web servisinin sözde kodu şöyle görünecektir:

1. Hesap oluşturma mikro hizmetini arayın, bazı bilgileri ve benzersiz bir görev kimliğini iletin 1.1 Hesap oluşturma mikro hizmeti ilk önce o hesabın oluşturulup oluşturulmadığını kontrol eder. Bir görev kimliği hesabın kaydı ile ilişkilendirilir. Mikro hizmet hesabın bulunmadığını algılar, böylece hesabı oluşturur ve görev kimliğini depolar. NOT: Bu hizmet 2000 kez çağrılabilir, her zaman aynı sonucu verecektir. Hizmet, "gerekiyorsa geri alma işlemini gerçekleştirmek için en az bilgi içeren bir makbuz" ile yanıt verir.

2. Hesap oluşturma ve görev kimliği vererek Cüzdan oluşturma işlevini arayın. Diyelim ki bir koşul geçerli değil ve cüzdan oluşturma gerçekleştirilemiyor. Çağrı bir hata ile geri dönüyor ancak hiçbir şey oluşturulmadı.

3. Orkestratör hata hakkında bilgilendirilir. Hesap oluşturma işlemini iptal etmesi gerektiğini biliyor ancak bunu kendisi yapmayacak. 1. cüzdanın sonunda alınan "minimal geri alma makbuzunu" geçerek cüzdan servisinden bunu yapmasını isteyecektir.

4. Hesap hizmeti geri alma fişini okur ve işlemin nasıl geri alınacağını bilir; geri alma makbuzu, işin bir parçası yapmak için kendisini çağırabileceği başka bir mikro hizmet hakkında bilgi içerebilir. Bu durumda, geri alma makbuzu Hesap Kimliği'ni ve muhtemelen ters işlemi gerçekleştirmek için gereken bazı ek bilgileri içerebilir. Bizim durumumuzda, işleri basitleştirmek için, hesap kimliğini kullanarak hesabı silmek olduğunu varsayalım.

5. Şimdi, web hizmetinin Hesap oluşturma işleminin geri alınmasının başarılı veya başarısız olduğunu (bu durumda) hiç almadığını varsayalım. Hesabın geri alma hizmetini tekrar çağırır. Ve bu hizmet normalde asla başarısız olmamalıdır çünkü hedefi artık hesabın mevcut olmamasıdır. Böylece var olup olmadığını kontrol eder ve geri almak için hiçbir şey yapılamayacağını görür. Böylece operasyonun başarılı olduğu sonucuna varır.

6. Web hizmeti, hesabın oluşturulamadığı kullanıcıya döner.

Bu senkronize bir örnektir. Sistemin hatayı tamamen düzeltmesini istemiyorsak, bunu farklı bir şekilde yönetebilir ve davayı yardım masasına yönelik bir mesaj kuyruğuna koyabilirdik. " Durumları düzeltmek için arka uç sistemine kancalar sağlanabilir Yardım masası başarıyla gerçekleştirilenleri içeren mesajlar aldı ve geri alma makbuzumuzun tam otomatik bir şekilde kullanılabileceği gibi şeyleri düzeltmek için yeterli bilgiye sahipti.

Bir arama yaptım ve microsoft web sitesinin bu yaklaşım için bir desen açıklaması var. Dengeleme işlem modeli denir:

Telafi edilen işlem modeli

Tüm dağıtılmış sistemler işlem tutarlılığı konusunda sorun yaşar. Bunu yapmanın en iyi yolu, söylediğin gibi, iki aşamalı bir taahhütte bulunmaktır. M-cüzdanı ve kullanıcıyı bekleyen bir durumda oluşturun. Oluşturulduktan sonra, kullanıcıyı etkinleştirmek için ayrı bir çağrı yapın.

Bu son çağrı güvenli bir şekilde tekrarlanabilir olmalıdır (bağlantınız kesilirse).

Bu, son çağrının her iki tablo hakkında da bilgi sahibi olmasını gerektirir (böylece tek bir JDBC işleminde yapılabilir).

Alternatif olarak, cüzdanı olmayan bir kullanıcı için neden bu kadar endişeli olduğunuzu düşünmek isteyebilirsiniz. Bunun bir soruna neden olacağına inanıyor musunuz? Eğer öyleyse, bunların ayrı dinlenme çağrıları olması belki de kötü bir fikirdir. Bir kullanıcının cüzdan olmadan var olmaması gerekiyorsa, muhtemelen cüzdanı kullanıcıya eklemelisiniz (kullanıcıyı oluşturmak için orijinal POST çağrısında).

IMHO, mikro hizmet mimarisinin temel yönlerinden biri, işlemin tek mikro hizmetle sınırlı olmasıdır (Tek sorumluluk ilkesi).

Mevcut örnekte, Kullanıcı oluşturma kendi işlemidir. Kullanıcı oluşturma, USER_CREATED olayını olay sırasına iter. Cüzdan hizmeti USER_CREATED etkinliğine abone olacak ve Cüzdan oluşturma işlemini gerçekleştirecek.

Cüzdanım kullanıcıyla aynı sql veritabanındaki kayıtların başka bir demet olsaydı, muhtemelen kullanıcı ve cüzdan oluşturma kodunu aynı hizmete yerleştirir ve normal veritabanı işlem olanaklarını kullanarak işleyebilirdim.

Bana, cüzdan oluşturma kodu başka bir sistem veya sisteme dokunmanızı gerektirdiğinde ne olacağını soruyorsunuz? Her şeyin yaratılış sürecinin ne kadar karmaşık ve / veya riskli olduğuna bağlı olduğunu söylüyorum.

Sadece başka bir güvenilir veri deposuna (sql işlemlerinize katılamayan bir tane) dokunma meselesi varsa, genel sistem parametrelerine bağlı olarak, ikinci yazımın kaybolmayacak kadar küçük bir şansını riske atmaya istekli olabilirim. Hiçbir şey yapmam, ancak bir istisna oluşturabilir ve telafi edici bir işlem veya hatta geçici bir yöntemle tutarsız verilerle başa çıkabilirim. Geliştiricilerime her zaman söylediğim gibi: "uygulamada bu tür bir şey oluyorsa, fark edilmeyecektir".

Cüzdan oluşturma karmaşıklığı ve riski arttıkça, ilgili riskleri iyileştirmek için adımlar atmalısınız. Diyelim ki bazı adımların birden çok iş ortağı API'sini çağırması gerekiyor.

Bu noktada, kısmen oluşturulmuş kullanıcılar ve / veya cüzdanlar kavramıyla birlikte bir mesaj kuyruğu da ekleyebilirsiniz.

Varlıklarınızın nihayetinde düzgün bir şekilde inşa edilmesini sağlamak için basit ve etkili bir strateji, işlerin başarılı olana kadar yeniden denemelerini sağlamaktır, ancak çoğu uygulamanız için kullanım durumlarına bağlıdır.

Ayrıca, ön hazırlık sürecimde neden başarısızlığa meyilli bir adım attığımı uzun ve zor düşünürdüm.

Basit bir çözüm, Kullanıcı Hizmetini kullanarak kullanıcı oluşturmanız ve kullanıcı hizmetinin etkinliklerini yayınladığı bir mesajlaşma veri yolu kullanmanız ve Cüzdan Hizmeti mesajlaşma veriyoluna kaydolması, Kullanıcı Oluşturulan etkinliğini dinlemeniz ve Kullanıcı için Cüzdan oluşturmanızdır. Bu arada, kullanıcı Cüzdanını görmek için Cüzdan kullanıcı arayüzüne giderse, kullanıcının yeni oluşturulup oluşturulmadığını kontrol edin ve cüzdan oluşturma işleminizin devam ettiğini gösterin, lütfen bir süre sonra kontrol edin

Bu tür veri tutarsızlıklarının olmasını önlemek için hangi çözümler mevcuttur?

Geleneksel olarak, dağıtılmış işlem yöneticileri kullanılır. Birkaç yıl Java EE dünyada önce siz bu hizmetleri yaratabilirdi EJB farklı düğümlere konuşlandırılan ler ve API ağ geçidi bu EJB'ler uzak çağrılar yapmış olur. Uygulama sunucusu (doğru şekilde yapılandırılmışsa), iki aşamalı kesinleştirme kullanarak işlemin her düğümde gerçekleştirilmesini veya geri alınmasını otomatik olarak sağlar, böylece tutarlılık garanti edilir. Ancak bu, tüm hizmetlerin aynı tür bir uygulama sunucusuna dağıtılmasını gerektirir (böylece uyumlu olurlar) ve gerçekte yalnızca tek bir şirket tarafından dağıtılan hizmetlerle çalışır.

İşlemlerin birden fazla REST isteğine yayılmasına izin veren kalıplar var mı?

SABUN için (tamam, REST değil), WS-AT belirtimi ancak entegre etmek zorunda kaldığım hiçbir hizmet bunu desteklemiyor. REST için JBoss'un boru hattında bir şey var . Aksi takdirde, "desen" ya mimarinize takabileceğiniz bir ürün bulmak ya da kendi çözümünüzü oluşturmaktır (önerilmez).

Java EE için böyle bir ürün yayınladım: https://github.com/maxant/genericconnector

Referans verdiğiniz kağıda göre Atomikos'tan Dene-İptal / Onayla deseni ve ilişkili Ürün de vardır.

BPEL Motorları, tazminat kullanarak uzaktan dağıtılan hizmetler arasındaki tutarlılığı ele alır.

Alternatif olarak, REST'in bu kullanım durumu için uygun olmayabileceğini biliyorum. Belki de REST'i tamamen bırakmak ve bir mesaj kuyruğu sistemi gibi farklı bir iletişim protokolü kullanmak için bu durumu ele almanın doğru yolu olabilir mi?

İşlem dışı kaynakları bir işleme "bağlamanın" birçok yolu vardır:

• Önerdiğiniz gibi, işlemsel bir mesaj kuyruğu kullanabilirsiniz, ancak eşzamansız olacaktır, bu nedenle yanıta bağlı kalırsanız dağınık hale gelir.
• Arka uç hizmetlerini veritabanınıza çağırmanız ve ardından bir toplu iş kullanarak arka uç hizmetlerini çağırmanız gerektiği gerçeğini yazabilirsiniz. Yine, async, dağınık olabilir.
• Arka uç mikro hizmetlerini düzenlemek için API ağ geçidiniz olarak bir iş süreci motoru kullanabilirsiniz.
• Kutunun dışında dağıtılmış işlemleri desteklediğinden, başlangıçta belirtildiği gibi uzak EJB'yi kullanabilirsiniz.

Yoksa uygulama kodumda tutarlılığı zorunlu kılmalı mıyım (örneğin, tutarsızlıkları algılayan ve bunları düzelten bir arka plan işine veya Kullanıcı modelimde "oluşturma", "oluşturulan" değerler vb. İle "durum" özelliğine sahip olarak)?

Şeytanlar oynamak savunuyor: neden sizin için bunu yapan ürünler olduğunda (yukarıya bakın) ve muhtemelen denendiğinden ve test edildiğinden, muhtemelen yapabileceğinizden daha iyi yaptığınızda neden böyle bir şey inşa edersiniz?

Şahsen Mikro Servisler fikrini seviyorum, kullanım vakaları tarafından tanımlanan modüller, ancak sorunuzdan bahsedildiği gibi, bankalar, sigorta, telekom vb. Gibi klasik işletmeler için uyum sorunları var ...

Dağıtılmış işlemler, daha önce de belirtildiği gibi, iyi bir seçim değil, insanlar şimdi sonunda tutarlı sistemler için daha fazla gidiyor ama bunun bankalar, sigorta, vb için çalışacağından emin değilim ....

Önerdiğim çözüm hakkında bir blog yazdım, bu size yardımcı olabilir ....

https://mehmetsalgar.wordpress.com/2016/11/05/micro-services-fan-out-transaction-problems-and-solutions-with-spring-bootjboss-and-netflix-eureka/

Nihai tutarlılık burada anahtardır.

• Hizmetlerden biri etkinliğin birincil işleyicisi olacak şekilde seçilir.
• Bu hizmet orijinal etkinliği tek bir taahhütle ele alacaktır.
• Birincil işleyici, ikincil etkileri diğer hizmetlere eşzamansız olarak iletmekten sorumlu olacaktır.
• Birincil işleyici, diğer servis çağrılarının düzenlenmesini gerçekleştirecektir.

Komutan, dağıtılan işlemden sorumludur ve kontrolü ele almaktadır. Yürütülecek talimatı bilir ve yürütmeyi koordine eder. Çoğu senaryoda sadece iki talimat olacaktır, ancak birden fazla talimatı işleyebilir.

Komutan, tüm talimatların yerine getirilmesini garanti etme sorumluluğunu üstlenir ve bu, emekli anlamına gelir. Komutan uzaktan güncellemeyi etkilemeye çalıştığında ve bir yanıt almadığında, yeniden denemesi olmaz. Bu şekilde sistem arızaya daha az eğilimli olacak şekilde yapılandırılabilir ve kendini iyileştirir.

Tekrar denerken, idempotence var. İdempotence, sonuçların sadece bir kez yapıldığı gibi aynı olacak şekilde iki kez bir şey yapabilme özelliğidir. Uzaktan servis veya veri kaynağında idempotence ihtiyacımız var, böylece talimatı bir kereden fazla alırsa, sadece bir kez işler.

Nihai tutarlılık Bu, dağıtılmış işlem zorluklarının çoğunu çözer, ancak burada birkaç noktayı dikkate almamız gerekir. Başarısız olan her işlemi bir yeniden deneme izleyecek, denenen yeniden deneme sayısı bağlama göre değişecektir.

Tutarlılık eninde sonunda, örneğin bir müşteri yeniden deneme sırasında tutarlı bir durumdayken, örneğin bir müşteri bir kitap sipariş edip ödeme yaptığında ve stok miktarını güncellediğinde. Stok güncelleme işlemleri başarısız olursa ve mevcut en son stok olduğunu varsayarsak, stok güncelleme için yeniden deneme işlemi başarılı olana kadar kitap hala kullanılabilir olacaktır. Yeniden deneme başarılı olduktan sonra sisteminiz tutarlı olacaktır.

Komut dosyası / programlamayı destekleyen API Yönetimi (APIM) platformunu neden kullanmıyorsunuz? Böylece, mikro hizmetleri rahatsız etmeden APIM'de kompozit hizmet oluşturabileceksiniz. Bu amaçla APIGEE kullanarak tasarladım.