Сәлеметсіз бе! Менің атым Вадим Мэдисон, мен Avito жүйесінің платформасын әзірлеуді басқарамын. Біз компанияда монолитті архитектурадан микросервиске қалай өтіп жатқанымыз бірнеше рет айтылды. Микросервистерден барынша пайда алу және оларда адасып қалмау үшін инфрақұрылымымызды қалай өзгерткенімізбен бөлісетін кез келді. PaaS бізге бұл жерде қалай көмектеседі, біз орналастыруды қалай жеңілдеттік және микросервисті құруды бір рет басу арқылы азайттық - оқыңыз. Төменде жазғанымның бәрі Avito-да толығымен орындалмаған, оның кейбіреулері платформамызды қалай дамытатынымыз.

(Осы мақаланың соңында мен микросервис архитектурасы бойынша сарапшы Крис Ричардсонның үш күндік семинарына қатысу мүмкіндігі туралы айтатын боламын).

Микросервистерге қалай келдік

Avito - әлемдегі ең үлкен құпия сайттардың бірі, онда күніне 15 миллионнан астам жаңа жарнамалар жарияланады. Біздің сервер секундына 20 мыңнан астам сұранысты қабылдайды. Қазіргі уақытта бізде бірнеше жүздеген микросервис бар.

Біз бірнеше жылдан бері микросервис архитектурасын құрудамыз. Дәл қалай - егжей-тегжейлі біздің әріптестер деді RIT++ 2017 бөлімінде. CodeFest 2017 (қараңыз. видео), Сергей Орлов пен Михаил Прокопчук бізге микросервистерге көшу не үшін қажет екенін және мұнда Кубернетес қандай рөл атқарғанын егжей-тегжейлі түсіндірді. Енді біз мұндай архитектураға тән масштабтау шығындарын азайту үшін бәрін жасаймыз.

Бастапқыда біз микросервистерді дамытуға және іске қосуға жан-жақты көмектесетін экожүйені жасаған жоқпыз. Олар жай ғана ақылға қонымды ашық бастапқы шешімдерді жинады, оларды үйде іске қосты және әзірлеушіні олармен жұмыс істеуге шақырды. Нәтижесінде ол ондаған жерге барды (бақылау тақталары, ішкі қызметтер), содан кейін оның кодты ескі әдіспен, монолитте кесуге деген ұмтылысы күшейе түсті. Төмендегі диаграммалардағы жасыл түс әзірлеушінің өз қолымен бір жолмен не істейтінін, ал сары түс автоматтандыруды көрсетеді.

Енді PaaS CLI утилитасында бір пәрменмен жаңа қызмет жасалады, ал жаңа дерекқор тағы екеуімен қосылып, Stage бағдарламасына орналастырылады.

«Микросервистің фрагментациясы» дәуірін қалай еңсеруге болады

Монолитті архитектурамен өнімдегі өзгерістердің дәйектілігі үшін әзірлеушілер көршілерімен не болып жатқанын анықтауға мәжбүр болды. Жаңа архитектурада жұмыс істегенде, қызмет контексттері енді бір-біріне тәуелді болмайды.

Сонымен қатар, микросервис архитектурасы тиімді болуы үшін көптеген процестерді орнату қажет, атап айтқанда:

• журналды жүргізу;
• сұранысты қадағалау (Jaeger);
• қателерді біріктіру (Sentry);
• Kubernetes күйлері, хабарлары, оқиғалары (Оқиға ағынын өңдеу);
• жарыс шегі / автоматты ажыратқыш (сіз Hystrix пайдалана аласыз);
• қызмет қосылымын бақылау (біз Netramesh қолданамыз);
• мониторинг (Графана);
• құрастыру (TeamCity);
• байланыс және хабарландыру (Slack, email);
• тапсырманы қадағалау; (Джира)
• құжаттаманы дайындау.

Жүйе өзінің тұтастығын жоғалтпауы және масштабтау кезінде тиімді болып қалуы үшін біз Avito-да микросервистерді ұйымдастыруды қайта ойластырдық.

Микросервистерді қалай басқарамыз

Көптеген Avito микросервистері арасында бірыңғай «партиялық саясатты» жүзеге асыруға келесілер көмектеседі:

• инфрақұрылымды қабаттарға бөлу;
• Платформа қызмет ретінде (PaaS) тұжырымдамасы;
• микросервистермен болатын барлық нәрсені бақылау.

Инфрақұрылымның абстракциялық қабаттары үш қабатты қамтиды. Жоғарыдан төменге қарай жүрейік.

