بل د څارنې سیسټم

16 موډیمونه، 4 سیلولر آپریټرونه = د وتلو سرعت 933.45 Mbit/s

پېژندنه

سلام! دا مقاله د دې په اړه ده چې څنګه موږ د ځان لپاره د څارنې نوی سیسټم لیکلی. دا د لوړ فریکونسۍ همغږي میټریکونو او خورا ټیټ سرچینې مصرف ترلاسه کولو وړتیا کې له موجوده څخه توپیر لري. د رای ورکولو کچه د 0.1 نانو ثانیو میټریکونو تر مینځ د همغږي دقت سره 10 ملی ثانیو ته رسیدلی شي. ټول بائنری فایلونه 6 میګابایټ نیسي.

د پروژې په اړه

موږ یو ځانګړی محصول لرو. موږ د ډیټا لیږد چینلونو له لارې پټولو او غلطۍ زغم لنډیز کولو لپاره جامع حل تولید کوو. دا هغه وخت دی چې ډیری چینلونه شتون لري، راځئ چې ووایو Operator1 (40Mbit/s) + Operator2 (30Mbit/s) + بل څه (5 Mbit/s)، پایله یو ثابت او چټک چینل دی، چې سرعت به یې یو څه وي. دا: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

دا ډول حلونه په تقاضا کې دي چیرې چې د کوم یو چینل ظرفیت کافي نه وي. د مثال په توګه، ټرانسپورټ، د ویډیو څارنې سیسټمونه او په ریښتیني وخت کې د ویډیو سټینګ کول، د ژوندیو تلویزیونونو او راډیو خپرونو خپرونه، هر هغه فرعي تاسیسات چیرې چې د مخابراتي آپریټرانو ترمنځ یوازې د لوی څلور استازي شتون لري او په یو موډیم / چینل کې سرعت کافي ندي. .
د دې هرې برخې لپاره، موږ د وسایلو جلا کرښه تولیدوو، مګر د دوی سافټویر برخه تقریبا ورته ده او د لوړ کیفیت د څارنې سیسټم د هغې یو له اصلي ماډلونو څخه دی، پرته له دې چې د محصول سم تطبیق ممکن نه وي.

د څو کلونو په جریان کې، موږ د څو کچې، چټک، کراس پلیټ فارم او لږ وزن څارنې سیسټم رامینځته کولو توان درلود. دا هغه څه دي چې موږ یې غواړو د خپلې معززې ټولنې سره شریک کړو.

د ستونزې تشکیل

د څارنې سیسټم د دوه بنسټیزو مختلفو ټولګیو میټریکونه وړاندې کوي: د حقیقي وخت میټریک او نور ټول. د څارنې سیسټم یوازې لاندې اړتیاوې درلودې:

1. د ریښتیني وخت میټریکونو لوړ فریکونسۍ همغږي استملاک او پرته له ځنډه د مخابراتو مدیریت سیسټم ته د دوی لیږد.
   د مختلف میټریکونو لوړ فریکونسۍ او همغږي کول یوازې مهم ندي ، دا د ډیټا لیږد چینلونو انټروپي تحلیل لپاره حیاتي دي. که په یو ډیټا لیږد چینل کې اوسط ځنډ 30 ملی ثانوي وي، نو یوازې د یو ملی ثانوي پاتې میټریکونو تر مینځ په ترکیب کې تېروتنه به د پایله شوي چینل سرعت نږدې 5٪ تخریب لامل شي. که موږ په 1 چینلونو کې د 4 ملی ثانوي لخوا وخت غلط کړو، د سرعت تخریب په اسانۍ سره 30٪ ته راټیټیږي. برسېره پردې، په چینلونو کې انټروپي په چټکۍ سره بدلیږي، نو که موږ دا په هر 0.5 ملی ثانوي کې له یو ځل څخه لږ اندازه کړو، په چټکو چینلونو کې د لږ ځنډ سره به موږ د لوړ سرعت تخریب ترلاسه کړو. البته، دا ډول دقت د ټولو میټریکونو لپاره اړین ندي او نه په ټولو شرایطو کې. کله چې په چینل کې ځنډ 500 ملی ثانیه وي ، او موږ د ورته سره کار کوو ، نو د 1 ملی ثانیه غلطی به نږدې د پام وړ نه وي. همدارنګه، د ژوند مالتړ سیسټم میټریکونو لپاره، موږ د 2 ثانیو لپاره د رایې ورکولو او همغږي کولو نرخونه لرو، مګر د څارنې سیسټم باید پخپله د دې وړتیا ولري چې د رای ورکولو خورا لوړ نرخونو او د میټریکونو خورا دقیق همغږي سره کار وکړي.
