🥇Mikhail Salosin. Golang Meetup. Go kasutamine rakenduse „Sootri+” tagumise osa arendamisel

Mihhail Salosin (edasi – MS): – Tere kõigile! Minu nimi on Mihhail. Töödan tagaroboti arendajana ettevõttes MC2 Software, ja räägin kasutusest Go mobiilirakenduse «Sotri+» tagaroboti pool.

Kas keegi kohalolejatest armastab hokit?

Siis on see rakendus just sinule. See on mõeldud Androidile ja iOS-ile ning võimaldab vaadata erinevate spordisündmuste ülekandeid reaalajas ja järelvaatamiseks. Rakenduses on ka erinev statistika, tekstilised ülekanded, tabelid konverentsidest, turniiridest ja muu teave, mis on kasulik fännidele.

Rakenduses on ka selline asi nagu videomomendid, st saab vaadata kohtumise teravaid hetki (väravaid, kaklusi, bullete jne). Kui sa ei soovi vaadata kogu ülekannet, saad vaadata ainult kõige huvitavamat.

Mida me arenduses kasutasime?

Peamine osa kirjutati Go keeles. See API, millega mobiilsed kliendid suhtlesid, kirjutati samuti Go keeles. Samuti oli Go keeles kirjutatud teenus push-teadete saatmiseks mobiilidele. Me pidime ka kirjutama oma ORM-i, millest me võib-olla kunagi räägime. Ja Go keeles on kirjutatud mõned väikesed teenused: piltide suuruse muutmine ja üleslaadimine toimetajate poole…

Andmebaasina kasutasime PostgreSQL-i. Toimetajate liides oli kirjutatud Ruby on Railsis ActiveAdmin gem'i abil. Ruby keeles on kirjutatud ka statistika import, mis tuleb statistika tarnijalt.

API süsteemitestide jaoks kasutasime Pythonis unittesti. Memcached'i kasutatakse API-de makse jupitamiseks, Chef'i – konfiguratsiooni haldamiseks, Zabbix'i – süsteemi sise statistikate kogumiseks ja jälgimiseks. Graylog2 – logide kogumiseks, Slate – dokumentatsioon API klientidele.

Protokolli valik

Esiteks probleem, millega me silmitsi seisis: pidime valima protokolli, millega tagarobot suheldes mobiilsete klientidega põhinedes järgmistel punktidel...

Suurim nõue: andmed klientides peavad uuenduma reaalajas. St kõik, kes hetkel vaatavad ülekannet, peavad saama uuendusi praktiliselt koheselt.
Lihtsustamiseks nõustusime, et andmed, mis sünkroniseeritakse klientidega, ei kustutata, vaid peidetakse spetsiaalsete lipukestega.
Iga haruldased päringud (nagu statistika, meeskondade koosseisud, meeskondade statistika) saadakse tavapäraste GET-päringutega.
Lisaks pidi süsteem rahulikult taluma 100 000 samaaegset kasutajat.

Sellega seoses oli meil kaks protokollivõimalust:

Websocketid. Kuid me ei vajanud klientsideme kanaleid. Me vajame ainult andmete saatmist serverilt kliendile, seega on veebisokett liialdus.
Server-Sent Events (SSE) sobis suurepäraselt! See on piisavalt lihtne ja rahuldab põhimõtteliselt kõike, mida me vajame.

Server-Sent Events

Mõned sõnad selle asja toimimise kohta…

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

Andmeid saab saata kliendiga kokkulepitud formaadis. Meie puhul saatsime seda kujul: event väljas oli muudetud struktuuri nimi (inimene, mängija), ja data väljas – JSON koos uute, muudetud mängija väljadega.

Nüüd räägime, kuidas toimub interaktsioon.

Esmalt määrab klient, millal viimati toimus sünkroniseerimine teenusega: ta vaatab oma kohalikku andmebaasi ja määrab viimase muudatuse kuupäeva.
Ta saadab päringu koos selle kuupäevaga.
Vastuseks saadame talle kõik uuendused, mis on toimunud pärast seda kuupäeva.
Pärast seda loob ta ühenduse live-kanaliga ja ei sulge seda enne, kui tal on neid uuendusi vaja:

Me saadame talle muudatuste loendi: kui keegi lõi värava – muudame mängu tulemust, kui keegi sai vigastada – saadame ka seda reaalajas. Seega saavad kliendid mängu sündmuste voo kaudu kohe värskeid andmeid. Aeg-ajalt, et klient mõistaks, et server ei ole surnud ja temaga ei ole midagi juhtunud, saadame iga 15 sekundi tagant timestampi – et ta teaks, et kõik on korras ja uuesti ühendust pole vaja luua.

