Rusya'da 2019'dan bu yana zorunlu etiketlemeye ilişkin bir yasa var. Kanun tüm mal grupları için geçerli olmayıp, ürün grupları için zorunlu etiketlemenin yürürlüğe giriş tarihleri farklıdır. Zorunlu etiketlemeye tabi ilk ürünler tütün, ayakkabı ve ilaçlar olacak; parfüm, tekstil ve süt gibi diğer ürünler ise daha sonra eklenecek. Bu mevzuat yeniliği, bir ürünün üretimden son tüketici tarafından satın alınmasına kadar tüm yaşam zincirinin, süreçteki tüm katılımcılara (hem devlete hem de mal satan tüm kuruluşlara) kadar takip edilmesini mümkün kılacak yeni BT çözümlerinin geliştirilmesini teşvik etti. zorunlu etiketleme.
X5'te etiketli malların takibini yapacak, devlet ve tedarikçilerle veri alışverişinde bulunacak sisteme “Marcus” adı veriliyor. Şimdi size onu nasıl ve kimin geliştirdiğini, teknoloji yığınının ne olduğunu ve neden gurur duyacağımız bir şey olduğunu anlatalım.
Gerçek Yüksek Yük
“Marcus” birçok sorunu çözüyor; asıl sorun, etiketli ürünlerin hareketini izlemek için X5 bilgi sistemleri ile etiketli ürünler için durum bilgi sistemi (GIS MP) arasındaki entegrasyon etkileşimidir. Platform aynı zamanda tarafımızca alınan tüm etiketleme kodlarını ve bu kodların nesneler arasındaki hareketinin tüm geçmişini de saklar ve etiketli ürünlerin yeniden sınıflandırılmasının ortadan kaldırılmasına yardımcı olur. İlk grup etiketli ürünler arasında yer alan tütün ürünlerini örnek alırsak, sadece bir kamyon dolusu sigara yaklaşık 600 paket içermektedir ve her birinin kendine özgü kodu bulunmaktadır. Sistemimizin görevi, bu tür her paketin depolar ve mağazalar arasındaki hareketlerinin yasallığını takip etmek ve doğrulamak ve sonuçta bunların son alıcıya satışının kabul edilebilirliğini doğrulamaktır. Saatte yaklaşık 000 nakit işlemini kaydediyoruz ve ayrıca bu tür her paketin mağazaya nasıl girdiğini de kaydetmemiz gerekiyor. Böylece nesneler arasındaki tüm hareketleri hesaba katarak yılda on milyarlarca kayıt bekliyoruz.
M Takımı
Marcus X5 bünyesinde bir proje olarak görülse de ürün yaklaşımı kullanılarak hayata geçiriliyor. Ekip Scrum'a göre çalışır. Proje geçen yaz başladı ancak ilk sonuçlar ancak Ekim ayında geldi; kendi ekibimiz tamamen toplandı, sistem mimarisi geliştirildi ve ekipman satın alındı. Şu anda ekipte 16 kişi var; bunlardan altısı arka uç ve ön uç geliştirmeyle, üçü ise sistem analiziyle ilgileniyor. Altı kişi daha manuel, yükleme, otomatik test ve ürün bakımıyla ilgileniyor. Ayrıca bir SRE uzmanımız var.
Ekibimizde yalnızca geliştiriciler kod yazmakla kalmıyor; neredeyse tüm kişiler otomatik testleri, yükleme komut dosyalarını ve otomasyon komut dosyalarını nasıl programlayacaklarını ve yazacaklarını biliyor. Ürün desteği bile yüksek düzeyde otomasyon gerektirdiğinden buna özellikle dikkat ediyoruz. Daha önce programlama yapmamış meslektaşlarımıza her zaman tavsiyelerde bulunmaya ve onlara yardım etmeye çalışıyoruz ve onlara üzerinde çalışmaları için bazı küçük görevler veriyoruz.
Coronavirüs salgını nedeniyle tüm ekibi uzaktan çalışmaya aktardık; geliştirme yönetimi için tüm araçların kullanılabilirliği, Jira ve GitLab'da yerleşik iş akışı bu aşamayı kolayca geçmeyi mümkün kıldı. Uzaktan geçirilen aylar, sonuç olarak ekibin üretkenliğinin düşmediğini gösterdi; çoğu kişi için iş yerindeki konfor arttı, eksik olan tek şey canlı iletişimdi.
Uzaktan ekip toplantısı
Uzaktan çalışma sırasında toplantılar
Çözümün teknoloji yığını
X5 için standart depo ve CI/CD aracı GitLab'dır. Bunu kod depolama, sürekli test etme ve test ve üretim sunucularına dağıtım için kullanıyoruz. Geliştiricinin kodda yaptığı değişiklikleri en az 2 çalışanın onaylaması gerektiğinde de kod inceleme uygulamasını kullanırız. Statik kod analizörleri SonarQube ve JaCoCo, kodumuzu temiz tutmamıza ve gerekli düzeyde birim testi kapsamını sağlamamıza yardımcı olur. Kodda yapılan tüm değişikliklerin bu kontrollerden geçmesi gerekir. Manuel olarak çalıştırılan tüm test komut dosyaları daha sonra otomatikleştirilir.
“Marcus”un iş süreçlerini başarılı bir şekilde hayata geçirebilmesi için her biri sırayla olmak üzere bir takım teknolojik sorunları çözmemiz gerekiyordu.
Görev 1. Sistemin yatay ölçeklenebilirliğine duyulan ihtiyaç
Bu sorunu çözmek için mimaride mikro hizmet yaklaşımını seçtik. Aynı zamanda hizmetlerin sorumluluk alanlarının anlaşılması da çok önemliydi. Süreçlerin özelliklerini dikkate alarak bunları ticari operasyonlara ayırmaya çalıştık. Örneğin, bir depoda kabul çok sık değil, çok büyük ölçekli bir işlemdir; bu sırada, bir teslimatta sayısı 600000'e ulaşan, kabul edilen mal birimleri hakkında devlet düzenleyicisinden hızlı bir şekilde bilgi alınması gerekir. , bu ürünün depoya kabul edilebilirliğini kontrol edin ve depo otomasyon sistemi için gerekli tüm bilgileri gönderin. Ancak depolardan sevkiyatın yoğunluğu çok daha fazladır ancak aynı zamanda küçük hacimli verilerle çalışır.
Tüm hizmetleri durum bilgisi olmayan bir temelde uyguluyoruz ve hatta Kafka'nın öz konuları dediğimiz şeyleri kullanarak iç işlemleri adımlara ayırmaya çalışıyoruz. Bu, bir mikro hizmetin kendisine bir mesaj göndermesidir; bu, daha fazla kaynak yoğun işlemlerde yükü dengelemenize olanak tanır ve ürün bakımını basitleştirir, ancak bu konuya daha sonra değineceğiz.
Harici sistemlerle etkileşim için modülleri ayrı hizmetlere ayırmaya karar verdik. Bu, harici sistemlerin API'lerinin sık sık değişmesi sorununu, iş işlevselliğine sahip hizmetler üzerinde neredeyse hiçbir etki yaratmadan çözmeyi mümkün kıldı.
Tüm mikro hizmetler, hem her bir mikro hizmeti ölçeklendirme sorununu çözen hem de üçüncü taraf Hizmet Keşif araçlarını kullanmamamıza olanak tanıyan bir OpenShift kümesinde dağıtılır.
Görev 2. Platform hizmetleri arasında yüksek yük ve çok yoğun veri alışverişini sürdürme ihtiyacı: Yalnızca projenin lansman aşamasında saniyede yaklaşık 600 işlem gerçekleştiriliyor. Perakende satış noktaları platformumuza bağlandıkça bu değerin 5000 işlem/sn'ye çıkmasını bekliyoruz.
Bu sorun, bir Kafka kümesinin konuşlandırılması ve platformun mikro hizmetleri arasındaki eşzamanlı etkileşimin neredeyse tamamen terk edilmesiyle çözüldü. Tüm işlemler eşzamansız olamayacağından bu, sistem gereksinimlerinin çok dikkatli bir analizini gerektirir. Aynı zamanda broker aracılığıyla sadece olayları iletmiyoruz, aynı zamanda gerekli tüm iş bilgilerini de mesajla aktarıyoruz. Böylece mesaj boyutu birkaç yüz kilobayta ulaşabilir. Kafka'daki mesaj boyutu sınırı, mesaj boyutunu doğru bir şekilde tahmin etmemizi gerektirir ve gerekirse bunları böleriz, ancak bölme mantıklıdır, iş operasyonlarıyla ilgilidir.
Mesela arabaya gelen eşyaları kolilere bölüyoruz. Senkron işlemler için ayrı mikro hizmetler tahsis edilir ve kapsamlı yük testleri gerçekleştirilir. Kafka'yı kullanmak bize başka bir zorluk sundu; hizmetimizin çalışmasını Kafka entegrasyonunu dikkate alarak test etmek, tüm birim testlerimizi eşzamansız hale getiriyor. Bu sorunu Embedded Kafka Broker'ı kullanarak kendi yardımcı program yöntemlerimizi yazarak çözdük. Bu, bireysel yöntemler için birim testleri yazma ihtiyacını ortadan kaldırmaz, ancak karmaşık durumları Kafka kullanarak test etmeyi tercih ederiz.
Hizmetlerin işleyişi sırasında veya Kafka partisiyle çalışırken istisnalar meydana geldiğinde TraceId'lerinin kaybolmaması için izleme loglarına çok dikkat edildi. İlkinde özel bir sorun yoksa, ikinci durumda grubun birlikte geldiği tüm TraceId'leri günlüğe kaydetmek ve izlemeye devam etmek için birini seçmek zorunda kalırız. Daha sonra orijinal TraceId'ye göre arama yaparken kullanıcı, izlemenin hangi kişiyle devam ettiğini kolayca bulacaktır.
Görev 3. Büyük miktarda veri depolama ihtiyacı: Yalnızca tütün için yılda 1 milyardan fazla etiket X5'e geliyor. Sürekli ve hızlı erişim gerektirirler. Toplamda sistemin bu etiketli malların hareket geçmişine ilişkin yaklaşık 10 milyar kaydı işlemesi gerekiyor.
Üçüncü sorunu çözmek için NoSQL veritabanı MongoDB seçildi. 5 düğümden oluşan bir parça oluşturduk ve her düğümde 3 sunucudan oluşan bir Çoğaltma Kümesi var. Bu, sistemi yatay olarak ölçeklendirmenize, kümeye yeni sunucular eklemenize ve hata toleransını sağlamanıza olanak tanır. Burada başka bir sorunla karşılaştık: yatay olarak ölçeklenebilir mikro hizmetlerin kullanımını dikkate alarak mongo kümesinde işlemselliğin sağlanması. Örneğin sistemimizin görevlerinden biri, aynı etiketleme kodlarına sahip ürünleri yeniden satma girişimlerini tespit etmektir. Burada hatalı taramalar veya kasiyerlerin hatalı işlemleriyle ilgili katmanlar ortaya çıkıyor. Bu tür kopyaların hem işlenen bir Kafka grubunda hem de paralel olarak işlenen iki grupta meydana gelebileceğini bulduk. Bu nedenle, veritabanını sorgulayarak kopyaların kontrol edilmesi hiçbir şey vermedi. Her bir mikro hizmet için, bu hizmetin iş mantığına göre sorunu ayrı ayrı çözdük. Örneğin, çekler için, toplu iş içinde bir çek ve ekleme sırasında kopyaların görünmesi için ayrı bir işlem ekledik.
Kullanıcıların operasyon geçmişiyle çalışmasının en önemli şey olan iş süreçlerimizin işleyişini hiçbir şekilde etkilememesini sağlamak için, tüm geçmiş verilerini, yine Kafka aracılığıyla bilgi alan ayrı bir veritabanına sahip ayrı bir hizmete ayırdık. . Bu şekilde kullanıcılar, devam eden işlemler için verileri işleyen hizmetleri etkilemeden, yalıtılmış bir hizmetle çalışır.
Görev 4: Kuyruğun yeniden işlenmesi ve izlenmesi:
Dağıtılmış sistemlerde, veritabanlarının, kuyrukların ve dış veri kaynaklarının kullanılabilirliğinde kaçınılmaz olarak sorunlar ve hatalar ortaya çıkar. Marcus örneğinde bu tür hataların kaynağı dış sistemlerle entegrasyondur. Belirli bir zaman aşımı ile hatalı yanıtlar için tekrarlanan isteklere izin verecek, ancak aynı zamanda ana kuyrukta başarılı isteklerin işlenmesini durdurmayan bir çözüm bulmak gerekiyordu. Bu amaçla “konu bazlı yeniden deneme” konsepti seçildi. Her ana konu için hatalı mesajların gönderildiği bir veya daha fazla yeniden deneme konusu oluşturulur ve aynı zamanda ana konudan gelen mesajların işlenmesindeki gecikme ortadan kaldırılır. Etkileşim şeması -
Böyle bir şemayı uygulamak için aşağıdakilere ihtiyacımız vardı: bu çözümü Spring ile entegre etmek ve kod tekrarını önlemek. İnternette gezinirken Spring BeanPostProccessor tabanlı benzer bir çözümle karşılaştık ancak bu bize gereksiz derecede hantal göründü. Ekibimiz, tüketiciler oluşturmak ve ayrıca Yeniden Deneme Tüketicileri eklemek için Bahar döngüsüne entegre olmamıza olanak tanıyan daha basit bir çözüm yaptı. Çözümümüzün bir prototipini Spring ekibine sunduk, görebilirsiniz . Yeniden Deneme Tüketicilerinin sayısı ve her tüketici için deneme sayısı, iş sürecinin ihtiyaçlarına bağlı olarak parametreler aracılığıyla yapılandırılır ve her şeyin işe yaraması için geriye kalan tek şey org.springframework.kafka.annotation.KafkaListener ek açıklamasını eklemektir. Tüm Spring geliştiricilerinin aşina olduğu bir şey.
Mesaj tüm yeniden deneme denemelerinden sonra işlenemezse Spring DeadLetterPublishingRecoverer kullanılarak DLT'ye (ölü harf konusu) gider. Desteğin talebi üzerine bu işlevselliği genişlettik ve DLT, stackTrace, traceId'de bulunan mesajları ve bunlarla ilgili diğer yararlı bilgileri görüntülemenize olanak tanıyan ayrı bir hizmet oluşturduk. Ayrıca tüm DLT konularına izleme ve uyarılar eklendi ve artık aslında bir DLT konusunda bir mesajın görünmesi, bir kusurun analiz edilmesi ve düzeltilmesi için bir neden haline geldi. Bu çok kullanışlıdır - konunun adına göre, sorunun sürecin hangi aşamasında ortaya çıktığını hemen anlıyoruz, bu da kök nedenini aramayı önemli ölçüde hızlandırıyor.
Son zamanlarda, nedenleri ortadan kaldırdıktan (örneğin, harici sistemin işlevselliğini geri yüklemek) ve elbette analiz için ilgili kusuru belirledikten sonra desteğimizi kullanarak mesajları yeniden göndermemize olanak tanıyan bir arayüz uygulamaya koyduk. Kişisel konularımızın kullanışlı olduğu yer burasıdır: Uzun bir işlem zincirini yeniden başlatmamak için, onu istediğiniz adımdan yeniden başlatabilirsiniz.
Platformun Çalıştırılması
Platform halihazırda verimli bir şekilde çalışıyor; her gün teslimat ve sevkiyat gerçekleştiriyoruz, yeni dağıtım merkezlerini ve mağazaları birbirine bağlıyoruz. Sistem, pilot uygulama kapsamında “Tütün” ve “Ayakkabı” ürün gruplarıyla çalışıyor.
Ekibimizin tamamı pilot uygulamaların yürütülmesine katılıyor, ortaya çıkan sorunları analiz ediyor ve günlüklerin iyileştirilmesinden süreçlerin değiştirilmesine kadar ürünümüzün iyileştirilmesine yönelik önerilerde bulunuyor.
Hatalarımızın tekrarlanmaması adına pilot uygulama sırasında tespit edilen tüm vakalar otomatik testlere yansıtılmaktadır. Çok sayıda otomatik test ve birim testinin varlığı, birkaç saat içinde regresyon testi yapmanıza ve bir düzeltmeyi tam anlamıyla yüklemenize olanak tanır.
Artık platformumuzu geliştirmeye ve iyileştirmeye devam ediyoruz ve sürekli olarak yeni zorluklarla karşı karşıya kalıyoruz. İlgilenirseniz aşağıdaki yazılarımızda çözümlerimizden bahsedeceğiz.
Kaynak: habr.com