Михаил Салосин (цаашид - MS): - Бүгдээрээ сайн уу! Намайг Майкл гэдэг. Би MC2 Software-д backend хөгжүүлэгчээр ажилладаг бөгөөд Look+ гар утасны програмын арын хэсэгт Go-г ашиглах талаар ярих болно.
Энд хоккейд дуртай хүн байна уу?
Тэгвэл энэ аппликейшн танд зориулагдана. Энэ нь Android болон iOS-д зориулагдсан бөгөөд төрөл бүрийн спортын арга хэмжээний нэвтрүүлгийг онлайнаар үзэж, бичлэг хийхэд ашигладаг. Энэхүү програм нь янз бүрийн статистик, текст нэвтрүүлэг, бага хурал, тэмцээнд зориулсан хүснэгтүүд болон шүтэн бишрэгчдэд хэрэгтэй бусад мэдээллийг агуулдаг.
Мөн програмд видео агшин гэх мэт зүйл байдаг, өөрөөр хэлбэл та тоглолтын хамгийн чухал мөчүүдийг (гоол, тулаан, шидэлт гэх мэт) үзэх боломжтой. Хэрэв та нэвтрүүлгийг бүхэлд нь үзэхийг хүсэхгүй байгаа бол зөвхөн хамгийн сонирхолтой нэвтрүүлгийг үзэх боломжтой.
Та хөгжилд юу ашигласан бэ?
Гол хэсгийг Go дээр бичсэн. Гар утасны үйлчлүүлэгчдийн харилцдаг API нь Go дээр бичигдсэн. Мөн Go-д гар утас руу түлхэх мэдэгдэл илгээх үйлчилгээг бичсэн. Бид ч бас хэзээ нэгэн цагт ярилцаж магадгүй ORM-ээ бичих хэрэгтэй болсон. За, зарим жижиг үйлчилгээг Go дээр бичсэн: засварлагчдад зориулж зургийн хэмжээг өөрчлөх, ачаалах ...
Бид PostgreSQL-г мэдээллийн сан болгон ашигласан. Редакторын интерфейсийг ActiveAdmin эрдэнийн тусламжтайгаар Ruby on Rails дээр бичсэн. Статистикийн үйлчилгээ үзүүлэгчээс статистик мэдээллийг импортлох нь мөн Ruby дээр бичигдсэн байдаг.
Системийн API тестийн хувьд бид Python unittest ашигласан. Memcached нь API төлбөрийн дуудлагыг дарахад, "Chef" нь тохиргоог хянахад, Zabbix нь дотоод системийн статистик мэдээллийг цуглуулах, хянахад ашиглагддаг. Graylog2 нь бүртгэл цуглуулахад зориулагдсан, Slate нь үйлчлүүлэгчдэд зориулсан API баримт бичиг юм.
Протоколын сонголт
Бидэнд тулгарсан эхний асуудал: бид дараах зүйлд тулгуурлан арын болон гар утасны үйлчлүүлэгчдийн хоорондын харилцан үйлчлэлийн протоколыг сонгох шаардлагатай болсон...
- Хамгийн чухал шаардлага: үйлчлүүлэгчдийн мэдээллийг бодит цаг хугацаанд нь шинэчлэх ёстой. Өөрөөр хэлбэл, одоо нэвтрүүлгийг үзэж байгаа хүн бүр шинэчлэлтийг шууд хүлээн авах ёстой.
- Аливаа зүйлийг хялбарчлахын тулд бид үйлчлүүлэгчидтэй синхрончлогдсон өгөгдлийг устгадаггүй, харин тусгай тугуудыг ашиглан нуудаг гэж үзсэн.
- Бүх төрлийн ховор хүсэлтийг (статистик, багийн бүрэлдэхүүн, багийн статистик гэх мэт) энгийн GET хүсэлтээр авдаг.
- Нэмж дурдахад систем нь 100 мянган хэрэглэгчийг нэгэн зэрэг хялбархан дэмжих ёстой байв.
Үүний үндсэн дээр бид хоёр протоколын сонголттой байсан:
- Websockets. Гэхдээ бидэнд үйлчлүүлэгчээс сервер хүртэлх суваг хэрэггүй байсан. Бид зөвхөн серверээс үйлчлүүлэгч рүү шинэчлэлт илгээх шаардлагатай байсан тул вэбсокет нь илүүдэхгүй сонголт юм.
- Server-Sent Events (SSE) яг л гарч ирэв! Энэ нь маш энгийн бөгөөд үндсэндээ бидний хэрэгцээтэй бүх зүйлийг хангадаг.
Серверээс илгээсэн үйл явдлууд
Энэ зүйл хэрхэн ажилладаг талаар хэдэн үг хэлье ...
Энэ нь http холболтын дээр ажилладаг. Үйлчлүүлэгч хүсэлт илгээж, сервер нь Content-Type: text/event-stream-ээр хариу өгөх бөгөөд клиенттэй холболтыг хаадаггүй, харин холболтод өгөгдөл бичсээр байна:
Мэдээллийг үйлчлүүлэгчидтэй тохиролцсон форматаар илгээх боломжтой. Манай тохиолдолд бид үүнийг дараах хэлбэрээр илгээсэн: өөрчлөгдсөн бүтцийн нэрийг (хүн, тоглогч) үйл явдлын талбарт илгээсэн бөгөөд тоглогчийн шинэ, өөрчлөгдсөн талбар бүхий JSON-г өгөгдлийн талбарт илгээсэн.
Одоо харилцан үйлчлэл нь өөрөө хэрхэн ажилладаг талаар ярилцъя.
- Үйлчлүүлэгчийн хийх хамгийн эхний зүйл бол үйлчилгээтэй хамгийн сүүлд синхрончлол хийгдсэнийг тодорхойлох явдал юм: энэ нь өөрийн локал мэдээллийн санг харж, хамгийн сүүлд бүртгэгдсэн өөрчлөлтийн огноог тодорхойлдог.
- Энэ огноотой хүсэлтийг илгээдэг.
- Үүний хариуд бид тэр өдрөөс хойш гарсан бүх шинэчлэлтийг түүнд илгээдэг.
- Үүний дараа энэ нь шууд сувагтай холбогдож, эдгээр шинэчлэлтүүд шаардлагатай болтол хаагдахгүй.
Бид түүнд өөрчлөлтийн жагсаалтыг илгээдэг: хэрэв хэн нэгэн гоол оруулбал бид тоглолтын оноог өөрчилдөг, хэрэв тэр бэртсэн бол үүнийг бодит цаг хугацаанд нь илгээдэг. Тиймээс үйлчлүүлэгчид тоглолтын үйл явдлын мэдээллийн санд хамгийн сүүлийн үеийн мэдээллийг шууд хүлээн авдаг. Үйлчлүүлэгч сервер үхээгүй, түүнд юу ч болоогүй гэдгийг ойлгохын тулд бид 15 секунд тутамд цагийн тэмдэг илгээдэг бөгөөд ингэснээр бүх зүйл эмх цэгцтэй байгаа бөгөөд дахин холбогдох шаардлагагүй болно.
Шууд холболтын үйлчилгээ хэрхэн хийгддэг вэ?
- Юуны өмнө бид буфержүүлсэн шинэчлэлтүүдийг хүлээн авах суваг үүсгэдэг.
- Үүний дараа бид энэ сувгийг захиалж шинэчлэлтүүдийг хүлээн авдаг.
- Үйлчлүүлэгч бүх зүйл зүгээр гэдгийг мэдэхийн тулд бид зөв толгойг тохируулсан.
- Эхний пинг илгээнэ үү. Бид зүгээр л одоогийн холболтын цагийг тэмдэглэдэг.
- Үүний дараа бид шинэчлэлтийн суваг хаагдах хүртэл сувгаас давталтаар уншина. Суваг нь одоогийн цагийн тэмдэг эсвэл нээлттэй холболтод бидний бичиж байгаа өөрчлөлтийг үе үе хүлээн авдаг.
Бидэнд тулгарсан хамгийн эхний асуудал бол: үйлчлүүлэгчтэй нээсэн холболт бүрийн хувьд бид 15 секунд тутамд нэг удаа тэмдэглэдэг таймер үүсгэсэн - хэрэв бид нэг машинаар (нэг API сервертэй) 6 мянган холболт нээгдсэн бол 6 мянган таймер бүтээгдсэн. Энэ нь машин шаардлагатай ачааллыг даахгүй болоход хүргэсэн. Асуудал нь бидний хувьд тийм ч тодорхой биш байсан ч бид бага зэрэг тусламж авч, үүнийг зассан.
Үүний үр дүнд одоо бидний пинг шинэчлэлт ирдэг сувгаас ирдэг.
Үүний дагуу 15 секунд тутамд нэг удаа хадаг ганц таймер байдаг.
Энд хэд хэдэн туслах функцүүд байдаг - толгой, ping болон бүтцийг өөрөө илгээх. Өөрөөр хэлбэл, хүснэгтийн нэр (хүн, тэмцээн, улирал) болон энэ оруулгын талаархи мэдээллийг энд дамжуулна.
Шинэчлэлтүүдийг илгээх механизм
Одоо өөрчлөлтүүд хаанаас ирсэн талаар бага зэрэг. Бидэнд нэвтрүүлгийг бодит цаг хугацаанд нь үздэг хэд хэдэн редактор, редакторууд байдаг. Тэд бүх үйл явдлыг бий болгодог: хэн нэгэн улаан хуудаснаас хөөгдсөн, хэн нэгэн гэмтсэн, ямар нэгэн төрлийн сэлгээ ...
CMS ашиглан өгөгдөл мэдээллийн санд ордог. Үүний дараа мэдээллийн сан нь Сонсох/Мэдэгдэх механизмыг ашиглан API серверүүдэд энэ тухай мэдэгдэнэ. API серверүүд энэ мэдээллийг аль хэдийн үйлчлүүлэгч рүү илгээдэг. Тиймээс бид үндсэндээ мэдээллийн санд холбогдсон цөөхөн хэдэн сервертэй бөгөөд мэдээллийн санд тусгай ачаалал байхгүй, учир нь үйлчлүүлэгч мэдээллийн сантай ямар ч байдлаар шууд харьцдаггүй.
PostgreSQL: Сонсох/Мэдэгдэх
Postgres дахь Сонсох/Мэдэгдэх механизм нь зарим үйл явдал өөрчлөгдсөнийг үйл явдлын захиалагчдад мэдэгдэх боломжийг олгодог - мэдээллийн санд зарим бичлэг бий болсон. Үүнийг хийхийн тулд бид энгийн триггер ба функцийг бичсэн:
Бичлэг оруулах эсвэл өөрчлөхдөө бид data_updates суваг дээрх мэдэгдлийн функцийг дуудаж, хүснэгтийн нэр болон өөрчлөгдсөн эсвэл оруулсан бичлэгийн танигчийг дамжуулдаг.
Үйлчлүүлэгчтэй синхрончлох ёстой бүх хүснэгтийн хувьд бид триггерийг тодорхойлдог бөгөөд бичлэгийг өөрчилсний дараа / шинэчлэсний дараа доорх слайд дээр заасан функцийг дууддаг.
API эдгээр өөрчлөлтийг хэрхэн хүлээж авдаг вэ?
Fanout механизм бий болсон - энэ нь үйлчлүүлэгч рүү мессеж илгээдэг. Энэ нь бүх хэрэглэгчийн сувгийг цуглуулж, эдгээр сувгуудаар дамжуулан хүлээн авсан шинэчлэлтүүдийг илгээдэг:
Энд өгөгдлийн санд холбогдож, сувгийг сонсохыг хүсч байгаа (data_updates) гэсэн стандарт pq номын сан нь холболт нээлттэй, бүх зүйл хэвийн байгаа эсэхийг шалгадаг. Би зай хэмнэхийн тулд алдаа шалгахыг орхиж байна (шалгахгүй байх нь аюултай).
Дараа нь бид 15 секунд тутамд ping илгээх Ticker-ийг асинхроноор тохируулж, бидний захиалсан сувгийг сонсож эхэлнэ. Хэрэв бид пинг хүлээн авбал бид энэ пингийг нийтэлдэг. Хэрэв бид ямар нэгэн төрлийн бичлэг хүлээн авбал бид энэ оруулгыг энэ Fanout-ийн бүх захиалагчдад нийтлэх болно.
Fan-out хэрхэн ажилладаг вэ?
Орос хэлээр үүнийг "хуваагч" гэж орчуулдаг. Бидэнд зарим шинэчлэлтийг хүлээн авахыг хүссэн захиалагчдыг бүртгэдэг нэг объект бий. Энэ объектод шинэчлэлт ирэнгүүт энэ шинэчлэлтийг бүх захиалагчиддаа түгээдэг. Хангалттай энгийн:
Үүнийг Go-д хэрхэн хэрэгжүүлдэг вэ:
Мутекс ашиглан синхрончлогдсон бүтэц байдаг. Энэ нь Fanout-ийн мэдээллийн санд холбогдсон төлөвийг хадгалах талбартай, өөрөөр хэлбэл одоо сонсож байгаа бөгөөд шинэчлэлтүүдийг хүлээн авах болно, мөн боломжтой бүх сувгийн жагсаалт - газрын зураг, гол нь суваг, бүтэц хэлбэртэй байна. үнэ цэнэ (үндсэндээ үүнийг ямар ч байдлаар ашигладаггүй).
Холбогдсон ба салгасан гэсэн хоёр арга нь Fanout-д бид суурьтай холбогдсон, энэ нь гарч ирсэн, суурьтай холболт тасарсан гэдгийг хэлэх боломжийг олгодог. Хоёрдахь тохиолдолд та бүх үйлчлүүлэгчдийг салгаж, тэд цаашид юу ч сонсох боломжгүй, тэдэнтэй холбогдох холболт хаагдсан тул дахин холбогдох болно гэдгийг хэлэх хэрэгтэй.
Мөн "сонсогчид" руу сувгийг нэмдэг Subscribe арга байдаг:
Үйлчлүүлэгч тасарсан тохиолдолд сонсогчдоос сувгийг устгадаг Бүртгэлээс хасах арга, мөн нийт захиалагчдад мессеж илгээх боломжийг олгодог Publish арга байдаг.
Асуулт: – Энэ сувгаар юу дамждаг вэ?
MS: – Өөрчлөгдсөн загвар эсвэл ping дамжуулагдсан (үндсэндээ зүгээр л тоо, бүхэл тоо).
MS: – Та юу ч илгээж, дурын бүтцийг илгээж, нийтэлж болно – энэ нь зүгээр л JSON болж хувирдаг, тэгээд л болоо.
MS: - Бид Postgres-ээс мэдэгдэл хүлээн авдаг - энэ нь хүснэгтийн нэр болон танигчийг агуулдаг. Хүснэгтийн нэр, танигч дээр үндэслэн бид шаардлагатай бичлэгийг аваад дараа нь энэ бүтцийг хэвлүүлэхээр илгээдэг.
Дэд бүтэц
Энэ нь дэд бүтцийн үүднээс ямар харагдаж байна вэ? Бидэнд 7 техник хангамжийн сервер бий: тэдгээрийн нэг нь мэдээллийн санд бүрэн зориулагдсан, үлдсэн зургаан нь виртуал машин ажиллуулдаг. API-ийн 6 хуулбар байдаг: API бүхий виртуал машин бүр тусдаа тоног төхөөрөмжийн сервер дээр ажилладаг - энэ нь найдвартай байдлын үүднээс юм.
Хүртээмжийг сайжруулах үүднээс бидэнд Keepalived суулгасан хоёр урд хэсэг байгаа бөгөөд ингэснээр ямар нэг зүйл тохиолдвол нэг урд тал нь нөгөөгөө сольж болно. Мөн - CMS-ийн хоёр хувь.
Мөн статистик импортлогч бий. Үе үе нөөцлөлт хийдэг DB Slave байдаг. Pigeon Pusher, үйлчлүүлэгчдэд мэдэгдэл илгээдэг програм, түүнчлэн дэд бүтцийн зүйлс байдаг: Zabbix, Graylog2, Chef.
Үнэн хэрэгтээ энэ дэд бүтэц нь илүүдэлтэй, учир нь 100 мянгад цөөн серверээр үйлчлэх боломжтой. Гэхдээ төмөр байсан - бид үүнийг ашигласан (бидэнд боломжтой гэж хэлсэн - яагаад болохгүй гэж).
Go-ийн давуу тал
Биднийг энэ программ дээр ажилласны дараа Go-ийн ийм тодорхой давуу талууд гарч ирсэн.
- Сайхан http номын сан. Үүний тусламжтайгаар та хайрцгаас маш их зүйлийг бий болгож чадна.
- Нэмж дурдахад сувгууд нь үйлчлүүлэгчдэд мэдэгдэл илгээх механизмыг хялбархан хэрэгжүүлэх боломжийг бидэнд олгосон.
- Тэмцээний детектор нь бидэнд хэд хэдэн чухал алдааг арилгах боломжийг олгосон гайхалтай зүйл (үе шатлалын дэд бүтэц). Тайзан дээр ажилладаг бүх зүйлийг Race товчлуураар эмхэтгэн ажиллуулдаг; Үүний дагуу бид ямар асуудал тулгарч болзошгүйг харахын тулд үе шатны дэд бүтцийг харж болно.
- Хэлний минимализм ба энгийн байдал.
Бид хөгжүүлэгч хайж байна! Хэрэв хэн нэгэн хүсвэл гуйя.
Асуултууд
Үзэгчдийн асуулт (цаашид – Б): – Та Fan-out-тай холбоотой нэг чухал зүйлийг алдсан бололтой. Үйлчлүүлэгч рүү хариу илгээхдээ үйлчлүүлэгч уншихыг хүсэхгүй байвал блоклодог гэдгийг би зөв ойлгож байна уу?
MS: -Үгүй ээ, бид хориглоогүй. Нэгдүгээрт, бид nginx-ийн ард энэ бүхэн байгаа, өөрөөр хэлбэл удаан үйлчлүүлэгчидтэй холбоотой асуудал байхгүй. Хоёрдугаарт, үйлчлүүлэгч нь буфер бүхий сувагтай байдаг - үнэндээ бид тэнд зуу хүртэл шинэчлэлт хийх боломжтой ... Хэрэв бид суваг руу бичиж чадахгүй бол тэр үүнийг устгадаг. Хэрэв бид суваг хаагдсаныг харвал бид зүгээр л сувгийг хаах болно, тэгээд л болоо - ямар нэгэн асуудал гарвал үйлчлүүлэгч дахин холбогдох болно. Тиймээс зарчмын хувьд энд ямар ч хориг байхгүй.
Дотор нь: – Тодорхойлогч хүснэгт биш харин Сонсох/Мэдэгдэл рүү шууд бичлэг илгээх боломжгүй байсан уу?
MS: – Сонсох/Мэдэгдэл илгээх нь урьдчилан ачаалахдаа 8 мянган байт хязгаартай. Зарчмын хувьд, хэрэв бид бага хэмжээний өгөгдөлтэй харьцаж байсан бол илгээх боломжтой байсан ч энэ арга нь [бидний үүнийг хийх арга] илүү найдвартай юм шиг санагдаж байна. Хязгаарлалтууд нь Postgres-д байдаг.
Дотор нь: – Үйлчлүүлэгчид сонирхдоггүй тоглолтын талаар мэдээлэл авдаг уу?
MS: -Ерөнхийдөө тийм. Дүрмээр бол 2-3 тоглолт зэрэгцэн явагддаг, тэр ч байтугай маш ховор байдаг. Үйлчлүүлэгч ямар нэг зүйл үзэж байгаа бол ихэвчлэн болж буй тоглолтыг үзэж байна. Дараа нь үйлчлүүлэгч эдгээр бүх шинэчлэлтүүдийг багтаасан локал мэдээллийн сантай бөгөөд интернет холболтгүй байсан ч үйлчлүүлэгч өөрийн шинэчлэлттэй байсан өмнөх бүх тоглолтыг үзэх боломжтой. Үндсэндээ бид сервер дээрх мэдээллийн баазыг үйлчлүүлэгчийн дотоод мэдээллийн сантай синхрончилдог бөгөөд ингэснээр тэр офлайн ажиллах боломжтой болно.
Дотор нь: – Та яагаад өөрөө ORM хийсэн бэ?
Алексей (Look+ програмыг хөгжүүлэгчдийн нэг): – Тухайн үед (нэг жилийн өмнө байсан) одоогийнхоос нэлээд олон ОРМ-ууд цөөн байсан. Ихэнх ORM-ийн хамгийн дуртай зүйл бол ихэнх нь хоосон интерфейс дээр ажилладаг. Өөрөөр хэлбэл, эдгээр ORM-ийн аргууд нь бүтэц, бүтцийн заагч, тоо, огт хамааралгүй зүйл гэх мэт юу ч хийхэд бэлэн байдаг.
Манай ORM нь өгөгдлийн загварт суурилсан бүтцийг бий болгодог. Би өөрөө. Тиймээс бүх аргууд нь бетонон, тусгалыг ашигладаггүй гэх мэт. Тэд бүтцийг хүлээн зөвшөөрч, ирэх бүтцийг ашиглахыг хүлээж байна.
Дотор нь: -Хэдэн хүн оролцсон бэ?
MS: – Эхний шатанд хоёр хүн оролцсон. Бид зургадугаар сард хаа нэгтээ эхэлсэн бөгөөд наймдугаар сард үндсэн хэсэг бэлэн болсон (эхний хувилбар). Есдүгээр сард нээлтээ хийсэн.
Дотор нь: – Та SSE-ийг тайлбарласан тохиолдолд та хугацаа хэтрүүлдэггүй. Яагаад тэр вэ?
MS: – Үнэнийг хэлэхэд SSE нь html5 протокол хэвээр байна: SSE стандарт нь миний ойлгож байгаагаар хөтчүүдтэй харилцах зориулалттай. Энэ нь хөтчүүдийг дахин холбох боломжтой (гэх мэт) нэмэлт функцуудтай боловч бидэнд холбогдох, мэдээлэл хүлээн авах логикийг хэрэгжүүлэх боломжтой үйлчлүүлэгчид байсан тул бидэнд хэрэггүй. Бид SSE биш, харин SSE-тэй төстэй зүйл хийсэн. Энэ нь өөрөө протокол биш юм.
Шаардлагагүй байсан. Миний ойлгож байгаагаар үйлчлүүлэгчид холболтын механизмыг бараг эхнээс нь хэрэгжүүлсэн. Тэд үнэхээр санаа зовсонгүй.
Дотор нь: – Та ямар нэмэлт хэрэгсэл ашигласан бэ?
MS: – Бид гофмт шиг хэв маягийг нэгдмэл болгохын тулд govet, golint-ийг хамгийн идэвхтэй ашигласан. Өөр юу ч ашиглаагүй.
Дотор нь: - Та дибаг хийхэд юу ашигласан бэ?
MS: – Дибаг хийх ажлыг ихэвчлэн тест ашиглан хийсэн. Бид дибаг хийгч эсвэл GOP ашиглаагүй.
Дотор нь: – Publish функц хэрэгжсэн слайдыг буцаах уу? Нэг үсэгтэй хувьсагчийн нэр таныг төөрөлдүүлж байна уу?
MS: - Үгүй. Тэдэнд харагдахуйц "нарийн" хүрээ байдаг. Тэдгээрийг эндээс өөр хаана ч ашигладаггүй (энэ ангийн дотоод хэсгүүдээс бусад) бөгөөд энэ нь маш авсаархан байдаг - энэ нь зөвхөн 7 мөрийг авдаг.
Дотор нь: -Ямар нэгэн байдлаар энэ нь мэдрэмжгүй хэвээр байна ...
MS: - Үгүй, үгүй, энэ бол жинхэнэ код! Энэ нь хэв маягийн тухай биш юм. Энэ бол үнэхээр ашигтай, маш жижиг анги юм - анги дотор ердөө 3 талбар ...
MS: – Ерөнхийдөө үйлчлүүлэгчидтэй синхрончлогдсон бүх өгөгдөл (улирлын тоглолт, тоглогчид) өөрчлөгддөггүй. Ойролцоогоор хэлэхэд, хэрэв бид тоглолтыг өөрчлөх шаардлагатай өөр спортыг хийвэл бид үйлчлүүлэгчийн шинэ хувилбарт бүх зүйлийг харгалзан үзэх бөгөөд үйлчлүүлэгчийн хуучин хувилбаруудыг хориглох болно.
Дотор нь: – Гуравдагч этгээдийн хараат байдлын менежментийн багц байдаг уу?
MS: – Бид go dep ашигладаг байсан.
Дотор нь: – Илтгэлийн сэдэвт видео бичлэгийн талаар ямар нэгэн зүйл байсан ч тайланд видеоны талаар юу ч байгаагүй.
MS: - Үгүй ээ, надад видеоны сэдэвт юу ч байхгүй. Үүнийг "Харах+" гэж нэрлэдэг - энэ нь програмын нэр юм.
Дотор нь: – Үйлчлүүлэгчид рүү дамжуулдаг гэж та хэллээ?..
MS: – Бид видеог цацахад оролцоогүй. Үүнийг бүхэлд нь Мегафон хийсэн. Тийм ээ, би энэ програмыг MegaFon гэж хэлээгүй.
MS: – Go – бүх өгөгдлийг илгээхэд зориулагдсан – оноо, тоглолтын үйл явдал, статистик... Go нь програмын бүхэл бүтэн backend юм. Үйлчлүүлэгч нь тоглогчийн аль холбоосыг ашиглахаа хаанаас ч мэдэж байх ёстой бөгөөд ингэснээр хэрэглэгч тоглолтыг үзэх боломжтой болно. Бидэнд бэлтгэсэн видео, дамжуулалтын холбоосууд байна.
Зарим зар 🙂
Бидэнтэй хамт байсанд баярлалаа. Манай нийтлэл танд таалагдаж байна уу? Илүү сонирхолтой контент үзэхийг хүсч байна уу? Захиалга өгөх эсвэл найзууддаа санал болгох замаар биднийг дэмжээрэй, , Бидний танд зориулж бүтээсэн анхны түвшний серверүүдийн өвөрмөц аналоги: (RAID1 болон RAID10, 24 хүртэлх цөм, 40 ГБ хүртэл DDR4-тэй байх боломжтой).
Амстердам дахь Equinix Tier IV дата төвд Dell R730xd 2 дахин хямд байна уу? Зөвхөн энд Нидерландад! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 доллараас! тухай уншина уу
Эх сурвалж: www.habr.com