Kuidas teenindatakse live-ühendust?

Esiteks loome kanali, kuhu uudised tulevad koos mahutiga.
Pärast seda registreerime selle kanali uuenduste vastuvõtmiseks.
Seame õige päise, et klient teaks, et kõik on korras.
Saadame esimese pingi. Lihtsalt salvestame ühenduse hetketimestampi.
Pärast seda loeme tsüklis kanalist seni, kuni värskenduste kanal on suletud. Kanalisse tuleb perioodiliselt kas praegune ajatemperatuur või muudatused, mille me juba salvestame avatud ühendustesse.

Esimene probleem, millega me silmitsi seisime, oli see, et iga kliendiga avatud ühenduse jaoks lõime taimeri, mis tiksus iga 15 sekundi tagant – seega, kui meil oli avatud 6000 ühendust ühe masina (ühe API-serveri) kaudu, loodi 6000 taimerit. See viis selleni, et masin ei suutnud vajalikku koormust taluda. Probleem ei olnud meie jaoks nii ilmne, kuid me saime veidi abi ja lahendasime selle.

Nüüd tuleb meil ping samast kanalist, kust tuleb ka uuendus.

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

Siin on mitu abifunktsiooni – pealkirja, pingi ja struktuuri saatmine. See tähendab, et edastatakse tabeli nimi (person, match, season) ja selle kirje teave:

Uuenduste saatmise mehhanism

Nüüd natuke sellest, kust muudatused tulevad. Meil on mitu inimest, toimetajaid, kes jälgivad reaalajas ülekandeid. Nad loovad kõik sündmused: kedagi eemaldati, keegi sai vigastada, mingi vahetus…

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

PostgreSQL: Listen/Notify

Listen/Notify mehhanism PostgreSQL-is võimaldab teavitada sündmuste tellijaid, et mõni sündmus on muutunud – andmebaasis on loodud mõni uus rida. Selleks kirjutasime lihtsa trigri ja funktsiooni:

Insertimise või kirje muutmise korral kutsume kanalis data_updates esile funktsiooni notify, edastades sinna tabeli nime ja muudetud või sisestatud kirje identifitseerija.

Kõikidele tabelitele, mis peavad olema kliendiga sünkroniseeritud, määrame trigri, mis pärast kirje muutmist/värskendamist kutsub välja alloleval slaidil määratud funktsiooni.
Kuidas API nende muudatuste tellimiseks registreerub?

Loodi Fanout mehhanismi – see saadab teadet klientidele. See kogub kõikide klientide kanalid ja saadab neile värskendused, mida ta nendelt kanalitelt sai:

Siin on standardne biblioteek pq, mis ühendub andmebaasiga ja ütleb, et soovib kuulata kanalit (data_updates), kontrollib, et ühendus on avatud ja kõik on korras. Jätan vigade kontrollimise välja, et ruumi säästa (veadeta jätmine võib olla riskantne).

Küsimus, kuidas me asünkroonselt määrame Tickeri, mis saadab ping’i iga 15 sekundi tagant, ja hakkame kuulama kanalit, millele me oleme tellinud. Kui me saame ping’i, avaldame selle ping’i. Kui me saame mingisuguse kirje, avaldame selle kirje kõigile selle Fanout’i tellijatele.

Kuidas Fan-out töötab?

Eestis tõlgitakse seda kui "haru". Meil on üks objekt, mis registreerib tellijad, kes soovivad saada mingeid värskendusi. Ja niipea, kui see objekt saab värskenduse, jagab ta selle värskenduse kõigile oma olemasolevatele tellijatele. Lihtne:

Kuidas see Go-s on rakendatud:

Olemas on struktuur, mis sünkroniseerub Mutexitega. Sellel on väli, mis hoiab Fanout’i ühenduse staatust andmebaasi, st hetkel kuuleb ta ja saab värskendusi, samuti kõigi olemasolevate kanalite loend – map, mille võtmed on kanalid ja struct väärtustena (tõepoolest ei kasutata seda kuidagi).

Kaks meetodit – Connected ja Disconnected – võimaldavad Fanout’ile öelda, et meil on ühendus andmebaasiga, see on olemas, ja et ühendus andmebaasiga on katkestatud. Teisel juhul tuleb kõiki kliente välja lülitada ja teavitada neid, et nad ei saa enam midagi kuulata ja et nad peaksid uuesti ühenduma, kuna ühendus nendega on katkenud.

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