2. د سرچینو لږترلږه مصرف او یو واحد سټیک.
   د پای وسیله کیدای شي یو پیاوړی آن بورډ کمپلیکس وي چې کولی شي په سړک کې وضعیت تحلیل کړي یا د خلکو بایومیټریک ریکارډ ترسره کړي، یا د پام په اندازه یو واحد تخته کمپیوټر چې د ځانګړو ځواکونو سرتیري د خپل بدن زغره لاندې اغوندي ترڅو ویډیو لیږد کړي. ریښتیني وخت د مخابراتو ضعیف شرایطو کې. د داسې ډول ډول جوړښتونو او کمپیوټري ځواک سره سره، موږ غواړو ورته سافټویر سټیک ولرو.
3. د چترۍ معمارۍ
   میټریکونه باید په پای وسیلې کې راټول او راټول شي ، په ځایی ډول زیرمه شوي ، او په ریښتیني وخت او په شاتګ کې لیدل شوي. که چیرې اړیکه شتون ولري، د مرکزي څارنې سیسټم ته ډاټا لیږدول. کله چې اړیکه شتون ونلري، د لیږلو کتار باید راټول شي او RAM مصرف نکړي.
4. د پیرودونکي د څارنې سیسټم کې د ادغام لپاره API، ځکه چې هیڅوک د نظارت ډیری سیسټمونو ته اړتیا نلري. پیرودونکی باید د هر ډول وسیلو او شبکو څخه ډاټا په یو واحد نظارت کې راټول کړي.

څه پیښ شو

د دې لپاره چې دمخه اغیزمن اوږد ریډ بار نه وي ، زه به د ټولو نظارت سیسټمونو مثالونه او اندازه ونه کړم. دا به د بلې مقالې لامل شي. زه به یوازې ووایم چې موږ د نظارت سیسټم موندلو توان نه درلود چې د 1 ملی ثانوي څخه کم غلطی سره په ورته وخت کې د دوه میټریکونو اخیستلو وړ وي او دا د 64 MB رام سره د ARM جوړښت او د 86 سره x64_32 معمارۍ کې په مساوي توګه کار کوي. GB رام له همدې امله، موږ پریکړه وکړه چې خپل ځان ولیکئ، کوم چې دا ټول کولی شي. دلته هغه څه دي چې موږ یې ترلاسه کړل:

د مختلفو شبکو توپوولوژیو لپاره د دریو چینلونو له لارې لنډیز کول

د ځینو کلیدي میترونو لید

معمارۍ

موږ ګولنګ د اصلي برنامې ژبې په توګه کاروو ، دواړه په وسیله او د معلوماتو مرکز کې. دا د ملټي ټاسک کولو پلي کولو سره ژوند خورا ساده کړی او د هر خدمت لپاره د یو ثابت سره تړلي اجرایوي بائنری فایل ترلاسه کولو وړتیا. د پایلې په توګه ، موږ د پای وسیلو ، پراختیا وخت او کوډ ډیبګ کولو لپاره د خدماتو پلي کولو لپاره سرچینې ، میتودونه او ترافیک د پام وړ خوندي کوو.

سیسټم د کلاسیک ماډلر اصول سره سم پلي کیږي او ډیری فرعي سیسټمونه لري:

1. د میټریک ثبت کول.
   هر میټریک د خپل تار لخوا خدمت کیږي او په چینلونو کې همغږي کیږي. موږ وکولی شو تر 10 نانو ثانیو پورې د همغږي کولو دقیقیت ترلاسه کړو.
2. د میټریک ذخیره کول
   موږ د وخت لړۍ لپاره زموږ د ذخیره کولو لیکلو یا د هغه څه کارولو ترمینځ غوره کول چې دمخه شتون درلود. ډیټابیس د مخکینۍ ډیټا لپاره اړین دی چې د راتلونکي لید سره مخ وي. یعني دا په هر 0.5 ملی ثانیه کې په چینل کې د ځنډ یا په ټرانسپورټ شبکه کې د خطا لوستلو ډیټا نلري ، مګر په هر انٹرفیس کې په هر 500 ملی ثانیه کې سرعت شتون لري. د کراس پلیټ فارم او ټیټ سرچینو مصرف لپاره د لوړې اړتیاو سربیره ، دا زموږ لپاره خورا مهم دي چې د پروسس کولو وړ اوسو. ډاټا هغه ځای دی چیرې چې ذخیره کیږي. دا د کمپیوټر ډیری سرچینې خوندي کوي. موږ د 2016 راهیسې پدې پروژه کې د ترنټول DBMS کاروو او تر دې دمه موږ په افق کې د دې لپاره بدیل نه وینو. انعطاف وړ، د منابعو د غوره مصرف سره، د کافي تخنیکي مالتړ څخه ډیر. Tarantool د GIS ماډل هم پلي کوي. البته، دا د PostGIS په څیر ځواکمن ندی، مګر دا زموږ د دندو لپاره کافي دی چې د ځینې موقعیت پورې اړوند میټریکونو ذخیره کول (د ټرانسپورټ لپاره اړونده).
3. د میټریکونو لید
   دلته هرڅه نسبتا ساده دي. موږ د ګودام څخه ډاټا اخلو او یا یې په ریښتیني وخت کې یا په شاتګ سره ښکاره کوو.
