Habari! Jina langu ni Vadim Madison, ninaongoza maendeleo ya Avito System Platform. Imesemwa zaidi ya mara moja jinsi sisi katika kampuni tunasonga kutoka kwa usanifu wa monolithic hadi kwa huduma ndogo. Ni wakati wa kushiriki jinsi tumebadilisha miundombinu yetu ili kunufaika zaidi na huduma ndogo na kujiepusha na kupotea kwazo. Jinsi PaaS inatusaidia hapa, jinsi tulivyorahisisha uwekaji na kupunguza uundaji wa huduma ndogo kwa mbofyo mmoja - soma. Sio kila kitu ninachoandika hapa chini kinatekelezwa kikamilifu katika Avito, baadhi yake ni jinsi tunavyoendeleza jukwaa letu.

(Na mwisho wa makala hii, nitazungumzia fursa ya kuhudhuria semina ya siku tatu kutoka kwa mtaalamu wa usanifu wa microservice Chris Richardson).

Jinsi tulivyokuja kwa huduma ndogo

Avito ni moja wapo ya tovuti kubwa zaidi zilizoainishwa ulimwenguni; zaidi ya matangazo mapya milioni 15 huchapishwa juu yake kwa siku. Hali yetu ya nyuma inakubali maombi zaidi ya elfu 20 kwa sekunde. Kwa sasa tuna huduma ndogo mia kadhaa.

Tumekuwa tukiunda usanifu wa huduma ndogo kwa miaka kadhaa sasa. Jinsi gani hasa - wenzetu kwa undani aliiambia katika sehemu yetu katika RIT ++ 2017. Katika CodeFest 2017 (tazama. video), Sergey Orlov na Mikhail Prokopchuk walielezea kwa undani kwa nini tulihitaji mpito kwa huduma ndogo na jukumu gani Kubernetes alicheza hapa. Kweli, sasa tunafanya kila kitu ili kupunguza gharama za kuongeza ambazo ni za asili katika usanifu kama huo.

Hapo awali, hatukuunda mfumo wa ikolojia ambao ungetusaidia kikamilifu kukuza na kuzindua huduma ndogo ndogo. Walikusanya tu masuluhisho ya busara ya chanzo huria, wakayazindua nyumbani na wakamwalika msanidi programu kukabiliana nayo. Kama matokeo, alienda sehemu kadhaa (dashibodi, huduma za ndani), baada ya hapo akawa na nguvu katika hamu yake ya kukata nambari kwa njia ya zamani, kwa monolith. Rangi ya kijani katika michoro hapa chini inaonyesha kile msanidi anafanya kwa njia moja au nyingine kwa mikono yake mwenyewe, na rangi ya njano inaonyesha automatisering.

Sasa katika matumizi ya PaaS CLI, huduma mpya imeundwa kwa amri moja, na hifadhidata mpya inaongezwa na mbili zaidi na kupelekwa kwa Hatua.

Jinsi ya kushinda enzi ya "mgawanyiko wa microservice"

Kwa usanifu wa monolithic, kwa ajili ya uthabiti wa mabadiliko katika bidhaa, watengenezaji walilazimika kufikiri nini kinachoendelea na majirani zao. Wakati wa kufanya kazi kwenye usanifu mpya, muktadha wa huduma hautegemei tena.

Kwa kuongezea, ili usanifu wa huduma ndogo uwe mzuri, michakato mingi inahitaji kuanzishwa, ambayo ni:

• ukataji miti;
• omba ufuatiliaji (Jaeger);
• ujumlisho wa makosa (Mlinzi);
• hali, ujumbe, matukio kutoka Kubernetes (Uchakataji wa Mitiririko ya Tukio);
• kikomo cha mbio / kivunja mzunguko (unaweza kutumia Hystrix);
• udhibiti wa muunganisho wa huduma (tunatumia Netramesh);
• ufuatiliaji (Grafana);
• mkusanyiko (TeamCity);
• mawasiliano na arifa (Slack, barua pepe);
• ufuatiliaji wa kazi; (Jira)
• maandalizi ya nyaraka.

