Hizmetler bir mikro hizmet mimarisinde birbirleriyle doğrudan konuşmalı mıdır?

Bir web uygulaması oluşturan bir dizi web hizmetim var. İstemciler bu hizmetlere REST API'lerinin çağrıları aracılığıyla erişebilir.

Bu hizmetler birbirleriyle doğrudan konuşabilmeli mi? Eğer öyleyse bu onları mikro hizmetler kavramına aykırı hale getirmez mi?

Müşteri, istemciye bir web sayfasını yüklemek için ihtiyaç duyduğu verileri almak için bunları birbiri ardına doğrudan aramalı mıdır?

Yoksa hizmetlerimin üstünde, istemciden gelen bir isteği işleyen, bu istekle ilgili verileri alan ve daha sonra istemciye geri gönderen başka bir katmanım olmalı mı?

Hizmetlerinizin bu resimdeki gibi görünmesini istiyorsanız, evet: Yapamayacağınız gibi değil, ancak çoğu zaman kötü sonuçları olacaktır. REST aracılığıyla iletişim, hizmetlerinizi önemli ölçüde bozmaz. Bazı servis arabirimi değiştiğinde, tüm bağımlı servislerin değiştirilmesi ve yeniden konuşlandırılması büyük olasılıktır. Ayrıca hizmeti yeniden dağıtırken, yüksek kullanılabilirlik standartları için iyi bir tasarım olarak kabul edilmeyen tüm bağımlı hizmetleri kaldırmanız gerekecektir.

Sonunda, alternatif monolit uygulaması olurdu daha yavaş, ancak hemen hemen aynı sorunları sahip mikro hizmet uygulaması olacak!

@Robert Harvey ile aynı fikirde değilim

Bununla birlikte, pratikte, mikro hizmetlerinizin biri veya daha fazlası (belki de hepsi) bir SQL veritabanı gibi bazı merkezi veri deposuyla konuşacaktır.

Entegrasyon veritabanı iyi bilinen bir antipatterndir

Çok daha iyi bir çözüm, hizmetleriniz arasında iletişimi senkronize olmayan hale getirmek için yayınlama-abone olma kalıbını kullanmaktır:

Lütfen bu iletişim yöntemini uygulamak için CQRS / ES yöntemine bir göz atın, Greg Young ve diğer çocuklar konuyla ilgili tonlarca güzel video sunuyor . Sadece "CQRS / ES" anahtar kelimesi için google. Bu yaklaşımda, her hizmet aynı anda yayıncı ve abone olacak ve hizmetlerin daha az birleşmesine izin verecektir.

İşte konuyla ilgili tartışmalara ışık tutan mikro hizmetlerle ilgili iyi bir dizi makale . Güzel resimlerle çok detaylı bir açıklama.

Udi Dahan'ın SOA hakkında söylediklerini okuyarak birçok iyi fikir edineceksiniz .

Hizmet, belirli bir iş kapasitesi için teknik otoritedir. Herhangi bir veri veya kural parçası yalnızca bir hizmete ait olmalıdır.

Bunun anlamı, hizmetler birbirlerinin etkinliklerini yayınlıyor ve abone olsa bile, her veri ve kural için yetkili hakikatin ne olduğunu her zaman biliyoruz.

Ayrıca, iş yetenekleri merceğinden hizmetlere baktığımızda, gördüğümüz şey, birçok kullanıcı arayüzünün farklı yeteneklere ait bilgileri sunmasıdır - bir ürünün stokta olup olmadığının yanı sıra fiyatı. Yukarıdaki hizmet tanımına uymamız için, bu, bu tür kullanıcı arayüzlerinin aslında bir karışım olduğunu anlamamıza yol açmaktadır - her hizmet, kendi verileriyle ilgilenen UI parçasına sahiptir.

Özellikle UI kompozisyonu ile ilgili olarak Mauro Servienti'nin UI Kompozisyonu hakkındaki makalesi iyi bir başlangıç ​​noktasıdır. Ayrıca burada bulunan Udi'nin videosuna bakın .

Bu hizmetler birbirleriyle doğrudan konuşabilmeli mi? Eğer öyleyse bu onları mikro hizmetler kavramına aykırı hale getirmez mi?

İki hizmet birbiriyle mesaj alışverişi yapıyorsa, bazı bağlantılar elde edersiniz. Birincil cevap, diğer hizmetin API'sı ile eşleşmeleridir - iç hizmet değiştiğinde bile hizmetin sabit kalmayı vaat ettiği sözleşme.