A. Үстіңгі – қызмет көрсету торы. Алдымен біз Istio-ны қолданып көрдік, бірақ ол тым көп ресурстарды пайдаланатыны анықталды, бұл біздің көлемдер үшін тым қымбат. Сондықтан сәулет тобының аға инженері Александр Лукьянченко өзінің жеке шешімін жасады - Netramesh (Ашық бастапқы кодта қол жетімді), оны біз қазір өндірісте қолданамыз және Istio-дан бірнеше есе аз ресурстарды тұтынамыз (бірақ Istio мақтана алатын барлық нәрсені жасай бермейді).
B. Орташа – Кубернетес. Біз оған микросервистерді орналастырамыз және басқарамыз.
C. Астыңғы жағы – жалаң металл. Біз бұлттарды немесе OpenStack сияқты заттарды пайдаланбаймыз, бірақ толығымен жалаң металлға сенеміз.

Барлық қабаттар PaaS арқылы біріктірілген. Ал бұл платформа өз кезегінде үш бөліктен тұрады.

I. Генераторлар, CLI утилитасы арқылы басқарылады. Ол әзірлеушіге микросервисті дұрыс жолмен және ең аз күшпен жасауға көмектеседі.

II. Біріктірілген коллектор жалпы бақылау тақтасы арқылы барлық құралдарды басқарумен.

III. Сақтау. Маңызды әрекеттер үшін триггерлерді автоматты түрде орнататын жоспарлаушылармен қосылады. Осындай жүйенің арқасында біреу Jira-да тапсырманы орнатуды ұмытып кеткендіктен бірде-бір тапсырманы жіберіп алмайды. Ол үшін біз Atlas деп аталатын ішкі құралды қолданамыз.

Avito-да микросервистерді енгізу де бір схема бойынша жүзеге асырылады, бұл әзірлеу мен шығарудың әрбір кезеңінде оларға бақылауды жеңілдетеді.

Стандартты микросервисті әзірлеу құбыры қалай жұмыс істейді?

Жалпы, микросервис жасау тізбегі келесідей көрінеді:

CLI-push → Үздіксіз интеграция → Пісіру → Орналастыру → Жасанды сынақтар → Канар сынақтары → Қысу сынағы → Өндіріс → Техникалық қызмет көрсету.

Оны дәл осы ретпен қарастырайық.

CLI-басу

• Микросервисті құру.
Біз әр әзірлеушіге микросервистерді қалай жасау керектігін үйрету үшін ұзақ уақыт күрестік. Бұған Confluence бағдарламасында егжей-тегжейлі нұсқауларды жазу кіреді. Бірақ схемалар өзгерді және толықтырылды. Нәтиже - саяхаттың басында тығырық пайда болды: микросервистерді іске қосу үшін әлдеқайда көп уақыт қажет болды және әлі де оларды жасау кезінде проблемалар жиі туындады.

Соңында біз микросервисті жасау кезінде негізгі қадамдарды автоматтандыратын қарапайым CLI утилитасын құрастырдық. Шын мәнінде, ол бірінші git push ауыстырады. Міне, ол дәл не істейді.

— Қызметті шаблонға сәйкес жасайды — қадам бойынша, «шебер» режимінде. Бізде Avito серверінде негізгі бағдарламалау тілдеріне арналған үлгілер бар: PHP, Golang және Python.

- Бір уақытта бір пәрмен белгілі бір машинада жергілікті даму үшін ортаны орналастырады - Minikube іске қосылды, Helm диаграммалары автоматты түрде жасалады және жергілікті кубернеттерде іске қосылады.

— Қажетті дерекқорды қосады. Әзірлеушіге қажетті дерекқорға қол жеткізу үшін IP мекенжайын, логин мен құпия сөзді білу қажет емес - ол жергілікті жерде, сахнада немесе өндірісте. Сонымен қатар, дерекқор бірден қатеге төзімді конфигурацияда және теңгерімдеу арқылы орналастырылады.

— Ол тікелей құрастыруды өзі орындайды. Әзірлеуші ​​өзінің IDE арқылы микросервисте бірдеңені түзетті делік. Утилита файлдық жүйедегі өзгерістерді көреді және олардың негізінде қолданбаны қайта құрады (Голанг үшін) және қайта іске қосады. PHP үшін біз текше ішіндегі каталогты жай ғана жібереміз, сонда тікелей қайта жүктеу «автоматты түрде» алынады.

