Yandex.Market qidiruvi qanday ishlaydi va serverlardan biri ishlamay qolsa nima bo'ladi

Salom, mening ismim Evgeniy. Men Yandex.Market qidiruv infratuzilmasida ishlayman. Men Habr jamoasiga Bozorning ichki oshxonasi haqida gapirib bermoqchiman - va aytadigan gaplarim ko'p. Avvalo, bozorni qidirish qanday ishlaydi, jarayonlar va arxitektura. Favqulodda vaziyatlarni qanday hal qilamiz: agar bitta server ishlamay qolsa nima bo'ladi? 100 ta shunday server bo'lsa-chi?

Shuningdek, bir vaqtning o'zida bir nechta serverlarda yangi funksiyalarni qanday amalga oshirishimizni bilib olasiz. Va qanday qilib biz foydalanuvchilarga hech qanday noqulaylik tug'dirmasdan, to'g'ridan-to'g'ri ishlab chiqarishda murakkab xizmatlarni sinab ko'ramiz. Umuman olganda, Bozor qidiruvi qanday ishlaydi, shunda hamma yaxshi vaqt o'tkazadi.

Biz haqimizda bir oz: biz qanday muammoni hal qilamiz

Matnni kiritganingizda, mahsulotni parametrlar bo'yicha qidirsangiz yoki turli do'konlardagi narxlarni taqqoslasangiz, barcha so'rovlar qidiruv xizmatiga yuboriladi. Qidiruv bozordagi eng katta xizmatdir.

Biz barcha qidiruv so'rovlarini qayta ishlaymiz: market.yandex.ru, beru.ru saytlaridan, Supercheck xizmati, Yandex.Advisor, mobil ilovalar. Biz yandex.ru saytidagi qidiruv natijalariga mahsulot takliflarini ham kiritamiz.

Qidiruv xizmati deganda men nafaqat qidiruvning o'zini, balki Bozordagi barcha takliflarga ega ma'lumotlar bazasini ham nazarda tutyapman. Ko'lami quyidagicha: kuniga milliarddan ortiq qidiruv so'rovlari qayta ishlanadi. Va hamma narsa tez, uzilishlarsiz ishlashi va har doim kerakli natijani berishi kerak.

Nima: Bozor arxitekturasi

Men bozorning hozirgi arxitekturasini qisqacha tasvirlab beraman. Buni taxminan quyidagi diagramma bilan tasvirlash mumkin:

Aytaylik, bizga hamkor do'kon keldi. U o'yinchoq sotmoqchiman, deydi: bu g'ichirlagan yovuz mushuk. Va yana bir g'azablangan mushuk chiyillashsiz. Va shunchaki mushuk. Keyin do'kon bozor qidiradigan takliflarni tayyorlashi kerak. Do'kon takliflar bilan maxsus xml yaratadi va sheriklik interfeysi orqali ushbu xmlga yo'lni bildiradi. Keyin indekser vaqti-vaqti bilan ushbu xml-ni yuklab oladi, xatolarni tekshiradi va barcha ma'lumotlarni katta ma'lumotlar bazasiga saqlaydi.

Bunday saqlangan xmllar juda ko'p. Ushbu ma'lumotlar bazasidan qidiruv indeksi yaratiladi. Indeks ichki formatda saqlanadi. Indeksni yaratgandan so'ng, Layout xizmati uni qidiruv serverlariga yuklaydi.

Natijada, ma'lumotlar bazasida g'azablangan g'azablangan mushuk paydo bo'ladi va serverda mushukning indeksi paydo bo'ladi.

Qidiruv arxitekturasi bo'limida mushukni qanday izlayotganimizni aytib beraman.

Bozor qidiruvi arxitekturasi

Biz mikroservislar dunyosida yashayapmiz: har bir kiruvchi so'rov market.yandex.ru ko'plab pastki so'rovlarni keltirib chiqaradi va ularni qayta ishlashda o'nlab xizmatlar ishtirok etadi. Diagrammada faqat bir nechtasi ko'rsatilgan:

