Geç Aşama Mikro Hizmetler

Amazon Prime Video ekibinin mikro hizmetlerini tek bir yapı halinde birleştirerek ölçeklendirme ve maliyetleri %90 oranında azaltma çabasını okudum . Buradaki hikayenin daha fazlası olduğundan emin olsam da, internette yayınlanan benzer hikayeler var; son on yılın mikro hizmet çılgınlığına bir tür çürütme.

Bana Twitter'da geçirdiğim son birkaç yılı hatırlattı; burada mikro hizmet sayısı (binlerce) zirveye ulaştı ve ardından trafik arttıkça bile düşmeye başladı. Her türden uygulama mantığı, şu ya da bu türden yekpare yönetilen platformlara dahil edildi. Amaca yönelik mikro hizmetler oluşturma ilkesi özünde iyi değildir ve belirli bir noktadan sonra, ekibimizin çoğu için olumlu bir yatırım getirisi gibi görünmedi.

Bir mikro hizmet mimarisi maliyetli olabilir. Son on yılda bunun büyük mühendislik kuruluşları için doğal bir politika olduğuna dair bir anlatı var, çünkü:

• Ekipler, daha geniş bir kuruluştan ve onun kodundan bağımsız olarak hizmetlerini yineleyebilir
• Hizmet mimarisinin küçük bileşenleri, daha büyük sistem kesintiye uğramadan değiştirilebilir
• Mimari, bağımsız hizmetler aracılığıyla net, yönetilebilir uygulama ve hata alanlarının tanımlanmasına izin verir.
• Mimari, bağımsız olarak ayarlanabilen veya ölçeklendirilebilen iş yüklerine izin verir

Tekil veya az sayıda monolitin aksine, küçük hizmet sahibi ekiplere ve sonuç olarak daha geniş ekosisteme aktarılan işin karmaşıklığını hesaba katmak gerekir. Dağıtılan iş, kuruluşun teknoloji yığınının olgunluğuna bağlıdır; ancak şunları içerebilir:

Tüm hizmet sahibi ekipler arasında dağıtılmış operasyonel sorumluluklar ve genel gider

• İş planlama ve devreye alma araçları, hizmet keşfi, RPC çerçeveleri, VM'ler ve ilişkili ayarlama, hizmet izleme ve günlük kaydından hizmet altyapısı bileşenlerinin anlaşılması ve yapılandırılması
• SLO'lar ve SLI'lar için dağıtılmış tanımlar ve geliştirme süreçleri, hizmet hatası ve hata yönetimi, karşı basınç yönetimi ve hata sinyali
• Dağıtılmış ve genellikle koordine olmayan kapasite planlama, yük testi, entegrasyon testi uygulaması ve sorumlulukları

• Birçok arka uç hizmetiyle etkileşime giren uygulama mantığı, genellikle bir dizi ısmarlama hizmet API tanımları, anlambilim, veri modelleri, sürüm oluşturma sistemleri ve hatta bazen farklı protokollerde geziniyor.
• Mühendisler, işlevsel şeyler inşa etmek için genel hizmet mimarisini ve trafik modellerini anlamalı ve bunlar hakkında akıl yürütmelidir.
• Yetersiz veya darboğazlı sunum yolları, dağıtılmış veri replikasyonu ve tüketimi, döngüsel istek bağımlılıkları için organik geçici çözümler

• Çıkarım ve sıralama, olay işleme, HTTP/dahili protokol API çevirisi ve veri modeli eşleme sorunlarına yerelleştirilmiş yaklaşımlar
• Genel parçalanma ve yığın boyunca standartları zor tutma

Sorun şu ki, yeni bir hizmet yaratma, inşa etme ve işletmeye alma süreci pahalıdır . Bu hizmetin üretim hizmet mimarisine entegrasyonu zordur. Verimli çalışma için başka bir hizmeti ayarlamak için gereken dikkat ; ilgili hizmet hesaplarını ayarlamak, gözlemlenebilirlik ve günlük kaydı profilleri, entegrasyon testleri, çağrı sırasında rotasyon ve diğer her şey, ekibin bakım ve operasyonel ek yüküne katkıda bulunur. Çoğu kuruluş, bu tür karmaşık basmakalıp işler için otomasyondan ve uçtan uca yapı iskelesinden yoksundur.

