Kamusta! Ang pangalan ko ay Vadim Madison, pinangunahan ko ang pagbuo ng Avito System Platform. Nasabi nang higit sa isang beses kung paano kami sa kumpanya ay lumilipat mula sa monolitikong arkitektura patungo sa isang microservice. Oras na para ibahagi kung paano namin binago ang aming imprastraktura upang masulit ang mga microservice at maiwasan ang aming sarili na mawala sa kanila. Paano kami tinutulungan ng PaaS dito, kung paano namin pinasimple ang deployment at binawasan ang paggawa ng microservice sa isang click - basahin. Hindi lahat ng isinulat ko tungkol sa ibaba ay ganap na ipinatupad sa Avito, ang ilan sa mga ito ay kung paano namin binuo ang aming platform.

(At sa dulo ng artikulong ito, magsasalita ako tungkol sa pagkakataong dumalo sa isang tatlong araw na seminar mula sa dalubhasa sa arkitektura ng microservice na si Chris Richardson).

Paano tayo napunta sa microservices

Ang Avito ay isa sa pinakamalaking classified na site sa mundo; higit sa 15 milyong bagong advertisement ang nai-publish dito bawat araw. Ang aming backend ay tumatanggap ng higit sa 20 libong mga kahilingan sa bawat segundo. Sa kasalukuyan, mayroon kaming ilang daang microservice.

Ilang taon na kaming nagtatayo ng microservice architecture. Paano eksakto - ang aming mga kasamahan sa detalye sinabi sa aming seksyon sa RIT++ 2017. Sa CodeFest 2017 (tingnan. video), Detalyadong ipinaliwanag nina Sergey Orlov at Mikhail Prokopchuk kung bakit kailangan namin ang paglipat sa mga microservice at kung ano ang papel na ginampanan ni Kubernetes dito. Well, ngayon ginagawa namin ang lahat upang mabawasan ang mga gastos sa pag-scale na likas sa gayong arkitektura.

Sa una, hindi kami lumikha ng isang ecosystem na komprehensibong makakatulong sa amin na bumuo at maglunsad ng mga microservice. Nangongolekta lang sila ng mga matinong solusyon sa open source, inilunsad ang mga ito sa bahay at inimbitahan ang developer na harapin ang mga ito. Bilang isang resulta, nagpunta siya sa isang dosenang mga lugar (dashboard, panloob na mga serbisyo), pagkatapos nito ay naging mas malakas siya sa kanyang pagnanais na i-cut ang code sa lumang paraan, sa isang monolith. Ang berdeng kulay sa mga diagram sa ibaba ay nagpapahiwatig kung ano ang ginagawa ng developer sa isang paraan o iba pa gamit ang kanyang sariling mga kamay, at ang dilaw na kulay ay nagpapahiwatig ng automation.

Ngayon sa PaaS CLI utility, ang isang bagong serbisyo ay nilikha gamit ang isang command, at isang bagong database ay idinagdag na may dalawa pa at na-deploy sa Stage.

Paano malalampasan ang panahon ng "pagkapira-piraso ng microservice"

Sa isang monolitikong arkitektura, para sa kapakanan ng pagkakapare-pareho ng mga pagbabago sa produkto, napilitan ang mga developer na malaman kung ano ang nangyayari sa kanilang mga kapitbahay. Kapag nagtatrabaho sa bagong arkitektura, ang mga konteksto ng serbisyo ay hindi na nakadepende sa isa't isa.

Bilang karagdagan, para maging mabisa ang isang arkitektura ng microservice, maraming proseso ang kailangang itatag, lalo na:

• pagtotroso;
• humiling ng pagsubaybay (Jaeger);
• pagsasama-sama ng error (Sentry);
• mga katayuan, mensahe, kaganapan mula sa Kubernetes (Pagproseso ng Stream ng Kaganapan);
• race limit / circuit breaker (maaari mong gamitin ang Hystrix);
• kontrol sa pagkakakonekta ng serbisyo (ginagamit namin ang Netramesh);
• pagsubaybay (Grafana);
• pagpupulong (TeamCity);
• komunikasyon at abiso (Slack, email);
• pagsubaybay sa gawain; (Jira)
• paghahanda ng dokumentasyon.

Upang matiyak na ang system ay hindi mawawala ang integridad nito at mananatiling epektibo habang ito ay sumusukat, muli naming inisip ang organisasyon ng mga microservice sa Avito.

Paano namin pinamamahalaan ang mga microservice

Ang sumusunod na tulong upang ipatupad ang isang pinag-isang "patakaran ng partido" sa maraming microservice ng Avito:

• paghahati ng imprastraktura sa mga layer;
• Konsepto ng Platform bilang isang Serbisyo (PaaS);
• pagsubaybay sa lahat ng nangyayari sa mga microservice.

Kasama sa mga layer ng abstraction ng imprastraktura ang tatlong layer. Pumunta tayo mula sa itaas hanggang sa ibaba.

A. Nangungunang - service mesh. Sa una sinubukan namin ang Istio, ngunit ito ay lumabas na gumagamit ito ng napakaraming mapagkukunan, na masyadong mahal para sa aming mga volume. Samakatuwid, ang senior engineer sa pangkat ng arkitektura na si Alexander Lukyanchenko ay bumuo ng kanyang sariling solusyon - Netramesh (magagamit sa Open Source), na kasalukuyang ginagamit namin sa produksyon at kumokonsumo ng ilang beses na mas kaunting mapagkukunan kaysa sa Istio (ngunit hindi ginagawa ang lahat ng maaaring ipagmalaki ni Istio).
B. Daluyan - Kubernetes. Nag-deploy at nagpapatakbo kami ng mga microservice dito.
C. Ibaba - hubad na metal. Hindi kami gumagamit ng mga ulap o mga bagay tulad ng OpenStack, ngunit ganap na umaasa sa bare metal.

Ang lahat ng mga layer ay pinagsama ng PaaS. At ang platform na ito, naman, ay binubuo ng tatlong bahagi.

I. Mga Generator, kinokontrol sa pamamagitan ng isang CLI utility. Siya ang tumutulong sa developer na lumikha ng isang microservice sa tamang paraan at may kaunting pagsisikap.

II. Pinagsama-samang kolektor na may kontrol sa lahat ng tool sa pamamagitan ng isang karaniwang dashboard.

III. Imbakan. Kumokonekta sa mga scheduler na awtomatikong nagtatakda ng mga trigger para sa mahahalagang pagkilos. Salamat sa ganoong sistema, wala ni isang gawain ang napalampas dahil lang sa may nakalimutang mag-set up ng gawain sa Jira. Gumagamit kami ng panloob na tool na tinatawag na Atlas para dito.

Ang pagpapatupad ng mga microservice sa Avito ay isinasagawa din ayon sa isang solong pamamaraan, na pinapasimple ang kontrol sa mga ito sa bawat yugto ng pag-unlad at pagpapalabas.

Paano gumagana ang isang karaniwang microservice development pipeline?

Sa pangkalahatan, ganito ang hitsura ng chain ng paglikha ng microservice:

CLI-push → Continuous Integration → Bake → Deploy → Artipisyal na pagsubok → Canary tests → Squeeze Testing → Production → Maintenance.

Suriin natin ito nang eksakto sa ganitong pagkakasunud-sunod.

CLI-push

• Paglikha ng microservice.
Matagal kaming nahirapan para turuan ang bawat developer kung paano gumawa ng mga microservice. Kasama dito ang pagsulat ng mga detalyadong tagubilin sa Confluence. Ngunit ang mga scheme ay nagbago at dinagdagan. Ang resulta ay lumitaw ang isang bottleneck sa simula ng paglalakbay: tumagal ng mas maraming oras upang ilunsad ang mga microservice, at madalas pa ring lumitaw ang mga problema sa panahon ng kanilang paglikha.

Sa huli, bumuo kami ng simpleng CLI utility na nag-automate sa mga pangunahing hakbang kapag gumagawa ng microservice. Sa katunayan, pinapalitan nito ang unang git push. Narito kung ano ang eksaktong ginagawa niya.

— Lumilikha ng serbisyo ayon sa isang template — hakbang-hakbang, sa “wizard” mode. Mayroon kaming mga template para sa mga pangunahing programming language sa Avito backend: PHP, Golang at Python.

- Isang utos sa isang pagkakataon ay naglalagay ng kapaligiran para sa lokal na pag-unlad sa isang partikular na makina - Ang Minikube ay inilunsad, ang mga Helm chart ay awtomatikong nabuo at inilulunsad sa mga lokal na kubernete.

— Ikinokonekta ang kinakailangang database. Hindi kailangang malaman ng developer ang IP, pag-login at password upang makakuha ng access sa database na kailangan niya - maging ito sa lokal, sa Stage, o sa produksyon. Higit pa rito, ang database ay na-deploy kaagad sa isang fault-tolerant na configuration at may pagbabalanse.

— Nagsasagawa ito ng live na pagpupulong mismo. Sabihin nating may naitama ang isang developer sa isang microservice sa pamamagitan ng kanyang IDE. Nakikita ng utility ang mga pagbabago sa file system at, batay sa mga ito, muling itinatayo ang application (para sa Golang) at mag-restart. Para sa PHP, ipinapasa lang namin ang direktoryo sa loob ng cube at doon ay makukuha ang live-reload na "awtomatikong".

— Bumubuo ng mga autotest. Sa anyo ng mga blangko, ngunit medyo angkop para sa paggamit.

• Pag-deploy ng microservice.

Ang pag-deploy ng microservice dati ay medyo mahirap para sa amin. Ang mga sumusunod ay kinakailangan:

I. Dockerfile.

II. Config.
III. Helm chart, na kung saan ay napakahirap at kinabibilangan ng:

— ang mga tsart mismo;
- mga template;
— mga tiyak na halaga na isinasaalang-alang ang iba't ibang mga kapaligiran.

Inalis namin ang sakit sa muling paggawa ng mga manifest ng Kubernetes kaya awtomatiko na itong nabuo. Ngunit ang pinakamahalaga, pinasimple nila ang pag-deploy sa limitasyon. Mula ngayon mayroon na kaming Dockerfile, at isinusulat ng developer ang buong config sa isang solong maikling app.toml file.

Oo, at sa app.toml mismo ay walang magagawa sa loob ng isang minuto. Tinukoy namin kung saan at gaano karaming mga kopya ng serbisyo ang itataas (sa dev server, sa pagtatanghal, sa produksyon), at ipahiwatig ang mga dependency nito. Pansinin ang laki ng linya = "maliit" sa bloke ng [engine]. Ito ang limitasyon na ilalaan sa serbisyo sa pamamagitan ng Kubernetes.

Pagkatapos, batay sa config, ang lahat ng kinakailangang Helm chart ay awtomatikong nabubuo at ang mga koneksyon sa mga database ay nilikha.

• Pangunahing pagpapatunay. Ang mga naturang pagsusuri ay awtomatiko din.
Kailangang subaybayan:
— mayroon bang Dockerfile;
— mayroon bang app.toml;
— mayroon bang magagamit na dokumentasyon?
— maayos ba ang dependency?
— kung naitakda na ang mga alituntunin ng alerto.
Hanggang sa huling punto: ang may-ari ng serbisyo mismo ang nagpapasiya kung aling mga sukatan ng produkto ang susubaybayan.

• Paghahanda ng dokumentasyon.
Problema pa rin ang lugar. Tila ito ang pinaka-halata, ngunit sa parehong oras ito rin ay isang talaan na "madalas na nakalimutan", at samakatuwid ay isang mahina na link sa kadena.
Kinakailangan na mayroong dokumentasyon para sa bawat microservice. Kasama dito ang mga sumusunod na bloke.

I. Maikling paglalarawan ng serbisyo. Literal na ilang pangungusap tungkol sa kung ano ang ginagawa nito at kung bakit ito kinakailangan.

II. Link ng diagram ng arkitektura. Mahalaga na sa isang mabilis na sulyap dito ay madaling maunawaan, halimbawa, kung gumagamit ka ng Redis para sa pag-cache o bilang pangunahing data store sa persistent mode. Sa Avito sa ngayon ito ay isang link sa Confluence.

III. Runbook. Isang maikling gabay sa pagsisimula ng serbisyo at ang pagkasalimuot ng paghawak nito.

IV. FAQ, kung saan makabubuting asahan ang mga problemang maaaring makaharap ng iyong mga kasamahan kapag nagtatrabaho sa serbisyo.

V. Paglalarawan ng mga endpoint para sa API. Kung bigla mong hindi tinukoy ang mga destinasyon, halos tiyak na babayaran ito ng mga kasamahan na may kaugnayan sa iyo ang mga microservice. Ngayon ginagamit namin ang Swagger at ang aming solusyon na tinatawag na maikling para dito.

VI. Mga label. O mga marker na nagpapakita kung saang produkto, functionality, o structural division ng kumpanya kabilang ang serbisyo. Tinutulungan ka nilang mabilis na maunawaan, halimbawa, kung pinuputol mo ang functionality na inilunsad ng iyong mga kasamahan para sa parehong unit ng negosyo noong nakaraang linggo.

VII. May-ari o may-ari ng serbisyo. Sa karamihan ng mga kaso, ito — o sila — ay maaaring awtomatikong matukoy gamit ang PaaS, ngunit upang maging ligtas, hinihiling namin sa developer na tukuyin ang mga ito nang manu-mano.

Sa wakas, isang magandang kasanayan na suriin ang dokumentasyon, katulad ng pagsusuri ng code.

Patuloy na Pagsasama

• Paghahanda ng mga repositoryo.
• Paglikha ng pipeline sa TeamCity.
• Pagtatakda ng mga karapatan.
• Maghanap ng mga may-ari ng serbisyo. Mayroong hybrid scheme dito - manu-manong pagmamarka at minimal na automation mula sa PaaS. Nabigo ang isang ganap na awtomatikong scheme kapag inilipat ang mga serbisyo para sa suporta sa isa pang development team o, halimbawa, kung huminto ang developer ng serbisyo.
• Pagrerehistro ng isang serbisyo sa Atlas (tingnan sa itaas). Sa lahat ng may-ari at dependency nito.
• Sinusuri ang mga migrasyon. Sinusuri namin kung ang alinman sa mga ito ay potensyal na mapanganib. Halimbawa, sa isa sa mga ito ay may lalabas na alter table o iba pang bagay na maaaring masira ang compatibility ng data schema sa pagitan ng iba't ibang bersyon ng serbisyo. Pagkatapos ay hindi isinasagawa ang paglipat, ngunit inilagay sa isang subscription - dapat na senyales ng PaaS ang may-ari ng serbisyo kapag ligtas itong gamitin.

maghurno

Ang susunod na yugto ay ang mga serbisyo sa packaging bago ang pag-deploy.

• Pagbuo ng application. Ayon sa mga klasiko - sa isang imahe ng Docker.
• Pagbuo ng mga Helm chart para sa mismong serbisyo at mga kaugnay na mapagkukunan. Kabilang ang para sa mga database at cache. Awtomatikong nilikha ang mga ito alinsunod sa app.toml config na nabuo sa yugto ng CLI-push.
• Paglikha ng mga tiket para sa mga admin na magbukas ng mga port (Kapag kailangan).
• Pagpapatakbo ng mga pagsubok sa unit at pagkalkula ng saklaw ng code. Kung ang saklaw ng code ay mas mababa sa tinukoy na threshold, malamang na hindi na lalayo pa ang serbisyo - sa pag-deploy. Kung ito ay nasa gilid ng katanggap-tanggap, kung gayon ang serbisyo ay bibigyan ng isang "pessimizing" na koepisyent: kung gayon, kung walang pagpapabuti sa tagapagpahiwatig sa paglipas ng panahon, ang developer ay makakatanggap ng isang abiso na walang pag-unlad sa mga tuntunin ng mga pagsubok ( at may kailangang gawin tungkol dito).
• Accounting para sa memorya at mga limitasyon ng CPU. Pangunahing nagsusulat kami ng mga microservice sa Golang at pinapatakbo ang mga ito sa Kubernetes. Kaya't isang subtlety na nauugnay sa kakaiba ng wikang Golang: bilang default, kapag nagsisimula, ang lahat ng mga core sa makina ay ginagamit, kung hindi mo tahasang itinakda ang variable ng GOMAXPROCS, at kapag ang ilang mga naturang serbisyo ay inilunsad sa parehong makina, magsisimula ang mga ito. upang makipagkumpetensya para sa mga mapagkukunan, nakakasagabal sa bawat isa. Ipinapakita ng mga graph sa ibaba kung paano nagbabago ang oras ng pagpapatupad kung patakbuhin mo ang application nang walang pagtatalo at sa karera para sa mode ng mapagkukunan. (Ang mga pinagmumulan ng mga graph ay dito).

