Mixail Salosin (keyingi o'rinlarda - MS): - Hammaga salom! Mening ismim Maykl. Men MC2 Software da backend dasturchisi sifatida ishlayman va Look+ mobil ilovasining backendida Go-dan foydalanish haqida gaplashaman.
Bu erda kimdir xokkeyni yaxshi ko'radimi?
Unda ushbu ilova siz uchun. U Android va iOS uchun moʻljallangan boʻlib, turli sport tadbirlarini onlayn va yozib olingan translyatsiyalarni tomosha qilish uchun ishlatiladi. Ilovada, shuningdek, turli statistik ma'lumotlar, matnli translyatsiyalar, konferentsiyalar, turnirlar uchun jadvallar va muxlislar uchun foydali bo'lgan boshqa ma'lumotlar mavjud.
Shuningdek, ilovada video lahzalar kabi narsa mavjud, ya'ni siz o'yinlarning eng muhim lahzalarini (gollar, janglar, otishmalar va boshqalar) ko'rishingiz mumkin. Agar siz translyatsiyani to'liq ko'rishni istamasangiz, faqat eng qiziqarlilarini tomosha qilishingiz mumkin.
Rivojlanishda nimadan foydalandingiz?
Asosiy qismi Go'da yozilgan. Mobil mijozlar muloqot qiladigan API Go-da yozilgan. Go'da mobil telefonlarga push-bildirishnomalarni yuborish xizmati ham yozilgan. Biz ham bir kun kelib gaplashishimiz mumkin bo'lgan o'z ORMimizni yozishimiz kerak edi. Go'da ba'zi kichik xizmatlar yozilgan: muharrirlar uchun rasmlar o'lchamini o'zgartirish va yuklash...
Ma'lumotlar bazasi sifatida biz PostgreSQL dan foydalandik. Tahrirlovchi interfeysi ActiveAdmin gem yordamida Ruby on Rails-da yozilgan. Statistik provayderdan statistik ma'lumotlarni import qilish ham Ruby-da yozilgan.
Tizim API testlari uchun biz Python unittest-dan foydalandik. Memcached API to'lov qo'ng'iroqlarini bostirish uchun ishlatiladi, "Chef" konfiguratsiyani boshqarish uchun ishlatiladi, Zabbix ichki tizim statistikasini yig'ish va kuzatish uchun ishlatiladi. Graylog2 jurnallar yig'ish uchun, Slate - mijozlar uchun API hujjatlari.
Protokol tanlash
Biz duch kelgan birinchi muammo: biz quyidagi fikrlarga asoslanib, backend va mobil mijozlar o'rtasidagi o'zaro aloqa protokolini tanlashimiz kerak edi...
- Eng muhim talab: mijozlar haqidagi ma'lumotlar real vaqtda yangilanishi kerak. Ya'ni, hozirda translyatsiyani tomosha qilayotgan har bir kishi deyarli bir zumda yangilanishlarni olishi kerak.
- Ishlarni soddalashtirish uchun biz mijozlar bilan sinxronlashtirilgan ma'lumotlar o'chirilmaydi, lekin maxsus bayroqlar yordamida yashiriladi deb taxmin qildik.
- Har qanday kam uchraydigan so'rovlar (masalan, statistika, jamoa tarkibi, jamoa statistikasi) oddiy GET so'rovlari orqali olinadi.
- Bundan tashqari, tizim bir vaqtning o'zida 100 ming foydalanuvchini osongina qo'llab-quvvatlashi kerak edi.
Shunga asoslanib, bizda ikkita protokol varianti bor edi:
- Veb-rozetkalar. Ammo mijozdan serverga kanallar kerak emas edi. Biz faqat serverdan mijozga yangilanishlarni yuborishimiz kerak edi, shuning uchun veb-soket ortiqcha variantdir.
- Server tomonidan yuborilgan voqealar (SSE) to'g'ri keldi! Bu juda oddiy va asosan bizga kerak bo'lgan hamma narsani qondiradi.
Server tomonidan yuborilgan voqealar
Bu narsa qanday ishlashi haqida bir necha so'z ...
U http ulanishi ustida ishlaydi. Mijoz so'rov yuboradi, server Content-Type: text/event-stream bilan javob beradi va mijoz bilan aloqani o'chirmaydi, lekin ulanishga ma'lumotlarni yozishni davom ettiradi:
Ma'lumotlar mijozlar bilan kelishilgan formatda yuborilishi mumkin. Bizning holatlarimizda biz uni ushbu shaklda yubordik: o'zgartirilgan tuzilmaning nomi (shaxs, o'yinchi) voqea maydoniga yuborildi va o'yinchi uchun yangi, o'zgartirilgan maydonlar bilan JSON ma'lumotlar maydoniga yuborildi.
Keling, o'zaro ta'sirning o'zi qanday ishlashi haqida gapiraylik.
- Mijoz qiladigan birinchi narsa bu xizmat bilan oxirgi marta sinxronlanganligini aniqlashdir: u o'zining mahalliy ma'lumotlar bazasini ko'rib chiqadi va u tomonidan qayd etilgan oxirgi o'zgarish sanasini aniqlaydi.
- Ushbu sana bilan so'rov yuboradi.
- Bunga javoban biz unga o'sha kundan beri sodir bo'lgan barcha yangilanishlarni yuboramiz.
- Shundan so'ng, u jonli kanalga ulanadi va ushbu yangilanishlarga muhtoj bo'lmaguncha yopilmaydi:
Biz unga o'zgarishlar ro'yxatini yuboramiz: agar kimdir gol ursa, o'yin hisobini o'zgartiramiz, agar u jarohat olsa, u ham real vaqt rejimida yuboriladi. Shunday qilib, mijozlar bir zumda o'yin voqealari tasmasidan so'nggi ma'lumotlarni olishadi. Vaqti-vaqti bilan, mijoz server o'lmaganligini, unga hech narsa bo'lmaganligini tushunishi uchun biz har 15 soniyada vaqt belgisini yuboramiz - shunda u hamma narsa tartibda ekanligini va qayta ulanishga hojat yo'qligini biladi.
Jonli ulanishga qanday xizmat ko'rsatiladi?
- Avvalo, biz buferlangan yangilanishlar olinadigan kanal yaratamiz.
- Shundan so'ng biz yangilanishlarni olish uchun ushbu kanalga obuna bo'lamiz.
- Mijoz hamma narsa yaxshi ekanligini bilishi uchun biz to'g'ri sarlavhani o'rnatdik.
- Birinchi pingni yuboring. Biz shunchaki joriy ulanish vaqtini yozib olamiz.
- Shundan so'ng, biz kanaldan yangilanish kanali yopilgunga qadar tsiklda o'qiymiz. Kanal vaqti-vaqti bilan joriy vaqt tamg'asini yoki biz allaqachon ochiq ulanishlar uchun yozayotgan o'zgarishlarni oladi.
Biz duch kelgan birinchi muammo quyidagicha edi: mijoz bilan ochilgan har bir ulanish uchun biz har 15 soniyada bir marta belgi qo'yadigan taymer yaratdik - ma'lum bo'lishicha, agar bizda bitta mashinada (bitta API server bilan) 6 ming ulanish ochilgan bo'lsa, 6 ming taymer yaratildi. Bu mashinaning kerakli yukni ushlab turmasligiga olib keldi. Muammo biz uchun unchalik aniq emas edi, lekin biz ozgina yordam oldik va uni tuzatdik.
Natijada, endi bizning pingimiz yangilanish kelgan kanaldan keladi.
Shunga ko'ra, har 15 soniyada bir marta belgi qo'yadigan faqat bitta taymer mavjud.
Bu erda bir nechta yordamchi funktsiyalar mavjud - sarlavha, ping va strukturaning o'zini yuborish. Ya'ni, jadval nomi (odam, o'yin, mavsum) va ushbu yozuv haqidagi ma'lumotlar bu erda uzatiladi:
Yangilanishlarni yuborish mexanizmi
Endi o'zgarishlar qaerdan kelib chiqqanligi haqida bir oz. Bizda ko'rsatuvni real vaqt rejimida tomosha qiladigan bir nechta odam, muharrirlar bor. Ular barcha voqealarni yaratadilar: kimdir maydondan chetlatildi, kimdir jarohat oldi, qandaydir almashtirish...
CMS yordamida ma'lumotlar ma'lumotlar bazasiga kiradi. Shundan so'ng, ma'lumotlar bazasi Tinglash/Ogohlantirish mexanizmi yordamida API serverlarini bu haqda xabardor qiladi. API serverlari allaqachon bu ma'lumotlarni mijozlarga yuboradi. Shunday qilib, bizda aslida ma'lumotlar bazasiga ulangan bir nechta serverlar mavjud va ma'lumotlar bazasida maxsus yuk yo'q, chunki mijoz hech qanday tarzda ma'lumotlar bazasi bilan bevosita aloqa qilmaydi:
PostgreSQL: Tinglash/Ogohlantirish
Postgres-dagi Tinglash/Ogohlantirish mexanizmi sizga voqea obunachilariga ba'zi voqea o'zgarganligi haqida xabar berish imkonini beradi - ma'lumotlar bazasida ba'zi yozuvlar yaratilgan. Buning uchun biz oddiy trigger va funktsiyani yozdik:
Yozuvni kiritish yoki o'zgartirishda biz data_updates kanalida xabar berish funksiyasini chaqiramiz, u erga jadval nomini va o'zgartirilgan yoki kiritilgan yozuvning identifikatorini uzatamiz.
Mijoz bilan sinxronlashtirilishi kerak bo'lgan barcha jadvallar uchun biz triggerni aniqlaymiz, u yozuvni o'zgartirgandan / yangilagandan so'ng quyidagi slaydda ko'rsatilgan funktsiyani chaqiradi.
API ushbu o'zgarishlarga qanday obuna bo'ladi?
Fanout mexanizmi yaratildi - u mijozga xabarlar yuboradi. U barcha mijozlar kanallarini to'playdi va ushbu kanallar orqali olingan yangilanishlarni yuboradi:
Bu erda ma'lumotlar bazasiga ulanadigan va kanalni (data_updates) tinglashni xohlayotganini aytadigan standart pq kutubxonasi ulanishning ochiqligini va hamma narsa yaxshi ekanligini tekshiradi. Joyni tejash uchun xato tekshiruvini o'tkazib yuboryapman (tekshirish xavfli).
Keyinchalik, biz har 15 soniyada ping yuboradigan Ticker-ni asinxron ravishda o'rnatamiz va biz obuna bo'lgan kanalni tinglashni boshlaymiz. Agar biz ping qabul qilsak, biz ushbu pingni nashr qilamiz. Agar biz biron bir yozuvni olsak, biz ushbu yozuvni ushbu Fanout-ning barcha obunachilariga e'lon qilamiz.
Fan-out qanday ishlaydi?
Rus tilida bu "ajratish" deb tarjima qilinadi. Bizda ba'zi yangilanishlarni olishni istagan abonentlarni ro'yxatdan o'tkazadigan bitta ob'ekt mavjud. Va ushbu ob'ektga yangilanish kelishi bilan u ushbu yangilanishni barcha obunachilarga tarqatadi. Yetarlicha oddiy:
Go'da qanday amalga oshiriladi:
Tuzilma mavjud, u Mutexlar yordamida sinxronlashtiriladi. U Fanout-ning ma'lumotlar bazasiga ulanish holatini saqlaydigan maydonga ega, ya'ni u hozir tinglanmoqda va yangilanishlarni oladi, shuningdek, barcha mavjud kanallar ro'yxati - xarita, uning kaliti kanal va struktura shaklida. qadriyatlar (asosan u hech qanday tarzda ishlatilmaydi).
Ikkita usul - Ulangan va O'chirilgan - Fanout-ga bazaga ulanishimiz borligini, u paydo bo'lganligini va bazaga ulanish buzilganligini aytishga imkon beradi. Ikkinchi holda, siz barcha mijozlarni uzib qo'yishingiz va ularga endi hech narsani tinglay olmasligini va ular bilan aloqa yopilganligi sababli qayta ulanishlarini aytishingiz kerak.
Kanalni "tinglovchilar" ga qo'shadigan obuna bo'lish usuli ham mavjud:
Obunani bekor qilish usuli mavjud bo'lib, agar mijoz uzilib qolsa, kanalni tinglovchilardan olib tashlaydi, shuningdek, barcha obunachilarga xabar yuborish imkonini beruvchi Publish usuli mavjud.
Savol: – Bu kanal orqali nimalar uzatiladi?
XONIM: – O‘zgartirilgan yoki ping yuborilgan model (asosan shunchaki raqam, butun son).
XONIM: - Siz istalgan narsani yuborishingiz, istalgan tuzilmani yuborishingiz, nashr qilishingiz mumkin - u shunchaki JSONga aylanadi va tamom.
XONIM: – Biz Postgres’dan bildirishnoma olamiz – unda jadval nomi va identifikator mavjud. Jadval nomi va identifikatoriga asoslanib, biz kerakli yozuvni olamiz, keyin esa ushbu tuzilmani nashrga jo'natamiz.
Infrastruktura
Bu infratuzilma nuqtai nazaridan qanday ko'rinadi? Bizda 7 ta apparat serverlari mavjud: ulardan biri to'liq ma'lumotlar bazasiga bag'ishlangan, qolgan oltitasi virtual mashinalarda ishlaydi. APIning 6 nusxasi mavjud: API bilan har bir virtual mashina alohida apparat serverida ishlaydi - bu ishonchlilik uchun.
Kirish imkoniyatini yaxshilash uchun bizda ikkita frontend o‘rnatilgan Keepalived bor, shunda biror narsa yuz bersa, bir frontend boshqasini almashtirishi mumkin. Shuningdek - CMSning ikki nusxasi.
Statistikani import qiluvchi ham mavjud. Vaqti-vaqti bilan zaxira nusxalari yaratiladigan DB Slave mavjud. Mijozlarga push-bildirishnomalar yuboradigan Pigeon Pusher ilovasi, shuningdek infratuzilma ob'ektlari mavjud: Zabbix, Graylog2 va Chef.
Aslida, bu infratuzilma ortiqcha, chunki 100 mingga kamroq serverlar bilan xizmat ko'rsatish mumkin. Ammo temir bor edi - biz uni ishlatdik (bizga bu mumkin, deb aytishdi - nima uchun emas).
Go-ning afzalliklari
Ushbu dastur ustida ishlaganimizdan so'ng, Go'ning bunday aniq afzalliklari paydo bo'ldi.
- Ajoyib http kutubxonasi. Uning yordamida siz qutidan juda ko'p narsalarni yaratishingiz mumkin.
- Bundan tashqari, mijozlarga bildirishnomalarni yuborish mexanizmini juda oson amalga oshirishga imkon bergan kanallar.
- Ajoyib narsa Poyga detektori bizga bir nechta muhim xatolarni (staging infratuzilmasi) yo'q qilishga imkon berdi. Sahnalashtirishda ishlaydigan hamma narsa ishga tushiriladi, Race tugmasi bilan kompilyatsiya qilinadi; va shunga ko'ra, bizda qanday muammolar borligini ko'rish uchun sahnalashtirish infratuzilmasini ko'rib chiqishimiz mumkin.
- Minimalizm va tilning soddaligi.
Biz dasturchilarni qidiramiz! Kim xohlasa, iltimos.
Sizning savollaringiz
Tomoshabinlar savoli (keyingi o'rinlarda – B): – Menimcha, siz Fan-out bilan bog'liq bir muhim narsani o'tkazib yuborgansiz. Mijozga javob yuborganingizda, agar mijoz o'qishni istamasa, blokirovka qilishingizni tushunishim to'g'rimi?
XONIM: - Yo'q, biz to'sqinlik qilmayapmiz. Birinchidan, bizda bularning barchasi nginx ortida bor, ya'ni sekin mijozlar bilan hech qanday muammo yo'q. Ikkinchidan, mijozning buferli kanali bor - aslida biz u erda yuztagacha yangilanishlarni qo'yishimiz mumkin... Agar kanalga yoza olmasak, u uni o'chiradi. Agar biz kanal bloklanganligini ko'rsak, biz shunchaki kanalni yopamiz va tamom - agar biron bir muammo yuzaga kelsa, mijoz qayta ulanadi. Shuning uchun, printsipial jihatdan, bu erda hech qanday blokirovka yo'q.
Savol: – Identifikatorlar jadvalini emas, balki Tinglash/Ogohlantirish-ga darhol yozuvni yuborish mumkin emasmi?
XONIM: – Tinglash/Ogohlantirish yuboradigan oldindan yuklashda 8 ming bayt chegarasiga ega. Aslida, agar biz oz miqdordagi ma'lumotlar bilan ishlayotgan bo'lsak, jo'natish mumkin edi, lekin menimcha, bu yo'l [biz buni qilish usuli] shunchaki ishonchliroq. Cheklovlar Postgresning o'zida.
Savol: – Mijozlar o'zlarini qiziqtirmagan o'yinlar haqida yangilanishlarni oladimi?
XONIM: - Umuman olganda, ha. Qoidaga ko'ra, parallel ravishda 2-3 ta o'yin bo'lib o'tadi va hatto kamdan-kam hollarda. Agar mijoz biror narsani ko'rayotgan bo'lsa, u odatda bo'layotgan o'yinni tomosha qiladi. Keyin mijozda ushbu yangilanishlar qo'shiladigan mahalliy ma'lumotlar bazasi mavjud va hatto Internetga ulanmasdan ham mijoz o'zi yangilangan barcha o'tgan o'yinlarni ko'rishi mumkin. Aslida, biz serverdagi ma'lumotlar bazasini mijozning mahalliy ma'lumotlar bazasi bilan sinxronlashtiramiz, shunda u oflayn rejimda ishlaydi.
Savol: – Nima uchun ORMni oʻzingiz yaratdingiz?
Aleksey (Look+ dasturini ishlab chiquvchilardan biri): - O'sha paytda (bir yil oldin edi) hozirgidan ko'ra kamroq ORMlar bor edi, ular juda ko'p. Ko'pgina ORMlar haqida mening eng sevimli narsam shundaki, ularning aksariyati bo'sh interfeyslarda ishlaydi. Ya'ni, ushbu ORMdagi usullar har qanday narsani olishga tayyor: struktura, struktura ko'rsatkichi, raqam, umuman ahamiyatsiz narsa ...
Bizning ORM ma'lumotlar modeliga asoslangan tuzilmalarni yaratadi. O'zim. Va shuning uchun barcha usullar aniq, aks ettirishdan foydalanmang va hokazo. Ular tuzilmalarni qabul qiladilar va kelgan tuzilmalardan foydalanishni kutishadi.
Savol: - Qancha odam qatnashdi?
XONIM: – Dastlabki bosqichda ikki kishi ishtirok etdi. Biz iyun oyida bir joyda boshladik va avgust oyida asosiy qism tayyor edi (birinchi versiya). Sentyabr oyida nashr etildi.
Savol: – SSE tasvirlangan joyda siz taym-outdan foydalanmaysiz. Nega bunday?
XONIM: - Rostini aytsam, SSE hali ham html5 protokoli: SSE standarti men tushunganimdek, brauzerlar bilan muloqot qilish uchun mo'ljallangan. Brauzerlar qayta ulanishi uchun (va hokazo) qo'shimcha funktsiyalarga ega, ammo bizga ular kerak emas, chunki bizda ulanish va ma'lumot olish uchun har qanday mantiqni amalga oshiradigan mijozlar bor edi. Biz SSE yaratmadik, balki SSEga o'xshash narsani yaratdik. Bu protokolning o'zi emas.
Hech qanday ehtiyoj yo'q edi. Men tushunganimdek, mijozlar ulanish mexanizmini deyarli noldan boshlab amalga oshirdilar. Ularga umuman ahamiyat bermadi.
Savol: – Qanday qo'shimcha yordamchi dasturlardan foydalangansiz?
XONIM: - Biz uslubni birlashtirish uchun govet va golintni, shuningdek, gofmtni eng faol ishlatganmiz. Boshqa hech narsa ishlatilmadi.
Savol: - Nosozliklarni tuzatish uchun nimadan foydalandingiz?
XONIM: – Nosozliklarni tuzatish asosan testlar yordamida amalga oshirildi. Biz hech qanday tuzatuvchi yoki GOP ishlatmadik.
Savol: – Publish funksiyasi amalga oshirilgan slaydni qaytara olasizmi? Bir harfli o'zgaruvchilar nomlari sizni chalkashtirib yuboradimi?
XONIM: - Yo'q. Ular juda "tor" ko'rish doirasiga ega. Ular bu erdan boshqa joyda ishlatilmaydi (ushbu sinfning ichki qismlari bundan mustasno) va u juda ixcham - u faqat 7 qatorni oladi.
Savol: - Negadir bu hali ham intuitiv emas ...
XONIM: - Yo'q, yo'q, bu haqiqiy kod! Bu uslub haqida emas. Bu shunchaki utilitar, juda kichik sinf - sinf ichida atigi 3 ta maydon ...
XONIM: - Umuman olganda, mijozlar bilan sinxronlashtirilgan barcha ma'lumotlar (mavsumdagi o'yinlar, o'yinchilar) o'zgarmaydi. Taxminan aytganda, agar biz o'yinni o'zgartirishimiz kerak bo'lgan boshqa sport turini qilsak, biz mijozning yangi versiyasida hamma narsani hisobga olamiz va mijozning eski versiyalari taqiqlanadi.
Savol: – Uchinchi tomonga qaramlikni boshqarish paketlari bormi?
XONIM: – Biz go depdan foydalanganmiz.
Savol: - Hisobot mavzusida video haqida nimadir bor edi, lekin video haqida xabarda hech narsa yo'q edi.
XONIM: - Yo'q, menda video mavzusida hech narsa yo'q. U "Look+" deb ataladi - bu dasturning nomi.
Savol: – Mijozlarga uzatiladi, dedingizmi?..
XONIM: - Biz video strimingda ishtirok etmadik. Bu butunlay Megafon tomonidan amalga oshirildi. Ha, men dastur MegaFon ekanligini aytmadim.
XONIM: – Go – barcha ma’lumotlarni jo‘natish uchun – hisob, o‘yin voqealari, statistik ma’lumotlar... Go ilovaning to‘liq backendidir. Mijoz o'yinchi uchun qaysi havoladan foydalanishni qaerdandir bilishi kerak, shunda foydalanuvchi o'yinni tomosha qilishi mumkin. Bizda tayyorlangan videolar va oqimlarga havolalar mavjud.
Ba'zi reklamalar 🙂
Biz bilan qolganingiz uchun tashakkur. Bizning maqolalarimiz sizga yoqdimi? Ko'proq qiziqarli tarkibni ko'rishni xohlaysizmi? Buyurtma berish yoki do'stlaringizga tavsiya qilish orqali bizni qo'llab-quvvatlang, , Siz uchun biz tomonidan ixtiro qilingan boshlang'ich darajadagi serverlarning noyob analogi: (RAID1 va RAID10, 24 tagacha yadro va 40 Gb gacha DDR4 bilan mavjud).
Amsterdamdagi Equinix Tier IV ma'lumotlar markazida Dell R730xd 2 baravar arzonmi? Faqat shu yerda Gollandiyada! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollardan! Haqida o'qing
Manba: www.habr.com