Otonom Mikro Hizmetler, olay kuyrukları ve hizmet keşfi

Son zamanlarda mikro hizmetler hakkında çok şey okudum ve işte şimdiye kadar aldığım sonuçlardan bazıları (herhangi bir noktada yanılıyorsam lütfen düzeltin).

1. Mikro hizmetler mimarisi, etki alanına dayalı tasarımla uyumludur. Genellikle bir MS bir sınırlı bağlamı temsil eder.
2. Mikro-servis A , mikro-servis B'de bulunan bir işlevsellik gerektiriyorsa , modelim muhtemelen yanlıştır ve A ve B aslında bir mikro-servis / BC olmalıdır.
3. Mikro hizmetler arasındaki senkron iletişim (doğrudan HTTP istekleri) kötüdür, mikro hizmetlerin amacına meydan okumasına neden olur ve bileşenler arasında bağlantı kurulmasını sağlar.
4. Hizmetler arasında zaman uyumsuz iletişim istenir. Hizmetler olayları ileti kuyruklarına yayımlamalıdır, böylece diğer hizmetler etkinliğin bir bölümünü abone edebilir ve işleyebilir veya içeriği için gerekli olan verilerin bir bölümünü çoğaltmak için kullanabilir. Bu şekilde, hizmetler senkronize iletişimde durum böyle olmayacak şekilde diğer hizmetler kapalı olsa bile istekleri işleyebilir.
5. Mikro-hizmet A olayı yayınlarsa, mikro-servis B o etkinliğe abone olur ve sonuç olarak yeni bir olay üretirse, mikro-servis A yeni oluşturulan olayı işlememeli, çünkü bu dairesel bir bağımlılık olacaktır. Bu durumda, üçüncü mikro hizmetini tanıtmak gerekir, ya da birleştirmek A ve B için AB mikro hizmet.
6. Mikro hizmet aslında yanıltıcı bir terimdir. Küçük bağlamlar için çabalamalıyız, ancak durum böyle olmak zorunda değil. Terim "mikro hizmet" değil, " iş hizmetini yapacak kadar büyük " olmalıdır.
7. Mikro hizmetler, yeni işlevleri daha kolay ve tüm sistemi kıracağımızdan korkmadan sunmamızı sağlar. Yeni bir hizmet sunarak veya mevcut hizmetlerden birini yeniden düzenleyerek yapılabilir.
8. Her mikro hizmetin kendi veri depolama alanı olmalıdır. Veri çoğaltma / çoğaltma bu mimaride istenen davranıştır.

Bu mimariyi anladığımı doğrulamak dışında, sorunun diğer kısmı çoğunlukla hizmet keşfi ile ilgili. Hizmetler eşzamansız olarak iletişim kuruyor ve amazon SQS gibi merkezi olay kuyruğunu kullanıyorsa, hizmet keşfinin mimaride böyle bir yeri olmadığı anlamına mı geliyor?

Hizmetler, sistemdeki diğer hizmetler hakkında bilgi sahibi olmamalıdır. Sadece bağlamlarının ve yayınlamaları ya da abone olmaları gereken olayların farkındalar mı?

Sonuçlarınız çoğunlukla yerleşik görünmektedir ve mikro hizmetlere girmenin yolunu çok iyi özetlemektedir.

Ancak 2, 5 ve 8'i tam olarak desteklemezdim:

• 2) Basit bir bağımlılık otomatik olarak birleşmeye yol açmamalıdır. Bu tür bağımlı aramaların sıklığını ve diğer hizmetlerden gelen aramaların sıklığını da göz önünde bulundurmalısınız.

  Dolayısıyla, bir mikro hizmet A mikro hizmet B'de çok sık işlevsellik gerektiriyorsa ve mikro hizmet B diğer mikro hizmetlere nadiren ihtiyaç duyuyorsa, öngörülen yapıya meydan okumalı ve her iki mikro hizmetin gruplandırılmasının daha uygun olup olmadığını sormalısınız.