Ili kuhakikisha kuwa mfumo haupotezi uadilifu wake na unaendelea kuwa na ufanisi unaposawazisha, tulifikiria upya shirika la huduma ndogo katika Avito.

Jinsi tunavyosimamia huduma ndogo

Msaada ufuatao wa kutekeleza "sera ya chama" kati ya huduma ndogo nyingi za Avito:

• kugawanya miundombinu katika tabaka;
• Dhana ya Jukwaa kama Huduma (PaaS);
• kufuatilia kila kitu kinachotokea na microservices.

Tabaka za uondoaji wa miundombinu ni pamoja na tabaka tatu. Twende kutoka juu hadi chini.

A. Juu - mesh ya huduma. Mara ya kwanza tulijaribu Istio, lakini ikawa kwamba inatumia rasilimali nyingi, ambayo ni ghali sana kwa kiasi chetu. Kwa hivyo, mhandisi mwandamizi katika timu ya usanifu Alexander Lukyanchenko alitengeneza suluhisho lake mwenyewe - Netramesh (inapatikana katika Open Source), ambayo kwa sasa tunaitumia katika uzalishaji na ambayo hutumia rasilimali mara kadhaa chini ya Istio (lakini haifanyi kila kitu ambacho Istio inaweza kujivunia).
B. Kati - Kubernetes. Tunapeleka na kuendesha huduma ndogo juu yake.
C. Chini - chuma tupu. Hatutumii mawingu au vitu kama OpenStack, lakini hutegemea kabisa chuma tupu.

Tabaka zote zimeunganishwa na PaaS. Na jukwaa hili, kwa upande wake, lina sehemu tatu.

I. Jenereta, kudhibitiwa kupitia matumizi ya CLI. Ni yeye ambaye husaidia msanidi programu kuunda huduma ndogo kwa njia sahihi na kwa bidii kidogo.

II. Mkusanyaji aliyejumuishwa na udhibiti wa zana zote kupitia dashibodi ya pamoja.

III. Hifadhi. Huunganishwa na vipanga ratiba ambavyo huweka vichochezi kiotomatiki vya vitendo muhimu. Shukrani kwa mfumo kama huo, hakuna kazi moja ambayo inakosa kwa sababu tu mtu alisahau kuanzisha kazi huko Jira. Tunatumia zana ya ndani inayoitwa Atlas kwa hili.

Utekelezaji wa huduma ndogo katika Avito pia unafanywa kulingana na mpango mmoja, ambao hurahisisha udhibiti juu yao katika kila hatua ya maendeleo na kutolewa.

Je, bomba la kawaida la ukuzaji huduma ndogo hufanya kazi vipi?

Kwa ujumla, mlolongo wa uundaji wa huduma ndogo unaonekana kama hii:

CLI-sukuma → Muunganisho Unaoendelea → Oka → Tumia → Majaribio Bandia → Majaribio ya Canary → Jaribio la Bana → Uzalishaji → Matengenezo.

Wacha tuipitie kwa mpangilio huu.

CLI-sukuma

• Kutengeneza huduma ndogo.
Tulijitahidi kwa muda mrefu kufundisha kila msanidi jinsi ya kufanya huduma ndogo. Hii ni pamoja na kuandika maagizo ya kina katika Confluence. Lakini mipango ilibadilika na kuongezewa. Matokeo yake ni kwamba kizuizi kilionekana mwanzoni mwa safari: ilichukua muda zaidi kuzindua huduma ndogo, na bado matatizo mara nyingi yalitokea wakati wa uumbaji wao.

Mwishowe, tuliunda matumizi rahisi ya CLI ambayo hubadilisha hatua za kimsingi wakati wa kuunda huduma ndogo. Kwa kweli, inachukua nafasi ya msukumo wa kwanza wa git. Hapa ni nini hasa yeye anafanya.