So'rovni qayta ishlashning soddalashtirilgan sxemasi

Har bir xizmatning ajoyib narsasi bor - o'ziga xos nomga ega o'z balanslagichi:

Balanslashtiruvchi bizga xizmatni boshqarishda ko'proq moslashuvchanlikni beradi: siz, masalan, yangilanishlar uchun tez-tez talab qilinadigan serverlarni o'chirib qo'yishingiz mumkin. Balanslashtiruvchi server mavjud emasligini ko'radi va so'rovlarni avtomatik ravishda boshqa serverlar yoki ma'lumotlar markazlariga yo'naltiradi. Serverni qo'shish yoki o'chirishda yuk avtomatik ravishda serverlar o'rtasida qayta taqsimlanadi.

Balanslashtiruvchining noyob nomi ma'lumotlar markaziga bog'liq emas. A xizmati B ga so'rov yuborganida, sukut bo'yicha balanslashtiruvchi B so'rovni joriy ma'lumotlar markaziga yo'naltiradi. Agar xizmat mavjud bo'lmasa yoki joriy ma'lumotlar markazida mavjud bo'lmasa, so'rov boshqa ma'lumotlar markazlariga yo'naltiriladi.

Barcha ma'lumotlar markazlari uchun yagona FQDN A xizmatiga joylardan butunlay abstrakt qilish imkonini beradi. Uning B xizmatiga bo'lgan so'rovi doimo ko'rib chiqiladi. Xizmat barcha ma'lumotlar markazlarida joylashgan hol bundan mustasno.

Ammo bu muvozanatlashtiruvchi bilan hamma narsa unchalik qizg'in emas: bizda qo'shimcha oraliq komponent mavjud. Balanslashtiruvchi beqaror bo'lishi mumkin va bu muammo ortiqcha serverlar tomonidan hal qilinadi. Bundan tashqari, A va B xizmatlari o'rtasida qo'shimcha kechikish mavjud. Lekin amalda u 1 ms dan kamroq va ko'pgina xizmatlar uchun bu juda muhim emas.

Kutilmagan holatlar bilan shug'ullanish: Qidiruv xizmati balansi va chidamliligi

Tasavvur qiling-a, qulash bor: siz chiyillashi bilan mushukni topishingiz kerak, lekin server qulab tushadi. Yoki 100 ta server. Qanday chiqish kerak? Biz haqiqatan ham foydalanuvchini mushuksiz qoldiramizmi?

Vaziyat qo'rqinchli, lekin biz bunga tayyormiz. Men sizga tartibda aytaman.

Qidiruv infratuzilmasi bir nechta ma'lumotlar markazlarida joylashgan:

