Gevşek bağlı mikro hizmet mimarisinde bağımlılıklarınızı nasıl takip edersiniz?


9

Modern programda popüler bir üst düzey mimari seçimi, REST tabanlı bir mikro hizmet sistemidir. Bunun gevşek bağlantı, kolay yeniden kullanım, kullanılabilecek teknolojiler üzerinde sınırlı kısıtlama, yüksek ölçeklenebilirlik vb. Gibi çeşitli avantajları vardır.

Ancak böyle bir mimaride öngördüğüm sorunlardan biri, bir uygulamanın bağımlılıklarının ne olduğu konusunda zayıf bir görünürlüktür. Örneğin, günlük olarak bir REST çağrısı kümesi kullanan bir uygulamam olduğunu varsayalım. Bu uygulama aynı zamanda sadece bir çeyrek kez ikinci bir REST çağrı kümesi kullanır. Günlükleri geçen hafta tarayacak olsaydım tüm günlük cal'leri görürdüm, ama muhtemelen üç aylık aramaları görmezdim. Refactor zamanı geldiğinde, üç ayda bir yapılan aramaların kırılma riski yüksektir.

Bu riski azaltmak ve gevşek bir şekilde bağlanmış mimarinin bağımlılıklarının ne olduğu konusunda daha fazla görünürlük sağlamak için hangi modeller veya araçlar kullanılabilir?


1
Tam olarak bu nedenle gevşek bağlantı kötü olabilir. Derleme zamanı bağımlılıkları olmadığında, hataları tespit etmenin tek yolu ve hiçbirini yakalayamamanız otomatik test kullanmaktır. Çözüm, muhtemelen birim testin yanı sıra entegrasyon testini de içeren bir tür otomatik testtir.
Frank Hileman

@FrankHileman Test açıkçası yardım, ama bunun tek çözüm olduğuna inanmakta zorlanıyorum. Ayrıca derleme zamanı kontrolleri olmayan birçok dil vardır (yani JS veya Python), bu nedenle sıkı bağlantıda bile hala sorunlarınız olacaktır.
David, Reinstate Monica'yı

1
statik tip sistemler derleme aşamasında çok sayıda hata yakalayabilir. Böyle bir sistemin olmaması için tek tazminat benim bilgime göre otomatik testtir. Otomatik provalar veya sadece derleme yoluyla statik hata tespiti her zaman testlerden daha güvenilir olacaktır.
Frank Hileman

Olası bir yol, her bir hizmetin API istemcisini ayrı olarak uygulamak ve bu istemcileri projenin bağımlılıkları olarak dahil etmek olabilir. API istemcileri ile hizmetin hangi sürümünü kullandığımızı takip etmek daha kolay olacaktır.
Laiv

@Laiv Özellikle RESTful hizmetleri merak ediyorum, bu yüzden herkes HTTP istekleri az ya da çok gönderebilir, çünkü bu gerçekten bir seçenek değil.
David, Reinstate Monica'nın

Yanıtlar:


4

Bu riski azaltmak için hangi modeller veya araçlar kullanılabilir?

API'larınızı ve işletme yeteneklerinizi geriye dönük olarak uyumlu tutma.

gevşek bir şekilde bağlanmış mimarinin bağımlılıklarının ne olduğu konusunda daha fazla görünürlük sağlamak

Sağlık kontrolleri.

Hizmetim, aylık API yeteneğiniz için bir müşteri. Ancak hizmetim her çalıştığında hizmetim api'nizin istemcisidir. Böylece servisim her 10 dakikada bir uyanıyor ya da her neyse aylık API'nize bağlanıyor ve servisimin ihtiyacı olan kapasitenin hala kullanılabilir olduğundan emin olmak için protokolü çalıştırıyor.

Böylece günlükleriniz, sunduğunuz her bir hizmetin hala kullanılabilir olduğunu görmek için diğer bazı hizmetlerin ne sıklıkta kontrol ettiğini gösterecektir.


1

Bağımlılıkları bulabileceğiniz en az iki konum vardır:

  • Yapılandırma. Harici API'lere erişmek, bu API'ların her biri hakkında bir dizi bilgi bilmek gerektirir. Erişim kimlikleri, gizli anahtarlar, uç noktalar. Bütün bunlar olamaz tür bilgiler, çünkü kodunda olacaktır değiştirin. Örnek olarak, yakın zamanda tüm mikro hizmetlerimi SSL'ye taşımaya başladım. Bu, taşınmakta olan hizmete dayanan her hizmetin https://sürümü değil , sürümü gösterecek şekilde yeniden yapılandırılması gerektiği anlamına gelir http://. Uç noktaların konfigürasyonda sabit kodlanmış olması yerine sevindim.

  • Arabirimler. API sürümü değişeceğinden bir hizmete doğrudan kodunuzdan erişemezsiniz ve hatta farklı bir API'ya geçmeye karar verebilirsiniz. Bunun yerine, bir soyutlama katmanı oluşturur ve bağımlılığı bir arabirim üzerinden kullanırsınız. Bu arayüzleri oluştururken ortak bir mantığı takip ederek, bağımlılıkları ararken daha sonra hayatınızı kolaylaştırabilirsiniz.

Refactor zamanı geldiğinde, üç ayda bir yapılan aramaların kırılma riski yüksektir.

Regresyon testi bunun içindir.

Sadece koda bakamaz, değiştiremez ve hiçbir şeyin kırılmadığına kendinize güvenemezsiniz. Bu bir mikro hizmet mimarisinde çalışmaz. Bu monolitik bir uygulamada da işe yaramaz. Bir derleyici, kodu değiştirirken ortaya koyacağınız bazı hataları yakalayabilir. Haskell gibi bazı dillerde, derleyici çok yetenekli olabilir ve hataların çoğunu yakalayabilir; Ancak, ana diller için derleyiciler sizin için fazla bir şey yapmaz. Testleriniz yoksa, mahvoldunuz. Mikro hizmetlerin varlığı önemsizdir.


-2

REST API'leri gevşek bir şekilde belirtilmiştir, bu nedenle bir noktada bir RPC arayüzü tanımlamak ve daha sonra versiyonlamak için gRPC, google protobufs veya Thrift'e geçmek yararlı olabilir.


2
Bu bir yorum olarak daha iyi olabilir ... ama dürüst olmak gerekirse bu pek açıklamıyor.
David, Reinstate Monica'yı

Yeterince adil. Bir dinlenme API'sının başka bir hizmete özgü derleme zamanı bağımlılığı yoktur, çünkü ikisi arasındaki bağlantı sadece bir HTTP dinlenme çağrısı, ana bilgisayar ve yol gibi bir şeydir. GRPC veya Protobuf veya Thrift ile kod üretmek için kullanılan bir arabirim tanımlanır. Oluşturulan kod derlenir ve sürümlenir ve ardından hizmet (ler) iniz bu arabirimlere karşı oluşturulur. Sonuç olarak, her hizmet açıkça diğer hizmet arabirimlerinizden birine veya daha fazlasına bağımlıdır. Umarım cevabımı açıklığa kavuşturur!
Patrick
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.