მიხაილ სალოსინი. გოლანგის შეხვედრა. გამოიყენეთ Go Look+ აპლიკაციის უკანა ნაწილში

მიხაილ სალოსინი (შემდგომში - MS): - Სალამი ყველას! Ჩემი სახელია მაიკლი. მე ვმუშაობ backend-ის დეველოპერად MC2 Software-ში და ვისაუბრებ Go-ის გამოყენებაზე Look+ მობილური აპლიკაციის ფონზე.

ვინმეს უყვარს აქ ჰოკეი?

მაშინ ეს აპლიკაცია თქვენთვისაა. ის არის Android-ისა და iOS-ისთვის და გამოიყენება სხვადასხვა სპორტული ღონისძიებების ონლაინ გადაცემის საყურებლად და ჩაწერილად. აპლიკაცია ასევე შეიცავს სხვადასხვა სტატისტიკას, ტექსტურ გადაცემებს, ცხრილებს კონფერენციებისთვის, ტურნირებისთვის და გულშემატკივრებისთვის სასარგებლო სხვა ინფორმაციას.

ასევე აპლიკაციაში არის ისეთი რამ, როგორიცაა ვიდეო მომენტები, ანუ შეგიძლიათ უყუროთ მატჩების ყველაზე მნიშვნელოვან მომენტებს (გოლები, ორთაბრძოლები, სროლები და ა.შ.). თუ არ გსურთ მთლიანი გადაცემის ყურება, შეგიძლიათ უყუროთ მხოლოდ ყველაზე საინტერესოებს.

რა გამოიყენე განვითარების პროცესში?

ძირითადი ნაწილი გო-ში დაიწერა. API, რომლითაც მობილური კლიენტები დაუკავშირდნენ, დაიწერა Go-ში. Go-ში ასევე დაიწერა მობილურ ტელეფონებზე push-შეტყობინებების გაგზავნის სერვისი. ჩვენ ასევე მოგვიწია საკუთარი ORM-ის დაწერა, რაზეც შესაძლოა ოდესმე ვისაუბროთ. ისე, Go-ში დაიწერა რამდენიმე მცირე სერვისი: ზომის შეცვლა და სურათების ჩატვირთვა რედაქტორებისთვის...

ჩვენ გამოვიყენეთ PostgreSQL, როგორც მონაცემთა ბაზა. რედაქტორის ინტერფეისი დაიწერა Ruby on Rails-ში ActiveAdmin ძვირფასი ქვის გამოყენებით. სტატისტიკის პროვაიდერისგან სტატისტიკის იმპორტი ასევე იწერება რუბიში.

სისტემის API ტესტებისთვის ჩვენ გამოვიყენეთ Python unittest. Memcached გამოიყენება API გადახდის ზარების შესაჩერებლად, "Chef" გამოიყენება კონფიგურაციის გასაკონტროლებლად, Zabbix გამოიყენება შიდა სისტემის სტატისტიკის შეგროვებისა და მონიტორინგისთვის. Graylog2 არის ჟურნალების შეგროვებისთვის, Slate არის API დოკუმენტაცია კლიენტებისთვის.

პროტოკოლის შერჩევა

პირველი პრობლემა, რომელიც შეგვხვდა: გვჭირდებოდა პროტოკოლის არჩევა backend-სა და მობილურ კლიენტებს შორის ურთიერთქმედებისთვის, შემდეგი პუნქტებიდან გამომდინარე...

• ყველაზე მნიშვნელოვანი მოთხოვნა: კლიენტების მონაცემები უნდა განახლდეს რეალურ დროში. ანუ, ყველამ, ვინც ამჟამად უყურებს გადაცემას, უნდა მიიღოს განახლებები თითქმის მყისიერად.
• საქმეების გასამარტივებლად, ჩვენ ვივარაუდეთ, რომ მონაცემები, რომლებიც სინქრონიზებულია კლიენტებთან, არ წაიშლება, მაგრამ იმალება სპეციალური დროშების გამოყენებით.
• ყველა სახის იშვიათი მოთხოვნა (როგორიცაა სტატისტიკა, გუნდის შემადგენლობა, გუნდის სტატისტიკა) მიიღება ჩვეულებრივი GET მოთხოვნით.
• გარდა ამისა, სისტემას ერთდროულად უჭირდა 100 ათასი მომხმარებლის მხარდაჭერა.