— Hutengeneza huduma kulingana na kiolezo — hatua kwa hatua, katika hali ya “mchawi”. Tuna violezo vya lugha kuu za programu katika mazingira ya nyuma ya Avito: PHP, Golang na Python.

- Amri moja baada ya nyingine hutuma mazingira ya ukuzaji wa ndani kwenye mashine mahususi - Minikube inazinduliwa, Chati za Helm huzalishwa kiotomatiki na kuzinduliwa katika kubernetes za ndani.

- Huunganisha hifadhidata inayohitajika. Msanidi hahitaji kujua IP, kuingia na nenosiri ili kupata ufikiaji wa hifadhidata anayohitaji - iwe ndani ya nchi, kwenye Hatua, au katika uzalishaji. Zaidi ya hayo, hifadhidata inawekwa mara moja katika usanidi unaostahimili makosa na kwa kusawazisha.

- Hufanya mkusanyiko wa moja kwa moja yenyewe. Wacha tuseme msanidi programu alirekebisha kitu kwenye huduma ndogo kupitia IDE yake. Huduma hiyo inaona mabadiliko katika mfumo wa faili na, kulingana nao, inaunda upya programu (kwa Golang) na kuanzisha upya. Kwa PHP, tunasambaza saraka ndani ya mchemraba na upakiaji wa moja kwa moja unapatikana "moja kwa moja".

- Huzalisha majaribio otomatiki. Kwa namna ya tupu, lakini inafaa kabisa kwa matumizi.

• Usambazaji wa huduma ndogo.

Kutuma huduma ndogo ilikuwa kazi kidogo kwetu. Yafuatayo yalihitajika:

I. Dockerfile.

II. Sanidi.
III. Chati ya usukani, ambayo yenyewe ni ngumu na inajumuisha:

- chati zenyewe;
- templates;
- maadili maalum kwa kuzingatia mazingira tofauti.

Tumeondoa maumivu ya kurekebisha faili za Kubernetes kwa hivyo sasa zinazalishwa kiotomatiki. Lakini muhimu zaidi, wamerahisisha upelekaji hadi kikomo. Kuanzia sasa tuna Dockerfile, na msanidi anaandika usanidi mzima katika faili moja fupi ya app.toml.

Ndiyo, na katika app.toml yenyewe hakuna kitu cha kufanya kwa dakika. Tunabainisha wapi na ni nakala ngapi za huduma ya kuongeza (kwenye seva ya dev, kwenye hatua, katika uzalishaji), na kuonyesha utegemezi wake. Angalia saizi ya mstari = "ndogo" kwenye kizuizi cha [injini]. Hiki ndicho kikomo ambacho kitatolewa kwa huduma kupitia Kubernetes.

Kisha, kwa kuzingatia usanidi, chati zote muhimu za Helm zinazalishwa kiotomatiki na miunganisho kwenye hifadhidata huundwa.

• Uthibitishaji wa kimsingi. Cheki kama hizo pia ni za kiotomatiki.
Inahitajika kufuatilia:
- kuna Dockerfile;
- kuna programu.toml;
- kuna nyaraka zinapatikana?
- utegemezi uko kwa mpangilio?
- ikiwa sheria za tahadhari zimewekwa.
Hadi hatua ya mwisho: mmiliki wa huduma mwenyewe huamua ni metrics ya bidhaa ya kufuatilia.

• Maandalizi ya nyaraka.
Bado ni eneo la shida. Inaonekana kuwa ni dhahiri zaidi, lakini wakati huo huo pia ni rekodi "mara nyingi husahau", na kwa hiyo kiungo cha mazingira magumu katika mlolongo.
Ni muhimu kwamba kuna nyaraka kwa kila microservice. Inajumuisha vitalu vifuatavyo.

I. Maelezo mafupi ya huduma. Sentensi chache kuhusu kile kinachofanya na kwa nini inahitajika.

