Mikhail Salosin (o hyn ymlaen - MS): - Helo bawb! Fy enw i yw Michael. Rwy'n gweithio fel datblygwr backend yn MC2 Software, a byddaf yn siarad am ddefnyddio Go yng nghefn y cymhwysiad symudol Look +.
Oes rhywun yma yn hoffi hoci?
Yna mae'r cais hwn ar eich cyfer chi. Mae ar gyfer Android ac iOS ac fe'i defnyddir i wylio darllediadau o ddigwyddiadau chwaraeon amrywiol ar-lein ac wedi'u recordio. Mae'r cymhwysiad hefyd yn cynnwys ystadegau amrywiol, darllediadau testun, tablau ar gyfer cynadleddau, twrnameintiau a gwybodaeth arall sy'n ddefnyddiol i gefnogwyr.
Hefyd yn y cais mae y fath beth ag eiliadau fideo, h.y. gallwch wylio'r eiliadau pwysicaf o gemau (nodau, ymladd, saethu, ac ati). Os nad ydych chi eisiau gwylio'r darllediad cyfan, dim ond y rhai mwyaf diddorol y gallwch chi eu gwylio.
Beth wnaethoch chi ei ddefnyddio wrth ddatblygu?
Ysgrifenwyd y brif ran yn Go. Ysgrifennwyd yr API y bu cleientiaid symudol yn cyfathrebu â nhw yn Go. Ysgrifennwyd gwasanaeth ar gyfer anfon hysbysiadau gwthio i ffonau symudol hefyd yn Go. Roedd yn rhaid i ni hefyd ysgrifennu ein ORM ein hunain, y gallem siarad amdano rywbryd. Wel, ysgrifennwyd rhai gwasanaethau bach yn Go: newid maint a llwytho delweddau ar gyfer y golygyddion...
Defnyddiwyd PostgreSQL fel cronfa ddata. Ysgrifennwyd y rhyngwyneb golygydd yn Ruby on Rails gan ddefnyddio'r berl ActiveAdmin. Mae mewnforio ystadegau gan ddarparwr ystadegau hefyd wedi'i ysgrifennu yn Ruby.
Ar gyfer profion API system, gwnaethom ddefnyddio Python unittest. Defnyddir Memcached i sbarduno galwadau talu API, defnyddir “Chef” i reoli cyfluniad, defnyddir Zabbix i gasglu a monitro ystadegau system fewnol. Mae Graylog2 ar gyfer casglu logiau, mae Slate yn ddogfennaeth API ar gyfer cleientiaid.
Dewis protocol
Y broblem gyntaf y daethom ar ei thraws: roedd angen i ni ddewis protocol ar gyfer rhyngweithio rhwng y backend a chleientiaid symudol, yn seiliedig ar y pwyntiau canlynol ...
- Y gofyniad pwysicaf: rhaid diweddaru data ar gleientiaid mewn amser real. Hynny yw, dylai pawb sy'n gwylio'r darllediad ar hyn o bryd dderbyn diweddariadau bron yn syth.
- Er mwyn symleiddio pethau, rydym yn cymryd yn ganiataol nad yw data sy'n cael ei gysoni â chleientiaid yn cael ei ddileu, ond yn cael ei guddio gan ddefnyddio baneri arbennig.
- Ceir pob math o geisiadau prin (fel ystadegau, cyfansoddiadau tîm, ystadegau tîm) trwy geisiadau GET arferol.
- Hefyd, roedd yn rhaid i'r system gefnogi 100 mil o ddefnyddwyr yn hawdd ar yr un pryd.
Yn seiliedig ar hyn, roedd gennym ddau opsiwn protocol:
- Socedi gwe. Ond nid oedd angen sianeli arnom o'r cleient i'r gweinydd. Nid oedd angen i ni ond anfon diweddariadau o'r gweinydd i'r cleient, felly nid oes angen soced gwe.
- Daeth Digwyddiadau a Anfonwyd gan Weinyddwyr (SSE) i fyny yn iawn! Mae'n eithaf syml ac yn y bôn mae'n bodloni popeth sydd ei angen arnom.
Digwyddiadau a Anfonwyd gan y Gweinydd
Ychydig eiriau am sut mae'r peth hwn yn gweithio ...
Mae'n rhedeg ar ben cysylltiad http. Mae'r cleient yn anfon cais, mae'r gweinydd yn ymateb gyda Content-Type: text/event-stream ac nid yw'n cau'r cysylltiad â'r cleient, ond mae'n parhau i ysgrifennu data i'r cysylltiad:
Gellir anfon data mewn fformat y cytunwyd arno gyda chleientiaid. Yn ein hachos ni, fe wnaethom ei anfon yn y ffurflen hon: anfonwyd enw'r strwythur newydd (person, chwaraewr) i faes y digwyddiad, ac anfonwyd JSON gyda meysydd newydd, wedi'u newid ar gyfer y chwaraewr i'r maes data.
Nawr, gadewch i ni siarad am sut mae'r rhyngweithio ei hun yn gweithio.
- Y peth cyntaf y mae'r cleient yn ei wneud yw pennu'r tro diwethaf i gydamseru â'r gwasanaeth gael ei berfformio: mae'n edrych ar ei gronfa ddata leol ac yn pennu dyddiad y newid diwethaf a gofnodwyd ganddo.
- Mae'n anfon cais gyda'r dyddiad hwn.
- Mewn ymateb, rydym yn anfon ato yr holl ddiweddariadau sydd wedi digwydd ers y dyddiad hwnnw.
- Ar ôl hynny, mae'n gwneud cysylltiad â'r sianel fyw ac nid yw'n cau nes bod angen y diweddariadau hyn arno:
Rydyn ni'n anfon rhestr o newidiadau ato: os yw rhywun yn sgorio gôl, rydyn ni'n newid sgôr y gêm, os yw'n cael ei anafu, mae hwn hefyd yn cael ei anfon mewn amser real. Felly, mae cleientiaid yn derbyn y data diweddaraf ar unwaith yn y porthiant digwyddiadau gêm. O bryd i'w gilydd, fel bod y cleient yn deall nad yw'r gweinydd wedi marw, na ddigwyddodd dim iddo, rydym yn anfon stamp amser bob 15 eiliad - fel ei fod yn gwybod bod popeth mewn trefn ac nid oes angen ailgysylltu.
Sut mae'r cysylltiad byw yn cael ei wasanaethu?
- Yn gyntaf oll, rydym yn creu sianel y derbynnir diweddariadau byffer iddi.
- Ar ôl hynny, rydym yn tanysgrifio i'r sianel hon i dderbyn diweddariadau.
- Rydym yn gosod y pennawd cywir fel bod y cleient yn gwybod bod popeth yn iawn.
- Anfonwch y ping cyntaf. Yn syml, rydym yn cofnodi'r stamp amser cysylltiad cyfredol.
- Ar ôl hynny, rydym yn darllen o'r sianel mewn dolen nes bod y sianel diweddaru ar gau. O bryd i'w gilydd mae'r sianel yn derbyn naill ai'r stamp amser presennol neu'r newidiadau yr ydym eisoes yn eu hysgrifennu i agor cysylltiadau.
Y broblem gyntaf y daethom ar ei thraws oedd y canlynol: ar gyfer pob cysylltiad a agorwyd gyda'r cleient, fe wnaethom greu amserydd a oedd yn ticio unwaith bob 15 eiliad - mae'n ymddangos pe bai gennym ni 6 mil o gysylltiadau ar agor gydag un peiriant (gydag un gweinydd API), 6 crëwyd mil o amserwyr. Arweiniodd hyn at y peiriant ddim yn dal y llwyth gofynnol. Nid oedd y broblem mor amlwg â hynny i ni, ond cawsom ychydig o help a'i thrwsio.
O ganlyniad, nawr mae ein ping yn dod o'r un sianel y daw'r diweddariad ohoni.
Yn unol â hynny, dim ond un amserydd sy'n ticio unwaith bob 15 eiliad.
Mae sawl swyddogaeth ategol yma - anfon y pennawd, ping a'r strwythur ei hun. Hynny yw, mae enw'r tabl (person, gêm, tymor) a'r wybodaeth am y cofnod hwn yn cael eu trosglwyddo yma:
Mecanwaith ar gyfer anfon diweddariadau
Nawr ychydig am o ble mae'r newidiadau'n dod. Mae gennym ni nifer o bobl, golygyddion, sy'n gwylio'r darllediad mewn amser real. Maen nhw'n creu'r holl ddigwyddiadau: cafodd rhywun ei anfon i ffwrdd, anafwyd rhywun, rhyw fath o rywun arall yn ei le ...
Gan ddefnyddio CMS, mae data'n mynd i mewn i'r gronfa ddata. Ar ôl hyn, mae'r gronfa ddata yn hysbysu'r gweinyddwyr API am hyn gan ddefnyddio'r mecanwaith Gwrando / Hysbysu. Mae gweinyddwyr API eisoes yn anfon y wybodaeth hon at gleientiaid. Felly, yn y bôn, dim ond ychydig o weinyddion sydd gennym wedi'u cysylltu â'r gronfa ddata ac nid oes llwyth arbennig ar y gronfa ddata, oherwydd nid yw'r cleient yn rhyngweithio'n uniongyrchol â'r gronfa ddata mewn unrhyw ffordd:
PostgreSQL: Gwrando / Hysbysu
Mae'r mecanwaith Gwrando/Hysbysu yn Postgres yn eich galluogi i hysbysu tanysgrifwyr digwyddiadau bod rhyw ddigwyddiad wedi newid - mae rhywfaint o gofnod wedi'i greu yn y gronfa ddata. I wneud hyn, fe wnaethom ysgrifennu sbardun a swyddogaeth syml:
Wrth fewnosod neu newid cofnod, rydym yn galw'r swyddogaeth hysbysu ar y sianel data_updates, gan basio yno enw'r tabl a dynodwr y cofnod a newidiwyd neu a fewnosodwyd.
Ar gyfer pob tabl y mae'n rhaid ei gydamseru â'r cleient, rydym yn diffinio sbardun, sydd, ar ôl newid / diweddaru cofnod, yn galw'r swyddogaeth a nodir ar y sleid isod.
Sut mae'r API yn tanysgrifio i'r newidiadau hyn?
Mae mecanwaith Fanout yn cael ei greu - mae'n anfon negeseuon at y cleient. Mae'n casglu'r holl sianeli cwsmeriaid ac yn anfon diweddariadau a gafodd trwy'r sianeli hyn:
Yma mae'r llyfrgell pq safonol, sy'n cysylltu â'r gronfa ddata ac yn dweud ei fod am wrando ar y sianel (data_updates), yn gwirio bod y cysylltiad ar agor a bod popeth yn iawn. Rwy'n hepgor gwirio gwallau i arbed lle (nid yw gwirio yn beryglus).
Nesaf, rydym yn gosod Ticker yn asyncronig, a fydd yn anfon ping bob 15 eiliad, ac yn dechrau gwrando ar y sianel y gwnaethom danysgrifio iddi. Os cawn ping, cyhoeddwn y ping hwn. Os byddwn yn derbyn rhyw fath o gofnod, yna rydym yn cyhoeddi'r cofnod hwn i holl danysgrifwyr y Fanout hwn.
Sut mae Fan-out yn gweithio?
Yn Rwsieg mae hyn yn cyfieithu fel “hollti”. Mae gennym un gwrthrych sy'n cofrestru tanysgrifwyr sydd am dderbyn rhai diweddariadau. A chyn gynted ag y bydd diweddariad yn cyrraedd y gwrthrych hwn, mae'n dosbarthu'r diweddariad hwn i'w holl danysgrifwyr. Digon syml:
Sut mae'n cael ei weithredu yn Go:
Mae yna strwythur, mae'n cael ei gydamseru gan ddefnyddio Mutexes. Mae ganddo faes sy'n arbed cyflwr cysylltiad Fanout â'r gronfa ddata, h.y. mae'n gwrando ar hyn o bryd a bydd yn derbyn diweddariadau, yn ogystal â rhestr o'r holl sianeli sydd ar gael - map, a'r allwedd yw'r sianel a'r strwythur ar ffurf gwerthoedd (yn y bôn nid yw'n cael ei ddefnyddio mewn unrhyw ffordd).
Mae dau ddull - Cysylltiedig a Datgysylltu - yn ein galluogi i ddweud wrth Fanout fod gennym gysylltiad â'r sylfaen, mae wedi ymddangos a bod y cysylltiad â'r sylfaen wedi'i dorri. Yn yr ail achos, mae angen i chi ddatgysylltu pob cleient a dweud wrthynt na allant wrando ar unrhyw beth mwyach a'u bod yn ailgysylltu oherwydd bod y cysylltiad â nhw wedi cau.
Mae yna hefyd ddull Tanysgrifio sy'n ychwanegu'r sianel at y “gwrandawyr”:
Mae yna ddull Dad-danysgrifio, sy'n tynnu'r sianel oddi wrth wrandawyr os yw'r cleient yn datgysylltu, yn ogystal â dull Cyhoeddi, sy'n eich galluogi i anfon neges at bob tanysgrifiwr.
Cwestiwn: - Beth sy'n cael ei drosglwyddo trwy'r sianel hon?
MS: – Mae'r model sydd wedi newid neu ping yn cael ei drosglwyddo (yn y bôn dim ond rhif, cyfanrif).
MS: - Gallwch chi anfon unrhyw beth, anfon unrhyw strwythur, ei gyhoeddi - mae'n troi'n JSON a dyna ni.
MS: – Rydym yn derbyn hysbysiad gan Postgres – mae’n cynnwys enw’r tabl a’r dynodwr. Yn seiliedig ar enw'r tabl a'r dynodwr, rydym yn cael y cofnod sydd ei angen arnom, ac yna rydym yn anfon y strwythur hwn i'w gyhoeddi.
Isadeiledd
Sut olwg sydd ar hyn o safbwynt seilwaith? Mae gennym 7 gweinydd caledwedd: mae un ohonynt wedi'i neilltuo'n llwyr i'r gronfa ddata, ac mae'r chwech arall yn rhedeg peiriannau rhithwir. Mae 6 chopi o'r API: mae pob peiriant rhithwir gyda'r API yn rhedeg ar weinydd caledwedd ar wahân - mae hyn ar gyfer dibynadwyedd.
Mae gennym ddau flaen blaen gyda Keepalived wedi'u gosod i wella hygyrchedd, felly os bydd rhywbeth yn digwydd, gall un blaen blaen gymryd lle'r llall. Hefyd – dau gopi o'r CMS.
Mae yna hefyd fewnforiwr ystadegau. Mae yna Gaethwas DB y gwneir copïau wrth gefn ohono o bryd i'w gilydd. Mae yna Pigeon Pusher, cymhwysiad sy'n anfon hysbysiadau gwthio i gleientiaid, yn ogystal â phethau seilwaith: Zabbix, Graylog2 a Chef.
Mewn gwirionedd, mae'r seilwaith hwn yn ddiangen, oherwydd gellir gwasanaethu 100 mil gyda llai o weinyddion. Ond roedd haearn - fe wnaethon ni ei ddefnyddio (fe ddywedwyd wrthym ei fod yn bosibl - pam lai).
Manteision Go
Ar ôl i ni weithio ar y cais hwn, daeth manteision mor amlwg Go i'r amlwg.
- Llyfrgell http oer. Ag ef gallwch chi greu cryn dipyn allan o'r bocs.
- Hefyd, sianeli a oedd yn caniatáu inni weithredu mecanwaith ar gyfer anfon hysbysiadau at gleientiaid yn hawdd iawn.
- Caniataodd y synhwyrydd Hil peth rhyfeddol inni ddileu sawl byg critigol (seilwaith llwyfannu). Mae popeth sy'n gweithio ar lwyfannu yn cael ei lansio, wedi'i lunio gyda'r allwedd Race; a gallwn, yn unol â hynny, edrych ar y seilwaith llwyfannu i weld pa broblemau posibl sydd gennym.
- Minimaliaeth a symlrwydd iaith.
Rydym yn chwilio am ddatblygwyr! Os oes unrhyw un eisiau, os gwelwch yn dda.
cwestiynau
Cwestiwn gan y gynulleidfa (o hyn ymlaen – B): – Mae’n ymddangos i mi eich bod wedi methu un pwynt pwysig ynglŷn â Fan-out. A ydw i'n gywir wrth ddeall, pan fyddwch chi'n anfon ymateb at gleient, eich bod chi'n blocio os nad yw'r cleient eisiau darllen?
MS: - Na, nid ydym yn rhwystro. Yn gyntaf, mae gennym hyn i gyd y tu ôl i nginx, hynny yw, nid oes unrhyw broblemau gyda chleientiaid araf. Yn ail, mae gan y cleient sianel gyda byffer - mewn gwirionedd, gallwn roi hyd at gant o ddiweddariadau yno... Os na allwn ysgrifennu at y sianel, yna mae'n ei dileu. Os gwelwn fod y sianel wedi'i rhwystro, yna byddwn yn cau'r sianel yn syml, a dyna ni - bydd y cleient yn ailgysylltu os bydd unrhyw broblem yn codi. Felly, mewn egwyddor, nid oes unrhyw rwystro yma.
AT: – Oni fyddai’n bosibl anfon cofnod ar unwaith i Wrando/Hysbysu, ac nid tabl adnabod?
MS: - Mae gan Listen/Notify derfyn o 8 mil beit ar y rhaglwyth y mae'n ei anfon. Mewn egwyddor, byddai’n bosibl anfon pe baem yn ymdrin â swm bach o ddata, ond mae’n ymddangos i mi fod y ffordd hon [y ffordd yr ydym yn ei wneud] yn syml yn fwy dibynadwy. Mae'r cyfyngiadau yn Postgres ei hun.
AT: – A yw cleientiaid yn derbyn diweddariadau ar barau nad oes ganddynt ddiddordeb ynddynt?
MS: - Yn gyffredinol, ie. Fel rheol, mae 2-3 gêm yn digwydd ochr yn ochr, a hyd yn oed wedyn yn eithaf anaml. Os yw cleient yn gwylio rhywbeth, yna fel arfer mae'n gwylio'r gêm sy'n digwydd. Yna, mae gan y cleient gronfa ddata leol y mae'r holl ddiweddariadau hyn yn cael eu hadio ynddi, a hyd yn oed heb gysylltiad Rhyngrwyd, gall y cleient weld yr holl gemau blaenorol y mae ganddo ddiweddariadau ar eu cyfer. Yn y bôn, rydym yn cydamseru ein cronfa ddata ar y gweinydd â chronfa ddata leol y cleient fel y gall weithio all-lein.
AT: – Pam wnaethoch chi wneud eich ORM eich hun?
Alexey (un o ddatblygwyr Look+): – Bryd hynny (roedd hi flwyddyn yn ôl) roedd llai o ORMs nag ar hyn o bryd, pan mae cryn dipyn ohonyn nhw. Fy hoff beth am y mwyafrif o ORMs allan yna yw bod y mwyafrif ohonyn nhw'n rhedeg ar ryngwynebau gwag. Hynny yw, mae'r dulliau yn yr ORMs hyn yn barod i ymgymryd ag unrhyw beth: strwythur, pwyntydd strwythur, rhif, rhywbeth cwbl amherthnasol ...
Mae ein ORM yn cynhyrchu strwythurau yn seiliedig ar y model data. Fi fy hun. Ac felly mae pob dull yn goncrid, peidiwch â defnyddio adlewyrchiad, ac ati Maent yn derbyn strwythurau ac yn disgwyl defnyddio'r strwythurau hynny a ddaw.
AT: – Faint o bobl gymerodd ran?
MS: – Yn y cam cychwynnol, cymerodd dau berson ran. Dechreuon ni yn rhywle ym mis Mehefin, ac ym mis Awst roedd y brif ran yn barod (y fersiwn gyntaf). Roedd rhyddhau ym mis Medi.
AT: – Pan fyddwch yn disgrifio SSE, nid ydych yn defnyddio terfyn amser. Pam hynny?
MS: – I fod yn onest, mae SSE yn dal i fod yn brotocol html5: mae safon SSE wedi'i gynllunio i gyfathrebu â phorwyr, hyd y deallaf. Mae ganddo nodweddion ychwanegol fel y gall porwyr ailgysylltu (ac yn y blaen), ond nid oes eu hangen arnom, oherwydd roedd gennym gleientiaid a allai weithredu unrhyw resymeg ar gyfer cysylltu a derbyn gwybodaeth. Ni wnaethom SSE, ond yn hytrach rhywbeth tebyg i SSE. Nid dyma'r protocol ei hun.
Nid oedd angen. Cyn belled ag y deallaf, gweithredodd cleientiaid y mecanwaith cysylltu bron o'r dechrau. Doedd dim ots ganddyn nhw.
AT: – Pa gyfleustodau ychwanegol wnaethoch chi eu defnyddio?
MS: - Fe wnaethon ni ddefnyddio govet a golint yn fwyaf gweithredol i wneud yr arddull yn unedig, yn ogystal â gofmt. Ni ddefnyddiwyd dim arall.
AT: – Beth wnaethoch chi ei ddefnyddio i ddadfygio?
MS: – Roedd dadfygio yn cael ei wneud i raddau helaeth gan ddefnyddio profion. Ni wnaethom ddefnyddio unrhyw ddadfygiwr na GOP.
AT: – Allwch chi ddychwelyd y sleid lle mae'r swyddogaeth Cyhoeddi yn cael ei gweithredu? Ydy enwau newidyn un llythyren yn eich drysu?
MS: - Nac ydy. Mae ganddynt gwmpas gweddol “gul” o welededd. Nid ydynt yn cael eu defnyddio yn unman arall ac eithrio yma (ac eithrio ar gyfer mewnol y dosbarth hwn), ac mae'n gryno iawn - dim ond 7 llinell y mae'n ei gymryd.
AT: - Rhywsut nid yw'n reddfol o hyd ...
MS: - Na, na, mae hwn yn god go iawn! Nid yw'n ymwneud ag arddull. Dosbarth mor iwtilitaraidd, bach iawn ydyw - dim ond 3 maes y tu mewn i'r dosbarth...
MS: - Ar y cyfan, nid yw'r holl ddata sy'n cael ei gydamseru â chleientiaid (gemau tymor, chwaraewyr) yn newid. Yn fras, os byddwn yn gwneud camp arall lle mae angen i ni newid y gêm, byddwn yn cymryd popeth i ystyriaeth yn fersiwn newydd y cleient, a bydd hen fersiynau'r cleient yn cael eu gwahardd.
AT: – A oes unrhyw becynnau rheoli dibyniaeth trydydd parti?
MS: - Roedden ni'n arfer mynd dep.
AT: – Roedd rhywbeth am fideo yn nhestun yr adroddiad, ond nid oedd unrhyw beth yn yr adroddiad am fideo.
MS: - Na, nid oes gennyf unrhyw beth yn y pwnc am y fideo. Fe'i gelwir yn "Look +" - dyna enw'r cais.
AT: - Dywedasoch ei fod yn cael ei ffrydio i gleientiaid? ..
MS: - Nid oeddem yn ymwneud â ffrydio fideo. Gwnaed hyn yn gyfan gwbl gan Megafon. Do, ni ddywedais mai MegaFon oedd y cais.
MS: – Ewch – ar gyfer anfon yr holl ddata – ar y sgôr, ar ddigwyddiadau gêm, ystadegau... Go yw ôl-wyneb cyfan y cais. Rhaid i'r cleient wybod o rywle pa ddolen i'w defnyddio ar gyfer y chwaraewr fel y gall y defnyddiwr wylio'r gêm. Mae gennym ddolenni i fideos a ffrydiau sydd wedi'u paratoi.
Rhai hysbysebion 🙂
Diolch am aros gyda ni. Ydych chi'n hoffi ein herthyglau? Eisiau gweld cynnwys mwy diddorol? Cefnogwch ni trwy osod archeb neu argymell i ffrindiau, , analog unigryw o weinyddion lefel mynediad, a ddyfeisiwyd gennym ni ar eich cyfer chi: (ar gael gyda RAID1 a RAID10, hyd at 24 craidd a hyd at 40GB DDR4).
Dell R730xd 2 gwaith yn rhatach yng nghanolfan ddata Equinix Haen IV yn Amsterdam? Dim ond yma yn yr Iseldiroedd! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - o $99! Darllenwch am
Ffynhonnell: hab.com