ამის საფუძველზე ჩვენ გვქონდა პროტოკოლის ორი ვარიანტი:

1. ვებსოკეტები. მაგრამ ჩვენ არ გვჭირდებოდა არხები კლიენტიდან სერვერამდე. ჩვენ მხოლოდ სერვერიდან კლიენტისთვის განახლებების გაგზავნა დაგვჭირდა, ამიტომ ვებსოკეტი ზედმეტი ვარიანტია.
2. სერვერის მიერ გაგზავნილი მოვლენები (SSE) ზუსტად გაჩნდა! ის საკმაოდ მარტივია და ძირითადად აკმაყოფილებს ყველაფერს, რაც ჩვენ გვჭირდება.

სერვერის გაგზავნილი მოვლენები

ორიოდე სიტყვა იმის შესახებ, თუ როგორ მუშაობს ეს...

ის მუშაობს http კავშირის თავზე. კლიენტი აგზავნის მოთხოვნას, სერვერი პასუხობს Content-Type: text/event-stream და არ ხურავს კავშირს კლიენტთან, მაგრამ აგრძელებს მონაცემთა ჩაწერას კავშირზე:

მონაცემების გაგზავნა შესაძლებელია კლიენტებთან შეთანხმებული ფორმატით. ჩვენს შემთხვევაში, ჩვენ გავგზავნეთ იგი ამ ფორმით: შეცვლილი სტრუქტურის სახელი (პირი, მოთამაშე) იგზავნება მოვლენის ველში, ხოლო JSON მოთამაშისთვის ახალი, შეცვლილი ველებით მონაცემთა ველში.

ახლა მოდით ვისაუბროთ იმაზე, თუ როგორ მუშაობს თავად ურთიერთქმედება.

• პირველი, რასაც კლიენტი აკეთებს, არის იმის განსაზღვრა, თუ როდის განხორციელდა სერვისთან სინქრონიზაცია: ის უყურებს მის ადგილობრივ მონაცემთა ბაზას და განსაზღვრავს მის მიერ დაფიქსირებული ბოლო ცვლილების თარიღს.
• ის აგზავნის მოთხოვნას ამ თარიღით.
• საპასუხოდ, ჩვენ მას ვუგზავნით ყველა განახლებას, რაც მოხდა ამ თარიღის შემდეგ.
• ამის შემდეგ, ის აკავშირებს პირდაპირ არხს და არ იხურება, სანამ არ დასჭირდება ეს განახლებები:

ჩვენ ვუგზავნით მას ცვლილებების სიას: თუ ვინმე გოლს გაიტანს, ჩვენ ვცვლით მატჩის ანგარიშს, თუ ის ტრავმირებულია, ეს ასევე იგზავნება რეალურ დროში. ამრიგად, კლიენტები მყისიერად იღებენ განახლებულ მონაცემებს მატჩის მოვლენის არხში. პერიოდულად, რათა კლიენტმა გაიგოს, რომ სერვერი არ მომკვდარა, რომ არაფერი მომხდარა, ვაგზავნით დროის ნიშანს ყოველ 15 წამში - რათა მან იცოდეს, რომ ყველაფერი რიგზეა და არ არის საჭირო ხელახლა დაკავშირება.

როგორ ემსახურება პირდაპირი კავშირი?

• უპირველეს ყოვლისა, ჩვენ ვქმნით არხს, რომელშიც მიიღება ბუფერული განახლებები.
• ამის შემდეგ, ჩვენ გამოვწერთ ამ არხს განახლებების მისაღებად.
• ჩვენ დავაყენეთ სწორი სათაური ისე, რომ კლიენტმა იცოდეს, რომ ყველაფერი წესრიგშია.
• გაგზავნეთ პირველი პინგი. ჩვენ უბრალოდ ჩავწერთ მიმდინარე კავშირის დროის ნიშანს.
• ამის შემდეგ, ჩვენ ვკითხულობთ არხიდან მარყუჟში, სანამ განახლების არხი არ დაიხურება. არხი პერიოდულად იღებს ან მიმდინარე დროის ნიშანს ან ცვლილებებს, რომლებსაც ჩვენ უკვე ვწერთ კავშირების გასახსნელად.