II. Kiungo cha mchoro wa usanifu. Ni muhimu kwamba kwa kuiangalia kwa haraka ni rahisi kuelewa, kwa mfano, ikiwa unatumia Redis kwa caching au kama hifadhi kuu ya data katika hali ya kuendelea. Katika Avito kwa sasa hiki ni kiungo cha Confluence.

III. Kitabu cha kukimbia. Mwongozo mfupi wa kuanzisha huduma na ugumu wa kuishughulikia.

IV. Maswali Yanayoulizwa Mara kwa Mara, ambapo itakuwa vizuri kutarajia matatizo ambayo wenzako wanaweza kukutana wakati wa kufanya kazi na huduma.

V. Maelezo ya sehemu za mwisho za API. Ikiwa ghafla haukutaja marudio, wenzako ambao microservices zao zinahusiana na zako karibu hakika watalipa. Sasa tunatumia Swagger na suluhisho letu linaitwa fupi kwa hili.

VI. Lebo. Au vialamisho vinavyoonyesha ni bidhaa gani, utendakazi, au mgawanyiko wa kimuundo wa kampuni ambayo huduma ni yake. Zinakusaidia kuelewa kwa haraka, kwa mfano, ikiwa unapunguza utendakazi ambao wenzako walizindua kwa kitengo sawa cha biashara wiki moja iliyopita.

VII. Mmiliki au wamiliki wa huduma. Katika hali nyingi, ni - au wao - wanaweza kubainishwa kiotomatiki kwa kutumia PaaS, lakini ili kuwa katika upande salama, tunahitaji msanidi programu azibainishe mwenyewe.

Hatimaye, ni mazoezi mazuri kukagua nyaraka, sawa na ukaguzi wa msimbo.

Ushirikiano unaoendelea

• Kuandaa hifadhi.
• Kuunda bomba katika TeamCity.
• Kuweka haki.
• Tafuta wamiliki wa huduma. Kuna mpango wa mseto hapa - kuashiria kwa mwongozo na otomatiki ndogo kutoka kwa PaaS. Mpango wa kiotomatiki kabisa hushindwa wakati huduma zinapohamishwa kwa usaidizi kwa timu nyingine ya usanidi au, kwa mfano, ikiwa msanidi wa huduma ataacha kufanya kazi.
• Kusajili huduma katika Atlas (tazama hapo juu). Pamoja na wamiliki wake wote na tegemezi.
• Kuangalia uhamiaji. Tunaangalia ikiwa yoyote kati yao ni hatari. Kwa mfano, katika mojawapo yao jedwali la kubadilisha au kitu kingine hujitokeza ambacho kinaweza kuvunja utangamano wa schema ya data kati ya matoleo tofauti ya huduma. Kisha uhamiaji haufanyiki, lakini umewekwa kwenye usajili - PaaS lazima ionyeshe mmiliki wa huduma wakati ni salama kuitumia.

Bika

Hatua inayofuata ni huduma za ufungaji kabla ya kupelekwa.

• Kujenga maombi. Kulingana na classics - katika picha ya Docker.
• Uzalishaji wa chati za Helm kwa huduma yenyewe na nyenzo zinazohusiana. Ikiwa ni pamoja na hifadhidata na kashe. Zinaundwa kiotomatiki kwa mujibu wa usanidi wa app.toml ambao ulitolewa katika hatua ya CLI-push.
• Kuunda tikiti kwa wasimamizi kufungua bandari (inapohitajika).
• Kuendesha majaribio ya kitengo na kuhesabu chanjo ya msimbo. Ikiwa chanjo ya msimbo iko chini ya kizingiti maalum, basi uwezekano mkubwa wa huduma haitaenda zaidi - kwa kupelekwa. Ikiwa iko kwenye hatihati ya kukubalika, basi huduma itapewa mgawo wa "kupoteza": basi, ikiwa hakuna uboreshaji wa kiashiria kwa wakati, msanidi programu atapokea arifa kwamba hakuna maendeleo katika suala la vipimo ( na kitu kinahitaji kufanywa juu yake).
• Uhasibu kwa kumbukumbu na mapungufu ya CPU. Tunaandika huduma ndogo katika Golang na kuziendesha katika Kubernetes. Kwa hivyo ujanja mmoja unaohusishwa na upekee wa lugha ya Golang: kwa msingi, wakati wa kuanza, cores zote kwenye mashine hutumiwa, ikiwa hautaweka wazi utofauti wa GOMAXPROCS, na wakati huduma kadhaa kama hizo zinazinduliwa kwenye mashine moja, huanza. kugombea rasilimali, kuingiliana. Grafu zilizo hapa chini zinaonyesha jinsi muda wa utekelezaji unavyobadilika ikiwa utaendesha programu bila ubishi na katika kinyang'anyiro cha hali ya rasilimali. (Vyanzo vya grafu ni hapa).