Ang oras ng pagpapatupad, mas kaunti ay mas mahusay. Maximum: 643ms, minimum: 42ms. Naki-click ang larawan.

Oras para sa operasyon, mas kaunti ay mas mabuti. Maximum: 14091 ns, minimum: 151 ns. Naki-click ang larawan.

Sa yugto ng paghahanda ng pagpupulong, maaari mong itakda ang variable na ito nang tahasan o maaari mong gamitin ang library automaxprocs mula sa mga lalaki mula sa Uber.

I-deploy

• Pagsusuri ng mga kombensiyon. Bago ka magsimulang maghatid ng mga service assemblies sa iyong nilalayong kapaligiran, kailangan mong suriin ang sumusunod:
- Mga endpoint ng API.
— Pagsunod sa mga tugon ng mga endpoint ng API sa schema.
— Format ng log.
— Pagtatakda ng mga header para sa mga kahilingan sa serbisyo (kasalukuyang ginagawa ito ng netramesh)
— Pagtatakda ng token ng may-ari kapag nagpapadala ng mga mensahe sa bus ng kaganapan. Ito ay kinakailangan upang masubaybayan ang pagkakakonekta ng mga serbisyo sa buong bus. Maaari kang magpadala ng parehong idempotent na data sa bus, na hindi nagpapataas ng koneksyon ng mga serbisyo (na mabuti), at ng data ng negosyo na nagpapalakas sa koneksyon ng mga serbisyo (na napakasama!). At sa puntong nagiging isyu ang koneksyong ito, nakakatulong ang pag-unawa kung sino ang sumulat at nagbabasa ng bus upang maayos na paghiwalayin ang mga serbisyo.

Wala pang masyadong convention sa Avito, pero lumalawak ang pool nila. Kung mas maraming ganoong kasunduan ang available sa isang form na mauunawaan at mauunawaan ng team, mas madaling mapanatili ang pagkakapare-pareho sa pagitan ng mga microservice.

Mga sintetikong pagsubok

• Closed loop testing. Para dito gumagamit kami ngayon ng open source Hoverfly.io. Una, itinatala nito ang tunay na pagkarga sa serbisyo, pagkatapos - sa isang saradong loop - tinutularan ito.

• Stress Testing. Sinusubukan naming dalhin ang lahat ng mga serbisyo sa pinakamainam na pagganap. At ang lahat ng mga bersyon ng bawat serbisyo ay dapat sumailalim sa pagsubok sa pag-load - sa paraang ito ay mauunawaan natin ang kasalukuyang pagganap ng serbisyo at ang pagkakaiba sa mga nakaraang bersyon ng parehong serbisyo. Kung, pagkatapos ng isang pag-update ng serbisyo, ang pagganap nito ay bumaba ng isa at kalahating beses, ito ay isang malinaw na senyales para sa mga may-ari nito: kailangan mong maghukay sa code at itama ang sitwasyon.
Ginagamit namin ang nakolektang data, halimbawa, upang maipatupad nang tama ang awtomatikong pag-scale at, sa huli, sa pangkalahatan ay nauunawaan kung gaano ka-scalable ang serbisyo.

Sa panahon ng pagsubok sa pag-load, sinusuri namin kung ang pagkonsumo ng mapagkukunan ay nakakatugon sa mga itinakdang limitasyon. At pangunahing nakatuon kami sa mga sukdulan.

a) Tinitingnan namin ang kabuuang pagkarga.
- Masyadong maliit - malamang na ang isang bagay ay hindi gagana kung ang load ay biglang bumaba ng maraming beses.
- Masyadong malaki - kailangan ang pag-optimize.

