Сайн уу? Намайг Вадим Мэдисон гэдэг, би Avito системийн платформыг хөгжүүлдэг. Компанийн хувьд бид цул архитектураас микро үйлчилгээ рүү хэрхэн шилжиж байгаа талаар нэг бус удаа хэлж байсан. Бичил үйлчилгээнээс хамгийн их ашиг хүртэх, тэдгээрт төөрөхөөс урьдчилан сэргийлэхийн тулд бид дэд бүтцээ хэрхэн өөрчилснөө хуваалцах цаг болжээ. PaaS энд бидэнд хэрхэн тусалдаг вэ, бид байршуулалтыг хэрхэн хялбарчилж, нэг товшилтоор бичил үйлчилгээ үүсгэхийг багасгасан - цааш уншина уу. Миний доор бичсэн бүх зүйл Avito-д бүрэн хэрэгждэггүй, зарим нь бидний платформыг хэрхэн хөгжүүлдэг.

(Энэ нийтлэлийн төгсгөлд би микро үйлчилгээний архитектурын шинжээч Крис Ричардсоны гурван өдрийн семинарт оролцох боломжийн талаар ярих болно).

Бид хэрхэн бичил үйлчилгээнд ирсэн бэ?

Avito бол дэлхийн хамгийн том нууцлагдсан сайтуудын нэг бөгөөд өдөрт 15 сая гаруй шинэ зар сурталчилгаа нийтлэгддэг. Манай backend нь секундэд 20 мянга гаруй хүсэлтийг хүлээн авдаг. Бид одоогоор хэдэн зуун микро үйлчилгээтэй.

Бид хэдэн жилийн турш бичил үйлчилгээний архитектурыг барьж байна. Яг яаж - манай хамт олон дэлгэрэнгүй хэлсэн Манай RIT++ 2017 хэсэгт. CodeFest 2017 дээр (харна уу. видео), Сергей Орлов, Михаил Прокопчук нар яагаад бичил үйлчилгээнд шилжих шаардлагатай болсон, Кубернетес энд ямар үүрэг гүйцэтгэсэн талаар дэлгэрэнгүй тайлбарлав. За, одоо бид ийм архитектурт хамаарах зардлыг багасгахын тулд бүх зүйлийг хийж байна.

Эхэндээ бид микро үйлчилгээг хөгжүүлэх, эхлүүлэхэд иж бүрэн туслах экосистемийг бүтээгээгүй. Тэд зүгээр л ухаалаг нээлттэй эхийн шийдлүүдийг цуглуулж, гэртээ ажиллуулж, хөгжүүлэгчийг тэдэнтэй ажиллахыг урьсан. Үүний үр дүнд тэрээр хэдэн арван газар (хяналтын самбар, дотоод үйлчилгээ) явсан бөгөөд үүний дараа тэрээр кодыг хуучин аргаар, нэг цул болгон хайчлах хүсэлдээ улам хүчтэй болсон. Доорх диаграмм дахь ногоон өнгө нь хөгжүүлэгч өөрийн гараар ямар нэг байдлаар юу хийж байгааг, шар өнгө нь автоматжуулалтыг илтгэнэ.

Одоо PaaS CLI хэрэглүүрт нэг тушаалаар шинэ үйлчилгээ үүсгэгдэж, шинэ мэдээллийн баазыг хоёр тушаалаар нэмж, Stage-д байршуулсан.

"Бичил үйлчилгээний хуваагдал"-ын эрин үеийг хэрхэн даван туулах вэ

Цул архитектурын тусламжтайгаар бүтээгдхүүн дэх өөрчлөлтийг тууштай байлгахын тулд хөгжүүлэгчид хөршүүдтэйгээ юу болж байгааг олж мэдэхээс өөр аргагүй болсон. Шинэ архитектур дээр ажиллах үед үйлчилгээний нөхцөлүүд бие биенээсээ хамааралгүй болсон.

Нэмж дурдахад микро үйлчилгээний архитектурыг үр дүнтэй болгохын тулд олон процессыг бий болгох шаардлагатай, тухайлбал:

• мод бэлтгэх;
• хүсэлтийг мөрдөх (Jaeger);
• алдааг нэгтгэх (Sentry);
• Kubernetes-ийн төлөв, мессеж, үйл явдлууд (Event Stream Processing);
• уралдааны хязгаар / таслуур (та Hystrix ашиглаж болно);
• үйлчилгээний холболтыг хянах (бид Netramesh ашигладаг);
• мониторинг (Графана);
• угсралт (TeamCity);
• харилцаа холбоо, мэдэгдэл (Slack, имэйл);
• ажлыг хянах; (Жира)
• бичиг баримт бүрдүүлэх.

Систем бүрэн бүтэн байдлаа алдахгүй, цар хүрээгээ тэлэх тусам үр дүнтэй хэвээр байхын тулд бид Avito дахь бичил үйлчилгээний зохион байгуулалтын талаар дахин бодож үзсэн.

Бид бичил үйлчилгээг хэрхэн удирддаг

Авитогийн олон бичил үйлчилгээнүүдийн дунд нэгдсэн "нам бодлого" хэрэгжүүлэхэд дараах зүйлс тусална.

• дэд бүтцийг давхаргад хуваах;
• Үйлчилгээний платформ (PaaS) үзэл баримтлал;
• бичил үйлчилгээтэй холбоотой бүх зүйлийг хянах.

Дэд бүтцийн хийсвэр давхарга нь гурван давхаргыг агуулдаг. Дээрээс доошоо явцгаая.

A. Топ - үйлчилгээний тор. Эхлээд бид Istio-г туршиж үзсэн боловч энэ нь хэтэрхий их нөөц ашигладаг нь бидний эзлэхүүнд хэтэрхий үнэтэй байдаг. Тиймээс архитектурын багийн ахлах инженер Александр Лукьянченко өөрийн шийдлийг боловсруулсан - Нетрамеш (Нээлттэй эх сурвалж дээр байдаг), бидний одоогоор үйлдвэрлэлд ашиглаж байгаа бөгөөд Istio-ээс хэд дахин бага нөөц зарцуулдаг (гэхдээ Istio-ийн сайрхаж чадах бүх зүйлийг хийдэггүй).
B. Дунд зэргийн - Кубернетес. Бид үүн дээр микро үйлчилгээг байрлуулж, ажиллуулдаг.
C. Доод талд - нүцгэн металл. Бид үүл эсвэл OpenStack гэх мэт зүйлсийг ашигладаггүй, харин нүцгэн металл дээр тулгуурладаг.

Бүх давхаргыг PaaS-ээр нэгтгэдэг. Мөн энэ платформ нь эргээд гурван хэсгээс бүрдэнэ.

I. Генераторууд, CLI хэрэгслээр удирддаг. Тэр бол хөгжүүлэгчийг зөв аргаар, хамгийн бага хүчин чармайлтаар бичил үйлчилгээг бий болгоход тусалдаг.

II. Нэгдсэн цуглуулагч нийтлэг хяналтын самбараар дамжуулан бүх хэрэгслийг удирдах боломжтой.

III. Хадгалах. Чухал ач холбогдол бүхий үйлдлүүдийн триггерийг автоматаар тохируулдаг хуваарьлагчтай холбогдоно. Ийм системийн ачаар хэн нэгэн Jira-д даалгавраа тавихаа мартсанаас болж нэг ч ажил алга болдоггүй. Үүний тулд бид Атлас хэмээх дотоод хэрэгслийг ашигладаг.

Avito дахь бичил үйлчилгээг хэрэгжүүлэх нь нэг схемийн дагуу хийгддэг бөгөөд энэ нь хөгжүүлэлт, хувилбарын үе шат бүрт хяналтыг хялбаршуулдаг.

Стандарт бичил үйлчилгээ хөгжүүлэх дамжуулах хоолой хэрхэн ажилладаг вэ?

Ерөнхийдөө бичил үйлчилгээ үүсгэх гинж нь дараах байдалтай байна.

CLI-түлхэх → Тасралтгүй интеграци → Жигнэмэг → Байршуулах → Хиймэл туршилт → Канарын туршилт → Шахах туршилт → Үйлдвэрлэл → Засвар үйлчилгээ.

Үүнийг яг энэ дарааллаар авч үзье.

CLI-түлхэх