პირველი პრობლემა, რომელიც შეგვხვდა იყო შემდეგი: კლიენტთან გახსნილი ყოველი კავშირისთვის, ჩვენ შევქმენით ტაიმერი, რომელიც 15 წამში ერთხელ იკეცებოდა - გამოდის, რომ თუ ჩვენ გვქონდა 6 ​​ათასი კავშირი გახსნილი ერთ მანქანაზე (ერთი API სერვერით), 6. შეიქმნა ათასი ტაიმერი. ამან გამოიწვია ის, რომ მანქანა არ იკავებდა საჭირო დატვირთვას. პრობლემა ჩვენთვის არც ისე აშკარა იყო, მაგრამ მცირე დახმარება მივიღეთ და მოვაგვარეთ.

შედეგად, ახლა ჩვენი პინგი მოდის იმავე არხიდან, საიდანაც მოდის განახლება.

შესაბამისად, არსებობს მხოლოდ ერთი ტაიმერი, რომელიც ყოველ 15 წამში ერთხელ იკლებს.

აქ არის რამდენიმე დამხმარე ფუნქცია - სათაურის გაგზავნა, პინგ და თავად სტრუქტურა. ანუ ცხრილის სახელი (პირი, მატჩი, სეზონი) და ამ ჩანაწერის შესახებ ინფორმაცია გადაცემულია აქ:

განახლებების გაგზავნის მექანიზმი

ახლა ცოტა იმაზე, თუ საიდან მოდის ცვლილებები. ჩვენ გვყავს რამდენიმე ადამიანი, რედაქტორები, რომლებიც გადაცემას რეალურ დროში უყურებენ. ისინი ქმნიან ყველა მოვლენას: ვიღაც გააძევეს, ვიღაც დაშავდა, რაღაც შემცვლელი...

CMS-ის გამოყენებით მონაცემები შედის მონაცემთა ბაზაში. ამის შემდეგ, მონაცემთა ბაზა აცნობებს ამის შესახებ API სერვერებს Listen/Notify მექანიზმის გამოყენებით. API სერვერები უკვე უგზავნიან ამ ინფორმაციას კლიენტებს. ამრიგად, ჩვენ არსებითად გვაქვს მხოლოდ რამდენიმე სერვერი დაკავშირებული მონაცემთა ბაზასთან და არ არის სპეციალური დატვირთვა მონაცემთა ბაზაზე, რადგან კლიენტი არანაირად არ ურთიერთობს უშუალოდ მონაცემთა ბაზასთან:

PostgreSQL: მოუსმინეთ/შეატყობინეთ

Listen/Notify მექანიზმი Postgres-ში საშუალებას გაძლევთ აცნობოთ ღონისძიების აბონენტებს, რომ ზოგიერთი მოვლენა შეიცვალა - მონაცემთა ბაზაში შეიქმნა გარკვეული ჩანაწერი. ამისათვის ჩვენ დავწერეთ მარტივი ტრიგერი და ფუნქცია:

ჩანაწერის ჩასმის ან შეცვლისას ჩვენ ვუწოდებთ notify ფუნქციას data_updates არხზე, ვაგზავნით ცხრილის სახელს და შეცვლილი ან ჩასმული ჩანაწერის იდენტიფიკატორს.

ყველა ცხრილისთვის, რომელიც უნდა იყოს სინქრონიზებული კლიენტთან, ჩვენ განვსაზღვრავთ ტრიგერს, რომელიც ჩანაწერის შეცვლის/განახლების შემდეგ იძახებს ქვემოთ მოცემულ სლაიდზე მითითებულ ფუნქციას.
როგორ გამოიწერს API ამ ცვლილებებს?

იქმნება Fanout მექანიზმი - ის უგზავნის შეტყობინებებს კლიენტს. ის აგროვებს მომხმარებლის ყველა არხს და აგზავნის განახლებებს, რომლებიც მიიღეს ამ არხებით:

აქ სტანდარტული pq ბიბლიოთეკა, რომელიც უერთდება მონაცემთა ბაზას და ამბობს, რომ არხის მოსმენა უნდა (data_updates), ამოწმებს, რომ კავშირი ღიაა და ყველაფერი კარგადაა. სივრცის დაზოგვის მიზნით გამოვტოვებ შეცდომის შემოწმებას (შემოწმება საშიშია).