Bu ek yük, ekiplerin UNIX'ten ilham alan " bir şeyi iyi yap " mikro hizmet mimarisi ilkesine bağlı kalması konusunda büyük bir caydırıcıdır. Mevcut hizmetlere yeni kullanım örnekleri oluşturmak artık daha kolay. Yelpazenin en uç noktasında, ekipler, bir ekip olarak sorumlu oldukları her şeyi (çeşitli ürünleri veya yetenekleri içerebilecek) kapsamaya başlayan “makro” hizmetler yürütür. Yeniden yapılanma nispeten yaygın bir olay olduğu için mülkiyet kalitesi zamanla düşer. Bir çamur topuyla çalışıyorsun.

Makro hizmet kesintileri, belirli bir özellik kümesiyle sınırlı değildir, bunun yerine, geçmiş kuruluş şemalarına benzeyebilecek, sistemin öngörülemeyen veya ilkesiz bir alanıdır. Site, bu hizmetlerin kullanılamamasına müsamaha gösterebilir veya etmeyebilir. Heterojen iş yükleri için hizmetleri optimize etmek daha zordur; çağrı yolları çözülemez. Eski bir meslektaşım bu "mikroliti" icat etti.

Mikro hizmetler, yerel optimizasyonu hizmet mimarisine kodlar ve teşvik eder. Amaç, hizmet geliştirme federasyonu olduğunda, ekipleri hizmet mimarisi için ilkeli bir tasarıma karşı sorumlu tutmak zordur. Benzer şekilde, bağımlı hizmetlerin özellikleri ısmarlama olduğunda, arka uç çapında optimizasyon problemlerini çözmek zordur. Dikkatlice tasarlanmış hizmet mimarisi ve destekleyici hizmet platformları olmadan kaldıraç bulmak zordur — yeniden kullanılabilir ürün platformu kodu, bir dizi büyük hizmete veya paylaşılan kitaplığa dağılmıştır ; ön uç hizmetleri genellikle ısmarlama.

Bilgi işlem katmanında (hizmet işlerini veya kapsayıcıları yöneten ve yürüten her şey), hizmet keşfinde, VM'de (belirli bağlamlarda uygulanabilir), hizmet çerçevesinde ( gRPC , Finagle veya Rest.Li gibi ) ve merkezi geliştirici araçlarında mikro hizmet kaldıracı bulunmuştur. Elbette, hizmet ağları bu endişelerin bazılarını güzel bir şekilde özetlemektedir.

Bu sorunlara yaklaşmanın bir başka yolu da işlevsel yükü azaltmaktır. Bu nedenle, hizmeti çalıştırmanın tekrarlanan altyapı yükünü azaltmaya çalışmak yerine , ortak iş sınıflarını yeniden uygulayan ekiplerin maliyetlerini azaltabilirsiniz . Yönetilen platformların bu kadar başarılı olmasının nedeni budur — bir hizmet oluşturmak veya işletmek pahalı olsa bile, uygulama mantığını bir genel veya özel yönetilen platforma dış kaynak sağlayarak inceltebilirsek, sahibi olan ekibin üzerindeki yük daha az olur.

Kuruluşların kendi özel ihtiyaçlarına, hedeflerine ve teknoloji yığını olgunluğuna dayalı olarak mimari ödünleşimleri dikkatli bir şekilde değerlendirmesi önemlidir. Mikro hizmetler belirli avantajlar sağlar. Ayrıca, ilk başta yönetilebilir gibi görünen ancak zamanla karmaşıklaşan karmaşıklıklar ve operasyonel ek yük getirirler. Bu sorunların ele alınmaması, uçtan uca geliştirme sürecini tek parça halinde çalışmaktan biraz daha kolaylaştırır.

Özellikle eski bir mikrolitle çalışıyorsanız, aklınızda bulundurmanız gereken birkaç şey:

• "Büyük hizmetler" veya yekpare yapılar mutlaka kötü değildir; mikro hizmetlerden farklı türde araçlara, altyapı desteğine ve ilkeler dizisine ihtiyaç duyarlar, ancak hizmet veren mimarinin iyi tanımlanmış ortak öğelerini yakalayacak şekilde oluşturulmaları gerekir.
• "Tek görev, tek hizmet" ilkesini savunmak, sıkı işbirliği, performans kaygıları ve farklı başarısızlık alanları etrafında sezgisel sınırlar çizmekten ve ekipleri plana bağlı kalmaya zorlamaktan çok daha az pratik olma eğilimindedir.
• Hizmet sahiplerinin sorumlu olduğu yığının dikey derinliğini (hizmet çerçeveleri, hizmet ağı, bilgi işlem) ve ayrıca yönetilen hizmetler aracılığıyla uygulama alanının kapsamını azaltarak "çok fazla hizmetin" karmaşıklığını ve ek yükünü hafifletebilirsiniz. ortak iş akışları için platformlar