• Бичил үйлчилгээ бий болгох.
Бид хөгжүүлэгчид бүрт бичил үйлчилгээ хийхийг заах гэж удаан хугацаанд тэмцсэн. Үүнд Confluence-д нарийвчилсан зааврыг бичсэн байсан. Гэхдээ схемүүд өөрчлөгдөж, нэмэлтээр нэмэгдэв. Үүний үр дүнд аялалын эхэнд гацаа гарч ирэв: микро үйлчилгээг эхлүүлэхэд илүү их цаг зарцуулсан бөгөөд тэдгээрийг бүтээх явцад асуудал байнга гардаг.

Эцэст нь бид бичил үйлчилгээ үүсгэх үндсэн алхмуудыг автоматжуулдаг энгийн CLI хэрэгслийг бүтээсэн. Үнэн хэрэгтээ энэ нь эхний git түлхэлтийг орлуулдаг. Түүний яг юу хийдэг талаар эндээс үзнэ үү.

- Загварын дагуу үйлчилгээг "шидтэн" горимд алхам алхмаар бий болгодог. Бид Avito арын хэсэгт програмчлалын үндсэн хэлнүүдийн загвартай: PHP, Golang, Python.

- Нэг тушаалаар орон нутгийн хөгжлийн орчинг тодорхой машин дээр байрлуулдаг - Minikube-г эхлүүлж, Helm диаграммуудыг автоматаар үүсгэж, орон нутгийн kubernetes-д ажиллуулдаг.

— Шаардлагатай мэдээллийн санг холбодог. Хөгжүүлэгч нь шаардлагатай мэдээллийн санд хандахын тулд IP, нэвтрэх нэр, нууц үгээ мэдэх шаардлагагүй - энэ нь орон нутгийн, Тайзны, эсвэл үйлдвэрлэлийн аль нь ч бай. Түүнчлэн, мэдээллийн баазыг нэн даруй алдааг тэсвэрлэх тохиргоотой, тэнцвэржүүлсэн байдлаар байрлуулдаг.

— Энэ нь өөрөө шууд угсралтыг гүйцэтгэдэг. Хөгжүүлэгч өөрийн IDE-ээр дамжуулан бичил үйлчилгээнд ямар нэг зүйлийг зассан гэж бодъё. Уг хэрэгсэл нь файлын системд гарсан өөрчлөлтийг харж, тэдгээрт үндэслэн програмыг (Голанг-д) дахин бүтээж, дахин эхлүүлнэ. PHP-ийн хувьд бид зүгээр л шоо доторх лавлахыг дамжуулж, шууд дахин ачааллыг "автоматаар" авдаг.

- Автомат тестийг үүсгэдэг. Хоосон хэлбэрээр, гэхдээ хэрэглэхэд нэлээд тохиромжтой.

• Бичил үйлчилгээний байршуулалт.

Бичил үйлчилгээ нэвтрүүлэх нь бидний хувьд бага зэрэг ажил байсан. Дараах шаардлагатай байсан.

I. Докер файл.

II. Тохиргоо.
III. Дугуйны диаграм нь өөрөө төвөгтэй бөгөөд дараахь зүйлийг агуулна.

- графикууд өөрсдөө;
- загварууд;
- өөр өөр орчныг харгалзан тодорхой утгууд.

Бид Kubernetes манифестуудыг дахин боловсруулахад зовлон зүдгүүрийг арилгасан тул автоматаар үүсгэгдсэн. Гэхдээ хамгийн чухал нь тэд байршуулалтыг хязгаар хүртэл хялбаршуулсан. Одооноос эхлэн бидэнд Dockerfile байгаа бөгөөд хөгжүүлэгч бүх тохиргоог нэг богино app.toml файлд бичдэг.

Тийм ээ, мөн app.toml-д нэг минутын турш хийх зүйл алга. Бид үйлчилгээний хаана, хэдэн хувийг (хөгжүүлэгчийн сервер дээр, үе шатанд, үйлдвэрлэлд) гаргахыг тодорхойлж, түүний хамаарлыг зааж өгдөг. [хөдөлгүүр] блок дахь шугамын хэмжээ = "жижиг" гэдгийг анхаарна уу. Энэ бол Kubernetes-ээр дамжуулан үйлчилгээнд хуваарилагдах хязгаар юм.