შემდეგი, ჩვენ ასინქრონულად ვაყენებთ Ticker-ს, რომელიც ყოველ 15 წამში აგზავნის პინგს და დავიწყებთ იმ არხის მოსმენას, რომელსაც ჩვენ გამოვწერეთ. თუ ჩვენ მივიღებთ პინგს, ჩვენ ვაქვეყნებთ ამ პინგს. თუ ჩვენ მივიღებთ რაიმე სახის ჩანაწერს, მაშინ ჩვენ ვაქვეყნებთ ამ ჩანაწერს ამ Fanout-ის ყველა გამომწერისთვის.

როგორ მუშაობს Fan-out?

რუსულად ეს ითარგმნება როგორც "სპლიტერი". ჩვენ გვაქვს ერთი ობიექტი, რომელიც აღრიცხავს აბონენტებს, რომლებსაც სურთ გარკვეული განახლებების მიღება. და როგორც კი განახლება მოვა ამ ობიექტზე, ის ავრცელებს ამ განახლებას თავის ყველა აბონენტს. საკმარისად მარტივი:

როგორ ხორციელდება Go-ში:

არსებობს სტრუქტურა, ის სინქრონიზებულია Mutexes-ის გამოყენებით. მას აქვს ველი, რომელიც ინახავს Fanout-ის მონაცემთა ბაზასთან დაკავშირების მდგომარეობას, ანუ ის ამჟამად უსმენს და მიიღებს განახლებებს, ასევე ყველა ხელმისაწვდომი არხის სია - რუკა, რომლის გასაღები არის არხი და სტრუქტურა. ღირებულებები (არსებითად ის არანაირად არ გამოიყენება).

ორი მეთოდი - დაკავშირებული და გათიშული - საშუალებას გვაძლევს ვუთხრათ Fanout-ს, რომ ჩვენ გვაქვს კავშირი ბაზასთან, ის გამოჩნდა და რომ კავშირი ბაზასთან გატეხილია. მეორე შემთხვევაში, თქვენ უნდა გათიშოთ ყველა კლიენტი და უთხრათ, რომ ვეღარაფერს უსმენენ და ხელახლა დაუკავშირდებიან, რადგან მათთან კავშირი დაიხურა.

ასევე არსებობს Subscribe მეთოდი, რომელიც ამატებს არხს „მსმენელებს“:

არსებობს Unsubscribe მეთოდი, რომელიც ხსნის არხს მსმენელებისგან კლიენტის გათიშვის შემთხვევაში, ასევე გამოქვეყნების მეთოდი, რომელიც საშუალებას გაძლევთ გაუგზავნოთ შეტყობინება ყველა აბონენტს.

კითხვა: – რა გადაიცემა ამ არხით?

ᲥᲐᲚᲑᲐᲢᲝᲜᲘ: – მოდელი, რომელიც შეიცვალა ან ping გადაიცემა (არსებითად მხოლოდ რიცხვი, მთელი რიცხვი).

ᲥᲐᲚᲑᲐᲢᲝᲜᲘ: – შეგიძლიათ გააგზავნოთ ყველაფერი, გაგზავნოთ ნებისმიერი სტრუქტურა, გამოაქვეყნოთ – ის უბრალოდ იქცევა JSON-ში და ეს არის ის.

ᲥᲐᲚᲑᲐᲢᲝᲜᲘ: - ჩვენ ვიღებთ შეტყობინებას Postgres-ისგან - ის შეიცავს ცხრილის სახელს და იდენტიფიკატორს. ცხრილის სახელსა და იდენტიფიკატორზე დაყრდნობით ვიღებთ საჭირო ჩანაწერს და შემდეგ ამ სტრუქტურას ვაგზავნით გამოსაქვეყნებლად.

ინფრასტრუქტურის

როგორ გამოიყურება ეს ინფრასტრუქტურის თვალსაზრისით? ჩვენ გვაქვს 7 ტექნიკის სერვერი: ერთი მათგანი მთლიანად ეძღვნება ბაზას, დანარჩენი ექვსი მუშაობს ვირტუალურ მანქანებზე. არსებობს API-ს 6 ასლი: თითოეული ვირტუალური მანქანა API-ით მუშაობს ცალკე ტექნიკის სერვერზე - ეს არის საიმედოობისთვის.

ჩვენ გვაქვს ორი წინა ნაწილი დაინსტალირებული Keepalived წვდომის გასაუმჯობესებლად, ასე რომ, თუ რამე მოხდება, ერთმა ფრონტმა შეცვალოს მეორე. ასევე – CMS-ის ორი ასლი.

ასევე არის სტატისტიკის იმპორტიორი. არსებობს DB Slave, საიდანაც პერიოდულად კეთდება სარეზერვო ასლები. არის Pigeon Pusher, აპლიკაცია, რომელიც აგზავნის push-შეტყობინებებს კლიენტებს, ასევე ინფრასტრუქტურულ ნივთებს: Zabbix, Graylog2 და Chef.

ფაქტობრივად, ეს ინფრასტრუქტურა ზედმეტია, რადგან 100 ათასის სერვისი შეიძლება ნაკლები სერვერით. ოღონდ რკინა იყო - გამოვიყენეთ (გვითხრეს, რომ შესაძლებელი იყო - რატომაც არა).

Go-ს დადებითი მხარეები

მას შემდეგ რაც ამ აპლიკაციაზე ვიმუშავეთ, Go-ს ასეთი აშკარა უპირატესობები გაჩნდა.

• მაგარი http ბიბლიოთეკა. მასთან ერთად შეგიძლიათ შექმნათ საკმაოდ ბევრი ყუთიდან.
• გარდა ამისა, არხები, რომლებიც საშუალებას გვაძლევს ძალიან მარტივად დაგვენერგა კლიენტებისთვის შეტყობინებების გაგზავნის მექანიზმი.
• მშვენიერი რამ რასის დეტექტორმა მოგვცა საშუალება აღმოვფხვრათ რამდენიმე კრიტიკული შეცდომა (დადგმის ინფრასტრუქტურა). ყველაფერი, რაც დადგმაზე მუშაობს, გაშვებულია, შედგენილია Race კლავიშით; და ჩვენ, შესაბამისად, შეგვიძლია გადავხედოთ დადგმის ინფრასტრუქტურას, რათა დავინახოთ რა პოტენციური პრობლემები გვაქვს.
• მინიმალიზმი და ენის სიმარტივე.

ჩვენ ვეძებთ დეველოპერებს! თუ ვინმეს უნდა, გთხოვთ.

კითხვები

კითხვა მაყურებლისგან (შემდგომში – B): – მეჩვენება, რომ თქვენ გამოგრჩათ ერთი მნიშვნელოვანი წერტილი Fan-out-თან დაკავშირებით. სწორად მესმის, რომ როდესაც კლიენტს უგზავნი პასუხს, ბლოკავ თუ კლიენტს არ სურს წაკითხვა?

ᲥᲐᲚᲑᲐᲢᲝᲜᲘ: - არა, არ ვბლოკავთ. ჯერ ერთი, ეს ყველაფერი გვაქვს nginx-ის უკან, ანუ ნელი კლიენტებთან არანაირი პრობლემა არ არის. მეორეც, კლიენტს აქვს არხი ბუფერით - ფაქტობრივად, იქ ასამდე განახლება შეგვიძლია დავაყენოთ... თუ არხს ვერ მივწერთ, მაშინ ის შლის. თუ დავინახავთ, რომ არხი დაბლოკილია, მაშინ ჩვენ უბრალოდ დავხურავთ არხს და ეს არის ის - კლიენტი ხელახლა დაუკავშირდება, თუ რაიმე პრობლემა წარმოიქმნება. ამიტომ, პრინციპში, აქ დაბლოკვა არ არის.

In: – არ შეიძლება ჩანაწერის დაუყოვნებლივ გაგზავნა Listen/Notify-ზე და არა იდენტიფიკატორის ცხრილის?

ᲥᲐᲚᲑᲐᲢᲝᲜᲘ: – Listen/Notify-ს აქვს 8 ათასი ბაიტის ლიმიტი წინასწარ ჩატვირთვაზე, რომელსაც ის აგზავნის. პრინციპში, გაგზავნა შესაძლებელი იქნებოდა, თუ საქმე გვქონდა მცირე მოცულობის მონაცემებთან, მაგრამ მეჩვენება, რომ ეს გზა [როგორც ამას ვაკეთებთ] უბრალოდ უფრო სანდოა. შეზღუდვები თავად Postgres-შია.

In: – იღებენ თუ არა მომხმარებლები განახლებებს მატჩების შესახებ, რომლებიც მათ არ აინტერესებთ?

