Merhaba Habr! dikkatinize sunuyorum yazarın makale çevirisi .
BT dünyasının yavaş yavaş Kubernetes gibi mikro hizmetlere ve araçlara yöneldiği bir dönemde tek bir sorun giderek daha fazla dikkat çekiyor. Bu sorun - mikro hizmet sürümleri. Yine de BT topluluğu mevcut durumun şu ankinden çok daha iyi olduğuna inanıyor önceki nesil teknoloji. Ancak mikro hizmetlerin sürümlendirilmesi oldukça karmaşık bir sorundur. Bunun bir kanıtı gibi makaleler olabilir .
Bu metni okuyarak hala sorunu anlamadıysanız, açıklayayım. Diyelim ki ürününüz 10 mikro hizmetten oluşuyor. Şimdi bu microservicelerin her biri için 1 yeni sürümün yayınlandığını varsayalım. Sadece 1 versiyon - Umarım hepimiz bunun çok önemsiz ve önemsiz bir gerçek olduğu konusunda hemfikir olabiliriz. Şimdi ise ürünümüze bir kez daha bakalım. Her bileşenin yalnızca bir yeni versiyonuyla, artık ürünümüzün nasıl oluşturulabileceğine dair 2^10 veya 1024 permütasyona sahibiz.
Hala bir yanlış anlama varsa, matematiği açıklamama izin verin. Yani her biri bir güncelleme alan 10 mikro hizmetimiz var. Yani, her mikro hizmet için (eski veya yeni) 2 olası sürüm alıyoruz. Artık ürün bileşenlerinin her biri için bu iki versiyondan birini kullanabiliriz. Matematiksel olarak bu, 10 basamaklı bir ikili sayıya sahip olmamızla aynıdır. Örneğin, 1'in yeni sürüm olduğunu ve 0'ın eski sürüm olduğunu varsayalım - bu durumda olası bir permütasyon 1001000000 olarak gösterilebilir - burada 1. ve 4. bileşenler güncellenir ve diğerleri güncellenmez. Matematikten, 10 basamaklı bir ikili sayının 2^10 veya 1024 değere sahip olabileceğini biliyoruz. Yani uğraştığımız sayının ölçeğini doğrulamış olduk.
Mantık yürütmemize daha fazla devam edelim - 100 mikro hizmetimiz varsa ve her birinin 10 olası sürümü varsa ne olur? Bütün durum oldukça nahoş bir hal alıyor - artık 10 üzeri 100 permütasyonumuz var - bu çok büyük bir sayı. Ancak ben bu durumu bu şekilde tanımlamayı tercih ediyorum çünkü artık “kubernetes” gibi kelimelerin arkasına saklanmıyoruz, sorunla olduğu gibi yüzleşiyoruz.
Neden bu sorundan bu kadar etkilendim? Kısmen bunun nedeni, daha önce NLP ve yapay zeka dünyasında çalışmış olmamız nedeniyle, yaklaşık 5-6 yıl önce kombinatoryal patlama sorununu çok tartışmış olmamızdı. Sadece versiyonlar yerine tek tek kelimelerimiz vardı ve ürünler yerine cümleler ve paragraflar vardı. Her ne kadar NLP ve yapay zekanın sorunları büyük ölçüde çözümsüz kalsa da, son birkaç yılda önemli ilerlemeler kaydedildiğini kabul etmek gerekir. (bence ilerleme kaydedilebilirоSektördeki insanların makine öğrenimine biraz daha az ve diğer tekniklere biraz daha fazla ilgi göstermeleri daha iyi olurdu - ancak bu zaten konu dışı).
DevOps ve mikro hizmetler dünyasına dönelim. Kunstkamera'da fil kılığına girme gibi büyük bir sorunla karşı karşıyayız - çünkü sıklıkla duyduğum şey "sadece kubernetleri ve dümeni alın, her şey yoluna girecek!" Ama hayır, her şey olduğu gibi bırakılırsa her şey yolunda gitmeyecektir. Üstelik bu problemin analitik çözümü, karmaşıklığı nedeniyle kabul edilebilir görünmemektedir. NLP'de olduğu gibi, bu soruna öncelikle arama kapsamını daraltarak, bu durumda güncelliğini yitirmiş permütasyonları ortadan kaldırarak yaklaşmalıyız.
Yardımcı olabilecek şeylerden biri geçen yıl yazdığım bir şey. . İyi tasarlanmış bir CI/CD sürecinin farklılıkların azaltılmasına büyük ölçüde yardımcı olduğunu unutmamak da önemlidir. Ancak CI/CD ile ilgili mevcut durum, muhasebe ve izleme bileşenleri için ek araçlar olmadan permütasyon sorununu çözecek kadar iyi değildir.
İhtiyacımız olan şey, entegrasyon aşamasında, her bir bileşen için risk faktörünü belirleyebileceğimiz ve aynı zamanda neyin işe yarayıp neyin yaramadığını görmek için çeşitli bileşenleri güncellemek ve operatör müdahalesi olmadan test etmek için otomatik bir sürece sahip olabileceğimiz bir deney sistemidir.
Böyle bir deney sistemi şöyle görünebilir:
- Geliştiriciler testler yazar (bu kritik bir aşamadır, çünkü aksi halde değerlendirme kriterimiz yoktur, makine öğreniminde verileri etiketlemek gibidir).
- Her bileşen (proje) kendi CI sistemini alır - bu süreç artık iyi gelişmiştir ve tek bir bileşen için CI sistemi oluşturma sorunu büyük ölçüde çözülmüştür.
- "Akıllı entegrasyon sistemi" çeşitli CI sistemlerinin sonuçlarını toplar ve bileşen projelerini nihai üründe birleştirir, testleri gerçekleştirir ve son olarak mevcut bileşenlere ve risk faktörlerine dayalı olarak istenen ürün işlevselliğini elde etmenin en kısa yolunu hesaplar. Güncelleme mümkün değilse, bu sistem geliştiricilere mevcut bileşenler ve bunlardan hangisinin hataya neden olduğu konusunda bilgi verir. Entegrasyon sistemi testleri değerlendirme kriteri olarak kullandığı için test sistemi burada da kritik önem taşıyor.
- Daha sonra Akıllı Entegrasyon Sisteminden veri alan ve güncellemeyi doğrudan gerçekleştiren CD sistemi. Bu aşama döngüyü sonlandırır.
Özetlemek gerekirse, benim için şu anki en büyük sorunlardan biri, çeşitli bileşenleri bir ürüne bağlayacak ve böylece ürünün bir bütün olarak nasıl bir araya getirildiğini takip etmenize olanak sağlayacak böyle bir "Akıllı Entegrasyon Sistemi"nin eksikliğidir. Topluluğun bu konudaki düşünceleriyle ilgileneceğim (spoiler - şu anda bir proje üzerinde çalışıyorum) , bu çok akıllı bir entegrasyon sistemi haline gelebilir).
Son olarak belirtmek istediğim bir konu da monolitin orta büyüklükteki bir proje için bile kabul edilemez olduğudur. Monolite geri dönerek uygulama süresini ve geliştirme kalitesini hızlandırma girişimleri benim için büyük şüpheciliğe neden oluyor. Birincisi, monolitin bileşenleri yönetme konusunda benzer bir sorunu var - içerdiği çeşitli kütüphaneler arasında, ancak bunların hepsi o kadar fark edilmiyor ve öncelikle geliştiricilerin harcadığı zamanda kendini gösteriyor. Monolit sorununun sonucu, kodda değişiklik yapmanın neredeyse imkansızlığı ve geliştirme hızının son derece yavaş olmasıdır.
Mikro hizmetler durumu iyileştirir ancak daha sonra mikro hizmet mimarisi, entegrasyon aşamasında kombinatoryal patlama sorunuyla karşı karşıya kalır. Evet genel olarak aynı sorunu geliştirme aşamasından entegrasyon aşamasına taşıdık. Ancak benim görüşüme göre, mikro hizmetler yaklaşımı hala daha iyi sonuçlara yol açıyor ve ekipler sonuçlara daha hızlı ulaşıyor (muhtemelen esas olarak geliştirme biriminin boyutunun küçültülmesi nedeniyle - veya Parti boyutu). Bununla birlikte, monolitten mikro hizmetlere geçiş süreci henüz yeterince iyileştirmedi; mikro hizmet sürümlerinin kombinatoryal patlaması çok büyük bir sorundur ve sorunu çözdükçe durumu iyileştirmek için çok fazla potansiyelimiz var.
Kaynak: habr.com