Дараа нь тохиргоонд үндэслэн шаардлагатай бүх Helm диаграммууд автоматаар үүсгэгдэж, мэдээллийн сантай холболтууд үүсдэг.

• Үндсэн баталгаажуулалт. Ийм шалгалтыг мөн автоматжуулсан байдаг.
Хянах шаардлагатай:
- Dockerfile байгаа эсэх;
- app.toml байна уу;
- Баримт бичиг байгаа юу?
- хараат байдал эмх цэгцтэй байна уу?
- дохиоллын дүрмийг тогтоосон эсэх.
Сүүлийн цэг хүртэл: үйлчилгээний эзэн өөрөө ямар бүтээгдэхүүний хэмжүүрийг хянахаа тодорхойлдог.

• Баримт бичгийг бэлтгэх.
Асуудалтай бүс хэвээр байна. Энэ нь хамгийн ойлгомжтой мэт боловч "ихэнхдээ мартагддаг" дээд амжилт бөгөөд гинжин хэлхээний эмзэг холбоос юм.
Микро үйлчилгээ бүрийн хувьд баримт бичиг байх шаардлагатай. Үүнд дараах блокууд орно.

I. Үйлчилгээний товч тодорхойлолт. Энэ нь юу хийдэг, яагаад хэрэгтэй вэ гэсэн цөөн хэдэн өгүүлбэр.

II. Архитектурын диаграмын холбоос. Үүнийг хурдан харвал жишээлбэл, Redis-ийг кэш хийх эсвэл байнгын горимд үндсэн мэдээллийн сан болгон ашиглаж байгаа эсэхийг ойлгоход хялбар байх нь чухал юм. Avito-д одоогоор энэ нь Confluence-ийн холбоос юм.

III. Runbook. Үйлчилгээг эхлүүлэх товч заавар, түүнийг зохицуулах нарийн ширийн зүйлс.

IV. Түгээмэл асуултуудҮйлчилгээтэй ажиллахад хамтран ажиллагсад тань тулгарч болзошгүй асуудлуудыг урьдчилан таамаглах нь зүйтэй.

V. API-ийн төгсгөлийн цэгүүдийн тодорхойлолт. Хэрэв та гэнэт очих газраа зааж өгөөгүй бол микро үйлчилгээ нь таныхтай холбоотой хамтран ажиллагсад бараг л төлбөр төлөх болно. Одоо бид Swagger ашигладаг бөгөөд үүнд зориулж brief нэртэй бидний шийдлийг ашигладаг.

VI. Шошго. Эсвэл тухайн үйлчилгээ нь компанийн аль бүтээгдэхүүн, функциональ эсвэл бүтцийн хэлтэст харьяалагддаг болохыг харуулсан тэмдэглэгээ. Эдгээр нь жишээлбэл, долоо хоногийн өмнө хамт ажиллагсадынхаа нэг бизнесийн нэгжид зориулж гаргасан функцийг багасгаж байгаа эсэхийг хурдан ойлгоход тусална.

VII. Үйлчилгээний эзэмшигч эсвэл эзэмшигчид. Ихэнх тохиолдолд үүнийг эсвэл тэдгээрийг PaaS ашиглан автоматаар тодорхойлох боломжтой боловч аюулгүй байдлын үүднээс бид хөгжүүлэгчээс тэдгээрийг гараар зааж өгөхийг шаарддаг.

Эцэст нь, кодыг шалгахтай адил баримт бичгийг шалгах нь сайн туршлага юм.

Тогтмол интеграцчилал

