Mikhail Salosin (baadaye - MS): - Salaam wote! Jina langu ni Michael. Ninafanya kazi kama msanidi wa hali ya nyuma katika Programu ya MC2, na nitazungumza kuhusu kutumia Go katika upande wa nyuma wa programu ya simu ya mkononi ya Look+.
Je, mtu yeyote hapa anapenda hoki?
Kisha maombi haya ni kwa ajili yako. Ni kwa ajili ya Android na iOS na hutumika kutazama matangazo ya matukio mbalimbali ya michezo mtandaoni na kurekodiwa. Maombi pia yana takwimu anuwai, matangazo ya maandishi, meza za mikutano, mashindano na habari zingine muhimu kwa mashabiki.
Pia kwenye programu kuna kitu kama dakika za video, i.e. unaweza kutazama wakati muhimu zaidi wa mechi (malengo, mapigano, mikwaju, n.k.). Ikiwa hutaki kutazama matangazo yote, unaweza kutazama yale ya kuvutia zaidi pekee.
Ulitumia nini katika maendeleo?
Sehemu kuu iliandikwa katika Go. API ambayo wateja wa simu waliwasiliana nayo iliandikwa katika Go. Huduma ya kutuma arifa kwa programu kwa simu za mkononi pia iliandikwa kwa Go. Pia tulilazimika kuandika ORM yetu wenyewe, ambayo tunaweza kuizungumzia siku moja. Kweli, huduma zingine ndogo ziliandikwa kwa Go: kurekebisha ukubwa na kupakia picha kwa wahariri...
Tulitumia PostgreSQL kama hifadhidata. Kiolesura cha mhariri kiliandikwa kwa Ruby on Rails kwa kutumia vito vya ActiveAdmin. Kuingiza takwimu kutoka kwa mtoaji takwimu pia kumeandikwa kwa Ruby.
Kwa majaribio ya API ya mfumo, tulitumia Python unittest. Memcached hutumika kuzima simu za malipo za API, "Chef" hutumika kudhibiti usanidi, Zabbix hutumika kukusanya na kufuatilia takwimu za mfumo wa ndani. Graylog2 ni ya kukusanya kumbukumbu, Slate ni hati za API kwa wateja.
Uchaguzi wa itifaki
Tatizo la kwanza tulilokumbana nalo: tulihitaji kuchagua itifaki ya mwingiliano kati ya watumiaji wa simu za nyuma na wa rununu, kulingana na mambo yafuatayo...
- Sharti muhimu zaidi: data juu ya wateja lazima isasishwe kwa wakati halisi. Hiyo ni, kila mtu ambaye kwa sasa anatazama matangazo anapaswa kupokea sasisho karibu mara moja.
- Ili kurahisisha mambo, tulichukulia kuwa data ambayo imesawazishwa na wateja haijafutwa, lakini inafichwa kwa kutumia alama maalum.
- Aina zote za maombi adimu (kama vile takwimu, nyimbo za timu, takwimu za timu) hupatikana kwa maombi ya kawaida ya GET.
- Kwa kuongezea, mfumo huo ulilazimika kusaidia watumiaji elfu 100 kwa wakati mmoja.
Kulingana na hili, tulikuwa na chaguzi mbili za itifaki:
- Soketi za wavuti. Lakini hatukuhitaji chaneli kutoka kwa mteja hadi kwa seva. Tulihitaji tu kutuma masasisho kutoka kwa seva hadi kwa mteja, kwa hivyo soketi ya wavuti ni chaguo lisilohitajika.
- Matukio ya Kutumwa na Seva (SSE) yalikuja sawa! Ni rahisi sana na kimsingi inakidhi kila kitu tunachohitaji.
Matukio Iliyotumwa na Seva
Maneno machache kuhusu jinsi jambo hili linavyofanya kazi...
Inaendesha juu ya muunganisho wa http. Mteja anatuma ombi, seva hujibu kwa Aina ya Yaliyomo: maandishi/mtiririko wa tukio na haifungi muunganisho na mteja, lakini inaendelea kuandika data kwa unganisho:
Data inaweza kutumwa katika muundo uliokubaliwa na wateja. Kwa upande wetu, tuliituma kwa fomu hii: jina la muundo uliobadilishwa (mtu, mchezaji) lilitumwa kwenye uwanja wa tukio, na JSON iliyo na sehemu mpya, zilizobadilishwa za mchezaji zilitumwa kwenye uwanja wa data.
Sasa hebu tuzungumze kuhusu jinsi mwingiliano yenyewe unavyofanya kazi.
- Jambo la kwanza ambalo mteja hufanya ni kuamua mara ya mwisho maingiliano na huduma yalifanyika: inaangalia hifadhidata yake ya ndani na huamua tarehe ya mabadiliko ya mwisho iliyorekodiwa nayo.
- Inatuma ombi na tarehe hii.
- Kwa kujibu, tunamtumia sasisho zote ambazo zimetokea tangu tarehe hiyo.
- Baada ya hapo, hufanya muunganisho kwenye chaneli ya moja kwa moja na haifungi hadi itahitaji masasisho haya:
Tunamtumia orodha ya mabadiliko: ikiwa mtu anafunga bao, tunabadilisha alama ya mechi, ikiwa anajeruhiwa, hii pia inatumwa kwa wakati halisi. Kwa hivyo, wateja hupokea data iliyosasishwa mara moja katika mlisho wa tukio la mechi. Mara kwa mara, ili mteja aelewe kuwa seva haijafa, kwamba hakuna kitu kilichotokea kwake, tunatuma muhuri wa muda kila sekunde 15 - ili ijue kuwa kila kitu kiko sawa na hakuna haja ya kuunganisha tena.
Je, muunganisho wa moja kwa moja unahudumiwa vipi?
- Kwanza kabisa, tunaunda kituo ambacho masasisho yaliyoakibishwa yatapokelewa.
- Baada ya hapo, tunajiunga na kituo hiki ili kupata sasisho.
- Tunaweka kichwa sahihi ili mteja ajue kuwa kila kitu ni sawa.
- Tuma ping ya kwanza. Tunarekodi tu muhuri wa wakati wa muunganisho wa sasa.
- Baada ya hayo, tunasoma kutoka kwa kituo kwa kitanzi hadi kituo cha sasisho kimefungwa. Kituo hupokea mara kwa mara muhuri wa wakati wa sasa au mabadiliko ambayo tayari tunaandika ili kufungua miunganisho.
Shida ya kwanza tuliyokutana nayo ilikuwa ifuatayo: kwa kila kiunganisho kilichofunguliwa na mteja, tuliunda kipima saa ambacho kilitikisa mara moja kila sekunde 15 - inabadilika kuwa ikiwa tungekuwa na viunganisho elfu 6 vilivyofunguliwa na mashine moja (na seva moja ya API), 6. vipima muda elfu viliundwa. Hii ilisababisha mashine kutoshikilia mzigo unaohitajika. Tatizo halikuwa wazi kwetu, lakini tulipata usaidizi kidogo na kulitatua.
Kama matokeo, sasa ping yetu inatoka kwa kituo sawa ambacho sasisho hutoka.
Ipasavyo, kuna kipima saa kimoja tu ambacho hujibu mara moja kila sekunde 15.
Kuna kazi kadhaa za msaidizi hapa - kutuma kichwa, ping na muundo yenyewe. Hiyo ni, jina la jedwali (mtu, mechi, msimu) na habari kuhusu kiingilio hiki hupitishwa hapa:
Utaratibu wa kutuma sasisho
Sasa kidogo juu ya wapi mabadiliko yanatoka. Tuna watu kadhaa, wahariri, ambao hutazama matangazo kwa wakati halisi. Wanaunda matukio yote: mtu alitolewa nje, mtu alijeruhiwa, aina fulani ya uingizwaji ...
Kwa kutumia CMS, data huingia kwenye hifadhidata. Baada ya hayo, hifadhidata huarifu seva za API kuhusu hili kwa kutumia utaratibu wa Sikiliza/Arifu. Seva za API tayari hutuma taarifa hii kwa wateja. Kwa hivyo, kimsingi tuna seva chache tu zilizounganishwa kwenye hifadhidata na hakuna mzigo maalum kwenye hifadhidata, kwa sababu mteja haingiliani moja kwa moja na hifadhidata kwa njia yoyote:
PostgreSQL: Sikiliza/Arifu
Utaratibu wa Sikiliza/Arifu katika Postgres hukuruhusu kuwaarifu wanaofuatilia tukio kuwa tukio fulani limebadilika - rekodi fulani imeundwa katika hifadhidata. Ili kufanya hivyo, tuliandika kichocheo rahisi na kazi:
Wakati wa kuingiza au kubadilisha rekodi, tunaita kazi ya arifa kwenye kituo cha data_updates, tukipitisha hapo jina la jedwali na kitambulisho cha rekodi iliyobadilishwa au kuingizwa.
Kwa meza zote zinazohitaji kusawazishwa na mteja, tunafafanua kichochezi, ambacho, baada ya kubadilisha / kusasisha rekodi, huita kazi iliyoonyeshwa kwenye slaidi hapa chini.
Je, API inajiandikisha vipi kwa mabadiliko haya?
Utaratibu wa Fanout umeundwa - hutuma ujumbe kwa mteja. Inakusanya chaneli zote za wateja na kutuma sasisho ilizopokea kupitia chaneli hizi:
Hapa maktaba ya kawaida ya pq, ambayo inaunganisha kwenye hifadhidata na inasema kwamba inataka kusikiliza kituo (data_updates), huangalia kuwa uunganisho umefunguliwa na kila kitu ni sawa. Ninaacha kuangalia makosa ili kuokoa nafasi (kutoangalia ni hatari).
Ifuatayo, tunaweka Ticker kwa usawa, ambayo itatuma ping kila sekunde 15, na kuanza kusikiliza kituo tulichojiandikisha. Ikiwa tunapokea ping, tunachapisha ping hii. Ikiwa tutapokea aina fulani ya ingizo, basi tutachapisha ingizo hili kwa waliojisajili wa Fanout hii.
Fan-out inafanyaje kazi?
Kwa Kirusi, hii inatafsiriwa kama "splitter". Tuna kitu kimoja ambacho husajili wasajili wanaotaka kupokea masasisho fulani. Na mara tu sasisho linapofika kwa kifaa hiki, husambaza sasisho hili kwa watumiaji wake wote. Rahisi kutosha:
Jinsi inatekelezwa katika Go:
Kuna muundo, ni synchronized kwa kutumia Mutexes. Inayo uwanja unaohifadhi hali ya unganisho la Fanout kwenye hifadhidata, i.e. inasikika kwa sasa na itapokea sasisho, na pia orodha ya chaneli zote zinazopatikana - ramani, ambayo ufunguo wake ni chaneli na muundo katika mfumo wa maadili (kimsingi haijatumika kwa njia yoyote).
Njia mbili - Imeunganishwa na Imekatwa - inatuwezesha kuwaambia Fanout kwamba tuna uhusiano na msingi, umeonekana na kwamba uunganisho kwenye msingi umevunjwa. Katika kesi ya pili, unahitaji kukata muunganisho wa wateja wote na kuwaambia kwamba hawawezi tena kusikiliza chochote na kwamba wanaunganisha tena kwa sababu unganisho kwao umefungwa.
Pia kuna njia ya Kujiandikisha ambayo huongeza kituo kwa "wasikilizaji":
Kuna njia ya Kujiondoa, ambayo huondoa chaneli kutoka kwa wasikilizaji ikiwa mteja atakata muunganisho, pamoja na njia ya Kuchapisha, ambayo hukuruhusu kutuma ujumbe kwa waliojisajili wote.
Swali: - Ni nini kinachopitishwa kupitia chaneli hii?
MS: - Mfano ambao umebadilika au ping hupitishwa (kimsingi nambari tu, nambari kamili).
MS: - Unaweza kutuma chochote, kutuma muundo wowote, kuchapisha - inabadilika kuwa JSON na ndivyo hivyo.
MS: - Tunapokea arifa kutoka kwa Postgres - ina jina la jedwali na kitambulisho. Kulingana na jina la jedwali na kitambulisho, tunapata rekodi tunayohitaji, na kisha tunatuma muundo huu kwa uchapishaji.
Miundombinu
Je, hii inaonekanaje kutoka kwa mtazamo wa miundombinu? Tuna seva 7 za vifaa: moja yao imejitolea kabisa kwa hifadhidata, zingine sita zinaendesha mashine za kawaida. Kuna nakala 6 za API: kila mashine ya kawaida iliyo na API inaendesha kwenye seva tofauti ya vifaa - hii ni ya kuegemea.
Tuna sehemu mbili za mbele ambazo Keepalved imesakinishwa ili kuboresha ufikivu, ili jambo likitokea, sehemu ya mbele inaweza kuchukua nafasi ya nyingine. Pia - nakala mbili za CMS.
Pia kuna mwagizaji wa takwimu. Kuna DB Slave ambayo chelezo hufanywa mara kwa mara. Kuna Pigeon Pusher, programu ambayo hutuma arifa za kushinikiza kwa wateja, pamoja na vitu vya miundombinu: Zabbix, Graylog2 na Chef.
Kwa kweli, miundombinu hii ni ya ziada, kwa sababu elfu 100 inaweza kutumika na seva chache. Lakini kulikuwa na chuma - tuliitumia (tuliambiwa kwamba inawezekana - kwa nini sivyo).
Faida za Go
Baada ya kufanya kazi kwenye programu hii, faida za dhahiri za Go ziliibuka.
- Maktaba nzuri ya http. Kwa hiyo unaweza kuunda mengi kabisa nje ya boksi.
- Pia, vituo ambavyo vilituruhusu kutekeleza kwa urahisi utaratibu wa kutuma arifa kwa wateja.
- Jambo la ajabu Kigunduzi cha Mbio kilituruhusu kuondoa mende kadhaa muhimu (miundombinu ya hatua). Kila kitu kinachofanya kazi kwenye maonyesho kinazinduliwa, kilichoandaliwa na ufunguo wa Mbio; na sisi, ipasavyo, tunaweza kuangalia miundombinu ya jukwaa ili kuona ni shida gani tunazo.
- Minimalism na usahili wa lugha.
Tunatafuta watengenezaji! Ikiwa kuna mtu anataka, tafadhali.
maswali
Swali kutoka kwa hadhira (hapa - B): - Inaonekana kwangu kwamba ulikosa jambo moja muhimu kuhusu Kushabikia. Je, niko sahihi kuelewa kwamba unapotuma jibu kwa mteja, unazuia ikiwa mteja hataki kusoma?
MS: - Hapana, hatuzuii. Kwanza, tunayo haya yote nyuma ya nginx, ambayo ni, hakuna shida na wateja wa polepole. Pili, mteja ana chaneli iliyo na bafa - kwa kweli, tunaweza kuweka hadi sasisho mia hapo ... Ikiwa hatuwezi kuandika kwa kituo, basi kinaifuta. Ikiwa tunaona kuwa kituo kimezuiwa, basi tutafunga chaneli tu, na ndivyo hivyo - mteja ataunganisha tena ikiwa shida yoyote itatokea. Kwa hiyo, kwa kanuni, hakuna kuzuia hapa.
Katika: - Je, haikuwezekana kutuma rekodi mara moja kwa Sikiliza/Arifu, na si jedwali la kitambulisho?
MS: - Sikiliza/Arifu ina kikomo cha baiti elfu 8 kwenye upakiaji wa mapema inayotuma. Kimsingi, ingewezekana kutuma ikiwa tulikuwa tukishughulika na kiasi kidogo cha data, lakini inaonekana kwangu kwamba njia hii [njia tunavyoifanya] ni ya kuaminika zaidi. Vizuizi viko kwenye Postgres yenyewe.
Katika: - Je, wateja hupokea sasisho kuhusu mechi ambazo hawapendezwi nazo?
MS: - Kwa ujumla, ndiyo. Kama sheria, kuna mechi 2-3 zinazoendelea sambamba, na hata hivyo mara chache sana. Ikiwa mteja anatazama kitu, basi kwa kawaida anatazama mechi inayoendelea. Kisha, mteja ana hifadhidata ya ndani ambayo sasisho hizi zote zinaongezwa, na hata bila muunganisho wa Mtandao, mteja anaweza kutazama mechi zote zilizopita ambazo ana sasisho. Kimsingi, tunasawazisha hifadhidata yetu kwenye seva na hifadhidata ya ndani ya mteja ili aweze kufanya kazi nje ya mtandao.
Katika: - Kwa nini umetengeneza ORM yako mwenyewe?
Alexey (mmoja wa watengenezaji wa Look+): - Wakati huo (ilikuwa mwaka mmoja uliopita) kulikuwa na ORM chache kuliko sasa, wakati kuna nyingi sana. Jambo ninalopenda zaidi kuhusu ORM nyingi huko nje ni kwamba nyingi huendesha kwenye miingiliano tupu. Hiyo ni, njia katika ORM hizi ziko tayari kuchukua chochote: muundo, pointer ya muundo, nambari, kitu kisicho na maana kabisa ...
ORM yetu hutengeneza miundo kulingana na muundo wa data. Mimi mwenyewe. Na kwa hiyo njia zote ni halisi, usitumie kutafakari, nk Wanakubali miundo na wanatarajia kutumia miundo hiyo inayokuja.
Katika: - Ni watu wangapi walishiriki?
MS: - Katika hatua ya awali, watu wawili walishiriki. Tulianza mahali fulani mnamo Juni, na mnamo Agosti sehemu kuu ilikuwa tayari (toleo la kwanza). Kulikuwa na kutolewa mnamo Septemba.
Katika: - Ambapo unaelezea SSE, hutumii muda wa kuisha. Kwanini hivyo?
MS: - Kusema kweli, SSE bado ni itifaki ya HTML5: kiwango cha SSE kimeundwa kuwasiliana na vivinjari, ninavyoelewa. Ina vipengele vya ziada ili vivinjari viweze kuunganisha tena (na kadhalika), lakini hatuvihitaji, kwa sababu tulikuwa na wateja ambao wangeweza kutekeleza mantiki yoyote ya kuunganisha na kupokea taarifa. Hatukutengeneza SSE, lakini badala yake kitu sawa na SSE. Hii sio itifaki yenyewe.
Hakukuwa na haja. Kwa kadiri ninavyoelewa, wateja walitekeleza utaratibu wa uunganisho karibu kutoka mwanzo. Hawakujali kabisa.
Katika: Umetumia huduma gani za ziada?
MS: - Tulitumia kikamilifu govet na golint kufanya mtindo kuwa wa umoja, pamoja na gofmt. Hakuna kingine kilichotumika.
Katika: - Umetumia nini kutatua hitilafu?
MS: - Utatuzi ulifanywa kwa kiasi kikubwa kwa kutumia vipimo. Hatukutumia kitatuzi chochote au GOP.
Katika: - Je, unaweza kurudisha slaidi ambapo kazi ya Kuchapisha inatekelezwa? Je, majina ya kubadilika kwa herufi moja yanakuchanganya?
MS: - Hapana. Wana upeo "nyembamba" wa kujulikana. Hazitumiwi popote pengine isipokuwa hapa (isipokuwa kwa watu wa ndani wa darasa hili), na ni ngumu sana - inachukua mistari 7 tu.
Katika: - Kwa njia fulani bado sio angavu ...
MS: - Hapana, hapana, hii ni nambari halisi! Sio kuhusu mtindo. Ni mtaalamu kama huyo, darasa dogo sana - fani 3 tu ndani ya darasa ...
MS: - Kwa ujumla, data yote ambayo imesawazishwa na wateja (mechi za msimu, wachezaji) haibadilika. Kwa kusema, ikiwa tutafanya mchezo mwingine ambao tunahitaji kubadilisha mechi, tutazingatia tu kila kitu katika toleo jipya la mteja, na matoleo ya zamani ya mteja yatapigwa marufuku.
Katika: - Je, kuna vifurushi vyovyote vya usimamizi wa utegemezi wa wahusika wengine?
MS: - Tulitumia kwenda chini.
Katika: - Kulikuwa na kitu kuhusu video katika mada ya ripoti, lakini hakukuwa na chochote katika ripoti kuhusu video.
MS: - Hapana, sina chochote katika mada kuhusu video. Inaitwa "Angalia +" - hilo ndilo jina la programu.
Katika: - Ulisema kwamba inatiririshwa kwa wateja? ..
MS: - Hatukuhusika katika kutiririsha video. Hii ilifanywa kabisa na Megafon. Ndiyo, sikusema kwamba programu ilikuwa MegaFon.
MS: - Nenda - kwa kutuma data yote - juu ya alama, matukio ya mechi, takwimu... Go ndio mandhari yote ya nyuma ya programu. Mteja lazima ajue kutoka mahali fulani kiungo cha kutumia kwa mchezaji ili mtumiaji aweze kutazama mechi. Tuna viungo vya video na mitiririko ambavyo vimetayarishwa.
Baadhi ya matangazo π
Asante kwa kukaa nasi. Je, unapenda makala zetu? Je, ungependa kuona maudhui ya kuvutia zaidi? Tuunge mkono kwa kuweka agizo au kupendekeza kwa marafiki, , analogi ya kipekee ya seva za kiwango cha kuingia, ambayo ilivumbuliwa na sisi kwa ajili yako: (inapatikana kwa RAID1 na RAID10, hadi cores 24 na hadi 40GB DDR4).
Dell R730xd 2x nafuu katika kituo cha data cha Equinix Tier IV huko Amsterdam? Hapa tu nchini Uholanzi! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - kutoka $99! Soma kuhusu
Chanzo: mapenzi.com