Altyapınızdaki eski hizmetler

Merhaba! Adım Pasha Chernyak, QIWI'nin lider geliştiricisiyim ve bugün kaçınılmaz olan hakkında konuşmak istiyorum. Miras Hakkında.

Şu soruyla başlayalım: Eski hizmet nedir? Eski bir hizmet, geliştiricinin bir hafta/ay/yıl boyunca dokunmadığı bir hizmet midir? Yoksa daha az deneyimli bir programcı tarafından, örneğin sizin tarafınızdan, ancak bir yıl önce yazılan bir hizmet mi? Artık daha havalı ve daha tecrübelisin. Yoksa Eski hizmet, bir daha asla kullanmamaya karar verdiğiniz ve yavaş yavaş yerine yenisini hazırladığınız bir hizmet mi? Her halükarda böyle bir hizmeti gözetimsiz bırakmak ve güncelleme yapmamak daha sonra patlayabilecek bir saatli bombadır.

QIWI olarak Legacy hizmetlerimizle nasıl çalıştığımıza geçmeden önce Cüzdan'daki hizmetlere nasıl düzen getirdiğimizi anlatacağım. İki yıldır performansından ben sorumluyum. Bir sorun olursa her zaman önce beni ararlar. Genelde gece 11:XNUMX'te başka birini aramaya cesaretim olmuyor, bu yüzden oturup alanımızdaki tüm hizmetleri çözmem gerekti.

Ama ben de herkes gibi geceleri uyumayı seviyorum, bu yüzden sömürüyle baş etmeye çalıştım: "Beyler, beni neden arıyorsunuz?" Buna “Başka kim?” gibi oldukça kısa ve öz bir cevap aldım. Çünkü hizmetleri tamir ediyorum ve adamlar kimi arayacaklarını bilmiyorlar.

Bu nedenle Cüzdan arka uç ekibinin retrospektiflerinden birinde hizmetlerimizin, mikro hizmetlerimizin ve cüzdan monolitlerimizin ve bunlardan sorumlu olanların bir listesini içeren bir tabela yapmamız gerektiğine karar verdik. İşaretler makul sınırlar dahilinde genellikle faydalıdır.

Kimin neden sorumlu olduğuna ilişkin bilgilerin yanı sıra, hizmetin sahibi kim, geliştirilmesinden, mimarisinden ve yaşam döngüsünden kim sorumlu sorularına da yanıtlar vardı. Bu hizmetten sorumlu kişiler, bir şey olması durumunda sorunu çözebilecek kişilerdir. Hizmetin sahibi, taahhütlerde +2 bırakma hakkına sahiptir, bu hizmetin yeni bir taahhüt kabul etmesinden önce sorumluların da incelemede hazır bulunması gerekir.

Zaman geçtikçe Kubernetes'e geçiş, her türlü kontrol stili, spotbug, ktlint, Kibana'da logların bulunması, adresleri doğrudan belirtmek yerine otomatik keşif hizmetleri ve diğer yararlı şeyler gibi yeni uygulamalar uygulanmaya başlandı. Ve her yerde masamız hizmetlerimizin alaka düzeyini korumamıza izin verdi. Bizim için bu, bu servisin bunu yapabileceğini ama henüz yapmadığını söyleyen bir tür kontrol listesi. Ancak takip ettiğimiz hizmetlerimiz, hizmet kaynaklarının nerede bulunduğu hakkında bilgimizin eksik olduğunu fark ederek yolumuza devam ettik. TeamCity'de montaj görevlerinin nerede başlatıldığı, nasıl dağıtıldıkları, end2end testlerinin kaynaklarının nerede saklandığı, mimariyle ilgili bakım oturumlarından fotoğraflar, alınan kararlarla ilgili. İdeal olarak, tüm bu bilgilerin bir yerlerde olmasını ve ihtiyaç duyulduğunda el altında olmasını isterim. Dolayısıyla burcumuz bilgi arayışının başlangıç ​​noktası oldu.

