Kitap Oluşturma Mikro Servisleri , cevabında @ RogerAlsing tarafından belirtilen stilleri ayrıntılı olarak açıklamaktadır.
Orkestrasyon vs Koreografi altında 43. sayfada kitap şöyle diyor:
Daha karmaşık bir mantık modellemeye başladığımızda, bireysel hizmetlerin sınırlarını aşan iş süreçlerini yönetme sorunuyla uğraşmak zorundayız. Ve mikro hizmetlerle, bu sınıra normalden daha erken vuracağız. [...] Bu akışı gerçekte uygulamak söz konusu olduğunda, takip edebileceğimiz iki mimari tarzı vardır. Orkestrasyon ile, bir orkestrada orkestra şefi gibi, süreci yönlendirmek ve yönlendirmek için merkezi bir beyine güveniyoruz. Koreografi ile, sistemin her bir parçasını işinden haberdar edip, dansçıların hepsi kendi yollarını bulan ve bir bale içinde çevrelerindeki diğer kişilere tepki veren gibi detaylar üzerinde çalışmasına izin veriyoruz.
Kitap daha sonra iki stili açıklamaya devam eder. Orkestrasyon stili, SOA'nın orkestrasyon / görev hizmetleri fikrine daha çok karşılık gelirken, koreografi stili Martin Fowler'in makalesinde belirtilen aptal borulara ve akıllı uç noktalara karşılık gelir .
Düzenleme Stili
Bu tarzda, yukarıdaki kitaptan bahsediyor:
Bu akış için bir düzenleme çözümünün nasıl olacağını düşünelim. Burada, muhtemelen yapılacak en basit şey, müşteri hizmetlerimizin merkezi beyin gibi davranması olacaktır. Yaratılışında, bir dizi talep / yanıt çağrısı aracılığıyla sadakat puan bankası, e-posta hizmeti ve posta servisi [...] ile konuşur. Müşteri hizmeti daha sonra müşterinin bu süreçte nerede olduğunu izleyebilir. Müşterinin hesabının kurulmuş olup olmadığını veya gönderilen e-postayı mı, yoksa postayı mı teslim aldığını kontrol edebilir. Akış şemasını alıp [...] doğrudan kod haline getiriyoruz. Belki de uygun bir kural motoru kullanarak bunu bizim için uygulayan takımları bile kullanabiliriz. Bu amaçla iş araçları modelleme yazılımı şeklinde ticari araçlar mevcuttur. Senkronize istek / yanıt kullandığımızı varsayarsak, her aşamanın işe yarayıp yaramadığını bile anlayabiliriz [...] Bu orkestrasyon yaklaşımının dezavantajı, müşteri hizmetlerinin merkezi bir yönetim otoritesinin çok fazla olabileceğidir. Bir ağın ortasındaki merkez ve mantığın yaşamaya başladığı merkezi bir nokta olabilir. Bu yaklaşımın anemik CRUD tabanlı hizmetlere ne yapılacağını söyleyen az sayıda akıllı “tanrı” hizmetiyle sonuçlandığını gördüm.
Not: Yazarın araçlardan bahsettiği zaman BPM gibi bir şeye atıfta bulunduğunu düşünüyorum (örneğin, Activity , Apache ODE , Camunda ). Aslında, İş Akışı Kalıpları Web Sitesi , bu tür bir düzenlemeyi yapmak için harika bir desen setine sahiptir ve ayrıca bu şekilde uygulamaya yardımcı olan farklı satıcı araçlarının değerlendirme ayrıntılarını sunar. Yazarın, bu entegrasyon stilini uygulamak için bu araçlardan birini kullanması gerektiğini ima ettiğini düşünmüyorum, ancak diğer hafif düzenleme çerçeveleri örneğin Bahar Entegrasyonu , Apache Camel veya Mule ESB kullanılabilir
Ancak, Microservices konusunda okuduğum diğer kitaplar ve genel olarak web'de bulduğum makalelerin çoğu, bu orkestrasyon yaklaşımından hoşlanmıyor ve bunun yerine bir sonrakini kullanmayı öneriyor gibi görünüyor .
Koreografi Stili
Koreografi stilinde yazar diyor ki:
Koreograflı bir yaklaşımla, bunun yerine, müşteri hizmetinin, Müşteri'nin oluşturduğunu söyleyerek, eşzamansız bir şekilde bir etkinlik yayınlamasını sağlayabiliriz. E-posta hizmeti, posta servisi ve bağlılık puanları bankası daha sonra bu olaylara abone olur ve buna göre tepki verir [...] Bu yaklaşım çok daha fazla ayrıştırılır. Bir müşterinin oluşturulmasına ulaşmak için başka bir hizmet gerekiyorsa, yalnızca etkinliklere abone olması ve gerektiğinde işini yapması gerekir. Dezavantajı, [iş akışı] 'nda gördüğümüz iş sürecine ilişkin açık görüşün şimdi sadece sistemimize dolaylı olarak yansıtılmasıdır [...] Bu, doğru şeylerin olmuş. Örneğin, sadakat puan bankasında bir hata olup olmadığını ve bir nedenle doğru hesabı açıp açmadığını biliyor musunuz? Bununla uğraşmaktan hoşlandığım bir yaklaşım, [iş akışı] 'ndaki iş sürecinin görünümüyle açıkça eşleşen bir izleme sistemi oluşturmaktır, ancak daha sonra hizmetlerin her birinin bağımsız varlıklar olarak ne yaptığını izleyerek, daha açık süreç akışı. [Akış şeması] [...] itici güç değil, sistemin nasıl davrandığını görebildiğimiz sadece bir lens. Genel olarak, koreograflanmış yaklaşıma daha fazla eğilimli sistemlerin daha gevşek bir şekilde bağlandığını ve daha esnek ve değişime daha uygun olduğunu keşfettim. Bununla birlikte, sistem sınırları içerisindeki süreçleri izlemek ve izlemek için fazladan iş yapmanız gerekir. En ağır düzenleme uygulamalarının son derece kırılgan ve daha yüksek bir değişim maliyeti olduğunu gördüm. Bunu göz önünde bulundurarak, her hizmetin tüm danstaki rolünü anlayacak kadar akıllı olduğu koreograflı bir sistemi hedeflemeyi şiddetle tercih ediyorum.
Not: Bugüne kadar koreografinin olay güdümlü mimari (EDA) için başka bir isim olup olmadığından hala emin değilim , ancak EDA bunu yapmanın sadece bir yolu ise, diğer yollar nelerdir? (Ayrıca bkz . "Olaya Dayalı" ile ne demek istiyorsun? Ve Olaya Dayalı Mimarinin Anlamları ). Ayrıca, CQRS ve EventSourcing gibi şeylerin bu mimari stille çok fazla yankılandığı görülüyor, değil mi?
Şimdi, bundan sonra eğlence geliyor. Microservices kitabı, mikro hizmetlerin REST ile uygulanacağını varsaymaz. Nitekim kitabın bir sonraki bölümünde, RPC ve SOA tabanlı çözümleri ve son olarak REST'i ele almaya devam ediyorlar. Burada önemli bir nokta Mikro Hizmetlerin REST anlamına gelmediğidir.
Peki, HATEOAS ne olacak? (Uygulama Durumunun Motoru Olarak Hiper Ortam)
Şimdi, RESTful yaklaşımını takip etmek istiyorsak, HATEOAS'ı görmezden gelemeyiz, ya da Roy Fielding, blogumuzda çözümümüzün gerçekten REST olmadığını söylemekten çok memnun olacaktır. REST API'sındaki blog yayınına bakın Hipermetin Tahrikli Olmalıdır :
Herhangi bir HTTP tabanlı arayüzü bir REST API çağıran kişi sayısı ile sinirli alıyorum. Hipermetin bir kısıtlama olduğu fikrinde REST mimari stilini netleştirmek için ne yapılması gerekir? Başka bir deyişle, uygulama durumunun motoru (ve dolayısıyla API) köprü metni tarafından yönlendirilmiyorsa, RESTful olamaz ve REST API olamaz. Dönemi. Bir yerde düzeltilmesi gereken bazı kırık kılavuzlar var mı?
Gördüğünüz gibi, Fielding, HATEOAS olmadan gerçekten RESTful uygulamalar oluşturmadığınızı düşünüyor. Fielding için, HATEOAS, düzenleme hizmetleri söz konusu olduğunda gitmenin yoludur. Sadece tüm bunları öğreniyorum, ama bana göre, HATEOAS aslında bağlantıları takip eden arkasındaki itici gücün kim veya ne olduğunu açıkça tanımlamıyor. Kullanıcı olabilecek bir kullanıcı arayüzünde, ancak bilgisayar-bilgisayar etkileşimlerinde, bunun daha üst düzey bir hizmet tarafından yapılması gerektiğini düşünüyorum.
HATEOAS'a göre, API tüketicisinin gerçekten bilmesi gereken tek bağlantı, sunucu ile iletişimi başlatan bağlantıdır (örneğin POST / sipariş). Bu noktadan itibaren, REST akışı gerçekleştirecektir, çünkü bu son noktanın cevabında, geri dönen kaynak bir sonraki olası durumlara bağlantılar içerecektir. API tüketicisi daha sonra uygulamayı takip etmek ve uygulamayı bir sonraki duruma taşımak için hangi bağlantıya karar verir.
Kulağa ne kadar havalı gelse de, müşterinin hala bağlantının POST, POUT, GET, PATCHed vb. Olup olmadığını bilmesi gerekir. İstemcinin bu başarısız olması durumunda ne yapacağının farkında olması gerekir (yeniden deneyin, telafi edin, iptal edin, vb.).
Tüm bunlar için oldukça yeniyim, ancak benim için, HATEOA'ların bakış açısından, bu müşteri veya API tüketicisi yüksek dereceli bir hizmettir. Bir insanın bakış açısından düşünürsek, bir web sayfasında bir son kullanıcının hangi bağlantıları izleyeceğine karar vererek hayal edebilirsiniz, ancak yine de web sayfasının programcısı, bağlantıları çağırmak için hangi yöntemi kullanacağına karar vermek zorunda kaldı, ve hangi yükü geçecek. Benim açımdan, bilgisayardan bilgisayara etkileşimde bilgisayar son kullanıcının rolünü üstlenir. Bir kez daha buna düzenleme hizmeti diyoruz.
HATEOAS'ı orkestrasyon veya koreografi ile kullanabileceğimizi düşünüyorum.
API Ağ Geçidi Düzeni
Bir başka ilginç model de API Ağ Geçidi Deseni olarak adlandırdığı şeyi öneren Chris Richardson tarafından önerildi .
Monolitik bir mimaride, uygulamanın web tarayıcıları ve yerel uygulamalar gibi istemcileri, uygulamanın N özdeş örneğinden birine yük dengeleyici aracılığıyla HTTP istekleri yapar. Ancak bir mikro hizmet mimarisinde, yekpare bir hizmet koleksiyonu ile değiştirildi. Sonuç olarak, cevaplamamız gereken kilit bir soru, müşterilerle ne etkileşime giriyor?
Yerel bir mobil uygulama gibi bir uygulama istemcisi, bireysel hizmetlere RESTful HTTP istekleri yapabilir [...] Yüzeyde bu çekici görünebilir. Bununla birlikte, bireysel hizmetlerin API'leri ile müşterilerin ihtiyaç duyduğu veriler arasında ayrıntı düzeyinde önemli bir uyumsuzluk olması muhtemeldir. Örneğin, bir web sayfasının görüntülenmesi büyük olasılıkla çok sayıda hizmete çağrı yapılmasını gerektirebilir. Örneğin Amazon.com,
bazı sayfaların 100'den fazla hizmete nasıl çağrı gerektirdiğini açıklar . Yüksek hızlı bir internet bağlantısı üzerinden bile olsa, daha düşük bant genişliğine, daha yüksek gecikme süresine sahip bir mobil ağ olsa bile, birçok isteğin çok verimsiz olmasını ve kötü bir kullanıcı deneyimiyle sonuçlanmasını sağlar.
Çok daha iyi bir yaklaşım, istemcilerin İnternet üzerinden bir API ağ geçidi olarak bilinen bir ön uç sunucuya sayfa başına az sayıda, belki de en az sayıda istek yapmasıdır.
API ağ geçidi, uygulamanın istemcileri ve mikro hizmetler arasında bulunur. İstemciye göre uyarlanmış API'lar sağlar. API ağ geçidi, mobil istemcilere kaba taneli bir API ve yüksek performanslı bir ağ kullanan masaüstü istemcilerine daha ince taneli bir API sağlar. Bu örnekte, masaüstü istemciler bir ürün hakkında bilgi almak için birden fazla istekte bulunurken, mobil istemci tek bir istekte bulunur.
API ağ geçidi, yüksek performanslı LAN üzerinden bir dizi mikro hizmete istekte bulunarak gelen istekleri işler. Örneğin Netflix,
her bir talebin hayranlarının ortalama altı arka uç hizmetine nasıl ulaştığını
açıklar . Bu örnekte, bir masaüstü istemciden gelen ayrıntılı istekler, karşılık gelen hizmete basitçe yakınlaştırılırken, mobil istemciden gelen her kaba taneli istek, birden çok hizmeti çağırmanın sonuçları toplanarak işlenir.
API ağ geçidi yalnızca istemciler ve uygulama arasındaki iletişimi optimize etmekle kalmaz, aynı zamanda mikro hizmetlerin ayrıntılarını da kapsar. Bu, mikro hizmetlerin istemcileri etkilemeden gelişmesini sağlar. Örneğin, iki mikro hizmet birleştirilebilir. Başka bir mikro hizmet iki veya daha fazla hizmete bölünebilir. Bu değişiklikleri yansıtacak şekilde yalnızca API ağ geçidinin güncellenmesi gerekir. Müşteriler etkilenmez.
API ağ geçidinin uygulama ve istemcileri arasında nasıl aracılık ettiğine baktığımıza göre, şimdi mikro hizmetler arasındaki iletişimin nasıl uygulanacağına bakalım.
Bu, yukarıda bahsedilen düzenleme tarzına oldukça benziyor, sadece biraz farklı bir niyetle, bu durumda, etkileşimlerin performansı ve basitleştirilmesi ile ilgili görünüyor.
.