b) Tinitingnan namin ang cutoff ayon sa RPS.
Dito tinitingnan natin ang pagkakaiba sa pagitan ng kasalukuyang bersyon at ng nauna at ang kabuuang dami. Halimbawa, kung ang isang serbisyo ay gumagawa ng 100 rps, kung gayon ito ay alinman sa hindi magandang pagkakasulat, o ito ang pagiging tiyak nito, ngunit sa anumang kaso, ito ay isang dahilan upang tingnan ang serbisyo nang napakalapit.
Kung, sa kabaligtaran, mayroong masyadong maraming RPS, kung gayon marahil mayroong ilang uri ng bug at ang ilan sa mga endpoint ay tumigil sa pagpapatupad ng payload, ngunit ang iba ay na-trigger lang. return true;

Mga pagsubok sa canary

Pagkatapos naming makapasa sa mga synthetic na pagsubok, sinubukan namin ang microservice sa isang maliit na bilang ng mga user. Nagsisimula kaming maingat, na may maliit na bahagi ng nilalayong madla ng serbisyo - mas mababa sa 0,1%. Sa yugtong ito, napakahalaga na ang tamang teknikal at mga sukatan ng produkto ay kasama sa pagsubaybay upang maipakita nila ang problema sa serbisyo sa lalong madaling panahon. Ang pinakamababang oras para sa isang canary test ay 5 minuto, ang pangunahing isa ay 2 oras. Para sa mga kumplikadong serbisyo, manu-manong itinakda namin ang oras.
Suriin natin:
— mga sukatan na tukoy sa wika, sa partikular, mga manggagawa sa php-fpm;
— mga error sa Sentry;
- mga katayuan ng tugon;
— oras ng pagtugon, eksakto at karaniwan;
- latency;
— mga pagbubukod, naproseso at hindi nahawakan;
— mga sukatan ng produkto.

Squeeze Testing

Ang Squeeze Testing ay tinatawag ding "squeezing" testing. Ang pangalan ng pamamaraan ay ipinakilala sa Netflix. Ang kakanyahan nito ay punan muna natin ang isang pagkakataon ng tunay na trapiko hanggang sa punto ng pagkabigo at sa gayon ay itinakda ang limitasyon nito. Pagkatapos ay magdagdag kami ng isa pang pagkakataon at i-load ang pares na ito - muli sa maximum; nakikita natin ang kanilang kisame at delta sa unang "pagpisil". At kaya ikinonekta namin ang isang pagkakataon sa isang pagkakataon at kalkulahin ang pattern ng mga pagbabago.
Ang data ng pagsubok sa pamamagitan ng "pagipit" ay dumadaloy din sa isang karaniwang database ng mga sukatan, kung saan maaari naming pagyamanin ang mga resulta ng artipisyal na pag-load sa kanila, o kahit na papalitan ang "mga gawa ng tao" sa kanila.

Produksyon

• Pagsusukat. Kapag inilunsad namin ang isang serbisyo sa produksyon, sinusubaybayan namin kung paano ito nasusukat. Sa aming karanasan, ang pagsubaybay lamang sa mga tagapagpahiwatig ng CPU ay hindi epektibo. Gumagana ang auto scaling gamit ang RPS benchmarking sa purong anyo nito, ngunit para lang sa ilang partikular na serbisyo, gaya ng online streaming. Kaya tinitingnan muna namin ang mga sukatan ng produkto na tukoy sa application.

Bilang resulta, kapag nag-scale, sinusuri namin ang:
- Mga tagapagpahiwatig ng CPU at RAM,
— ang bilang ng mga kahilingan sa pila,
- oras ng pagtugon,
— pagtataya batay sa naipon na makasaysayang data.

Kapag nag-scale ng isang serbisyo, mahalagang subaybayan din ang mga dependency nito para hindi natin ma-scale ang unang serbisyo sa chain, at ang mga na-access nito ay nabigo sa ilalim ng pagkarga. Upang magtatag ng katanggap-tanggap na pag-load para sa buong pool ng mga serbisyo, tinitingnan namin ang dating data ng "pinakamalapit" na umaasa na serbisyo (batay sa kumbinasyon ng mga indicator ng CPU at RAM, kasama ng mga sukatan na partikular sa app) at inihambing ang mga ito sa dating data. ng pagsisimula ng serbisyo, at iba pa sa buong “dependency chain” ", mula sa itaas hanggang sa ibaba.

