Միխայիլ Սալոսին (այսուհետ՝ MS). - Բարեւ բոլորին! Իմ անունը Մայքլ է։ Ես աշխատում եմ որպես backend-ի ծրագրավորող MC2 Software-ում և կխոսեմ Go-ի օգտագործման մասին Look+ բջջային հավելվածի հետնամասում։
Այստեղ որևէ մեկը հոկեյ սիրու՞մ է:
Ապա այս հավելվածը ձեզ համար է: Այն Android-ի և iOS-ի համար է և օգտագործվում է առցանց տարբեր մարզական իրադարձությունների հեռարձակումները դիտելու և ձայնագրելու համար: Հավելվածը պարունակում է նաև տարբեր վիճակագրություն, տեքստային հեռարձակումներ, համաժողովների, մրցաշարերի աղյուսակներ և երկրպագուների համար օգտակար այլ տեղեկություններ:
Հավելվածում կա նաև վիդեո պահեր, այսինքն՝ կարող եք դիտել հանդիպումների ամենակարևոր պահերը (գոլեր, մենամարտեր, փոխհրաձգություններ և այլն): Եթե չեք ցանկանում դիտել ամբողջ հեռարձակումը, կարող եք դիտել միայն ամենահետաքրքիրները:
Ի՞նչ եք օգտագործել զարգացման մեջ:
Հիմնական մասը գրվել է Go-ում։ API-ն, որի հետ շփվում էին բջջային հաճախորդները, գրված էր Go-ում: Go-ում գրվել է նաև բջջային հեռախոսներին push ծանուցումներ ուղարկելու ծառայություն։ Մենք նաև պետք է գրեինք մեր սեփական ORM-ը, որի մասին կարող ենք մի օր խոսել: Դե, Go-ում գրվել են մի քանի փոքր ծառայություններ՝ չափափոխել և բեռնել նկարները խմբագիրների համար...
Մենք օգտագործել ենք PostgreSQL որպես տվյալների բազա: Խմբագրի ինտերֆեյսը գրվել է Ruby on Rails-ով, օգտագործելով ActiveAdmin գոհարը: Վիճակագրության մատակարարից վիճակագրություն ներմուծելը նույնպես գրված է Ruby-ով:
Համակարգի API թեստերի համար մենք օգտագործել ենք Python unittest-ը: Memcached-ը օգտագործվում է API-ի վճարման զանգերը կարգավորելու համար, «Chef»-ը՝ կոնֆիգուրացիան վերահսկելու համար, Zabbix-ը՝ հավաքագրելու և վերահսկելու ներքին համակարգի վիճակագրությունը: Graylog2-ը տեղեկամատյաններ հավաքելու համար է, Slate-ը API-ի փաստաթղթեր է հաճախորդների համար:
Արձանագրության ընտրություն
Առաջին խնդիրը, որին հանդիպեցինք. մենք պետք է ընտրեինք պրոտոկոլ backend-ի և բջջային հաճախորդների միջև փոխգործակցության համար՝ հիմնվելով հետևյալ կետերի վրա...
- Ամենակարևոր պահանջը. հաճախորդների վերաբերյալ տվյալները պետք է թարմացվեն իրական ժամանակում: Այսինքն, բոլորը, ովքեր ներկայումս դիտում են հեռարձակումը, պետք է թարմացումներ ստանան գրեթե ակնթարթորեն:
- Իրերը պարզեցնելու համար մենք ենթադրեցինք, որ տվյալները, որոնք համաժամանակացված են հաճախորդների հետ, չեն ջնջվում, այլ թաքնված են հատուկ դրոշների միջոցով:
- Բոլոր տեսակի հազվագյուտ հարցումները (օրինակ՝ վիճակագրություն, թիմային կազմ, թիմային վիճակագրություն) ստացվում են սովորական GET հարցումներով:
- Բացի այդ, համակարգը պետք է հեշտությամբ աջակցեր 100 հազար օգտատերերի միաժամանակ։
Դրա հիման վրա մենք ունեինք երկու արձանագրային տարբերակ.
- Վեբ վարդակներ. Բայց մեզ պետք չէին հաճախորդից սերվեր ալիքներ: Մեզ անհրաժեշտ էր միայն թարմացումներ ուղարկել սերվերից հաճախորդին, ուստի վեբսոկետը ավելորդ տարբերակ է:
- Սերվերի կողմից ուղարկված իրադարձությունները (SSE) ճիշտ հայտնվեցին: Այն բավականին պարզ է և հիմնականում բավարարում է այն ամենը, ինչ մեզ անհրաժեշտ է։
Սերվերի կողմից ուղարկված իրադարձություններ
Մի քանի խոսք այն մասին, թե ինչպես է այս բանն աշխատում...
Այն աշխատում է http կապի վերևում: Հաճախորդը հարցում է ուղարկում, սերվերը պատասխանում է Content-Type՝ text/event-stream և չի փակում կապը հաճախորդի հետ, այլ շարունակում է տվյալներ գրել կապին.
Տվյալները կարող են ուղարկվել հաճախորդների հետ համաձայնեցված ձևաչափով: Մեր դեպքում մենք այն ուղարկել ենք այս ձևով՝ փոփոխված կառուցվածքի (անձ, խաղացող) անվանումն ուղարկվել է իրադարձությունների դաշտ, իսկ JSON՝ խաղացողի համար նոր, փոփոխված դաշտերով՝ տվյալների դաշտ։
Հիմա եկեք խոսենք այն մասին, թե ինչպես է փոխազդեցությունն ինքնին աշխատում:
- Առաջին բանը, որ հաճախորդն անում է, որոշում է, թե երբ է կատարվել վերջին անգամ ծառայության հետ համաժամացումը. նա նայում է իր տեղական տվյալների բազան և որոշում իր կողմից գրանցված վերջին փոփոխության ամսաթիվը:
- Այն հարցում է ուղարկում այս ամսաթվով:
- Ի պատասխան՝ մենք նրան ուղարկում ենք բոլոր թարմացումները, որոնք տեղի են ունեցել այդ օրվանից:
- Դրանից հետո այն միանում է կենդանի ալիքին և չի փակվում այնքան ժամանակ, քանի դեռ նրան պետք չեն այս թարմացումները.
Մենք նրան ուղարկում ենք փոփոխությունների ցուցակը. եթե ինչ-որ մեկը գոլ է խփում, մենք փոխում ենք հանդիպման հաշիվը, եթե նա վնասվածք է ստանում, սա նույնպես ուղարկվում է իրական ժամանակում։ Այսպիսով, հաճախորդները ակնթարթորեն ստանում են արդի տվյալներ համընկնումների իրադարձությունների հոսքում: Պարբերաբար, որպեսզի հաճախորդը հասկանա, որ սերվերը չի մահացել, որ նրան ոչինչ չի պատահել, մենք յուրաքանչյուր 15 վայրկյանը մեկ ժամանակի դրոշմակնիք ենք ուղարկում, որպեսզի նա իմանա, որ ամեն ինչ կարգին է, և կարիք չկա նորից միանալու:
Ինչպե՞ս է սպասարկվում ուղիղ կապը:
- Առաջին հերթին մենք ստեղծում ենք ալիք, որտեղ կստացվեն բուֆերացված թարմացումներ:
- Դրանից հետո մենք բաժանորդագրվում ենք այս ալիքին՝ թարմացումներ ստանալու համար։
- Մենք սահմանել ենք ճիշտ վերնագիր, որպեսզի հաճախորդը իմանա, որ ամեն ինչ կարգին է:
- Ուղարկեք առաջին պինգը: Մենք պարզապես գրանցում ենք ընթացիկ կապի ժամանակացույցը:
- Դրանից հետո մենք կարդում ենք ալիքից ցիկլով մինչև թարմացման ալիքը փակվի: Ալիքը պարբերաբար ստանում է կամ ընթացիկ ժամանակացույցը կամ փոփոխություններ, որոնք մենք արդեն գրում ենք կապեր բացելու համար:
Առաջին խնդիրը, որին հանդիպեցինք, հետևյալն էր. հաճախորդի հետ բացված յուրաքանչյուր կապի համար մենք ստեղծեցինք ժմչփ, որը նշում էր յուրաքանչյուր 15 վայրկյանը մեկ. ստացվում է, որ եթե մենք ունենայինք 6 հազար կապ բաց մեկ մեքենայի հետ (մեկ API սերվերով), 6. ստեղծվել են հազար ժամաչափ: Դա հանգեցրել է նրան, որ մեքենան չի պահել անհրաժեշտ բեռը: Խնդիրն այնքան էլ ակնհայտ չէր մեզ համար, բայց մենք մի փոքր օգնություն ստացանք և ուղղեցինք այն:
Արդյունքում, այժմ մեր պինգը գալիս է նույն ալիքից, որտեղից գալիս է թարմացումը։
Համապատասխանաբար, կա միայն մեկ ժմչփ, որը նշում է 15 վայրկյանը մեկ անգամ:
Այստեղ կան մի քանի օժանդակ գործառույթներ՝ ուղարկելով վերնագիր, ping և հենց կառուցվածքը: Այսինքն՝ աղյուսակի անվանումը (անձ, հանդիպում, մրցաշրջան) և այս գրառման մասին տեղեկությունները փոխանցվում են այստեղ.
Թարմացումներ ուղարկելու մեխանիզմ
Հիմա մի փոքր այն մասին, թե որտեղից են գալիս փոփոխությունները։ Մենք ունենք մի քանի հոգի՝ խմբագիրներ, ովքեր հեռարձակումը դիտում են իրական ժամանակում։ Նրանք ստեղծում են բոլոր իրադարձությունները՝ ինչ-որ մեկը հեռացվել է խաղադաշտից, մեկը վիրավորվել է, ինչ-որ մեկը փոխարինվել է...
CMS-ի միջոցով տվյալները մուտք են գործում տվյալների բազա: Դրանից հետո տվյալների բազան այդ մասին տեղեկացնում է API սերվերներին՝ օգտագործելով Listen/Notify մեխանիզմը: API սերվերներն արդեն ուղարկում են այս տեղեկատվությունը հաճախորդներին: Այսպիսով, մենք, ըստ էության, ունենք տվյալների բազային միացված ընդամենը մի քանի սերվեր, և տվյալների բազայի վրա հատուկ բեռ չկա, քանի որ հաճախորդը որևէ կերպ ուղղակիորեն չի փոխազդում տվյալների բազայի հետ.
PostgreSQL: Լսել/ծանուցել
Postgres-ում Listen/Notify մեխանիզմը թույլ է տալիս ծանուցել իրադարձությունների բաժանորդներին, որ ինչ-որ իրադարձություն փոխվել է. տվյալների բազայում ստեղծվել է որոշակի գրառում: Դա անելու համար մենք գրեցինք պարզ ձգան և գործառույթ.
Գրառում տեղադրելիս կամ փոխելիս մենք զանգում ենք notify ֆունկցիան data_updates ալիքում՝ այնտեղ փոխանցելով աղյուսակի անվանումը և փոփոխված կամ տեղադրվող գրառումի նույնացուցիչը:
Բոլոր աղյուսակների համար, որոնք պետք է համաժամանակացվեն հաճախորդի հետ, մենք սահմանում ենք ձգան, որը գրառումը փոխելուց/թարմացնելուց հետո կանչում է ստորև նշված սլայդում նշված գործառույթը:
Ինչպե՞ս է API-ն բաժանորդագրվում այս փոփոխություններին:
Ստեղծվում է Fanout մեխանիզմ՝ այն հաղորդագրություններ է ուղարկում հաճախորդին: Այն հավաքում է հաճախորդների բոլոր ալիքները և ուղարկում թարմացումները, որոնք ստացել է այս ուղիներով.
Այստեղ ստանդարտ pq գրադարանը, որը միանում է տվյալների շտեմարանին և ասում, որ ուզում է լսել ալիքը (data_updates), ստուգում է, որ կապը բաց է և ամեն ինչ լավ է։ Ես բաց եմ թողնում սխալի ստուգումը` տարածք խնայելու համար (չստուգելը վտանգավոր է):
Հաջորդը, մենք ասինխրոն կարգադրում ենք Ticker-ը, որը յուրաքանչյուր 15 վայրկյանը մեկ ping կուղարկի և սկսում ենք լսել այն ալիքը, որին մենք բաժանորդագրվել ենք։ Եթե մենք պինգ ենք ստանում, մենք հրապարակում ենք այս պինգը։ Եթե մենք ինչ-որ գրառում ենք ստանում, ապա մենք հրապարակում ենք այս գրառումը այս Fanout-ի բոլոր բաժանորդներին:
Ինչպե՞ս է աշխատում Fan-out-ը:
Ռուսերեն դա թարգմանվում է որպես «բաժանող»: Մենք ունենք մեկ օբյեկտ, որը գրանցում է բաժանորդներին, ովքեր ցանկանում են ստանալ որոշ թարմացումներ։ Եվ հենց որ թարմացում է հասնում այս օբյեկտին, այն տարածում է այս թարմացումը իր բոլոր բաժանորդներին: Բավական պարզ.
Ինչպես է այն իրականացվում Go-ում.
Կա կառուցվածք, այն համաժամացվում է Mutexes-ի միջոցով։ Այն ունի դաշտ, որը պահպանում է Fanout-ի միացման վիճակը տվյալների բազայի հետ, այսինքն՝ այն ներկայումս լսում է և կստանա թարմացումներ, ինչպես նաև բոլոր հասանելի ալիքների ցանկը՝ քարտեզ, որի բանալին ալիքն է և կառուցվածքը: արժեքներ (ըստ էության, այն ոչ մի կերպ չի օգտագործվում):
Երկու մեթոդ՝ Միացված և Անջատված, թույլ են տալիս մեզ ասել Fanout-ին, որ մենք կապ ունենք բազայի հետ, այն հայտնվել է և որ կապը բազայի հետ խզվել է: Երկրորդ դեպքում, դուք պետք է անջատեք բոլոր հաճախորդներին և ասեք նրանց, որ նրանք այլևս չեն կարող որևէ բան լսել, և որ նրանք նորից միանում են, քանի որ նրանց հետ կապը փակվել է:
Կա նաև Բաժանորդագրվելու մեթոդ, որն ավելացնում է ալիքը «լսողների» մեջ.
Գոյություն ունի Unsubscribe մեթոդը, որը հեռացնում է ալիքը լսողներից, եթե հաճախորդը անջատվի, ինչպես նաև Publish մեթոդ, որը թույլ է տալիս հաղորդագրություն ուղարկել բոլոր բաժանորդներին։
Question: – Ի՞նչ է փոխանցվում այս ալիքով:
MS: – Փոխանցված մոդելը կամ ping-ը փոխանցվում է (ըստ էության, ընդամենը թիվ, ամբողջ թիվ):
MS: – Կարող եք ցանկացած բան ուղարկել, ուղարկել ցանկացած կառույց, հրապարակել այն – այն պարզապես վերածվում է JSON-ի և վերջ:
MS: – Մենք ծանուցում ենք ստանում Postgres-ից – այն պարունակում է աղյուսակի անվանումը և նույնացուցիչը: Սեղանի անվան և նույնացուցիչի հիման վրա մենք ստանում ենք մեզ անհրաժեշտ գրառումը, այնուհետև ուղարկում ենք այս կառույցը հրապարակման:
Ենթակառուցվածքի
Ինչպիսի՞ն է սա ենթակառուցվածքի տեսանկյունից: Մենք ունենք 7 ապարատային սերվեր, որոնցից մեկն ամբողջությամբ նվիրված է տվյալների բազային, մյուս վեցը աշխատում են վիրտուալ մեքենաներով: API-ի 6 օրինակ կա. API-ով յուրաքանչյուր վիրտուալ մեքենա աշխատում է առանձին ապարատային սերվերի վրա. սա հուսալիության համար է:
Մատչելիությունը բարելավելու համար մենք ունենք երկու ճակատ, որտեղ տեղադրված է Keepalived, այնպես որ, եթե ինչ-որ բան պատահի, մի ճակատը կարողանա փոխարինել մյուսին: Նաև՝ CMS-ի երկու օրինակ:
Կա նաև վիճակագրություն ներմուծող. Կա DB Slave, որից պարբերաբար կրկնօրինակումներ են արվում։ Կա Pigeon Pusher հավելված, որը ուղարկում է push ծանուցումներ հաճախորդներին, ինչպես նաև ենթակառուցվածքային բաներ՝ Zabbix, Graylog2 և Chef:
Փաստորեն, այս ենթակառուցվածքը ավելորդ է, քանի որ 100 հազարը կարելի է սպասարկել ավելի քիչ սերվերներով։ Բայց երկաթ կար - օգտագործեցինք (մեզ ասացին, որ հնարավոր է - ինչու չէ):
Go-ի առավելությունները
Այս հավելվածի վրա աշխատելուց հետո ի հայտ եկան Go-ի նման ակնհայտ առավելությունները։
- Cool http գրադարան: Դրանով դուք կարող եք շատ բան ստեղծել տուփից դուրս:
- Բացի այդ, ալիքներ, որոնք մեզ թույլ տվեցին շատ հեշտությամբ ներդնել հաճախորդներին ծանուցումներ ուղարկելու մեխանիզմ:
- Հրաշալի բան Race դետեկտորը մեզ թույլ տվեց վերացնել մի քանի կարևոր սխալներ (բեմական ենթակառուցվածք): Այն ամենը, ինչ աշխատում է բեմադրության վրա, գործարկվում է, կազմվում է Race ստեղնով; և մենք, համապատասխանաբար, կարող ենք նայել բեմական ենթակառուցվածքը՝ տեսնելու, թե ինչ պոտենցիալ խնդիրներ ունենք։
- Լեզվի մինիմալիզմ և պարզություն.
Մենք փնտրում ենք մշակողների! Եթե որեւէ մեկը ցանկանում է, խնդրում եմ:
Հարցեր
Հարց հանդիսատեսի կողմից (այսուհետ՝ Բ). Ճի՞շտ եմ հասկանում, որ երբ պատասխան եք ուղարկում հաճախորդին, արգելափակում եք, եթե հաճախորդը չի ուզում կարդալ:
MS: -Չէ, չենք արգելափակում։ Նախ, մենք ունենք այս ամենը nginx-ի հետևում, այսինքն՝ դանդաղ հաճախորդների հետ կապված խնդիրներ չկան: Երկրորդ, հաճախորդն ունի բուֆեր ունեցող ալիք - փաստորեն, մենք կարող ենք այնտեղ տեղադրել մինչև հարյուր թարմացում... Եթե չենք կարողանում գրել ալիքին, ապա այն ջնջում է: Եթե տեսնենք, որ ալիքն արգելափակված է, ապա մենք պարզապես կփակենք ալիքը, և վերջ. հաճախորդը նորից կմիանա, եթե որևէ խնդիր առաջանա: Հետեւաբար, սկզբունքորեն, այստեղ արգելափակում չկա։
IN: – Հնարավո՞ր չէ անմիջապես ձայնագրություն ուղարկել Listen/Notify-ին, այլ ոչ թե նույնացուցիչ աղյուսակ:
MS: – Listen/Notify-ն ունի 8 հազար բայթի սահմանափակում իր ուղարկած նախաբեռնման համար: Սկզբունքորեն հնարավոր կլիներ ուղարկել, եթե մենք գործ ունենայինք փոքր քանակությամբ տվյալների հետ, բայց ինձ թվում է, որ այս կերպ [մենք դա անում ենք] պարզապես ավելի հուսալի է։ Սահմանափակումները հենց Postgres-ում են:
IN: – Արդյո՞ք հաճախորդները ստանում են թարմացումներ այն խաղերի վերաբերյալ, որոնք իրենց չեն հետաքրքրում:
MS: -Ընդհանուր առմամբ՝ այո։ Որպես կանոն, զուգահեռաբար 2-3 հանդիպում է ընթանում, իսկ հետո էլ՝ բավականին հազվադեպ։ Եթե հաճախորդը ինչ-որ բան է դիտում, ապա սովորաբար նա դիտում է ընթացող հանդիպումը: Այնուհետև, հաճախորդն ունի տեղական տվյալների բազա, որտեղ այս բոլոր թարմացումները գումարվում են, և նույնիսկ առանց ինտերնետ կապի, հաճախորդը կարող է դիտել բոլոր նախորդ համընկնումները, որոնց համար նա թարմացումներ ունի: Ըստ էության, մենք սերվերի վրա մեր տվյալների բազան համաժամացնում ենք հաճախորդի տեղական տվյալների բազայի հետ, որպեսզի նա կարողանա աշխատել անցանց:
IN: - Ինչու՞ ստեղծեցիք ձեր սեփական ORM-ը:
Ալեքսեյ (Look+-ի մշակողներից մեկը). – Այն ժամանակ (դա մեկ տարի առաջ էր) ORM-ներն ավելի քիչ էին, քան հիմա, երբ դրանք բավականին շատ են։ ORM-ների մեծ մասում իմ ամենասիրած բանն այն է, որ դրանց մեծ մասն աշխատում է դատարկ միջերեսներով: Այսինքն՝ այս ORM-ներում մեթոդները պատրաստ են իրենց վրա վերցնել ամեն ինչ՝ կառուցվածք, կառուցվածքի ցուցիչ, թիվ, միանգամայն անկապ մի բան...
Մեր ORM-ը ստեղծում է կառուցվածքներ՝ հիմնված տվյալների մոդելի վրա: Ինքս ինձ. Եվ հետևաբար բոլոր մեթոդները կոնկրետ են, չեն օգտագործում արտացոլումը և այլն: Նրանք ընդունում են կառույցներ և ակնկալում են օգտագործել այն կառույցները, որոնք գալիս են:
IN: - Քանի՞ հոգի է մասնակցել:
MS: – Սկզբնական փուլում երկու հոգի էին մասնակցում. Սկսեցինք ինչ-որ տեղ հունիսին, իսկ օգոստոսին հիմնական մասը պատրաստ էր (առաջին տարբերակը): սեպտեմբերին թողարկում եղավ.
IN: – Այնտեղ, որտեղ դուք նկարագրում եք SSE-ն, դուք չեք օգտագործում ժամանակացույց: Ինչո՞ւ է այդպես։
MS: – Անկեղծ ասած, SSE-ն դեռևս html5 արձանագրություն է. SSE ստանդարտը նախատեսված է բրաուզերների հետ հաղորդակցվելու համար, որքան ես հասկանում եմ: Այն ունի հավելյալ հնարավորություններ, որպեսզի բրաուզերները կարողանան նորից միանալ (և այլն), բայց դրանք մեզ պետք չեն, քանի որ մենք ունեինք հաճախորդներ, որոնք կարող էին որևէ տրամաբանություն կիրառել միացման և տեղեկատվության ստացման համար։ Մենք չենք ստեղծել SSE, այլ ավելի շուտ SSE-ի նման մի բան: Սա ինքնին արձանագրությունը չէ։
Կարիք չկար։ Ինչքան ես հասկացա, հաճախորդները միացման մեխանիզմն իրականացրել են գրեթե զրոյից։ Նրանք իսկապես հոգ չէին տանում:
IN: - Ի՞նչ լրացուցիչ կոմունալ ծառայություններ եք օգտագործել:
MS: – Մենք ամենաակտիվ կերպով օգտագործել ենք գովետը և գոլինտը ոճը միասնական դարձնելու համար, ինչպես նաև gofmt-ը: Ուրիշ ոչինչ չի օգտագործվել։
IN: - Ի՞նչ եք օգտագործել վրիպազերծման համար:
MS: – Վրիպազերծումը հիմնականում իրականացվել է թեստերի միջոցով: Մենք չենք օգտագործել վրիպազերծիչ կամ GOP:
IN: – Կարո՞ղ եք վերադարձնել այն սլայդը, որտեղ իրականացվում է Publish ֆունկցիան: Միատառ փոփոխականների անունները ձեզ շփոթու՞մ են:
MS: - Ոչ: Նրանք ունեն բավականին «նեղ» տեսանելիության շրջանակ: Նրանք այլուր չեն օգտագործվում, բացի այստեղից (բացառությամբ այս դասի ինտերիերի), և այն շատ կոմպակտ է. այն տևում է ընդամենը 7 տող:
IN: - Ինչ-որ կերպ դա դեռ ինտուիտիվ չէ ...
MS: - Ոչ, ոչ, սա իսկական ծածկագիր է: Խոսքը ոճի մասին չէ: Դա ուղղակի օգտակար, շատ փոքր դասարան է. դասարանի ներսում ընդամենը 3 դաշտ...
MS: – Մեծ հաշվով, բոլոր տվյալները, որոնք համաժամանակացված են հաճախորդների հետ (մրցաշրջանային հանդիպումներ, խաղացողներ) չեն փոխվում: Կոպիտ ասած, եթե մենք պատրաստենք այլ սպորտաձև, որում պետք է փոխենք խաղը, ուղղակի հաճախորդի նոր տարբերակում ամեն ինչ հաշվի կառնենք, իսկ հաճախորդի հին տարբերակները կարգելվեն։
IN: – Կա՞ն որևէ երրորդ կողմի կախվածության կառավարման փաթեթներ:
MS: - Մենք օգտագործել ենք go dep:
IN: – Զեկույցի թեմայում տեսագրության մասին ինչ-որ բան կար, իսկ տեսանյութի մասին զեկույցում ոչինչ չկար:
MS: -Ոչ, տեսանյութի մասին թեմայում ոչինչ չունեմ: Այն կոչվում է «Look+» – այդպես է կոչվում հավելվածը:
IN: – Դուք ասացիք, որ այն փոխանցվում է հաճախորդներին:
MS: – Մենք ներգրավված չենք եղել տեսանյութերի հոսքի մեջ: Դա ամբողջությամբ արվել է Megafon-ի կողմից: Այո, ես չեմ ասել, որ հավելվածը MegaFon-ն է:
MS: – Գնալ – բոլոր տվյալները ուղարկելու համար՝ հաշիվների, խաղերի իրադարձությունների, վիճակագրության... Go-ն հավելվածի ամբողջ հետնամասն է: Հաճախորդը պետք է ինչ-որ տեղից իմանա, թե որ հղումն օգտագործել խաղացողի համար, որպեսզի օգտատերը կարողանա դիտել հանդիպումը: Մենք ունենք պատրաստած տեսանյութերի և հոսքերի հղումներ:
Մի քանի գովազդ 🙂
Շնորհակալություն մեզ հետ մնալու համար: Ձեզ դուր են գալիս մեր հոդվածները: Ցանկանու՞մ եք տեսնել ավելի հետաքրքիր բովանդակություն: Աջակցեք մեզ՝ պատվիրելով կամ խորհուրդ տալով ընկերներին, , մուտքի մակարդակի սերվերների եզակի անալոգ, որը հորինվել է մեր կողմից ձեզ համար. (հասանելի է RAID1 և RAID10-ով, մինչև 24 միջուկով և մինչև 40 ԳԲ DDR4):
Dell R730xd 2 անգամ ավելի էժան Ամստերդամի Equinix Tier IV տվյալների կենտրոնում: Միայն այստեղ Նիդեռլանդներում! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-ից: Կարդացեք մասին
Source: www.habr.com