— Автотесттер жасайды. Бланкілер түрінде, бірақ пайдалану үшін өте қолайлы.

• Микросервисті қолдану.

Микросервисті қолдану бұрын біз үшін біраз жұмыс болатын. Мыналар қажет болды:

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

II. Конфигурация.
III. Штурвал диаграммасы, ол өзі ауыр және мыналарды қамтиды:

— диаграммалардың өзі;
— шаблондар;
— әртүрлі орталарды ескере отырып, нақты мәндер.

Біз Kubernetes манифесттерін қайта өңдеудің ауыртпалығын алып тастадық, сондықтан олар енді автоматты түрде жасалады. Бірақ ең бастысы, олар орналастыруды шегіне дейін жеңілдетті. Енді бізде Dockerfile бар және әзірлеуші ​​бүкіл конфигурацияны бір қысқа app.toml файлында жазады.

Иә, және app.toml ішінде бір минутқа ештеңе істеуге болмайды. Біз қызметтің қай жерде және қанша көшірмелерін шығару керектігін (әзірлеуші ​​серверде, кезеңде, өндірісте) көрсетеміз және оның тәуелділіктерін көрсетеміз. [қозғалтқыш] блогындағы сызық өлшемі = "кіші" екеніне назар аударыңыз. Бұл Kubernetes арқылы қызметке бөлінетін шек.

Содан кейін конфигурация негізінде барлық қажетті Helm диаграммалары автоматты түрде жасалады және дерекқорларға қосылымдар жасалады.

• Негізгі валидация. Мұндай тексерулер де автоматтандырылған.
Бақылау қажет:
— Dockerfile бар ма;
— app.toml бар ма;
— құжаттама бар ма?
— тәуелдiлiк ретiнде ме?
— ескерту ережелері орнатылған ба.
Соңғы нүктеге дейін: қызмет иесінің өзі қандай өнім көрсеткіштерін бақылау керектігін анықтайды.

• Құжаттаманы дайындау.
Әлі де проблемалық аймақ. Бұл ең айқын болып көрінеді, бірақ сонымен бірге бұл «жиі ұмытылатын» рекорд, сондықтан тізбектегі осал буын.
Әрбір микросервис үшін құжаттама болуы қажет. Ол келесі блоктарды қамтиды.

I. Қызметтің қысқаша сипаттамасы. Оның не істейтіні және не үшін қажет екендігі туралы бірнеше сөйлем.

II. Архитектура диаграммасының сілтемесі. Оған жылдам қарап отырып, мысалы, Redis-ті кэштеу үшін немесе тұрақты режимде негізгі деректер қоймасы ретінде пайдаланып жатқаныңызды түсіну оңай болуы маңызды. Әзірге Авитода бұл Confluence сілтемесі.

III. Runbook. Қызметті іске қосу және оны өңдеудің қыр-сырлары туралы қысқаша нұсқаулық.

IV. Жиі қойылатын сұрақтар, бұл жерде қызметпен жұмыс істеу кезінде әріптестеріңіз кездесуі мүмкін проблемаларды болжау жақсы болар еді.

V. API үшін соңғы нүктелердің сипаттамасы. Егер сіз кенеттен бағыттарды көрсетпесеңіз, микросервистері сіздікімен байланысты әріптестер бұл үшін міндетті түрде төлейді. Енді біз Swagger қолданамыз және бұл үшін brief деп аталатын шешіміміз.

VI. Жапсырмалар. Немесе қызмет қай өнімге, функционалдылыққа немесе компанияның құрылымдық бөлімшесіне жататынын көрсететін маркерлер. Олар, мысалы, әріптестеріңіз бір апта бұрын бір бизнес бөлімі үшін шығарған функционалдылықты қысқартып жатқаныңызды тез түсінуге көмектеседі.

VII. Қызметтің иесі немесе иелері. Көп жағдайда оны немесе оларды PaaS көмегімен автоматты түрде анықтауға болады, бірақ қауіпсіз болу үшін әзірлеушіден оларды қолмен көрсетуді талап етеміз.

Ақырында, кодты қарауға ұқсас құжаттаманы қарап шығудың жақсы тәжірибесі.

Үздіксіз интеграция