Wakati wa utekelezaji, chini ni bora. Upeo: 643ms, kiwango cha chini: 42ms. Picha inaweza kubofya.

Wakati wa upasuaji, chini ni bora. Upeo: 14091 ns, kiwango cha chini: 151 ns. Picha inaweza kubofya.

Katika hatua ya maandalizi ya mkusanyiko, unaweza kuweka tofauti hii kwa uwazi au unaweza kutumia maktaba automaxprocs kutoka kwa wavulana kutoka Uber.

Weka

• Kukagua mikusanyiko. Kabla ya kuanza kuwasilisha makusanyiko ya huduma kwa mazingira unayokusudia, unahitaji kuangalia yafuatayo:
- Viwango vya API.
- Utiifu wa majibu ya mwisho wa API na schema.
- Umbizo la kumbukumbu.
- Kuweka vichwa vya maombi kwa huduma (kwa sasa hii inafanywa na netramesh)
- Kuweka tokeni ya mmiliki wakati wa kutuma ujumbe kwa basi la tukio. Hii inahitajika ili kufuatilia muunganisho wa huduma kwenye basi. Unaweza kutuma data zote mbili zisizo na uwezo kwa basi, ambayo haiongezei muunganisho wa huduma (ambayo ni nzuri), na data ya biashara inayoimarisha muunganisho wa huduma (ambayo ni mbaya sana!). Na wakati muunganisho huu unakuwa suala, kuelewa ni nani anayeandika na kusoma basi husaidia kutenganisha huduma vizuri.

Hakuna mikusanyiko mingi sana huko Avito bado, lakini bwawa lao linapanuka. Kadiri makubaliano kama haya yanavyopatikana katika fomu ambayo timu inaweza kuelewa na kuelewa, ndivyo inavyokuwa rahisi kudumisha uthabiti kati ya huduma ndogo.

Vipimo vya syntetisk

• Jaribio la kitanzi lililofungwa. Kwa hili sasa tunatumia chanzo wazi Hoverfly.io. Kwanza, inarekodi mzigo halisi kwenye huduma, kisha - tu katika kitanzi kilichofungwa - inaiga.

• Upimaji wa Stress. Tunajaribu kuleta huduma zote kwa utendaji bora. Na matoleo yote ya kila huduma lazima iwe chini ya kupima mzigo - kwa njia hii tunaweza kuelewa utendaji wa sasa wa huduma na tofauti na matoleo ya awali ya huduma sawa. Ikiwa, baada ya sasisho la huduma, utendaji wake umeshuka kwa mara moja na nusu, hii ni ishara wazi kwa wamiliki wake: unahitaji kuchimba msimbo na kurekebisha hali hiyo.
Tunatumia data iliyokusanywa, kwa mfano, kutekeleza kwa usahihi kuongeza kiotomatiki na, mwishowe, kuelewa kwa ujumla jinsi huduma inavyoweza kuongezeka.

Wakati wa kupima mzigo, tunaangalia ikiwa matumizi ya rasilimali yanakidhi mipaka iliyowekwa. Na sisi kuzingatia hasa juu ya uliokithiri.

