Salom, Xabr! Men Artem Karamyshev, tizim boshqaruvi guruhi rahbariman . O'tgan yil davomida bizda ko'plab yangi mahsulotlar paydo bo'ldi. Biz API xizmatlari osonlik bilan kengaytiriladigan, xatolarga chidamli va foydalanuvchi yukining tez o'sishiga tayyor bo'lishini ta'minlashni xohladik. Bizning platformamiz OpenStack-da amalga oshirilgan va men sizga xatoga chidamli tizimni olish uchun qanday komponentlarning xatolarga chidamliligi muammolarini hal qilishimiz kerakligini aytmoqchiman. O'ylaymanki, bu OpenStack-da mahsulotlar ishlab chiqaradiganlar uchun qiziqarli bo'ladi.
Platformaning umumiy xatolarga chidamliligi uning tarkibiy qismlarining chidamliligidan iborat. Shunday qilib, biz xavflarni aniqlagan va ularni yopgan barcha darajalarni bosqichma-bosqich bosib o'tamiz.
Ushbu hikoyaning video versiyasi, asosiy manbai Uptime day 4 konferentsiyasida hisobot bo'lgan, tomonidan tashkil etilgan , ko'rishingiz mumkin .
Jismoniy arxitekturaning chidamliligi
MCS bulutining umumiy qismi endi ikkita Tier III ma'lumotlar markazlarida joylashgan bo'lib, ular o'rtasida 200 Gbit/s o'tkazish qobiliyatiga ega, turli yo'nalishlar bo'yicha jismoniy darajada saqlangan o'zining qora tolasi mavjud. III daraja jismoniy infratuzilma uchun nosozliklarga chidamlilikning zarur darajasini ta'minlaydi.
To'q rangli tolalar ham jismoniy, ham mantiqiy darajada saqlanadi. Kanalni band qilish jarayoni takroriy bo'ldi, muammolar paydo bo'ldi va biz doimiy ravishda ma'lumotlar markazlari o'rtasidagi aloqani yaxshilaymiz.
Misol uchun, yaqinda ma'lumotlar markazlaridan biri yaqinidagi quduqda ishlayotganda ekskavator quvurni sindirib tashladi va bu quvur ichida ham asosiy, ham zaxira optik kabel mavjud edi. Bizning ma'lumotlar markazi bilan xatoga chidamli aloqa kanalimiz bir nuqtada, quduqda zaif bo'lib chiqdi. Shunga ko'ra, biz infratuzilmaning bir qismini yo'qotdik. Biz xulosalar chiqardik va bir qator harakatlarni amalga oshirdik, jumladan, qo'shni quduqqa qo'shimcha optikani o'rnatish.
Ma'lumotlar markazlarida aloqa provayderlari mavjud bo'lib, biz ularga prefikslarimizni BGP orqali uzatamiz. Har bir tarmoq yo'nalishi uchun eng yaxshi ko'rsatkich tanlanadi, bu esa turli mijozlarni eng yaxshi ulanish sifati bilan ta'minlash imkonini beradi. Agar bitta provayder orqali aloqa uzilib qolsa, biz mavjud provayderlar orqali marshrutimizni qayta quramiz.
Agar provayder muvaffaqiyatsiz bo'lsa, biz avtomatik ravishda keyingisiga o'tamiz. Ma'lumotlar markazlaridan biri ishlamay qolsa, bizda ikkinchi ma'lumot markazida xizmatlarimizning ko'zgu nusxasi mavjud bo'lib, ular butun yukni oladi.
Jismoniy infratuzilmaning chidamliligi
Ilova darajasidagi xatolarga chidamlilik uchun nima ishlatamiz
Bizning xizmatimiz bir qancha ochiq manba komponentlari asosida qurilgan.
ExaBGP BGP asosidagi dinamik marshrutlash protokoli yordamida bir qator funksiyalarni amalga oshiradigan xizmatdir. Biz undan foydalanuvchilar APIga kirishlari mumkin bo'lgan oq ro'yxatga kiritilgan IP manzillarimizni reklama qilish uchun faol foydalanamiz.
HAProksi OSI modelining turli darajalarida juda moslashuvchan trafikni muvozanatlash qoidalarini sozlash imkonini beruvchi yuqori yuk balanslagichidir. Biz undan barcha xizmatlar oldida muvozanatni saqlash uchun foydalanamiz: ma'lumotlar bazalari, xabarlar brokerlari, API xizmatlari, veb-xizmatlar, bizning ichki loyihalarimiz - hamma narsa HAProxy orqasida.
API ilovasi — python tilida yozilgan veb-ilova, uning yordamida foydalanuvchi o'z infratuzilmasi va xizmatini boshqaradi.
Ishchi arizasi (keyingi o'rinlarda oddiy ishchi) - OpenStack xizmatlarida bu infratuzilmaga API buyruqlarini translyatsiya qilish imkonini beruvchi infratuzilma demonidir. Masalan, diskni yaratish ishchida, yaratish so'rovi esa dastur API'sida sodir bo'ladi.
Standart OpenStack dastur arxitekturasi
OpenStack uchun ishlab chiqilgan aksariyat xizmatlar bitta paradigmaga amal qilishga harakat qiladi. Xizmat odatda 2 qismdan iborat: API va ishchilar (backend ijrochilar). Qoidaga ko'ra, API bu python tilidagi WSGI ilovasi bo'lib, u mustaqil jarayon (daemon) sifatida yoki tayyor Nginx yoki Apache veb-serverlari yordamida ishga tushiriladi. API foydalanuvchi so'rovini qayta ishlaydi va qo'shimcha ko'rsatmalarni bajarish uchun ishchi ilovaga uzatadi. O'tkazish xabar brokeri yordamida amalga oshiriladi, odatda RabbitMQ, boshqalari yomon qo'llab-quvvatlanadi. Xabarlar brokerga etib kelganida, ular ishchilar tomonidan qayta ishlanadi va agar kerak bo'lsa, javob qaytariladi.
Ushbu paradigma izolyatsiya qilingan umumiy muvaffaqiyatsizlik nuqtalarini o'z ichiga oladi: RabbitMQ va ma'lumotlar bazasi. Ammo RabbitMQ bitta xizmat doirasida ajratilgan va nazariy jihatdan har bir xizmat uchun individual bo'lishi mumkin. Shunday qilib, MCS-da biz ushbu xizmatlarni iloji boricha ajratamiz; har bir alohida loyiha uchun alohida ma'lumotlar bazasi, alohida RabbitMQ yaratamiz. Ushbu yondashuv yaxshi, chunki ba'zi zaif nuqtalarda baxtsiz hodisa yuz berganda, butun xizmat emas, balki uning bir qismi buziladi.
Ishchi ilovalari soni cheksizdir, shuning uchun API unumdorlik va nosozliklarga chidamliligini oshirish uchun balanslashtirgichlar orqasida osongina gorizontal ravishda kengaytira oladi.
Ba'zi xizmatlar API va ishchilar o'rtasida murakkab ketma-ket operatsiyalar sodir bo'lganda, xizmat doirasida muvofiqlashtirishni talab qiladi. Bunday holda, bitta muvofiqlashtirish markazi, Redis, Memcache va boshqalar kabi klaster tizimidan foydalaniladi, bu bir ishchiga boshqasiga bu vazifa unga berilganligini aytishga imkon beradi ("iltimos, buni olmang"). Biz boshqalardan foydalanamiz. Qoidaga ko'ra, ishchilar ma'lumotlar bazasi bilan faol aloqada bo'lishadi, u erdan ma'lumotlarni yozadilar va o'qiydilar. Biz multimaster klasterida joylashgan ma'lumotlar bazasi sifatida mariadb dan foydalanamiz.
Ushbu klassik yagona xizmat OpenStack uchun umumiy qabul qilingan tarzda tashkil etilgan. Uni yopiq tizim deb hisoblash mumkin, buning uchun masshtablash usullari va xatolarga chidamlilik juda aniq. Masalan, API nosozlikka bardoshliligi uchun ularning oldiga balanserni qo'yish kifoya. Ishchilarni ko'paytirish ularning sonini ko'paytirish orqali erishiladi.
Butun sxemadagi zaif nuqta RabbitMQ va MariaDB hisoblanadi. Ularning arxitekturasi alohida maqolaga loyiqdir.Ushbu maqolada men API nosozliklariga tolerantlikka e'tibor qaratmoqchiman.
Openstack ilovalari arxitekturasi. Bulutli platformaning muvozanati va xatolarga chidamliligi
ExaBGP yordamida HAProxy balanslagichini nosozliklarga chidamli qilish
API-larimizni kengaytiriladigan, tez va nosozliklarga chidamli qilish uchun biz ularning oldiga yuk balansini qo'yamiz. Biz HAProxy ni tanladik. Menimcha, u bizning vazifamiz uchun barcha kerakli xususiyatlarga ega: bir nechta OSI darajalarida muvozanat, boshqaruv interfeysi, moslashuvchanlik va miqyoslilik, ko'plab muvozanatlash usullari, sessiya jadvallarini qo'llab-quvvatlash.
Yechilishi kerak bo'lgan birinchi muammo bu balanslagichning o'zi xatoga chidamliligi edi. Shunchaki muvozanatlashtirgichni o'rnatish ham nosozlik nuqtasini yaratadi: balanslashtiruvchi buziladi va xizmat ishdan chiqadi. Buning oldini olish uchun biz HAProxy-dan ExaBGP bilan birgalikda foydalandik.
ExaBGP sizga xizmat holatini tekshirish mexanizmini amalga oshirish imkonini beradi. Biz ushbu mexanizmdan HAProxy funksiyasini tekshirish uchun foydalandik va muammo yuzaga kelganda BGP dan HAProxy xizmatini o‘chirib qo‘ydik.
ExaBGP+HAProxy sxemasi
- Biz kerakli dasturlarni ExaBGP va HAProxy ni uchta serverga o'rnatamiz.
- Biz har bir serverda loopback interfeysini yaratamiz.
- Barcha uchta serverda biz ushbu interfeysga bir xil oq IP-manzilni tayinlaymiz.
- Oq IP-manzil ExaBGP orqali Internetga e'lon qilinadi.
Xatolarga chidamlilik uchta serverdan bir xil IP-manzilni reklama qilish orqali erishiladi. Tarmoq nuqtai nazaridan, bir xil manzilga uch xil keyingi hoplardan kirish mumkin. Router uchta bir xil marshrutni ko'radi, o'z ko'rsatkichi asosida ulardan eng yuqori ustuvorligini tanlaydi (bu odatda bir xil variant) va trafik faqat serverlardan biriga o'tadi.
HAProxy yoki server ishlamay qolishi bilan bog'liq muammolar bo'lsa, ExaBGP marshrutni e'lon qilishni to'xtatadi va trafik muammosiz boshqa serverga o'tadi.
Shunday qilib, biz muvozanatlashtiruvchining nosozliklarga chidamliligiga erishdik.
HAProxy balanslagichlarining nosozliklarga chidamliligi
Sxema nomukammal bo'lib chiqdi: biz HAProxy-ni qanday zaxiralashni o'rgandik, lekin xizmatlar ichida yukni qanday taqsimlashni o'rganmadik. Shuning uchun biz ushbu sxemani biroz kengaytirdik: biz bir nechta oq IP-manzillar orasidagi muvozanatga o'tdik.
DNS plus BGP asosida balanslash
Bizning HAProxy uchun yukni muvozanatlash masalasi hal etilmagan. Biroq, biz bu erda qilganimiz kabi, uni juda oddiy hal qilish mumkin.
Uchta serverni muvozanatlash uchun sizga 3 ta oq IP manzil va yaxshi eski DNS kerak bo'ladi. Ushbu manzillarning har biri har bir HAProxy-ning orqaga qaytish interfeysida aniqlanadi va Internetda e'lon qilinadi.
OpenStack-da resurslarni boshqarish uchun ma'lum bir xizmatning so'nggi nuqtasi API-ni belgilaydigan xizmat katalogidan foydalaniladi. Ushbu katalogda biz uch xil IP manzillar orqali DNS orqali hal qilinadigan public.infra.mail.ru domen nomini ro'yxatdan o'tkazamiz. Natijada biz DNS orqali uchta manzil o'rtasida yuk taqsimotini olamiz.
Ammo oq IP-manzillarni e'lon qilishda biz server tanlash ustuvorliklarini nazorat qilmasligimiz sababli, bu hali muvozanatlashmaydi. Odatda, IP-manzil stajiga qarab faqat bitta server tanlanadi, qolgan ikkitasi esa ishlamaydi, chunki BGPda hech qanday ko'rsatkich belgilanmagan.
Biz ExaBGP orqali turli ko'rsatkichlar bilan marshrutlarni yuborishni boshladik. Har bir muvozanatlashtiruvchi uchta oq IP-manzilni reklama qiladi, lekin ulardan biri, bu balanslashtiruvchi uchun asosiysi, minimal ko'rsatkich bilan e'lon qilinadi. Shunday qilib, barcha uchta balanser ishlayotganda, birinchi IP-manzilga qo'ng'iroqlar birinchi balanslashtirgichga, ikkinchisiga ikkinchisiga va uchinchisiga uchinchisiga qo'ng'iroq qiladi.
Balanslashtiruvchilardan biri yiqilsa nima bo'ladi? Agar biron bir muvozanatlashtiruvchi ishlamay qolsa, uning asosiy manzili hali ham boshqa ikkitasidan reklama qilinadi va trafik ular o'rtasida qayta taqsimlanadi. Shunday qilib, biz DNS orqali foydalanuvchiga bir vaqtning o'zida bir nechta IP-manzillarni beramiz. DNS va turli ko'rsatkichlar bo'yicha muvozanatlash orqali biz barcha uchta balanslashtirgich bo'ylab yukning teng taqsimlanishiga erishamiz. Va shu bilan birga, biz xatolarga chidamlilikni yo'qotmaymiz.
DNS + BGP asosida HAProxy-ni muvozanatlash
ExaBGP va HAProxy o'rtasidagi o'zaro ta'sir
Shunday qilib, biz marshrutlarni e'lon qilishni to'xtatishga asoslanib, server chiqib ketgan taqdirda nosozliklarga chidamlilikni joriy qildik. Ammo HAProxy serverning ishlamay qolishidan tashqari boshqa sabablarga ko'ra yopilishi mumkin: boshqaruv xatolari, xizmat ichidagi nosozliklar. Biz bu holatlarda ham buzilgan muvozanatni yuk ostidan olib tashlamoqchimiz va bizga boshqa mexanizm kerak.
Shuning uchun, oldingi sxemani kengaytirib, biz ExaBGP va HAProxy o'rtasida yurak urishini amalga oshirdik. Bu ExaBGP va HAProxy o'rtasidagi o'zaro ta'sirning dasturiy ta'minoti, ExaBGP ilovalar holatini tekshirish uchun maxsus skriptlardan foydalanganda.
Buning uchun ExaBGP konfiguratsiyasida HAProxy holatini tekshirishi mumkin bo'lgan salomatlik tekshiruvini sozlashingiz kerak. Bizning holatda, biz HAProxy-da sog'liqni saqlashni sozladik va ExaBGP tomonidan oddiy GET so'rovi bilan tekshiramiz. Agar e'lon to'xtasa, HAProxy ishlamayapti va uni reklama qilishning hojati yo'q.
HAProxy salomatlik tekshiruvi
HAProxy Peers: sessiya sinxronizatsiyasi
Keyingi narsa seanslarni sinxronlashtirish edi. Tarqalgan balanschilar orqali ishlaganda, mijoz seanslari haqidagi ma'lumotlarni saqlashni tashkil qilish qiyin. Ammo HAProxy Peers funksiyasi - seans jadvallarini turli HAProxy jarayonlari o'rtasida o'tkazish qobiliyati tufayli buni amalga oshirishi mumkin bo'lgan bir nechta muvozanatchilardan biridir.
Turli xil muvozanatlash usullari mavjud: oddiy, masalan , va kengaytirilgan, mijozning sessiyasi eslab qolsa va har safar u avvalgidek bir xil serverda tugaydi. Biz ikkinchi variantni amalga oshirishni xohladik.
HAProxy ushbu mexanizmning mijoz seanslarini saqlash uchun stick-jadvallardan foydalanadi. Ular mijozning asl IP manzilini, tanlangan maqsad manzilini (backend) va ba'zi xizmat ma'lumotlarini saqlaydi. Odatda, tayoq jadvallari manba-IP + maqsad-IP juftligini saqlash uchun ishlatiladi, bu ayniqsa, boshqa balanslashtirgichga, masalan, RoundRobin balanslash rejimiga o'tishda foydalanuvchi sessiyasi kontekstini o'tkaza olmaydigan ilovalar uchun foydalidir.
Agar tayoq stoliga turli xil HAProxy jarayonlari o'rtasida harakatlanish o'rgatilgan bo'lsa (muvozanat sodir bo'ladi), bizning balanslashtirgichlarimiz bitta stol stollari bilan ishlash imkoniyatiga ega bo'ladi. Bu, agar balanslashtirgichlardan biri ishlamay qolsa, mijoz tarmog'ini muammosiz o'zgartirish imkonini beradi; mijoz seanslari bilan ishlash avval tanlangan backendlarda davom etadi.
To'g'ri ishlashi uchun seans o'rnatilgan balanslashtiruvchining manba IP-manzili muammosini hal qilish kerak. Bizning holatda, bu loopback interfeysidagi dinamik manzil.
Tengdoshlarning to'g'ri ishlashiga faqat ma'lum sharoitlarda erishiladi. Ya'ni, TCP seansini tugatish uchun vaqt topa olmasligi uchun TCP kutish vaqti etarlicha katta bo'lishi yoki almashtirish tez bo'lishi kerak. Biroq, u uzluksiz almashtirish imkonini beradi.
IaaS-da bizda xuddi shu texnologiyadan foydalangan holda qurilgan xizmat mavjud. Bu , bu Octavia deb ataladi. U ikkita HAProxy jarayoniga asoslangan va dastlab tengdoshlarni qo'llab-quvvatlashni o'z ichiga oladi. Ular ushbu xizmatda o'zlarini a'lo darajada isbotladilar.
Rasmda uchta HAProxy misoli orasidagi tengdoshlar jadvallarining harakati sxematik tarzda ko'rsatilgan, uni qanday sozlash mumkinligi haqida konfiguratsiya taklif etiladi:
HAProxy Peers (sessiya sinxronizatsiyasi)
Agar siz xuddi shu sxemani amalga oshirsangiz, uning ishlashi diqqat bilan tekshirilishi kerak. Bu 100% vaqtning o'zida bir xil tarzda ishlashi haqiqat emas. Lekin, hech bo'lmaganda, mijozning IP-manbasini eslab qolishingiz kerak bo'lganda, tayoq jadvallarini yo'qotmaysiz.
Bitta mijozdan bir vaqtning o'zida so'rovlar sonini cheklash
Hammaga ochiq boʻlgan har qanday xizmatlar, jumladan, APIʼlarimiz ham soʻrovlar ostida qolishi mumkin. Ularning sabablari foydalanuvchi xatolaridan maqsadli hujumlargacha butunlay boshqacha bo'lishi mumkin. Biz vaqti-vaqti bilan IP manzillar bo'yicha DDoSed qilinamiz. Mijozlar ko'pincha o'z skriptlarida xato qiladilar va bizga mini-DDoSlarni beradilar.
Qanday bo'lmasin, qo'shimcha himoya ta'minlanishi kerak. Aniq yechim - bu API so'rovlari sonini cheklash va zararli so'rovlarni qayta ishlash uchun CPU vaqtini behuda sarflamaslikdir.
Bunday cheklovlarni amalga oshirish uchun biz bir xil tayoq jadvallari yordamida HAProxy asosida tashkil etilgan tarif chegaralaridan foydalanamiz. Cheklovlarni o'rnatish juda oddiy va foydalanuvchini API-ga so'rovlar soni bilan cheklash imkonini beradi. Algoritm so'rovlar yuboriladigan IP manbasini eslab qoladi va bir foydalanuvchidan bir vaqtning o'zida so'rovlar sonini cheklaydi. Albatta, biz har bir xizmat uchun o'rtacha API yuklash profilini hisoblab chiqdik va bu qiymatdan ≈ 10 barobar ko'p chegara o'rnatdik. Biz vaziyatni diqqat bilan kuzatib borishda davom etamiz va barmog'imizni pulsda ushlab turamiz.
Bu amalda qanday ko'rinadi? Avtomatik o'lchamdagi API-larimizdan doimo foydalanadigan mijozlarimiz bor. Ular ertalab ikki yuzdan uch yuzgacha virtual mashinalar yaratadilar va kechqurun ularni o'chirib tashlaydilar. OpenStack uchun PaaS xizmatlari bilan virtual mashinani yaratish kamida 1000 ta API so'rovlarini talab qiladi, chunki xizmatlar o'rtasidagi o'zaro aloqa API orqali ham amalga oshiriladi.
Vazifalarni bunday uzatish juda katta yukni keltirib chiqaradi. Biz ushbu yukni baholadik, kunlik cho'qqilarni to'pladik, ularni o'n barobar oshirdik va bu bizning tarif chegaramiz bo'ldi. Biz barmog'imizni pulsda ushlab turamiz. Biz tez-tez ishga tushirish mumkin bo'lgan CGA skriptlari bor-yo'qligini bilish uchun bizga qarashga harakat qilayotgan botlarni va skanerlarni ko'ramiz, biz ularni faol ravishda kesib tashlamoqdamiz.
Foydalanuvchilar sezmasdan kod bazasini qanday yangilash mumkin
Shuningdek, biz kodni joylashtirish jarayonlari darajasida xatolarga chidamlilikni amalga oshiramiz. Chiqarish paytida nosozliklar bo'lishi mumkin, ammo ularning xizmat mavjudligiga ta'sirini minimallashtirish mumkin.
Biz xizmatlarimizni doimiy ravishda yangilab turamiz va foydalanuvchilarga ta'sir qilmasdan kodlar bazasi yangilanishini ta'minlashimiz kerak. Biz ushbu muammoni HAProxy boshqaruv imkoniyatlaridan va xizmatlarimizda Graceful O'chirishni amalga oshirishdan foydalangan holda hal qilishga muvaffaq bo'ldik.
Ushbu muammoni hal qilish uchun balanserning nazoratini va xizmatlarning "to'g'ri" o'chirilishini ta'minlash kerak edi:
- HAProxy holatida boshqaruv stats fayli orqali amalga oshiriladi, bu asosan rozetka bo'lib, HAProxy konfiguratsiyasida aniqlangan. Siz unga stdio orqali buyruqlar yuborishingiz mumkin. Ammo bizning konfiguratsiyani boshqarishning asosiy vositamiz qulay, shuning uchun u HAProxy-ni boshqarish uchun o'rnatilgan modulga ega. Biz undan faol foydalanamiz.
- Bizning API va Dvigatel xizmatlarimizning aksariyati oqlangan o'chirish texnologiyalarini qo'llab-quvvatlaydi: o'chirishda ular http so'rovi yoki biron bir xizmat vazifasi bo'ladimi, joriy vazifa bajarilishini kutishadi. Xuddi shu narsa ishchi bilan sodir bo'ladi. U bajarayotgan barcha vazifalarni biladi va hamma narsani muvaffaqiyatli bajargandan so'ng tugaydi.
Ushbu ikki nuqta tufayli bizning joylashtirishimiz uchun xavfsiz algoritm shunday ko'rinadi.
- Ishlab chiquvchi yangi kod to'plamini yig'adi (biz uchun bu RPM), uni ishlab chiquvchi muhitda sinab ko'radi, bosqichda sinab ko'radi va uni sahna omborida qoldiradi.
- Ishlab chiquvchi "artifaktlar" ning eng batafsil tavsifi bilan joylashtirish vazifasini qo'yadi: yangi paketning versiyasi, yangi funksionallikning tavsifi va kerak bo'lganda tarqatishning boshqa tafsilotlari.
- Tizim ma'muri yangilashni boshlaydi. Ansible o'yin kitobini ishga tushiradi, u o'z navbatida quyidagilarni bajaradi:
- Bosqich omboridan paketni oladi va undan mahsulot omboridagi paket versiyasini yangilash uchun foydalanadi.
- Yangilangan xizmatning orqa tomonlari ro'yxatini tuzadi.
- HAProxy-da yangilanadigan birinchi xizmatni o'chiradi va uning jarayonlari tugashini kutadi. Yaxshi o'chirish tufayli, barcha joriy mijozlar so'rovlari muvaffaqiyatli bajarilishiga ishonchimiz komil.
- API va ishchilar to'liq to'xtatilgandan va HAProxy o'chirilgandan so'ng, kod yangilanadi.
- Ansible xizmatlarini ishga tushiradi.
- Har bir xizmat uchun ma'lum "tutqichlar" tortiladi, ular bir qator oldindan belgilangan kalit testlarida birlik sinovini amalga oshiradi. Yangi kodning asosiy tekshiruvi amalga oshiriladi.
- Agar oldingi bosqichda hech qanday xato topilmasa, backend faollashtiriladi.
- Keling, keyingi orqa qismga o'tamiz.
- Barcha backendlar yangilangandan so'ng, funktsional testlar ishga tushiriladi. Agar ular etishmayotgan bo'lsa, ishlab chiquvchi o'zi yaratgan har qanday yangi funksiyani ko'rib chiqadi.
Bu joylashtirishni yakunlaydi.
Xizmatni yangilash davri
Agar bizda bitta qoida bo'lmasa, bu sxema ishlamaydi. Biz jangda eski va yangi versiyalarni qo'llab-quvvatlaymiz. Oldindan, dasturiy ta'minotni ishlab chiqish bosqichida, xizmat ma'lumotlar bazasida o'zgarishlar bo'lsa ham, ular oldingi kodni buzmasliklari belgilab qo'yilgan. Natijada, kod bazasi asta-sekin yangilanadi.
xulosa
Xatolarga chidamli WEB arxitekturasi haqida o'z fikrlarim bilan o'rtoqlashar ekanman, uning asosiy fikrlarini yana bir bor ta'kidlamoqchiman:
- jismoniy xatolarga chidamlilik;
- tarmoq xatoliklariga chidamliligi (balansatorlar, BGP);
- ishlatiladigan va ishlab chiqilgan dasturiy ta'minotning xatolarga chidamliligi.
Hamma uchun barqaror ish vaqti!
Manba: www.habr.com