• 5) elbette, mesaj işlemede sonsuz bisiklet sürmekten kaçınmanız gerekir.

  Ancak bir aracı eklemek bunu engellemez: A, C tarafından işlenen ve B tarafından işlenen bir iletiyi başlatan, A tarafından işlenen bir iletiyi başlatan ve burada bir döngüye hapsolmuş bir ileti başlatabilir.

  Sorun sadece mikro hizmet seviyesi göz önüne alınarak değerlendirilemez: soru gerçekten mesaj türünden ve döngüye yol açabilecek içerikten kaynaklanmaktadır. Bu nedenle, mesajların servisler arasındaki dağılımını ve işlenmesini modelleyen grafik bir bütün olarak analiz edilmelidir (aslında bu karmaşık olabilir, bu nedenle bu döngüleri tespit eden ve bunları parçalayan bir izleme mikro servisi hayal edebilirsiniz).

• 8) evet, her mikro hizmetin kendi depolama / veri tabanı olmalıdır.

  Hizmetlerin bağımsız olmasını sağlamak için minimum çoğaltma gerekir. Ancak, çoğaltmanın istendiğini söylemek için şu ana kadar gitmezdim: çoğaltma işlemleri yoluyla gizli bağlantıdan kaçınmak için minimumda tutulmalıdır.

  Mikro hizmetler, gevşek bağlantı ile ilgilidir. Bu, bazen verileri çoğaltmak yerine ilgili verileri almak için başka bir mikro hizmet çağrısı yapılarak daha etkili bir şekilde gerçekleştirilebilir.

Son numaralandırılmamış iki olumlama burada kesin olarak cevaplanamayacak kadar geniştir. Bence öneriniz iyi bir başlangıç ​​noktası, ama gerçekten mimari gereksinimlere ve kısıtlamalara bağlı.

Mikro hizmetler, farklı işlev alanlarını ayırmakla ilgilidir. Her hizmet, farklı bir teknoloji yığını kullanılarak, farklı bir ekip tarafından farklı bir hızda geliştirilebilir. Bu, kurumsal esneklik yaratır. Ödünleşim, her ilave hizmetin bir işletim ortamında yönetilmesi gereken bir şey daha oluşturduğu operasyonel karmaşıklıktır. Bu nedenle, monolitin mikro hizmete karşı temel değiş tokuşu bağımlılıklardan kaçınmakla ilgili değildir, her şeyin bir kerede gönderilmesi gereken kilit adımlı geliştirme ve konuşlandırmadan kaçınmakla ilgilidir, çünkü daha sık gönderilmesi pahasına daha hareketli parçalar.

Hizmetler, sistemdeki diğer hizmetler hakkında bilgi sahibi olmamalıdır. Sadece bağlamlarının ve yayınlamaları ya da abone olmaları gereken olayların farkındalar mı?

Bağımlılıktan kaçınma sorunu kırmızı bir ringa balığıdır. Ürününüzün parçaları arasında her zaman bağımlılıklarınız olacaktır ve bunların ayrı bir hizmette mi yoksa aynı kodun bir parçası olup olmadığı, bağımlılıkların kesilebileceği gerçeğini değiştirmez. Operasyonel seviyede kırılabilirler, çünkü bir anahtar sunucu kapanır ve bunu operasyonel artıklık ve başarısızlık uygulamalarıyla yönetirsiniz. Ayrıca entegrasyon seviyesinde kırılabilirler, çünkü parçalar entegrasyon testi ile tespit ettiğiniz uyumsuz şekillerde değişir. Kodlar hizmetler arasında karıştırılırsa, potansiyel olarak bozuk bağımlılıklar sorunu çözülmez. Bozuk bağımlılıklardan kaçınmanın çözümleri, hizmetlerinizin büyüklüğü ile ilgisi olmayan operasyonel artıklık ve entegrasyon testidir.

Hizmetler eşzamansız olarak iletişim kuruyor ve amazon SQS gibi merkezi olay kuyruğunu kullanıyorsa, hizmet keşfinin mimaride böyle bir yeri olmadığı anlamına mı geliyor?

Bu soruyu cevaplamak için önce bu soruyu cevaplayın: neden eşzamansız olarak iletişim kurmak istiyorsunuz? Ayrı bileşenlerin bağımsız gelişimini kolaylaştırmak mı? 7/24 çalışan bir sistemin operasyonel kullanılabilirliğini geliştirmek mi? Diyelim ki ikincisi ve verileri yerel veritabanlarına çoğaltmak için kuyrukları kullanmak istiyorsunuz. Artık verileriniz eski olabilir. Bir noktada çok bayat olacak. Bununla nasıl başa çıkıyorsunuz? Dahası, başka bir çalışma zamanı bileşeni olan kuyruğun operasyonel kullanılabilirliğini nasıl sağlıyorsunuz? Ve bu yerel veritabanlarının kullanılabilirliğini nasıl sağlıyorsunuz? Bir veritabanı kümesini yönetmek yerine artık birkaç tane var. Operasyon ekibiniz bu iş yükünü kaldırabilir mi? Ve gerçekten, karmaşıklığı buna değer mi, basit bir monolit inşa ettiyseniz, kullanıcılarınız her ay daha fazla özellik ve birkaç saat kesinti ile daha mutlu olur mu?

Demek istediğimi anlıyorsun. Sistem tasarımı doğru ve yanlış değil, çok çeşitli ödünleşimler arasından seçim yapmakla ilgilidir. Yanlış olan her şey doğru olabilir ve tersi de geçerlidir, ancak siz sadece doğru bağlamda görürseniz. Kişisel bağlam size özgüdür, bu yüzden size verebilir süre bir cevap, bu olmayacak cevap. Kitlenizin kim olduğunu, ihtiyaçlarının ne olduğunu ve doğru tasarımın kendini göstereceğini unutmayın.

1. Mikro hizmetler mimarisi, etki alanına dayalı tasarımla uyumludur. Genellikle bir MS bir sınırlı bağlamı temsil eder.

Katılmıyorum. DDD çok OO olma eğilimindedir. sipariş teslim edildi mi? Order.Deliver (), Micro-servislerin DeliveryService.Deliver (order)

2. Mikro-servis A, mikro-servis B'de bulunan bir işlevsellik gerektiriyorsa, modelim muhtemelen yanlıştır ve A ve B aslında bir mikro-servis / BC olmalıdır.

Katılmıyorum, size mikro hizmetleri mikro tutmaya çalışmalısınız. onları daha da küçük ayırın!

3. Mikro hizmetler arasındaki senkron iletişim (doğrudan HTTP istekleri) kötüdür, mikro hizmetlerin amacına meydan okumasına neden olur ve bileşenler arasında bağlantı kurulmasını sağlar.

Katılmıyorum. servisler onları kimin aradığını umursamamalı ve arayanlar mantığın bir mikro hizmette uygulanmasını önemsememelidir.

4. Hizmetler arasında zaman uyumsuz iletişim istenir. Hizmetler olayları ileti kuyruklarına yayımlamalıdır, böylece diğer hizmetler etkinliğin bir bölümünü abone edebilir ve işleyebilir veya içeriği için gerekli olan verilerin bir bölümünü çoğaltmak için kullanabilir. Bu şekilde, hizmetler senkronize iletişimde durum böyle olmayacak şekilde diğer hizmetler kapalı olsa bile istekleri işleyebilir.

Kuyruklar iyidir. Ama mantığınız yanlış. senkronizasyon yanıtları ile asenkron arasındaki tek fark, senkronizasyon yanıtını beklemenizdir. RPC tarzı çağrıları kuyruklar ve çoklu çalışanlar ile prob uygulayabilirsiniz.

5. Mikro-hizmet A olayı yayınlarsa, mikro-servis B o etkinliğe abone olur ve sonuç olarak yeni bir olay üretirse, mikro-servis A yeni oluşturulan olayı işlememeli, çünkü bu dairesel bir bağımlılık olacaktır. Bu durumda, üçüncü mikro hizmeti tanıtmalı veya A ve B'yi AB mikro servisine birleştirmeliyiz.

Katılmıyorum. Dairesel bir bağımlılık değildir, çünkü mikro hizmetleriniz birleştirilmez. Ayrıca yeniden göndermek için senarios, SendEmail, EmailFailed, SendAgain 3 mikro hizmete ihtiyaç duymaz

6. Mikro hizmet aslında yanıltıcı bir terimdir. Küçük bağlamlar için çabalamalıyız, ancak durum böyle olmak zorunda değil. Terim "mikro hizmet" değil, "iş hizmetini yapacak kadar büyük" olmalıdır.

Katılmıyorum. Nano servisleri inceleyin.

