میخایل سالوسین (له دې وروسته - MS): - سلام و ټولو ته! زما نوم مایکل دی. زه په MC2 سافټویر کې د بیک انډ پراختیا کونکي په توګه کار کوم ، او زه به د لید + ګرځنده غوښتنلیک په شاته کې د Go کارولو په اړه وغږیږم.
ایا دلته څوک هاکي خوښوي؟
بیا دا غوښتنلیک ستاسو لپاره دی. دا د Android او iOS لپاره دی او د آنلاین او ثبت شوي مختلف سپورت پیښو خپرونو لیدو لپاره کارول کیږي. په غوښتنلیک کې مختلف احصایې، د متن خپرونې، د کنفرانسونو میزونه، ټورنمنټونه او نور معلومات هم شامل دي چې د مینه والو لپاره ګټور دي.
همدارنګه په غوښتنلیک کې د ویډیو شیانو په څیر یو شی شتون لري، د بیلګې په توګه تاسو کولی شئ د سیالیو خورا مهم شیبې وګورئ (هدفونه، جګړې، ډزې، او نور). که تاسو نه غواړئ ټوله خپرونه وګورئ، تاسو کولی شئ یوازې خورا په زړه پورې خپرونې وګورئ.
تاسو په پرمختیا کې څه کارولي؟
اصلي برخه په Go کې لیکل شوې وه. هغه API چې ګرځنده پیرودونکي ورسره اړیکه لري په Go کې لیکل شوي. ګرځنده تلیفونونو ته د پش خبرتیاو لیږلو خدمت هم په ګو کې لیکل شوی و. موږ باید خپل ORM هم ولیکو، کوم چې موږ ممکن یوه ورځ په اړه خبرې وکړو. ښه، ځینې کوچني خدمتونه په Go کې لیکل شوي: د ایډیټورانو لپاره د عکسونو اندازه کول او پورته کول ...
موږ PostgreSQL د ډیټابیس په توګه کاروو. د ایډیټر انٹرفیس د ActiveAdmin ګیم په کارولو سره په ریلونو روبي کې لیکل شوی و. د احصایې چمتو کونکي څخه د احصایې واردول هم په روبي کې لیکل شوي.
د سیسټم API ازموینې لپاره، موږ د Python Unitest کاروو. Memcached د API تادیې زنګ وهلو لپاره کارول کیږي، "شیف" د ترتیب کولو کنټرول لپاره کارول کیږي، Zabbix د داخلي سیسټم احصایې راټولولو او څارلو لپاره کارول کیږي. ګریلوګ 2 د لاګونو راټولولو لپاره دی ، سلیټ د پیرودونکو لپاره د API سند دی.
د پروتوکول انتخاب
لومړۍ ستونزه چې موږ ورسره مخ شو: موږ اړتیا لرو چې د لاندې ټکو پراساس د بیک اینڈ او ګرځنده پیرودونکو ترمینځ متقابل عمل لپاره پروتوکول غوره کړو ...
- ترټولو مهمه اړتیا: د پیرودونکو معلومات باید په ریښتیني وخت کې تازه شي. دا دی، هرڅوک چې اوس مهال خپرونې ګوري باید نږدې سمدستي تازه معلومات ترلاسه کړي.
- د شیانو ساده کولو لپاره، موږ داسې انګیرل چې هغه معلومات چې د مراجعینو سره همغږي شوي نه دي حذف شوي، مګر د ځانګړو بیرغونو په کارولو سره پټ شوي.
- ټول ډوله نادره غوښتنې (لکه احصایې، د ټیم جوړښت، د ټیم احصایې) د عادي GET غوښتنو لخوا ترلاسه کیږي.
- برسېره پردې، سیسټم باید په ورته وخت کې د 100 زرو کاروونکو ملاتړ وکړي.
د دې پر بنسټ، موږ دوه پروتوکول اختیارونه درلودل:
- ویب ساکټونه. مګر موږ د پیرودونکي څخه سرور ته چینلونو ته اړتیا نه درلوده. موږ یوازې اړتیا درلوده چې له سرور څخه پیرودونکي ته تازه معلومات واستوو، نو د ویب ساکټ یو بې ځایه انتخاب دی.
- د سرور لیږل شوي پیښې (SSE) په سمه توګه راپورته شوي! دا خورا ساده دی او اساسا هرڅه چې موږ ورته اړتیا لرو پوره کوي.
د سرور لخوا لیږل شوي پیښې
د دې کار د څرنګوالي په اړه یو څو خبرې ...
دا د http پیوستون په سر کې پرمخ ځي. پیرودونکي غوښتنه لیږي ، سرور د مینځپانګې ډول سره ځواب ورکوي: متن / پیښې جریان او د پیرودونکي سره اړیکه نه بندوي ، مګر اړیکې ته د معلوماتو لیکلو ته دوام ورکوي:
معلومات په هغه شکل کې لیږل کیدی شي چې د پیرودونکو سره موافقه شوې وي. زموږ په قضیه کې، موږ دا په دې بڼه لیږلی: د بدل شوي جوړښت نوم (شخص، لوبغاړی) د پیښې ساحې ته لیږل شوی و، او JSON د نوي، بدل شوي ساحې سره د لوبغاړي لپاره د معلوماتو ساحې ته لیږل شوی و.
اوس راځئ چې په دې اړه وغږیږو چې متقابل عمل پخپله څنګه کار کوي.
- لومړی شی چې پیرودونکي یې کوي د وروستي ځل لپاره د خدمت سره همغږي کول مشخص کوي: دا خپل محلي ډیټابیس ګوري او د وروستي بدلون نیټه ټاکي چې د هغې لخوا ثبت شوي.
- دا د دې نیټې سره غوښتنه لیږي.
- په ځواب کې، موږ هغه ټول تازه معلومات لیږو چې د دې نیټې راهیسې پیښ شوي.
- له هغې وروسته، دا د ژوندی چینل سره اړیکه نیسي او نه تړل کیږي تر هغه چې دا تازه معلوماتو ته اړتیا ولري:
موږ هغه ته د بدلونونو لیست لیږو: که څوک یو ګول وکړي، موږ د لوبې سکور بدلوو، که هغه ټپي شي، دا هم په ریښتیني وخت کې لیږل کیږي. پدې توګه ، پیرودونکي سمدلاسه د میچ پیښې فیډ کې تازه معلومات ترلاسه کوي. په دوره توګه، د دې لپاره چې پیرودونکي پوه شي چې سرور مړ شوی نه دی، دا هیڅ شی ندی شوی، موږ په هر 15 ثانیو کې یو مهال ویش لیږو - ترڅو پوه شي چې هرڅه سم دي او بیا نښلولو ته اړتیا نشته.
ژوندی اتصال څنګه خدمت کیږي؟
- له هرڅه دمخه ، موږ یو چینل رامینځته کوو چیرې چې بفر شوي تازه معلومات به ترلاسه شي.
- له هغې وروسته، موږ د تازه معلوماتو ترلاسه کولو لپاره دا چینل سبسکرایب کړئ.
- موږ سم سرلیک ترتیب کړ ترڅو پیرودونکي پوه شي چې هرڅه سم دي.
- لومړی پینګ واستوئ. موږ په ساده ډول د اوسني پیوستون مهال ویش ثبت کوو.
- له هغې وروسته، موږ د چینل څخه په لوپ کې لوستلو تر هغه چې د تازه کولو چینل تړل شوی وي. چینل په دوره توګه یا اوسنی مهال ویش ترلاسه کوي یا هغه بدلونونه چې موږ دمخه د اړیکو پرانیستلو لپاره لیکلي یو.
لومړۍ ستونزه چې موږ ورسره مخ شوه لاندې وه: د پیرودونکي سره د هرې اړیکې خلاصولو لپاره ، موږ یو ټایمر رامینځته کړی چې په هرو 15 ثانیو کې یو ځل ټک کوي - دا معلومه شوه چې که موږ د یو ماشین سره 6 زره اړیکې خلاصې وې (د یو API سرور سره) ، 6 زره ټایمرونه جوړ شول. دا د دې لامل شوی چې ماشین اړین بار ونه ساتي. ستونزه موږ ته دومره څرګنده نه وه، مګر موږ لږ مرسته ترلاسه کړه او دا مو حل کړه.
د پایلې په توګه، اوس زموږ پینګ د ورته چینل څخه راځي چې تازه معلومات راځي.
په دې اساس، یوازې یو ټایمر شتون لري چې په هرو 15 ثانیو کې یو ځل ټک کوي.
دلته ډیری مرستندویه دندې شتون لري - د سرلیک لیږل، پینګ او پخپله جوړښت. دا، د میز نوم (شخص، لوبه، فصل) او د دې ننوتلو په اړه معلومات دلته لیږدول کیږي:
د تازه معلوماتو لیږلو میکانیزم
اوس په دې اړه لږ څه بدلونونه له کوم ځای څخه راځي. موږ ډیری خلک لرو، مدیران چې په ریښتیني وخت کې خپرونې ګوري. دوی ټولې پیښې رامینځته کوي: یو څوک لیږل شوی ، څوک ټپي شوی ، یو ډول بدیل ...
د CMS په کارولو سره، ډاټا ډیټابیس ته ننوځي. له دې وروسته، ډیټابیس د اوریدلو / خبرتیا میکانیزم په کارولو سره د API سرورونو ته خبر ورکوي. د API سرورونه دمخه دا معلومات پیرودونکو ته لیږي. پدې توګه ، موږ په لازمي ډول یوازې یو څو سرورونه لرو چې ډیټابیس سره وصل دي او په ډیټابیس کې کوم ځانګړي بار شتون نلري ، ځکه چې پیرودونکي په هیڅ ډول د ډیټابیس سره مستقیم تعامل نه کوي:
PostgreSQL: واورئ / خبر کړئ
په پوسټګریس کې د اوریدلو / خبرتیا میکانیزم تاسو ته اجازه درکوي د پیښې پیرودونکو ته خبر ورکړئ چې ځینې پیښه بدله شوې - ځینې ریکارډ په ډیټابیس کې رامینځته شوی. د دې کولو لپاره، موږ یو ساده محرک او فعالیت لیکلی:
کله چې یو ریکارډ داخل کړئ یا بدل کړئ، موږ د ډیټا_اپډیټس چینل کې د خبرتیا فنکشن ته زنګ وهو، هلته د میز نوم او د ریکارډ پیژندونکی چې بدل شوی یا داخل شوی و.
د ټولو جدولونو لپاره چې باید د پیرودونکي سره همغږي شي ، موږ یو محرک تعریف کوو ، کوم چې د ریکارډ بدلولو / تازه کولو وروسته په لاندې سلایډ کې ښودل شوي فنکشن ته زنګ وهي.
API څنګه د دې بدلونونو ګډون کوي؟
د فینوټ میکانیزم رامینځته شوی - دا پیرودونکي ته پیغامونه لیږي. دا ټول پیرودونکي چینلونه راټولوي او د دې چینلونو له لارې ترلاسه شوي تازه معلومات لیږي:
دلته د معیاري pq کتابتون ، کوم چې ډیټابیس سره وصل دی او وايي چې دا غواړي چینل ته غوږ ونیسي (ډاټا_اپډیټس) ، چیک کوي چې پیوستون خلاص دی او هرڅه سم دي. زه د ځای خوندي کولو لپاره د تیروتنې چک کول پریږدم (نه چک کول خطرناک دي).
بیا ، موږ په غیر متناسب ډول ټیکر تنظیم کوو ، کوم چې به په هر 15 ثانیو کې پینګ واستوي ، او هغه چینل ته غوږ نیول پیل کړي چې موږ یې ګډون کړی. که موږ پینګ ترلاسه کړو، موږ دا پینګ خپروو. که موږ یو ډول داخله ترلاسه کړو، نو موږ دا ننوتل د دې فین آوټ ټولو پیرودونکو ته خپروو.
فین آؤٹ څنګه کار کوي؟
په روسي کې دا د "سپلیټر" په توګه ژباړل کیږي. موږ یو اعتراض لرو چې پیرودونکي راجستر کوي څوک چې غواړي ځینې تازه معلومات ترلاسه کړي. او هرڅومره ژر چې دې اعتراض ته تازه معلومات راشي ، نو دا تازه خپلو ټولو پیرودونکو ته توزیع کوي. کافي ساده:
دا څنګه په Go کې پلي کیږي:
یو جوړښت شتون لري، دا د Mutexes په کارولو سره همغږي کیږي. دا یوه ساحه لري چې ډیټابیس ته د فین آوټ اړیکې حالت خوندي کوي، د بیلګې په توګه دا اوس اوریدل کیږي او تازه معلومات ترلاسه کوي، او همدارنګه د ټولو شته چینلونو لیست - نقشه، چې کلیدي یې د چینل او جوړښت په بڼه دی. ارزښتونه (په اصل کې دا په هیڅ ډول نه کارول کیږي).
دوه میتودونه - نښلول شوي او منحل شوي - موږ ته اجازه راکوي چې Fanout ته ووایو چې موږ د اډې سره اړیکه لرو، دا ښکاره شوې او د اډې سره اړیکه مات شوې. په دویمه قضیه کې، تاسو اړتیا لرئ چې ټول پیرودونکي منحل کړئ او دوی ته ووایاست چې دوی نور هیڅ شی نشي اوریدلی او دا چې دوی بیا نښلوي ځکه چې دوی سره اړیکه تړل شوې ده.
د ګډون کولو میتود هم شتون لري چې چینل "اوریدونکو" ته اضافه کوي:
د ګډون د ختمولو طریقه شتون لري، کوم چې چینل له اوریدونکو څخه لیرې کوي که چیرې پیرودونکي وصل شي، په بیله بیا د خپرولو طریقه، کوم چې تاسو ته اجازه درکوي ټولو پیرودونکو ته پیغام واستوي.
پوښتنه: - د دې چینل له لارې څه لیږدول کیږي؟
اغلی: - هغه ماډل چې بدل شوی یا پینګ لیږدول شوی (په لازمي ډول یوازې یو شمیر ، عدد).
اغلی: - تاسو کولی شئ هرڅه واستوئ ، کوم جوړښت واستوئ ، خپور کړئ - دا یوازې په JSON بدلیږي او بس.
اغلی: - موږ د پوسټګریس څخه خبرتیا ترلاسه کوو - دا د میز نوم او پیژندونکی لري. د میز د نوم او پیژندونکي پر بنسټ، موږ هغه ریکارډ ترلاسه کوو چې موږ ورته اړتیا لرو، او بیا موږ دا جوړښت د خپرولو لپاره لیږو.
زیربنا
دا د زیربنا له لید څخه څه ښکاري؟ موږ 7 هارډویر سرورونه لرو: یو یې په بشپړ ډول ډیټابیس ته وقف شوی ، نور شپږ مجازی ماشینونه چلوي. د API 6 کاپي شتون لري: د API سره هر مجازی ماشین په جلا هارډویر سرور کې چلیږي - دا د اعتبار لپاره دی.
موږ د لاسرسي ښه کولو لپاره د Keepalived سره دوه فرنټ اینډونه لرو ، نو که چیرې یو څه پیښ شي ، یو فرنټ اینډ کولی شي بل ځای په ځای کړي. همدارنګه - د CMS دوه کاپي.
د احصایې واردونکی هم شتون لري. دلته د DB غلام شتون لري چې له هغې څخه بیک اپ په دوره توګه جوړیږي. د کبوتر پشر شتون لري، یو غوښتنلیک چې پیرودونکو ته د فشار خبرتیاوې لیږي، په بیله بیا د زیربناوو شیان: زیبکس، ګریلوګ 2 او شیف.
په حقیقت کې، دا زیربنا بې ځایه ده، ځکه چې 100 زره د لږو سرورونو سره خدمت کیدی شي. مګر دلته اوسپنه وه - موږ یې کارولې (موږ ته ویل شوي چې دا ممکنه وه - ولې نه).
د Go ګټې
وروسته له دې چې موږ په دې غوښتنلیک کار وکړ، د Go داسې ښکاره ګټې راڅرګندې شوې.
- ښه http کتابتون. د دې سره تاسو کولی شئ د بکس څخه ډیر څه رامینځته کړئ.
- برسیره پردې، هغه چینلونه چې موږ ته اجازه راکوي چې په اسانۍ سره پیرودونکو ته د خبرتیاوو لیږلو میکانیزم پلي کړو.
- په زړه پوري شی د ریس کشف کونکي موږ ته اجازه راکړه چې ډیری مهمې کیګونه له مینځه یوسو (د زیربنا مرحله). هرڅه چې په سټینګ کې کار کوي په لاره اچول شوي ، د ریس کیلي سره ترکیب شوي؛ او په دې اساس، موږ کولی شو د سټینګ زیربنا وګورو ترڅو وګورو چې موږ کومې احتمالي ستونزې لرو.
- د ژبې لږوالی او سادگي.
موږ د پراختیا کونکو په لټه کې یو! که څوک وغواړي، مهرباني وکړئ.
پوښتنې
د لیدونکو څخه پوښتنه (له دې وروسته - B): - ماته داسې بریښي چې تاسو د فین آوټ په اړه یو مهم ټکی له لاسه ورکړی. ایا زه په دې پوهیدو کې سم یم چې کله تاسو پیرودونکي ته ځواب واستوئ، تاسو بند کړئ که چیرې مراجع نه غواړي لوستل شي؟
اغلی: - نه، موږ بلاک نه کوو. لومړی، موږ دا ټول د نګینکس شاته لرو، دا دی، د ورو پیرودونکو سره کومه ستونزه نشته. دوهم، پیرودونکي د بفر سره یو چینل لري - په حقیقت کې، موږ کولی شو هلته تر سلو پورې تازه معلومات ورکړو ... که موږ چینل ته ونه لیکو، نو دا یې حذف کوي. که موږ وګورو چې چینل بند شوی، نو موږ به په ساده ډول چینل وتړو، او دا دی - پیرودونکي به بیا وصل شي که کومه ستونزه رامنځته شي. له همدې امله، په اصولو کې، دلته هیڅ بندیز نشته.
په: - ایا دا ممکنه نده چې سمدلاسه د اوریدلو / خبرتیا لپاره ریکارډ واستوو ، او نه د پیژندونکي میز؟
اغلی: - اوریدل / خبرتیا په پریلوډ کې د 8 زره بایټس حد لري چې دا لیږل کیږي. په اصولو کې، دا به ممکنه وي چې لیږل شي که چیرې موږ د لږ مقدار ډاټا سره معامله وکړو، مګر داسې ښکاري چې دا طریقه [هغه لاره چې موږ یې کوو] په ساده ډول د اعتبار وړ دی. محدودیتونه پخپله په پوسټګریس کې دي.
په: - ایا پیرودونکي د میچونو په اړه تازه معلومات ترلاسه کوي چې دوی ورسره علاقه نلري؟
اغلی: - په عمومي توګه، هو. د یوې قاعدې په توګه، دلته 2-3 لوبې په موازي توګه روانې دي، او حتی په ندرت سره. که یو پیرودونکی یو څه ګوري، نو معمولا هغه لوبه ګوري چې روانه ده. بیا، پیرودونکی یو محلي ډیټابیس لري په کوم کې چې دا ټول تازه معلومات اضافه شوي، او حتی د انټرنیټ اتصال پرته، پیرودونکی کولی شي ټولې تیرې لوبې وګوري چې د هغه لپاره تازه معلومات لري. په لازمي ډول ، موږ خپل ډیټابیس په سرور کې د پیرودونکي ځایی ډیټابیس سره همغږي کوو ترڅو هغه آفلاین کار وکړي.
په: - تاسو ولې خپل ORM جوړ کړ؟
الیکسي (د Look+ یو له پراختیا کونکو څخه): - په هغه وخت کې (دا یو کال دمخه و) د اوس په پرتله لږ ORMs شتون درلود ، کله چې دوی خورا ډیر دي. د ډیری ORMs په اړه زما غوره شی دا دی چې ډیری یې په خالي انٹرفیسونو کې پرمخ ځي. دا دی، په دې ORMs کې میتودونه د هر څه اخیستلو لپاره چمتو دي: یو جوړښت، د جوړښت پوائنټر، یو شمیر، یو څه چې په بشپړه توګه غیر مناسب ...
زموږ ORM د ډیټا ماډل پراساس جوړښتونه رامینځته کوي. زه پخپله. او له همدې امله ټول میتودونه کانکریټ دي، انعکاس نه کاروئ، او داسې نور. دوی جوړښتونه مني او تمه لري چې هغه جوړښتونه وکاروي چې راځي.
په: - څومره کسانو برخه اخیستې وه؟
اغلی: - په لومړي پړاو کې، دوه کسانو برخه اخیستې وه. موږ د جون په میاشت کې یو ځای پیل کړ، او د اګست په میاشت کې اصلي برخه چمتو وه (لومړی نسخه). په سپتمبر کې خوشې شو.
په: - چیرې چې تاسو SSE تشریح کوئ، تاسو د وخت پای نه کاروئ. ولې دغه دی؟
اغلی: - د ریښتیني کیدو لپاره ، SSE لاهم یو html5 پروتوکول دی: د SSE معیار د براوزرونو سره د خبرو اترو لپاره ډیزاین شوی ، تر هغه چې زه پوهیږم. دا اضافي ځانګړتیاوې لري ترڅو براوزرونه بیا وصل شي (او داسې نور)، مګر موږ ورته اړتیا نلرو، ځکه چې موږ پیرودونکي درلودل چې د معلوماتو د نښلولو او ترلاسه کولو لپاره کوم منطق پلي کولی شي. موږ SSE نه دی جوړ کړی، بلکه د SSE سره ورته یو څه. دا پخپله پروتوکول ندی.
هیڅ اړتیا نه وه. تر هغه ځایه چې زه پوهیږم، پیرودونکو د اړیکو میکانیزم تقریبا له پیل څخه پلي کړ. دوی واقعیا پروا نه درلوده.
په: - تاسو کوم اضافي اسانتیاوې کارولې؟
اغلی: - موږ په فعاله توګه د سټایل متحد کولو لپاره د ګوویټ او ګولینټ څخه کار اخلو، او همدارنګه د gofmt. نور څه نه دي کارول شوي.
په: - تاسو د ډیبګ کولو لپاره څه کارولي؟
اغلی: - ډیبګ کول په لویه کچه د ازموینو په کارولو سره ترسره شوي. موږ هیڅ ډیبګر یا GOP نه دی کارولی.
په: - ایا تاسو کولی شئ هغه سلایډ بیرته راوباسئ چیرې چې د خپرولو فعالیت پلي کیږي؟ ایا د واحد لیک متغیر نومونه تاسو مغشوشوي؟
اغلی: - نه. دوی د لید لید خورا "تنګ" ساحه لري. دوی دلته پرته بل چیرې نه کارول کیږي (د دې ټولګي داخلي څخه پرته)، او دا خورا کمپیکٹ دی - دا یوازې 7 لینونه نیسي.
په: - یو څه دا لاهم هوښیار ندی ...
اغلی: - نه، نه، دا یو ریښتینی کوډ دی! دا د سټایل په اړه ندي. دا یوازې یو ګټور، خورا کوچنی ټولګی دی - په ټولګي کې یوازې 3 ساحې ...
اغلی: - په لویه کچه ، ټول هغه معلومات چې د پیرودونکو سره همغږي شوي (د فصل میچونه ، لوبغاړي) نه بدلیږي. په لنډه توګه، که موږ یو بل سپورت جوړ کړو چې موږ یې د میچ بدلولو ته اړتیا لرو، موږ به په ساده ډول د مراجعینو په نوي نسخه کې هرڅه په پام کې ونیسو، او د پیرودونکي زاړه نسخې به منع شي.
په: - ایا د دریمې ډلې انحصاري مدیریت کڅوړې شتون لري؟
اغلی: - موږ لاړ شو.
په: - د راپور په موضوع کې د ویډیو په اړه څه وو، خو په راپور کې د ویډیو په اړه څه نه وو.
اغلی: - نه، زه د ویډیو په اړه په موضوع کې هیڅ نه لرم. دا د "Look +" په نوم یادیږي - دا د غوښتنلیک نوم دی.
په: - تاسو وویل چې دا پیرودونکو ته خپریږي؟ ..
اغلی: - موږ د ویډیو په جریان کې ښکیل نه وو. دا په بشپړه توګه د میګافون لخوا ترسره شوی. هو، ما ونه ویل چې غوښتنلیک میګافون و.
اغلی: - لاړشئ - د ټولو معلوماتو لیږلو لپاره - په نمرو کې ، د میچ پیښو په اړه ، احصایې ... Go د غوښتنلیک لپاره بشپړ شالید دی. پیرودونکي باید له کوم ځای څخه پوه شي چې کوم لینک د لوبغاړي لپاره کارول کیږي ترڅو کاروونکي وکولی شي لوبه وګوري. موږ د ویډیوګانو او جریانونو لینکونه لرو چې چمتو شوي دي.
ځینې اعلانونه 🙂
له موږ سره د پاتې کیدو لپاره مننه. ایا تاسو زموږ مقالې خوښوي؟ غواړئ نور په زړه پورې مینځپانګه وګورئ؟ د امر په ورکولو یا ملګرو ته وړاندیز کولو سره زموږ ملاتړ وکړئ ، , د ننوتلو کچې سرورونو یو ځانګړی انلاګ ، کوم چې زموږ لخوا ستاسو لپاره اختراع شوی و: (د RAID1 او RAID10 سره شتون لري، تر 24 کور پورې او تر 40GB DDR4 پورې).
ډیل R730xd په امستردام کې د Equinix Tier IV ډیټا مرکز کې 2 ځله ارزانه؟ یوازې دلته په هالنډ کې! ډیل R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - له $ 99 څخه! په اړه ولولئ
سرچینه: www.habr.com