• Репозиторийлерді дайындау.
• TeamCity жүйесінде конвейер жасау.
• Құқықтарды орнату.
• Қызмет иелерін іздеңіз. Мұнда гибридті схема бар - қолмен белгілеу және PaaS-тен минималды автоматтандыру. Қызметтер басқа әзірлеу тобына қолдау көрсету үшін тасымалданғанда немесе, мысалы, қызметті әзірлеуші ​​​​шықса, толық автоматты схема сәтсіз болады.
• Атласта қызметті тіркеу (жоғарыдан қараңыз). Барлық иелерімен және тәуелділіктерімен.
• Тасымалдауларды тексеру. Біз олардың кез келгенінің қауіпті екенін тексереміз. Мысалы, олардың бірінде өзгерту кестесі немесе қызметтің әртүрлі нұсқалары арасындағы деректер схемасының үйлесімділігін бұзуы мүмкін басқа нәрсе пайда болады. Содан кейін тасымалдау орындалмайды, бірақ жазылымға орналастырылады - PaaS оны пайдалану қауіпсіз болғанда қызмет иесіне сигнал беруі керек.

Пісіру

Келесі кезең - орналастыру алдында орау қызметтері.

• Қолданбаны құру. Классика бойынша - Докер кескінінде.
• Қызметтің өзі және қатысты ресурстар үшін Helm диаграммаларын жасау. Соның ішінде дерекқорлар мен кэшке арналған. Олар CLI-басу кезеңінде жасалған app.toml конфигурациясына сәйкес автоматты түрде жасалады.
• Әкімшілерге порттарды ашу билеттерін жасау (қажет болған жағдайда).
• Бірлік сынақтарын орындау және кодты қамтуды есептеу. Егер кодты қамту көрсетілген шекті деңгейден төмен болса, онда қызмет одан әрі - орналастыруға дейін бармауы мүмкін. Егер ол қолайлы шегінде болса, онда қызметке «пессимизирлеу» коэффициенті тағайындалады: содан кейін уақыт өте келе индикаторда жақсарту болмаса, әзірлеуші ​​сынақтар бойынша прогресс жоқ екендігі туралы хабарлама алады ( және бұл туралы бірдеңе істеу керек).
• Жад пен процессордың шектеулерін есепке алу. Біз негізінен Голангта микросервистерді жазамыз және оларды Кубернетесте іске қосамыз. Демек, Голанг тілінің ерекшелігімен байланысты бір нәзіктік: әдепкі бойынша, іске қосу кезінде машинадағы барлық ядролар пайдаланылады, егер сіз GOMAXPROCS айнымалы мәнін нақты орнатпасаңыз және бір құрылғыда бірнеше осындай қызметтер іске қосылғанда, олар басталады. ресурстар үшін бәсекелесу, бір-біріне кедергі жасау. Төмендегі графиктер қолданбаны даусыз және ресурстар үшін жарыс режимінде іске қоссаңыз, орындау уақыты қалай өзгеретінін көрсетеді. (Графиктердің көздері осында).

Орындау уақыты, азырақ болғаны жақсы. Максималды: 643 мс, минимум: 42 мс. Фотосуретті басуға болады.

Операция уақыты аз болса, жақсырақ. Максималды: 14091 нс, минимум: 151 нс. Фотосуретті басуға болады.

Құрастыруды дайындау кезеңінде бұл айнымалы мәнді анық орнатуға немесе кітапхананы пайдалануға болады automaxprocs Uber жігіттерінен.

Орналастыру

• Конвенцияларды тексеру. Қызметтік жинақтарды жоспарланған орталарға жеткізуді бастамас бұрын, келесілерді тексеру керек:
- API соңғы нүктелері.
— API соңғы нүктелерінің жауаптарының схемаға сәйкестігі.
— Журнал пішімі.
— Қызметке сұраулар үшін тақырыптарды орнату (қазір бұл netramesh арқылы жүзеге асырылады)
— Оқиғалар шинасына хабарлама жіберу кезінде иесінің таңбалауышын орнату. Бұл автобустағы қызметтердің қосылуын бақылау үшін қажет. Сіз автобусқа идемпотентті деректерді де жібере аласыз, бұл қызметтердің қосылуын арттырмайды (бұл жақсы), және қызметтердің қосылуын күшейтетін іскери деректерді (бұл өте нашар!). Бұл қосылым мәселеге айналған кезде, автобусты кім жазып, оқитынын түсіну қызметтерді дұрыс бөлуге көмектеседі.

Авитода әлі көп конвенциялар жоқ, бірақ олардың пулы кеңейіп келеді. Ұжым түсінетін және түсінетін пішінде мұндай келісімдер неғұрлым көп болса, микросервистер арасындағы сәйкестікті сақтау соғұрлым оңайырақ болады.

Синтетикалық сынақтар

