Görünüşe göre mikro hizmetlere yönelik ilginin zirvesi geride kaldı. Artık haftada birkaç kez “Monolitimi 150 hizmete nasıl taşıdım?” yazılarını okumuyoruz. Artık daha sağduyulu düşünceler duyuyorum: "Tek parçadan nefret etmiyorum, sadece verimliliği önemsiyorum." Hatta birkaç göç gözlemledik . Büyük bir uygulamadan birden fazla küçük hizmete geçerken birçok yeni sorunu çözmeniz gerekecektir. Bunları mümkün olduğunca kısaca listeleyelim.
Ortam: temel kimyadan kuantum mekaniğine
Temel bir veritabanı ve arka plan işlemine sahip bir uygulama oluşturmak oldukça basit bir süreçti. Benioku dosyasını Github'da yayınlıyorum - ve genellikle bir saat, en fazla birkaç saat sonra her şey çalışır ve yeni bir projeye başlarım. En azından başlangıç ortamı için kod ekleme ve çalıştırma birinci günde yapılır. Ancak mikro hizmetlere yönelirsek ilk lansman süresi hızla artar. Evet, artık orkestrasyonlu Docker'ımız ve bir grup K8 makinemiz var, ancak acemi bir programcı için tüm bunlar çok daha karmaşık. Birçok genç için bu gerçekten gereksiz bir komplikasyon olan bir yüktür.
Sistemi anlamak kolay değil
Bir an için gençlerimize odaklanalım. Monolitik uygulamalarda, bir hata oluştuğunda onu takip etmek ve hemen hata ayıklamaya geçmek kolaydı. Artık, başka bir hizmeti işleyen bir mesaj veriyolunda bir şeyi sıraya koyan başka bir hizmetle konuşan bir hizmetimiz var ve sonra bir hata oluşuyor. Sonunda Hizmet A'nın sürüm 11'i çalıştırdığını ve Hizmet E'nin zaten sürüm 12'yi beklediğini öğrenmek için tüm bu parçaları bir araya getirmemiz gerekiyor. Bu benim standart birleştirilmiş günlüğümden çok farklı: yürümek için etkileşimli bir terminal/hata ayıklayıcı kullanmak zorunda olmak süreci adım adım tamamlıyoruz. Hata ayıklama ve anlama doğası gereği daha zor hale geldi.
Eğer hata ayıklanamıyorsa belki onları test ederiz
Sürekli entegrasyon ve sürekli gelişim artık sıradan hale geliyor. Gördüğüm çoğu yeni uygulama, her yeni sürümde otomatik olarak testler oluşturup çalıştırıyor ve kayıttan önce testlerin yapılıp incelenmesini gerektiriyor. Bunlar terk edilmemesi gereken harika süreçler ve birçok şirket için büyük bir değişim oldu. Ancak şimdi hizmeti gerçekten test etmek için uygulamamın tam çalışan bir sürümünü çıkarmam gerekiyor. 8 hizmetten oluşan K150 kümesine sahip yeni mühendisi hatırlıyor musunuz? Şimdi CI sistemimize, her şeyin gerçekten çalıştığını doğrulamak için tüm bu sistemleri nasıl çalıştıracağımızı öğreteceğiz. Bu muhtemelen çok fazla çaba gerektireceğinden her parçayı ayrı ayrı test edeceğiz: Spesifikasyonlarımızın yeterince iyi olduğundan, API'lerin temiz olduğundan ve hizmet arızasının izole edildiğinden ve diğerlerini etkilemeyeceğinden eminim.
Tüm tavizlerin iyi bir nedeni vardır. Sağ?
Mikro hizmetlere geçmenin birçok nedeni vardır. Bunun daha fazla esneklik, ekipleri ölçeklendirmek, performans ve daha iyi sürdürülebilirlik sağlamak için yapıldığını gördüm. Ancak gerçekte, gelişmeye devam eden monolitleri geliştirmek için onlarca yıl boyunca araç ve uygulamalara yatırım yaptık. Farklı teknolojilerdeki profesyonellerle çalışıyorum. Genellikle ölçeklendirmeden bahsediyoruz çünkü tek bir Postgres veritabanı düğümünün sınırlarına giriyorlar. Konuşmaların çoğu bununla ilgili .
Ama her zaman mimarileri hakkında bilgi edinmek ilgimi çekiyor. Mikro hizmetlere geçişin hangi aşamasındalar? Monolitik uygulamalarından memnun olduklarını söyleyen daha fazla mühendis görmek ilginç. Birçok kişi mikro hizmetlerden faydalanacak ve faydalar, geçiş yolundaki engellerden daha ağır basacaktır. Ama şahsen, lütfen bana yekpare başvurumu, sahilde bir yer verin - ve ben tamamen mutluyum.
Kaynak: habr.com