Docker uygulamasında mikro hizmetler


9

İlk mikro hizmetlerimizi Amazon fargate kullanarak Docker kapsayıcılarını kullanarak yazıyoruz. Spring Boot'u kullanarak uygulama düzeyinde birçok şüphemiz var

Projede birden fazla mikro hizmetimiz olacak, tüm mikro hizmetleri tek bir kapta yazmamız iyi bir uygulama mı yoksa ayrı mikro hizmetler için ayrı Docker kapsayıcısı oluşturmam gerekiyor. Uygun bir şekilde tek bir konteyner kullanıyoruz, ancak bu gelecekte proje yapımız için herhangi bir sorun yaratıyor mu?

Uygulamayı AWS fargate'de dağıtmayı planlıyoruz ve uygulamamızın gelecekte genişletilmesi ve yaklaşık 100 ila 150 farklı mikro hizmet beklemesi için büyük bir seçeneği olacak. Bu durumda, tüm bu mikro hizmetleri farklı kaplara da yüklememiz uygun mu?


Hepsi yapınıza bağlıdır. Başkalarının size yardımcı olabileceği şekilde daha fazla ayrıntı paylaşmanız gerekiyor
Nico Haase

6
Kapsayıcı başına bir hizmet uygulamak neredeyse her zaman daha mantıklıdır, çünkü bu size hizmetleri bağımsız olarak ölçeklendirme ve tek tek hizmetleri yükseltilmiş sürümlerle veya alternatif uygulamalarla değiştirme yeteneği verir.
larsks

Ödünç alma hizmetleri, gruplama hizmetleri ve bunları tek tek yürütme arasında sizinle birlikte. Geçerli uygulamanızın alan adı kesimini yapın, aynı veri deposunu paylaşabildikleri için hizmetleri alan adı başına gruplayın. Bu, gruplandırılmış hizmetleri daha iyi yönetmenize yardımcı olacaktır.
Srini M

Yanıtlar:


21

Mikro hizmetlerle hatırlanması gereken en önemli şey, öncelikle teknik problemleri değil örgütsel problemleri çözmektir. Dolayısıyla, bir kuruluşun mikro hizmet kullanması gerekip gerekmediğine ve bu hizmetlerin nasıl dağıtıldığına baktığımızda, kuruluşun mikro hizmet stilinin çözdüğü sorunlara sahip olup olmadığına bakmamız gerekir.

O zaman mimariniz hakkındaki sorunuzun cevabı çoğunlukla teknoloji ekibinizin büyüklüğüne, organizasyon yapısına, ürününüzün yaşına, mevcut dağıtım uygulamalarınıza ve bunların orta vadede nasıl değişme olasılığına bağlı olacaktır.

Örneğin, kuruluşunuz:

  • 25'ten az teknik personele sahiptir,
  • 1 veya 2 takım halinde organize edilmiş,
  • bunların her biri ürünün herhangi bir kısmında çalışır,
  • 12 aydan daha az olan
  • ve düzenli olarak (örneğin günlük, haftalık, aylık) aynı anda dağıtılır,
  • ve kuruluş hızla büyümek üzere değil,

o zaman neredeyse neredeyse mikroservisleri unutmak istiyorsunuz. Böyle bir durumda, ekip hala alan hakkında bilgi edinmede yenidir, bu yüzden sistemi dağıtılmış bir mimariye bölmenin harika bir yolunun ne olduğunu gerçekten anlamak için bilmeleri gereken her şeyi bilmiyorlar. Bu, şimdi bölerlerse, muhtemelen sınırları daha sonra değiştirmek isteyecekler ve zaten bir dağıtılmış sisteminiz olduğunda, monolitte çok daha basit hale geldiklerinde çok pahalı hale geliyorlar. Dahası, yalnızca sistemin herhangi bir parçası üzerinde çalışabilen (ve destekleyebilen) küçük bir ekiple, bireysel ekiplerin bireysel hizmetleri dağıtabileceği ve bakımını yapabileceği bir platform oluşturmaya yatırım yapmak için çok az neden vardır. Bu aşamadaki bir organizasyon, ekipleri özerk yapmak ve yüksek ölçekli, dayanıklı bir mimari oluşturmak yerine, genellikle müşteri bulmak ve ürünü hızlı bir şekilde yinelemek, hatta ürünü bile döndürmekle çok daha fazla ilgilenecektir. Monolitik bir mimari bu noktada mantıklıdır, ancakAPI'lar tarafından uygulanan açık bileşen sınırları ve kapsüllenmiş veri erişimi ile iyi tasarlanmış monolit, daha sonra hizmetleri ayrı işlemlere çekmeyi kolaylaştırır.

