Salom! Mening ismim Vadim Madison, men Avito tizimi platformasini ishlab chiqishga rahbarlik qilaman. Biz kompaniyada qanday qilib monolit arxitekturadan mikroservislarga o'tayotganimiz haqida bir necha bor aytilgan. Mikroservislardan maksimal darajada foydalanish va ularda adashib qolmaslik uchun infratuzilmamizni qanday o‘zgartirganimiz haqida baham ko‘rish vaqti keldi. Bu erda PaaS bizga qanday yordam beradi, qanday qilib biz joylashtirishni soddalashtirdik va mikroservis yaratishni bir marta bosish bilan qisqartirdik - o'qing. Quyida yozganlarimning hammasi Avito-da to'liq amalga oshirilmagan, ularning ba'zilari bizning platformamizni qanday rivojlantirishimizdir.

(Va ushbu maqolaning oxirida men mikroservis arxitekturasi bo'yicha mutaxassis Kris Richardsonning uch kunlik seminarida qatnashish imkoniyati haqida gapiraman).

Mikroservislarga qanday keldik

Avito dunyodagi eng katta tasniflangan saytlardan biri bo'lib, unda kuniga 15 milliondan ortiq yangi reklamalar chop etiladi. Bizning serverimiz soniyada 20 mingdan ortiq so'rovlarni qabul qiladi. Hozirda bizda bir necha yuz mikroservislar mavjud.

Biz bir necha yillardan beri mikroservis arxitekturasini qurmoqdamiz. Qanday qilib aniq - bizning hamkasblarimiz batafsil dedi RIT++ 2017 bo'limida. CodeFest 2017 da (qarang. видео), Sergey Orlov va Mixail Prokopchuk nima uchun mikroservislarga o'tish kerakligini va Kubernetes bu erda qanday rol o'ynaganini batafsil tushuntirib berdi. Xo'sh, endi biz bunday arxitekturaga xos bo'lgan masshtablash xarajatlarini minimallashtirish uchun hamma narsani qilyapmiz.

Dastlab biz mikroservislarni ishlab chiqish va ishga tushirishda har tomonlama yordam beradigan ekotizim yaratmadik. Ular shunchaki ochiq manbali oqilona echimlarni to'plashdi, ularni uyda ishga tushirishdi va ishlab chiquvchini ular bilan shug'ullanishga taklif qilishdi. Natijada, u o'nlab joylarga (boshqaruv paneli, ichki xizmatlar) bordi, shundan so'ng u eski usulda, monolitda kodni kesish istagida kuchliroq bo'ldi. Quyidagi diagrammalardagi yashil rang ishlab chiquvchining o'z qo'llari bilan u yoki bu tarzda nima qilishini, sariq rang esa avtomatlashtirishni ko'rsatadi.

Endi PaaS CLI yordam dasturida bitta buyruq bilan yangi xizmat yaratiladi va yana ikkitasi bilan yangi ma'lumotlar bazasi qo'shiladi va Stage-ga joylashtiriladi.

"Mikroservisning parchalanishi" davrini qanday engish mumkin

Monolit arxitektura bilan mahsulotdagi o'zgarishlarning izchilligi uchun ishlab chiquvchilar qo'shnilari bilan nima sodir bo'layotganini aniqlashga majbur bo'lishdi. Yangi arxitektura ustida ishlayotganda, xizmat kontekstlari endi bir-biriga bog'liq emas.

Bundan tashqari, mikroservis arxitekturasi samarali bo'lishi uchun ko'plab jarayonlarni o'rnatish kerak, xususan:

• loglarni yozish;
• so'rovni kuzatish (Jaeger);
• xatolarni yig'ish (Sentry);
• Kubernetes dan statuslar, xabarlar, voqealar (Voqealar oqimini qayta ishlash);
• poyga chegarasi / o'chirgich (siz Hystrixdan foydalanishingiz mumkin);
• xizmat ulanishini nazorat qilish (biz Netramesh-dan foydalanamiz);
• monitoring (Grafana);
• montaj (TeamCity);
• aloqa va xabar berish (Slack, email);
• vazifalarni kuzatish; (Jira)
• hujjatlarni tayyorlash.

Tizim o'zining yaxlitligini yo'qotmasligi va kengaygan sari samarali bo'lib qolishi uchun biz Avito'da mikroservislarni tashkil qilishni qayta ko'rib chiqdik.

Mikroservislarni qanday boshqaramiz

Ko'pgina Avito mikroservislari orasida yagona "partiya siyosatini" amalga oshirishga quyidagi yordam beradi:

• infratuzilmani qatlamlarga bo'lish;
• Platforma xizmat sifatida (PaaS) tushunchasi;
• mikroservislar bilan sodir bo'ladigan hamma narsani kuzatish.

Infratuzilmani abstraktsiya qatlamlari uchta qatlamni o'z ichiga oladi. Keling, yuqoridan pastgacha boraylik.

A. Yuqori - xizmat ko'rsatish to'ri. Avvaliga biz Istio-ni sinab ko'rdik, ammo u juda ko'p resurslardan foydalangani ma'lum bo'ldi, bu bizning hajmlarimiz uchun juda qimmat. Shuning uchun, arxitektura guruhining katta muhandisi Aleksandr Lukyanchenko o'z yechimini ishlab chiqdi - Netramesh (Ochiq manbada mavjud), biz hozirda ishlab chiqarishda foydalanamiz va Istio'dan bir necha baravar kam resurslarni iste'mol qiladi (lekin Istio maqtana oladigan hamma narsani qilmaydi).
B. O'rta - Kubernetes. Biz unga mikroservislarni joylashtiramiz va boshqaramiz.
C. Pastki qismi - yalang'och metall. Biz bulutlarni yoki OpenStack kabi narsalarni ishlatmaymiz, lekin butunlay yalang'och metallga tayanamiz.

Barcha qatlamlar PaaS tomonidan birlashtirilgan. Va bu platforma, o'z navbatida, uch qismdan iborat.

I. Generatorlar, CLI yordam dasturi orqali boshqariladi. Aynan u ishlab chiquvchiga mikroservisni to'g'ri va minimal kuch bilan yaratishga yordam beradi.

II. Konsolidatsiyalangan kollektor umumiy asboblar paneli orqali barcha asboblarni boshqarish bilan.

III. Saqlash. Muhim harakatlar uchun triggerlarni avtomatik o'rnatadigan rejalashtiruvchilar bilan bog'lanadi. Bunday tizim tufayli, kimdir Jirada vazifa o'rnatishni unutganligi sababli biron bir vazifa o'tkazib yuborilmaydi. Buning uchun biz Atlas deb nomlangan ichki vositadan foydalanamiz.

Avito-da mikroservislarni amalga oshirish, shuningdek, ishlab chiqish va chiqarishning har bir bosqichida ular ustidan nazoratni soddalashtiradigan yagona sxema bo'yicha amalga oshiriladi.

Standart mikroservisni ishlab chiqish quvuri qanday ishlaydi?

Umuman olganda, mikroservis yaratish zanjiri quyidagicha ko'rinadi:

CLI-push → Uzluksiz integratsiya → Pishirish → Joylashtirish → Sunʼiy testlar → Kanareyka testlari → Siqish testi → Ishlab chiqarish → Xizmat.

Keling, buni aynan shu tartibda ko'rib chiqaylik.

CLI-bosish

• Mikroservis yaratish.
Biz har bir dasturchiga mikroservislarni qanday qilishni o'rgatish uchun uzoq vaqt kurashdik. Bunga Confluence-da batafsil ko'rsatmalar yozish kiradi. Ammo sxemalar o'zgardi va to'ldirildi. Natijada, sayohatning boshida muammo paydo bo'ldi: mikroservislarni ishga tushirish uchun ko'proq vaqt kerak bo'ldi va ularni yaratishda muammolar ko'pincha paydo bo'ldi.

Oxir-oqibat, biz mikroservis yaratishda asosiy qadamlarni avtomatlashtiradigan oddiy CLI yordam dasturini yaratdik. Aslida, u birinchi git push o'rnini bosadi. Mana u aynan nima qiladi.

— Xizmatni shablonga muvofiq yaratadi — bosqichma-bosqich, “sehrgar” rejimida. Bizda Avito backendidagi asosiy dasturlash tillari uchun shablonlarimiz bor: PHP, Golang va Python.

- Bir vaqtning o'zida bitta buyruq ma'lum bir mashinada mahalliy rivojlanish uchun muhitni o'rnatadi - Minikube ishga tushiriladi, Helm diagrammalari avtomatik ravishda yaratiladi va mahalliy kubernetlarda ishga tushiriladi.

— Kerakli maʼlumotlar bazasini ulaydi. Ishlab chiquvchiga kerak bo'lgan ma'lumotlar bazasiga kirish uchun IP, login va parolni bilish shart emas - u mahalliy, Stage yoki ishlab chiqarishda. Bundan tashqari, ma'lumotlar bazasi darhol xatoga chidamli konfiguratsiyada va balanslash bilan joylashtiriladi.

— U jonli yig‘ishni o‘zi bajaradi. Aytaylik, ishlab chiquvchi IDE orqali mikroservisda biror narsani tuzatdi. Yordamchi dastur fayl tizimidagi o'zgarishlarni ko'radi va ular asosida dasturni qayta tiklaydi (Golang uchun) va qayta ishga tushiriladi. PHP uchun biz shunchaki kub ichidagi katalogni yo'naltiramiz va u erda "avtomatik" jonli qayta yuklash olinadi.

— Avtotestlarni yaratadi. Blankalar shaklida, lekin foydalanish uchun juda mos keladi.

• Mikroservisni joylashtirish.

Ilgari mikroservisni o'rnatish biz uchun biroz mashaqqatli edi. Quyidagilar talab qilingan:

I. Docker fayli.

II. Konfiguratsiya.
III. Rulda diagrammasi, o'zi noqulay va quyidagilarni o'z ichiga oladi:

- diagrammalarning o'zi;
- shablonlar;
- turli muhitlarni hisobga olgan holda o'ziga xos qiymatlar.

Biz Kubernetes manifestlarini qayta ishlashdan xalos bo'ldik, shuning uchun ular endi avtomatik tarzda yaratiladi. Lekin eng muhimi, ular chegaragacha joylashtirishni soddalashtirdilar. Bundan buyon bizda Dockerfile bor va ishlab chiquvchi butun konfiguratsiyani bitta qisqa app.toml faylida yozadi.

Ha, va app.toml-ning o'zida bir daqiqaga hech narsa qilish mumkin emas. Biz xizmatning qayerda va qancha nusxasini ko'paytirishni belgilaymiz (ishlab chiqaruvchi serverda, sahnalashda, ishlab chiqarishda) va uning bog'liqligini ko'rsatamiz. [dvigatel] blokidagi chiziq o'lchamiga = "kichik" e'tibor bering. Bu Kubernetes orqali xizmatga ajratiladigan chegara.

Keyin, konfiguratsiya asosida barcha kerakli Helm diagrammalari avtomatik ravishda yaratiladi va ma'lumotlar bazalariga ulanishlar yaratiladi.

• Asosiy tekshirish. Bunday tekshiruvlar ham avtomatlashtirilgan.
Kuzatish kerak:
— Dockerfile bormi;
— app.toml bormi;
- hujjatlar mavjudmi?
— qaramlik joyidami?
- ogohlantirish qoidalari o'rnatilganmi.
Oxirgi nuqtaga: qaysi mahsulot ko'rsatkichlarini kuzatishni xizmat egasining o'zi belgilaydi.

• Hujjatlarni tayyorlash.
Hali ham muammoli maydon. Bu eng ravshan bo'lib tuyuladi, lekin ayni paytda bu "ko'pincha unutilgan" rekord va shuning uchun zanjirning zaif bo'g'inidir.
Har bir mikroservis uchun hujjatlar bo'lishi kerak. U quyidagi bloklarni o'z ichiga oladi.

I. Xizmatning qisqacha tavsifi. Bu nima va nima uchun kerakligi haqida bir nechta jumlalar.

II. Arxitektura diagrammasi havolasi. Muhimi, unga tez nazar tashlasangiz, masalan, siz Redis-dan keshlash uchun foydalanasizmi yoki doimiy rejimda asosiy ma'lumotlar ombori sifatida foydalanasizmi, tushunish oson. Avito-da hozircha bu Confluence-ga havola.

III. Runbook. Xizmatni ishga tushirish bo'yicha qisqacha qo'llanma va uni boshqarishning nozik tomonlari.

IV. TSS, bu erda xizmat bilan ishlashda hamkasblaringiz duch kelishi mumkin bo'lgan muammolarni oldindan bilish yaxshi bo'lar edi.

V. API uchun oxirgi nuqtalarning tavsifi. Agar siz to'satdan manzillarni aniqlamagan bo'lsangiz, mikroservislari siznikiga tegishli bo'lgan hamkasblar buning uchun deyarli to'laydi. Endi biz Swagger-dan foydalanamiz va buning uchun brief deb nomlangan yechimimiz.

VI. Yorliqlar. Yoki xizmat qaysi mahsulot, funksionallik yoki kompaniyaning tarkibiy bo'linmasiga tegishli ekanligini ko'rsatadigan markerlar. Ular, masalan, hamkasblaringiz bir hafta oldin xuddi shu biznes bo'limi uchun ishlab chiqargan funksiyalarni qisqartirayotganingizni tezda tushunishingizga yordam beradi.

VII. Xizmat egasi yoki egalari. Aksariyat hollarda u yoki ular PaaS yordamida avtomatik ravishda aniqlanishi mumkin, ammo xavfsiz tomonda bo'lish uchun biz ishlab chiquvchidan ularni qo'lda ko'rsatishni talab qilamiz.

Nihoyat, kodni ko'rib chiqishga o'xshash hujjatlarni ko'rib chiqish yaxshi amaliyotdir.

Har doim integratsiya

• Repozitariylarni tayyorlash.
• TeamCity-da quvur liniyasi yaratish.
• Huquqlarni sozlash.
• Xizmat egalarini qidiring. Bu erda gibrid sxema mavjud - qo'lda belgilash va PaaS-dan minimal avtomatlashtirish. Xizmatlar boshqa ishlab chiqish guruhiga qo'llab-quvvatlash uchun o'tkazilganda yoki, masalan, xizmatni ishlab chiqaruvchisi chiqib ketganda, to'liq avtomatik sxema ishlamay qoladi.
• Atlasda xizmatni ro'yxatdan o'tkazish (yuqoriga qarang). Barcha egalari va qaramliklari bilan.
• Migratsiyalarni tekshirish. Biz ulardan birortasi potentsial xavfli ekanligini tekshiramiz. Misol uchun, ulardan birida o'zgartirish jadvali yoki xizmatning turli versiyalari o'rtasida ma'lumotlar sxemasining mosligini buzishi mumkin bo'lgan boshqa narsa paydo bo'ladi. Keyin migratsiya amalga oshirilmaydi, lekin obunaga joylashtiriladi - PaaS undan foydalanish xavfsiz bo'lganda xizmat egasiga signal berishi kerak.

Pishiriq

Keyingi bosqich - joylashtirishdan oldin qadoqlash xizmatlari.

• Ilovani yaratish. Klassiklarga ko'ra - Docker tasvirida.
• Xizmatning o'zi va tegishli resurslar uchun Helm diagrammalarini yaratish. Shu jumladan ma'lumotlar bazalari va kesh uchun. Ular CLI-push bosqichida yaratilgan app.toml konfiguratsiyasiga muvofiq avtomatik ravishda yaratiladi.
• Administratorlar uchun portlarni ochish uchun chiptalar yaratish (kerak bo'lganda).
• Birlik testlarini o'tkazish va kod qamrovini hisoblash. Agar kodning qamrovi belgilangan chegaradan past bo'lsa, xizmat ko'rsatishni davom ettirmaydi - tarqatish. Agar u maqbul bo'lish arafasida bo'lsa, xizmatga "pessimizatsiya" koeffitsienti beriladi: agar vaqt o'tishi bilan ko'rsatkich yaxshilanmasa, ishlab chiquvchi testlar bo'yicha hech qanday taraqqiyot yo'qligi haqida xabar oladi ( va bu haqda biror narsa qilish kerak).
• Xotira va protsessor cheklovlarini hisobga olish. Biz asosan mikroservislarni Golangda yozamiz va ularni Kubernetesda ishga tushiramiz. Demak, Golang tilining o'ziga xos xususiyati bilan bog'liq bitta noziklik: sukut bo'yicha, ishga tushirishda, agar siz GOMAXPROCS o'zgaruvchisini aniq belgilamasangiz, mashinadagi barcha yadrolar ishlatiladi va bir xil mashinada bir nechta bunday xizmatlar ishga tushirilsa, ular boshlanadi. resurslar uchun raqobat qilish, bir-biriga aralashish. Quyidagi grafiklar, agar siz dasturni tortishuvlarsiz va resurslar uchun poygada ishlatsangiz, bajarish vaqti qanday o'zgarishini ko'rsatadi. (Grafiklar manbalari shu yerda).

Bajarish vaqti, kamroq bo'lsa, yaxshiroqdir. Maksimal: 643ms, minimal: 42ms. Suratni bosish mumkin.

Jarrohlik vaqti kamroq bo'lsa yaxshi bo'ladi. Maksimal: 14091 ns, minimal: 151 ns. Suratni bosish mumkin.

Yig'ishga tayyorgarlik bosqichida siz ushbu o'zgaruvchini aniq belgilashingiz yoki kutubxonadan foydalanishingiz mumkin automaxprocs Uber yigitlaridan.

Joylashtirish

• Konventsiyalarni tekshirish. Xizmat yig'malarini mo'ljallangan muhitingizga yetkazib berishni boshlashdan oldin quyidagilarni tekshirishingiz kerak:
- API so'nggi nuqtalari.
— API so‘nggi nuqtalari javoblarining sxemaga muvofiqligi.
— Jurnal formati.
— Xizmatga so'rovlar sarlavhalarini o'rnatish (hozirda bu netramesh tomonidan amalga oshiriladi)
— Voqealar avtobusiga xabar jo'natishda egasi tokenini o'rnatish. Bu avtobus bo'ylab xizmatlarning ulanishini kuzatish uchun kerak. Siz avtobusga idempotent ma'lumotlarni ham yuborishingiz mumkin, bu xizmatlarning ulanishini oshirmaydi (bu yaxshi), va xizmatlarning ulanishini kuchaytiradigan biznes ma'lumotlari (bu juda yomon!). Va bu ulanish muammoga aylanganda, avtobusni kim yozishi va o'qishini tushunish xizmatlarni to'g'ri ajratishga yordam beradi.

Avitoda hali juda ko'p konventsiyalar mavjud emas, lekin ularning hovuzi kengaymoqda. Jamoa tushunadigan va tushunadigan shaklda bunday kelishuvlar qanchalik ko'p bo'lsa, mikroservislar o'rtasidagi muvofiqlikni saqlash shunchalik oson bo'ladi.

Sintetik sinovlar

• Yopiq davr sinovi. Buning uchun biz hozir ochiq manbadan foydalanamiz Hoverfly.io. Birinchidan, u xizmatdagi haqiqiy yukni qayd qiladi, keyin esa - faqat yopiq tsiklda - uni taqlid qiladi.

• Stress testi. Biz barcha xizmatlarni optimal ishlashga keltirishga harakat qilamiz. Va har bir xizmatning barcha versiyalari yuk sinovidan o'tishi kerak - bu orqali biz xizmatning joriy ishlashi va bir xil xizmatning oldingi versiyalari bilan farqini tushunishimiz mumkin. Agar xizmat yangilanishidan so'ng uning ishlashi bir yarim baravar kamaygan bo'lsa, bu uning egalari uchun aniq signaldir: siz kodni o'rganishingiz va vaziyatni to'g'rilashingiz kerak.
Biz to'plangan ma'lumotlardan, masalan, avtomatik o'lchovni to'g'ri amalga oshirish uchun foydalanamiz va oxir-oqibat, xizmat qanchalik kengayishi mumkinligini tushunamiz.

Yukni sinovdan o'tkazishda biz resurslar iste'moli belgilangan chegaralarga mos kelishini tekshiramiz. Va biz birinchi navbatda ekstremallarga e'tibor qaratamiz.

a) Biz umumiy yukni ko'rib chiqamiz.
- Juda kichik - agar yuk birdaniga bir necha marta tushib qolsa, ehtimol biror narsa ishlamaydi.
- Juda katta - optimallashtirish talab qilinadi.

b) RPS bo'yicha kesishmaga qaraymiz.
Bu erda biz joriy versiya va oldingi versiya va umumiy miqdor o'rtasidagi farqni ko'rib chiqamiz. Misol uchun, agar xizmat 100 rps ishlab chiqaradigan bo'lsa, unda u yomon yozilgan yoki bu uning o'ziga xosligi, lekin har holda, bu xizmatni diqqat bilan ko'rib chiqish uchun sababdir.
Agar aksincha, RPS juda ko'p bo'lsa, unda qandaydir xatolik bor va ba'zi so'nggi nuqtalar foydali yukni bajarishni to'xtatgan, ammo boshqasi shunchaki ishga tushirilgan. return true;