a) Tunaangalia jumla ya mzigo.
- Ndogo sana - uwezekano mkubwa kitu haifanyi kazi kabisa ikiwa mzigo unashuka ghafla mara kadhaa.
- Kubwa sana - uboreshaji unahitajika.

b) Tunaangalia cutoff kulingana na RPS.
Hapa tunaangalia tofauti kati ya toleo la sasa na la awali na jumla ya wingi. Kwa mfano, ikiwa huduma inazalisha rps 100, basi imeandikwa vibaya, au hii ni maalum yake, lakini kwa hali yoyote, hii ni sababu ya kuangalia huduma kwa karibu sana.
Ikiwa, kinyume chake, kuna RPS nyingi sana, basi labda kuna aina fulani ya mdudu na baadhi ya miisho imeacha kutekeleza upakiaji, na nyingine nyingine inasababishwa tu. return true;

Vipimo vya Canary

Baada ya kupita vipimo vya syntetisk, tunajaribu huduma ndogo kwa idadi ndogo ya watumiaji. Tunaanza kwa uangalifu, na sehemu ndogo ya hadhira iliyokusudiwa ya huduma - chini ya 0,1%. Katika hatua hii, ni muhimu sana kwamba vipimo sahihi vya kiufundi na bidhaa vijumuishwe katika ufuatiliaji ili vionyeshe tatizo kwenye huduma haraka iwezekanavyo. Wakati wa chini wa mtihani wa canary ni dakika 5, kuu ni masaa 2. Kwa huduma ngumu, tunaweka wakati kwa mikono.
Hebu tuchambue:
- vipimo vya lugha mahususi, haswa, wafanyikazi wa php-fpm;
- makosa katika Sentry;
- hali ya majibu;
- wakati wa majibu, halisi na wastani;
- kuchelewa;
- isipokuwa, kusindika na kutoshughulikiwa;
- vipimo vya bidhaa.

Finya Upimaji

Upimaji wa Finya pia huitwa upimaji wa "kubana". Jina la mbinu ilianzishwa kwenye Netflix. Kiini chake ni kwamba kwanza tunajaza mfano mmoja na trafiki halisi hadi kushindwa na hivyo kuweka kikomo chake. Kisha tunaongeza mfano mwingine na kupakia jozi hii - tena kwa kiwango cha juu; tunaona dari yao na delta na "finya" ya kwanza. Na kwa hivyo tunaunganisha mfano mmoja kwa wakati mmoja na kuhesabu muundo wa mabadiliko.
Data ya majaribio kupitia "kubana" pia hutiririka hadi kwenye hifadhidata ya kawaida ya vipimo, ambapo tunaweza kuboresha matokeo ya upakiaji wa bandia nayo, au hata kubadilisha "sanisi" nayo.

Uzalishaji

• Kuongeza. Tunapotoa huduma kwa uzalishaji, tunafuatilia jinsi inavyoongezeka. Katika uzoefu wetu, ufuatiliaji wa viashiria vya CPU pekee haufanyi kazi. Kuongeza alama kiotomatiki kwa kuweka alama kwenye RPS katika hali yake safi hufanya kazi, lakini kwa huduma fulani pekee, kama vile utiririshaji mtandaoni. Kwa hivyo tunaangalia kwanza vipimo vya bidhaa mahususi vya programu.

Kama matokeo, wakati wa kuongeza ukubwa tunachambua:
- Viashiria vya CPU na RAM,
- idadi ya maombi kwenye foleni;
- muda wa majibu,
- utabiri kulingana na data ya kihistoria iliyokusanywa.

Wakati wa kuongeza huduma, ni muhimu pia kufuatilia utegemezi wake ili tusipunguze huduma ya kwanza katika mlolongo, na wale wanaopata hushindwa chini ya mzigo. Ili kuanzisha mzigo unaokubalika kwa kundi zima la huduma, tunaangalia data ya kihistoria ya huduma tegemezi "iliyo karibu" (kulingana na mchanganyiko wa viashiria vya CPU na RAM, pamoja na vipimo mahususi vya programu) na kuzilinganisha na data ya kihistoria. ya huduma ya kuanzisha, na kadhalika katika "msururu wa utegemezi" ", kutoka juu hadi chini.

