Geleceği inşa etmek: Mikro hizmet mimarisi

Birkaç yıldır çalışmakta olan bir e-ticaret sistemi için 2-3 yıllık bir mimari yol haritasını tartışırken, tipik soru şudur : mikro hizmet mimarisine geçmemiz gerekiyor mu?

Mikro hizmetler şu anda popüler bir terimdir, bu nedenle onları sistemin evrimi için düşünmek doğaldır. Bununla birlikte, monolitik bir sistemi mikro hizmetlere yeniden tasarlamanın birincil itici güçleri gerçekten iş ve operasyonel niteliktedir, örneğin:

1. İş büyümesi için mimari: Sistem daha fazla müşteriye hizmet verdiğinden ve daha fazla işlem gerçekleştirdiğinden, daha fazla kapasite ve kaynağa ihtiyaç duyar. Ancak, sistemin tüm parçaları aynı hızda büyümeyebilir.
2. Trafik zirvelerinin ele alınması: İdeal olarak, sistem, her zaman en yoğun trafiği desteklemek için altyapının maksimum kapasiteye zorlanmayacağı şekilde otomatik olarak veya en azından dinamik olarak ölçeklenebilmelidir.
3. Daha hızlı pazara sunma süresi: Bir özelliğin eklenmesi veya değiştirilmesi aylar yerine günler veya haftalar aldığında ve aşırı (ve genellikle pahalı) regresyon testi ve tüm ortamı çalıştıran tüm uygulamaların yeniden başlatılmasını gerektirmediğinde, işletme için önemli bir değer vardır. Bunun cevabı, mikro hizmetler tarafından kolaylaştırılan modülerlik ve değiştirilebilirlik için tasarımdır.
4. İçerik ve kullanıcı deneyiminde hızlı, anında değişiklikler: Birçok geleneksel çevrimiçi sistem, içeriği aynı web uygulamasından, aynı zamanda ödeme, hesabım ve diğer özellikler (yani monolit) için de içeren dinamik olarak sunucu tarafında oluşturur. Bu, müşteriye yönelik içeriğin güncel, potansiyel olarak kişiselleştirilmiş ve yönetilebilir olmasına rağmen, bu içeriğin sürekli olarak yeniden oluşturulmasının çok büyük miktarda CPU döngüsü tükettiği, veri depolarında ve potansiyel olarak diğer alt sistemlerde çevrimiçi bağımlılıklar oluşturduğu anlamına gelir.

Mikro hizmet mimarisinin nihai amacı, bu uygulamayı varsayılan içerik sunan, envanter durumu hakkında bilgi sağlayan ve kişiselleştirilmiş teklifler ve öneriler sunan nispeten bağımsız hizmetlere bölmektir. Bu hizmetler daha sonra en iyi kullanıcı deneyimini elde etmek için ayarlanabilir, ölçeklenebilir ve yönetilebilir.

Buradaki fikir, birkaç bağımsız, ölçeklenebilir, değiştirilebilir hizmetten oluşan bir sisteme sahip olmaktır.

Tuğla tuğla: Sistemi kademeli olarak hareket ettirin

O zaman soru şu ki, bu planı nasıl uygulayacağız? Sistemi sıfırdan yeniden yazmak genellikle kabul edilemez. Mevcut platforma yapılan bir yatırım var, işlevsellik test edilmiş ve kanıtlanmış veya mevcut sistemde tamamlanması gereken başka işlevsel geliştirmeler var.

Hedef mimari üzerinde anlaşmak ve yeniden mimari faaliyetleri yol haritası geliştirme planına dahil ederek sistemi kademeli olarak hedefe doğru hareket ettirmek daha iyi bir yaklaşım olabilir:

1. En öncelikli iş sorununu ele alacak bir değişiklik belirleyin ve yeniden düzenleme/taşıma için plan yapın. Örneğin, değişikliklerin siteye daha hızlı aktarılabilmesi için “ sistemin işlemsel bölümlerinden içerik yönetimini ayırmak ”.
2. Bir özellik eklerken (örneğin, 'Beğenebilirsiniz' veya 'Ek bir X harcarsanız…') mevcut uygulamaya karıştırmak yerine, bunun bir arayüzü ortaya çıkaran bağımsız bir hizmet olarak değer sağlayabilecek bir şey olup olmadığını düşünün ve bağımsız olarak yönetilebilir. Bağımsız bir süreç olarak çalışmasına veya başlangıçta kendi başına konuşlandırılabilir olmasına gerek yoktur, ancak iyi anlaşılmış minimum bağımlılıklarla iyi bir şekilde kapsüllenmiş olmalıdır.
3. Bir alt sistemde önemli bir değişiklik yaparken (örneğin, Hesabım) bunu kendi başına bir uygulama veya hizmet yapmak için doğru zaman olup olmadığını düşünün. Yine, önemli faktör, hem kod hem de çalışma zamanı düzeyindeki bağımlılıkları dikkate almaktır.

