Mihhail Salosin. Golang Meetup. Go kasutamine rakenduse "Smotri+" tagaplaanil.

Mihhail Salosin (edasi – MS): – Tere kõigile! Minu nimi on Mihhail. Olen MC2 Software'is tagaplaanide arendaja ja räägin teile Go kasutamisest mobiilirakenduse «Sotri+» tagaplaanis.

Kas keegi kohalolejatest armastab hoki?

Siis on see rakendus teie jaoks. See on mõeldud Androidile ja iOS-ile, võimaldades vaadata erinevate spordisündmuste otse- ja järelvaatamise ülekandeid. Rakenduses on ka erinev statistika, tekstilised ülekanded, koosseisud turniiride ja konverentside jaoks ning muu teave, mis on fännide jaoks kasulik.

Rakenduses on ka funktsioon, nagu videomomendid, st saate vaadata mängude teravaid hetki (väravad, kaklused, karistuslöögid jne). Kui te ei soovi vaadata kogu ülekanne, siis saate vaadata ainult kõige huvitavamat.

Mida kasutati arenduses?

Peamine osa oli kirjutatud Go keeles. API, millega suhtlesid mobiilklientide programmid, oli samuti kirjutatud Go keeles. Push-teadete saatmiseks mobiilidesse oli samuti kasutatud Go keelt. Lisaks pidime kirjutama oma ORM-i, millest räägime ehk kunagi tulevikus. Go keeles on kirjutatud ka mõned väikesed teenused: piltide suuruse muutmine ja üleslaadimine toimetajate poole…

Andmebaasina kasutasime PostgreSQL-i. Toimetajate liides oli kirjutatud Ruby on Railsis kasutades ActiveAdmini gemi. Statistika, mille importimiseks kasutasime Ruby keelt, tuli statistikapakkujalt.

API süsteemitestide jaoks kasutasime Pythonis unittesti. API maksete päringute ülevaate kontrollimiseks kasutatakse Memcached'i, konfiguratsiooni haldamiseks Chef'i ning sisemiste statistiliste andmete kogumiseks ja jälgimiseks Zabbix'i. Logide kogumiseks kasutame Graylog2 ja API dokumentatsiooniks klientidele on Slate.

Protokolli valik

Esimene probleem, millega silmitsi seisisime: pidime valima protokolli, mille kaudu toimub suhtlemine taustsüsteemi ja mobiilsete klientide vahel, tuginedes järgmistele punktidele…

• Peamine nõue: kliendiandmed peavad värskenduma reaalajas. See tähendab, et kõik, kes hetkel vaatavad ülekanne, peaksid saama värskendusi praktiliselt koheselt.
• Lihtsustamiseks oletame, et andmed, mis sünkroniseeritakse klientidega, ei eemaldata, vaid peidetakse spetsiaalsete lipukestega.
• Mõned haruldased päringud (nt statistika, meeskondade koosseis, meeskondade statistika) saadakse tavaliste GET-päringutega.
• Lisaks pidi süsteem taluma rahulikult 100 000 kasutajat samaaegselt.

Seetõttu oli meil kaks protokollivalikut:

1. Websocketid. Kuid me ei vajanud kanalit kliendilt serverile. Meile oli vajalik ainult värskenduste saatmine serverist kliendile, mistõttu oli veebisoket üleliigne variant.
2. Server-Sent Events (SSE) sobis ideaalselt! See on piisavalt lihtne ja rahuldab põhimõtteliselt kõiki meie vajadusi.

Server-Sent Events

Mõned sõnad selle süsteemi toimimise kohta...

See töötab http-ühenduse peal. Klient saadab päringu, server vastab Content-Type: text/event-stream ja ei sulge ühendust, vaid jätkab andmete kirjutamist sellesse ühendusse.

Andmed saab saata kliendi heakskiidetud vormingus. Meie puhul saatsime me seda selliselt: event väljale saadeti muudetud struktuuri nimi (inimene, mängija), ja data väljale - JSON uute, muudetud mängija väli-dega.