• Хадгалах газар бэлдэж байна.
• TeamCity-д дамжуулах хоолой үүсгэж байна.
• Эрхийг тохируулах.
• Үйлчилгээний эздийг хайх. Энд эрлийз схем байдаг - гарын авлагын тэмдэглэгээ, PaaS-аас хамгийн бага автоматжуулалт. Үйлчилгээг өөр хөгжүүлэлтийн багт шилжүүлэх эсвэл жишээлбэл үйлчилгээ хөгжүүлэгч ажлаасаа гарсан тохиолдолд бүрэн автомат схем амжилтгүй болно.
• Атлас дахь үйлчилгээг бүртгэж байна (дээрээс үзнэ үү). Бүх эзэмшигчид болон хамааралтай хүмүүстэй.
• Шилжилт хөдөлгөөнийг шалгаж байна. Бид тэдгээрийн аль нэг нь аюултай байж болзошгүй эсэхийг шалгадаг. Жишээлбэл, тэдгээрийн аль нэгэнд нь өөрчлөх хүснэгт эсвэл үйлчилгээний өөр хувилбаруудын хооронд өгөгдлийн схемийн нийцтэй байдлыг эвдэж болох өөр зүйл гарч ирнэ. Дараа нь шилжүүлэг хийгдээгүй, харин захиалгад байрлуулсан - PaaS нь ашиглахад аюулгүй үед үйлчилгээний эзэнд дохио өгөх ёстой.

Жигнэх

Дараагийн шат бол байрлуулахаас өмнө савлах үйлчилгээ юм.

• Аппликейшн бүтээх. Сонгодогуудын дагуу - Докерын дүр төрхөөр.
• Үйлчилгээний өөрөө болон холбогдох нөөцийн хувьд Helm график үүсгэх. Мэдээллийн сан болон кэшийг багтаасан болно. Тэдгээрийг CLI-түлхэх шатанд үүсгэсэн app.toml тохиргооны дагуу автоматаар үүсгэнэ.
• Админуудад порт нээх тасалбар үүсгэх (шаардлагатай үед).
• Нэгжийн тестийг ажиллуулж, кодын хамрах хүрээг тооцоолох. Хэрэв кодын хамрах хүрээ нь заасан босго хэмжээнээс доогуур байвал үйлчилгээ цааш явахгүй байх магадлалтай - байршуулалт. Хэрэв энэ нь хүлээн зөвшөөрөгдөх хэмжээнд байгаа бол үйлчилгээнд "гутранги" коэффициентийг оноох болно: хэрэв цаг хугацааны явцад үзүүлэлт сайжрахгүй бол хөгжүүлэгчид туршилтын явцад ахиц дэвшил гараагүй гэсэн мэдэгдэл хүлээн авах болно ( мөн энэ талаар ямар нэг зүйл хийх хэрэгтэй).
• Санах ой болон CPU-ийн хязгаарлалтын бүртгэл. Бид голчлон Голанг хэл дээр бичил үйлчилгээ бичээд Kubernetes дээр ажиллуулдаг. Тиймээс Голанг хэлний өвөрмөц онцлогтой холбоотой нэг нарийн зүйл нь: анхдагч байдлаар, эхлүүлэх үед машин дээрх бүх цөмийг ашигладаг, хэрэв та GOMAXPROCS хувьсагчийг тодорхой заагаагүй бол ижил машин дээр хэд хэдэн ийм үйлчилгээг ажиллуулж эхлэхэд тэдгээр нь эхэлдэг. нөөцийн төлөө өрсөлдөх, бие биедээ саад учруулах. Доорх графикууд нь хэрэв та програмыг маргаангүй, нөөцийн горимд уралдуулж ажиллуулбал гүйцэтгэлийн хугацаа хэрхэн өөрчлөгдөхийг харуулж байна. (Графикийн эх сурвалжууд нь энд).

Гүйцэтгэх хугацаа бага байх нь дээр. Хамгийн их: 643ms, хамгийн бага: 42ms. Зургийг товших боломжтой.

Мэс засал хийх хугацаа бага байх нь дээр. Хамгийн их: 14091 ns, хамгийн бага: 151 ns. Зургийг товших боломжтой.

Угсралтын бэлтгэлийн үе шатанд та энэ хувьсагчийг тодорхой зааж өгөх эсвэл номын санг ашиглаж болно automaxprocs Uber-ийн залуусаас.

Байрлуулах

