Сайн уу, намайг Евгений гэдэг. Би Yandex.Market хайлтын дэд бүтцэд ажилладаг. Би Хабр нийгэмлэгт захын дотоод гал тогооны талаар хэлэхийг хүсч байна - надад хэлэх зүйл их байна. Юуны өмнө Зах зээлийн хайлт хэрхэн ажилладаг, үйл явц, архитектур. Онцгой байдлын үед бид хэрхэн ажиллах вэ: нэг сервер унтарвал яах вэ? Ийм 100 сервер байвал яах вэ?
Та мөн хэд хэдэн сервер дээр шинэ функцуудыг хэрхэн хэрэгжүүлэх талаар суралцах болно. Мөн бид нарийн төвөгтэй үйлчилгээг хэрэглэгчдэд төвөг учруулахгүйгээр шууд үйлдвэрлэлд хэрхэн туршиж үздэг. Ерөнхийдөө зах зээлийн хайлт хэрхэн ажилладаг тул хүн бүр цагийг сайхан өнгөрүүлдэг.
Бидний тухай бага зэрэг: бид ямар асуудлыг шийддэг
Та текст оруулах, параметрээр бүтээгдэхүүн хайх, эсвэл өөр өөр дэлгүүрийн үнийг харьцуулах үед бүх хүсэлт хайлтын үйлчилгээ рүү илгээгдэнэ. Хайлт бол зах зээлийн хамгийн том үйлчилгээ юм.
Бид хайлтын бүх хүсэлтийг боловсруулдаг: market.yandex.ru, beru.ru, Supercheck үйлчилгээ, Yandex.Advisor, гар утасны програмуудаас. Бид мөн yandex.ru дээрх хайлтын үр дүнд бүтээгдэхүүний саналыг оруулдаг.
Хайлтын үйлчилгээ гэж би зөвхөн хайлтыг төдийгүй зах зээл дээрх бүх саналыг агуулсан мэдээллийн санг хэлж байна. Хэмжээ нь ийм байна: өдөрт нэг тэрбум гаруй хайлтын хүсэлтийг боловсруулдаг. Мөн бүх зүйл хурдан, тасалдалгүйгээр ажиллаж, хүссэн үр дүнг үргэлж өгөх ёстой.
Юу вэ: Зах зээлийн архитектур
Би зах зээлийн өнөөгийн архитектурыг товч тайлбарлах болно. Үүнийг дараах диаграмаар ойролцоогоор тодорхойлж болно.
Түнш дэлгүүр манайд ирлээ гэж бодъё. Тэр хэлэхдээ би тоглоом зармаар байна: энэ муу муур дуугарч байна. Бас нэг жиргээгүй ууртай муур. Тэгээд зүгээр л муур. Дараа нь дэлгүүр нь зах зээл хайж байгаа саналуудыг бэлтгэх хэрэгтэй. Дэлгүүр нь санал болгож буй тусгай xml үүсгэж, түншлэлийн интерфейсээр дамжуулан энэ xml рүү хүрэх замыг харуулдаг. Дараа нь индексжүүлэгч нь энэ xml-ийг үе үе татаж аваад, алдааг шалгаж, бүх мэдээллийг асар том мэдээллийн санд хадгалдаг.
Ийм хадгалсан xml олон бий. Энэ мэдээллийн сангаас хайлтын индекс үүсгэгддэг. Индексийг дотоод форматаар хадгалдаг. Индексийг үүсгэсний дараа Layout үйлчилгээ нь хайлтын серверт байршуулдаг.
Үүний үр дүнд өгөгдлийн санд хашгирах ууртай муур гарч ирэх бөгөөд муурны индекс сервер дээр гарч ирнэ.
Хайлтын архитектурын хэсэгт бид муурыг хэрхэн хайж байгааг танд хэлэх болно.
Зах зээлийн хайлтын архитектур
Бид микро үйлчилгээний ертөнцөд амьдарч байна: ирж буй хүсэлт бүр нь маш олон дэд асуулга үүсгэдэг бөгөөд тэдгээрийг боловсруулахад олон арван үйлчилгээ оролцдог. Диаграм нь зөвхөн цөөн хэдэн зүйлийг харуулж байна:
Хүсэлтийг боловсруулах хялбаршуулсан схем
Үйлчилгээ бүр гайхалтай зүйлтэй байдаг - өвөрмөц нэртэй өөрийн тэнцвэржүүлэгч:
Тэнцвэржүүлэгч нь үйлчилгээг удирдахад илүү уян хатан байдлыг өгдөг: жишээлбэл, шинэчлэлт хийхэд ихэвчлэн шаардлагатай серверүүдийг унтрааж болно. Тэнцвэржүүлэгч серверийг ашиглах боломжгүй байгааг хараад автоматаар хүсэлтийг бусад сервер эсвэл дата төв рүү чиглүүлдэг. Сервер нэмэх эсвэл хасах үед ачааллыг серверүүдийн хооронд автоматаар дахин хуваарилдаг.
Тэнцвэржүүлэгчийн өвөрмөц нэр нь мэдээллийн төвөөс хамаардаггүй. А үйлчилгээ нь В-д хүсэлт гаргах үед анхдагчаар тэнцвэржүүлэгч В хүсэлтийг одоогийн дата төв рүү дахин чиглүүлдэг. Хэрэв үйлчилгээ байхгүй эсвэл одоогийн дата төвд байхгүй бол хүсэлтийг бусад дата төв рүү шилжүүлнэ.
Бүх өгөгдлийн төвүүдэд зориулсан ганц FQDN нь А үйлчилгээг байршлаас бүрэн салгах боломжийг олгодог. Түүний В үйлчилгээ үзүүлэх хүсэлтийг үргэлж авч үзэх болно. Үл хамаарах зүйл бол үйлчилгээ нь бүх мэдээллийн төвд байрладаг тохиолдол юм.
Гэхдээ энэ тэнцвэржүүлэгчийн хувьд бүх зүйл тийм ч ягаан биш юм: бидэнд нэмэлт завсрын бүрэлдэхүүн хэсэг бий. Тэнцвэржүүлэгч тогтворгүй байж магадгүй бөгөөд энэ асуудлыг илүүдэл серверүүд шийддэг. Мөн А болон В үйлчилгээний хооронд нэмэлт саатал гардаг. Гэвч бодит байдал дээр энэ нь 1 мс-ээс бага байдаг бөгөөд ихэнх үйлчилгээний хувьд энэ нь тийм ч чухал биш юм.
Гэнэтийн асуудлыг шийдвэрлэх: Хайлтын үйлчилгээний тэнцвэр ба уян хатан байдал
Уналт гарч байна гэж төсөөлөөд үз дээ: чи шуугиантай муур олох хэрэгтэй, гэхдээ сервер гацсан. Эсвэл 100 сервер. Яаж гарах вэ? Бид үнэхээр хэрэглэгчийг муургүйгээр үлдээх гэж байна уу?
Нөхцөл байдал аймшигтай байгаа ч бид үүнд бэлэн байна. Би танд дарааллаар нь хэлье.
Хайлтын дэд бүтэц нь хэд хэдэн мэдээллийн төвд байрладаг:
Зураг төсөл боловсруулахдаа бид нэг дата төвийг хаах боломжийг тусгасан. Амьдрал гэнэтийн зүйлээр дүүрэн байдаг - жишээлбэл, экскаватор газар доорх кабелийг огтолж чаддаг (тиймээ, ийм зүйл болсон). Үлдсэн мэдээллийн төвүүдийн хүчин чадал нь хамгийн их ачааллыг тэсвэрлэхэд хангалттай байх ёстой.
Нэг дата төвийг авч үзье. Дата төв бүр ижил тэнцвэржүүлэгч үйлдлийн схемтэй:
Нэг тэнцвэржүүлэгч нь дор хаяж гурван физик сервер юм. Энэхүү илүүдэл нь найдвартай байдлын үүднээс хийгдсэн. Тэнцвэржүүлэгчид HAProx дээр ажилладаг.
Бид HAProx-ийг өндөр гүйцэтгэлтэй, нөөц багатай, өргөн ажиллагаатай учраас сонгосон. Манай хайлтын программ сервер бүрийн дотор ажилладаг.
Нэг сервер доголдох магадлал бага байна. Гэхдээ хэрэв танд олон сервер байгаа бол дор хаяж нэг сервер ажиллахгүй байх магадлал нэмэгддэг.
Бодит байдал дээр ийм зүйл тохиолддог: серверүүд эвдэрч байна. Тиймээс бүх серверийн статусыг байнга хянаж байх шаардлагатай. Хэрэв сервер хариу өгөхөө больсон бол автоматаар траффикээс салгагдана. Энэ зорилгоор HAProxy нь эрүүл мэндийн үзлэгт суурилуулсан байдаг. Энэ нь "/ping" HTTP хүсэлтээр бүх серверүүд рүү секундэд нэг удаа очдог.
HAProxy-ийн өөр нэг онцлог: agent-check нь бүх серверүүдийг жигд ачаалах боломжийг олгодог. Үүнийг хийхийн тулд HAProxy нь бүх серверүүдтэй холбогддог бөгөөд тэдгээр нь одоогийн ачааллаас хамааран 1-ээс 100 хүртэл жингээ буцаана. Жинг боловсруулах дараалалд байгаа хүсэлтийн тоо болон процессорын ачаалал дээр үндэслэн тооцдог.
Одоо муур олох тухай. Хайлтын үр дүнд дараах хүсэлтүүд гарч ирдэг: /хайх?текст=ууртай+муур. Хайлт хурдан байхын тулд муурны индекс бүхэлдээ RAM-д багтах ёстой. SSD-ээс унших нь ч хангалттай хурдан биш юм.
Нэгэн цагт санал болгож буй мэдээллийн сан бага байсан бөгөөд нэг серверийн RAM хангалттай байсан. Саналын бааз нэмэгдэхийн хэрээр бүх зүйл энэ RAM-д багтахаа больсон бөгөөд өгөгдөл нь shard 1, shard 2 гэсэн хоёр хэсэгт хуваагдсан.
Гэхдээ энэ нь үргэлж тохиолддог: аливаа шийдэл, тэр ч байтугай сайн шийдэл нь бусад асуудлуудыг үүсгэдэг.
Тэнцвэржүүлэгч ямар ч сервер рүү очсон хэвээр байна. Гэтэл хүсэлт ирсэн машин дээр индексийн тал нь л байсан. Үлдсэн хэсэг нь бусад серверүүд дээр байсан. Тиймээс сервер хөрш зэргэлдээ машин руу очих шаардлагатай болсон. Хоёр серверээс өгөгдлийг хүлээн авсны дараа үр дүнг нэгтгэж, дахин эрэмбэлсэн.
Тэнцвэржүүлэгч нь хүсэлтийг жигд хуваарилдаг тул бүх серверүүд зөвхөн өгөгдөл илгээхээс гадна дахин эрэмбэлэгдсэн байв.
Хэрэв хөрш зэргэлдээ сервер ажиллахгүй бол асуудал гарсан. Үүний шийдэл нь өөр өөр ач холбогдолтой хэд хэдэн серверийг "хөрш" сервер болгон зааж өгөх явдал байв. Эхлээд хүсэлтийг одоогийн тавиур дээр байгаа серверүүд рүү илгээсэн. Хэрэв хариу ирээгүй бол хүсэлтийг энэ дата төвийн бүх серверт илгээсэн. Эцэст нь хүсэлт бусад дата төвүүдэд очсон.
Саналын тоо нэмэгдэхийн хэрээр өгөгдлийг дөрвөн хэсэгт хуваасан. Гэхдээ энэ нь хязгаар биш байсан.
Одоогоор найман хэлтэрхийний тохиргоог ашиглаж байна. Нэмж дурдахад илүү их санах ойг хэмнэхийн тулд индексийг хайлтын хэсэг (хайлт хийхэд ашигладаг) болон хэсэгчилсэн хэсэг (хайлтанд оролцдоггүй) гэж хуваасан.
Нэг сервер зөвхөн нэг хэлтэрхийн мэдээллийг агуулна. Тиймээс, бүтэн индексийг хайхын тулд өөр өөр хэлтэрхий агуулсан найман серверээс хайх хэрэгтэй.
Серверүүд нь кластерт хуваагддаг. Кластер бүр найман хайлтын систем, нэг хэсэгчилсэн сервер агуулдаг.
Хэсгийн сервер нь статик өгөгдөл бүхий түлхүүр утгын мэдээллийн санг ажиллуулдаг. Тэд бичиг баримтыг гаргахад шаардлагатай байдаг, жишээлбэл, муурны дуу чимээний тодорхойлолт. Хайлтын серверүүдийн санах ойг ачаалахгүйн тулд өгөгдлийг тусдаа сервер рүү тусгайлан шилжүүлдэг.
Баримт бичгийн ID нь зөвхөн нэг индекс дотор өвөрмөц байдаг тул хэсэгчилсэн баримт бичиг байхгүй тохиолдолд нөхцөл байдал үүсч болно. За, эсвэл нэг ID-ийн хувьд өөр агуулгатай байх болно. Тиймээс хайлт амжилттай болж, үр дүн нь эргэж ирэхийн тулд бүхэл бүтэн кластерт тууштай байх шаардлагатай байв. Бид тууштай байдлыг хэрхэн хянах талаар би доор хэлэх болно.
Хайлт нь өөрөө дараах бүтэцтэй: хайлтын хүсэлт найман серверийн аль нэгэнд ирж болно. Тэр 1-р серверт ирсэн гэж бодъё. Энэ сервер бүх аргументуудыг боловсруулж, юуг хэрхэн хайхыг ойлгодог. Ирж буй хүсэлтээс хамааран сервер нь шаардлагатай мэдээллээр гадны үйлчилгээнд нэмэлт хүсэлт гаргаж болно. Нэг хүсэлтийн араас гаднах үйлчилгээнд арав хүртэлх хүсэлт ирж болно.
Шаардлагатай мэдээллийг цуглуулсны дараа саналын санд хайлт эхэлнэ. Үүнийг хийхийн тулд кластерын бүх найман серверт дэд асуулга хийдэг.
Хариултуудыг хүлээн авсны дараа үр дүнг нэгтгэнэ. Эцэст нь үр дүнг гаргахын тулд хэсэгчилсэн серверийн хэд хэдэн дэд асуулга шаардлагатай байж магадгүй юм.
Кластер доторх хайлтын асуулга дараах байдалтай байна. /shard1?текст=ууртай+муур. Нэмж дурдахад, маягтын дэд асуулга нь секундэд нэг удаа кластер доторх бүх серверүүдийн хооронд байнга хийгддэг: /төлөв.
Хүсэлт гаргах /төлөв сервер байхгүй нөхцөл байдлыг илрүүлдэг.
Энэ нь хайлтын системийн хувилбар болон индексийн хувилбар нь бүх сервер дээр ижил байхыг хянадаг, эс тэгвээс кластер дотор үл нийцэх өгөгдөл байх болно.
Хэдийгээр нэг хэсэгчилсэн сервер найман хайлтын системээс хүсэлтийг боловсруулдаг ч процессор нь маш бага ачаалалтай байдаг. Тиймээс бид одоо хэсэгчилсэн өгөгдлийг тусдаа үйлчилгээ рүү шилжүүлж байна.
Өгөгдөл дамжуулахын тулд бид баримт бичгийн бүх нийтийн түлхүүрүүдийг нэвтрүүлсэн. Одоо өөр баримт бичгийн агуулгыг нэг түлхүүр ашиглан буцаах нөхцөл байдал боломжгүй юм.
Гэхдээ өөр архитектурт шилжих ажил хараахан дуусаагүй байна. Одоо бид тусгай зориулалтын snippet серверээс салахыг хүсч байна. Тэгээд кластерийн бүтцээс бүрмөсөн холд. Энэ нь биднийг үргэлжлүүлэн хялбархан масштаблах боломжийг олгоно. Нэмэлт урамшуулал бол төмрийн ихээхэн хэмнэлт юм.
Одоо аз жаргалтай төгсгөлтэй аймшигтай түүхүүд. Сервер ашиглах боломжгүй болсон хэд хэдэн тохиолдлыг авч үзье.
Ямар нэг аймшигтай зүйл болсон: нэг сервер ажиллах боломжгүй байна
Нэг сервер боломжгүй байна гэж бодъё. Дараа нь кластер дахь үлдсэн серверүүд хариу өгөх боломжтой боловч хайлтын үр дүн бүрэн бус байх болно.
Статус шалгах замаар /төлөв Хөрш зэргэлдээх серверүүд нэг нь боломжгүй гэдгийг ойлгодог. Тиймээс, бүрэн бүтэн байдлыг хангахын тулд кластер дахь бүх серверүүд хүсэлт тус бүрээр /ping Тэд тэнцвэржүүлэгчид бас боломжгүй гэж хариулж эхэлдэг. Кластер дахь бүх серверүүд үхсэн (энэ нь үнэн биш юм). Энэ бол манай кластер схемийн гол сул тал - ийм учраас бид үүнээс холдохыг хүсч байна.
Алдаатай бүтэлгүйтсэн хүсэлтийг тэнцвэржүүлэгч бусад серверүүд дээр дахин илгээдэг.
Тэнцвэржүүлэгч нь үхсэн серверүүд рүү хэрэглэгчийн урсгалыг илгээхээ больсон ч тэдний статусыг үргэлжлүүлэн шалгадаг.
Сервер бэлэн болсон үед энэ нь хариу өгч эхэлдэг /ping. Үхсэн серверүүдийн пингэд ердийн хариу ирж эхэлмэгц тэнцвэржүүлэгчид хэрэглэгчийн траффикийг тэнд илгээж эхэлдэг. Кластерийн ажиллагаа сэргэлээ, яараарай.
Бүр муу: олон сервер ажиллах боломжгүй байна
Дата төвийн серверүүдийн нэлээд хэсэг нь хасагдсан. Юу хийх вэ, хаашаа гүйх вэ? Тэнцвэрлэгч дахин аврах ажилд ирдэг. Тэнцвэржүүлэгч бүр санах ойд одоогийн серверийн тоог байнга хадгалдаг. Энэ нь одоогийн дата төвийн боловсруулж чадах хамгийн их урсгалыг байнга тооцдог.
Дата төвийн олон серверүүд ажиллахаа больсон үед тэнцвэржүүлэгч энэ дата төв нь бүх урсгалыг боловсруулах боломжгүй гэдгийг ойлгодог.
Дараа нь илүүдэл траффик бусад дата төвүүдэд санамсаргүй байдлаар хуваарилагдаж эхэлдэг. Бүх зүйл ажилладаг, бүгд баяртай байдаг.
Бид үүнийг хэрхэн хийдэг: хэвлэлийг нийтлэх
Одоо үйлчилгээнд оруулсан өөрчлөлтийг хэрхэн нийтлэх талаар ярилцъя. Энд бид үйл явцыг хялбаршуулах замаар явлаа: шинэ хувилбар гаргах нь бараг бүрэн автоматжуулсан.
Төсөлд тодорхой тооны өөрчлөлтүүд хуримтлагдсан тохиолдолд шинэ хувилбар автоматаар үүсгэгдэж, бүтээгдэж эхэлнэ.
Дараа нь уг үйлчилгээг туршилтанд шилжүүлж, үйл ажиллагааны тогтвортой байдлыг шалгана.
Үүний зэрэгцээ гүйцэтгэлийн автомат туршилтыг эхлүүлсэн. Үүнийг тусгай алба зохицуулдаг. Би энэ тухай одоо ярихгүй - түүний тайлбар нь тусдаа нийтлэлд зориулагдсан болно.
Туршилтанд амжилттай нийтлэгдсэн тохиолдолд prestable-д хувилбарыг хэвлэх ажлыг автоматаар эхлүүлнэ. Prestable бол ердийн хэрэглэгчийн урсгалыг чиглүүлдэг тусгай кластер юм. Хэрэв алдаа гарвал тэнцвэржүүлэгч үйлдвэрлэлд дахин хүсэлт гаргана.
Урьдчилан тогтворжсон тохиолдолд хариу өгөх хугацааг хэмжиж, үйлдвэрлэлийн өмнөх хувилбартай харьцуулдаг. Хэрэв бүх зүйл хэвийн байгаа бол хүн холбогддог: ачааллын туршилтын график, үр дүнг шалгаж, дараа нь үйлдвэрлэлд нэвтэрч эхэлнэ.
Хамгийн сайн нь хэрэглэгчдэд зориулагдана: A/B тест
Үйлчилгээнд өөрчлөлт оруулах нь бодит үр өгөөж авчрах эсэх нь үргэлж тодорхой байдаггүй. Өөрчлөлтүүдийн ашиг тусыг хэмжихийн тулд хүмүүс A/B тест хийсэн. Yandex.Market хайлт дээр хэрхэн ажилладаг талаар би танд бага зэрэг хэлэх болно.
Энэ бүхэн шинэ функцийг идэвхжүүлэх шинэ CGI параметр нэмэхээс эхэлдэг. Бидний параметр бол: зах зээлийн_шинэ_функц=1. Хэрэв туг байгаа бол кодонд бид энэ функцийг идэвхжүүлнэ:
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}Шинэ функцийг үйлдвэрлэлд нэвтрүүлж байна.
A/B тестийг автоматжуулахын тулд нарийвчилсан мэдээлэл өгдөг тусгай үйлчилгээ байдаг . Үйлчилгээнд туршилтыг үүсгэсэн. Замын хөдөлгөөний эзлэх хувь, жишээлбэл, 15% байна. Хувиар нь асуулгад бус харин хэрэглэгчдэд зориулагдсан болно. Туршилтын үргэлжлэх хугацааг, жишээлбэл, долоо хоногоор зааж өгсөн болно.
Хэд хэдэн туршилтыг нэгэн зэрэг хийж болно. Тохиргоонд та бусад туршилтуудтай огтлолцох боломжтой эсэхийг зааж өгч болно.
Үүний үр дүнд үйлчилгээ автоматаар аргумент нэмдэг зах зээлийн_шинэ_функц=1 хэрэглэгчдийн 15% хүртэл. Мөн сонгосон хэмжүүрүүдийг автоматаар тооцдог. Туршилт дууссаны дараа шинжээчид үр дүнг харж, дүгнэлт гаргадаг. Судалгааны үр дүнд үндэслэн үйлдвэрлэлд нэвтрүүлэх эсвэл сайжруулах шийдвэр гаргадаг.
Зах зээлийн авъяас чадвар: үйлдвэрлэлд туршилт хийх
Үйлдвэрлэлд шинэ функцийг туршиж үзэх шаардлагатай байдаг ч хүнд ачаалалтай "байлдааны" нөхцөлд хэрхэн ажиллахаа мэдэхгүй байна.
Шийдэл бий: CGI параметрүүд дэх тугуудыг зөвхөн A/B тест хийхэд ашиглахаас гадна шинэ функцийг шалгахад ашиглаж болно.
Бид танд үйлчилгээг эрсдэлд оруулахгүйгээр олон мянган серверийн тохиргоог нэн даруй өөрчлөх боломжийг олгодог хэрэгслийг хийсэн. Үүнийг Stop Tap гэж нэрлэдэг. Анхны санаа нь ямар ч зохион байгуулалтгүйгээр зарим функцийг хурдан идэвхгүй болгох явдал байв. Дараа нь багаж нь өргөжиж, илүү төвөгтэй болсон.
Үйлчилгээний урсгалын диаграммыг доор үзүүлэв.
Тугны утгыг API-ээр тохируулдаг. Удирдлагын үйлчилгээ нь эдгээр утгыг мэдээллийн санд хадгалдаг. Бүх серверүүд мэдээллийн сан руу арван секунд тутамд нэг удаа очиж, тугны утгыг шахаж, хүсэлт бүрт эдгээр утгыг хэрэглэнэ.
Зогсоох товчлуур дээр та хоёр төрлийн утгыг тохируулж болно:
1) Нөхцөл илэрхийлэл. Утгын аль нэг нь үнэн бол хэрэглэнэ. Жишээлбэл:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}Хүсэлтийг DC3 байршилд боловсруулах үед "1" утгыг хэрэглэнэ. Хүсэлтийг beru.ru сайтын хоёр дахь кластер дээр боловсруулахад утга нь "4" байна.
2) болзолгүй утгууд. Нөхцөлүүдийн аль нь ч хангагдаагүй бол анхдагчаар өргөдөл гаргана. Жишээлбэл:
үнэ цэнэ, үнэ цэнэ!
Хэрэв утга нь анхаарлын тэмдэгээр төгссөн бол илүү өндөр ач холбогдол өгнө.
CGI параметрийн анализатор нь URL-г задлан шинжилдэг. Дараа нь Stop Tap-ийн утгуудыг хэрэглэнэ.
Дараахь тэргүүлэх ач холбогдол бүхий утгуудыг хэрэглэнэ.
- Зогсоох товшилтоор давуу эрх нэмэгдүүлсэн (анхны тэмдэг).
- Хүсэлтийн үнэ цэнэ.
- Stop товшилтын өгөгдмөл утга.
- Кодын өгөгдмөл утга.
Нөхцөлт утгуудад заасан олон тугнууд байдаг - тэдгээр нь бидэнд мэдэгдэж байгаа бүх хувилбаруудад хангалттай.
- Мэдээллийн төв.
- Байгаль орчин: үйлдвэрлэл, туршилт, сүүдэр.
- Байршил: зах, Беру.
- Кластерын дугаар.
Энэ хэрэгслийн тусламжтайгаар та тодорхой бүлэг серверүүд дээр (жишээлбэл, зөвхөн нэг мэдээллийн төвд) шинэ функцийг идэвхжүүлж, бүх үйлчилгээнд онцгой эрсдэлгүйгээр энэ функцын ажиллагааг шалгах боломжтой. Хэдийгээр та хаа нэгтээ ноцтой алдаа гаргасан ч бүх зүйл буурч, дата төв бүхэлдээ уналтад орсон ч тэнцвэржүүлэгчид хүсэлтийг бусад дата төв рүү шилжүүлэх болно. Эцсийн хэрэглэгчид юу ч анзаарахгүй.
Хэрэв та асуудал анзаарсан бол тугийг нэн даруй өмнөх утга руу нь буцаах боломжтой бөгөөд өөрчлөлтийг буцаах болно.
Энэ үйлчилгээ нь бас сул талуудтай: хөгжүүлэгчид үүнийг маш их хайрладаг бөгөөд ихэнхдээ бүх өөрчлөлтийг Stop Tap руу түлхэхийг оролддог. Бид буруу хэрэглээтэй тэмцэхийг хичээж байна.
Тогтвортой кодыг үйлдвэрлэлд нэвтрүүлэхэд бэлэн байгаа үед Stop Tap арга нь сайн ажилладаг. Үүний зэрэгцээ та эргэлзээтэй хэвээр байгаа бөгөөд "байлдааны" нөхцөлд кодыг шалгахыг хүсч байна.
Гэсэн хэдий ч Stop Tap нь хөгжүүлэлтийн явцад туршилт хийхэд тохиромжгүй. "Сүүдрийн кластер" гэж нэрлэгддэг хөгжүүлэгчдэд зориулсан тусдаа кластер байдаг.
Нууц тест: Сүүдрийн кластер
Кластеруудын аль нэгнийх нь хүсэлтийг сүүдрийн кластерт давхардуулдаг. Гэхдээ тэнцвэржүүлэгч нь энэ кластерын хариуг бүрэн үл тоомсорлодог. Түүний үйл ажиллагааны диаграммыг доор үзүүлэв.
Бид жинхэнэ "байлдааны" нөхцөлд байгаа туршилтын кластер авдаг. Ердийн хэрэглэгчийн урсгал тэнд очдог. Хоёр кластерын техник хангамж ижил тул гүйцэтгэл болон алдааг харьцуулж болно.
Тэнцвэржүүлэгч хариуг бүрэн үл тоомсорлодог тул эцсийн хэрэглэгчид сүүдрийн кластерийн хариултыг харахгүй. Тиймээс алдаа гаргах нь аймшигтай биш юм.
үр дүн нь
Тэгэхээр бид зах зээлийн хайлтыг хэрхэн бүтээсэн бэ?
Бүх зүйл хэвийн ажиллахын тулд бид функцийг тусдаа үйлчилгээ болгон хуваадаг. Ингэснээр бид зөвхөн хэрэгцээтэй бүрэлдэхүүн хэсгүүдийн хэмжээг томруулж, бүрэлдэхүүн хэсгүүдийг илүү хялбар болгож чадна. Тусдаа бүрэлдэхүүн хэсгийг өөр багт хуваарилж, үүн дээр ажиллах үүрэг хариуцлагыг хуваалцахад хялбар байдаг. Энэ аргын тусламжтайгаар төмрийн ихээхэн хэмнэлт нь илт давуу тал юм.
Сүүдрийн кластер нь бидэнд тусалдаг: бид үйлчилгээг хөгжүүлж, үйл явцад нь туршиж, хэрэглэгчдэд саад болохгүй.
За, мэдээжийн хэрэг үйлдвэрлэлд туршиж байна. Олон мянган серверийн тохиргоог өөрчлөх шаардлагатай юу? Амархан, Зогсоох товчлуурыг ашигла. Ингэснээр та нэн даруй бэлэн цогц шийдлийг гаргаж, асуудал гарвал тогтвортой хувилбар руу буцах боломжтой.
Үргэлж өсөн нэмэгдэж буй саналуудаар бид зах зээлийг хэрхэн хурдан бөгөөд тогтвортой болгож байгааг харуулж чадсан гэж найдаж байна. Бид серверийн асуудлыг хэрхэн шийдэж, асар олон тооны хүсэлтийг шийдэж, үйлчилгээний уян хатан байдлыг сайжруулж, ажлын процессыг тасалдуулахгүйгээр хийдэг.
Эх сурвалж: www.habr.com