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

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

Има ли някой от присъстващите, който обича хокей?

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

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

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

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

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

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

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

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

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

Въз основа на това, имахме два варианта на протокола:

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

Събития, изпращани от сървъра

Няколко думи за начина, по който функционира тази система...

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

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

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

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

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

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

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

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

В резултат сега ping идва от същия канал, от който идва update.

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

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

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

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

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

PostgreSQL: Listen/Notify

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

При 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 и това е всичко.

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

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

Как изглежда това от инфраструктурна гледна точка? Имаме 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 байта на предварителното зареждане, което изпраща. По принцип можеше да се изпраща, ако ставаше въпрос за малко количество данни, но мисля, че така [както ние правим] е просто по-надеждно. Ограниченията са в самия „Postgres“.

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

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

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

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

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

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

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

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

МС: – Ако говорим честно, 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 Е5-2650 v4 на стойност 9000 евро за копейки?

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