Kanareyka testlari

Sintetik testlardan o'tganimizdan so'ng biz mikroservisni oz sonli foydalanuvchilarda sinab ko'ramiz. Biz ehtiyotkorlik bilan boshlaymiz, xizmatning mo'ljallangan auditoriyasining kichik ulushi - 0,1% dan kam. Ushbu bosqichda to'g'ri texnik va mahsulot ko'rsatkichlari monitoringga kiritilishi juda muhim, shunda ular xizmatdagi muammoni imkon qadar tezroq ko'rsatadi. Kanareyka testining minimal vaqti - 5 daqiqa, asosiysi - 2 soat. Murakkab xizmatlar uchun biz vaqtni qo'lda o'rnatamiz.
Keling, tahlil qilaylik:
— tilga xos ko'rsatkichlar, xususan, php-fpm ishchilari;
— Sentrydagi xatolar;
— javob holatlari;
— javob vaqti, aniq va oʻrtacha;
- kechikish;
— qayta ishlangan va ishlov berilmagan istisnolar;
- mahsulot ko'rsatkichlari.

Siqish testi

Siqish testi "siqish" testi deb ham ataladi. Texnikaning nomi Netflix-ga kiritilgan. Uning mohiyati shundan iboratki, birinchi navbatda biz bitta instansiyani haqiqiy trafik bilan ishlamay qolgangacha to'ldiramiz va shu bilan uning chegarasini belgilaymiz. Keyin biz yana bir misol qo'shamiz va bu juftlikni yuklaymiz - yana maksimal darajaga; biz ularning shiftini va deltasini birinchi "siqish" bilan ko'ramiz. Shunday qilib, biz bir vaqtning o'zida bitta misolni bog'laymiz va o'zgarishlar sxemasini hisoblaymiz.
"Siqish" orqali test ma'lumotlari ham umumiy ko'rsatkichlar ma'lumotlar bazasiga oqib chiqadi, bu erda biz sun'iy yuklash natijalarini ular bilan boyitamiz yoki hatto "sintetika" ni ular bilan almashtiramiz.

Ishlab chiqarish

• Masshtablash. Biz xizmatni ishlab chiqarishga chiqarganimizda, biz uning hajmini kuzatib boramiz. Bizning tajribamizga ko'ra, faqat CPU ko'rsatkichlarini kuzatish samarasiz. RPS benchmarking bilan avtomatik masshtablash sof shaklda ishlaydi, lekin faqat ma'lum xizmatlar uchun, masalan, onlayn oqim. Shunday qilib, biz birinchi navbatda dasturga xos mahsulot ko'rsatkichlarini ko'rib chiqamiz.

Natijada, masshtablashda biz tahlil qilamiz:
- CPU va RAM ko'rsatkichlari,
- navbatdagi so'rovlar soni;
- javob vaqti,
— toʻplangan tarixiy maʼlumotlarga asoslangan prognoz.

Xizmatni masshtablashtirganda, zanjirdagi birinchi xizmatni masshtablashtirmasligimiz uchun uning bog'liqligini kuzatish ham muhim, va u kiradigan xizmatlar yuk ostida muvaffaqiyatsiz bo'ladi. Xizmatlarning butun puli uchun maqbul yukni o'rnatish uchun biz "eng yaqin" bog'liq xizmatning tarixiy ma'lumotlarini ko'rib chiqamiz (protsessor va RAM ko'rsatkichlari kombinatsiyasi asosida, ilovaga xos ko'rsatkichlar bilan birga) va ularni tarixiy ma'lumotlar bilan taqqoslaymiz. ishga tushirish xizmati va boshqalar "bog'liq zanjiri" bo'ylab yuqoridan pastgacha.

Xizmat

Mikroservis ishga tushirilgandan so'ng biz unga triggerlarni ulashimiz mumkin.

Bu erda triggerlar yuzaga keladigan odatiy holatlar mavjud.
— Potensial xavfli migratsiya aniqlandi.
— Xavfsizlik yangilanishlari chiqarildi.
— Xizmatning o'zi uzoq vaqtdan beri yangilanmagan.
— Xizmatga yuklanish sezilarli darajada kamaydi yoki uning baʼzi mahsulot koʻrsatkichlari meʼyordan tashqarida.
— Xizmat endi yangi platforma talablariga javob bermaydi.

Triggerlarning ba'zilari ish barqarorligi uchun javobgardir, ba'zilari - tizimga texnik xizmat ko'rsatish funktsiyasi sifatida - masalan, ba'zi xizmatlar uzoq vaqt davomida o'rnatilmagan va uning asosiy tasviri xavfsizlik tekshiruvlaridan o'tishni to'xtatgan.

Boshqaruv paneli

Muxtasar qilib aytganda, asboblar paneli butun PaaS-ning boshqaruv panelidir.

• Xizmat haqida ma'lumotlarning yagona nuqtasi, uning sinov qamrovi, tasvirlar soni, ishlab chiqarish nusxalari soni, versiyalari va boshqalar.
• Xizmatlar va teglar bo'yicha ma'lumotlarni filtrlash vositasi (biznes bo'linmalariga tegishli belgilar, mahsulot funksionalligi va boshqalar).
• Kuzatish, qayd qilish va monitoring qilish uchun infratuzilma vositalari bilan integratsiyalash vositasi.
• Xizmat hujjatlarining yagona nuqtasi.
• Xizmatlar bo'yicha barcha voqealarning yagona nuqtai nazari.

jami

PaaS-ni joriy etishdan oldin, yangi ishlab chiquvchi ishlab chiqarishda mikroservisni ishga tushirish uchun zarur bo'lgan barcha vositalarni tushunish uchun bir necha hafta sarflashi mumkin: Kubernetes, Helm, bizning ichki TeamCity xususiyatlari, ma'lumotlar bazalari va keshlar bilan bog'lanishni xatolarga bardoshli tarzda o'rnatish va hokazo. Endi u Tez boshlashni o'qish va xizmatni o'zi yaratish uchun bir necha soat vaqt ketadi.

Men HighLoad++ 2018 uchun ushbu mavzu bo'yicha hisobot berdim, uni tomosha qilishingiz mumkin видео и taqdimot.

Oxirigacha o'qiganlar uchun bonus trek

Biz Avito'da ishlab chiquvchilar uchun uch kunlik ichki treningni tashkil qilmoqdamiz Kris Richardson, mikroservis arxitekturasi bo'yicha mutaxassis. Biz ushbu postning o'quvchilaridan biriga unda ishtirok etish imkoniyatini bermoqchimiz. u Trening dasturi e'lon qilindi.

Mashg'ulotlar 5-7 avgust kunlari Moskvada bo'lib o'tadi. Bu to'liq ishg'ol qilinadigan ish kunlari. Tushlik va trening bizning ofisimizda bo'ladi va tanlangan ishtirokchi yo'l va turar joy xarajatlarini o'zi to'laydi.

Ishtirok etish uchun ariza berishingiz mumkin ushbu google shaklida. Sizdan - nima uchun treningda qatnashishingiz kerak degan savolga javob va siz bilan qanday bog'lanish haqida ma'lumot. Ingliz tilida javob bering, chunki Kris treningda qatnashadigan ishtirokchini o'zi tanlaydi.
Trening ishtirokchisining ismini ushbu postni yangilashda va ishlab chiquvchilar uchun Avito ijtimoiy tarmoqlarida e'lon qilamiz (AvitoTech in Facebook, VKontakte, Twitter) 19 iyuldan kechiktirmay.

Manba: www.habr.com