• Жабық циклды тестілеу. Ол үшін біз қазір ашық бастапқы кодты қолданамыз Hoverfly.io. Біріншіден, ол қызметке нақты жүктемені жазады, содан кейін - тек жабық циклде - ол оны эмуляциялайды.

• Стресс тестілеу. Біз барлық қызметтерді оңтайлы өнімділікке жеткізуге тырысамыз. Әр қызметтің барлық нұсқалары жүктемелік тестілеуден өтуі керек - осылайша біз қызметтің ағымдағы өнімділігін және сол қызметтің алдыңғы нұсқаларынан айырмашылығын түсіне аламыз. Егер қызметті жаңартудан кейін оның өнімділігі бір жарым есе төмендесе, бұл оның иелері үшін айқын сигнал: кодты зерттеп, жағдайды түзету керек.
Біз жиналған деректерді, мысалы, автоматты масштабтауды дұрыс енгізу үшін пайдаланамыз және соңында қызметтің қаншалықты масштабталатынын түсінеміз.

Жүктемені сынау кезінде біз ресурстарды тұтыну белгіленген шектеулерге сәйкес келетінін тексереміз. Және біз ең алдымен экстремалды жағдайларға назар аударамыз.

а) Біз жалпы жүктемені қарастырамыз.
- Тым кішкентай - жүктеме кенеттен бірнеше рет түсіп кетсе, бірдеңе мүлдем жұмыс істемеуі мүмкін.
- Тым үлкен - оңтайландыру қажет.

б) Біз RPS бойынша кесіндіні қарастырамыз.
Мұнда біз ағымдағы нұсқа мен алдыңғы нұсқа арасындағы айырмашылықты және жалпы санды қарастырамыз. Мысалы, егер қызмет 100 rps шығарса, онда ол нашар жазылған, немесе бұл оның ерекшелігі, бірақ кез келген жағдайда бұл қызметке өте мұқият қарауға себеп болады.
Егер, керісінше, тым көп RPS болса, онда қандай да бір қате бар және кейбір соңғы нүктелер пайдалы жүктемені орындауды тоқтатқан, ал басқалары жай ғана іске қосылған. return true;

Канар сынақтары

Синтетикалық сынақтардан өткеннен кейін біз микросервисті пайдаланушылардың аз санына тексереміз. Біз мұқият бастаймыз, қызметтің болжалды аудиториясының аз ғана үлесі – 0,1%-дан аз. Бұл кезеңде дұрыс техникалық және өнім көрсеткіштерін қызметте мәселені мүмкіндігінше тез көрсету үшін мониторингке қосу өте маңызды. Канариялық сынақтың ең аз уақыты - 5 минут, негізгісі - 2 сағат. Күрделі қызметтер үшін біз уақытты қолмен орнатамыз.
Талдап көрейік:
— тілге тән көрсеткіштер, атап айтқанда, php-fpm жұмысшылары;
— Сентридегі қателер;
— жауап күйлері;
— жауап беру уақыты, нақты және орташа;
— кідіріс;
— ерекше жағдайлар, өңделген және өңделмеген;
— өнім көрсеткіштері.

Қысу сынағы

Сығу сынағы «қысу» сынағы деп те аталады. Техниканың атауы Netflix-ке енгізілді. Оның мәні мынада: біз алдымен бір дананы сәтсіздікке дейін нақты трафикпен толтырамыз және осылайша оның шегін белгілейміз. Содан кейін біз басқа дананы қосамыз және осы жұпты жүктейміз - қайтадан максимумға дейін; біз олардың төбесі мен дельтасын бірінші «сығумен» көреміз. Осылайша біз бір уақытта бір дананы қосып, өзгерістер үлгісін есептейміз.
«Сығу» арқылы сынақ деректері де жалпы метрика дерекқорына түседі, онда біз олармен жасанды жүктеме нәтижелерін байытамыз немесе тіпті «синтетиканы» олармен ауыстырамыз.

Өндіріс

• Масштабтау. Қызметті өндіріске шығарған кезде біз оның масштабын бақылаймыз. Біздің тәжірибемізде тек CPU көрсеткіштерін бақылау тиімсіз. RPS бенчмаркингімен автоматты масштабтау таза түрде жұмыс істейді, бірақ тек онлайн ағын сияқты белгілі бір қызметтер үшін. Сондықтан біз алдымен қолданбаға тән өнім көрсеткіштерін қарастырамыз.