Обслуживание

Baada ya huduma ndogo kuanza kufanya kazi, tunaweza kushikamana na vichochezi kwake.

Hapa kuna hali za kawaida ambazo vichochezi hutokea.
- Uhamaji unaoweza kuwa hatari umegunduliwa.
- Sasisho za usalama zimetolewa.
- Huduma yenyewe haijasasishwa kwa muda mrefu.
— Mzigo kwenye huduma umepungua kwa kiasi kikubwa au baadhi ya vipimo vya bidhaa viko nje ya masafa ya kawaida.
- Huduma haifikii tena mahitaji mapya ya jukwaa.

Baadhi ya vichochezi vinawajibika kwa uthabiti wa operesheni, zingine - kama kazi ya matengenezo ya mfumo - kwa mfano, huduma zingine hazijatumwa kwa muda mrefu na picha yake ya msingi imekoma kupitisha ukaguzi wa usalama.

Dashibodi

Kwa kifupi, dashibodi ndio paneli dhibiti ya PaaS yetu nzima.

• Sehemu moja ya habari kuhusu huduma, na data juu ya chanjo yake ya majaribio, idadi ya picha zake, idadi ya nakala za uzalishaji, matoleo, nk.
• Zana ya kuchuja data kwa huduma na lebo (alama za mali ya vitengo vya biashara, utendaji wa bidhaa, n.k.)
• Chombo cha kuunganishwa na zana za miundombinu za ufuatiliaji, ukataji miti na ufuatiliaji.
• Sehemu moja ya nyaraka za huduma.
• Mtazamo mmoja wa matukio yote kwenye huduma.

Katika jumla ya

Kabla ya kutambulisha PaaS, msanidi programu mpya anaweza kutumia wiki kadhaa kuelewa zana zote zinazohitajika ili kuzindua huduma ndogo katika uzalishaji: Kubernetes, Helm, vipengele vyetu vya ndani vya TeamCity, kuweka miunganisho ya hifadhidata na kache kwa njia inayostahimili hitilafu, n.k. Sasa inatumika. inachukua saa kadhaa kusoma uanzishaji wa haraka na kuunda huduma yenyewe.

Nilitoa ripoti juu ya mada hii ya HighLoad++ 2018, unaweza kuitazama video и uwasilishaji.

Wimbo wa bonasi kwa wale waliosoma hadi mwisho

Sisi katika Avito tunaandaa mafunzo ya ndani ya siku tatu kwa watengenezaji kutoka Chris Richardson, mtaalam wa usanifu wa microservice. Tungependa kutoa fursa ya kushiriki kwa mmoja wa wasomaji wa chapisho hili. Hapa Mpango wa mafunzo umewekwa.

Mafunzo hayo yatafanyika kuanzia Agosti 5 hadi 7 huko Moscow. Hizi ni siku za kazi ambazo zitashughulikiwa kikamilifu. Chakula cha mchana na mafunzo vitakuwa katika ofisi yetu, na mshiriki aliyechaguliwa atalipia usafiri na malazi mwenyewe.

Unaweza kutuma maombi ya kushiriki katika fomu hii ya google. Kutoka kwako - jibu la swali kwa nini unahitaji kuhudhuria mafunzo na habari juu ya jinsi ya kuwasiliana nawe. Jibu kwa Kiingereza, kwa sababu Chris atachagua mshiriki ambaye atahudhuria mafunzo mwenyewe.
Tutatangaza jina la mshiriki wa mafunzo katika sasisho la chapisho hili na kwenye mitandao ya kijamii Avito kwa watengenezaji (AvitoTech in Facebook, Vkontakte, Twitter) kabla ya Julai 19.

Chanzo: mapenzi.com