ᲥᲐᲚᲑᲐᲢᲝᲜᲘ: - ზოგადად, კი. როგორც წესი, პარალელურად 2-3 მატჩი მიმდინარეობს, თანაც საკმაოდ იშვიათად. თუ კლიენტი რაღაცას უყურებს, მაშინ ჩვეულებრივ ის უყურებს მატჩს, რომელიც მიმდინარეობს. შემდეგ, კლიენტს აქვს ადგილობრივი მონაცემთა ბაზა, რომელშიც ყველა ეს განახლება არის დამატებული და ინტერნეტთან კავშირის გარეშეც კი, კლიენტს შეუძლია ნახოს ყველა წარსული მატჩი, რომლისთვისაც მას აქვს განახლებები. არსებითად, ჩვენ სერვერზე ჩვენს მონაცემთა ბაზის სინქრონიზაციას ვახდენთ კლიენტის ადგილობრივ მონაცემთა ბაზასთან, რათა მან შეძლოს მუშაობა ოფლაინში.

In: – რატომ შექმენით საკუთარი ORM?

ალექსეი (Look+-ის ერთ-ერთი დეველოპერი): – იმ დროს (ეს იყო ერთი წლის წინ) ნაკლები ORM იყო, ვიდრე ახლა, როცა საკმაოდ ბევრია. ჩემი საყვარელი რამ ORM-ების უმეტესობაში არის ის, რომ მათი უმეტესობა მუშაობს ცარიელ ინტერფეისებზე. ანუ, ამ ORM-ებში არსებული მეთოდები მზადაა აიღოს ყველაფერი: სტრუქტურა, სტრუქტურის მაჩვენებელი, რიცხვი, რაღაც სრულიად შეუსაბამო...

ჩვენი ORM წარმოქმნის სტრუქტურებს მონაცემთა მოდელის საფუძველზე. მე თვითონ. ამიტომ ყველა მეთოდი კონკრეტულია, არ იყენებენ ასახვას და ა.შ. ისინი იღებენ სტრუქტურებს და ელიან, რომ გამოიყენებენ იმ სტრუქტურებს, რომლებიც მოდის.

In: - რამდენმა ადამიანმა მიიღო მონაწილეობა?

ᲥᲐᲚᲑᲐᲢᲝᲜᲘ: – საწყის ეტაპზე ორი ადამიანი მონაწილეობდა. სადღაც ივნისში დავიწყეთ, აგვისტოში კი მთავარი ნაწილი მზად იყო (პირველი ვერსია). სექტემბერში იყო გამოშვება.

In: – სადაც თქვენ აღწერთ SSE-ს, თქვენ არ იყენებთ ტაიმაუტს. Რატომ არის, რომ?

ᲥᲐᲚᲑᲐᲢᲝᲜᲘ: – მართალი გითხრათ, SSE მაინც არის html5 პროტოკოლი: SSE სტანდარტი შექმნილია ბრაუზერებთან კომუნიკაციისთვის, რამდენადაც მე მესმის. მას აქვს დამატებითი ფუნქციები, რათა ბრაუზერებს შეეძლოთ ხელახლა დაკავშირება (და ასე შემდეგ), მაგრამ ჩვენ არ გვჭირდება ისინი, რადგან გვყავდა კლიენტები, რომლებსაც შეეძლოთ რაიმე ლოგიკის განხორციელება ინფორმაციის დასაკავშირებლად და მისაღებად. ჩვენ არ გავაკეთეთ SSE, არამედ რაღაც მსგავსი SSE. ეს არ არის თავად პროტოკოლი.
არ იყო საჭიროება. რამდენადაც მე მესმის, კლიენტებმა კავშირის მექანიზმი თითქმის ნულიდან განახორციელეს. მათ ნამდვილად არ აინტერესებდათ.

In: – რა დამატებითი კომუნალური საშუალებები იყენებდით?

ᲥᲐᲚᲑᲐᲢᲝᲜᲘ: – ჩვენ ყველაზე აქტიურად ვიყენებდით გოვეტს და გოლინტს სტილის უნიფიცირებისთვის, ისევე როგორც გოფმტ. სხვა არაფერი გამოუყენებიათ.

In: – რას იყენებდით გამართვისთვის?

ᲥᲐᲚᲑᲐᲢᲝᲜᲘ: – გამართვა ძირითადად განხორციელდა ტესტების გამოყენებით. ჩვენ არ გამოგვიყენებია რაიმე გამართვა ან GOP.

In: – შეგიძლიათ დააბრუნოთ სლაიდი, სადაც განხორციელებულია Publish ფუნქცია? ერთასოიანი ცვლადის სახელები გაწუხებთ?

