Salam! Mənim adım Vadim Madison, Avito Sistem Platformasının inkişafına rəhbərlik edirəm. Şirkətdə monolit arxitekturadan mikroservisə necə keçdiyimiz dəfələrlə deyilib. Mikroservislərdən maksimum yararlanmaq və onlarda itməmək üçün infrastrukturumuzu necə dəyişdirdiyimizi bölüşməyin vaxtıdır. PaaS burada bizə necə kömək edir, yerləşdirməni necə sadələşdirmişik və mikroservis yaradılmasını bir kliklə azaltdıq – oxuyun. Aşağıda yazdığım hər şey Avito-da tam tətbiq olunmur, bunun bir hissəsi platformamızı necə inkişaf etdirdiyimizdir.
(Və bu məqalənin sonunda mən mikroservis arxitekturası üzrə ekspert Kris Riçardsondan üç günlük seminara getmək imkanından danışacağam).
Mikroservislərə necə gəldik
Avito dünyanın ən böyük elanlarından biridir, gündə 15 milyondan çox yeni reklam dərc edir. Bizim backend saniyədə 20 mindən çox sorğu qəbul edir. İndi bir neçə yüz mikroservisimiz var.
Biz bir ildən artıqdır ki, mikroservis arxitekturası qururuq. Necə dəqiq - ətraflı həmkarlarımız RIT++ 2017-dəki bölməmizdə. CodeFest 2017-də (bax ), Sergey Orlov və Mixail Prokopçuk nə üçün ümumiyyətlə mikroservislərə keçid lazım olduğunu və Kubernetesin burada hansı rol oynadığını ətraflı izah etdilər. Yaxşı, indi belə bir arxitekturaya xas olan miqyaslama xərclərini minimuma endirmək üçün hər şeyi edirik.
Əvvəlcə biz mikroservislərin inkişafı və işə salınmasında bizə hərtərəfli kömək edəcək bir ekosistem yaratmadıq. Onlar sadəcə ağıllı açıq mənbə həlləri topladılar, onları evdə işə saldılar və tərtibatçıya onlarla məşğul olmağı təklif etdilər. Nəticədə, o, onlarla yerə getdi (iş panelləri, daxili xidmətlər), bundan sonra kodu köhnə şəkildə, monolitdə kəsmək istəyini gücləndirdi. Aşağıdakı diaqramlarda yaşıl rəng, tərtibatçının öz əlləri ilə bu və ya digər şəkildə nə etdiyini, sarı rəng isə avtomatlaşdırmanı göstərir.
İndi PaaS CLI yardım proqramında bir komanda yeni xidmət yaradır, daha ikisi isə yeni verilənlər bazası əlavə edir və onu Mərhələdə yerləşdirir.
"Mikroservis parçalanması" dövrünü necə aradan qaldırmaq olar
Monolit bir arxitektura ilə məhsuldakı dəyişikliklərin ardıcıllığı üçün tərtibatçılar qonşuları ilə nə baş verdiyini anlamağa məcbur oldular. Yeni arxitektura üzərində işləyərkən xidmət kontekstləri artıq bir-birindən asılı deyil.
Bundan əlavə, mikroservis arxitekturasının effektiv olması üçün bir çox proseslərin qurulması lazımdır, yəni:
• karotaj;
• sorğunun izlənməsi (Jaeger);
• səhvlərin toplanması (Sentry);
• Kubernetes-dən statuslar, mesajlar, hadisələr (Event Stream Processing);
• yarış limiti / elektrik açarı (siz Hystrix istifadə edə bilərsiniz);
• xidmətə qoşulma nəzarəti (biz Netramesh-dən istifadə edirik);
• monitorinq (Grafana);
• montaj (TeamCity);
• rabitə və bildiriş (Slack, email);
• tapşırıqların izlənməsi; (Jira)
• sənədlərin hazırlanması.
Sistemin bütövlüyünü itirməməsini və genişləndikcə səmərəli qalmasını təmin etmək üçün biz Avito-da mikroservislərin təşkilini yenidən düşündük.
Mikroservisləri necə idarə edirik
Avito bir çox mikroservislər arasında vahid "partiya siyasəti" həyata keçirməyə kömək edir:
- infrastrukturun təbəqələrə bölünməsi;
- Platformanın Xidmət kimi konsepsiyası (PaaS);
- mikroservislərlə baş verən hər şeyi izləmək.
İnfrastruktur abstraksiya səviyyələrinə üç qat daxildir. Gəlin yuxarıdan aşağıya gedək.
A. Üst - xidmət şəbəkəsi. Əvvəlcə Istio-nu sınadıq, lakin məlum oldu ki, o, həddən artıq çox resurs istifadə edir, bu da bizim həcmlərimiz üçün çox bahadır. Buna görə də, memarlıq qrupunun baş mühəndisi Alexander Lukyanchenko öz həllini hazırladı - (Açıq Mənbədə mövcuddur), hazırda istehsalda istifadə etdiyimiz və Istio-dan bir neçə dəfə az resurs istehlak edən (lakin Istio-nun öyünə biləcəyi hər şeyi etmir).
B. Orta - Kubernetes. Bunun üzərində biz mikroservisləri yerləşdirir və işlədirik.
C. Alt - çılpaq metal. Biz buludlardan və OpenStack kimi şeylərdən istifadə etmirik, lakin tamamilə çılpaq metal üzərində otururuq.
Bütün təbəqələr PaaS ilə birləşdirilir. Bu platforma isə öz növbəsində üç hissədən ibarətdir.
I. Generatorlar, CLI yardım proqramı vasitəsilə idarə olunur. Məhz o, tərtibatçıya düzgün şəkildə və minimum səylə mikroservis yaratmağa kömək edir.
II. Birləşdirilmiş kollektor ümumi alətlər paneli vasitəsilə bütün alətlərə nəzarət.
III. saxlama. Mənalı hərəkətlər üçün tetikleyicileri avtomatik təyin edən planlaşdırıcılarla əlaqə qurur. Belə bir sistem sayəsində kimsə Jira-da tapşırıq qoymağı unutduğuna görə heç bir tapşırıq buraxılmır. Bunun üçün biz Atlas adlı daxili alətdən istifadə edirik.
Avito-da mikroservislərin tətbiqi də tək sxem üzrə həyata keçirilir ki, bu da inkişafın və buraxılışın hər bir mərhələsində onlara nəzarəti asanlaşdırır.
Standart mikroservis inkişaf boru kəməri necə işləyir
Ümumiyyətlə, mikroservis yaratma zənciri belə görünür:
CLI-push → Davamlı İnteqrasiya → Pişirmə → Yerləşdirmə → Süni testlər → Kanar testləri → Sıxma Testi → İstehsal → Baxım.
Gəlin onu məhz bu ardıcıllıqla keçirək.
CLI-push
• Mikroservis yaradılması.
Hər bir tərtibatçıya mikroservislər yaratmağı öyrətmək üçün uzun müddət mübarizə apardıq. O cümlədən Confluence-də ətraflı təlimatlar yazdı. Lakin sxemlər dəyişdi və əlavə edildi. Nəticə - səyahətin əvvəlində darboğaz yarandı: mikroservisləri işə salmaq üçün icazə veriləndən daha çox vaxt lazım idi və hələ də onları yaratmaqda problemlər tez-tez olurdu.
Sonda biz mikroservis yaratmaq üçün əsas addımları avtomatlaşdıran sadə CLI yardım proqramını qurduq. Əslində, o, ilk git təkanını əvəz edir. Onun etdiyi şey budur.
- Şablon üzrə xidmət yaradır - addım-addım, "sehrbaz" rejimində. Avito backendində əsas proqramlaşdırma dilləri üçün şablonlarımız var: PHP, Golang və Python.
- Hər dəfə bir əmr müəyyən bir maşında yerli inkişaf üçün mühit yerləşdirir - Minikube yüksəlir, Helm diaqramları avtomatik olaraq yaradılır və yerli kubernetlərdə işləyir.
— Tələb olunan verilənlər bazasını birləşdirir. Tərtibatçı ehtiyac duyduğu verilənlər bazasına daxil olmaq üçün IP, login və şifrəni bilməlidir - ən azı yerli, ən azı Stage, ən azı istehsalda. Üstəlik, verilənlər bazası dərhal xətaya dözümlü konfiqurasiyada və balanslaşdırma ilə yerləşdirilir.
- Canlı montajı özü həyata keçirir. Deyək ki, tərtibatçı öz IDE vasitəsilə mikroservisdə nəyisə düzəltdi. Utilit fayl sistemindəki dəyişiklikləri görür və onlara əsaslanaraq tətbiqi yenidən qurur (Golang üçün) və yenidən başlayır. PHP üçün biz sadəcə olaraq qovluğu kubun içinə yönləndiririk və orada canlı yenidən yükləmə “avtomatik olaraq” əldə edilir.
- Avtotestlər yaradır. Blank şəklində, lakin olduqca istifadə edilə bilər.
• Mikroservisi yerləşdirin.
Əvvəllər bizimlə mikroservis yerləşdirmək bir az çətin idi. Məcburi tələb:
I. Doker faylı.
II. konfiqurasiya.
III. Helm-chart, özü də çətin və daxildir:
- qrafiklərin özləri;
- şablonlar;
- müxtəlif mühitləri nəzərə alan xüsusi dəyərlər.
Kubernetes manifestlərinin yenidən işlənməsinin ağrısını aradan qaldırdıq və indi onlar avtomatik yaradılıb. Ancaq ən əsası, biz yerləşdirməni limitə qədər sadələşdirdik. Bundan sonra bizdə Dockerfile var və tərtibatçı bütün konfiqurasiyanı tək qısa app.toml faylında yazır.
Bəli və app.toml-un özündə indi bir dəqiqəlik məsələ var. Xidmətin neçə nüsxəsinin haradan götürüləcəyini (dev-serverdə, quruluşda, istehsalda) təyin edirik, onun asılılıqlarını göstəririk. [mühərrik] blokunda xəttin ölçüsünə = "kiçik" olduğuna diqqət yetirin. Bu, Kubernetes vasitəsilə xidmətə ayrılacaq limitdir.
Bundan əlavə, konfiqurasiya əsasında bütün lazımi Helm-diaqramları avtomatik olaraq yaradılır və verilənlər bazası ilə əlaqə yaradılır.
• Əsas doğrulama. Belə yoxlamalar da avtomatlaşdırılıb.
İzləmək lazımdır:
- Dockerfile varmı;
- app.toml varmı;
- Sənədləşmə varmı?
— asılılıq qaydasında olub-olmaması;
— xəbərdarlıq qaydalarının müəyyən edilib-edilməməsi.
Sonuncu nöqtəyə: xidmətin sahibi özü hansı məhsul ölçülərinə nəzarət edəcəyini müəyyənləşdirir.
• Sənədlərin hazırlanması.
Hələ problemli sahədir. Bu, ən açıq görünür, lakin eyni zamanda rekord "tez-tez unudulmuş" və buna görə də zəncirdəki həssas halqadır.
Sənədlərin hər bir mikroservis üçün olması zəruridir. Bura aşağıdakı bloklar daxildir.
I. Xidmətin qısa təsviri. Nə etdiyi və nə üçün olduğu haqqında bir neçə cümlə.
II. Memarlıq diaqramına keçid. Bir baxışda, məsələn, Redis-dən keşləmə üçün və ya davamlı rejimdə əsas məlumat anbarı kimi istifadə etdiyinizi başa düşmək asan olması vacibdir. Avito-da, hələlik, bu Confluence-ə keçiddir.
III. runbook. Xidməti işə salmaq üçün qısa bələdçi və ondan istifadənin incəlikləri.
IV. Tez-tez verilən suallar, burada xidmətlə işləyərkən həmkarlarınızın qarşılaşa biləcəyi problemləri qabaqcadan görmək yaxşı olardı.
V. API son nöqtələrinin təsviri. Birdən təyinat yerlərini göstərməmisinizsə, mikroservisləri sizin xidmətinizə qoşulan həmkarlarınız bunun üçün demək olar ki, mütləq ödəyəcəklər. İndi bunun üçün Swagger-dən istifadə edirik və həllimiz brief adlanır.
VI. Etiketlər. Və ya xidmətin şirkətin hansı məhsula, funksionallığa, struktur bölməsinə aid olduğunu göstərən markerlər. Onlar, məsələn, bir həftə əvvəl həmkarlarınızın eyni biznes bölməsi üçün tətbiq etdiyi funksionallığı görüb-görmədiyinizi tez başa düşməyə kömək edir.
VII. Xidmət sahibi və ya sahibləri. Əksər hallarda, bu və ya onlar PaaS-dən istifadə etməklə avtomatik müəyyən edilə bilər, lakin sığorta üçün biz tərtibatçıdan onları əl ilə də müəyyən etməyi tələb edirik.
Nəhayət, kod araşdırmalarına bənzər sənədlərin nəzərdən keçirilməsi yaxşı təcrübədir.
Davamlı inteqrasiya
- Anbarların hazırlanması.
- TeamCity-də boru kəmərinin yaradılması.
- Hüquqların verilməsi.
- Xidmət sahiblərini axtarın. Budur hibrid sxem - əl ilə işarələmə və PaaS-dən minimal avtomatlaşdırma. Xidmətlər başqa bir inkişaf qrupunda dəstəyə ötürüldükdə və ya məsələn, xidmət tərtibatçısı işdən çıxdıqda tam avtomatik sxem uğursuz olur.
- Atlasda xidmət qeydiyyatı (yuxarıya bax). Bütün sahibləri və asılılıqları ilə.
- Miqrasiyaların yoxlanılması. Onların arasında potensial təhlükəli olanların olub olmadığını yoxlayırıq. Məsələn, onlardan birində dəyişdirmə cədvəli və ya xidmətin müxtəlif versiyaları arasında məlumat sxeminin uyğunluğunu poza biləcək başqa bir şey açılır. Sonra köçürmə həyata keçirilmir, lakin abunəyə qoyulur - PaaS, onu tətbiq etmək təhlükəsiz olduqda, xidmət sahibinə siqnal verməlidir.
Yandırın
Növbəti mərhələ yerləşdirmədən əvvəl qablaşdırma xidmətləridir.
- Tətbiq montajı. Klassiklərə görə - Docker təsvirində.
- Xidmətin özü və əlaqəli resurslar üçün Helm diaqramlarının yaradılması. Verilənlər bazası və önbellek üçün. Onlar CLI-push mərhələsində yaradılan app.toml konfiqurasiyasına uyğun olaraq avtomatik olaraq yaradılır.
- Adminlər üçün portların açılması üçün biletlərin yaradılması (lazım olduqda).
- Vahid testlərinin icrası və kodun əhatə dairəsinin hesablanması. Kodun əhatə dairəsi göstərilən həddən aşağıdırsa, çox güman ki, xidmət daha da irəli getməyəcək - yerləşdirməyə. Əgər məqbul ərəfəsindədirsə, o zaman xidmətə "pessimizasiya" əmsalı təyin ediləcək: o zaman, zamanla göstəricidə yaxşılaşma olmazsa, tərtibatçı testlər baxımından heç bir irəliləyiş olmadığı barədə bildiriş alacaq ( və bununla bağlı bir şey etmək lazımdır).
- Yaddaş və CPU məhdudiyyətlərinin uçotu. Əsasən, biz Golang-da mikroservislər yazırıq və onları Kubernetes-də işlədirik. Beləliklə, Golanq dilinin xüsusiyyəti ilə əlaqəli bir incəlik: standart olaraq, maşındakı bütün nüvələr işə salındıqda istifadə olunur, əgər siz GOMAXPROCS dəyişənini açıq şəkildə təyin etməsəniz və eyni maşında bir neçə belə xidmət işə salındıqda, onlar işə başlayır. bir-birinə müdaxilə edərək, resurslar uğrunda yarışmaq. Aşağıdakı qrafiklər proqram mübahisəsiz və resurs yarışı rejimində işlədildikdə icra müddətinin necə dəyişdiyini göstərir. (Qrafiklərin mənbələri ).
İcra müddəti, daha az daha yaxşıdır. Maksimum: 643ms, minimum: 42ms. Foto klik edilə bilər.
Əməliyyat üçün daha az vaxt daha yaxşıdır. Maksimum: 14091 ns, minimum: 151 ns. Foto klik edilə bilər.
Montajın hazırlanması mərhələsində siz bu dəyişəni açıq şəkildə təyin edə bilərsiniz və ya kitabxanadan istifadə edə bilərsiniz Uberdəki uşaqlardan.
Yerləşdirmək
• Konvensiyaların yoxlanılması. Nəzərdə tutulan mühitlərə xidmət quruluşlarını çatdırmağa başlamazdan əvvəl aşağıdakıları yoxlamaq lazımdır:
- API son nöqtələri.
— API son nöqtələrinin sxemə uyğunluğu.
- Giriş formatı.
- Xidmətə müraciətlər üçün başlıqların təyin edilməsi (indi bunu netramesh edir)
- Avtobusa (hadisə avtobusu) mesaj göndərərkən sahibi markerinin qurulması. Bu, avtobus vasitəsilə xidmətlərin əlaqəsini izləmək üçün lazımdır. Siz həm idempotent məlumatları avtobusa xidmətlərin bağlantısını artırmayan (bu yaxşıdır), həm də xidmətlərin əlaqəsini artıran biznes məlumatlarını (bu, çox pisdir!) göndərə bilərsiniz. Və bu əlaqənin problemə çevrildiyi anda avtobusu kimin yazıb oxuduğunu anlamaq xidmətləri düzgün ayırmağa kömək edir.
İndiyə qədər Avitoda çoxlu konvensiyalar yoxdur, lakin onların hovuzu genişlənir. Komanda üçün başa düşülən və əlverişli formada bu cür razılaşmalar nə qədər çox olsa, mikroservislər arasında ardıcıllığı saxlamaq bir o qədər asan olar.
Sintetik testlər
• Qapalı dövrə testi. Bunun üçün indi açıq mənbədən istifadə edirik . Birincisi, o, xidmətin real yükünü qeyd edir, sonra - yalnız qapalı dövrədə - təqlid edir.
• Stress Testi. Biz bütün xidmətləri optimal performansa çatdırmağa çalışırıq. Və hər bir xidmətin bütün versiyaları yükləmə testinə məruz qalmalıdır - beləliklə, xidmətin cari performansını və eyni xidmətin əvvəlki versiyaları ilə fərqi başa düşə bilərik. Xidmət yeniləməsindən sonra onun performansı bir yarım dəfə azalıbsa, bu, sahibləri üçün aydın bir siqnaldır: kodu qazmaq və vəziyyəti düzəltmək lazımdır.
Biz toplanmış məlumatlardan başlayırıq, məsələn, avtomatik ölçməni düzgün həyata keçirmək və sonda xidmətin nə qədər genişlənə biləcəyini başa düşmək üçün.
Yük testi zamanı biz resurs istehlakının müəyyən edilmiş limitlərə uyğun olub olmadığını yoxlayırıq. Və biz ilk növbədə ekstremallara diqqət yetiririk.
a) Ümumi yükə baxırıq.
- Çox kiçik - yük birdən-birə bir neçə dəfə düşərsə, çox güman ki, bir şey ümumiyyətlə işləmir.
- Çox böyük - optimallaşdırma tələb olunur.
b) RPS kəsilməsinə baxın.
Burada indiki versiya ilə əvvəlki versiya arasındakı fərqə və ümumi sayına baxırıq. Məsələn, xidmət 100 rps verirsə, ya zəif yazılmışdır, ya da bu onun xüsusiyyətləridir, lakin hər halda, bu xidmətə çox yaxından baxmaq üçün bir səbəbdir.
Əksinə, çox sayda RPS varsa, bəlkə də bir növ səhv və bəzi son nöqtələr faydalı yükü yerinə yetirməyi dayandırdı, ancaq bəziləri return true;
Kanareyka testləri
Sintetik testlərdən keçdikdən sonra biz mikroservisi az sayda istifadəçi üzərində işlədirik. Xidmətin nəzərdə tutulan auditoriyasının kiçik bir hissəsi ilə - 0,1% -dən az olan diqqətlə başlayırıq. Bu mərhələdə düzgün texniki və məhsul göstəricilərinin monitorinqə daxil edilməsi çox vacibdir ki, problemi xidmətdə mümkün qədər tez göstərsin. Minimum kanareyka testi müddəti 5 dəqiqə, əsası 2 saatdır. Mürəkkəb xidmətlər üçün vaxtı əl rejimində təyin edirik.
Təhlil edirik:
- dilə aid ölçülər, xüsusən də php-fpm işçiləri;
— gözətçidə səhvlər;
— cavab statusları;
— cavab müddəti (cavab vaxtı), dəqiq və orta;
- gecikmə;
- işlənən və işlənməyən istisnalar;
- məhsul göstəriciləri.
Sıxma Testi
Sıxma testinə "sıxma" testi də deyilir. Texnikanın adı Netflix-ə təqdim edildi. Onun mahiyyəti ondan ibarətdir ki, əvvəlcə bir instansiyanı uğursuz vəziyyətə real trafiklə doldururuq və bununla da onun limitini təyin edirik. Sonra başqa bir nümunə əlavə edirik və bu cütü yükləyirik - yenidən maksimuma qədər; onların tavanını və deltasını ilk sıxışdırmaqla görürük. Beləliklə, biz hər addımda bir nümunəni bağlayırıq və dəyişikliklərdəki nümunəni hesablayırıq.
"Sıxma" vasitəsilə testlər haqqında məlumatlar da ümumi ölçülər bazasına axır, burada biz ya süni yükləmənin nəticələrini onlarla zənginləşdiririk, ya da "sintetika" nı onlarla əvəz edirik.
İstehsal
• Ölçəkləmə. Xidməti istehsala yayaraq, onun necə miqyasına nəzarət edirik. Eyni zamanda, təcrübəmizə görə, yalnız CPU göstəricilərinin monitorinqi səmərəsizdir. RPS müqayisəsi ilə avtomatik miqyaslama ən təmiz formada işləyir, lakin yalnız onlayn yayım kimi müəyyən xidmətlər üçün. Beləliklə, biz ilk növbədə tətbiqə aid məhsul göstəricilərinə baxırıq.
Nəticədə, miqyaslandırarkən təhlil edirik:
- CPU və RAM göstəriciləri,
- növbədəki sorğuların sayı,
- cavab müddəti,
— toplanmış tarixi məlumatlar əsasında proqnoz.
Xidməti miqyaslandırarkən onun asılılıqlarını izləmək də vacibdir ki, biz zəncirdəki ilk xidməti miqyasına salmasın və onun daxil olduğu xidmətlər yük altında olsun. Bütün xidmət hovuzu üçün məqbul yükü müəyyən etmək üçün biz “ən yaxın” asılı xidmətin tarixi məlumatlarına baxırıq (prosessor və operativ yaddaş baxımından, proqrama xas göstəricilərlə birlikdə) və onu əvvəlki məlumatlarla müqayisə edirik. xidmətin işə salınması və s. bütün “asılılıq zənciri” boyunca yuxarıdan aşağıya.
Xidmət
Mikroservis işə salındıqdan sonra biz ona triggerləri asa bilərik.
Budur, tetikleyicilerin işlədiyi tipik vəziyyətlər.
- Potensial təhlükəli miqrasiya aşkar edildi.
- Təhlükəsizlik yeniləmələri buraxıldı.
- Xidmətin özü uzun müddətdir ki, yenilənməyib.
— Xidmətin yükü nəzərəçarpacaq dərəcədə azalıb və ya onun bəzi məhsul göstəriciləri normadan kənardır.
— Xidmət artıq platformanın yeni tələblərinə cavab vermir.
Tətiklərdən bəziləri işin sabitliyinə cavabdehdir, bəziləri - sistemə texniki xidmət funksiyası kimi - məsələn, bəzi xidmətlər uzun müddətdir yerləşdirilməyib və onun əsas görüntüsü təhlükəsizlik yoxlamalarından keçməyi dayandırıb.
İdarə paneli
Bir sözlə, idarə paneli bütün PaaS-in idarəetmə panelidir.
- Xidmət haqqında məlumatın vahid nöqtəsi, onun sınaq əhatə dairəsi, şəkillərinin sayı, istehsal nüsxələrinin sayı, versiyalar və s.
- Məlumatların xidmətlər və etiketlər (biznes bölmələrinə aid işarələr, məhsulun funksionallığı və s.)
- İzləmə, giriş, monitorinq üçün infrastruktur alətləri ilə inteqrasiya aləti.
- Xidmətlər üçün sənədlərin vahid nöqtəsi.
- Xidmətə görə bütün hadisələrə vahid baxış bucağı.
Ümumi
PaaS tətbiqindən əvvəl yeni tərtibatçı istehsalda mikroservisin işə salınması üçün lazım olan bütün alətləri başa düşmək üçün bir neçə həftə sərf edə bilərdi: Kubernetes, Helm, daxili TeamCity xüsusiyyətlərimiz, verilənlər bazası və keşlərlə xətaya dözümlü şəkildə əlaqə qurmaq, və s. İndi sürətli başlanğıcı oxumaq və xidməti özü etmək bir neçə saat çəkir.
HighLoad ++ 2018 üçün bu mövzuda hesabat hazırladım, görə bilərsiniz и .
Sona qədər oxuyanlar üçün bonus trek
Biz Avito-da tərtibatçılar üçün daxili üç günlük təlim təşkil edirik , mikroservis arxitekturası üzrə ekspert. Bu yazının oxucularından birinə orada iştirak etmək fürsəti vermək istəyirik. təlim proqramı yerləşdirilib.
Təlim avqustun 5-dən 7-dək Moskvada keçiriləcək. Bunlar tam dolu olacaq iş günləridir. Nahar və məşq ofisimizdə olacaq və səyahət və yerləşmə xərclərini seçilmiş iştirakçı özü ödəyir.
İştirak üçün müraciət edə bilərsiniz . Sizdən - niyə təlimdə iştirak etməli olduğunuz sualının cavabı və sizinlə necə əlaqə saxlamağınız barədə məlumat. İngilis dilində cavab verin, çünki təlimə gələn iştirakçını Chris özü seçəcək.
Təlim iştirakçısının adını bu yazıya yeniləmə ilə və tərtibatçılar üçün Avito sosial şəbəkələrində elan edəcəyik (AvitoTech in , , ) iyulun 19-dan gec olmayaraq.
Mənbə: www.habr.com