Михаил Салосин (цаашид МС гэх): Бүгдээрээ сайн уу! Намайг Михаил гэдэг. Би MC2 Software-ийн backend хөгжүүлэгч бөгөөд "Smotri+" гар утасны програмын арын хэсэгт 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: Сонсох/Мэдэгдэх
PostgreSQL-ийн Сонсох/Мэдэгдэх механизм нь үйл явдал өөрчлөгдсөн буюу мэдээллийн сангийн бүртгэл үүсгэсэн үед үйл явдлын захиалагчдад мэдэгдэх боломжийг олгодог. Үүнийг хийхийн тулд бид энгийн триггер ба функцийг бичсэн:
Бичлэг оруулах эсвэл өөрчлөх үед бид data_updates суваг дээрх мэдэгдлийн функцийг дуудаж, хүснэгтийн нэр болон өөрчлөгдсөн эсвэл оруулсан бичлэгийн ID-г дамжуулдаг.
Үйлчлүүлэгчтэй синхрончлох шаардлагатай бүх хүснэгтийн хувьд бид бичлэгийг өөрчилсний/шинэчилсэний дараа доорх слайдад заасан функцийг дууддаг триггерийг тодорхойлдог.
API эдгээр өөрчлөлтийг хэрхэн хүлээж авдаг вэ?
Fanout механизм бий болсон - энэ нь үйлчлүүлэгчдэд мессеж илгээдэг. Энэ нь үйлчлүүлэгчийн бүх сувгийг цуглуулж, эдгээр сувгуудаар дамжуулан хүлээн авсан шинэчлэлтүүдийг илгээдэг:
Мэдээллийн сантай холбогдож, сувгийг сонсохыг хүсч буйгаа (data_updates) зааж, холболт нээлттэй, бүх зүйл хэвийн байгаа эсэхийг шалгадаг стандарт pq номын сан энд байна. Би зай хэмнэхийн тулд алдаа шалгахыг орхиж байна (шалгахгүй байх нь аюултай).
Дараа нь бид 15 секунд тутамд пинг илгээж, бидний захиалсан сувгийг сонсож эхлэх Тикерийг асинхроноор тохируулсан. Хэрэв бид пинг хүлээн авбал бид үүнийг нийтэлдэг. Хэрэв бид бичлэг хүлээн авбал энэ Fanout-ийн бүх захиалагчдад нийтлэх болно.
Fan-out хэрхэн ажилладаг вэ?
Орос хэлээр үүнийг "хуваагч" гэж орчуулдаг. Бидэнд тодорхой шинэчлэлтүүдийг хүлээн авахыг хүссэн захиалагчдыг бүртгэдэг нэг объект бий. Энэ объект дээр шинэчлэлт ирэнгүүт үүнийг бүх захиалагчдад түгээдэг. Энэ нь маш энгийн:
Үүнийг Go-д хэрхэн хэрэгжүүлдэг вэ:
Mutexes ашиглан синхрончлогдсон бүтэц бий. Энэ нь Fanout-ийн өгөгдлийн сантай холболтыг хадгалах талбартай, өөрөөр хэлбэл одоо сонсож байгаа бөгөөд шинэчлэлтүүдийг хүлээн авах болно, мөн боломжтой бүх сувгуудын жагсаалт - гол нь суваг болох газрын зураг, утгыг агуулсан бүтэц (үнэндээ ашиглагдаагүй).
Холбогдсон ба салгасан гэсэн хоёр арга нь бидэнд мэдээллийн сантай холбогдсон, энэ нь тогтоогдсон, мэдээллийн сантай холболт тасарсан гэдгийг Fanout-д хэлэх боломжийг олгодог. Хоёрдахь тохиолдолд бид бүх үйлчлүүлэгчдийг салгаж, тэд цаашид юу ч сонсох боломжгүй, тэдэнтэй холбогдох холбоо тасарсан тул дахин холбогдох хэрэгтэй гэдгийг мэдэгдэх шаардлагатай.
Мөн "сонсогчид" руу суваг нэмдэг Subscribe арга байдаг:
Үйлчлүүлэгч тасарсан тохиолдолд сувгийг сонсох жагсаалтаас хасдаг Бүртгэлээс хасах арга, нийт захиалагчдад мессеж илгээх боломжийг олгодог Publish арга байдаг.
Асуулт: – Энэ сувгаар юу дамждаг вэ?
MS: – Өөрчлөгдсөн загвар эсвэл пинг (үндсэндээ зүгээр л тоо, бүхэл тоо) дамжуулагдана.
MS: – Та юу ч, ямар ч бүтцийг илгээх, нийтлэх боломжтой – энэ нь зүгээр л JSON болж хувирдаг, тэгээд л болоо.
MS: Бид PostgreSQL-ээс мэдэгдэл хүлээн авдаг бөгөөд энэ нь хүснэгтийн нэр болон танигчийг агуулдаг. Хүснэгтийн нэр болон танигчийг ашиглан бид шаардлагатай бичлэгийг олж аваад дараа нь энэ бүтцийг хэвлүүлэхээр илгээдэг.
Дэд бүтэц
Энэ нь дэд бүтцийн үүднээс ямар харагдаж байна вэ? Бид долоон техник хангамжийн сервертэй: нэг нь бүхэлдээ мэдээллийн санд зориулагдсан, нөгөө зургаан нь виртуал машин ажиллуулдаг. API-ийн зургаан тохиолдол байдаг: API-г ажиллуулж буй виртуал машин бүр найдвартай байх үүднээс тусдаа техник хангамжийн сервер дээр ажилладаг.
Хүртээмжтэй байлгах үүднээс бид Keepalived-г ажиллуулж байгаа хоёр урд талбартай тул шаардлагатай бол нэг урд талын хэсгийг нөгөөг нь сольж болно. Бидэнд бас CMS-ийн хоёр хувь бий.
Статистик импортлогч бас бий. Мэдээллийг үе үе нөөцлөх DB Slave байдаг. Pigeon Pusher, үйлчлүүлэгчдэд мэдэгдэл илгээдэг програм, мөн дэд бүтцийн бүрэлдэхүүн хэсгүүд байдаг: Zabbix, Graylog2, Chef.
Бодит байдал дээр 100 хэрэглэгчдэд цөөн серверээр үйлчлэх боломжтой учраас энэ дэд бүтэц нь шаардлагагүй юм. Гэхдээ бидэнд техник хангамж байсан - бид үүнийг ашигласан (бидэнд үүнийг боломжтой гэж хэлсэн - яагаад болохгүй гэж).
Go-ийн давуу тал
Энэхүү программ дээр ажилласны дараа Go програмын дараах давуу талууд тодорхой болсон.
- Сайхан HTTP номын сан. Энэ нь танд хайрцагнаас маш их зүйлийг бий болгох боломжийг олгодог.
- Нэмж дурдахад сувгууд нь үйлчлүүлэгчдэд мэдэгдэл илгээх механизмыг хялбархан хэрэгжүүлэх боломжийг бидэнд олгосон.
- Тэмцээний илрүүлэгч нь хэд хэдэн чухал алдааг (үе шатлалын дэд бүтэц) арилгах боломжийг бидэнд олгосон гайхалтай функц юм. Тайлбар дээр ажиллаж байгаа бүх зүйл ажиллаж байгаа бөгөөд Race товчлуураар эмхэтгэсэн; Иймээс бид ямар боломжит асуудлууд гарч болзошгүйг харахын тулд үе шатны дэд бүтцийг ашиглаж болно.
- Хэлний минимализм ба энгийн байдал.
Бид хөгжүүлэгч хайж байна! Сонирхсон хүн байвал бидэнтэй нэгдээрэй.
Асуултууд
Үзэгчдийн асуулт (цаашид Асуулт гэх): – Та Fan-out-тай холбоотой нэг чухал зүйлийг алдсан гэж бодож байна. Үйлчлүүлэгч рүү хариу илгээхдээ уншихыг хүсэхгүй байвал блоклодог гэдгийг би зөв ойлгож байна уу?
MS: "Үгүй ээ, бид блоклогддоггүй. Нэгдүгээрт, бидэнд Nginx-ийн ард бүх зүйл байгаа тул удаан үйлчлүүлэгчидтэй холбоотой асуудал байхгүй. Хоёрдугаарт, үйлчлүүлэгч нь буфертэй сувагтай байдаг - бид тэнд үндсэндээ зуу хүртэлх шинэчлэлтийг хадгалах боломжтой ... Хэрэв бид суваг руу бичиж чадахгүй бол энэ нь устгадаг. Хэрэв суваг хаагдсаныг харвал бид зүгээр л сувгийг хааж, ямар нэгэн асуудал гарах болно. Энд ямар ч саад байхгүй."
Дотор нь: – Тодорхойлогч хүснэгтийн оронд Сонсох/Мэдэгдэл рүү шууд бичлэг илгээх боломжгүй байсан уу?
MS: – Сонсох/Мэдэгдэл илгээх нь урьдчилан ачаалах бүрт 8 байт хязгаартай. Зарчмын хувьд, хэрэв бид бага хэмжээний өгөгдөлтэй харьцаж байсан бол үүнийг илгээх боломжтой байсан ч энэ нь илүү найдвартай гэж би бодож байна. Хязгаарлалтууд нь PostgreSQL-д байдаг.
Дотор нь: – Үйлчлүүлэгчид сонирхдоггүй тоглолтын талаар мэдээлэл авдаг уу?
MS: -Ерөнхийдөө тийм. Ерөнхийдөө хоёр, гурван тэмцээн зэрэг явагддаг бөгөөд тэр ч байтугай энэ нь маш ховор байдаг. Үйлчлүүлэгч ямар нэг зүйл үзэж байгаа бол тэд ихэвчлэн яг одоо тоглож байгаа тоглолтыг үздэг. Дараа нь үйлчлүүлэгч нь эдгээр бүх шинэчлэлтүүдийг хадгалдаг локал мэдээллийн сантай бөгөөд интернет холболтгүй байсан ч шинэчлэгдсэн өмнөх бүх тоглолтыг үзэх боломжтой. Үндсэндээ бид сервер дээрх мэдээллийн баазыг үйлчлүүлэгчийн дотоод мэдээллийн сантай синхрончилдог тул офлайнаар ажиллах боломжтой.
Дотор нь: – Та яагаад өөрийн ORM-ээ үүсгэсэн бэ?
Алексей ("Smotri+" хөгжүүлэгчдийн нэг): – Тухайн үед (энэ нь жилийн өмнө байсан) нэлээн цөөн байсан одоогийнхоос цөөн тооны ORM байсан. Одоо байгаа бүх ORM-уудаас надад хамгийн дургүй зүйл бол ихэнх нь хоосон интерфейс дээр ажилладаг явдал юм. Өөрөөр хэлбэл, эдгээр ORM-ийн аргууд нь бүтэц, бүтцийн заагч, тоо, огт хамааралгүй бүх зүйлийг хүлээн авахад бэлэн байдаг.
Манай ORM нь өгөгдлийн загварт тулгуурлан бүтцийг бий болгодог. Тиймээс бүх аргууд нь бетонон, тусгал ашигладаггүй гэх мэт. Тэд бүтээцийг хүлээн зөвшөөрч, өгсөн бүтцийг ашиглахыг хүлээж байна.
Дотор нь: -Хэдэн хүн оролцсон бэ?
MS: – Эхний шатанд хоёр хүн хамрагдсан. Бид зургадугаар сард эхэлсэн бөгөөд үндсэн хэсэг (эхний хувилбар) наймдугаар сар гэхэд бэлэн болсон. 9-р сард гарсан.
Дотор нь: – Та SSE гэж тайлбарлавал завсарлага хэрэглэдэггүй. Яагаад тэр вэ?
MS: "Үнэнийг хэлэхэд, SSE нь HTML5 протокол хэвээр байна: SSE стандарт нь миний ойлгож байгаагаар хөтөчтэй харилцахад зориулагдсан. Энэ нь хөтчүүдийг дахин холбох боломжийг олгодог нэмэлт функцуудтай (гэх мэт), гэхдээ бидэнд ямар ч холболт, мэдээлэл хайх логикийг хэрэгжүүлж чадах үйлчлүүлэгчид байсан тул бидэнд хэрэггүй байсан. Бид SSE-г үүсгээгүй, харин SSE-тэй төстэй зүйл биш юм."
Шаардлагагүй байсан. Миний ойлгож байгаагаар үйлчлүүлэгчид холболтын механизмыг бараг эхнээс нь хэрэгжүүлсэн. Тэд үндсэндээ хамаагүй байсан.
Дотор нь: – Та ямар нэмэлт хэрэгсэл ашигласан бэ?
MS: – Бид гофмт гэх мэт тууштай хэв маягийг хадгалахын тулд govet болон golint-ийг хамгийн өргөнөөр ашигласан. Бид өөр зүйл ашиглаагүй.
Дотор нь: - Та үүнийг дибаг хийхдээ юу ашигласан бэ?
MS: – Дибаг хийх ажлыг ихэвчлэн туршилтаар хийсэн. Бид дибаг хийгч эсвэл GOP ашиглаагүй.
Дотор нь: – Publish функц хэрэгжсэн слайдыг буцаах уу? Нэг үсэгтэй хувьсагчийн нэрс будлиантай байна уу?
MS: "Үгүй. Тэдгээр нь нэлээд нарийхан хүрээтэй. Эндээс өөр хаана ч ашигладаггүй (энэ ангийн дотоод хэсгүүдээс бусад), маш авсаархан—энэ нь ердөө 7 мөр л авдаг."
Дотор нь: -Ямар нэгэн байдлаар энэ нь зөн совингийн мэдрэмжгүй хэвээр байна ...
MS: "Үгүй, үгүй, энэ бол жинхэнэ код! Энэ бол хэв маягийн асуудал биш. Энэ бол зүгээр л маш ашигтай, маш жижиг анги юм - анги доторх ердөө гурван талбар..."
MS: – Ерөнхийдөө үйлчлүүлэгчидтэй синк хийсэн бүх өгөгдөл (улирлын тоглолт, тоглогчид) өөрчлөгдөөгүй хэвээр байна. Товчоор хэлбэл, хэрэв бид тоглолтын өөрчлөлтийг шаарддаг өөр спортыг хөгжүүлэх юм бол бид үйлчлүүлэгчийн шинэ хувилбарт бүх зүйлийг анхаарч үзэх бөгөөд хуучин хувилбаруудыг хориглох болно.
Дотор нь: – Хамааралтай байдлын менежментийн гуравдагч этгээдийн багц байдаг уу?
MS: – Бид go dep ашигладаг байсан.
Дотор нь: - Илтгэлийн сэдэв нь видеоны талаар ямар нэг зүйлийг дурдсан боловч тайланд видео дурдаагүй.
MS: "Үгүй ээ, миний хэлхээс дотор видеоны талаар юу ч байхгүй. Үүнийг "Watch+" гэж нэрлэдэг—энэ бол програмын нэр."
Дотор нь: - Та үйлчлүүлэгчид рүү дамжуулдаг гэж хэлсэн үү?
MS: "Бид видео цацалтад оролцоогүй. Үүнийг бүхэлд нь Мегафон хариуцаж байсан. Тийм ээ, би энэ програмыг Megafon-ынх гэж хэлээгүй."
MS: – Go – бүх өгөгдөл – оноо, тоглолтын үйл явдал, статистик зэргийг илгээх зориулалттай... Go нь програмын бүхэл бүтэн арын хэсэг юм. Үйлчлүүлэгч нь тоглогчийн аль холбоосыг ашиглахыг хаанаас ч мэдэж байх ёстой бөгөөд ингэснээр хэрэглэгч тоглолтыг үзэх боломжтой болно. Бидэнд аль хэдийн бэлтгэгдсэн видео болон дамжуулалтын холбоосууд байна.
Зарим зар 🙂
Бидэнтэй хамт байсанд баярлалаа. Манай нийтлэл танд таалагдаж байна уу? Илүү сонирхолтой контент үзэхийг хүсч байна уу? Захиалга өгөх эсвэл найзууддаа санал болгох замаар биднийг дэмжээрэй, , Бидний танд зориулж бүтээсэн анхны түвшний серверүүдийн өвөрмөц аналоги: (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