• Конвенцуудыг шалгах. Үйлчилгээний угсралтыг төлөвлөсөн орчинд хүргэж эхлэхээсээ өмнө та дараах зүйлсийг шалгах хэрэгтэй.
- API төгсгөлийн цэгүүд.
- API төгсгөлийн хариултуудын схемтэй нийцэж байгаа эсэх.
- Бүртгэлийн формат.
— Үйлчилгээний хүсэлтийн толгой хэсгийг тохируулах (одоогоор үүнийг netramesh хийж байна)
— Үйл явдлын автобус руу мессеж илгээх үед эзэмшигчийн токеныг тохируулах. Энэ нь автобусны хоорондох үйлчилгээний холболтыг хянахад шаардлагатай. Та үйлчилгээний холболтыг нэмэгдүүлэхгүй (энэ нь сайн) болон үйлчилгээний холболтыг бэхжүүлдэг бизнесийн өгөгдөл (энэ нь маш муу!) -ийг автобус руу илгээж болно. Энэхүү холболт нь асуудал болж хувирах үед автобусанд хэн бичиж, уншиж байгааг ойлгох нь үйлчилгээг зөв салгахад тусалдаг.

Авито хотод хараахан тийм ч олон конвенци байхгүй ч тэдний сан өргөжиж байна. Багийн ойлгож, ойлгохуйц хэлбэрээр ийм гэрээнүүд хэдий чинээ олон байна, төдий чинээ микро үйлчилгээний хоорондын уялдаа холбоог хадгалахад хялбар болно.

Синтетик туршилтууд

• Хаалттай цикл туршилт. Үүний тулд бид одоо нээлттэй эх сурвалжийг ашиглаж байна Hoverfly.io. Нэгдүгээрт, энэ нь үйлчилгээний бодит ачааллыг бүртгэдэг, дараа нь зөвхөн хаалттай циклээр үүнийг дуурайдаг.

• Стресс тест. Бид бүх үйлчилгээг оновчтой гүйцэтгэлд хүргэхийг хичээдэг. Үйлчилгээ бүрийн бүх хувилбарууд ачааллын туршилтанд хамрагдах ёстой - ингэснээр бид үйлчилгээний одоогийн гүйцэтгэл болон ижил үйлчилгээний өмнөх хувилбаруудын ялгааг ойлгох болно. Хэрэв үйлчилгээний шинэчлэлт хийсний дараа түүний гүйцэтгэл нэг ба хагас дахин буурсан бол энэ нь эзэмшигчдэд зориулсан тодорхой дохио юм: та кодыг ухаж, нөхцөл байдлыг засах хэрэгтэй.
Жишээлбэл, бид цуглуулсан өгөгдлийг автомат масштабыг зөв хэрэгжүүлэхэд ашигладаг бөгөөд эцэст нь уг үйлчилгээг хэр зэрэг өргөжүүлэх боломжтойг ерөнхийд нь ойлгодог.

Ачааллын туршилтын явцад бид нөөцийн хэрэглээ тогтоосон хязгаарт нийцэж байгаа эсэхийг шалгадаг. Мөн бид юуны түрүүнд хэт туйлшралд анхаарлаа хандуулдаг.

a) Бид нийт ачааллыг хардаг.
- Хэт жижиг - ачаалал гэнэт хэд хэдэн удаа унавал ямар нэг зүйл ажиллахгүй байх магадлалтай.
- Хэт том - оновчтой болгох шаардлагатай.

б) Бид RPS-ийн дагуу таслалтыг хардаг.
Энд бид одоогийн хувилбар болон өмнөх хувилбаруудын хоорондох ялгаа, нийт тоо хэмжээг харна. Жишээлбэл, хэрэв үйлчилгээ нь 100 rps гаргадаг бол энэ нь муу бичигдсэн эсвэл энэ нь түүний онцлог шинж чанар юм, гэхдээ ямар ч тохиолдолд энэ нь үйлчилгээг маш сайн харах шалтгаан болдог.
Хэрэв эсрэгээр, хэтэрхий олон RPS байгаа бол магадгүй ямар нэгэн алдаа гарч, зарим төгсгөлийн цэгүүд ачааллыг гүйцэтгэхээ больсон, нөгөө нь зүгээр л идэвхжсэн байж магадгүй юм. return true;

Канарын туршилтууд