Loyihalashda biz bitta ma'lumot markazini o'chirish imkoniyatini o'z ichiga olamiz. Hayot kutilmagan hodisalar bilan to'la - masalan, ekskavator er osti kabelini kesishi mumkin (ha, shunday bo'ldi). Qolgan ma'lumotlar markazlari sig'imi eng yuqori yuklanishga bardosh berish uchun etarli bo'lishi kerak.

Keling, bitta ma'lumot markazini ko'rib chiqaylik. Har bir ma'lumot markazida bir xil balanslashtiruvchi ish sxemasi mavjud:

Bitta muvozanatlashtiruvchi kamida uchta jismoniy serverdir. Bu ortiqcha ishonchlilik uchun qilingan. Balanslashtiruvchilar HAProx-da ishlaydi.

Biz HAProx-ni yuqori unumdorligi, kam resurs talablari va keng funksionalligi tufayli tanladik. Bizning qidiruv dasturimiz har bir server ichida ishlaydi.

Bitta serverning ishdan chiqishi ehtimoli past. Ammo agar sizda ko'plab serverlar bo'lsa, kamida bittasi ishlamay qolishi ehtimoli ortadi.

Bu haqiqatda sodir bo'ladi: serverlar ishdan chiqadi. Shuning uchun barcha serverlarning holatini doimiy ravishda kuzatib borish kerak. Agar server javob berishni to'xtatsa, u avtomatik ravishda trafikdan uziladi. Shu maqsadda HAProxy o'rnatilgan sog'liq tekshiruviga ega. U barcha serverlarga soniyada bir marta HTTP soʻrovi “/ping” bilan boradi.

HAProxy-ning yana bir xususiyati: agent-check barcha serverlarni bir tekisda yuklash imkonini beradi. Buning uchun HAProxy barcha serverlarga ulanadi va ular 1 dan 100 gacha bo'lgan joriy yukga qarab o'z vaznini qaytaradi. Og'irligi qayta ishlash uchun navbatdagi so'rovlar soni va protsessordagi yukdan kelib chiqqan holda hisoblanadi.

Endi mushukni topish haqida. Qidiruv natijasida quyidagi soʻrovlar paydo boʻladi: /search?text=angry+cat. Qidiruv tez bo'lishi uchun butun mushuk indeksi RAMga mos kelishi kerak. Hatto SSD-dan o'qish ham etarlicha tez emas.

Bir vaqtlar takliflar bazasi kichik edi va buning uchun bitta serverning operativ xotirasi etarli edi. Takliflar bazasi o'sishi bilan hamma narsa endi ushbu RAMga mos kelmaydi va ma'lumotlar ikki qismga bo'lingan: shard 1 va shard 2.

Ammo bu har doim sodir bo'ladi: har qanday yechim, hatto yaxshi bo'lsa ham, boshqa muammolarni keltirib chiqaradi.

Balanslashtiruvchi hali ham istalgan serverga bordi. Ammo so'rov kelgan mashinada indeksning faqat yarmi bor edi. Qolganlari boshqa serverlarda edi. Shuning uchun server qo'shni mashinaga o'tishi kerak edi. Ikkala serverdan ma'lumotlarni olgandan so'ng, natijalar birlashtirildi va qayta tartiblandi.

Balanslashtiruvchi so'rovlarni teng ravishda taqsimlaganligi sababli, barcha serverlar faqat ma'lumotlarni yuborish emas, balki qayta tartiblash bilan shug'ullangan.

Agar qo'shni server mavjud bo'lmasa, muammo yuzaga keldi. Yechim turli ustuvorliklarga ega bo'lgan bir nechta serverlarni "qo'shni" server sifatida belgilash edi. Birinchidan, so'rov joriy rafdagi serverlarga yuborildi. Agar javob bo'lmasa, so'rov ushbu ma'lumotlar markazidagi barcha serverlarga yuborildi. Va nihoyat, so'rov boshqa ma'lumotlar markazlariga yuborildi.
Takliflar soni ortishi bilan ma'lumotlar to'rt qismga bo'lingan. Lekin bu chegara emas edi.

Hozirda sakkizta shard konfiguratsiyasi qo'llaniladi. Bundan tashqari, ko'proq xotirani tejash uchun indeks qidiruv qismiga (qidirish uchun ishlatiladi) va parcha qismiga (qidiruvda ishtirok etmaydigan) bo'lingan.

Bitta server faqat bitta parcha uchun ma'lumotni o'z ichiga oladi. Shuning uchun, to'liq indeksni qidirish uchun siz turli xil parchalarni o'z ichiga olgan sakkizta serverda qidirishingiz kerak.

Serverlar klasterlarga guruhlangan. Har bir klasterda sakkizta qidiruv tizimi va bitta parcha serveri mavjud.

Snippet serveri statik ma'lumotlarga ega kalit-qiymat ma'lumotlar bazasini boshqaradi. Hujjatlarni berish uchun ular kerak, masalan, mushukning shitirlashi bilan tavsifi. Qidiruv serverlarining xotirasini yuklamaslik uchun ma'lumotlar alohida serverga maxsus uzatiladi.

Hujjat identifikatorlari faqat bitta indeks ichida noyob bo'lganligi sababli, parchalarda hujjatlar yo'qligi sababli vaziyat yuzaga kelishi mumkin. Xo'sh, yoki bitta identifikator uchun turli xil tarkib bo'ladi. Shu sababli, qidiruv ishlari samarali bo'lishi va natijalar qaytarilishi uchun butun klaster bo'ylab izchillikka ehtiyoj bor edi. Men sizga izchillikni qanday nazorat qilishimizni quyida aytib beraman.

Qidiruvning o'zi quyidagicha tuzilgan: qidiruv so'rovi sakkizta serverdan istalganiga kelishi mumkin. Aytaylik, u 1-serverga keldi. Bu server barcha argumentlarni qayta ishlaydi va nimani va qanday izlash kerakligini tushunadi. Kiruvchi so'rovga qarab, server zarur ma'lumotlar uchun tashqi xizmatlarga qo'shimcha so'rovlar yuborishi mumkin. Bitta so‘rovdan keyin tashqi xizmatlarga o‘ntagacha so‘rov yuborilishi mumkin.

Kerakli ma'lumotlar to'plangandan so'ng, takliflar bazasida qidiruv boshlanadi. Buning uchun klasterdagi barcha sakkizta serverga quyi so'rovlar amalga oshiriladi.

Javoblar olingandan keyin natijalar birlashtiriladi. Oxir-oqibat, natijalarni yaratish uchun parcha serveriga yana bir nechta quyi so'rovlar kerak bo'lishi mumkin.

Klaster ichidagi qidiruv so'rovlari quyidagicha ko'rinadi: /shard1?text=angry+cat. Bundan tashqari, formaning pastki so'rovlari doimiy ravishda klaster ichidagi barcha serverlar o'rtasida soniyada bir marta amalga oshiriladi: /holat.

So'rov /holat server mavjud bo'lmagan vaziyatni aniqlaydi.

Shuningdek, u qidiruv tizimining versiyasi va indeks versiyasi barcha serverlarda bir xil bo'lishini nazorat qiladi, aks holda klaster ichida nomuvofiq ma'lumotlar bo'ladi.

Bitta snippet-server sakkizta qidiruv tizimining so'rovlarini qayta ishlashiga qaramay, uning protsessori juda kam yuklangan. Shuning uchun biz endi parcha ma'lumotlarini alohida xizmatga o'tkazmoqdamiz.

Ma'lumotlarni uzatish uchun biz hujjatlar uchun universal kalitlarni joriy qildik. Endi bitta kalit yordamida boshqa hujjatning mazmuni qaytarilishi mumkin emas.

Ammo boshqa arxitekturaga o'tish hali tugallanmagan. Endi biz ajratilgan snippet serveridan xalos bo'lishni xohlaymiz. Va keyin klaster tuzilishidan butunlay uzoqlashing. Bu bizga osonlik bilan miqyosni davom ettirish imkonini beradi. Qo'shimcha bonus temirni sezilarli darajada tejashdir.

Va endi baxtli yakun bilan qo'rqinchli hikoyalar. Serverning ishlamasligining bir nechta holatlarini ko'rib chiqaylik.

Dahshatli narsa yuz berdi: bitta server mavjud emas

Aytaylik, bitta server mavjud emas. Keyin klasterdagi qolgan serverlar javob berishda davom etishi mumkin, ammo qidiruv natijalari to'liq bo'lmaydi.

Holatni tekshirish orqali /holat qo'shni serverlar mavjud emasligini tushunishadi. Shuning uchun, to'liqlikni saqlash uchun klasterdagi barcha serverlar har bir so'rov bo'yicha /ping ular muvozanatlashtiruvchiga ular ham mavjud emas deb javob berishni boshlaydilar. Ma'lum bo'lishicha, klasterdagi barcha serverlar nobud bo'lgan (bu haqiqat emas). Bu bizning klaster sxemamizning asosiy kamchiligi - shuning uchun biz undan uzoqlashmoqchimiz.

Xato bilan bajarilmagan so'rovlar balans tuzuvchi tomonidan boshqa serverlarga qayta yuboriladi.
Balanslashtiruvchi, shuningdek, o'lik serverlarga foydalanuvchi trafigini yuborishni to'xtatadi, lekin ularning holatini tekshirishda davom etadi.

Server mavjud bo'lganda, u javob berishni boshlaydi /ping. O'lik serverlardan pingga normal javoblar kela boshlaganda, balanschilar u yerga foydalanuvchi trafigini jo'natishadi. Klaster ishi tiklandi, hurray.

Bundan ham yomoni: ko'plab serverlar mavjud emas

Ma'lumotlar markazidagi serverlarning muhim qismi qisqartirilgan. Nima qilish kerak, qaerga yugurish kerak? Balanschi yana yordamga keladi. Har bir balanschi doimiy ravishda jonli serverlarning joriy sonini xotirada saqlaydi. U doimiy ravishda joriy ma'lumotlar markazi ishlov berishi mumkin bo'lgan maksimal trafik miqdorini hisoblab chiqadi.

Ma'lumotlar markazidagi ko'plab serverlar ishlamay qolganda, balanslashtiruvchi ushbu ma'lumotlar markazi barcha trafikni qayta ishlay olmasligini tushunadi.

Keyin ortiqcha trafik boshqa ma'lumotlar markazlariga tasodifiy taqsimlana boshlaydi. Hammasi ishlaydi, hamma baxtli.

Buni qanday qilamiz: nashrlarni nashr qilish

Keling, xizmatga kiritilgan o'zgarishlarni qanday nashr etishimiz haqida gapiraylik. Bu erda biz jarayonlarni soddalashtirish yo'lini oldik: yangi versiyani chiqarish deyarli to'liq avtomatlashtirilgan.
Loyihada ma'lum miqdordagi o'zgarishlar to'planganda, yangi versiya avtomatik ravishda yaratiladi va uni qurish boshlanadi.

Keyin xizmat sinovga chiqariladi, u erda ish barqarorligi tekshiriladi.

Shu bilan birga, avtomatik ishlash testi ishga tushiriladi. Bu maxsus xizmat tomonidan hal qilinadi. Men hozir bu haqda gapirmayman - uning tavsifi alohida maqolaga loyiqdir.

Agar testda chop etish muvaffaqiyatli bo'lsa, relizni prestableda chop etish avtomatik ravishda boshlanadi. Prestable - bu oddiy foydalanuvchi trafigi yo'naltirilgan maxsus klaster. Agar u xatoni qaytarsa, balanslashtiruvchi ishlab chiqarishga qayta so'rov yuboradi.

Oldindan barqaror rejimda javob vaqtlari o'lchanadi va ishlab chiqarishdagi oldingi versiya bilan taqqoslanadi. Agar hamma narsa yaxshi bo'lsa, u holda odam ulanadi: grafiklarni va yukni sinovdan o'tkazish natijalarini tekshiradi va keyin ishlab chiqarishni boshlaydi.

Eng yaxshisi foydalanuvchiga tushadi: A/B testi

Xizmatga o'zgartirishlar haqiqiy foyda keltiradimi yoki yo'qmi, har doim ham aniq emas. O'zgarishlarning foydaliligini o'lchash uchun odamlar A/B testini o'ylab topishdi. Men sizga Yandex.Market qidiruvida qanday ishlashi haqida bir oz aytib beraman.

Hammasi yangi funktsiyalarni ta'minlaydigan yangi CGI parametrini qo'shish bilan boshlanadi. Bizning parametrimiz quyidagicha bo'lsin: bozor_yangi_funksionalligi=1. Keyin kodda bayroq mavjud bo'lsa, biz ushbu funksiyani yoqamiz:

If (cgi.experiments.market_new_functionality) {
// enable new functionality
}

Yangi funksionallik ishlab chiqarishga chiqarilmoqda.

A/B testini avtomatlashtirish uchun batafsil ma'lumot beruvchi maxsus xizmat mavjud bu yerda tasvirlangan. Xizmatda tajriba yaratiladi. Trafik ulushi, masalan, 15% o'rnatiladi. Foizlar so'rovlar uchun emas, balki foydalanuvchilar uchun o'rnatiladi. Tajribaning davomiyligi ham ko'rsatilgan, masalan, bir hafta.

Bir vaqtning o'zida bir nechta tajribalar o'tkazilishi mumkin. Sozlamalarda siz boshqa tajribalar bilan kesishish mumkinligini belgilashingiz mumkin.

Natijada, xizmat avtomatik ravishda argument qo'shadi bozor_yangi_funksionalligi=1 foydalanuvchilarning 15% gacha. Shuningdek, u tanlangan ko'rsatkichlarni avtomatik ravishda hisoblab chiqadi. Tajriba tugagandan so'ng, tahlilchilar natijalarni ko'rib chiqadilar va xulosalar chiqaradilar. Topilmalar asosida ishlab chiqarish yoki takomillashtirishga yo'naltirish to'g'risida qaror qabul qilinadi.

Bozorning mohir qo'li: ishlab chiqarishda sinov

Ko'pincha siz ishlab chiqarishda yangi funktsiyaning ishlashini sinab ko'rishingiz kerak bo'ladi, lekin siz uning "jangovar" sharoitida og'ir yuk ostida qanday harakat qilishiga ishonchingiz komil emas.

Yechim bor: CGI parametrlaridagi bayroqlar nafaqat A/B testi, balki yangi funksiyalarni sinab ko‘rish uchun ham qo‘llanilishi mumkin.

Biz sizga xizmatni xavf ostiga qo'ymasdan minglab serverlarda konfiguratsiyani bir zumda o'zgartirish imkonini beruvchi vositani yaratdik. U Stop Tap deb ataladi. Asl g'oya, tartibsiz ba'zi funksiyalarni tezda o'chirib qo'yish edi. Keyin asbob kengayib, murakkablashdi.

Xizmatlar oqimi diagrammasi quyida keltirilgan:

Bayroq qiymatlari API orqali o'rnatiladi. Boshqaruv xizmati ushbu qiymatlarni ma'lumotlar bazasida saqlaydi. Barcha serverlar ma'lumotlar bazasiga har o'n soniyada bir marta kiradi, bayroq qiymatlarini chiqaradi va har bir so'rovga ushbu qiymatlarni qo'llaydi.

To'xtatish tugmachasida siz ikki turdagi qiymatlarni o'rnatishingiz mumkin:

1) Shartli iboralar. Qiymatlardan biri rost bo'lganda amal qiling. Masalan:

{
	"condition":"IS_DC1",
	"value":"3",
}, 
{
	"condition": "CLUSTER==2 and IS_BERU", 
	"value": "4!" 
}

"3" qiymati so'rov DC1 manzilida ko'rib chiqilganda qo'llaniladi. Va so'rov beru.ru sayti uchun ikkinchi klasterda ko'rib chiqilganda qiymat "4" ni tashkil qiladi.

2) Shartsiz qiymatlar. Agar shartlarning hech biri bajarilmasa, sukut bo'yicha murojaat qiling. Masalan:

qiymat, qadr!

Agar qiymat undov belgisi bilan tugasa, unga ustunlik beriladi.

CGI parametr tahlilchisi URLni tahlil qiladi. Keyin Stop Tap-dagi qiymatlarni qo'llaydi.

Quyidagi ustuvorliklarga ega qiymatlar qo'llaniladi:

1. Stop Tap (undov belgisi) dan yuqori ustuvorlik bilan.
2. So'rovdan olingan qiymat.
3. Toʻxtatish tegidan standart qiymat.
4. Koddagi standart qiymat.

Shartli qiymatlarda ko'rsatilgan ko'plab bayroqlar mavjud - ular bizga ma'lum bo'lgan barcha stsenariylar uchun etarli:

• Ma'lumotlar markazi.
• Atrof-muhit: ishlab chiqarish, sinov, soya.
• Joy: bozor, beru.
• Klaster raqami.