Biraz daha ileriye bakalım ve ...

  • 50'den fazla teknoloji personeli,
  • 7 ekip halinde organize edildi,
  • her biri yalnızca ürünün belirli alanlarında çalışır,
  • 3 yaşında,
  • ve çalışmalarını diğer ekiplerin yaptıklarından bağımsız olarak dağıtmak isteyen takımlara sahiptir.

Böyle bir organizasyon kesinlikle dağıtılmış bir mimari inşa etmelidir. Eğer bu takımların hepsi bir monolitte çalışmazlarsa ve bunun yerine her türlü örgütsel problemle karşılaşırlarsa, ekipler işlerini koordine etmek zorunda kalırlar, bir takım yeni özelliklerinde KG'yi bitirirken serbest bırakılır. personel ve müşteriler için büyük bir güçlük oluşturuyor. Dahası, olgun bir ürünle kuruluş, hem etki alanını hem de ekipleri (bu sırayla; Conway Yasası'na bakın) makul bir şekilde, koordinasyonu en aza indirirken ilerleme sağlayabilecek hassas, özerk birimlere ayırabilmek için alan hakkında yeterince bilgi sahibi olmalıdır.

Zaten mikro hizmet seçmişsiniz gibi görünüyor. Yukarıdaki ölçeklerde nerede oturduğunuza bağlı olarak, bu kararı yeniden gözden geçirmek isteyebilirsiniz.

Mikro hizmetlerle geliştirmeye devam etmek, ancak hepsini tek bir kapta dağıtmak istiyorsanız, bununla ilgili yanlış bir şey olmadığını bilinşu anda kuruluşunuzun çalışma biçimine uygunsa. Gelecekte proje yapınız için problem yaratacak mı? Başarılı olursanız ve kuruluşunuz büyürse, özellikle de ekipler hizmet sahibi olmaya başladığında ve tüm uygulamayı dağıtmadan sadece hizmetlerini dağıtmak istediğinde, bu tek kapsayıcı dağıtımının artık en uygun olmadığı bir zaman gelecektir. . Ancak bu özerklik ekstra iş ve karmaşıklık pahasına olacaktır ve bu noktada size hiçbir fayda sağlamayabilir. Gelecekte sisteminiz için doğru yaklaşım olmayacağı, bugün için doğru yaklaşım olmadığı anlamına gelmez. İşin püf noktası, ona bir göz atmak ve ekstra yatırımı ne zaman yapacağınızı bilmek.


1
Bu harika bir açıklama ve liman işçileri ile mikro hizmetleri proje ve ekip yapısı temelinde nerede kullanmamız gerektiğini belirleyebiliyoruz. Teşekkür ederim.
anoop

2

Mikro hizmetleriniz için tek bir kap kullanıyorsanız, ancak mikro hizmetlerin temel amacı, her bir hizmeti ayrı ayrı korumaktır, her hizmetin gevşek bir şekilde bağlanması ve her hizmetin ayrı bir veritabanı olması gerekir (hizmet mimarisi başına veritabanı elde etmek istiyorsanız). Bu nedenle, hizmetlerinizi ayrı bir kapta çalıştırın ve docker sürüsü veya Kubernetes ile bu hizmetleri düzenleyin. Maliyeti biliyorum ama doğru şekilde yaparsanız o zaman mikro hizmet mimarisinin gücünü göreceksiniz.


Farklı mikro hizmetler için farklı liman işçisi konteyneri kullanmamız maliyet açısından faydalı mıdır? Projede yaklaşık 100 ila 150 mikro hizmet beklediğimizden beri
anoop

Hayır, maliyet açısından yararlı değildir, ancak her hizmetin ayrı bir şekilde yürütülmesi teknik olarak faydalı olacaktır.
Slim Coder
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.