Синтетик туршилтыг давсны дараа бид микро үйлчилгээг цөөн тооны хэрэглэгчдэд туршиж үздэг. Бид үйлчилгээний зорилтот үзэгчдийн багахан хувийг буюу 0,1% -иас бага хэмжээгээр анхааралтай эхэлдэг. Энэ үе шатанд техникийн болон бүтээгдэхүүний зөв хэмжигдэхүүнийг хяналтанд оруулах нь маш чухал бөгөөд ингэснээр үйлчилгээнд байгаа асуудлыг аль болох хурдан харуулах болно. Канарын тест хийх хамгийн бага хугацаа 5 минут, гол нь 2 цаг байна. Нарийн төвөгтэй үйлчилгээний хувьд бид цагийг гараар тохируулдаг.
Ингээд дүн шинжилгээ хийцгээе:
— хэлний тусгай хэмжүүр, ялангуяа php-fpm ажилчид;
- Sentry дахь алдаа;
- хариултын төлөв;
- хариу өгөх хугацаа, нарийн ба дундаж;
- хоцрогдол;
- үл хамаарах зүйл, боловсруулсан болон боловсруулаагүй;
- бүтээгдэхүүний хэмжүүр.

Шахах туршилт

Шахах тестийг мөн "шахах" тест гэж нэрлэдэг. Техникийн нэрийг Netflix-д нэвтрүүлсэн. Үүний мөн чанар нь бид эхлээд нэг инстанцыг бүтэлгүйтэх хүртэл бодит траффикээр дүүргэж, улмаар түүний хязгаарыг тогтоох явдал юм. Дараа нь бид өөр нэг жишээ нэмж, энэ хосыг дахин ачаална - дахин дээд тал нь; Бид эхний "шахалт" -аар тэдний тааз, гурвалжийг хардаг. Тиймээс бид нэг нэг жишээг холбож, өөрчлөлтийн загварыг тооцоолно.
Туршилтын өгөгдөл нь "шахах" замаар мөн нийтлэг хэмжүүрийн мэдээллийн сан руу урсдаг бөгөөд бид тэдгээрээр хиймэл ачааллын үр дүнг баяжуулж, эсвэл бүр "синтетик" -ийг сольж өгдөг.

Үйлдвэрлэл

• Томруулах. Бид үйлчилгээг үйлдвэрлэлд нэвтрүүлэхдээ түүний цар хүрээг хянадаг. Бидний туршлагаас харахад зөвхөн CPU-ийн үзүүлэлтүүдийг хянах нь үр дүнгүй юм. RPS харьцуулалт бүхий автомат масштаб нь цэвэр хэлбэрээр ажилладаг, гэхдээ зөвхөн онлайн дамжуулалт гэх мэт зарим үйлчилгээнд зориулагдсан. Тиймээс бид эхлээд хэрэглээний онцлогт тохирсон бүтээгдэхүүний хэмжүүрүүдийг авч үздэг.

Үүний үр дүнд масштаблахдаа бид дүн шинжилгээ хийдэг.
- CPU болон RAM үзүүлэлтүүд,
- дараалалд байгаа хүсэлтийн тоо,
- хариу цаг,
- хуримтлагдсан түүхэн мэдээлэлд үндэслэн урьдчилсан мэдээ.

Үйлчилгээг масштаблахдаа түүний хамаарлыг хянах нь чухал бөгөөд ингэснээр бид гинжин хэлхээний эхний үйлчилгээг масштаблахгүй байх ба түүний ханддаг үйлчилгээ ачаалалтай үед бүтэлгүйтдэг. Үйлчилгээний бүх санд хүлээн зөвшөөрөгдөх ачааллыг тогтоохын тулд бид "хамгийн ойрын" хамааралтай үйлчилгээний түүхэн өгөгдлийг (процессор болон RAM үзүүлэлтүүдийн хослол, програмын тусгай хэмжүүрүүд дээр үндэслэн) үзэж, тэдгээрийг түүхэн өгөгдөлтэй харьцуулдаг. эхлүүлэх үйлчилгээ гэх мэт "хамааралтай байдлын гинжин хэлхээ" "дээдээс доош хүртэл.

Үйлчилгээ

Микросервисийг ашиглалтад оруулсны дараа бид түүнд триггер хавсаргаж болно.