MyAccount hizmetinde bir değişiklik yapmak, diğer tüm modüllerin yeniden derlenmesini ve yeniden dağıtılmasını gerektiriyorsa, bu (henüz) geçiş için iyi bir aday değildir. Ancak, kendi özel alan endişelerini kapsayan başka aday modüller de olabilir:

• • Müşteri e-posta iletişim hizmeti
  • Hizmet olarak ödeme
  • Öğe kullanılabilirliği hizmeti
  • Ticaret arama motoru
  • Çeşitli kişiselleştirme, danışmanlık veya tavsiye hizmetleri
  • Ürün incelemeleri/derecelendirme hizmeti

Projenizi doğru şekilde ölçeklendirme: Mikro hizmet mimarisi süreçlerini ve planlarını tanımlama

Gördüğünüz gibi, bu resim, hizmetlerin sayısı arttıkça ve çözümün artan karmaşıklığı hissine katkıda bulunarak, hızlı bir şekilde meşgul hissetmeye başlayabilir. Bununla başa çıkmak için ekiplerin projenin aşağıdaki yönlerine ekstra dikkat etmesi gerekir:

Mimari netliği: Bu, mutlaka 'önden büyük bir tasarım' yaklaşımı anlamına gelmez, ancak ekibin, sistemin hangi hizmetlerden oluşturulacağı ve hizmetlerin nasıl oluşturulacağı, dağıtılacağı konusunda ortak bir vizyonu ve anlayışı paylaşması gerekir. , ve izlenir. Ekibin farklı uygulamaları (API öncelikli), çerçeveleri (Spring Cloud), ortak uygulama altyapısı öğelerini (API Ağ Geçidi, kimlik doğrulama sunucusu, hizmet kaydı vb.) benimsemeye hazır olması gerekir. Bunların tümü her zaman gerekli değildir, ancak olması gerekir. sistemin bir parçası olup olmayacakları bilinçli bir mimari karar.

DevOps: Bu, başka bir popüler terimdir, ancak bu bağlamda son derece önemlidir. Sistem büyüdükçe hizmetlerin sayısı bunaltıcı hale gelebilir, bu nedenle mikro hizmetler dünyasında DevOps gerekli bir unsurdur. Bu, yapıların otomasyonu ve akıcı hale getirilmesi, dağıtımın test edilmesi, yeniden başlatmalar, otomatik ölçeklendirme, uyarı vb. anlamına gelir. Birkaç uygulama sunucusuna dağıtılan tek bir ikili dosyayla ilgilenmiyoruz. Her biri potansiyel olarak birden çok durumda çalışan düzinelerce daha küçük işlevsellik parçası olabilir, bu kimsenin manuel olarak desteklemek isteyeceği bir şey değildir. Çalışan tüm bu uygulamalardan manuel olarak günlükler topladığınızı hayal edin…

Mikro hizmet mimarisi: Doğru yapmak

Mikro hizmetlere geçişi yanlış anlamanın birçok yolu vardır: Gerçek bir iş gerekçesi olmadan, yalnızca teknolojinin vızıltısını takip ederek, birbirine fazlasıyla bağımlı olan uygun olmayan hizmetleri belirleyerek, karmaşıklığı ele almak için DevOps uygulamalarını benimsemede başarısız olarak, takım içinde doğru beceriler vb.

Bununla birlikte, uygun planlama ve risk yönetimi ile, bir süre sonra (ve stres ve şüpheler ve PM'nin paniklemesi) ekip, bazı olumlu etkiler hissetmeye başlamalıdır:

• Sistem veya önemli parçaları daha iyi ölçeklenir
• Gecenin ortasında her şeyi yeniden başlatmak zorunda kalmadan yeni bir özellik sunmak daha kolay
• Sistem bileşenlerinin daha net bir amacı vardır ve bu nedenle geliştirilmesi, test edilmesi ve değiştirilmesi daha kolaydır

Mimari yol haritası, gelecekte iki-üç yıl için sistem evriminin yönünü belirlemeye yardımcı olan araçtır.

İş yol haritası, stratejik teknoloji ve endüstri yönü ile ekip becerileri ve kabiliyeti ile iyi bir şekilde uyumlu olması gerekir. Özellikle mikroservisler gibi yeni mimari kavramların ve yaklaşımların tanıtılmasıyla önemi daha da artmaktadır.