Habr ŝanĝas la mondon. Ni blogas jam pli ol unu jaron. Antaŭ proksimume ses monatoj, ni ricevis tute logikan reagon de Khabrovites: „Dodo, vi diras ĉie, ke vi havas vian propran sistemon. Kaj kio estas ĉi tiu sistemo? Kaj kial picĉeno bezonas ĝin?
Ni sidis, pensis kaj konstatis, ke vi pravas. Ni provas klarigi ĉion sur niaj fingroj, sed ĝi eliras en ŝiritaj pecoj kaj nenie estas kompleta priskribo de la sistemo. Tiel komenciĝis longa vojaĝo de kolektado de informoj, serĉado de aŭtoroj kaj verkado de serio da artikoloj pri Dodo IS. Ni iru!
Dankon: Dankon pro dividi viajn komentojn kun ni. Dank' al li, ni finfine priskribis la sistemon, kompilis teknikan radaron kaj baldaŭ disvolvos grandan priskribon de niaj procezoj. Sen vi, ni sidus tie ankoraŭ 5 jarojn.
Serio de artikoloj "Kio estas Dodo IS?" rakontas pri:
- Frua monolito en Dodo IS (2011-2015). (En progreso...)
- La malantaŭa oficejo vojo: apartaj bazoj kaj buso. (vi estas ĉi tie)
- La klienta flanka vojo: fasado super la bazo (2016-2017). (En progreso...)
- La historio de realaj mikroservoj. (2018-2019). (En progreso...)
- Finita segado de la monolito kaj stabiligo de la arkitekturo. (En progreso...)
Se vi interesiĝas scii ion alian - skribu en la komentoj.
Opinio pri la kronologia priskribo de la aŭtoro
Mi regule okazigas kunvenon por novaj dungitoj pri la temo "Sistema Arkitekturo". Ni nomas ĝin "Enkonduko al Dodo IS Architecture" kaj ĝi estas parto de la eniĝa procezo por novaj programistoj. Rakontante en unu aŭ alia formo pri nia arkitekturo, pri ĝiaj trajtoj, mi naskiĝis certan historian aliron al la priskribo.
Tradicie, ni rigardas la sistemon kiel aron de komponantoj (teknikaj aŭ pli altnivelaj), komercaj moduloj, kiuj interagas unu kun la alia por atingi iun celon. Kaj se tia vidpunkto estas pravigita por dezajno, tiam ĝi ne estas tute taŭga por priskribo kaj kompreno. Estas pluraj kialoj ĉi tie:
- Realo estas malsama ol kio estas surpapere. Ne ĉio funkcias kiel planite. Kaj ni interesiĝas pri kiel ĝi efektive rezultis kaj funkcias.
- Konsekvenca prezento de informoj. Fakte, oni povas iri kronologie de la komenco al la nuna stato.
- De simpla al kompleksa. Ne universale, sed en nia kazo ĝi estas. La arkitekturo moviĝis de pli simplaj aliroj al pli kompleksaj. Ofte per komplikaĵo, problemoj de efektiviga rapideco kaj stabileco estis solvitaj, same kiel dekoj da aliaj propraĵoj el la listo de nefunkciaj postuloj ( bone dirite pri kontrasto de komplekseco kun aliaj postuloj).
En 2011, la Dodo IS-arkitekturo aspektis jene:
Ĝis 2020, ĝi fariĝis iom pli komplika kaj fariĝis tiel:
Kiel okazis ĉi tiu evoluo? Kial necesas malsamaj partoj de la sistemo? Kiuj arkitekturaj decidoj estis faritaj kaj kial? Ni eksciu en ĉi tiu serio de artikoloj.
La unuaj problemoj de 2016: kial servoj forlasu la monoliton
La unuaj artikoloj de la ciklo temas pri la servoj, kiuj unue disiĝis de la monolito. Por meti vin en kuntekston, mi diros al vi kiajn problemojn ni havis en la sistemo komence de 2016, ke ni devis trakti la apartigon de servoj.
Ununura MySql-datumbazo, en kiu ĉiuj aplikaĵoj, kiuj ekzistis tiutempe en Dodo IS, skribis siajn rekordojn. La konsekvencoj estis:
- Peza ŝarĝo (kun 85% de petoj kalkulitaj por legado).
- La bazo kreskis. Pro tio, ĝia kosto kaj subteno fariĝis problemo.
- Ununura punkto de fiasko. Se unu aplikaĵo skribanta al la datumbazo subite komencis fari ĝin pli aktive, tiam aliaj aplikaĵoj sentis ĝin sur si mem.
- Neefikeco en stokado kaj demandoj. Ofte la datumoj estis konservitaj en iu strukturo kiu estis oportuna por iuj scenaroj sed ne taŭga por aliaj. Indeksoj akcelas iujn operaciojn, sed povas malrapidigi aliajn.
- Kelkaj el la problemoj estis forigitaj per haste faritaj kaŝmemoroj kaj leg-replikoj al la bazoj (ĉi tio estos aparta artikolo), sed ili nur permesis al ili gajni tempon kaj ne fundamente solvis la problemon.
La problemo estis la ĉeesto de la monolito mem. La konsekvencoj estis:
- Unuopaj kaj maloftaj eldonoj.
- Malfacileco en komuna disvolviĝo de granda nombro da homoj.
- Nekapablo alporti novajn teknologiojn, novajn kadrojn kaj bibliotekojn.
Problemoj kun la bazo kaj la monolito estis priskribitaj multfoje, ekzemple, en la kunteksto de kraŝoj komence de 2018 (, и ), do mi ne tro loĝos. Mi nur diru, ke ni volis doni pli da fleksebleco dum disvolvado de servoj. Antaŭ ĉio, ĉi tio koncernis tiujn, kiuj estis la plej ŝarĝitaj kaj enradikigitaj en la tuta sistemo - Aŭto kaj Spurilo.
La Back Office Vojo: Apartaj Bazoj kaj Buso
Ĉapitronavigado
Monolitskemo 2016
Jen la ĉefaj blokoj de la monolito Dodo IS 2016, kaj ĝuste sube estas transskribo de iliaj ĉefaj taskoj.
Kasisto Livero. Kontado por kurieroj, eldonado de mendoj al kurieroj.
Kontaktocentro. Akcepto de mendoj per la telefonisto.
ejo. Niaj retejoj (dodopizza.ru, dodopizza.co.uk, dodopizza.by, ktp.).
Aŭtomata. Servo de rajtigo kaj aŭtentikigo por la malantaŭa oficejo.
spuristo. Mendo spurilo en la kuirejo. Servo por markado de pretaj statusoj dum preparado de mendo.
Kaso de la Restoracio. Preni mendojn en restoracio, kasisto interfacoj.
eksportado. Alŝuto de raportoj en 1C por kontado.
Sciigoj kaj fakturoj. Voĉaj komandoj en la kuirejo (ekzemple, "Nova pico alvenis") + fakturpreso por kurieroj.
Shift Manager. Interfacoj por la laboro de la deĵorestro: listo de mendoj, agado-grafikoj, translokigo de dungitoj al la deĵoro.
Oficeja Direktisto. Interfacoj por la laboro de la koncesiulo kaj la administranto: akcepto de dungitoj, raportoj pri la laboro de la picejo.
Restoracio Poenttabulo. Menua ekrano sur televidiloj en picejoj.
admin. Agordoj en specifa picejo: menuo, prezoj, kontado, reklamaj kodoj, reklamoj, retpaĝaj standardoj ktp.
Persona Konto de Dungito. Laborhoraroj de dungitoj, informoj pri dungitoj.
Kuireja Motivada Estraro. Aparta ekrano, kiu pendas en la kuirejo kaj montras la rapidecon de la picistoj.
komunikado. Sendante sms kaj retpoŝton.
FileStorage. Propra servo por ricevi kaj elsendi statikajn dosierojn.
La unuaj provoj solvi la problemojn helpis nin, sed ili estis nur provizora ripozo. Ili ne fariĝis sistemaj solvoj, do estis klare, ke io devas esti farita kun la bazoj. Ekzemple, dividi la ĝeneralan datumbazon en plurajn pli specialecajn.
Komencante Malŝarĝi la Monoliton: Aŭtentigo kaj Spurilo-Disigo
La ĉefaj servoj, kiuj tiam registris kaj legis el la datumbazo pli ol aliaj:
- Aŭt. Servo de rajtigo kaj aŭtentikigo por la malantaŭa oficejo.
- Spuristo. Mendo spurilo en la kuirejo. Servo por markado de pretaj statusoj dum preparado de mendo.
Kion faras Auth?
Auth estas servo per kiu uzantoj ensalutas al la malantaŭa oficejo (estas aparta sendependa enirejo ĉe la klientflanko). Oni ankaŭ postulas en la peto certigi, ke la postulataj alirrajtoj ĉeestas kaj ke ĉi tiuj rajtoj ne ŝanĝiĝis ekde la lasta ensaluto. Tra ĝi, aparatoj eniras la picejon.
Ekzemple, ni volas malfermi ekranon kun la statoj de finitaj mendoj sur la televidilo pendanta en la halo. Tiam ni malfermas auth.dodopizza.ru, elektas "Ensalutu kiel aparato", aperas kodo, kiu povas esti enigita en speciala paĝo en la komputilo de la deĵormanaĝero, indikante la tipon de aparato (aparato). La televidilo mem ŝanĝos al la dezirata interfaco de sia picejo kaj komencos montri la nomojn de klientoj, kies mendoj estas pretaj tie.
De kie estas la ŝarĝoj?
Ĉiu ensalutinta uzanto de la back office iras al la datumbazo, al la uzanttabelo por ĉiu peto, eltiras la uzanton per sql-demando kaj kontrolas ĉu li havas la necesajn aliron kaj rajtojn al ĉi tiu paĝo.
Ĉiu el la aparatoj faras la samon nur kun la aparato-tabelo, kontrolante ĝian rolon kaj ĝian aliron. Granda nombro da petoj al la majstra datumbazo kondukas al ĝia ŝarĝo kaj la malŝparo de rimedoj de la komuna datumbazo por ĉi tiuj operacioj.
Malŝarĝo de Aŭto
Auth havas izolitan domajnon, tio estas, datumoj pri uzantoj, ensalutoj aŭ aparatoj eniras la servon (provizore) kaj restas tie. Se iu bezonas ilin, tiam li iros al ĉi tiu servo por datumoj.
ESTIS. La origina skemo de laboro estis kiel sekvas:
Mi ŝatus klarigi iomete kiel ĝi funkciis:
- Peto de ekstere venas al la backend (estas Asp.Net MVC), kunportas kunsigan kuketon, kiu estas uzata por ricevi sesiajn datumojn de Redis(1). Ĝi aŭ enhavas informojn pri aliroj, kaj tiam aliro al la regilo estas malfermita (3,4), aŭ ne.
- Se ne ekzistas aliro, vi devas trairi la rajtigan proceduron. Ĉi tie, por simpleco, ĝi estas montrita kiel parto de la vojo en la sama atributo, kvankam ĝi estas transiro al la ensaluta paĝo. En la kazo de pozitiva scenaro, ni ricevos ĝuste finitan sesion kaj iros al la Backoffice-Regilo.
- Se estas datumoj, tiam vi devas kontroli ĝin por graveco en la uzantdatumbazo. Ĉu lia rolo ŝanĝiĝis, ĉu li nun ne rajtas sur la paĝon? En ĉi tiu kazo, post ricevi la seancon (1), vi devas iri rekte al la datumbazo kaj kontroli la aliron de la uzanto per la aŭtentikiga logika tavolo (2). Poste, ĉu al la ensalutpaĝo, aŭ iru al la regilo. Tia simpla sistemo, sed ne tute norma.
- Se ĉiuj proceduroj estas trapasitaj, tiam ni saltas plu en la logiko en regiloj kaj metodoj.
Uzantdatenoj estas apartigitaj de ĉiuj aliaj datumoj, ĝi estas konservita en aparta membrotabelo, funkcioj de la AuthService-logika tavolo povas bone iĝi api-metodoj. Domajnaj limoj estas sufiĉe klare difinitaj: uzantoj, iliaj roloj, alirdatumoj, doni kaj nuligi aliron. Ĉio aspektas tiel, ke ĝi povas esti elprenita en aparta servo.
IĜI. Do ili faris:
Ĉi tiu aliro havas kelkajn problemojn. Ekzemple, voki metodon ene de procezo ne estas la sama kiel voki eksteran servon per http. Latencia, fidindeco, konservebleco, travidebleco de la operacio estas tute malsamaj. Andrey Morevskiy parolis pli detale pri tiaj problemoj en sia raporto. .
La aŭtentikiga servo kaj, kun ĝi, la aparato-servo estas uzataj por la back office, tio estas, por servoj kaj interfacoj uzataj en produktado. Aŭtentikigo por klientservoj (kiel retejo aŭ poŝtelefona aplikaĵo) okazas aparte sen uzado de Auth. La disiĝo daŭris ĉirkaŭ unu jaron, kaj nun ni denove traktas ĉi tiun temon, transdonante la sistemon al novaj aŭtentigaj servoj (kun normaj protokoloj).
Kial la disiĝo daŭris tiel longe?
Estis multaj problemoj survoje, kiuj malrapidigis nin:
- Ni volis movi datumojn pri uzantoj, aparatoj kaj aŭtentikigadoj de landaj specifaj datumbazoj en unu. Por fari tion, ni devis traduki ĉiujn tabelojn kaj uzadon de la int-identigilo al la tutmonda UUId-identigilo (lastatempe relaboris ĉi tiun kodon kaj malfermfonteca projekto ). Stoki uzantajn datumojn (ĉar ĝi estas personaj informoj) havas siajn limojn kaj por iuj landoj necesas konservi ilin aparte. Sed la tutmonda identigilo de la uzanto devas esti.
- Multaj tabeloj en la datumbazo havas reviziajn informojn pri la uzanto kiu faris la operacion. Ĉi tio postulis plian mekanismon por konsistenco.
- Post la kreado de api-servoj, estis longa kaj laŭgrada periodo de transiro al alia sistemo. Ŝanĝado devis esti senjunta por uzantoj kaj postulis manan laboron.
Skemo de registrado de aparato en picejo:
Ĝenerala arkitekturo post la eltiro de Auth kaj Devices-servo:
Примечание. Por 2020, ni laboras pri nova versio de Auth, kiu baziĝas sur la rajtiga normo OAuth 2.0. Ĉi tiu normo estas sufiĉe kompleksa, sed ĝi estas utila por evoluigi trapasan aŭtentikigservon. En la artikolo "» Ni Aleksej Ĉernjaev provis rakonti pri la normo kiel eble plej simple kaj klare, por ke vi ŝparu tempon por studi ĝin.
Kion faras Spuristo?
Nun pri la dua el la ŝarĝitaj servoj. La spuristo plenumas duoblan rolon:
- Unuflanke, ĝia tasko estas montri al la dungitoj en la kuirejo, kiaj mendoj estas nuntempe en laboro, kiaj produktoj devas esti kuiritaj nun.
- Aliflanke, ciferecigi ĉiujn procezojn en la kuirejo.
Kiam nova produkto aperas en ordo (ekzemple pico), ĝi iras al la Rolling out tracker-stacio. En ĉi tiu stacio, estas picofaristo, kiu prenas bulkon de la bezonata grandeco kaj elrulas ĝin, post kio li notas sur la spurilo-tabulo, ke li plenumis sian taskon kaj transdonas la rulitan paston bazon al la sekva stacio - "Inicado". .
Tie, la sekva picisto plenigas la picon, poste notas sur la tablojdo, ke li plenumis sian taskon kaj metas la picon en la fornon (tio estas ankaŭ aparta stacio, kiu devas esti notita sur la tablojdo). Tia sistemo estis de la komenco mem en Dodo kaj de la komenco mem de la ekzisto de Dodo IS. Ĝi permesas vin plene spuri kaj ciferecigi ĉiujn transakciojn. Krome, la spuristo sugestas kiel kuiri apartan produkton, gvidas ĉiun specon de produkto laŭ ĝiaj fabrikaj skemoj, konservas la optimuman kuirtempon por la produkto kaj spuras ĉiujn operaciojn sur la produkto.
Tiel aspektas la ekrano de la tablojdo ĉe la stacio de la spuristo "Raskatka"
De kie estas la ŝarĝoj?
Ĉiu el la picejoj havas ĉirkaŭ kvin tabuletojn kun spurilo. En 2016, ni havis pli ol 100 picejojn (kaj nun pli ol 600). Ĉiu el la tabeloj faras peton al la backend unufoje ĉiujn 10 sekundojn kaj skrapas datumojn de la mendotabelo (konekto kun la kliento kaj adreso), menda komponado (konekto kun la produkto kaj indiko de la kvanto), la motiva kontada tabelo (la tempo de premado estas spurita en ĝi). Kiam picfabrikisto klakas sur produkto sur la spurilo, la enskriboj en ĉiuj ĉi tiuj tabeloj estas ĝisdatigitaj. La mendotabelo estas ĝenerala, ĝi ankaŭ enhavas enmetojn kiam oni akceptas mendon, ĝisdatigojn de aliaj partoj de la sistemo kaj multajn legaĵojn, ekzemple sur televidilo, kiu pendas en picejo kaj montras finitajn mendojn al klientoj.
Dum la periodo de lukto kun ŝarĝoj, kiam ĉio kaj ĉio estis kaŝita kaj translokigita al la nesinkrona kopio de la bazo, ĉi tiuj operacioj kun la spurilo daŭre iris al la majstra bazo. Ne devus esti ia malfruo, la datumoj estu ĝisdatigitaj, malsinkronigita estas neakceptebla.
Ankaŭ, la manko de propraj tabeloj kaj indeksoj sur ili ne permesis skribi pli specifajn demandojn adaptitajn por ilia uzo. Ekzemple, povus esti efika por spuristo havi indekson por picejo sur menda tablo. Ni ĉiam forigas picajn mendojn de la spura datumbazo. Samtempe, por ricevi mendon, ne tiom gravas, en kiu picejo ĝi falas, pli gravas, kiu kliento faris ĉi tiun mendon. Kaj signifas tie la indekso sur la kliento estas necesa. Ankaŭ ne necesas, ke la spuristo stoku la identigilon de la presita kvitanco aŭ bonus-promocioj asociitaj kun la ordo en la mendotabelo. Ĉi tiu informo ne interesas nia spurista servo. En komuna monolita datumbazo, tabeloj povus nur esti kompromiso inter ĉiuj uzantoj. Ĉi tio estis unu el la originaj problemoj.
ESTIS. La origina arkitekturo estis:
Eĉ post estado apartigita en apartajn procezojn, la plej granda parto de la kodbazo restis ofta por malsamaj servoj. Ĉio sub la regiloj estis ununura kaj vivis en la sama deponejo. Ni uzis komunajn metodojn de servoj, deponejojn, komunan bazon, en kiu kuŝis komunaj tabloj.
Malŝarĝante Spurilon
La ĉefa problemo kun la spurilo estas, ke la datumoj devas esti sinkronigitaj inter malsamaj datumbazoj. Ĉi tio ankaŭ estas ĝia ĉefa diferenco de la disiĝo de la Auth-servo, la ordo kaj ĝia stato povas ŝanĝiĝi kaj devus esti montritaj en malsamaj servoj.
Ni akceptas mendon ĉe la Kaso de la Restoracio (ĉi tio estas servo), ĝi estas konservita en la datumbazo en la stato "Akceptita". Post tio, li devus atingi la spurilon, kie li ŝanĝos sian statuson plurfoje: de "Kuirejo" al "Pakita". Samtempe, iuj eksteraj influoj de la Kasisto aŭ la Shift Manager interfaco povas okazi kun la mendo. Mi donos la ordonstatusojn kun ilia priskribo en la tabelo:
La skemo por ŝanĝi ordostatusojn aspektas jene:
Statusoj ŝanĝiĝas inter malsamaj sistemoj. Kaj ĉi tie la spurilo ne estas fina sistemo, en kiu la datumoj estas fermitaj. Ni vidis plurajn eblajn alirojn por dispartigo en tia kazo:
- Ni koncentras ĉiujn ordonajn agojn en unu servo. En nia kazo, ĉi tiu opcio postulas tro da servo por labori kun la mendo. Se ni haltus ĉe ĝi, ni ricevus la duan monoliton. Ni ne solvus la problemon.
- Unu sistemo vokas al alia. La dua opcio jam estas pli interesa. Sed kun ĝi, ĉenoj de vokoj estas eblaj (), la konektebleco de la komponantoj estas pli alta, ĝi estas pli malfacile administrebla.
- Ni organizas eventojn, kaj ĉiu servo komunikas kun alia per ĉi tiuj eventoj. Kiel rezulto, ĝi estis la tria opcio, kiu estis elektita, laŭ kiu ĉiuj servoj komencas interŝanĝi eventojn inter si.
La fakto, ke ni elektis la trian opcion signifis, ke la spuristo havus sian propran datumbazon, kaj por ĉiu ŝanĝo en la ordo, ĝi sendus eventon pri tio, al kiu aliaj servoj abonas kaj kiu ankaŭ falas en la majstran datumbazon. Por fari tion, ni bezonis iun servon, kiu certigus la liveron de mesaĝoj inter servoj.
En tiu tempo, ni jam havis RabbitMQ en la stako, tial la fina decido uzi ĝin kiel mesaĝmakleristo. La diagramo montras la transiron de mendo de la Restoracia Kasisto tra la Spurilo, kie ĝi ŝanĝas sian statuson kaj sian ekranon sur la Interfaco de Mendoj de la Administranto. IĜI:
Ordu vojon paŝon post paŝo
La ordvojo komenciĝas ĉe unu el la mendfontaj servoj. Jen la Kasisto de la Restoracio:
- Ĉe la kaso, la mendo estas tute preta, kaj estas tempo sendi ĝin al la spuristo. La evento al kiu la spuristo estas abonita estas ĵetita.
- La spuristo, akceptante mendon por si mem, konservas ĝin al sia propra datumbazo, farante la eventon "Ordo Akceptita de Spuristo" kaj sendante ĝin al RMQ.
- Estas pluraj pritraktantoj jam abonitaj al la eventa buso per mendo. Por ni gravas tiu, kiu faras sinkronigon kun monolita bazo.
- La prizorganto ricevas eventon, elektas el ĝi datumojn signifajn por ĝi: en nia kazo, ĉi tio estas la stato de la ordo "Akceptita de la Spuristo" kaj ĝisdatigas sian mendan enton en la ĉefa datumbazo.
Se iu bezonas mendon el la monolitaj tablomendoj, tiam vi povas legi ĝin ankaŭ de tie. Ekzemple, la Interfaco de Ordoj en la Ŝanĝmanaĝero bezonas ĉi tion:
Ĉiuj aliaj servoj ankaŭ povas aboni por mendi eventojn de la spurilo por uzi ilin por si mem.
Se post iom da tempo la mendo funkcias, tiam ĝia stato unue ŝanĝiĝas en sia datumbazo (Tracker-datumbazo), kaj tiam la evento "OrderIn Progress" tuj generiĝas. Ĝi ankaŭ eniras RMQ, de kie ĝi estas sinkronigita en monolita datumbazo kaj liverita al aliaj servoj. Povas esti diversaj problemoj survoje, pli da detaloj pri ili troveblas en la raporto de Zhenya Peshkov .
Fina arkitekturo post ŝanĝoj en Auth kaj Tracker
Resumante la mezan rezulton: Komence, mi havis la ideon paki la naŭjaran historion de la sistemo Dodo IS en unu artikolon. Mi volis rapide kaj simple paroli pri la etapoj de evoluado. Tamen, sidiĝante por la materialo, mi konstatis, ke ĉio estas multe pli komplika kaj interesa ol ŝajnas.
Pripensante la avantaĝojn (aŭ ties mankon) de tia materialo, mi alvenis al la konkludo, ke daŭra evoluo estas neebla sen plenrajtaj analoj de eventoj, detalaj retrospektivoj kaj analizo de miaj pasintaj decidoj.
Mi esperas, ke estis utile kaj interese por vi lerni pri nia vojo. Nun mi alfrontas elekton, kiun parton de la sistemo Dodo IS priskribi en la sekva artikolo: skribu en la komentoj aŭ voĉdoni.
Nur registritaj uzantoj povas partopreni la enketon. , bonvolu.
Pri kiu parto de Dodo IS vi ŝatus scii en la sekva artikolo?
-
24,1%Frua monolito en Dodo IS (2011-2015)14
-
24,1%Unuaj problemoj kaj iliaj solvoj (2015-2016)14
-
20,7%La klientflanka vojo: fasado super bazo (2016-2017)12
-
36,2%La historio de realaj mikroservoj (2018-2019)21
-
44,8%Kompleta segado de la monolito kaj stabiligo de la arkitekturo26
-
29,3%Pri pluaj planoj por la disvolviĝo de la sistemo17
-
19,0%Mi volas nenion scii pri Dodo IS11
58 uzantoj voĉdonis. 6 uzantoj sindetenis.
fonto: www.habr.com