Ushbu vosita yordamida siz ma'lum bir serverlar guruhida (masalan, faqat bitta ma'lumot markazida) yangi funksiyalarni yoqishingiz va butun xizmat uchun alohida xavf tug'dirmasdan ushbu funksiyaning ishlashini sinab ko'rishingiz mumkin. Agar biror joyda jiddiy xatoga yo'l qo'ygan bo'lsangiz ham, hamma narsa tusha boshladi va butun ma'lumotlar markazi ishlamay qoldi, balanschilar so'rovlarni boshqa ma'lumotlar markazlariga yo'naltiradilar. Yakuniy foydalanuvchilar hech narsani sezmaydilar.

Muammoni sezsangiz, darhol bayroqni oldingi qiymatiga qaytarishingiz mumkin va o'zgarishlar orqaga qaytariladi.

Ushbu xizmatning kamchiliklari ham bor: ishlab chiquvchilar uni juda yaxshi ko'radilar va ko'pincha barcha o'zgarishlarni "Stop Tap" ga surishga harakat qilishadi. Biz noto'g'ri foydalanishga qarshi kurashishga harakat qilmoqdamiz.

Agar sizda barqaror kod ishlab chiqarishga tayyor bo'lsa, Stop Tap yondashuvi yaxshi ishlaydi. Shu bilan birga, sizda hali ham shubha bor va siz kodni "jangovar" sharoitda tekshirishni xohlaysiz.