Нәтижесінде масштабтау кезінде біз талдаймыз:
- CPU және RAM көрсеткіштері,
— кезектегі сұраныстар саны,
- Жауап беру уақыты,
— жинақталған тарихи деректерге негізделген болжам.

Қызметті масштабтау кезінде оның тәуелділіктерін бақылау маңызды, осылайша біз тізбектегі бірінші қызметті масштабтамаймыз, ал ол кіретіндер жүктеме кезінде сәтсіздікке ұшырайды. Бүкіл қызметтер пулы үшін қолайлы жүктемені орнату үшін біз «ең жақын» тәуелді қызметтің тарихи деректерін қарастырамыз (процессор мен жедел жад көрсеткіштерінің комбинациясы негізінде, қолданбаға тән көрсеткіштермен біріктірілген) және оларды тарихи деректермен салыстырамыз. инициализация қызметінің және т.б. «тәуелділік тізбегі» бойынша жоғарыдан төменге дейін.

Қызмет

Микросервис іске қосылғаннан кейін біз оған триггерлерді қоса аламыз.

Міне, триггерлер пайда болатын типтік жағдайлар.
— Ықтимал қауіпті көші-қон анықталды.
— Қауіпсіздік жаңартулары шығарылды.
— Қызметтің өзі көптен бері жаңартылмаған.
— Қызметке жүктеме айтарлықтай төмендеді немесе оның кейбір өнім көрсеткіштері қалыпты ауқымнан тыс.
— Сервис енді жаңа платформа талаптарына сәйкес келмейді.

Кейбір триггерлер жұмыс тұрақтылығына жауап береді, кейбіреулері - жүйеге қызмет көрсету функциясы ретінде - мысалы, кейбір қызмет ұзақ уақыт бойы қолданылмаған және оның негізгі кескіні қауіпсіздік тексерулерінен өтуді тоқтатты.

Бақылау тақтасы

Қысқаша айтқанда, бақылау тақтасы - біздің бүкіл PaaS басқару тақтасы.

• Сервис туралы ақпараттың бірыңғай нүктесі, оның сынақтан өтуі, оның кескіндерінің саны, өндірістік көшірмелердің саны, нұсқалары және т.б.
• Деректерді қызметтер мен белгілер бойынша сүзуге арналған құрал (бизнес бөлімшелеріне жататын белгілер, өнімнің функционалдығы және т.б.)
• Бақылау, тіркеу және бақылау үшін инфрақұрылым құралдарымен біріктіру құралы.
• Қызметтік құжаттаманың бір нүктесі.
• Қызметтер бойынша барлық оқиғаларға бір көзқарас.

Барлығы

PaaS-ті енгізбес бұрын, жаңа әзірлеуші ​​бірнеше апта бойы микросервисті өндірісте іске қосу үшін қажетті барлық құралдарды түсінуге жұмсай алады: Kubernetes, Helm, біздің ішкі TeamCity мүмкіндіктеріміз, дерекқорлар мен кэштерге қателерге төзімді түрде қосылымдарды орнату және т.б. жылдам бастауды оқу және қызметтің өзін жасау үшін бірнеше сағат қажет.

Мен бұл тақырып бойынша HighLoad++ 2018 бағдарламасына есеп бердім, көре аласыздар видео и презентация.

Соңына дейін оқығандар үшін бонустық трек

Біз Avito-да әзірлеушілер үшін ішкі үш күндік тренинг ұйымдастырамыз Крис Ричардсон, микросервис архитектурасы бойынша сарапшы. Біз осы посттың оқырмандарының біріне қатысу мүмкіндігін бергіміз келеді. Бұл Тренинг бағдарламасы жарияланды.

Оқу-жаттығу 5-7 тамыз аралығында Мәскеуде өтеді. Бұл толық жұмыс істейтін жұмыс күндері. Түскі ас пен тренинг біздің кеңседе болады, ал таңдалған қатысушы жол ақысы мен тұру ақысын өзі төлейді.

Сіз қатысуға өтініш бере аласыз осы Google пішінінде. Сізден - тренингке не үшін қатысу керек деген сұраққа жауап және сізбен қалай байланысуға болатыны туралы ақпарат. Ағылшын тілінде жауап беріңіз, өйткені тренингке қатысатын қатысушыны Крис өзі таңдайды.
Тренингке қатысушының аты-жөнін осы жазбаның жаңартуында және әзірлеушілерге арналған Avito әлеуметтік желілерінде жариялаймыз (AvitoTech в. Facebook, ВКонтакте, Twitter) 19 шілдеден кешіктірмей.

Ақпарат көзі: www.habr.com