ᲥᲐᲚᲑᲐᲢᲝᲜᲘ: - არა. მათ აქვთ საკმაოდ "ვიწრო" ხილვადობის ფარგლები. ისინი არ გამოიყენება სხვაგან, გარდა აქა (გარდა ამ კლასის შიდა ნაწილებისა) და ძალიან კომპაქტურია - მხოლოდ 7 სტრიქონი სჭირდება.

In: - რატომღაც ეს ჯერ კიდევ არ არის ინტუიციური ...

ᲥᲐᲚᲑᲐᲢᲝᲜᲘ: - არა, არა, ეს ნამდვილი კოდია! ეს არ ეხება სტილს. ეს უბრალოდ უტილიტარული, ძალიან მცირე კლასია - მხოლოდ 3 ველი კლასში...

ᲥᲐᲚᲑᲐᲢᲝᲜᲘ: – ზოგადად, ყველა მონაცემი, რომელიც სინქრონიზებულია კლიენტებთან (სეზონის მატჩები, მოთამაშეები) არ იცვლება. უხეშად რომ ვთქვათ, თუ სხვა სპორტს გავაკეთებთ, რომელშიც მატჩის შეცვლა გვჭირდება, უბრალოდ კლიენტის ახალ ვერსიაში ყველაფერს გავითვალისწინებთ და კლიენტის ძველი ვერსიები აიკრძალება.

In: – არის თუ არა მესამე მხარის დამოკიდებულების მართვის პაკეტები?

ᲥᲐᲚᲑᲐᲢᲝᲜᲘ: - ჩვენ გამოვიყენეთ go dep.

In: - რეპორტაჟის თემაში იყო რაღაც ვიდეოზე, მაგრამ ვიდეოზე არაფერი იყო.

ᲥᲐᲚᲑᲐᲢᲝᲜᲘ: - არა, ვიდეოს შესახებ თემაში არაფერი მაქვს. მას ჰქვია "Look+" - ეს არის აპლიკაციის სახელი.

In: – თქვენ თქვით, რომ ის გადადის კლიენტებზე?..

ᲥᲐᲚᲑᲐᲢᲝᲜᲘ: – ჩვენ არ ვიყავით ჩართული ვიდეოს სტრიმინგში. ეს მთლიანად მეგაფონმა გააკეთა. დიახ, მე არ მითქვამს, რომ აპლიკაცია იყო MegaFon.

ᲥᲐᲚᲑᲐᲢᲝᲜᲘ: – წადი – ყველა მონაცემის გასაგზავნად – ანგარიშის, მატჩის მოვლენებზე, სტატისტიკაზე... Go არის აპლიკაციის მთელი უკანა ნაწილი. კლიენტმა სადღაც უნდა იცოდეს რომელი ბმული გამოიყენოს მოთამაშისთვის, რათა მომხმარებელმა შეძლოს მატჩის ყურება. ჩვენ გვაქვს მომზადებული ვიდეოების და სტრიმინგების ლინკები.

რამდენიმე რეკლამა 🙂

გმადლობთ, რომ დარჩით ჩვენთან. მოგწონთ ჩვენი სტატიები? გსურთ ნახოთ უფრო საინტერესო შინაარსი? მხარი დაგვიჭირეთ შეკვეთის განთავსებით ან მეგობრებისთვის რეკომენდაციით, ღრუბელი VPS დეველოპერებისთვის 4.99 დოლარიდან, საწყისი დონის სერვერების უნიკალური ანალოგი, რომელიც ჩვენ მიერ გამოგონილია თქვენთვის: მთელი სიმართლე VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps 19$-დან ან როგორ გავაზიარო სერვერი? (ხელმისაწვდომია RAID1 და RAID10-ით, 24 ბირთვამდე და 40 გბ-მდე DDR4).

Dell R730xd 2-ჯერ იაფია Equinix Tier IV მონაცემთა ცენტრში ამსტერდამში? Მხოლოდ აქ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ტელევიზორი $199-დან ნიდერლანდებში! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-დან! Წაიკითხო რაღაცის შესახებ როგორ ავაშენოთ ინფრასტრუქტურის კორპუსი. კლასი Dell R730xd E5-2650 v4 სერვერების გამოყენებით 9000 ევროს ღირებულების პენი?

წყარო: www.habr.com