Dasturiy ta'minotdagi chidamlilik, hatto kutilmagan muammolar yoki nosozliklar yuz bergan taqdirda ham dasturning muammosiz va ishonchli ishlashini davom ettirish qobiliyatini anglatadi. Fintech loyihalarida barqarorlik bir necha sabablarga ko'ra ayniqsa katta ahamiyatga ega. Birinchidan, kompaniyalar tartibga soluvchi talablarni bajarishlari shart va moliyaviy tartibga soluvchilar tizimda barqarorlikni saqlash uchun operatsion barqarorlikni ta'kidlaydilar. Bundan tashqari, raqamli vositalarning ko'payishi va uchinchi tomon xizmat ko'rsatuvchi provayderlarga ishonish Fintech biznesini xavfsizlikka tahdidlarning kuchayishiga olib keladi. Moslashuvchanlik, shuningdek, kibertahdidlar, pandemiyalar yoki geosiyosiy hodisalar kabi turli omillar ta'sirida yuzaga keladigan uzilishlar xavfini kamaytirishga, asosiy biznes operatsiyalari va muhim aktivlarni himoya qilishga yordam beradi.  Chidamlilik namunalari orqali biz dasturiy ta'minot uzilishlarga bardosh bera olishi va o'z faoliyatini saqlab turishini ta'minlash uchun mo'ljallangan eng yaxshi amaliyotlar va strategiyalar to'plamini tushunamiz. Ushbu naqshlar xavfsizlik tarmoqlari kabi ishlaydi, xatolarni bartaraf etish, yukni boshqarish va nosozliklarni bartaraf etish mexanizmlarini ta'minlaydi va shu bilan ilovalarning noqulay sharoitlarda mustahkam va ishonchli bo'lishini ta'minlaydi.  Eng keng tarqalgan chidamlilik strategiyalari orasida bukhead, kesh, zaxira, qayta urinish va elektron to'xtatuvchidir. Ushbu maqolada men ularni hal qilishga yordam beradigan muammolar misollari bilan batafsilroq muhokama qilaman.  To'siq   Keling, yuqoridagi sozlamalarni ko'rib chiqaylik. Bizda ba'zi ma'lumotlarni olish uchun orqada bir nechta orqa tomonlari bo'lgan juda oddiy dastur mavjud. Ushbu backendlarga ulangan bir nechta HTTP mijozlari mavjud. Ma'lum bo'lishicha, ularning barchasi bir xil ulanish hovuziga ega! Shuningdek, protsessor va RAM kabi boshqa resurslar.  Agar backendlardan biri yuqori so'rovning kechikishiga olib keladigan muammolarga duch kelsa nima bo'ladi? Yuqori javob vaqti tufayli butun ulanish hovuzi backend1 dan javob kutayotgan so'rovlar bilan to'liq band bo'ladi. Natijada, sog‘lom backend2 va backend3 uchun mo‘ljallangan so‘rovlar davom eta olmaydi, chunki hovuz tugagan. Bu shuni anglatadiki, bizning orqa tomonlarimizdan biridagi nosozlik butun dastur bo'ylab muvaffaqiyatsizlikka olib kelishi mumkin. Ideal holda, dasturning qolgan qismi normal ishlashda davom etar ekan, biz faqat ishlamay qolgan backend bilan bog'liq funksionallikning buzilishini xohlaymiz.   Bulkhead namunasi nima?   Bulkhead naqsh atamasi kema qurishdan kelib chiqqan bo'lib, u kema ichida bir nechta izolyatsiya qilingan bo'limlarni yaratishni o'z ichiga oladi. Agar bir bo'limda oqish sodir bo'lsa, u suv bilan to'ldiriladi, ammo boshqa bo'limlar ta'sir qilmaydi. Bu izolyatsiya butun kemaning bir marta buzilish tufayli cho'kib ketishini oldini oladi.  Ushbu muammoni hal qilish uchun qanday qilib bukhead naqshidan foydalanishimiz mumkin?   Bulkhead naqshidan dastur ichidagi har xil turdagi resurslarni ajratish uchun foydalanish mumkin, bu esa bir qismdagi nosozlik butun tizimga ta'sir qilishining oldini oladi. Buni muammomizga qanday qo'llashimiz mumkin:  Aloqa hovuzlarini izolyatsiya qilish Biz har bir backend (backend1, backend2, backend3) uchun alohida ulanish hovuzlarini yaratishimiz mumkin. Bu, agar backend1 yuqori javob vaqtlari yoki nosozliklarni boshdan kechirayotgan bo'lsa, uning ulanish hovuzi mustaqil ravishda tugaydi va backend2 va backend3 uchun ulanish hovuzlariga ta'sir qilmaydi. Ushbu izolyatsiya sog'lom backendlarga so'rovlarni normal tarzda qayta ishlashni davom ettirish imkonini beradi.  Fondagi faoliyat uchun resurslarni cheklash Bulkheads-dan foydalanib, biz ommaviy ishlov berish yoki rejalashtirilgan vazifalar kabi fon faoliyati uchun maxsus resurslarni ajratishimiz mumkin. Bu ushbu faoliyatning real vaqt operatsiyalari uchun zarur bo'lgan resurslarni iste'mol qilishiga to'sqinlik qiladi. Misol uchun, biz kirish so'rovlarini ko'rib chiqish uchun etarli resurslar mavjudligini ta'minlab, fon vazifalariga bag'ishlangan mavzular sonini yoki protsessordan foydalanishni cheklashimiz mumkin.  Kiruvchi so'rovlar bo'yicha cheklovlarni o'rnatish, shuningdek, ilovaning turli qismlariga kiruvchi so'rovlar sonini cheklash uchun bulkheadlar qo'llanilishi mumkin. Misol uchun, biz har bir yuqori oqim xizmati uchun bir vaqtning o'zida qayta ishlanishi mumkin bo'lgan so'rovlar soni bo'yicha maksimal chegarani belgilashimiz mumkin. Bu har qanday bitta backend tizimni haddan tashqari oshirib yuborishning oldini oladi va boshqa backendlar og'ir yuk ostida bo'lsa ham ishlashda davom etishini ta'minlaydi.     Kesh  Faraz qilaylik, bizning backend tizimlarimiz alohida xatolarga duch kelish ehtimoli past. Biroq, agar operatsiya barcha bu backendlarni parallel ravishda so'rashni o'z ichiga olgan bo'lsa, ularning har biri mustaqil ravishda xatoni qaytarishi mumkin. Ushbu xatolar mustaqil ravishda yuzaga kelganligi sababli, bizning ilovamizdagi xatoning umumiy ehtimoli har qanday bitta backend xato ehtimolidan yuqori. Kümülatif xatolik ehtimoli P_total=1−(1−p)^n formulasi yordamida hisoblanishi mumkin, bu erda n - backend tizimlari soni.  Misol uchun, har birida xatolik ehtimoli p=0,001 bo'lgan o'nta orqa qism bo'lsa (SLA 99,9% ga to'g'ri keladi), natijada xatolik ehtimoli quyidagicha bo'ladi:  P_jami=1−(1−0,001)^10=0,009955  Bu shuni anglatadiki, bizning umumiy SLA taxminan 99% ga tushadi, bu bir nechta backendlarni parallel ravishda so'rashda umumiy ishonchlilik qanday pasayishini ko'rsatadi. Ushbu muammoni yumshatish uchun biz xotiradagi keshni amalga oshirishimiz mumkin.     Xotiradagi kesh yordamida buni qanday hal qilishimiz mumkin  Xotiradagi kesh yuqori tezlikdagi ma'lumotlar buferi bo'lib xizmat qiladi, tez-tez foydalaniladigan ma'lumotlarni saqlaydi va ularni har safar sekin manbalardan olish zaruratini yo'q qiladi. Xotirada saqlangan keshlar tarmoq orqali ma'lumotlarni olish bilan solishtirganda xatolik ehtimoli 0% bo'lganligi sababli, ular ilovamizning ishonchliligini sezilarli darajada oshiradi. Bundan tashqari, keshlash tarmoq trafigini kamaytiradi va xatolar ehtimolini yanada kamaytiradi. Binobarin, xotiradagi keshdan foydalanish orqali biz dasturimizda backend tizimlariga nisbatan pastroq xatolik darajasiga erishishimiz mumkin. Bundan tashqari, xotiradagi keshlar tarmoqqa asoslangan olishdan ko'ra tezroq ma'lumotlarni olish imkonini beradi va shu bilan ilovalarning kechikishini kamaytiradi - bu sezilarli afzallik.   Xotiradagi kesh: Shaxsiylashtirilgan keshlar  Foydalanuvchi profillari yoki tavsiyalar kabi shaxsiylashtirilgan ma'lumotlar uchun xotiradagi keshlardan foydalanish ham juda samarali bo'lishi mumkin. Lekin biz foydalanuvchining barcha so'rovlari ular uchun keshlangan ma'lumotlardan foydalanish uchun doimiy ravishda bir xil dastur namunasiga o'tishini ta'minlashimiz kerak, bu esa yopishqoq seanslarni talab qiladi. Yopishqoq seanslarni amalga oshirish qiyin bo'lishi mumkin, ammo bu stsenariy uchun bizga murakkab mexanizmlar kerak emas. Kichik trafikni qayta muvozanatlash qabul qilinadi, shuning uchun izchil xeshlash kabi barqaror yukni muvozanatlash algoritmi etarli bo'ladi.  Bundan tashqari, tugun ishlamay qolgan taqdirda, izchil xeshlash faqat muvaffaqiyatsiz tugun bilan bog'langan foydalanuvchilar muvozanatni qayta tiklashni ta'minlaydi va tizimdagi buzilishlarni minimallashtiradi. Ushbu yondashuv shaxsiylashtirilgan keshlarni boshqarishni soddalashtiradi va ilovamizning umumiy barqarorligi va unumdorligini oshiradi.     Xotiradagi kesh: mahalliy ma'lumotlarni replikatsiya qilish  Agar biz keshlash niyatida boʻlgan maʼlumotlar muhim boʻlsa va tizimimiz tomonidan koʻrib chiqiladigan har bir soʻrovda, masalan, kirish siyosatlari, obuna rejalari yoki domenimizdagi boshqa muhim obʼyektlarda foydalanilsa, bu maʼlumotlar manbai tizimimizda jiddiy nosozlik boʻlishi mumkin. Ushbu muammoni hal qilish uchun yondashuvlardan biri bu ma'lumotlarni to'g'ridan-to'g'ri ilovamiz xotirasiga to'liq takrorlashdir.  Ushbu stsenariyda, agar manbadagi ma'lumotlar hajmini boshqarish mumkin bo'lsa, biz ilovamiz boshida ushbu ma'lumotlarning oniy rasmini yuklab olish orqali jarayonni boshlashimiz mumkin. Keyinchalik, keshlangan ma'lumotlar manba bilan sinxronlanganligini ta'minlash uchun biz yangilanish hodisalarini olishimiz mumkin. Ushbu usulni qo'llash orqali biz ushbu muhim ma'lumotlarga kirishning ishonchliligini oshiramiz, chunki har bir qayta tiklash to'g'ridan-to'g'ri xotiradan 0% xatolik ehtimoli bilan sodir bo'ladi. Bundan tashqari, xotiradan ma'lumotlarni olish juda tezdir va shu bilan bizning ilovamiz ish faoliyatini optimallashtiradi. Ushbu strategiya tashqi ma'lumotlar manbasiga tayanish bilan bog'liq xavfni samarali ravishda kamaytiradi, ilovamiz ishlashi uchun muhim ma'lumotlarga izchil va ishonchli kirishni ta'minlaydi.   Qayta yuklanadigan konfiguratsiya  Biroq, dasturni ishga tushirish bo'yicha ma'lumotlarni yuklab olish zarurati, shu bilan ishga tushirish jarayonini kechiktirish, ilovalarni tezkor ishga tushirishni targ'ib qiluvchi "12 faktorli dastur" tamoyillaridan birini buzadi. Biroq, biz keshlashdan foydalanishning afzalliklaridan mahrum bo'lishni xohlamaymiz. Ushbu dilemmani hal qilish uchun keling, potentsial echimlarni ko'rib chiqaylik.  Tez ishga tushirish, ayniqsa Kubernetes kabi platformalar uchun juda muhim, ular ilovalarni turli jismoniy tugunlarga tez koʻchirishga tayanadi. Yaxshiyamki, Kubernetes ishga tushirish zondlari kabi xususiyatlardan foydalangan holda sekin ishga tushadigan ilovalarni boshqarishi mumkin.  Biz duch kelishi mumkin bo'lgan yana bir qiyinchilik - dastur ishlayotgan paytda konfiguratsiyalarni yangilash. Ko'pincha, ishlab chiqarish bilan bog'liq muammolarni hal qilish uchun kesh vaqtlarini yoki so'rovni kutish vaqtini sozlash kerak. Yangilangan konfiguratsiya fayllarini ilovamizga tezda joylashtira olsak ham, bu o'zgarishlarni qo'llash odatda qayta ishga tushirishni talab qiladi. Har bir ilovani ishga tushirish muddati uzaytirilganda, qayta ishga tushirish foydalanuvchilarga tuzatishlarni kiritishni sezilarli darajada kechiktirishi mumkin.  Buni hal qilish uchun bitta yechim konfiguratsiyalarni bir vaqtning o'zida o'zgaruvchida saqlash va uni vaqti-vaqti bilan yangilab turadigan fon oqimiga ega bo'lishdir. Biroq, HTTP so'rovining kutish vaqti kabi ba'zi parametrlar mos keladigan konfiguratsiya o'zgarganda HTTP yoki ma'lumotlar bazasi mijozlarini qayta ishga tushirishni talab qilishi mumkin va bu mumkin bo'lgan qiyinchilik tug'diradi. Shunga qaramay, Java uchun Cassandra drayveri kabi ba'zi mijozlar konfiguratsiyalarni avtomatik qayta yuklashni qo'llab-quvvatlaydi va bu jarayonni soddalashtiradi.  Qayta yuklanadigan konfiguratsiyalarni amalga oshirish uzoq dasturni ishga tushirish vaqtlarining salbiy ta'sirini yumshatishi va qo'shimcha imtiyozlarni taqdim etishi mumkin, masalan, xususiyat bayrog'ini amalga oshirishni osonlashtirish. Ushbu yondashuv bizga konfiguratsiya yangilanishlarini samarali boshqarishda dastur ishonchliligi va sezgirligini saqlab qolish imkonini beradi.   Ortga qaytish  Endi yana bir muammoni ko'rib chiqamiz: bizning tizimimizda foydalanuvchi so'rovi backend yoki ma'lumotlar bazasiga so'rov yuborish orqali qabul qilinganda va qayta ishlansa, vaqti-vaqti bilan kutilgan ma'lumotlar o'rniga xato javobi olinadi. Keyinchalik, bizning tizimimiz foydalanuvchiga "xato" bilan javob beradi.  Biroq, ko'pgina stsenariylarda foydalanuvchini katta qizil xato xabari bilan qoldirmasdan, biroz eskirgan ma'lumotlarni va ma'lumotlarni yangilashda kechikish borligini bildiruvchi xabarni ko'rsatish afzalroq bo'lishi mumkin.   Ushbu muammoni hal qilish va tizimimizning xatti-harakatlarini yaxshilash uchun biz Fallback naqshini amalga oshirishimiz mumkin. Ushbu naqshning kontseptsiyasi ikkinchi darajali ma'lumot manbasiga ega bo'lishni o'z ichiga oladi, unda asosiy manbaga nisbatan pastroq sifatli yoki yangi ma'lumotlar bo'lishi mumkin. Agar asosiy ma'lumot manbai mavjud bo'lmasa yoki xatolik qaytarsa, tizim xato xabarini ko'rsatish o'rniga foydalanuvchiga ma'lumotlarning qandaydir shakli taqdim etilishini ta'minlab, ushbu ikkilamchi manbadan ma'lumotlarni olishga qaytishi mumkin.     Qayta urinish  Yuqoridagi rasmga qarasangiz, hozir biz duch kelayotgan muammo va kesh misolida duch kelgan muammo o'rtasidagi o'xshashlikni ko'rasiz.  Buni hal qilish uchun biz qayta urinish deb nomlanuvchi naqshni amalga oshirishni ko'rib chiqishimiz mumkin. Keshlarga tayanish o'rniga, tizim xatolik yuz berganda so'rovni avtomatik ravishda qayta yuborish uchun mo'ljallangan bo'lishi mumkin. Ushbu qayta urinish namunasi oddiyroq muqobilni taklif etadi va ilovamizdagi xatolar ehtimolini samarali ravishda kamaytiradi. Ma'lumotlarni o'zgartirish uchun ko'pincha keshni bekor qilishning murakkab mexanizmlarini talab qiladigan keshlashdan farqli o'laroq, muvaffaqiyatsiz so'rovlarni qayta urinish nisbatan oson amalga oshiriladi. Keshni bekor qilish dasturiy ta'minot injiniringidagi eng qiyin vazifalardan biri sifatida qabul qilinganligi sababli, qayta urinib ko'rish strategiyasini qabul qilish xatolarni boshqarishni soddalashtirishi va tizim barqarorligini oshirishi mumkin.  O'chirish to'xtatuvchisi   Biroq, potentsial oqibatlarni hisobga olmasdan, qayta urinish strategiyasini qabul qilish keyingi asoratlarga olib kelishi mumkin.  Tasavvur qilaylik, bizning orqa tomonlarimizdan biri muvaffaqiyatsizlikka uchradi. Bunday stsenariyda muvaffaqiyatsiz backendga qayta urinishlarni boshlash trafik hajmining sezilarli darajada oshishiga olib kelishi mumkin. Trafikning to'satdan ko'tarilishi orqa tomonni bosib ketishi mumkin, bu esa nosozlikni kuchaytirishi va tizim bo'ylab kaskad effektini keltirib chiqarishi mumkin.  Ushbu qiyinchilikni engish uchun qayta urinish namunasini elektron to'xtatuvchining namunasi bilan to'ldirish muhimdir. O'chirish to'xtatuvchisi quyi oqim xizmatlarining xatolik darajasini kuzatuvchi himoya mexanizmi bo'lib xizmat qiladi. Xato darajasi oldindan belgilangan chegaradan oshib ketganda, o'chirgich ma'lum vaqt davomida ta'sirlangan xizmatga so'rovlarni to'xtatadi. Ushbu davr mobaynida tizim ishlamay qolgan xizmat vaqtini tiklash uchun qo'shimcha so'rovlarni yuborishdan bosh tortadi. Belgilangan oraliqdan so'ng, o'chirgich ehtiyotkorlik bilan cheklangan miqdordagi so'rovlarni o'tkazishga imkon beradi va xizmat barqarorlashganligini tekshiradi. Agar xizmat tiklangan bo'lsa, normal trafik asta-sekin tiklanadi; aks holda, kontaktlarning zanglashiga olib, xizmat normal ishlashiga qadar so'rovlarni bloklashda davom etadi. Qayta urinish mantig'i bilan bir qatorda elektron to'xtatuvchining naqshini birlashtirib, biz xatolik holatlarini samarali boshqarishimiz va orqa qismdagi nosozliklar paytida tizimning haddan tashqari yuklanishining oldini olishimiz mumkin.   Oʻrash  Xulosa qilib aytadigan bo'lsak, ushbu chidamlilik namunalarini amalga oshirish orqali biz favqulodda vaziyatlarga qarshi ilovalarimizni kuchaytirishimiz, yuqori mavjudlikni saqlashimiz va foydalanuvchilarga uzluksiz tajriba taqdim etishimiz mumkin. Bundan tashqari, telemetriya loyihaning barqarorligini ta'minlashda e'tibordan chetda qolmasligi kerak bo'lgan yana bir vosita ekanligini ta'kidlamoqchiman. Yaxshi jurnallar va ko'rsatkichlar xizmatlar sifatini sezilarli darajada oshirishi va ularning ishlashi haqida qimmatli ma'lumotlarni taqdim etishi va ularni yanada yaxshilash uchun asosli qarorlar qabul qilishda yordam berishi mumkin.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

effect

Even

Read My Stories

Ushbu audio hikoyaning asl tilida yaratilgan!

Juda uzoq; O'qish

Make resilience your competitive advantage

Fintech loyihalari uchun haqiqiy dunyoga chidamli strategiyalar

About Author

IZOHLAR

TEGI QILISH

USHBU MAQOLA TAQDIM ETILGAN

Related Stories

Meet Uzi World Digital, Winner of Startups of the year 2024 in Kolkata, West Bengal, India

Meet UzairaAdvisory, Winner of Startups of The Year 2024 in Business

Meet UzairaAdvisory, Startups of The Year 2024 Nominee

Meet Uzi World Digital, Winner of Startups of the year 2024 in Kolkata, West Bengal, India

Meet UzairaAdvisory, Winner of Startups of The Year 2024 in Business

Meet UzairaAdvisory, Startups of The Year 2024 Nominee

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps