Михаил Салосин. Golang Meetup. Използване на Go в бекенда на приложението „Смотри+“

Михаил Салосин (по-далее – МС): – Здравейте на всички! Казвам се Михаил. Работя като бекенд разработчик в компанията MC2 Software и ще ви разкажа за използването на Go в бекенда на мобилното приложение "Смотри+".

Има ли някой между вас, който обича хокей?

Тогава това приложение е за вас. То е за "Андроид" и iOS и служи за гледане на различни спортни събития на живо и на запис. В приложението има също статистика, текстови предавания, таблици по конференции, турнири и друга информация, полезна за феновете.

В приложението има и нещо, наречено видеомоменти, т.е. можете да видите най-интересните моменти от мачовете (голове, битки, буллити и др.). Ако не ви се гледа цялото предаване, можете да видите само най-интересното.

Какво използвахме в разработката?

Основната част беше написана на Go. API-то, с което общуваха мобилните клиенти, беше написано на Go. Също така на Go беше написан сервис за изпращане на push уведомления на мобилни устройства. Освен това трябваше да напишем собствено ORM, за което може би някога ще разкажем. Написахме и някои малки сервисита на Go: ресайзинг и качване на изображения за редакторите...

Като база данни използвахме "Постгрес" (PostgreSQL). Интерфейсът за редакторите беше написан на Ruby on Rails с помощта на гема (gem) ActiveAdmin. Импортът на статистика от доставчика на статистика също е написан на "Руби".

За системни тестове на API използвахме unittest на "Питон" (Python). Memcached се използва за ограничаване на API-заявките за плащане, "Шеф" (Chef) – за контрол на конфигурацията, Zabbix – за събиране и мониторинг на вътрешни статистически данни на системата. Graylog2 – за събиране на логове, Slate – това е документацията на API за клиентите.

Избор на протокол

Проблемът, с който се сблъсквахме първо: трябваше да изберем протокол за взаимодействие на бекенда с мобилните клиенти, въз основа на следните точки…

• Най-важното изискване: данните на клиентите трябва да се обновяват в реално време. Тоест всички, които в момента гледат предаването, трябва да получават актуализации почти веднага.
• За опростяване приеха, че данните, които се синхронизират с клиентите, не се изтриват, а се скриват с помощта на специални флагове.
• Разнообразни редки запитвания (като статистики, състави на отбори, статистики на отбори) се извършват с обикновени GET запитвания.
• Освен това, системата трябваше спокойно да издържи 100 хиляди потребители едновременно.

На базата на това имахме два варианта на протокол:

1. Websocket-и. Но не ни бяха нужни канали от клиента към сървъра. Нужно ни беше единствено да изпращаме актуализации от сървъра към клиента, затова уебсокетът беше излишен вариант.
2. Server-Sent Events (SSE) се оказа идеален! Той е достатъчно прост и удовлетворява всички наши нужди.

Server-Sent Events

Няколко думи за това как работи това нещо...

То работи върху http връзка. Клиентът прави запитване, на което сървърът отговаря с Content-Type: text/event-stream и не затваря връзката с клиента, а продължава да записва данни в нея:

Данните могат да се изпращат в формат, договорен с клиентите. В нашия случай изпращахме по следния начин: в полето събитие се записваше името на променената структура (човек, играч), а в полето данни – JSON с новите, променени полета за играча.

Сега за самото взаимодействие.

• Първо, клиентът определя кога последно е синхронизирал с услугата: той проверява в локалната си база данни и определя датата на последната промяна, записана у него.
• Той изпраща запитване с тази дата.
• В отговор му изпращаме всички актуализации, които са се случили след тази дата.
• След това той установява връзка с live канала и не я затваря, докато му трябват тези актуализации:

Изпращаме му списък с промените: ако някой вкара гол – променяме резултата от мача, ако получи травма – също се изпраща в реално време. По този начин, в лентата на събитията от мача клиентите моментално получават актуални данни. Периодично, за да може клиентът да разбере, че сървърът не е спрял, че с него всичко е наред, изпращаме на всеки 15 секунди timestamp – за да знае, че всичко е наред и не се налага да се преподключва.

Как се обслужва live връзката?

• На първо място създаваме канал, в който ще идват актуализации с буфер.
• След това подписваме този канал за получаване на актуализации.
• Настройваме правилния заглавие, за да знае клиентът, че всичко е ок.
• Изпращаме първия ping. Просто записваме актуалния timestamp на връзката.
• След това в цикъл четем от канала, докато каналът за обновления не бъде затворен. В канала периодично постъпват текущи времеви печати или промени, които вече записваме в отворени съединения.

Проблемът, с който се сблъскахме, беше следният: за всяко отворено съединение с клиент създавахме таймер, който тиктакаше на всеки 15 секунди. Получава се, че ако имахме 6000 отворени съединения с един сървър (с един API-сървър), се създаваха 6000 таймера. Това доведе до невъзможност на машината да поддържа необходимата натовареност. Проблемът не беше толкова очевиден за нас, но след малко помощ успяхме да го решим.

В крайна сметка сега получаваме ping от същия канал, от който идват обновленията.

Съответно, имаме само един таймер, който тиктака на всеки 15 секунди.

Тук са няколко помощни функции – изпращане на заглавие, ping и самата структура. Тоест тук се предава името на таблицата (person, match, season) и самата информация за записа:

Механизмът за изпращане на обновления

Сега малко за източниците на промените. Имаме няколко редактори, които наблюдават транслацията в реално време. Те създават всички събития: някой е бил изгонен, някой е получил контузия, има смяна…

С помощта на CMS данните попадат в базата. След това базата с механизма Listen/Notify уведомява API-сървърите за това. API-сървърите разпространяват информацията на клиентите. По този начин, в действителност, към базата е свързано само няколко сървъра и нямаме особено натоварване на базата, защото клиентите не взаимодействат директно с базата:

PostgreSQL: Listen/Notify

Механизмът Listen/Notify в PostgreSQL позволява уведомяване на абонатите за събития, когато е направено изменение на даден запис в базата. За целта написахме прост тригер и функция:

При insert или изменение на записа, извикваме функцията notify на канала data_updates, предаваме името на таблицата и идентификатора на записа, който е бил изменен или добавен.

За всички таблици, които трябва да бъдат синхронизирани с клиента, определяме тригер, който след изменение/обновление на записа извиква функцията, указана на слайда отдолу.
Как API се абонира за тези промени?

Създава се механизъм Fanout – той разпространява съобщения на клиентите. Той събира всички канали на клиентите и разпраща актуализации, които е получил по тези канали:

Тук е стандартната библиотека pq, която се свързва с базата и казва, че иска да слуша канала (data_updates), проверява, че връзката е отворена и всичко е наред. Пропускам проверката за грешки, за да спестя място (пропускането на проверка е рисково).

След това асинхронно задаваме Ticker, който ще изпраща ping на всеки 15 секунди, и започваме да слушаме канала, на който сме се абонирали. Ако получим ping, публикуваме този ping. Ако получим някакъв запис, то публикуваме този запис на всички абонати на този Fanout.

Как работи Fan-out?

На български това се превежда като „разклонител“. Имаме един обект, който регистрира абонатите, които искат да получават актуализации. И веднага щом актуализация за този обект дойде, той разпространява тази актуализация на всички свои абонати. Доста е просто:

Как е реализирано на Go:

Има структура, която се синхронизира с помощта на Mutex. Има поле, което запазва състоянието на връзката на Fanout с базата, т.е. в момента той слуша и ще получава актуализации, а също и списък на всички налични канали – map, чийто ключ е каналът и struct под формата на стойности (по същество, то не се използва).

Два метода – Connected и Disconnected – позволяват на Fanout да знае, че имаме връзка с базата, тя се е появила и че връзката с базата е прекъсната. Във втория случай трябва да изключим всички клиенти и да им съобщим, че вече не могат да слушат нищо и че трябва да се преосъединят, тъй като връзката с тях е затворена.

Също така има метод Subscribe, който добавя канал в „слушателите“:

Има метод Unsubscribe, който премахва канала от слушателите, ако клиентът се е изключил, а също и метод Publish, който позволява разпространението на съобщение на всички абонати.

Въпрос: – Какво се предава по този канал?

МС: – Предава се модел, който е променен или ping (по същество просто число, integer).

МС: – Може да се предава каквото и да е, всяка структура – тя просто се превръща в JSON и това е всичко.

МС: – Получаваме уведомление от "Postgres" – в него е записано името на таблицата и идентификаторът. По името на таблицата и идентификатора получаваме необходимия запис, а след това изпращаме тази структура за публикуване.

Инфраструктура

Как изглежда това от гледна точка на инфраструктурата? Имаме 7 физически сървъра: един от тях е напълно отделен за базата данни, а на другите шест работят виртуални машини. Има 6 копия на API: всяка виртуална машина с API работи на отделен физически сървър – за надеждност.

Имаме два фронтенда, на които е инсталиран Keepalived за подобряване на достъпността, за да може в случай на проблем един фронтенд да замести друг. Освен това – две копия на CMS.

Също така имаме импортер за статистика. Има DB Slave, от който периодично се правят архиви. Има Pigeon Pusher – приложението, което разпраща известия на клиентите, както и инфраструктурни неща: Zabbix, Graylog2 и Chef.

Всъщност тази инфраструктура е излишна, защото 100 хиляди могат да се обслужват и с по-малко сървъри. Но тъй като имахме оборудване – решихме да го използваме (казаха ни, че е възможно – защо не).

Предимства на Go

След като работихме над това приложение, се появиха очевидните предимства на Go.

• Страхотна HTTP библиотека. С нея може да се създаде доста много "от кутията".
• Освен това, каналите, които ни позволиха да реализираме механизмите за изпращане на известия на клиентите много лесно.
• Страхотният Race detector ни помогна да отстраним няколко критични бъга (стейджинг инфраструктура). Всичко, което работи на стейджинг, е стартирано, компилирано с ключа Race; и ние, съответно, можем да видим на стейджинг инфраструктурата какви потенциални проблеми имаме.
• Минимализъм и простота на езика.

Търсим разработчици! Ако някой е заинтересован – моля.

Въпроси

Въпрос от аудиторията (наричан по-нататък В): – Мисля, че пропуснахте един важен момент относно Fan-out. Правилно ли разбирам, че когато изпращате отговор на клиента, вие се блокирате, ако клиентът не желае да чете?

МС: – Не, ние не се блокираме. Първо, всичко това е зад nginx, така че нямаме проблеми с бавни клиенти. Второ, клиентът има канал с кеш, по същество можем да изпратим до сто ъпдейта... Ако не можем да запишем в канала, той го изтрива. Ако видим, че каналът се е блокирал, просто ще затворим канала и всичко – клиентът ще се пренареди, ако възникне някакъв проблем. Затова тук по принцип не възниква блокировка.

В: – Не можеше ли веднага да се изпрати в Listen/Notify записа, а не таблица-идентификатор?

МС: – Listen/Notify има ограничение от 8000 байта на preload, който изпраща. Всъщност можеше да се изпрати, ако ставаше въпрос за малко количество данни, но ми се струва, че по начина, по който го правим, е просто по-надеждно. Ограниченията са в самия „Postgres”.

В: – Получават ли клиентите ъпдейти за мачове, които не ги интересуват?

МС: – Всъщност да. Обикновено там се провеждат 2-3 мача паралелно и то доста рядко. Ако клиентът гледа нещо, той обикновено следи мача, който тече. После, на клиента има локална база, в която се съхраняват всички тези ъпдейти, и дори без интернет връзка клиентът може да види всички минали мачове, за които има ъпдейти. По същество синхронизираме нашата база на сървера с локалната база на клиента, за да може той да работи и офлайн.

В: – Защо направихте своя ORM?

Алексей (един от разработчиците на „Смотри+”): – В онзи момент (преди година) ORM-ите бяха по-малко, отколкото сега, когато има доста. От повечето съществуващи ORM-и, най-много не ми харесва, че повечето от тях работят с празни интерфейси. Тоест методите в тези ORM-и са готови да приемат всичко: структура, указател за структура, число, нещо, което изобщо не е свързано с работата...

Нашият ORM генерира структури на базата на данните. Сам. И затова всички методи са конкретни, не използват рефлексия и т.н. Те приемат структури и очакват да използват точно тези структури, които ще получат.

В: – Колко души участваха?

МС: – В началния етап участваха двама души. Някъде през юни започнахме, през август основната част беше готова (първата версия). През септември беше релизът.

В: – Там, където описвате SSE, не използвате timeout. Защо така?

МС: – Ако говорим откровено, SSE всъщност е html5-протокол: стандартът SSE е предназначен за комуникация с браузерите, колкото разбирам. Има допълнителни функции, за да могат браузерите да се свързват отново (и така нататък), но те не ни трябват, защото имахме клиенти, които можеха да реализират всяка логика на свързване и получаване на информация. Направихме по-скоро нещо, приличащо на SSE, но не самия протокол.
Нямаше нужда. Колкото разбирам, клиентите реализираха механизма на свързването практически от нулата. За тях беше по принцип без разлика.

В: – Какви допълнителни инструменти използвахте?

МС: – Най-активно използвахме govet и golint, за да е стилът единен, а също и gofmt. Друга нищо не сме използвали.

В: – С какво извършвахте отладка?

МС: – Отладката по същество ставаше чрез тестове. Никакъв дебъгер, GOP не използвахме.

В: – Можете ли да покажете слайда, където е реализирана функцията Publish? Не ви ли притесняват еднописмените имена на променливите?

МС: – Не. Техните области на видимост са доста "тесни". Те не се използват никъде, освен тук (освен вътре в този клас), и е много компактно – заема само 7 реда.

В: – Нещо все пак не е интуитивно…

МС: – Не-не, това е истински код! Не е въпрос на стил. Просто това е един такъв утилитарен, много малък клас – само 3 полета вътре в класа...

МС: – По същество, всичките данни, които се синхронизират с клиентите (сезонни мачове, играчи), не се променят. Грубо казано, ако ще правим още един вид спорт, в който трябва да променяме мача, просто ще вземем предвид всичко в новата версия на клиента, а старите версии на клиента ще бъдат забранени.

В: – Има ли някакви външни пакети за управление на зависимости?

МС: – Използвахме go dep.

В: – В темата на доклада имаше нещо за видео, а в доклада за видео няма.

МС: – Не, в темата ми за видео няма нищо. Намира се под название "Смоти+" – така се нарича приложението.

В: – Казахте, че се стриймва на клиентите?..

МС: – С стрийминг на видео не се занимавахме. Това напълно го правеше "Мегафон". Да, не казах, че приложението е мегафоновско.

МС: – Go – за изпращане на всички данни – относно сметката, събитията на мача, статистиката… Go – това е напълно бекенд решение за приложението. Клиентът отнякъде трябва да научи каква връзка да използва за плеъра, за да може потребителят да гледа мача. Ние имаме връзки към видеа и стриймове, които са подготвени.

Малко реклама 🙂

Благодарим ви, че оставате с нас. Харесвате ли нашите статии? Искате ли да виждате повече интересни материали? Подкрепете ни, като направите поръчка или препоръчате на познати, облачни VPS за разработчици от $4.99, уникален аналог на entry-level сървъри, който е създаден от нас за вас: Цялата истина за VPS (KVM) E5-2697 v3 (6 ядра) 10GB DDR4 480GB SSD 1Gbps от $19 или как да делите правилно сървър? (с налични опции за RAID1 и RAID10, до 24 ядра и до 40GB DDR4).

Dell R730xd на половин цена в дата центъра Equinix Tier IV в Амстердам? Всичко това само при нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100TB от 199 $ в Нидерландия! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от 99 $! Чете се за това Как да построим инфраструктура от корпоративен клас с помощта на сървъри Dell R730xd E5-2650 v4 на стойност 9000 евро за малко пари?

Източник: habr.com