Nüüd räägime, kuidas ise suhtlus toimib.

• Kõigepealt määrab klient, millal viimane kord sündis sünkroniseerimine teenusega: ta vaatab oma lokaalsesse andmebaasi ja määrab viimase muudatuse kuupäeva, mis tal on salvestatud.
• Ta saadab päringu koos selle kuupäevaga.
• Vastuseks saadame me talle kõik värskendused, mis on toimunud alates sellest kuupäevast.
• Pärast seda loob ta ühenduse live-kanaliga ja ei sulge seda, kuni need värskendused on vajalikud:

Me saadame talle muudatuste loendi: kui keegi lõi värava - muudame mängu skoori, kui keegi sai vigastada - saadetakse see samuti reaalajas. Seega saavad kliendid mängu sündmuste voos koheselt ajakohased andmed. Aeg-ajalt, et klient saaks aru, et server ei ole kokku kukkunud, et temaga ei ole midagi juhtunud, saadame me iga 15 sekundi järel timestamp'i - et ta teaks, et kõik on korras ja ta ei pea uuesti ühendust looma.

Kuidas toimub live-ühenduse haldamine?

• Esiteks loome kanali, kuhu saadetakse uuendusi koos puhvriga.
• Pärast seda registreerime selle kanali uuenduste saamiseks.
• Seame õige pealkirja, et klient teaks, et kõik on korras.
• Saadame esimese ping'i. Lihtsalt salvestame praeguse ühenduse ajamärgi.
• Seejärel loeme silmuses kanalist kuni uuenduste kanal on suletud. Kanalile saadetakse perioodiliselt kas praegune ajamärk või muudatused, mille me juba salvestame avatud ühendustes.

Esimene probleem, millega silmitsi seisisime, oli järgmine: igale avatud kliendiühendusele loodi taimer, mis tiksus iga 15 sekundi tagant – tähendab, et kui meil oli avatud 6000 ühendust ühe masinaga (ühe API-serveriga), siis loodi 6000 taimerit. See tõi kaasa selle, et masin ei suutnud vajalikku koormust taluda. Probleem ei olnud meie jaoks nii ilmne, kuid me saime veidi abi ja lahendasime selle.

Sellest ajast saadik tuleb meie ping samast kanalist, kust tuleb ka uuendus.

Seega on meil ainult üks taimer, mis tiksub iga 15 sekundi tagant.

Siin on mõned abifunktsioonid – pealkirjade saatmine, pingi ja struktuuri saatmine. See tähendab, et edastatakse tabeli nimi (isiku, mängu, hooaja) ja teave selle kirje kohta:

Uuenduste saatmise mehhanism

Nüüd räägime veidi sellest, kust muutused tulevad. Meil on mõned inimesed, toimetajad, kes jälgivad reaalajas edastust. Nad loovad kõik sündmused: kedagi eemaldatakse, keegi saab vigastada, toimub vahetus...

CMS-i kaudu jõuavad andmed andmebaasi. Pärast seda teavitab andmebaas mehhanismi Listen/Notify abil API-servereid. API-serverid jagavad selle teabe klientidele. Seega on meil põhimõtteliselt andmebaasiga ühendatud vaid mõned serverid ning andmebaasile ei ole erilist koormust, kuna klient ei suhtle andmebaasiga otseselt:

PostgreSQL: Listen/Notify

Listen/Notify mehhanism „Postgreses“ võimaldab teavitada sündmuste tellijaid, et mõni sündmus on muutunud – andmebaasis on loodud mõni uus kirje. Selleks kirjutasime lihtsa trigeri ja funktsiooni:

Insert või kirje muutmise korral kutsume andmekanalis data_updates välja notify funktsiooni, edastades sinna tabeli nime ja muudetud või sisestatud kirje ID.