Ancak QIWI, startup ruhunu korusa da büyük bir şirkettir. Zaten 12 yaşındayız ve takımlar değişiyor: insanlar gidiyor, insanlar geliyor, yeni takımlar oluşuyor. Ve alan adımızda devraldığımız birçok hizmeti keşfettik. Bazıları diğer ekiplerdeki geliştiricilerden geldi, bazıları ise bir şekilde dolaylı olarak Cüzdan'la ilişkiliydi; dolayısıyla hizmet artık bilançomuzda yer alıyor. Neyin ve nasıl çalıştığını anlamak - neden? Hizmet işe yarıyor ve kesinlikle iyileştirilmesi gereken ürün özelliklerimiz var.

Nasıl oluyor

Ancak bir noktada hizmetin işlevini yerine getirmeyi bıraktığını, bir şeylerin bozulduğunu keşfederiz - böyle bir durumda ne yapmalı? Hizmet çalışmayı durdurdu. Kesinlikle. Ve bunu ilk olarak tesadüfen ve ikinci olarak altı ay sonra öğrendik. Olur. Bildiğimiz tek şey hizmetin hangi sanal makinelere dağıtılacağı, kaynaklarının nerede bulunacağıydı ve hepsi bu. Git klonu yapıyoruz ve birkaç yıl önce bunu yazan kişinin aklına dalıyoruz ama ne görüyoruz? Bize tanıdık gelen Spring Boot'lardan hiçbiri yok, her şeye alışkın olmamıza rağmen, tam bir yığınımız var falan. Belki orada bir Bahar Çerçevesi vardır? Ama hayır.

Bütün bunları yazan adam sert biriydi ve her şeyi saf Java ile yazmıştı. Bir geliştirici için alışılagelmiş araçlar yoktur ve bir fikir ortaya çıkar: Tüm bunları yeniden yazmamız gerekiyor. Mikro hizmetlerimiz var ve her ekmek kızartma makinesinden her zamanki gibi "Arkadaşlar, ihtiyacınız olan şey mikro hizmetler!" Aniden bir şeyler ters giderse, herhangi bir dili sakince alabilirsiniz ve her şey yoluna girecek.

Sorun şu ki artık bu hizmetten sorumlu bir müşterimiz yok. Hangi iş gereksinimlerine sahipti, bu hizmet ne yapmalıydı? Ve hizmet, iş süreçlerinize sıkı bir şekilde entegre edilmiştir.

Şimdi söyleyin bana, iş gereksinimlerini bilmeden bir hizmeti yeniden yazmak ne kadar kolaydır? Hizmetin nasıl günlüğe kaydedildiği açık değil; metriklerin olup olmadığı bilinmiyor. Varsa bile bunların ne olduğu daha da bilinmiyor. Ve aynı zamanda hizmet, çok sayıda anlaşılmaz iş mantığı sınıfını içerir. Bir tür veritabanına, henüz hakkında hiçbir şey bilmediğimiz bir şey dahil edilmiştir.

Nereden başlamalı?

En mantıklı noktadan - testlerin mevcudiyeti. Genellikle orada en azından bir miktar mantık yazılıdır ve olup bitenler hakkında sonuçlar çıkarabilirsiniz. Artık TDD moda ama 5 yıl önce her şeyin neredeyse şimdikiyle aynı olduğunu görüyoruz: neredeyse hiç birim testi yok ve bize hiçbir şey söylemiyor. Belki bir tür doğrulama dışında, bazı xml'lerin bazı özel sertifikalarla nasıl imzalandığı.