On olemas meetod Unsubscribe, mis eemaldab kanali kuulajate seast, kui klient on välja lülitunud, ning meetod Publish, mis võimaldab saata teadet kõigile tellijatele.

Küsimus: – Mis sellel kanalil edastatakse?

MS: – Edastatakse mudel, mis on muutunud või ping (tõepoolest lihtsalt number, täisarv).

MS: – Võid edastada muud, ükskõik millist struktuuri, see avaldatakse – see muudetakse lihtsalt JSON-iks ja kõik.

MS: – Me saame teate „Postgres'ilt” – see sisaldab tabeli nime ja identifikaatorit. Tabeli nime järgi saame identifikaatori ja saame vajalikud kirjed, mida saadame seejärel avaldamiseks.

Infrastruktuur

Kuidas see infrastruktuuri vaatenurgast välja näeb? Meil on 7 füüsilist serverit: üks neist on täielikult pühendatud andmebaasile, ülejäänud kuuel jooksevad virtuaalmasinad. Meil on 6 API koopiat: iga virtuaalmasin, kus API töötab, asub eraldi füüsilisel serveril – see on usaldusväärsuse tagamiseks.

Meil on kaks frontend'i, millel on paigaldatud Keepalived, et parandada kättesaadavust, nii et hädaolukordades suudaks üks frontend asendada teise. Samuti on kaks CMS koopia.

Samuti on olemas statistika impordija. On DB Slave, millelt tehakse regulaarselt varukoopiaid. On Pigeon Pusher – see rakendus saadab klientidele teateid, koos infrastruktuuri elementidega: Zabbix, Graylog2 ja Chef.

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

Go eelised

Pärast selle rakendusega töötamist ilmusid esile järgmised ilmne Go eelised.

Suurepärane http-raamatukogu. Selle abil on võimalik palju luua juba „karbist välja”.
Ja kanalid, mis võimaldasid meil väga lihtsalt rakendada klientidele teadete saatmise mehhanismi.
Imeline asi, Race detector, aitas meil kõrvaldada mitmeid kriitilisi vigu (staging-infrastruktuur). Kõik, mis töötab staging'is – on käivitatud, kompileeritud Race võtmega; seega saame staging-infrastruktuuris vaadata, millised potentsiaalsed probleemid meil on.
Keele minimalism ja lihtsus.

Otsime arendajaid! Kui keegi on huvitatud – palun.

Küsimused

Küsimus publikult (edaspidi – K): – Tundub, et te jätsite ühe olulise hetke Fan-out osas tähelepanuta. Kas ma õigesti mõistan, et kui saadate kliendile vastuse, jääte kinni, kui klient ei soovi lugeda?

MS: – Ei, me ei blokeeri. Esiteks on kõik meie jaoks nginx'i taga, seega aeglaste klientidega mingeid probleeme ei ole. Teiseks, kliendi kanalil on vaht – sisuliselt võime sinna paigutada kuni sada uuendust... Kui me ei saa kanalisse kirjutada, siis see kustutab selle. Kui me näeme, et kanal on blokeeritud, siis lihtsalt sulgeme kanali ja kõik – klient ühendub jälle, kui juhtub mingi probleem. Seega sisuliselt blokeeringud ei teki.

K: – Kas ei saanud kohe saata Listen/Notify kirje, mitte tabeli-identifikaatorit?

MS: – Listen/Notify'l on 8000-baidi piirang eelnevalt laaditavale, mida ta saadab. Põhimõtteliselt oleks saanud saata, kui tegeleme väikese hulga andmetega, aga mulle tundub, et nii [kui me teeme] on lihtsalt usaldusväärsem. Piirangud on ise „PostgreSQL'is”.

K: – Kas kliendid saavad uuendusi kohtumistest, mis neid ei huvita?

MS: – Üldiselt jah. Üldiselt on seal paralleelselt 2-3 kohtumist, ja see on pigem harv. Kui klient vaatab midagi, siis tavaliselt vaatab ta just seda kohtumist, mis toimub. Siis on kliendil kohalik andmebaas, kuhu kõik need uuendused kogutakse, ja isegi ilma internetiühenduseta saab klient vaadata kõiki möödunud mänge, mille kohta tal on uuendusi. Sisuliselt 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): – Toona (see oli aasta tagasi) oli ORM-e vähem, kui nüüd, kui neid on piisavalt palju. Enamik olemasolevatest ORM-idest, mis mulle kõige vähem meeldivad, töötavad enamasti tühipindadega. See tähendab, et need ORM-id on valmis võtma vastu kõike, mis iganes: struktuuri, struktuuri viidat, arvu, midagi, mis ei ole asjaga seotud...

