Hallo! Mäin Numm ass Vadim Madison, ech féieren d'Entwécklung vun der Avito System Plattform. Et gouf méi wéi eemol gesot wéi mir an der Firma vun enger monolithescher Architektur op eng Mikroservicer plënneren. Et ass Zäit ze deelen wéi mir eis Infrastruktur transforméiert hunn fir dat Bescht aus Mikroservicer ze kréien an ze verhënneren datt mir an hinnen verluer goen. Wéi PaaS eis hei hëlleft, wéi mir den Détachement vereinfacht hunn an d'Schafung vun engem Mikroservice op ee Klick reduzéiert hunn - liest weider. Net alles wat ech hei drënner schreiwen ass voll an Avito implementéiert, e puer dovun ass wéi mir eis Plattform entwéckelen.
(An um Enn vun dësem Artikel wäert ech iwwer d'Geleeënheet schwätzen fir en dräi Deeg Seminar vum Mikroservice Architektur Expert Chris Richardson deelzehuelen).
Wéi mir op Mikroservicer ukomm sinn
Avito ass ee vun de gréisste klasséiert Siten op der Welt; méi wéi 15 Milliounen nei Annoncen ginn op et pro Dag publizéiert. Eise Backend akzeptéiert méi wéi 20 Tausend Ufroe pro Sekonn. Mir hunn de Moment e puer honnert Mikroservicer.
Mir bauen eng Mikroservicearchitektur fir e puer Joer elo. Wéi genee - eis Kollegen am Detail bei eiser Rubrik um RIT++ 2017. Um CodeFest 2017 (kuckt. ), Sergey Orlov a Mikhail Prokopchuk hunn am Detail erkläert firwat mir den Iwwergank op Mikroservicer gebraucht hunn a wéi eng Roll Kubernetes hei gespillt huet. Gutt, elo maache mir alles fir d'Skaléierungskäschten ze minimiséieren, déi an esou enger Architektur inherent sinn.
Am Ufank hu mir keen Ökosystem erstallt, deen eis ëmfaassend hëllefe géif Mikroservicer z'entwéckelen an ze starten. Si hunn einfach sënnvoll Open Source Léisunge gesammelt, se doheem lancéiert an den Entwéckler invitéiert fir mat hinnen ze handelen. Als Resultat ass hien op eng Dutzend Plazen (Dashboards, intern Servicer) gaangen, duerno gouf hie méi staark a sengem Wonsch de Code op de alen Wee ze schneiden, an engem Monolith. Déi gréng Faarf an den Diagrammen hei drënner weist op wat den Entwéckler eng oder aner Manéier mat sengen Hänn mécht, an déi giel Faarf weist d'Automatisatioun un.
Elo am PaaS CLI Utility gëtt en neie Service mat engem Kommando erstallt, an eng nei Datebank gëtt mat zwee bäigefüügt an op Stage ofgesat.
Wéi d'Ära vun der "Mikroservice Fragmentatioun" ze iwwerwannen
Mat enger monolithescher Architektur, fir d'Konsistenz vun den Ännerungen am Produkt, goufen d'Entwéckler gezwongen erauszefannen, wat mat hiren Noperen lass ass. Wann Dir un der neier Architektur schafft, hänke Servicekontexter net méi vuneneen of.
Zousätzlech, fir datt eng Mikroservicearchitektur effektiv ass, musse vill Prozesser etabléiert ginn, nämlech:
• Logged;
• Ufro Tracing (Jaeger);
• Feeler Aggregatioun (Sentry);
• Statusen, Messagen, Eventer vu Kubernetes (Event Stream Processing);
• Course Limite / Circuit Breaker (Dir kënnt Hystrix benotzen);
• Kontroll vun Service Konnektivitéit (mir benotzen Netramesh);
• Iwwerwaachung (Grafana);
• Assemblée (TeamCity);
• Kommunikatioun an Notifikatioun (Slack, E-Mail);
• Aufgab Tracking; (Jira)
• Virbereedung vun Dokumentatioun.
Fir sécherzestellen datt de System seng Integritéit net verléiert an effektiv bleift wéi et skaléiert, hu mir d'Organisatioun vu Mikroservicer an Avito nei iwwerluecht.
Wéi verwalten mir Mikroservicer
Déi folgend Hëllef fir eng vereenegt "Parteipolitik" ënner villen Avito Mikroservicer ëmzesetzen:
- d'Infrastruktur an Schichten opdeelen;
- Plattform als Service (PaaS) Konzept;
- iwwerwaacht alles wat mat Mikroservicer geschitt.
Infrastrukturabstraktiounsschichten enthalen dräi Schichten. Loosst eis vun uewen no ënnen goen.
A. Top - Service Mesh gemaach. Am Ufank hu mir Istio probéiert, awer et huet sech erausgestallt datt et ze vill Ressourcen benotzt, wat ze deier ass fir eis Bänn. Dofir huet de Senior Ingenieur am Architekturteam Alexander Lukyanchenko seng eege Léisung entwéckelt - (verfügbar an der Open Source), déi mir am Moment an der Produktioun benotzen an déi e puer Mol manner Ressourcen verbrauchen wéi Istio (awer net alles mécht, vun deem Istio ka kachen).
B. Mëttel - Kubernetes. Mir deployéieren a bedreiwen Mikroservicer drop.
C. Ënnen - bare Metal. Mir benotzen keng Wolleken oder Saachen wéi OpenStack, awer vertrauen ganz op blo Metal.
All Schichten sinn duerch PaaS kombinéiert. An dës Plattform, am Tour, besteet aus dräi Deeler.
I. Generatoren, kontrolléiert iwwer e CLI Utility. Et ass hatt, deen den Entwéckler hëlleft e Mikroservice op déi richteg Manéier a mat engem Minimum vun Effort ze kreéieren.
II. Konsolidéiert Sammler mat Kontroll vun all Tools duerch e gemeinsamen Dashboard.
III. Stockage. Verbënnt mat Scheduler déi automatesch Ausléiser fir bedeitend Aktiounen setzen. Dank esou engem System gëtt keng eenzeg Aufgab verpasst just well een vergiess huet eng Aufgab am Jira opzestellen. Mir benotzen eng intern Outil genannt Atlas fir dës.
D'Ëmsetzung vu Mikroservicer an Avito gëtt och no engem eenzege Schema duerchgefouert, wat d'Kontroll iwwer si an all Etapp vun der Entwécklung a Verëffentlechung vereinfacht.
Wéi funktionnéiert eng Standard Mikroservice Entwécklung Pipeline?
Allgemeng gesäit d'Mikroservice Kreatiounskette esou aus:
CLI-Push → Kontinuéierlech Integratioun → Bake → Deploy → Kënschtlech Tester → Kanaresch Tester → Squeeze Testen → Produktioun → Ënnerhalt.
Loosst eis et genau an dëser Reiefolleg duerchgoën.
CLI-Push
• Schafen engem microservice.
Mir hu laang gekämpft fir all Entwéckler ze léieren wéi een Mikroservicer mécht. Dëst beinhalt d'Schreiwen vun detailléierte Instruktiounen am Confluence. Awer d'Schemaen geännert a goufen ergänzt. D'Resultat ass datt e Flaschenhals am Ufank vun der Rees erschéngt: et huet vill méi Zäit gedauert fir Mikroservicer ze lancéieren, an ëmmer nach Problemer entstanen während hirer Schafung.
Um Enn hu mir en einfachen CLI Utility gebaut, deen d'Basis Schrëtt automatiséiert wann Dir e Mikroservice erstellt. Tatsächlech ersetzt et den éischte Git Push. Hei ass wat si genee mécht.
- Erstellt e Service no enger Schabloun - Schrëtt fir Schrëtt, am "Wizard" Modus. Mir hunn Template fir d'Haaptprogramméierungssproochen am Avito Backend: PHP, Golang a Python.
- Ee Kommando gläichzäiteg benotzt en Ëmfeld fir lokal Entwécklung op enger spezifescher Maschinn - Minikube gëtt lancéiert, Helm Charts ginn automatesch generéiert a lancéiert an lokalen Kuberneten.
- Verbënnt déi erfuerderlech Datebank. Den Entwéckler brauch net d'IP, Login a Passwuert ze kennen fir Zougang zu der Datebank ze kréien déi hien brauch - sief et lokal, op der Bühn oder an der Produktioun. Ausserdeem gëtt d'Datebank direkt an enger Feelertolerant Konfiguratioun a mat Balance ofgesat.
- Et mécht Live Assemblée selwer. Loosst eis soen datt en Entwéckler eppes an engem Mikroservice duerch seng IDE korrigéiert huet. D'Utility gesäit Ännerungen am Dateiesystem a baséiert op hinnen, baut d'Applikatioun op (fir Golang) an nei start. Fir PHP fuerdere mir einfach den Verzeechnes am Cube weider an do gëtt Live-Reload "automatesch" kritt.
- Generéiert Autotester. A Form vun Blanken, awer ganz gëeegent fir ze benotzen.
• Microservice Détachement.
E Mikroservice z'installéieren war fréier e bëssen Aarbecht fir eis. Déi folgend waren néideg:
I. Dockerfile.
II. Config.
III. Helm Chart, déi selwer ëmständlech ass an enthält:
- d'Charts selwer;
- Schablounen;
- spezifesch Wäerter déi verschidden Ëmfeld berücksichtegen.
Mir hunn d'Péng aus der Ëmaarbechtung vu Kubernetes Manifestatiounen geholl sou datt se elo automatesch generéiert ginn. Awer am wichtegsten, si vereinfacht den Ofbau op d'Limite. Vun elo un hu mir eng Dockerfile, an den Entwéckler schreift déi ganz Configuratioun an enger eenzeger kuerzer app.toml Datei.
Jo, an an app.toml selwer gëtt et eng Minutt näischt ze maachen. Mir spezifizéieren wou a wéi vill Exemplare vum Service ze erhéijen (op dem Dev-Server, op der Inszenéierung, an der Produktioun), a weisen seng Ofhängegkeeten un. Notéiert d'Linngréisst = "kleng" am Block [Motor]. Dëst ass d'Limite déi dem Service iwwer Kubernetes zougewisen gëtt.
Dann, baséiert op der Configuratioun, ginn all déi néideg Helm Charts automatesch generéiert a Verbindunge mat den Datenbanken erstallt.
• Basis Validatioun. Esou Kontrollen sinn och automatiséiert.
Muss verfollegen:
- gëtt et eng Dockerfile;
- gëtt et app.toml;
- Gëtt et Dokumentatioun verfügbar?
- ass d'Ofhängegkeet an der Rei?
- ob Alarmregele festgeluecht goufen.
Zum leschte Punkt: de Besëtzer vum Service selwer bestëmmt wéi eng Produktmetriken ze iwwerwaachen.
• Virbereedung vun Dokumentatioun.
Nach ëmmer e Problem Beräich. Et schéngt déi offensichtlechst ze sinn, awer gläichzäiteg ass et och e Rekord "oft vergiess", an dofir e vulnérable Link an der Kette.
Et ass néideg datt et Dokumentatioun fir all Mikroservice gëtt. Et enthält déi folgend Blocks.
I. Kuerz Beschreiwung vum Service. Wuertwiertlech e puer Sätz iwwer wat et mécht a firwat et néideg ass.
II. Architekturdiagramm Link. Et ass wichteg datt mat engem schnelle Bléck et einfach ze verstoen ass, zum Beispill, ob Dir Redis fir Cache benotzt oder als Haaptdatengeschäft am persistente Modus. An Avito fir de Moment ass dëst e Link op Confluence.
III. Runbook. E kuerze Guide fir de Service unzefänken an d'Intricacies vun der Handhabung.
IV. FAQ, wou et gutt wier d'Problemer virzegoen, déi Är Kollegen bei der Aarbecht mam Service begéinen.
V. Beschreiwung vun Ennpunkte fir d'API. Wann Dir op eemol d'Destinatioune net uginn hutt, wäerte Kollegen, deenen hir Mikroservicer mat Ärem verbonne sinn, bal sécher dofir bezuelen. Elo benotze mir Swagger an eis Léisung genannt kuerz fir dëst.
VI. Etiketten. Oder Markéierer déi weisen wéi engem Produkt, Funktionalitéit oder strukturell Divisioun vun der Firma de Service gehéiert. Si hëllefen Iech séier ze verstoen, zum Beispill, ob Dir d'Funktionalitéit schneit, déi Är Kollegen virun enger Woch fir déi selwecht Geschäftsunitéit ausgerullt hunn.
VII. Besëtzer oder Besëtzer vum Service. Am meeschte Fäll kann et - oder se - automatesch mat PaaS bestëmmt ginn, awer fir op der sécherer Säit ze sinn, brauche mir den Entwéckler se manuell ze spezifizéieren.
Schlussendlech ass et eng gutt Praxis Dokumentatioun ze iwwerpréiwen, ähnlech wéi Code Iwwerpréiwung.
Kontinuitéit Integratioun
- Repositories virbereeden.
- Erstellt eng Pipeline an TeamCity.
- Astellungsrechter.
- Sich fir Service Besëtzer. Et gëtt en Hybridschema hei - manuell Marquage a minimal Automatioun vu PaaS. E voll automatesch Schema feelt wann Servicer fir Ënnerstëtzung un en anert Entwécklungsteam transferéiert ginn oder, zum Beispill, wann de Service Entwéckler ophält.
- Aschreiwen engem Service am Atlas (kuckt uewen). Mat all senge Besëtzer an Ofhängegkeeten.
- Iwwerpréift Migratiounen. Mir kontrolléieren ob eng vun hinnen potenziell geféierlech sinn. Zum Beispill, an engem vun hinnen en Ännerungstabell oder soss eppes opdaucht, deen d'Kompatibilitéit vum Dateschema tëscht verschiddene Versioune vum Service briechen kann. Da gëtt d'Migratioun net duerchgefouert, awer an engem Abonnement gesat - de PaaS muss de Servicebesëtzer signaliséieren wann et sécher ass et ze benotzen.
Bake
Déi nächst Etapp ass Verpackungsservicer virum Ofbau.
- Bau vun der Applikatioun. No de Klassiker - an engem Docker Bild.
- Generatioun vun Helm Charts fir de Service selwer a verbonne Ressourcen. Inklusiv fir Datenbanken a Cache. Si ginn automatesch am Aklang mat der app.toml Config erstallt, déi an der CLI-Push-Bühn generéiert gouf.
- Erstellt Ticketen fir Administrateuren fir Ports opzemaachen (wann néideg).
- Lafen Eenheet Tester a Berechnung Code Ofdeckung. Wann de Code Ofdeckung ënner der spezifizéierter Schwell ass, da wäert de Service héchstwahrscheinlech net méi wäit goen - zum Ofbau. Wann et op der Grenz vun akzeptabel ass, gëtt de Service e "pessimiséierende" Koeffizient zougewisen: dann, wann et keng Verbesserung am Indikator mat der Zäit ass, kritt den Entwéckler eng Notifikatioun datt et kee Fortschrëtt am Sënn vun Tester ass ( an eppes muss doriwwer gemaach ginn).
- Rechnung fir Erënnerung an CPU Aschränkungen. Mir schreiwen haaptsächlech Mikroservicer op Golang a lafen se a Kubernetes. Dofir ass eng Subtilitéit verbonne mat der Besonderheet vun der Golang Sprooch: Par défaut, beim Start, ginn all Käre vun der Maschinn benotzt, wann Dir d'GOMAXPROCS Variabel net explizit setzt, a wann e puer sou Servicer op der selwechter Maschinn lancéiert ginn, fänken se un fir Ressourcen ze konkurréiere, matenee stéieren. D'Grafiken hei ënnen weisen wéi d'Ausféierungszäit ännert wann Dir d'Applikatioun ouni Sträit leeft an an der Course fir Ressourcen Modus. (Quelle vu Grafike sinn ).
Ausféierung Zäit, manner ass besser. Maximum: 643ms, Minimum: 42ms. D'Foto ass klickbar.
Zäit fir Operatioun, manner ass besser. Maximum: 14091 ns, Minimum: 151 ns. D'Foto ass klickbar.
An der Assemblée Virbereedungsstadium kënnt Dir dës Variabel explizit setzen oder Dir kënnt d'Bibliothéik benotzen vun de Kärelen vun Uber.
Deploy
• Konventioune kontrolléieren. Ier Dir ufänkt Serviceversammlungen an Är geplangten Ëmfeld ze liwweren, musst Dir déi folgend kontrolléieren:
- API Endpunkte.
- Konformitéit vun API Endpunkte Äntwerte mam Schema.
- Log Format.
- Header setzen fir Ufroe fir de Service (aktuell gëtt dëst vun netramesh gemaach)
- De Besëtzer Token setzen wann Dir Messagen un den Eventbus schéckt. Dëst ass néideg fir d'Konnektivitéit vu Servicer iwwer de Bus ze verfolgen. Dir kënnt souwuel idempotent Daten op de Bus schécken, wat d'Konnektivitéit vu Servicer net erhéicht (wat gutt ass), a Geschäftsdaten, déi d'Konnektivitéit vu Servicer stäerken (wat ganz schlecht ass!). An um Punkt wou dës Konnektivitéit en Thema gëtt, hëlleft Versteesdemech wien de Bus schreift a liest fir d'Servicer richteg ze trennen.
Et sinn nach net ganz vill Konventioune zu Avito, awer hire Pool erweidert. Wat méi esou Ofkommes verfügbar sinn an enger Form déi d'Team kann verstoen a verstoen, wat et méi einfach ass d'Konsistenz tëscht Mikroservicer z'erhalen.
Synthetesch Tester
• Closed Loop Testen. Fir dëst benotze mir elo Open Source . Als éischt registréiert et déi richteg Belaaschtung op de Service, dann - just an enger zougemaacher Loop - emuléiert et.
• Stress Testen. Mir probéieren all Servicer op eng optimal Leeschtung ze bréngen. An all Versioune vun all Service musse Laaschttesten ënnerleien - sou kënne mir déi aktuell Leeschtung vum Service an den Ënnerscheed mat fréiere Versioune vum selwechte Service verstoen. Wann, no engem Service Update, seng Leeschtung ëm annerhallef Mol erofgaang ass, ass dat e kloert Signal fir seng Besëtzer: Dir musst an de Code graven an d'Situatioun korrigéieren.
Mir benotzen déi gesammelten Donnéeën, zum Beispill, fir d'Autoscaling korrekt ëmzesetzen an um Enn allgemeng ze verstoen wéi skalierbar de Service ass.
Wärend der Laaschtestung kontrolléiere mir ob d'Ressourceverbrauch de festgeluechte Grenzen entsprécht. A mir konzentréieren eis virun allem op Extremer.
a) Mir kucken op d'Gesamtbelaaschtung.
- Ze kleng - wahrscheinlech eppes funktionnéiert guer net wann d'Laascht op eemol e puer Mol fällt.
- Ze grouss - Optimisatioun erfuerderlech.
b) Mir kucken de Cutoff no RPS.
Hei kucke mir den Ënnerscheed tëscht der aktueller Versioun an der viregter an der GesamtQuantitéit. Zum Beispill, wann e Service 100 rps produzéiert, dann ass et entweder schlecht geschriwwen, oder dat ass seng Spezifizitéit, awer op alle Fall ass dëst e Grond fir de Service ganz no ze kucken.
Wann, am Géigendeel, et ze vill RPS sinn, da gëtt et vläicht eng Aart vu Feeler an e puer vun den Endpunkte hunn opgehalen d'Notzlaascht auszeféieren, an en aneren gëtt einfach ausgeléist return true;
Kanaresch Tester
Nodeems mir d'synthetesch Tester passéieren, testen mir de Mikroservice op eng kleng Zuel vu Benotzer. Mir fänken virsiichteg un, mat engem klengen Undeel vum geplangte Publikum vum Service - manner wéi 0,1%. Op dëser Etapp ass et ganz wichteg datt déi richteg technesch a Produkt Metriken an der Iwwerwaachung abegraff sinn, sou datt se de Problem am Service sou séier wéi méiglech weisen. D'Mindestzäit fir e Kanarentest ass 5 Minutten, den Haapt ass 2 Stonnen. Fir komplex Servicer setzen mir d'Zäit manuell.
Loosst eis analyséieren:
- Sproochspezifesch Metriken, besonnesch php-fpm Aarbechter;
- Feeler am Sentry;
- Äntwert Status;
- Äntwertzäit, genau an duerchschnëttlech;
- latency;
- Ausnahmen, veraarbecht an net behandelt;
- Produkt Metriken.
Squeeze Testen
Squeeze Testen gëtt och "Squeeze" Testen genannt. Den Numm vun der Technik gouf an Netflix agefouert. Seng Essenz ass datt mir als éischt eng Instanz mat echte Verkéier op de Punkt vum Echec fëllen an domat seng Limit setzen. Da fügen mir eng aner Instanz derbäi a lueden dëst Pair - erëm op de Maximum; mir gesinn hir Plafong an Delta mat der éischter "Squeeze". An dofir verbannen mir eng Instanz gläichzäiteg a berechnen d'Muster vun den Ännerungen.
Testdaten duerch "Squeezing" fléissen och an eng gemeinsam Metrik Datebank, wou mir entweder d'kënschtlech Belaaschtungsresultater mat hinnen beräicheren, oder souguer "Synthetik" mat hinnen ersetzen.
Produktioun
• Skaléieren. Wa mir e Service op d'Produktioun ausrollen, iwwerwaache mir wéi et skaléiert. An eiser Erfahrung ass d'Iwwerwaachung vun nëmmen CPU Indikatoren net effikass. Auto Skaléieren mat RPS Benchmarking a senger reiner Form funktionnéiert, awer nëmme fir verschidde Servicer, sou wéi Online Streaming. Also kucke mir als éischt op Applikatiounsspezifesch Produktmetriken.
Als Resultat, wa mir Skalen analyséieren:
- CPU an RAM Indikatoren,
- d'Zuel vun den Ufroen an der Schlaang,
- Äntwert Zäit,
- Prognose baséiert op cumuléierten historeschen Donnéeën.
Wann Dir e Service skaléieren, ass et och wichteg seng Ofhängegkeeten ze iwwerwaachen, sou datt mir den éischte Service an der Kette net skaléieren, an déi op en Zougang falen ënner Laascht. Fir eng akzeptabel Belaaschtung fir de ganze Pool vu Servicer z'etabléieren, kucke mir d'historesch Donnéeën vum "noosten" ofhängege Service (baséiert op enger Kombinatioun vun CPU an RAM Indikatoren, gekoppelt mat appspezifesche Metriken) a vergläichen se mat den historeschen Donnéeën vum Initialiséiere Service, a sou weider duerch d'ganz "Ofhängegkeetskette", vun uewe bis ënnen.
Service
Nodeems de Mikrodéngscht a Betrib geholl ass, kënne mir Ausléiser derbäi befestigen.
Hei sinn typesch Situatiounen an deenen Ausléiser optrieden.
- Potenziell geféierlech Migratiounen entdeckt.
- Sécherheetsupdates goufen verëffentlecht.
- De Service selwer ass fir eng laang Zäit net aktualiséiert ginn.
- D'Laascht op de Service ass merkbar erofgaang oder e puer vu senge Produktmetriken sinn ausserhalb vum normale Beräich.
- De Service entsprécht net méi den neie Plattformfuerderunge.
E puer vun den Ausléiser si verantwortlech fir d'Stabilitéit vun der Operatioun, e puer - als Funktioun vum Systemerhaltung - zum Beispill, e puer Service ass net laang agesat ginn a säi Basisbild huet opgehalen Sécherheetskontrollen ze passéieren.
Dashboard
Kuerz gesot, den Dashboard ass d'Kontrollpanel vun eisem ganze PaaS.
- Een eenzegen Informatiounspunkt iwwer de Service, mat Daten iwwer seng Testofdeckung, d'Zuel vu senge Biller, d'Zuel vun de Produktiounskopien, Versiounen, asw.
- En Tool fir Daten no Servicer an Etiketten ze filteren (Markéierer fir zu Geschäftsunitéiten ze gehéieren, Produktfunktionalitéit, asw.)
- En Tool fir Integratioun mat Infrastruktur Tools fir Tracing, Logging an Iwwerwaachung.
- Eng eenzeg Punkt vum Service Dokumentatioun.
- Eng eenzeg Siicht vun all Evenementer iwwer Servicer.
Total
Ier en PaaS agefouert huet, kéint en neien Entwéckler e puer Woche verbréngen fir all Tools ze verstoen déi néideg sinn fir e Mikroservice an der Produktioun ze lancéieren: Kubernetes, Helm, eis intern TeamCity Features, Verbindunge mat Datenbanken a Cache op eng Feelertolerant Manéier opzestellen, asw. dauert e puer Stonnen fir de Quickstart ze liesen an de Service selwer ze kreéieren.
Ech hunn e Bericht iwwer dëst Thema fir HighLoad ++ 2018 ginn, Dir kënnt et kucken и .
Bonus Streck fir déi, déi bis Enn liesen
Mir bei Avito organiséieren eng intern dräi-Dag Training fir Entwéckler aus , en Expert an der Mikroservicearchitektur. Mir géifen gären engem vun de Lieser vun dësem Post d'Méiglechkeet ginn fir matzemaachen. Den Trainingsprogramm gouf gepost.
Den Training fënnt vum 5. bis de 7. August zu Moskau statt. Dëst sinn Aarbechtsdeeg déi voll besat sinn. Mëttegiessen an Training wäerten an eisem Büro sinn, an de gewielte Participant bezuele selwer Rees an Ënnerkunft.
Dir kënnt fir Participatioun ufroen . Vun Iech - d'Äntwert op d'Fro firwat Dir un der Formatioun deelhuelen muss an Informatiounen iwwert wéi Dir Kontakt. Äntwert op englesch, well de Chris wielt de Participant dee selwer an d'Formatioun deelhëlt.
Mir wäerten den Numm vum Trainingsparticipant an engem Update op dësem Post an op sozialen Netzwierker annoncéieren Avito fir Entwéckler (AvitoTech an , , ) spéitstens den 19. Juli.
Source: will.com