Kendi başıma bir sistem geliştirirken, mikro hizmetleri kullanmalı mıyım?

İşyerinde yeni bir projeye başlıyorum ve muhtemelen bir veya iki geliştiricinin mevcut uygulamaları veya basit komut dosyalarını ana projeye dahil etmesi gerekecek olsa da, projenin neredeyse tek geliştiricisi olacak. Projenin küçük ölçekli toplu ve akış verilerini alma / işleme ve hem olaya dayalı ve isteğe bağlı kod yürütme işlemlerini gerçekleştirmesi gerekir. Çerçevenin bazı bölümleri yoğun şekilde CPU'ya bağlı olacak ve bazı bölümler yoğun bir şekilde G / Ç'ye bağlı olabilir; Verilerin çoğu tek bir makinede yaşamak zorundadır, ancak kullanılabilir bilgi işlem gücünü artırmak için bir küme oluşturabilir ve VM'leri bağlayabiliriz. Muhtemelen bu temel çerçeveyi sağlayan hizmetlere bağlı bir ya da daha fazla küçük web uygulaması olacaktır. Ana dil hemen hemen her şey için Python olacaktır.

Sorum şu: bu tür bir çabaya bir mikro hizmet yaklaşımı benim alıp almamam gerektiği ya da gelişimin çoğunu kendim yapacağım göz önüne alındığında, monolitik bir uygulamayla yapışmam gerekip gerekmediği. Benim düşüncem, mikro hizmetlerin (Nameko kullanarak) farklı uygulama modellerine (veri boru hatları, etkinliğe başlatılan, talep üzerine, web uygulamaları vb.) Sahip olan unsurları ile iş yükünü dağıtmanın açık bir yolu arasında doğal bir ayrılık sağladığıdır. çoklu işlemlerde iletişim. Benim endişem, muhtemelen sistemi yönetmek için gerekli olan birden fazla hizmeti (rabbitmq, redis, vb.) Yönetmek için bir Kubernetes kümesini (Docker'ı biliyorum ama yine de Kubernet'lere oldukça yeniyim) sahip olacağım. ve potansiyel olarak, biz gerekli tüm yetenekleri gerçekten yerine getirecek küçük kod parçaları.

Tek bir geliştiriciden biraz daha fazlasını içeren bir proje için, mikro hizmetler hala böyle karmaşık bir sistemin geliştirilmesini ve sürdürülmesini kolaylaştırıyor mu? Bunun yerine kullanmayı düşünmem gereken ya da sistemi bu şekilde tasarlamanın yükünü azaltmak için kullanmam gereken yöntemler / sistemler / çerçeveler var mı?

Mikro hizmetler, genellikle yazılımınızı dağıtık bir sisteme dönüştürdüğü için istenmeyen bir durumdur ve dağıtılmış sistemler her şeyi çok daha zorlaştırır. Ancak hizmet odaklı bir mimarinin bazı önemli faydaları vardır:

• farklı ekipler tarafından bağımsız olarak farklı hizmetler geliştirilebilir ve dağıtılabilir
• farklı hizmetler bağımsız olarak ölçeklenebilir

Tek geliştirici olacağınız için hizmetleri bağımsız olarak geliştirme esnekliğine ihtiyacınız yoktur.

Ancak bazı parçaların CPU'ya bağlı olabileceğini unutmayın. Bu nedenle, bunları uygulamanın geri kalanından bağımsız olarak ölçeklendirmek istenebilir. Bu durumda, bu, tüm projeyi bir mikro hizmet mimarisine dönüştürmeniz gerektiği anlamına gelmez. İşlemcinin yoğun bölümünü yalnızca kendi hizmetine taşımanız ve gerisini uygun bir monolitte tutmanız yeterlidir. Sistemin hangi hatlara bölünmesi gerektiğini söylemek zor, ancak genel olarak DDD'nin “sınırlı bağlamlar” fikri iyi bir rehber.

Monolitlerin fena olmadığını unutmayın. Monolith'ler, dağınık ve anlaşılmaz büyük bir projeye eşit değil. Sistemi farklı mikro servislere böldüğünüzde, sistemi bir monolit içindeki farklı bileşenlere de ayırabilirsiniz. Bu bileşenler arasındaki ayrım, hizmet odaklı bir mimaride daha görünür ve daha net bir şekilde uygulanır. Bu, iyi tasarlanmış bir sistem için, bir bileşeni daha sonra bir noktada bir servise dönüştürmenin oldukça kolay olması gerektiği anlamına gelir. Dolayısıyla, şu an karar vermek zorunda değilsiniz, eğer bir monolit kendini uygun bulmazsa, mikro hizmetlere geçebilirsiniz.

Martin Fowler'in Microservice Premium (2015) kavramını da göz önünde bulundurun : mikro hizmetler, sisteminizin temel karmaşıklığına ek olarak, kendi başlarına da önemli bir karmaşıklık sunar. Verimliliği düşürmek için bu “primi” ödemek zorundasınız. Bu, basit projeler için mikro hizmetlerin sizi daha az üretken hale getirdiği anlamına gelir. Bu, daha karmaşık projeler için değişir: monolitik bir çözümle çalışmak gittikçe zorlaşırken, bir mikro hizmet mimarisi daha iyi ölçeklenir ve kabaca sürekli çaba gerektirir. Yazılım servisinizde verilen ilk mikro servis çabalarının buna değip değmeyeceğini bilmek zorundasınız. Bu soruyu sorduğun için, cevap muhtemelen “hayır” dır. Fowler devam ediyor:

Bu yüzden, ilk kılavuzum, bir monolit olarak yönetilemeyecek kadar karmaşık bir sisteme sahip olmadığınız sürece, mikro hizmetleri bile göz önünde bulundurmaz. Yazılım sistemlerinin çoğu tek bir yekpare uygulama olarak kurulmalıdır. Bu monolit içindeki iyi modülerliğe dikkat edin, ancak ayrı servislere ayırmaya çalışmayın.