Meie ORM genereerib struktuure andmemudeli põhjal. Ise. Ja seega on kõik meetodid konkreetsed, ei kasuta peegeldust jne. Need võtavad vastu struktuurid ja ootavad, et neid struktuure kasutatakse.

K: – Kui palju inimesi osales?

MS: – Algfaasis osales kaks inimest. Kusagil juunis alustasime, augustis oli peamine osa valmis (esimene versioon). Septembris toimus väljaanne.

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

MS: Kui rääkida otse, siis SSE on ikkagi html5-protokoll: SSE standard on mõeldud suhtlemiseks brauseritega, nii palju kui ma aru saan. Sellel on lisafunktsioonid, et brauserid saaksid uuesti ühenduda (ja muud), kuid need pole meile vajalikud, sest meil oli kliente, kes said rakendada mis tahes ühendamise ja teabe hankimise loogikat. Tegime pigem midagi, mis sarnaneb SSE-le. See ei ole protokoll ise.
Ei olnud vajadust. Nii palju kui ma mõistan, rakendasid kliendid ühendusmehhanismi peaaegu nullist. Neil ei olnud põhimõtteliselt vahet.

K: Milliseid täiendavaid tööriistu te kasutasite?

MS: Kasutame aktiivselt govet ja golint, et stiil oleks ühtlane, samuti gofmt. Rohkem me midagi ei kasutanud.

K: Kuidas te debugimist tegite?

MS: Debugimine toimus suures osas testide kaudu. Me ei kasutanud mingit debuggerit, GOP-i.

K: Kas saaksite tagastada slaidi, kus on rakendatud funktsioon Publish? Kas ühenäolised muutujate nimed ei häiri teid?

MS: Ei. Neil on piisavalt kitsas nähtavus. Nad ei kasutata kuskil mujal kui siin (välja arvatud selle klassi sisemuses), ja see on väga kompaktne – võtab vaid 7 rida.

K: Kuid see ei tundu ikkagi intuitiivne...

MS: Ei-ei, see on tõeline kood! Asi ei ole stiilis. Lihtsalt see on selline utilitaarne, täiesti väike klass – vaid 3 välja klassi sees...

MS: Suures osas ei muutu kõik need andmed, mis sünkroniseeritakse klientidega (hooajalised mängud, mängijad). Üldiselt öeldes, kui me teeme veel mõnda spordiala, kus tuleb mängu muuta, arvestame kõik uues kliendi versioonis, samas kui vanad kliendi versioonid blokeeritakse.

K: Kas on mingeid kolmandate osapoolte pakette sõltuvuste haldamiseks?

MS: Kasutame go dep.

K: Ettekanne käsitles midagi videot, aga ettekandes videost midagi pole.

MS: Ei, mul ei ole videos midagi ettepanekus. See on nimetatud "Vaata+" – see on rakenduse nimi.

K: Te rääkisite, et see voogedastatakse klientidele?

MS: Me ei tegelenud voogedastava videoga. Selle tegi täielikult "MegaFon". Jah, ma ei öelnud, et rakendus on megafooni oma.

MS: – Go – andmete edastamiseks – arve, mänguürituste, statistika jms kohta… Go – see on täielik tagumine osa rakendusele. Kliendil peab olema allikas, kust teada saada, millist linki kasutada mängu vaatamiseks. Meil on videolinkide ja voogesituste lingid, mis on valmis.

Veidi reklaami 🙂

Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavat sisu? Toetage meid, tellides teenuse või soovitades meid tuttavatele. Pilve VPS arendajatele alates $4.99, ainulaadne entry-level 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 jagada serverit õigesti? (saadaval RAID1 ja RAID10 variandid, kuni 24 tuuma ja kuni 40GB DDR4).

Dell R730xd on Equinixi Tier IV andmekeskuses Amsterdamis kaks korda odavam? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandis! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege sellest Kuidas luua ettevõtte tasemel infrastruktuuri, kasutades Dell R730xd E5-2650 v4 servereid, mille hind on 9000 eurot, taskukohase hinna eest?

Allikas: habr.com