Serbisyo

Pagkatapos maisagawa ang microservice, maaari kaming mag-attach ng mga trigger dito.

Narito ang mga karaniwang sitwasyon kung saan nagaganap ang mga pag-trigger.
— May nakitang potensyal na mapanganib na paglilipat.
— Ang mga update sa seguridad ay inilabas.
— Ang serbisyo mismo ay hindi na-update sa loob ng mahabang panahon.
— Ang pagkarga sa serbisyo ay kapansin-pansing nabawasan o ang ilan sa mga sukatan ng produkto nito ay nasa labas ng normal na hanay.
— Hindi na natutugunan ng serbisyo ang mga bagong kinakailangan sa platform.

Ang ilan sa mga nag-trigger ay may pananagutan para sa katatagan ng operasyon, ang ilan - bilang isang function ng pagpapanatili ng system - halimbawa, ang ilang serbisyo ay hindi na-deploy sa loob ng mahabang panahon at ang base na imahe nito ay tumigil sa pagpasa sa mga pagsusuri sa seguridad.

Dashboard

Sa madaling salita, ang dashboard ay ang control panel ng aming buong PaaS.

• Isang punto ng impormasyon tungkol sa serbisyo, na may data sa saklaw ng pagsubok nito, ang bilang ng mga larawan nito, ang bilang ng mga kopya ng produksyon, mga bersyon, atbp.
• Isang tool para sa pag-filter ng data ayon sa mga serbisyo at label (mga marker ng pagmamay-ari ng mga unit ng negosyo, functionality ng produkto, atbp.)
• Isang tool sa pagsasama sa mga tool sa imprastraktura para sa pagsubaybay, pag-log, at pagsubaybay.
• Isang punto ng dokumentasyon ng serbisyo.
• Isang solong punto ng view ng lahat ng mga kaganapan sa mga serbisyo.

Sa kabuuan

Bago ipakilala ang PaaS, maaaring gumugol ng ilang linggo ang isang bagong developer sa pag-unawa sa lahat ng mga tool na kinakailangan para maglunsad ng microservice sa produksyon: Kubernetes, Helm, ang aming mga internal na feature ng TeamCity, pagse-set up ng mga koneksyon sa mga database at cache sa isang fault-tolerant na paraan, atbp. Ngayon ay tumatagal ng ilang oras upang basahin ang quickstart at gawin ang serbisyo mismo.

Nagbigay ako ng ulat sa paksang ito para sa HighLoad++ 2018, maaari mo itong panoorin video и pagtatanghal.

Bonus track para sa mga nagbabasa hanggang dulo

Kami sa Avito ay nag-aayos ng panloob na tatlong araw na pagsasanay para sa mga developer mula sa Chris Richardson, isang dalubhasa sa microservice architecture. Nais naming bigyan ng pagkakataon na makilahok dito sa isa sa mga mambabasa ng post na ito. Dito Ang programa ng pagsasanay ay nai-post.

Ang pagsasanay ay magaganap mula Agosto 5 hanggang 7 sa Moscow. Ito ay mga araw ng trabaho na ganap na abala. Ang tanghalian at pagsasanay ay nasa aming opisina, at ang napiling kalahok ay magbabayad para sa paglalakbay at tirahan mismo.

Maaari kang mag-aplay para sa pakikilahok sa google form na ito. Mula sa iyo - ang sagot sa tanong kung bakit kailangan mong dumalo sa pagsasanay at impormasyon kung paano makipag-ugnayan sa iyo. Sagot sa English, dahil si Chris ang pipili ng kalahok na dadalo mismo sa training.
Iaanunsyo namin ang pangalan ng kalahok sa pagsasanay sa isang update sa post na ito at sa mga social network na Avito para sa mga developer (AvitoTech sa Facebook, Vkontakte, Twitter) hindi lalampas sa Hulyo 19.

Pinagmulan: www.habr.com