Mihail Salosin (jäljempänä – MS): - Hei kaikki! Minun nimeni on Michael. Työskentelen taustakehittäjänä MC2 Softwaressa ja aion puhua Go:n käytöstä Look+ -mobiilisovelluksen taustaohjelmassa.
Pitääkö täällä kukaan jääkiekosta?
Sitten tämä sovellus on sinua varten. Se on tarkoitettu Androidille ja iOS:lle, ja sitä käytetään eri urheilutapahtumien lähetysten katseluun verkossa ja tallennettuina. Sovellus sisältää myös erilaisia tilastoja, tekstilähetyksiä, konferenssien, turnausten taulukoita ja muuta faneille hyödyllistä tietoa.
Sovelluksessa on myös sellainen asia kuin videohetket, eli voit katsoa otteluiden tärkeimmät hetket (maalit, taistelut, rangaistuslaukaukset jne.). Jos et halua katsoa koko lähetystä, voit katsoa vain mielenkiintoisimmat.
Mitä käytit kehityksessä?
Pääosa on kirjoitettu Go. Sovellusliittymä, jonka kanssa mobiiliasiakkaat kommunikoivat, oli kirjoitettu Gossa. Goon kirjoitettiin myös palvelu push-ilmoitusten lähettämiseen matkapuhelimiin. Meidän piti myös kirjoittaa oma ORM, josta saatamme puhua joskus. No, Goon kirjoitettiin pieniä palveluita: koon muuttaminen ja kuvien lataaminen toimittajille...
Tietokantana käytimme PostgreSQL:ää. Editorin käyttöliittymä on kirjoitettu Ruby on Rails -kielellä ActiveAdmin-helmiä käyttäen. Tilastojen tuonti tilastotoimittajalta on myös kirjoitettu Rubylla.
Järjestelmän API-testeissä käytimme Python-yksikkötestiä. Memcachediä käytetään API-maksukutsujen hillitsemiseen, "Chef" -sovelluksella konfigurointia ohjataan, Zabbixilla kerätään ja seurataan sisäisiä järjestelmätilastoja. Graylog2 on lokien keräämiseen, Slate on API-dokumentaatio asiakkaille.
Protokollan valinta
Ensimmäinen kohtaamamme ongelma: meidän piti valita protokolla taustajärjestelmän ja mobiiliasiakkaiden välistä vuorovaikutusta varten seuraavien seikkojen perusteella...
- Tärkein vaatimus: asiakastiedot on päivitettävä reaaliajassa. Toisin sanoen kaikkien lähetystä parhaillaan katsovien pitäisi saada päivitykset lähes välittömästi.
- Asioiden yksinkertaistamiseksi oletimme, että asiakkaiden kanssa synkronoituja tietoja ei poisteta, vaan ne piilotetaan erityisillä lipuilla.
- Kaikenlaiset harvinaiset pyynnöt (kuten tilastot, tiimikokoonpanot, tiimitilastot) saadaan tavallisilla GET-pyynnöillä.
- Lisäksi järjestelmän piti helposti tukea 100 tuhatta käyttäjää samanaikaisesti.
Tämän perusteella meillä oli kaksi protokollavaihtoehtoa:
- Websocketit. Emme kuitenkaan tarvinneet kanavia asiakkaalta palvelimelle. Meidän piti lähettää vain päivitykset palvelimelta asiakkaalle, joten websocket on tarpeeton vaihtoehto.
- Server-Sent Events (SSE) tuli juuri oikeaan! Se on melko yksinkertainen ja periaatteessa täyttää kaikki mitä tarvitsemme.
Palvelimen lähettämät tapahtumat
Muutama sana miten tämä homma toimii...
Se toimii http-yhteyden päällä. Asiakas lähettää pyynnön, palvelin vastaa Content-Type: text/event-stream ja ei sulje yhteyttä asiakkaaseen, vaan jatkaa tietojen kirjoittamista yhteyteen:
Tiedot voidaan lähettää asiakkaan kanssa sovitussa muodossa. Meidän tapauksessamme lähetimme sen tässä muodossa: tapahtumakenttään lähetettiin muuttuneen rakenteen nimi (henkilö, pelaaja) ja tietokenttään JSON uusilla, pelaajalle muuttuneilla kentillä.
Puhutaan nyt siitä, miten vuorovaikutus itse toimii.
- Ensimmäinen asia, jonka asiakas tekee, on määrittää, milloin viimeksi synkronointi palvelun kanssa on suoritettu: se tarkastelee paikallista tietokantaansa ja määrittää viimeisen tallentaman muutoksen päivämäärän.
- Se lähettää pyynnön tällä päivämäärällä.
- Vastauksena lähetämme hänelle kaikki päivitykset, jotka ovat tapahtuneet tuon päivämäärän jälkeen.
- Sen jälkeen se muodostaa yhteyden live-kanavaan eikä sulkeudu ennen kuin se tarvitsee näitä päivityksiä:
Lähetämme hänelle listan muutoksista: jos joku tekee maalin, muutamme ottelun tulosta, jos hän loukkaantuu, tämä lähetetään myös reaaliajassa. Näin asiakkaat saavat välittömästi ajantasaiset tiedot ottelutapahtumasyötteessä. Ajoittain, jotta asiakas ymmärtää, että palvelin ei ole kuollut, ettei sille ole tapahtunut mitään, lähetämme aikaleiman 15 sekunnin välein - jotta se tietää, että kaikki on kunnossa, eikä yhteyttä tarvitse muodostaa uudelleen.
Miten live-yhteys huolletaan?
- Ensinnäkin luomme kanavan, johon puskuroidut päivitykset vastaanotetaan.
- Sen jälkeen tilaamme tämän kanavan saadaksemme päivityksiä.
- Asetamme oikean otsikon, jotta asiakas tietää, että kaikki on kunnossa.
- Lähetä ensimmäinen ping. Tallennamme vain nykyisen yhteyden aikaleiman.
- Sen jälkeen luemme kanavasta silmukassa, kunnes päivityskanava suljetaan. Kanava vastaanottaa ajoittain joko nykyisen aikaleiman tai muutokset, joita jo kirjoitamme avoimiin yhteyksiin.
Ensimmäinen kohtaamamme ongelma oli seuraava: jokaiselle asiakkaalla avatulle yhteydelle loimme ajastimen, joka tiki 15 sekunnin välein - käy ilmi, että jos meillä olisi 6 tuhatta yhteyttä auki yhdellä koneella (yhdellä API-palvelimella), 6 tuhat ajastinta luotiin. Tämä johti siihen, että kone ei kestänyt vaadittua kuormaa. Ongelma ei ollut meille niin ilmeinen, mutta saimme hieman apua ja korjasimme sen.
Tämän seurauksena pingimme tulee nyt samalta kanavalta, josta päivitys tulee.
Näin ollen on vain yksi ajastin, joka tikittää kerran 15 sekunnissa.
Tässä on useita aputoimintoja - otsikon lähettäminen, ping ja itse rakenne. Eli taulukon nimi (henkilö, ottelu, kausi) ja tiedot tästä merkinnästä välitetään täällä:
Päivitysten lähetysmekanismi
Nyt vähän siitä, mistä muutokset tulevat. Meillä on useita ihmisiä, toimittajia, jotka katsovat lähetystä reaaliajassa. He luovat kaikki tapahtumat: joku lähetettiin ulos, joku loukkaantui, jonkinlainen tilalle...
CMS:n avulla tiedot tulevat tietokantaan. Tämän jälkeen tietokanta ilmoittaa tästä API-palvelimille Listen/Notify-mekanismilla. API-palvelimet lähettävät jo nämä tiedot asiakkaille. Näin ollen meillä on käytännössä vain muutama palvelin kytkettynä tietokantaan, eikä tietokannassa ole erityistä kuormitusta, koska asiakas ei ole suoraan vuorovaikutuksessa tietokannan kanssa millään tavalla:
PostgreSQL: Kuuntele/Ilmoita
Postgresin Listen/Notify-mekanismin avulla voit ilmoittaa tapahtuman tilaajille, että jokin tapahtuma on muuttunut - tietokantaan on luotu tietue. Tätä varten kirjoitimme yksinkertaisen liipaisimen ja toiminnon:
Tietuetta lisättäessä tai muutettaessa kutsumme data_updates-kanavalla notify-toimintoa, jolloin välitetään sinne taulukon nimi ja muutetun tai lisätyn tietueen tunniste.
Kaikille taulukoille, jotka on synkronoitava asiakkaan kanssa, määritämme liipaisimen, joka tietueen muuttamisen/päivityksen jälkeen kutsuu alla olevassa diassa ilmoitettua toimintoa.
Miten API hyväksyy nämä muutokset?
Fanout-mekanismi luodaan - se lähettää viestejä asiakkaalle. Se kerää kaikki asiakaskanavat ja lähettää vastaanottamansa päivitykset seuraavien kanavien kautta:
Täällä tavallinen pq-kirjasto, joka muodostaa yhteyden tietokantaan ja sanoo haluavansa kuunnella kanavaa (data_updates), tarkistaa, että yhteys on auki ja kaikki on kunnossa. Jätän virheentarkistuksen väliin tilan säästämiseksi (tarkistamatta jättäminen on vaarallista).
Seuraavaksi asetimme asynkronisesti Tickerin, joka lähettää pingin 15 sekunnin välein ja alkaa kuunnella tilaamaamme kanavaa. Jos saamme pingin, julkaisemme tämän pingin. Jos saamme jonkinlaisen merkinnän, julkaisemme tämän merkinnän kaikille tämän Fanoutin tilaajille.
Miten Fan-out toimii?
Venäjän kielellä tämä tarkoittaa "jakajaa". Meillä on yksi objekti, joka rekisteröi tilaajia, jotka haluavat saada päivityksiä. Ja heti kun päivitys saapuu tähän objektiin, se jakaa tämän päivityksen kaikille tilaajilleen. Tarpeeksi yksinkertainen:
Kuinka se toteutetaan Gossa:
On olemassa rakenne, se synkronoidaan Mutexesilla. Siinä on kenttä, joka tallentaa Fanoutin yhteyden tilan tietokantaan, eli se kuuntelee parhaillaan ja vastaanottaa päivityksiä sekä luettelon kaikista saatavilla olevista kanavista - kartta, jonka avain on kanava ja rakenne muodossa arvot (olennaisesti sitä ei käytetä millään tavalla).
Kahden menetelmän - Connected ja Disconnected - avulla voimme kertoa Fanoutille, että meillä on yhteys tukiasemaan, se on ilmestynyt ja että yhteys tukiasemaan on katkennut. Toisessa tapauksessa sinun on katkaistava kaikkien asiakkaiden yhteys ja kerrottava heille, että he eivät voi enää kuunnella mitään ja että he muodostavat yhteyden uudelleen, koska yhteys heihin on katkennut.
On myös tilausmenetelmä, joka lisää kanavan "kuuntelijoille":
On olemassa Unsubscribe-menetelmä, joka poistaa kanavan kuuntelijoilta, jos asiakas katkaisee yhteyden, sekä Publish-menetelmä, jonka avulla voit lähettää viestin kaikille tilaajille.
Kysymys: – Mitä tämän kanavan kautta välitetään?
NEITI: – Malli, joka on muuttunut tai ping lähetetään (olennaisesti vain numero, kokonaisluku).
NEITI: – Voit lähettää mitä tahansa, lähettää minkä tahansa rakenteen, julkaista sen – se vain muuttuu JSONiksi ja siinä kaikki.
NEITI: – Saamme ilmoituksen Postgresilta – se sisältää taulukon nimen ja tunnisteen. Taulukon nimen ja tunnuksen perusteella saamme tarvitsemamme tietueen, jonka jälkeen lähetämme tämän rakenteen julkaistavaksi.
infrastruktuuri
Miltä tämä näyttää infrastruktuurin näkökulmasta? Meillä on 7 laitteistopalvelinta: yksi niistä on täysin omistettu tietokannalle, muut kuusi ajaa virtuaalikoneita. API:sta on 6 kopiota: jokainen virtuaalikone, jossa on API, toimii erillisellä laitteistopalvelimella - tämä on luotettavuuden vuoksi.
Meillä on kaksi käyttöliittymää, joissa Keepalived on asennettu parantamaan saavutettavuutta, jotta jos jotain tapahtuu, toinen käyttöliittymä voi korvata toisen. Myös – kaksi kopiota CMS:stä.
Siellä on myös tilastojen maahantuoja. On olemassa DB-slave, josta tehdään varmuuskopiot ajoittain. Siellä on Pigeon Pusher, sovellus, joka lähettää push-ilmoituksia asiakkaille, sekä infrastruktuuriasioita: Zabbix, Graylog2 ja Chef.
Itse asiassa tämä infrastruktuuri on tarpeeton, koska 100 tuhatta voidaan palvella vähemmillä palvelimilla. Mutta siellä oli rautaa - käytimme sitä (meille kerrottiin, että se oli mahdollista - miksi ei).
Go:n plussat
Kun työskentelimme tämän sovelluksen parissa, Gosta tuli ilmi selkeitä etuja.
- Siisti http-kirjasto. Sen avulla voit luoda melko paljon suoraan laatikosta.
- Lisäksi kanavat, joiden avulla pystyimme erittäin helposti toteuttamaan mekanismin ilmoitusten lähettämiseksi asiakkaille.
- Hieno asia, Race-detektori antoi meille mahdollisuuden poistaa useita kriittisiä virheitä (lavainfrastruktuuri). Kaikki, mikä toimii lavastuksessa, käynnistetään, kootaan Race-näppäimellä; ja voimme näin ollen tarkastella lavastusinfrastruktuuria nähdäksemme, mitä mahdollisia ongelmia meillä on.
- Minimalismi ja kielen yksinkertaisuus.
Etsimme kehittäjiä! Jos joku haluaa niin kiitos.
kysymykset
Kysymys yleisöltä (jäljempänä – B): – Minusta tuntuu, että sinulta jäi huomioi yksi tärkeä seikka Fan-outista. Olenko ymmärtänyt oikein, että kun lähetät vastauksen asiakkaalle, estät, jos asiakas ei halua lukea?
NEITI: - Ei, emme estä. Ensinnäkin meillä on tämä kaikki nginxin takana, eli hitaiden asiakkaiden kanssa ei ole ongelmia. Toiseksi asiakkaalla on kanava puskurilla - itse asiassa voimme laittaa sinne jopa sata päivitystä... Jos emme voi kirjoittaa kanavalle, se poistaa sen. Jos näemme, että kanava on estetty, suljemme kanavan, ja siinä kaikki - asiakas muodostaa yhteyden uudelleen, jos ongelmia ilmenee. Siksi tässä ei periaatteessa ole estoa.
in: – Eikö Kuuntele/Ilmoita-palveluun voisi lähettää heti tietueen, ei tunnistetaulukkoa?
NEITI: – Kuuntele/Ilmoita lähettämänsä esilatauksen raja on 8 tuhatta tavua. Periaatteessa lähettäminen olisi mahdollista, jos olisimme tekemisissä pienen tietomäärän kanssa, mutta minusta näyttää siltä, että tämä tapa [tapa, jolla teemme sen] on yksinkertaisesti luotettavampi. Rajoitukset ovat itse Postgresissa.
in: – Saavatko asiakkaat päivityksiä otteluista, joista he eivät ole kiinnostuneita?
NEITI: - Yleisesti ottaen kyllä. Pääsääntöisesti otteluita on meneillään 2-3 rinnakkain, ja silloinkin melko harvoin. Jos asiakas katselee jotain, niin yleensä hän katsoo meneillään olevaa ottelua. Sitten asiakkaalla on paikallinen tietokanta, johon kaikki nämä päivitykset lasketaan, ja jopa ilman Internet-yhteyttä asiakas voi tarkastella kaikkia aiempia osumia, joihin hänellä on päivityksiä. Pohjimmiltaan synkronoimme palvelimella olevan tietokannan asiakkaan paikallisen tietokannan kanssa, jotta hän voi työskennellä offline-tilassa.
in: – Miksi teit oman ORM:n?
Aleksei (yksi Look+:n kehittäjistä): – Tuolloin (se oli vuosi sitten) ORM:ita oli vähemmän kuin nyt, jolloin niitä on aika paljon. Oma suosikkini useimmissa ORM-järjestelmissä on, että useimmat niistä toimivat tyhjillä käyttöliittymillä. Eli näiden ORM:ien menetelmät ovat valmiita ottamaan vastaan mitä tahansa: rakenteen, rakenneosoittimen, numeron, jotain täysin epäolennaista...
ORMmme luo rakenteita tietomallin pohjalta. Itse. Ja siksi kaikki menetelmät ovat konkreettisia, eivät käytä heijastusta jne. He hyväksyvät rakenteet ja odottavat käyttävänsä niitä rakenteita, jotka tulevat.
in: – Kuinka monta henkilöä osallistui?
NEITI: – Alkuvaiheessa osallistui kaksi henkilöä. Aloitimme jossain kesäkuussa ja elokuussa pääosa oli valmis (ensimmäinen versio). Julkaisu ilmestyi syyskuussa.
in: – Kun kuvailet SSE:tä, et käytä aikakatkaisua. Miksi niin?
NEITI: – Rehellisesti sanottuna SSE on edelleen html5-protokolla: SSE-standardi on käsittääkseni suunniteltu kommunikoimaan selaimien kanssa. Siinä on lisäominaisuuksia, jotta selaimet voivat muodostaa yhteyden uudelleen (ja niin edelleen), mutta emme tarvitse niitä, koska meillä oli asiakkaita, jotka pystyivät toteuttamaan minkä tahansa logiikan yhteyden muodostamiseen ja tiedon vastaanottamiseen. Emme tehneet SSE:tä, vaan jotain SSE:n kaltaista. Tämä ei ole itse protokolla.
Ei ollut tarvetta. Ymmärtääkseni asiakkaat ottivat yhteysmekanismin käyttöön melkein tyhjästä. He eivät todellakaan välittäneet.
in: – Mitä muita apuohjelmia käytit?
NEITI: – Käytimme tyylin yhtenäistämiseen aktiivisimmin govet ja golint sekä gofmt. Mitään muuta ei käytetty.
in: – Mitä käytit virheenkorjaukseen?
NEITI: – Virheenkorjaus tehtiin suurelta osin testeillä. Emme käyttäneet mitään debuggeria tai GOP:ta.
in: – Voitko palauttaa dian, jossa Publish-toiminto on toteutettu? Hämmentävätkö yksikirjaimien muuttujien nimet sinua?
NEITI: - Ei. Niillä on melko "kapea" näkyvyys. Niitä ei käytetä missään muualla paitsi täällä (lukuun ottamatta tämän luokan sisäosia), ja se on erittäin kompakti - se kestää vain 7 riviä.
in: – Jotenkin se ei ole vieläkään intuitiivinen...
NEITI: - Ei, ei, tämä on oikea koodi! Kyse ei ole tyylistä. Se on vain niin hyödyllinen, hyvin pieni luokka - vain 3 kenttää luokassa...
NEITI: – Yleisesti ottaen kaikki asiakkaiden kanssa synkronoidut tiedot (kauden ottelut, pelaajat) eivät muutu. Karkeasti sanottuna, jos teemme toisen lajin, jossa meidän on vaihdettava ottelua, otamme yksinkertaisesti kaiken huomioon asiakkaan uudessa versiossa ja asiakkaan vanhat versiot kielletään.
in: – Onko olemassa kolmannen osapuolen riippuvuuden hallintapaketteja?
NEITI: – Käytimme go dep.
in: – Raportin aiheessa oli jotain videosta, mutta videosta ei ollut mitään.
NEITI: – Ei, minulla ei ole videon aiheessa mitään. Sen nimi on "Look+" - se on sovelluksen nimi.
in: – Sanoit, että se suoratoistetaan asiakkaille?
NEITI: – Emme olleet mukana videoiden suoratoistossa. Tämän teki kokonaan Megafon. Kyllä, en sanonut, että sovellus oli MegaFon.
NEITI: – Go – kaikkien tietojen lähettämiseen – tuloksesta, ottelutapahtumista, tilastoista... Go on sovelluksen koko taustaohjelma. Asiakkaan tulee tietää jostain, mitä linkkiä hän käyttää, jotta käyttäjä voi seurata ottelua. Meillä on linkkejä videoihin ja streameihin, jotka on valmistettu.
Muutamia mainoksia 🙂
Kiitos, että pysyt kanssamme. Pidätkö artikkeleistamme? Haluatko nähdä mielenkiintoisempaa sisältöä? Tue meitä tekemällä tilauksen tai suosittelemalla ystäville, , ainutlaatuinen lähtötason palvelimien analogi, jonka me keksimme sinulle: (saatavana RAID1:n ja RAID10:n kanssa, jopa 24 ydintä ja jopa 40 Gt DDR4-muistia).
Dell R730xd 2 kertaa halvempi Equinix Tier IV -palvelinkeskuksessa Amsterdamissa? Vain täällä Alankomaissa! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - alkaen 99 dollaria! Lukea
Lähde: will.com