Kõikidele tabelitele, mis peavad olema kliendiga sünkroniseeritud, defineerime käivitaja, mis pärast kirje muutmist/uendamist kutsub välja slaidil allpool näidatud funktsiooni.
Kuidas API nendest muudatustest teada saab?

Loodud on Fanout mehhanism – see saadab sõnumeid klientidele. See kogub kõik kliendi kanalid ja edastab neile saadud uuendused:

Siin on standardne teek pq, mis ühendub andmebaasiga ja ütleb, et soovib kuulata kanalit (data_updates), kontrollides, et ühendus on avatud ja kõik on korras. Jätan veateate kontrollimise välja, et ruumi kokku hoida (kontrollimata jätmine võib olla ohtlik).

Seejärel määrame asünkroonselt Ticker'i, mis saadab ping'i iga 15 sekundi tagant, ja hakkame kuulama kanali, millele oleme tellinud. Kui saame ping'i, avaldame selle. Kui saame mõne kirje, avaldame selle kõikidele selle Fanout'i tellijatele.

Kuidas Fan-out töötab?

Eesti keeles tõlgitakse see kui "haruühendus". Meil on üks objekt, mis registreerib tellijad, kes soovivad saada mingit teavet. Ja kui sellele objektile tuleb uuendus, jagab ta selle uuenduse kõikidele tellijatele, kellel see on. Suhteliselt lihtne:

Kuidas seda Go's rakendatakse:

On struktuur, mis sünkroniseeritakse Mutex'ide abil. Sellel on väli, mis salvestab Fanout'i ühenduse oleku andmebaasiga, st hetkel kuulab see ja saab uuendusi, samuti on olemas kõigi kanalite nimekiri – map, mille võtmed on kanal ja struktuur väärtustena (seda ei kasutata tegelikult millegiks).

Kahe meetodiga – Connected ja Disconnected – saab Fanout’ile öelda, et meil on ühendus andmebaasiga, see on tekkinud, ja et andmebaasiühendus on katkestatud. Teisel juhul tuleb kõik kliendid lahti ühendada ja neile teatada, et nad ei saa enam midagi kuulata ja paluda neil uuesti ühendada, kuna nendega side on katkenud.

Samuti on olemas meetod Subscribe, mis lisab kanali "kuulajate" hulka:

On olemas Unsubscribe meetod, mis eemaldas kanali kuulajatest, kui klient on välja lülitatud, samuti Publish meetod, mis võimaldab sõnumit saata kõigile tellijatele.

Küsimus: – Mida selle kanali kaudu edastatakse?

M: – Edastatakse mudel, mis on muutunud, või ping (põhimõtteliselt lihtsalt number, integer).

M: – Võib edastada ükskõik mida, igasuguseid struktuure – need lihtsalt muudetakse JSON-ks ja kõik.

M: – Saame teate Postgres'ist – see sisaldab tabeli nime ja identifikaatorit. Tabeli nime põhjal saame ja identifikaatori põhjal saame vajaliku kirje, ning selle struktuuri saadame avaldamiseks.

Infrastruktuur

Kuidas see infrastruktuuri vaatepunktist välja näeb? Meil on 7 füüsilist serverit: üks neist on täielikult pühendatud andmebaasile, ülejäänud kuuel töötavad virtuaalmasinad. Kuuest API koopiatest: iga virtuaalmasin API-ga töötab eraldi füüsilisel serveril – see on usaldusväärsuse jaoks.

Meil on kaks frontend'i, millel on installitud Keepalived, et parandada kättesaadavust, et vajadusel saaks üks frontend asendada teise. Veel – kaks CMS koopiat.

Samuti on olemas statistika importija. On DB Slave, millest tehakse perioodiliselt varukoopiaid. On Pigeon Pusher – rakendus, mis saadab klientidele push-teateid, samuti infrastruktuursed asjad: Zabbix, Graylog2 ja Chef.