Koddan hiçbir şey anlayamadık ve sanal makinede ne olduğuna bakmaya gittik. Hizmet günlüklerini açtık ve içlerinde bir http istemci hatası bulduk; uygulama kaynaklarına gömülü kendinden imzalı sertifika utanmadan çürümüştü. Analistlerimizle iletişime geçtik, yeni bir sertifika istediler, bize verdiler ve hizmet yeniden çalışıyor. Görünüşe göre hepsi bu. Ya da değil? Sonuçta hizmet çalışıyor, işimizin ihtiyaç duyduğu bazı işlevleri yerine getiriyor. Uygulama geliştirme konusunda belirli standartlarımız var ve muhtemelen siz de buna sahipsiniz. Örneğin, günlükleri düğümdeki bir klasörde saklamayın, bunları elastik gibi bir tür depolama alanında saklayın ve bunlara Kibana'da bakın. Altın metrikleri de hatırlayabilirsiniz. Yani servisin üzerindeki yük, servise gelen talep sayısı, hayatta olup olmadığı, HealthCheck'inin nasıl gittiği. En azından bu ölçümler, ne zaman vicdan rahatlığıyla hizmet dışı bırakılabileceğini ve kötü bir rüya gibi unutulabileceğini bilmenize yardımcı olacaktır.

Ne yapmalı

Bu nedenle, bu kadar eski bir hizmeti masaya ekliyoruz ve ardından geliştiriciler arasından hizmetle ilgilenecek ve onu düzene koyacak gönüllüler aramaya başlıyoruz: hizmet hakkında en azından bazı bilgiler yazacaklar, bağlantılar ekleyecekler grafana'daki kontrol panellerine, montaj görevlerine ve uygulamanın nasıl dağıtıldığını anlayın, dosyaları ftp kullanarak manuel olarak yüklemeyin.

Önemli olan tüm bu yararlı gönüllü faaliyetin ne kadar süreceğidir? Az ya da çok deneyimli bir geliştirici için bir sprint, örneğin %20'lik bir teknik borç sırasında. Belirli bir devlet sistemiyle iletişim kurmanın tüm kökleşmiş mantığını anlamak ve bunu daha yeni teknolojilere taşımak ne kadar zaman aldı? Buna kefil olamam, ekibin belki bir, belki iki aylık çalışmasına kefil olamam. Bunu bazı yeni hizmetlerle mevcut entegrasyon deneyimime dayanarak söylüyorum.

Aynı zamanda iş değerinin serbest bırakılması da söz konusu değildir. Kesinlikle. Destek için bir hizmet kiralamak ve buna biraz zaman harcamak normaldir. Ancak servisle yaptığımız standart danslardan sonra onu da masaya ekledik, onunla ilgili bilgiler ekledik ve belki bir gün yeniden yazacağız. Ama artık hizmet standartlarımızı karşılıyor.

Sonuç olarak, Legacy hizmetleriyle ne yapılacağına dair bir plan yapmak istiyorum.

Mirası sıfırdan yeniden yazmak kötü bir fikir
Cidden, bunu düşünmene bile gerek yok. Bunu istediğim açık ve bazı avantajları var, ancak genellikle siz dahil kimsenin buna ihtiyacı yok.

Rehber
Uygulamalarınızın kaynak kodlarını kazın, neyin nerede ve nasıl çalıştığını gösteren bir referans kitabı yapın, günlüklerin ve ölçümlerin nerede bulunduğunu hızlı bir şekilde anlamak için oraya projenin bir açıklamasını (koşullu benioku.md) girin. Sizden sonra bu konuyla ilgilenecek geliştirici sadece teşekkür edecek.

Alanı anlayın
Bir alan adınız varsa parmağınızı nabzında tutmaya çalışın. Evet, kulağa önemsiz geliyor ama herkes hizmetlerin tek bir anahtarda olduğundan emin değil. Ancak tek bir standartta çalışmak aslında önemli ölçüde daha kolaydır.

Ankete sadece kayıtlı kullanıcılar katılabilir. Giriş yapLütfen.

Mirasınızla ne yaparsınız?

• %31.5Sıfırdan yeniden yazıyorum, daha doğru 12

• %52.6Neredeyse seninle aynı20

• %10.5Mirasımız yok, biz harikayız4

• %5.2Yorumlara yazacağım2

38 kullanıcı oy kullandı. 20 kişi çekimser kaldı.

Kaynak: habr.com