Biroq, Stop Tap dasturi ishlab chiqish jarayonida sinov uchun mos emas. Ishlab chiquvchilar uchun "soya klasteri" deb nomlangan alohida klaster mavjud.

Yashirin test: soyali klaster

Klasterlardan birining so'rovlari soyali klasterga takrorlanadi. Ammo muvozanatlashtiruvchi ushbu klasterning javoblarini butunlay e'tiborsiz qoldiradi. Uning ishlash diagrammasi quyida keltirilgan.

Biz haqiqiy "jangovar" sharoitda bo'lgan sinov klasterini olamiz. Oddiy foydalanuvchi trafigi u erga boradi. Ikkala klasterdagi apparat bir xil, shuning uchun unumdorlik va xatolarni solishtirish mumkin.

Balanslashtiruvchi javoblarni butunlay e'tiborsiz qoldirganligi sababli, oxirgi foydalanuvchilar soya klasteridan javoblarni ko'rmaydilar. Shuning uchun xato qilish qo'rqinchli emas.

topilmalar

Xo'sh, biz bozor qidiruvini qanday yaratdik?

Hammasi muammosiz bo'lishi uchun biz funksionallikni alohida xizmatlarga ajratamiz. Shunday qilib, biz faqat o'zimizga kerak bo'lgan komponentlarni o'lchashimiz va komponentlarni soddalashtirishimiz mumkin. Boshqa jamoaga alohida komponentni tayinlash va u ustida ishlash uchun mas'uliyatni bo'lishish oson. Va bu yondashuv bilan temirni sezilarli darajada tejash aniq ortiqcha.

Soya klasteri ham bizga yordam beradi: biz xizmatlarni ishlab chiqishimiz, ularni jarayonda sinab ko‘rishimiz va foydalanuvchini bezovta qilmasligimiz mumkin.

Xo'sh, ishlab chiqarishda sinov, albatta. Minglab serverlarda konfiguratsiyani o'zgartirish kerakmi? Oson, Stop Tap-dan foydalaning. Shunday qilib, agar muammo yuzaga kelsa, darhol tayyor kompleks yechimni chiqarib, barqaror versiyaga qaytishingiz mumkin.

Umid qilamanki, biz bozorni qanday tez va barqaror qilishimizni ko'rsata oldim va takliflar bazasi tobora o'sib bormoqda. Qanday qilib biz server muammolarini hal qilamiz, ko'p sonli so'rovlarni hal qilamiz, xizmatning moslashuvchanligini yaxshilaymiz va buni ish jarayonlarini to'xtatmasdan qilamiz.

Manba: www.habr.com