Shoprocket'ın Mikroservislere Yolculuğu: Bölüm 1

Shoprocket'teki işimin birkaç ayında, sinirlenmeye başladım. Küçük, zeki geliştiricilerden oluşan takımımızla dünya çapında üzerinde çalıştığımız bir PHP uygulamamız vardı. Neden sinirleniyordum? Bana kalırsa, hata düzeltmeleri daha fazla hataya neden oluyordu, yeni özelliklerin entegrasyonu olması gerektiği kadar basit değildi ve dağıtımlar nadir ve stresliydi. Bu problemlerin sebebi: oldukça bağlı kod.

Monolitik bir uygulamamız vardı ve neredeyse tüm kod tabanımız bir Github deposunda yer alıyordu. Bir özelliğe yapılacak güncellemeler veya düzeltmeler genellikle birçok yerde gerçekleşiyordu. Test amacıyla, en az iki diğer geliştiricinin bir dalı onaylaması gereken bir akran inceleme sürecimiz vardı, sonra bu dal ana dal ile birleştirilip dağıtılabiliyordu. Tüm bunlar, hatalar gizlice geçip girdiğinde, kırıcı değişiklikleri bulmanın genellikle zor olduğu anlamına geliyordu. Ve bulduğumuzda, düzeltmeler aynı süreçten geçecek ve tüm uygulamanın yeniden dağıtılması gerekecekti.

Her zaman yeni şeyler arayan hevesli bir genç geliştirici olarak, mikro hizmetlerle karşılaştığımda, bu mimari stilin tüm sorunlarımızı çözeceğini düşündüm. Mikro hizmetlerin resmi bir tanımı yok, ama araştırmalarımdan anladığım kadarıyla mikro hizmet mimarisi, bağımsız hizmetlerin dağıtılmış sistemler olarak tasarlanması yoludur; her biri son derece özel ve kendi yaşam döngüsüne sahiptir. Daha ayrıntılı bir kavramsal tanıtım isteyen okuyucular için Martin Fowler'ın mükemmel makalesini öneririm.

Mikro hizmetlerde ilgilendiğim birçok yön vardı ama özellikle iki tanesi: Öncelikle, uygulamayı çok sıkı sınırlarla hizmetlerine ayırma fikri. Bu, belirli bir iş bağlamına özgü mantığın bileşenler arasında sızma şansını azaltır çünkü sınırlar arasındaki arayüzlerin dikkatlice planlanması gerekir. Yerel işlev çağrıları yapmaktan daha basit değil; İkincisi, her bileşen kendi bağımsız yaşam döngüsüne sahip olabilir. Bu takımların kendi kodları üzerinde sahiplik almasını sağlar ve her bir hizmet için en uygun teknoloji yığını kullanılabilir. Ayrıca, değişikliklerin bir seferde bir hizmete dağıtılmasına olanak tanır ve eğer bir şeyler ters giderse, uygulamanın geri kalanını etkilemeden geri alınabilir.

Bu yüzden, buna ikna oldum. Shoprocket monoliti parçalayacaktı! Bu yolculuğu takip eden kısa bir blog yazısı serisinin ilkine hoş geldiniz. Umarım, benzer bir geçişi planlayan veya yaşayan okuyucular, başarılarımızdan ve başarısızlıklarımızdan ders alır ve kendi projelerinde bu zorluğu üstlenmeye daha iyi hazırlanmış hissederler.

İlk zorluğum teknik değildi, insaniydi. Fikri geri kalan ekibe satmam gerekmekteydi. Meraklı görünüyorlardı ama aynı heyecanı paylaşmıyorlardı ve ürünümüzün bu erken aşamasında geliştirme saatlerinden vazgeçmeye istekli değildiler. Neyse ki, CTO'muz oturum yönetimimize bakmamı istedi ve ben de bir oturum hizmeti ayırabileceğimi ikna ederek fırsatı değerlendirdim.

Gerçekten de, ilk hizmet için belki de kötü bir bileşen seçimi yaptım. Ürünümüz, herhangi bir web sitesinde e-ticareti etkinleştiren bir javascript eklentisi içeriyor. Oturumları bir kaynak olarak ele alıyoruz ve oturum bilgilerini veritabanına kaydederek sepet terk etme oranları gibi KPI'ların detaylı analizini sağlıyoruz. Ancak bu kaynak, siparişler veya satır öğeleri gibi somut bir şey değil. Dahası, uygulama durumu değiştikçe hemen hemen her değişiklikle oturum kaynağını kullanıyorduk. Bu durum, hizmetin uygulamanın geri kalanı ile kaçınılmaz olarak çok iletişimli olacağı anlamına geliyordu ki, bunu öngörememiştim, bu da görevimi zorlaştırıyordu.

Patronumu ikna ettikten sonra, mikro hizmetler üzerine araştırmalarımı hızlandırdım. Daha önce bahsettiğim makalenin yanı sıra, Sam Newman'ın 'Mikro Hizmetler İnşası' adlı kitabını da çok değerli bir kaynak olarak buldum. Her iki kaynağa da sık sık referans vereceğim.

Newman kitabında, önce mevcut bir uygulamanın alanın sınırlı bağlamlarını yansıtan modüller haline yeniden yapılandırılmasını öneriyor. Ardından, geliştiriciler memnun olduğunda, modüller kendi hizmetlerine ayrılabilir. Bunun nedeni, eğer sınırları kötü seçilmişse, modülleri kırmanın ve yeniden yazmanın, tüm ek kısa çerçeveler ve kalıcı kaynaklarla birlikte tüm hizmetleri kırmaktan çok daha kolay olmasıdır. Ancak, zaman kısıtlamaları ve kendi bileşenimi oluşturma isteğim nedeniyle, ilk hizmetle devam ettim.

Kullandığımız monolitik yapıdan sadece kısmen farklı bir yığın seçtim ve inşa etmeye başladım. İnşaat hızlı bir şekilde ilerledi, bağımsız bir uygulama ile REST API'si oluşturmak birkaç hafta sürdü. Ancak o zaman gerçek zorluklar başladı.

Hizmeti monolit ile iletişim kurdurmam gerekiyordu. Bu noktada, oturum yönetiminin geri kalan kodla ne kadar sıkı bir şekilde bağlı olduğunu öğrendim. Mevcut işlev çağrılarını kırmak ve bunları API çağrılarına çevirmek biraz zaman aldı. Bu zordu. Oturum hizmeti ile monolitin kendi veritabanı şemaları olduğundan, eski veritabanından oturum kaynaklarını kullanan monolitteki herhangi bir mantığı yeniden yazmak zorunda kaldım ve javascript eklentisi gibi istemcilerle uyumluluğu korumak için uygulama sınırında verileri yeniden yapılandırmam gerekiyordu.

Hizmeti mevcut uygulamamızla entegre etmek, hizmeti yazmaktan daha uzun sürdü ve bu, mikro hizmetlerin genellikle getirdiği hizmet keşfi, günlüğe kaydetme ve izleme gibi birçok ekstra yükü içermiyordu. Dahası, sıkı bağlantı nedeniyle, kodun birçok alanında değişiklikler yapıldı. Takım bu süre zarfında kodun çeşitli alanları üzerinde paralel çalıştığı için, değişiklikleri birleştirip oturum hizmetini üretime almak için çok daha fazla iş gerekecekti.

Hizmet yakında üretime girebilir, ancak şimdi Newman'ın tavsiyesini takip edip mevcut uygulamamızı modüler hale getirmek için çabalarımı harcamalıydım. Tek başına bir hizmetin faydası çok az. Gerçek fayda, tüm şeyi, en azından çok kaba hizmetlere ayırmaktan gelir; bu, mümkün olduğunca az konuştuğu bir yapı ister ve henüz oraya ulaşmadık.

Mikro hizmetler fikrine hala bağlıyım ve bir hizmet ayırma çabamı başarılı bir deney olarak görüyorum. Uygulama mimarisinde ve alan modellemesinde çok şey öğrendim ve REST ilkelerine olan anlayışımı, başka şeylerin yanı sıra geliştirdim. Bunlar, kodumuzun diğer alanlarında hemen yankı buldu.

Dönüşüm yapmak isteyen okuyucular için, bu konuda mümkün olduğunca çok şey okumalarını ve mevcut kod tabanınıza ve alan modelinize güvenene kadar çalışmayı ertelemelerini öneririm. Monolitik bir uygulamada istikrar ve dayanıklılık sağlamak için başka yollar da var. Test odaklı geliştirme ve otomatik birim ve işlevsel testler büyük ölçüde yardımcı olur. Ayrıca, yatay ölçeklendirme dağıtımları biraz daha sorunsuz hale getirir.

Shoprocket mikro hizmetler yolculuğuna devam edecek. Bölüm 2'de daha fazla bilgi vermeyi sabırsızlıkla bekliyoruz!