Tegelikult on see infrastruktuur üleliigne, sest 100 000 klienti saab teenindada ka väiksema serverite arvuga. Kuid kuna riistvara oli olemas, kasutasime seda (meile öeldi, et see on võimalik – miks mitte).

Go eelised

Pärast seda, kui me selle rakenduse kallal töötasime, ilmnesid Go selged eelised.

• Suurepärane http-raamatukogu. Selle abil saab juba "karbist välja" päris palju luua.
• Lisaks võimaldavad kanalid meil väga lihtsalt rakendada teatiste saatmise mehhanismi klientidele.
• Imeline asi Race detector võimaldas meil kõrvaldada mitu kriitilist viga (staging-infrastruktuur). Kõik, mis töötab staging'is – on käivitatud, kompileeritud Race-võtmega; ja seega saame staging-infrastruktuuris vaadata, millised potentsiaalsed probleemid meil on.
• Keeles on minimalism ja lihtsus.

Otsime arendajaid! Kui keegi on huvitatud – palun.

Küsimused

Küsimus publikust (edaspidi – K): – Olen arvamusel, et jätsite ühe olulise momendi Fan-out'i osas käsitlemata. Kas ma saan õigesti aru, et kui saadate kliendile vastuse, siis te blokeerite, kui klient ei soovi lugeda?

M: – Ei, me ei blokeeri. Esiteks on meie teenused kõik nginx'i taga, seega ei esine probleeme aeglaste klientidega. Teiseks, kliendil on kanalis puhversüsteem – tegelikult saame sinna saata kuni sada uuendust... Kui me ei saa kanalisse kirjutada, siis ta kustutab selle. Kui märkame, et kanal on blokeeritud, siis me lihtsalt sulgeme kanali ja kõik – klient reconnect'ib, kui tekkima peaks mingi probleem. Seega ei esine siin põhimõtteliselt blokeeringut.

K: – Kas ei oleks olnud võimalik kohe saata Listen/Notify kaudu kirje, mitte tabeli identifikaator?

M: – Listen/Notify'il on 8000 baitine piirang eelkoormusele, mille ta saadab. Teoreetiliselt oleks saanud saata, kui meil oleks vähe andmeid, kuid mulle tundub, et see [nagu meie teeme] on lihtsalt usaldusväärsem. Piirangud on Postgreses endas.

K: – Kas kliendid saavad uuendusi mängudest, mis neid ei huvita?

M: – Üldiselt jah. Tüüpiliselt toimub seal 2-3 matši samal ajal, ja see on isegi harva. Kui klient vaatab midagi, siis tavaliselt vaatab ta just seda matši, mis käib. Seejärel on kliendil kohalik andmebaas, kuhu kõik need uuendused kogunevad, ja isegi ilma internetiühenduseta saab klient vaadata kõiki toimunud matše, mille kohta tal on uuendusi. Põhimõtteliselt sünkroniseerime oma andmebaasi serveris kliendi kohaliku andmebaasiga, et ta saaks töötada ka offline.

K: – Miks te tegite oma ORM-i?

Aleksei (üks „Smotri+” arendajatest): – Sel hetkel (see oli aasta tagasi) oli ORM-e vähem kui praegu, kui neid on juba üsna palju. Enamik olemasolevaid ORM-e mulle ei meeldi, kuna enamik neist töötab tühjade liideste peal. See tähendab, et nende ORM-ide meetodid on valmis vastu võtma mida iganes: struktuuri, struktuuri viidatud, arvu, midagi täiesti asjatu...

Meie ORM genereerib struktuure andmemudeli alusel. Iseseisvalt. Ja seetõttu on kõik meetodid konkreetsed, ei kasuta refleksiooni jne. Nad võtavad vastu struktuure ja ootavad, et kasutada neid struktuure, mis sisenevad.

K: – Kui palju inimesi osales?

M: – Algfaasis osales kaks inimest. Kuskil juunis me alustasime, augustiks oli enamus valmis (esimene versioon). Septembris toimus väljaanne.

