Амралтын өдрүүд дуусаж, бид Istio Service Mesh цувралын XNUMX дахь нийтлэлээрээ эргэн ирлээ.
Өнөөдрийн сэдэв бол Circuit Breaker бөгөөд орос хэл рүү цахилгааны инженерээр орчуулбал "хэлхээ таслагч" гэсэн утгатай бөгөөд энгийн хэллэгээр "хэлхээ таслагч" гэсэн утгатай. Зөвхөн Istio-д энэ машин нь богино холболт эсвэл хэт ачаалалтай хэлхээг салгадаггүй, харин алдаатай савыг салгадаггүй.
Энэ нь хэрхэн хамгийн тохиромжтой ажиллах ёстой
Бичил үйлчилгээг Kubernetes удирддаг бол жишээ нь OpenShift платформ дотор ачааллаас хамааран автоматаар томордог. Микро үйлчилгээ нь pods-д ажилладаг тул нэг төгсгөлийн цэг дээр чингэлэгжүүлсэн микро үйлчилгээний олон тохиолдол байж болох ба Кубернетес хүсэлтийг чиглүүлж, тэдгээрийн хооронд ачааллын тэнцвэрийг бий болгоно. Хамгийн тохиромжтой нь - энэ бүхэн төгс ажиллах ёстой.
Микро үйлчилгээ нь жижиг бөгөөд түр зуурынх гэдгийг бид санаж байна. Энд гарч ирэх, алга болоход хялбар гэсэн утгатай түр зуурын чанарыг ихэвчлэн дутуу үнэлдэг. Боодол дахь микро үйлчилгээний өөр нэг тохиолдлын төрөлт, үхэл нь нэлээд хүлээгдэж буй зүйл бөгөөд OpenShift болон Kubernetes үүнийг сайн зохицуулдаг бөгөөд бүх зүйл маш сайн ажилладаг - гэхдээ онолын хувьд дахин.
Энэ нь үнэхээр яаж ажилладаг
Микро үйлчилгээний тодорхой жишээ, өөрөөр хэлбэл контейнер ашиглах боломжгүй болсон гэж төсөөлөөд үз дээ: эсвэл энэ нь хариу өгөхгүй (алдаа 503), эсвэл илүү тааламжгүй нь хариу үйлдэл үзүүлдэг, гэхдээ хэтэрхий удаан. Өөрөөр хэлбэл, энэ нь алдаатай эсвэл хүсэлтэд хариу өгөхгүй, гэхдээ энэ нь автоматаар усан сангаас хасагддаггүй. Энэ тохиолдолд юу хийх ёстой вэ? Дахин оролдох уу? Би үүнийг чиглүүлэлтийн схемээс хасах ёстой юу? Мөн "хэт удаан" гэж юу гэсэн үг вэ - энэ нь хэдэн тоо вэ, хэн үүнийг тодорхойлдог вэ? Магадгүй түр завсарлаад дараа дахин оролдоно уу? Хэрэв тийм бол хэр хугацааны дараа?
Istio дахь Pool Ejection гэж юу вэ
Энд Istio нь Цөөрмөөс зайлуулах процедурыг хэрэгжүүлж, чиглүүлэлт, ачааллыг тэнцвэржүүлэх нөөцийн сангаас гэмтэлтэй савыг түр хугацаанд зайлуулдаг Хэлхээ таслагч хамгаалалтын машинаараа аврах ажилд ирдэг.
Хэт хэтийн үзүүлэлтийг илрүүлэх стратегийг ашиглан Istio нь шугамаас гадуур байгаа муруй хонхоруудыг илрүүлж, тэдгээрийг унтах цонх гэж нэрлэгддэг тодорхой хугацааны туршид нөөцийн сангаас устгадаг.
Энэ нь OpenShift платформ дээрх Кубернетес дээр хэрхэн ажилладгийг харуулахын тулд репозитор дахь жишээнээс хэвийн ажиллаж байгаа микро үйлчилгээний дэлгэцийн агшинг авч үзье. . Энд бид v1 ба v2 гэсэн хоёр podтой бөгөөд тус бүр нь нэг контейнер ажиллуулдаг. Istio чиглүүлэлтийн дүрмийг ашиглаагүй тохиолдолд Kubernetes нь анхдагч байдлаар жигд тэнцвэртэй дугуй чиглүүлэлт хийдэг:
Сүйрэлд бэлдэж байна
Pool Ejection хийхээсээ өмнө Istio чиглүүлэлтийн дүрмийг бий болгох хэрэгтэй. Бид хүсэлтийг 50/50 харьцаагаар pods хооронд хуваарилахыг хүсч байна гэж бодъё. Нэмж дурдахад бид v2 савны тоог нэгээс хоёр болгон нэмэгдүүлэх болно, жишээ нь:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Одоо бид трафикийг 50/50 харьцаагаар pods хооронд хуваарилахын тулд чиглүүлэлтийн дүрмийг тогтоосон.
Энэ дүрмийн үр дүн дараах байдалтай байна.
Энэ дэлгэц нь 50/50 биш, 14:9 гэсэн алдааг олж харж болно, гэхдээ цаг хугацаа өнгөрөх тусам байдал сайжирна.
Алдаа гаргаж байна
Одоо хоёр v2 контейнерийн аль нэгийг идэвхгүй болгоцгооё, ингэснээр бидэнд нэг эрүүл v1 контейнер, нэг эрүүл v2 контейнер, нэг алдаатай v2 сав байх болно.
Алдааг засах
Тиймээс, бид алдаатай савтай тул Pool Ejection хийх цаг болжээ. Маш энгийн тохиргоог ашигласнаар бид энэ бүтэлгүйтсэн контейнерийг эрүүл төлөвтөө буцна (дахин эхлүүлэх эсвэл гүйцэтгэлийг сэргээх) гэж найдаж 15 секундын турш ямар ч чиглүүлэлтийн схемээс хасах болно. Энэ тохиргоо болон ажлын үр дүн нь дараах байдалтай байна.
Таны харж байгаагаар бүтэлгүйтсэн v2 контейнер нь сангаас хасагдсан тул чиглүүлэлтийн хүсэлтэд ашиглахаа больсон. Гэхдээ 15 секундын дараа автоматаар усан сан руу буцах болно. Үнэндээ бид зүгээр л Pool Ejection хэрхэн ажилладагийг харуулсан.
Архитектур барьж эхэлцгээе
Pool Ejection нь Istio-ийн хяналтын чадавхитай хослуулан зогсолт, доголдлыг арилгахгүй бол багасгахын тулд алдаатай савыг автоматаар солих тогтолцоог бий болгож эхлэх боломжийг танд олгоно.
НАСА-д нэг чанга уриа бий - Бүтэлгүйтэл бол сонголт биш бөгөөд зохиогч нь нислэгийн захирал гэж тооцогддог. . Үүнийг орос хэлээр “Бүтэлгүйтэл бол сонголт биш” гэж орчуулж болох бөгөөд энд байгаа утга нь хэрэв та хангалттай хүсэл эрмэлзэлтэй бол бүх зүйлийг ажил хэрэг болгож чадна гэсэн үг юм. Гэсэн хэдий ч бодит амьдрал дээр бүтэлгүйтэл нь зүгээр л тохиолддоггүй, хаа сайгүй, бүх зүйлд зайлшгүй тохиолддог. Микросервисийн хувьд тэдэнтэй хэрхэн харьцах вэ? Бидний бодлоор хүсэл зоригт биш, харин савны чадварт найдах нь дээр. , болон .
Istio, дээр дурдсанчлан, физик ертөнцөд өөрийгөө сайнаар нотолсон хэлхээний таслагчийн үзэл баримтлалыг хэрэгжүүлдэг. Цахилгаан таслуур нь хэлхээний асуудалтай хэсгийг унтраадагтай адил Istio програм хангамжийн Circuit Breaker нь эцсийн цэгт ямар нэг зүйл буруу байх үед, жишээлбэл, сервер гацсан эсвэл ажиллаж эхлэх үед хүсэлтийн урсгал болон асуудлын контейнер хоорондын холболтыг нээдэг. удаашруулах.
Түүнээс гадна, хоёр дахь тохиолдолд зөвхөн илүү олон асуудал гардаг, учир нь нэг чингэлэгийн тоормос нь түүнд нэвтрэх үйлчилгээнд саатал үүсгэж, улмаар системийн гүйцэтгэлийг бүхэлд нь бууруулж, дахин дахин үүсгэдэг. аль хэдийн удаан ажиллаж байгаа үйлчилгээнд хүсэлт гаргах нь зөвхөн нөхцөл байдлыг улам хүндрүүлдэг.
Онолын хувьд хэлхээ таслагч
Circuit Breaker нь эцсийн цэг рүү ирэх хүсэлтийн урсгалыг хянадаг прокси юм. Энэ цэг ажиллахаа болих эсвэл заасан тохиргооноос хамааран удааширч эхлэхэд прокси нь контейнертэй холболтыг тасалдаг. Дараа нь ачааллыг тэнцвэржүүлснээр замын хөдөлгөөнийг бусад чингэлэг рүү шилжүүлдэг. Холболт нь өгөгдсөн унтах цонхонд нээлттэй хэвээр байна, жишээ нь хоёр минут, дараа нь хагас нээлттэй гэж үзнэ. Дараагийн хүсэлтийг илгээх оролдлого нь холболтын цаашдын төлөвийг тодорхойлдог. Хэрэв үйлчилгээнд бүх зүйл хэвийн байвал холболт ажиллах нөхцөл рүү буцаж, дахин хаагдана. Хэрэв үйлчилгээнд ямар нэг алдаа гарсаар байвал холболт тасарч, унтах цонхыг дахин идэвхжүүлнэ. Хялбаршуулсан хэлхээ таслагчийн төлөвийн диаграмм дараах байдалтай байна.
Энэ бүхэн системийн архитектурын түвшинд явагддаг гэдгийг энд тэмдэглэх нь зүйтэй. Тиймээс хэзээ нэгэн цагт та програмууддаа Circuit Breaker-тэй ажиллахыг заах хэрэгтэй болно, тухайлбал хариуд нь өгөгдмөл утгыг өгөх эсвэл боломжтой бол үйлчилгээ байгаа эсэхийг үл тоомсорлох болно. Үүний тулд хаалтны хэв маягийг ашигладаг боловч энэ нь энэ зүйлийн хамрах хүрээнээс гадуур юм.
Практикт хэлхээ таслагч
Жишээлбэл, бид OpenShift дээр санал болгож буй микро үйлчилгээний хоёр хувилбарыг ажиллуулах болно. 1-р хувилбар сайн ажиллах боловч v2-д бид сервер дээрх удаашралыг дуурайхын тулд саатал гаргах болно. Үр дүнг харахын тулд хэрэгслийг ашиглана уу :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Бүх зүйл үр дүнтэй мэт санагдаж байна, гэхдээ ямар үнээр? Эхлээд харахад бид 100% хүртээмжтэй байдаг, гэхдээ сайтар хараарай - гүйлгээний хамгийн дээд хугацаа нь 12 секунд байна. Энэ бол гацаа болж байгаа нь тодорхой бөгөөд үүнийг өргөжүүлэх шаардлагатай байна.
Үүнийг хийхийн тулд бид Istio-г ашиглан контейнеруудыг удаашруулах дуудлагыг арилгах болно. Circuit Breaker ашиглан харгалзах тохиргоо дараах байдалтай байна.
httpMaxRequestsPerConnection параметрийн сүүлчийн мөр нь одоо байгаа холболтоос гадна өөр хоёр дахь холболт үүсгэхийг оролдох үед холболтыг салгах ёстойг дохио өгдөг. Манай контейнер удаан үйлчилгээг дуурайдаг тул ийм нөхцөл байдал үе үе гарч ирэх бөгөөд дараа нь Istio 503 алдааг буцаана, гэхдээ бүслэлт үүнийг харуулах болно:
За, бидэнд Circuit Breaker байна, дараа нь яах вэ?
Тиймээс бид үйлчилгээний эх кодыг огт хөндөхгүйгээр автомат унтраалтыг хэрэгжүүлсэн. Дээр дурдсан Circuit Breaker болон Pool Ejection процедурыг ашигласнаар бид тоормосны савыг хэвийн байдалдаа орох хүртэл нөөцийн сангаас салгаж, төлөвийг нь тогтоосон давтамжтайгаар шалгаж болно - бидний жишээнд энэ нь хоёр минут (sleepWindow параметр).
Програмын 503 алдаанд хариу өгөх чадварыг эх кодын түвшинд тохируулсан хэвээр байгааг анхаарна уу. Нөхцөл байдлаас шалтгаалан Circuit Breaker ашиглах олон стратеги байдаг.
Дараагийн бичлэгт: Бид Istio-д аль хэдийн суулгасан эсвэл амархан нэмсэн мөшгих, хянах, түүнчлэн системд алдааг хэрхэн зориудаар нэвтрүүлэх талаар авч үзэх болно.
Эх сурвалж: www.habr.com