7. Mikro hizmetler, yeni işlevleri daha kolay ve tüm sistemi kıracağımızdan korkmadan sunmamızı sağlar. Yeni bir hizmet sunarak veya mevcut hizmetlerden birini yeniden düzenleyerek yapılabilir.

Katılmıyorum. Evet ayrışıyorsunuz, ancak mikro hizmetlerin düzenlenmesi herhangi bir monolit projesi kadar ürkütücü olabilir

8. Her mikro hizmetin kendi veri depolama alanı olmalıdır. Veri çoğaltma / çoğaltma bu mimaride istenen davranıştır.

Katılmıyorum. Depolamayı paylaşmamanız gerekse de, mikro servisleriniz mümkün olduğunca vatansız olmaya çalışmalıdır. uçuş sırasında verileri çoğaltma

Sonuçlarınız hoş bir kural ama evrensel değil. En iyi seçeneğin, bir yeşil alan projesinde bile bu kuralları ihlal etmek olduğu durumlar olacaktır. Bazı durumlarda senkron iletişim en iyi seçenektir. Bazı durumlarda, senkronize iletişim ile birleşmiş olsalar bile, iki hizmeti bir araya getirmek iyi değildir.

Diğer sorunuza da kuyruk tabanlı iletişim için servis keşfi gerekli değildir.

Um, sadece nesne yönelimli programlamadan bahsediyorsun. Ya da en azından orijinal olarak tasarlandığı şey: mesajlar kullanarak birbirleriyle iletişim kuran bağımsız çalışan kod parçaları.

Alan Kay, hücrelerin birbirinden nispeten bağımsız olduğu ve diğer hücrelerdeki harici arayüzlere bağlanan mesajlar aracılığıyla iletişim kurduğu biyolojik sistemlerden sonra modellenmiş olarak OOP'u tasarladı.

Öyleyse, neden tüm nesneler aynı bilgisayarda çalışmadığı için onu OOP olarak düşünmeyi bırakıyoruz? Bir şey varsa, bu aynı bilgisayarda ve aynı uygulamanın bir parçası olduklarından daha nesne yönelimlidir , çünkü tüm nesneler aynı uygulamadaysa, geliştiriciler genellikle tüm sınıflar tarafından paylaşılan global değişkenleri kullanarak OOP'yi kırır ve Tüm nesneler aynı öğelere bağlı olduğunda, birbirlerinden tamamen bağımsızlar gibi kapsüllenmezler ve kapsülleme OOP'un bütün noktasıdır.

Örneğin, diğer cevaplarda söylenen hemen hemen her şey OOP hakkında bir ders kitabı ifadesidir.

Sınırlı Bağlam ve Çekirdek Etki Alanı gibi önemli bir kavram hakkında sık sık yanlış bir anlayışla karşılaştığım için, üzerinde biraz durmak istiyorum.

Alt alanları iş yetenekleri olarak düşünmenin son derece karlı olduğunu gördüm. İş yeteneği, kuruluşunuzun yaptığı bir şeydir. İş işlevlerinden biridir. Hedefimiz iş-BT hizalaması olduğundan , teknik servislerimle kesinlikle 1: 1 ilişki kurmalarını istiyorum .

Yani bu süreç aşağıya iniyor. İlk olarak, üst düzey iş yeteneklerini tanımlarım. İsim ve fiil (veya bir türev formu) şeklinde olmalıdır. Genellikle 10'dan az iş yeteneği vardır. Sonra daha derinlere iniyorum, iç içe geçmiş yetenekleri tespit ediyorum. Ve böylece, bölünecek hiçbir şey kalmayana kadar. Bu yaklaşımı kullanarak geldiğiniz yetenekler, gerçek etki alanını, kuruluşunuzun çalışma şeklini yansıtır. Bu yetenekler tamamen gevşek bir şekilde birleştirilecektir, bu nedenle teknik servislerinizi bu yeteneklerle eşlerseniz, özerk ve olaya dayalı olacaktır. Bu işleme İş yeteneği eşlemesi denir , ancak hizmetlerinizi bulmanın başka yolları da vardır, bunların en önemlisi muhtemelen Değer Zinciri Analizi'dir .

İşte bu yaklaşımı kullanarak hizmet sınırlarını belirlemeye bir örnek .