K: – Seal, kus kirjeldate SSE-d, te ei kasuta timeout'i. Miks nii?

M: – Ausalt öeldes on SSE ikkagi HTML5 protokoll: SSE standard on mõeldud suhtlemiseks brauseritega, kui ma õigesti aru saan. Sellel on lisafunktsioonid, et brauserid saaksid uuesti ühendada (ja muud), kuid neid pole meil vaja, kuna meie kliendid suudavad rakendada mis tahes ühenduse ja teabe saamise loogikat. Me olime teinud pigem mitte SSE, vaid midagi SSE-taolist. See ei ole protokoll ise.
Pole olnud vajadust. Kui ma õigesti aru saan, siis kliendid rakendasid ühenduse mehhanismi praktiliselt nullist. Nad ei hoolinud sellest üldse.

K: – Milliseid lisatööriistu te kasutasite?

M: – Kõige aktiivsemalt kasutasime govet ja golint, et stiil oleks ühtlane, samuti gofmt. Muid ei kasutanud.

K: – Kuidas te kärpimist tegite?

M: – Kärpimist tehti põhimõtteliselt testide abil. Me ei kasutanud mingit debugeerijat, GOP-i.

K: – Kas sa saad tagasi tuua slaidi, kus on rakendatud Publish funktsioon? Kas ühekohalised muutuja nimetused ei häiri sind?

M: – Ei. Neil on piisavalt „kitsas” ulatus. Nad ei kasuta ennast kusagil mujal, välja arvatud siin (välja arvatud selle klassi sees), ja see on väga kompaktne – hõlmab vaid 7 rida.

K: – Kuidaski tundub see ikkagi mitte intuitiivne…

M: – Ei-ärk, see on tõeline kood! Küsimus ei ole stiilis. See on lihtsalt nii utilitaarne, täiesti väike klass – ainult 3 välja klassi sees…

M: – Üldiselt ei muutu kõik need andmed, mis sünkroonitakse klientidega (hooaegade mängud, mängijad). Ütleme niimoodi, et kui me teeme mõne muu spordiala, kus tuleb mängu muuta, siis arvestame sellega lihtsalt uues kliendi versioonis, ja vanad versioonid blokeeritakse.

K: – Kas on olemas mingeid kolmanda osapoole pakette sõltuvuste haldamiseks?

M: – Me kasutasime go dep.

K: – Ettekande teemal oli midagi videotest, aga ettekandes video kohta ei ole.

M: – Ei, minul ei ole teemas midagi video kohta. See nimi on „Sootri+” – nii nimetatakse seda rakendust.

K: – Kas sa rääkisid, et seda edastatakse klientidele?..

M: – Me ei ole tegelenud voogedastuse videoga. Selle tegi täielikult „MegaFon“. Jah, ma ei maininud, et see on MegaFoni rakendus.

M: – Go – kõigi andmete edastamiseks – arve, mänguürituste, statistika… Go on täielik backend rakendusele. Klient peab kusagilt teadma, millist linki kasutada mängija jaoks, et kasutaja saaks mängu vaadata. Meil on videolinkide ja voogedastuste lingid, mis on ette valmistatud.

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavaid materjale? Toetage meid, tehes tellimuse või soovitades meid tuttavatele. pilve VPS arendajatele alates $4,99, ainulaadne sisenemise taseme serverite analoog, mille oleme teie jaoks välja mõelnud: Kogu tõde VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps alates $19 või kuidas õieti serverit jagada? (saadaval on RAID1 ja RAID10 variandid, kuni 24 südamikku ja kuni 40GB DDR4).

Kas Dell R730xd on kaks korda odavam Equinixi Tier IV andmete keskuses Amsterdamis? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandi turul! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege, kuidas Luua ettevõtte tasemel infrastruktuur Dell R730xd E5-2650 v4 serveritega, mille hind on 9000 eurot, madala hinnaga?

Allikas: habr.com