Bunun ötesinde, servis keşfi gibi teknikler belirli bir servis sağlayıcıya bağımlılığı azaltabilir ve mesaj brokerleri üreticileri ve tüketicileri birbirinden ayırabilir (yine de birbirlerinin mesajlarını ve mesaj aracının API'sı ile nasıl etkileşimde bulunmaları gerektiğini bilmeleri gerekir) sihir yoktur ).

"Doğrudan" ile ne demek istediğinize bağlıdır.

Mikro hizmet mimarisine göre, kendi sunucunuzda, hatta harici sunucularda, REST gibi bir arabirim aracılığıyla diğer mikro hizmetlerin çağrılmasını sağlayan mikro hizmetlere sahip olmak mükemmeldir.

İyi olmayan şey, bir mikro hizmetin doğrudan yöntem çağrılarını kullanarak başka bir hizmet çağrısında bulunmasıdır; bu da her iki mikro servisi aynı monolitin bir parçası haline getirir.

Bu hizmetler birbirleriyle doğrudan konuşabilmeli mi? Eğer öyleyse bu onları mikro hizmetler kavramına aykırı hale getirmez mi?

Eşleşme kötü bir kelime değildir. Her uygulamanın zaten belirli bir dereceye kadar bağlantısı vardır; mikro hizmetlerinizle konuşan uygulamalar mikro hizmetlere zaten bağlıdır , aksi takdirde çalışmazlar.

Mikro hizmetlerle gerçekten peşinde olduğunuz şey gevşek bağlantıdır ; bunu bir mikro hizmetin diğerini genel API'sı üzerinden sorgulaması veya bir olay veri yolu kullanarak gerçekleştirmesi ile elde edebilirsiniz.

Uygulamada, ancak mikro hizmetlerinizin biri veya daha fazlası (belki de hepsi) SQL veritabanı gibi bazı merkezi veri deposuyla konuşacaktır. Hedefinize nasıl ulaşmak istediğinize bağlı olarak, bir mikro hizmetin veritabanı verilerini bir şekilde değiştirmesi, diğer mikro hizmetin değişikliği almak için sorgulayacağı basitçe olabilir.

Görünüşe göre SOA'lar ve genel olarak mimarlık hakkında konuşurken insanlar anlambilim ve jargona yakalanıyorlar. Bir hizmeti "mikro" yapan nedir? Sonuçta, kullandığınız "puanlama sistemi" ne olursa olsun, hizmeti açıkça "mikro olmayan" yapmayan bazı özellikler dizisidir. Yargıtay adaletinin ahlaksızlık hakkında söylediği şey neydi? "Gördüğümde bileceğim."

Eminim bazı insanlar bunun cevapsız olduğunu söyleyecektir, ama sonra noktayı kaçırıyorlar. Mikro hizmet mimarileri, aralarında "sıkı bağlantı" sorunu olmak üzere çeşitli sorunlardan kaçınmayı amaçlamaktadır. Yani, birbirinizin çok fazla ince ayrıntısına bağlı bir mikro hizmet karmaşası oluşturursanız, bir pub / alt mesaj veri yolu veya doğrudan çağrılar kullansanız da yok olan sıkı bir bağlantı oluşturdunuz. parçalardan yeni çözümler oluşturma, tüm sistemi düşürmeden parçaları ayrı ayrı yeniden yapılandırma vb.

Müşteri, istemciye bir web sayfasını yüklemek için ihtiyaç duyduğu verileri almak için bunları birbiri ardına doğrudan aramalı mıdır?

Değişir; ancak, müşteriye doğrudan kullanılabilir yetenekler sağlamanızı ve sonuçların nasıl toplandığının ayrıntılarını gizlemeyi (kapsülleyerek) öneririm (örneğin, birden fazla mikro servis aracılığıyla).

Müşteri tarafından bireysel mikro hizmet sonuçlarının birleştirilmesinde çok fazla mantık varsa, bu yanlışlıkla bazı iş mantığının istemciye sızmasına neden olabilir. Ayrıca, iç mimarinizin daha fazlasını istemciye gösterebilir ve mikro hizmetlerin daha sonra yeniden düzenlenmesini engelleyebilir.

Yani, bu mikro hizmetlerle, bazen müşteriye yararlı soyutlamalara sahip bir uç nokta sağlayan ve diğer (belki de şimdi daha fazla dahili) mikro hizmetlerin daha yüksek düzeyde koordinasyonunu sağlayan bir sargı mikro hizmetine sahip olmak yararlı olabilir.

(Ayrıca, müşteriye gidiş-dönüş gezileri, mikro hizmetlerinizden birbirlerine göre daha pahalıdır.)

Örneğin, GraphQL tarafından alınan yöne bakarsanız, bir uç noktaya doğrudan ilgili sorgular yayınlayan istemcileri bulabilirsiniz; bu, bir mikro hizmet koleksiyonu olarak uygulanabilir veya uygulanmayabilir. Mikro hizmetlerin mimarisi GraphQL'in arkasına gizlendiğinden, mimariyi yeniden düzenlemeyi ve aynı zamanda istemci için daha kolay hale getirir. Örneğin, bkz . Https://stackoverflow.com/a/38079681/471129 .

Mikro hizmetlerin temel amacı, uygulamanızı gevşek bir şekilde birleştirmektir. Bu nedenle, hizmetler birbirini arayamaz. Aksi takdirde, bağlı olarak bağlanır. Ancak, veri paylaşması gereken iki hizmetimiz varsa ne yapacağız? Cevap Message Broker. Böylece, istemciden veri alan hizmet, verileri merkezi ileti aracısına paylaşabilir, daha sonra hizmetlerin bu verileri kullanması, dönüştürmesi ve kendi veri deposuna koyması gerekir. Kafka'yı öneriyorum çünkü Kafka Stream ile farklı konulara ait verileri anında birleştirebilirsiniz. PS. mikro hizmetlerinizi özelliğe göre ayırmak daha iyidir.