Өдөөгч хүчин зүйл тохиолддог ердийн нөхцөл байдал энд байна.
- Аюултай байж болзошгүй шилжилт хөдөлгөөн илэрсэн.
- Аюулгүй байдлын шинэчлэлтүүд гарсан.
— Үйлчилгээ өөрөө шинэчлэгдээгүй удаж байна.
— Үйлчилгээний ачаалал мэдэгдэхүйц буурсан эсвэл бүтээгдэхүүний зарим үзүүлэлт хэвийн хэмжээнээс гадуур байна.
— Үйлчилгээ нь шинэ платформын шаардлагыг хангахаа больсон.

Зарим өдөөгч нь үйл ажиллагааны тогтвортой байдлыг хариуцдаг бол зарим нь системийн засвар үйлчилгээний үүрэг гүйцэтгэдэг, жишээлбэл, зарим үйлчилгээ удаан хугацаанд ашиглагдаагүй, үндсэн дүр төрх нь аюулгүй байдлын шалгалтыг давахаа больсон.

Хяналтын самбар

Товчхондоо, хяналтын самбар нь бидний бүх PaaS-ийн хяналтын самбар юм.

• Туршилтын хамрах хүрээ, зургийн тоо, үйлдвэрлэлийн хуулбар, хувилбар гэх мэт үйлчилгээний талаархи мэдээллийн нэг цэг.
• Мэдээллийг үйлчилгээ, шошго (бизнесийн нэгжид хамаарах тэмдэглэгээ, бүтээгдэхүүний функц гэх мэт) шүүх хэрэгсэл.
• Мөшгих, бүртгэх, хянах дэд бүтцийн хэрэгслүүдтэй нэгтгэх хэрэгсэл.
• Үйлчилгээний нэг цэгийн баримт бичиг.
• Үйлчилгээний бүх үйл явдлын нэг цэгээс.

Нийт

PaaS-ийг нэвтрүүлэхээс өмнө шинэ хөгжүүлэгч бичил үйлчилгээг үйлдвэрлэлд нэвтрүүлэхэд шаардлагатай бүх хэрэгслүүдийг ойлгоход хэдэн долоо хоног зарцуулж болох юм: Kubernetes, Helm, манай TeamCity-ийн дотоод функцууд, мэдээллийн сан болон кэштэй холболтыг гэмтэлд тэсвэртэй байдлаар тохируулах гэх мэт. Хурдан эхлэлийг уншиж, үйлчилгээг өөрөө бий болгоход хэдэн цаг зарцуулдаг.

Би HighLoad++ 2018-д зориулж энэ сэдвээр илтгэл тавьсан, та үүнийг үзэх боломжтой видео и танилцуулга.

Дуустал уншсан хүмүүст зориулсан урамшууллын зам

Бид Avito компаниас хөгжүүлэгчдэд зориулсан дотоод гурван өдрийн сургалтыг зохион байгуулж байна Крис Ричардсон, бичил үйлчилгээний архитектурын мэргэжилтэн. Бид энэ нийтлэлийг уншигчдын нэгэнд оролцох боломжийг олгохыг хүсч байна. энд Сургалтын хөтөлбөрийг нийтэллээ.

Сургалт 5-р сарын 7-XNUMX-ны хооронд Москва хотод болно. Эдгээр нь бүрэн дүүрэн ажиллах ажлын өдрүүд юм. Өдрийн хоол, сургалт манай оффис дээр байх ба сонгогдсон оролцогч замын зардал, байрны зардлыг өөрөө хариуцна.

Та оролцох хүсэлтээ гаргаж болно энэ google хэлбэрээр. Танаас - яагаад сургалтанд хамрагдах ёстой вэ гэсэн асуултын хариулт, тантай хэрхэн холбогдох талаарх мэдээлэл. Сургалтанд хамрагдах оролцогчийг Крис өөрөө сонгох тул англиар хариулна уу.
Бид сургалтад оролцогчийн нэрийг энэ нийтлэлийн шинэчлэлт болон хөгжүүлэгчдэд зориулсан Avito нийгмийн сүлжээн дээр зарлах болно (AvitoTech in Фэйсбүүкт байна, Вконтакте, Твиттер) 19-р сарын XNUMX-ээс хэтрэхгүй.

Эх сурвалж: www.habr.com