4. د مرکزي څارنې سیسټم سره د معلوماتو همغږي کول.
   د مرکزي څارنې سیسټم د ټولو وسیلو څخه ډاټا ترلاسه کوي، دا د ټاکل شوي تاریخ سره ذخیره کوي او د API له لارې د پیرودونکي څارنې سیسټم ته لیږي. د کلاسیک نظارت سیسټمونو برخلاف ، په کوم کې چې "سر" شاوخوا ګرځي او معلومات راټولوي ، موږ برعکس سکیم لرو. وسیلې پخپله ډیټا لیږي کله چې اړیکه شتون ولري. دا یو خورا مهم ټکی دی ، ځکه چې دا تاسو ته اجازه درکوي د وسیلې څخه د هغه مودې لپاره ډیټا ترلاسه کړئ چې په جریان کې یې شتون نلري او چینلونه او سرچینې نه پورته کوي پداسې حال کې چې وسیله شتون نلري. موږ د انفلوکس څارنې سرور د مرکزي څارنې سیسټم په توګه کاروو. د دې انالوګونو په خلاف، دا کولی شي د بیرته راګرځیدونکي ډاټا وارد کړي (یعنی د میټریک ترلاسه کولو شیبې څخه د وخت ټاپه سره توپیر لري). دا معیاري سټیک هم غوره شوی و ځکه چې دا د نږدې هر پیرودونکي څارنې سیسټم سره چمتو شوي API ادغام لري.
5. د مرکزي وسیلې مدیریت سیسټم سره د معلوماتو همغږي کول.
   د وسیلې مدیریت سیسټم د صفر ټچ چمتو کول پلي کوي (د فرم ویئر تازه کول ، ترتیب کول ، او نور) او د نظارت سیسټم برعکس ، په هر وسیله یوازې ستونزې ترلاسه کوي. دا د آن بورډ هارډویر واچ ډاگ خدماتو او د ژوند ملاتړ سیسټمونو ټول میټریکونو عملیاتو لپاره محرکونه دي: د CPU او SSD تودوخې ، CPU بار ، خالي ځای او په ډیسکونو کې د سمارټ روغتیا. د فرعي سیسټم ذخیره هم په Tarantool کې جوړه شوې ده. دا موږ ته د زرګونو وسیلو په اوږدو کې د وخت لړۍ راټولولو کې د پام وړ سرعت راکوي ، او د دې وسیلو سره د معلوماتو همغږي کولو مسله هم په بشپړ ډول حل کوي. ترنټوول یو ښه قطار او تضمین شوی تحویلي سیسټم لري. موږ دا مهم خصوصیت له بکس څخه ترلاسه کړ ، عالي!

د شبکې مدیریت سیسټم

نور څه شی دی

تر اوسه پورې، زموږ ضعیف اړیکه د مرکزي څارنې سیسټم دی. دا په معیاري سټیک کې 99.9٪ پلي کیږي او یو شمیر زیانونه لري:

1. InfluxDB ډیټا له لاسه ورکوي کله چې بریښنا له لاسه ورکړي. د یوې قاعدې په توګه، پیرودونکي سمدستي هر هغه څه راټولوي چې له وسیلو څخه راځي او ډیټابیس پخپله د 5 دقیقو څخه زاړه معلومات نلري، مګر په راتلونکي کې دا ممکن درد شي.
2. ګرافانا د ډیټا راټولولو او د دې نندارې ترکیب سره یو شمیر ستونزې لري. ترټولو عام ستونزه هغه وخت ده چې ډیټابیس د وخت لړۍ لري چې د 2 ثانیو وقفې سره پیل کیږي، ووایه، 00:00:00، او ګرافانا د +1 ثانیو څخه په راټولولو کې ډاټا ښودل پیل کوي. د پایلې په توګه، کاروونکي د نڅا ګراف ګوري.
3. د دریمې ډلې څارنې سیسټمونو سره د API ادغام لپاره د کوډ ډیر مقدار. دا خورا ډیر کمپیکٹ کیدی شي او البته په Go کې بیا لیکل کیدی شي)

زه فکر کوم چې تاسو ټولو په بشپړ ډول لیدلي چې ګرافانا څنګه ښکاري او زما پرته د هغې ستونزې پیژني، نو زه به د عکسونو سره پوسټ ډیر نه کړم.

پایلې

ما په عمدي توګه تخنیکي توضیحات نه دي بیان کړي، مګر یوازې د دې سیسټم اساسي ډیزاین بیان کړی. لومړی، د تخنیکي پلوه په بشپړ ډول د سیسټم تشریح کولو لپاره، بله مقاله به اړین وي. دوهم، هرڅوک به پدې کې علاقه ونه لري. په نظرونو کې ولیکئ چې کوم تخنیکي توضیحات غواړئ پوه شئ.

که څوک د دې مقالې له ساحې هاخوا پوښتنې لري، تاسو کولی شئ ما ته په [email protected] کې ولیکئ

سرچینه: www.habr.com