Михаил Салосин. Golang среща. Използване на Go в задната част на приложението Look+

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

Някой тук харесва ли хокей?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сега нека поговорим за това как работи самото взаимодействие.

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

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

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

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

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

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

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

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

Механизъм за изпращане на актуализации

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

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

PostgreSQL: слушане/уведомяване

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

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

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

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

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

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

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

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

Как се прилага в Go:

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

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

Има и метод за абониране, който добавя канала към „слушателите“:

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

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

ГОСПОЖИЦА: – Моделът, който се е променил или се предава ping (по същество само число, цяло число).

ГОСПОЖИЦА: – Можете да изпратите всичко, да изпратите всякаква структура, да я публикувате – просто се превръща в JSON и това е.

ГОСПОЖИЦА: – Получаваме известие от Postgres – то съдържа името и идентификатора на таблицата. Въз основа на името и идентификатора на таблицата получаваме необходимия запис и след това изпращаме тази структура за публикуване.

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

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

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

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

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

Плюсове на Go

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

• Страхотна http библиотека. С него можете да създадете доста неща извън кутията.
• Плюс канали, които ни позволиха много лесно да внедрим механизъм за изпращане на известия до клиенти.
• Чудесното нещо Race детектор ни позволи да елиминираме няколко критични грешки (инфраструктура за етапи). Стартира се всичко, което работи на етапа, компилирано с ключа Race; и ние, съответно, можем да разгледаме етапната инфраструктура, за да видим какви потенциални проблеми имаме.
• Минимализъм и простота на езика.

Търсим програмисти! Ако някой иска, моля.

Въпроси

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

ГОСПОЖИЦА: - Не, не блокираме. Първо, имаме всичко това зад nginx, тоест няма проблеми с бавните клиенти. Второ, клиентът има канал с буфер - всъщност там можем да поставим до сто актуализации... Ако не можем да пишем в канала, той го изтрива. Ако видим, че каналът е блокиран, тогава просто ще затворим канала и това е - клиентът ще се свърже отново, ако възникне проблем. Следователно по принцип тук няма блокиране.

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

ГОСПОЖИЦА: – Listen/Notify има ограничение от 8 хиляди байта за предварителното зареждане, което изпраща. По принцип би било възможно да изпратим, ако имаме работа с малко количество данни, но ми се струва, че този начин [начинът, по който го правим] е просто по-надежден. Ограниченията са в самия Postgres.

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

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

AT: – Защо направихте свой собствен ORM?

Алексей (един от разработчиците на Look+): – По това време (беше преди година) имаше по-малко ORM, отколкото сега, когато има доста от тях. Любимото ми нещо за повечето ORM е, че повечето от тях работят на празни интерфейси. Тоест, методите в тези ORMs са готови да поемат всичко: структура, указател на структура, число, нещо напълно без значение...

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

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

ГОСПОЖИЦА: – В началния етап участваха двама души. Започнахме някъде през юни, а през август беше готова основната част (първата версия). Имаше освобождаване през септември.

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

ГОСПОЖИЦА: – Честно казано, SSE все още е html5 протокол: стандартът SSE е предназначен да комуникира с браузъри, доколкото разбирам. Има допълнителни функции, така че браузърите да могат да се свързват отново (и т.н.), но ние не се нуждаем от тях, защото имахме клиенти, които можеха да прилагат всякаква логика за свързване и получаване на информация. Ние не направихме SSE, а по-скоро нещо подобно на SSE. Това не е самият протокол.
Не е необходимо. Доколкото разбирам, клиентите внедриха механизма за свързване почти от нулата. Всъщност не им пукаше.

AT: – Какви допълнителни помощни програми използвахте?

ГОСПОЖИЦА: – Най-активно използвахме govet и golint, за да обединим стила, както и gofmt. Нищо друго не е използвано.

AT: – Какво използвахте за отстраняване на грешки?

ГОСПОЖИЦА: – Отстраняването на грешки до голяма степен беше извършено чрез тестове. Не използвахме никакъв дебъгер или GOP.

AT: – Можете ли да върнете слайда, където е реализирана функцията Публикуване? Еднобуквените имена на променливи объркват ли ви?

ГОСПОЖИЦА: - Не. Те имат доста „тесен“ обхват на видимост. Те не се използват никъде другаде, освен тук (с изключение на вътрешните части на този клас), и е много компактен - отнема само 7 реда.

AT: – Някак все още не е интуитивно...

ГОСПОЖИЦА: - Не, не, това е истински код! Не става въпрос за стил. Това е просто такъв утилитарен, много малък клас - само 3 полета вътре в класа...

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

AT: – Има ли пакети за управление на зависимости на трети страни?

ГОСПОЖИЦА: – Използвахме go dep.

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

ГОСПОЖИЦА: – Не, нямам нищо в темата за видеото. Нарича се "Look+" - това е името на приложението.

AT: – Казахте, че се предава на клиенти?..

ГОСПОЖИЦА: – Не сме участвали в поточно видео. Това беше изцяло направено от Мегафон. Да, не съм казал, че приложението е MegaFon.

ГОСПОЖИЦА: – Go – за изпращане на всички данни – за резултат, за събития от мачове, статистика... Go е целият бекенд за приложението. Клиентът трябва да знае от някъде кой линк да използва за играча, за да може потребителят да гледа мача. Имаме подготвени връзки към видеоклипове и потоци.

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

Благодарим ви, че останахте с нас. Харесвате ли нашите статии? Искате ли да видите още интересно съдържание? Подкрепете ни, като направите поръчка или препоръчате на приятели, облачен VPS за разработчици от $4.99, уникален аналог на сървъри от начално ниво, който беше изобретен от нас за вас: Цялата истина за VPS (KVM) E5-2697 v3 (6 ядра) 10GB DDR4 480GB SSD 1Gbps от $19 или как да споделите сървър? (предлага се с RAID1 и RAID10, до 24 ядра и до 40GB 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 TV от $199 в Холандия! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - от $99! Прочети за Как да изградим инфраструктура Corp. клас с използване на сървъри Dell R730xd E5-2650 v4 на стойност 9000 евро за стотинка?

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