دا د یو پیاوړی، لوړ بار سیسټم رامینځته کولو لپاره زموږ د خیټې لارې په اړه د یوې اوږدې کیسې دوام دی چې د تبادلې عملیات یقیني کوي. لومړۍ برخه دلته ده:
پراسرار تېروتنه
د ډیری ازموینو وروسته، د سوداګرۍ او پاکولو تازه سیسټم په کار واچول شو، او موږ د یوې ستونزې سره مخ شو چې په اړه یې موږ کولی شو د جاسوس - صوفیانه کیسه ولیکو.
په اصلي سرور کې د پیل کولو څخه سمدلاسه وروسته، یو له لیږدونو څخه د غلطۍ سره پروسس شو. په هرصورت، په بیک اپ سرور کې هرڅه سم وو. دا معلومه شوه چې په اصلي سرور کې د توزیع محاسبه کولو ساده ریاضياتي عملیات د اصلي دلیل څخه منفي پایله ورکړه! موږ خپلې څیړنې ته دوام ورکړ، او د SSE2 راجستر کې موږ په یو څه کې یو توپیر وموند، کوم چې د فلوټینګ پوائنټ شمیرو سره کار کولو په وخت کې د ګردي کولو مسولیت لري.
موږ یو ساده ټیسټ افادیت لیکلی ترڅو د رانډینګ بټ سیټ سره د اکسپوننټ محاسبه کړو. دا معلومه شوه چې د RedHat لینکس په نسخه کې چې موږ یې کارولې، د ریاضیاتي فعالیت سره کار کولو کې یوه ستونزه وه کله چې بد قسمت بټ داخل شو. موږ دا ریډ هټ ته راپور ورکړ، یو څه وروسته موږ د دوی څخه یو پیچ ترلاسه کړ او دا یې راوباسي. تېروتنه نوره نه ده رامنځته شوې، خو دا څرګنده نه ده چې دا بټ له کوم ځای څخه راغلی؟ فعالیت یې په غاړه درلود fesetround د C ژبې څخه. موږ خپل کوډ په دقت سره تحلیل کړ چې د اټکل شوې غلطۍ په لټه کې شو: موږ ټول ممکنه حالتونه چیک کړل؛ ټولو هغو افعالو ته کتل چې ګردي کول یې کارولي؛ هڅه وکړه چې ناکامه ناسته بیا تولید کړي؛ د مختلف انتخابونو سره مختلف کمپیلرونه کارول شوي؛ جامد او متحرک تحلیلونه کارول شوي.
د تېروتنې لامل ونه موندل شو.
بیا دوی د هارډویر معاینه پیل کړه: دوی د پروسیسرونو بار ازموینه ترسره کړه؛ رام چک کړ؛ موږ حتی په یوه حجره کې د څو بټ غلطۍ خورا احتمالي سناریو لپاره ازموینې ترسره کړې. هیڅ ګټه نلري.
په پای کې، موږ د لوړې انرژۍ فزیک نړۍ څخه په یوه تیورۍ کې میشت شو: یو څه د انرژي لوړ ذرات زموږ د ډیټا مرکز ته الوتنه وکړه، د قضیې دیوال یې سور کړ، پروسیسر یې وویشته او د محرک لیچ یې په دې برخه کې ودراوه. دا بې بنسټه تیوري د "نیوټرینو" په نوم یادیږي. که تاسو د ذراتو فزیک څخه لرې یاست: نیوټرینو تقریبا د بهرنۍ نړۍ سره اړیکه نه لري، او یقینا د دې توان نلري چې د پروسیسر عملیات اغیزمن کړي.
څرنګه چې د ناکامۍ لامل موندل ممکن نه و، نو "سرغړونکي" سرور یوازې په قضیه کې له عملیاتو څخه لرې شوی و.
د یو څه وخت وروسته، موږ د ګرم بیک اپ سیسټم ښه کولو پیل وکړ: موږ د "تودوخې زیرمې" (ګرم) په نوم معرفي کړل - غیر متناسب نقلونه. دوی د معاملو یو جریان ترلاسه کړ چې کیدای شي په مختلفو ډیټا مرکزونو کې موقعیت ولري، مګر ګرمې په فعاله توګه د نورو سرورونو سره اړیکه نه وه نیولې.
ولې دا کار وشو؟ که د بیک اپ سرور ناکام شي، نو د اصلي سرور سره ګرم تړل شوی نوی بیک اپ کیږي. دا ، د ناکامۍ وروسته ، سیسټم د سوداګرۍ ناستې پای پورې د یو اصلي سرور سره نه پاتې کیږي.
او کله چې د سیسټم نوې نسخه ازمول شوې او په عمل کې واچول شوه ، د رانډینګ بټ خطا بیا رامینځته شوه. برسېره پردې، د ګرمو سرورونو په شمیر کې زیاتوالي سره، تېروتنه ډیر ځله ښکاره شوه. په ورته وخت کې، پلورونکي د ښودلو لپاره هیڅ شی نه درلود، ځکه چې کوم کره شواهد شتون نلري.
د وضعیت د راتلونکي تحلیل په جریان کې، یوه تیوري راپورته شوه چې ستونزه د OS سره تړاو لري. موږ یو ساده برنامه لیکلې چې یو فنکشن په نه ختمیدونکي لوپ کې بولي fesetround، اوسنی حالت په یاد ساتي او د خوب له لارې یې ګوري، او دا په ډیری سیالیو کې ترسره کیږي. د خوب لپاره د پیرامیټونو او د تارونو شمیر غوره کولو سره ، موږ د یوټیلیټ چلولو شاوخوا 5 دقیقو وروسته د بټ ناکامۍ په دوامداره توګه بیا تولید پیل کړ. که څه هم، د Red Hat ملاتړ ونه توانید چې دا بیا تولید کړي. زموږ د نورو سرورونو ازموینې ښودلې چې یوازې هغه څوک چې ځانګړي پروسیسرونه لري د خطا لپاره حساس دي. په ورته وخت کې ، نوي کرنل ته بدلول ستونزه حل کړه. په پاى کې، موږ په ساده ډول OS بدل کړ، او د بګ اصلي لامل ناڅرګند پاتې شو.
او ناڅاپه تیر کال د هابري په اړه یوه مقاله خپره شوه "" په دې کې بیان شوي وضعیت زموږ سره ورته و، مګر لیکوال تحقیق نور هم واخیست او یوه تیوري یې وړاندې کړه چې تېروتنه په مایکروکوډ کې وه. او کله چې د لینکس کرنل تازه کیږي ، تولید کونکي هم مایکرو کوډ تازه کوي.
د سیسټم نور پرمختګ
که څه هم موږ له خطا خلاص شو، دې کیسه موږ دې ته اړ کړل چې د سیسټم جوړښت بیا غور وکړو. په هرصورت، موږ د داسې کیګونو له تکرار څخه خوندي نه یو.
لاندې اصول د ریزرویشن سیسټم کې د راتلونکي پرمختګ لپاره اساس جوړوي:
- تاسو په هیچا باور نشئ کولی. سرورونه ممکن په سمه توګه کار ونکړي.
- د اکثریت ریزرویشن.
- د اجماع ډاډ. د اکثریت ریزرویشن لپاره د منطقي اضافه په توګه.
- دوه ځله ناکامي ممکنه ده.
- حیاتي. نوی ګرم سټنډرډ سکیم باید د تیرو څخه بد نه وي. تجارت باید د وروستي سرور پورې په دوامداره توګه پرمخ ولاړ شي.
- په ځنډ کې لږ زیاتوالی. هر ډول ځنډ لوی مالي زیانونه اړوي.
- لږترلږه د شبکې تعامل د امکان تر حده ټیټ ساتلو لپاره.
- په ثانیو کې د نوي ماسټر سرور غوره کول.
په بازار کې شتون لرونکي هیڅ حل موږ ته مناسب نه و ، او د رافټ پروتوکول لاهم په ماشومتوب کې و ، نو موږ خپل حل رامینځته کړ.
شبکه کول
د ریزرویشن سیسټم سربیره، موږ د شبکې تعامل عصري کول پیل کړل. د I/O فرعي سیسټم ډیری پروسې لري، کوم چې په جټټر او ځنډ باندې خورا ناوړه اغیزه درلوده. د سلګونو پروسو سره چې د TCP پیوستون اداره کوي، موږ مجبور یو چې په دوامداره توګه د دوی ترمنځ تیر کړو، او په مایکرو ثانیه پیمانه دا یو ډیر وخت نیسي عملیات دی. مګر ترټولو بده برخه دا ده چې کله یوې پروسې د پروسس لپاره پاکټ ترلاسه کړ، دا یې د سیسټم وی کتار ته واستاوه او بیا یې د بل سیسټم وی کتار څخه د پیښې لپاره انتظار وکړ. په هرصورت، کله چې د نوډونو لوی شمیر شتون ولري، په یوه پروسه کې د نوي TCP پاکټ راتګ او په بل کې په کتار کې د معلوماتو ترلاسه کول د OS لپاره دوه سیالي پیښې استازیتوب کوي. په دې حالت کې، که چیرې د دواړو دندو لپاره فزیکي پروسیسر شتون ونلري، یو به پروسس شي، او دویم به د انتظار په کتار کې ځای پرځای شي. د پایلو وړاندوینه کول ناممکن دي.
په داسې حاالتو کې، د متحرک پروسې لومړیتوب کنټرول کارول کیدی شي، مګر دا به د سرچینو د پام وړ سیسټم غوښتنې ته اړتیا ولري. د پایلې په توګه، موږ د کلاسیک ایپل په کارولو سره یو تار ته واړوو، دې کار سرعت ډیر کړی او د لیږد پروسس کولو وخت یې کم کړی. موږ د سیسټم وی له لارې د جلا شبکې ارتباطي پروسو او مخابراتو څخه هم خلاص شو، د سیسټم تلیفونونو شمیر یې د پام وړ کم کړ او د عملیاتو لومړیتوبونو کنټرول یې پیل کړ. یوازې په I/O فرعي سیسټم کې، دا ممکنه وه چې شاوخوا 8-17 مایکرو ثانیې خوندي کړئ، د سناریو پورې اړه لري. دا واحد تار شوی سکیم له هغه وخت راهیسې بدل شوی نه کارول شوی؛ د حاشیې سره یو ایپل تار د ټولو ارتباطاتو خدمت کولو لپاره کافي دی.
د راکړې ورکړې پروسس کول
زموږ په سیسټم کې مخ په زیاتیدونکي بار د هغې نږدې ټولې برخې نوي کولو ته اړتیا لري. مګر، له بده مرغه، په وروستیو کلونو کې د پروسیسر ساعت سرعت وده کې خنډ نور د پروسو سر ته رسولو ته اجازه نه ورکوي. له همدې امله، موږ پریکړه وکړه چې د انجن پروسه په دریو کچو وویشو، په دوی کې ترټولو بوخت د خطر چک کولو سیسټم دی، کوم چې په حسابونو کې د فنډ شتون ارزوي او پخپله لیږد رامینځته کوي. مګر پیسې په مختلفو اسعارو کې کیدی شي، او دا اړینه وه چې معلومه کړي چې د غوښتنو پروسس کولو پر بنسټ باید ویشل شي.
منطقي حل دا دی چې دا د اسعارو په واسطه وویشل شي: یو سرور په ډالرو کې تجارت کوي، بل په پونډ کې، او دریم په یورو کې. مګر که ، د داسې سکیم سره ، دوه لیږدونه د مختلف اسعارو پیرود لپاره واستول شي ، نو د بټوې غیر همغږي کولو ستونزه به رامینځته شي. مګر همغږي کول ستونزمن او ګران دي. له همدې امله، دا به سمه وي چې په جلا توګه د بټو په واسطه او په جلا توګه د وسایلو پواسطه جلا کړئ. په هرصورت، ډیری لویدیځ تبادلې د خطرونو چک کولو دنده نه لري لکه څنګه چې موږ یې کوو، نو ډیری وختونه دا په آفلاین توګه ترسره کیږي. موږ اړتیا لرو چې آنلاین تصدیق پلي کړو.
راځئ چې د مثال په توګه تشریح کړو. یو سوداګر غواړي $ 30 واخلي، او غوښتنه د لیږد تایید ته ځي: موږ ګورو چې ایا دا سوداګر دې سوداګرۍ حالت ته اجازه لري او ایا هغه اړین حقونه لري. که هرڅه سم وي، غوښتنه د خطر تایید سیسټم ته ځي، د بیلګې په توګه. د معاملې پای ته رسولو لپاره د فنډونو کافي اندازه چیک کول. د یادونې وړ ده چې اړین مقدار اوس مهال بند شوی دی. بیا غوښتنه د سوداګرۍ سیسټم ته لیږل کیږي، کوم چې لیږد تصویب یا ردوي. راځئ چې ووایو لیږد تصویب شو - بیا د خطر تصدیق کولو سیسټم په نښه کوي چې پیسې غیر بلاک شوي، او روبل په ډالرو بدلیږي.
په عموم کې، د خطر چک کولو سیسټم پیچلي الګوریتمونه لري او د ډیری سرچینو خورا خورا محاسبې ترسره کوي، او په ساده ډول د "حساب بیلانس" نه ګوري، لکه څنګه چې دا په لومړي نظر کې ښکاري.
کله چې موږ د انجن پروسې په کچو ویشل پیل کړل، موږ له یوې ستونزې سره مخ شو: هغه کوډ چې په هغه وخت کې شتون درلود په فعاله توګه د اعتبار او تصدیق مرحلو کې ورته ډیټا کارولې، کوم چې د ټول کوډ بیس بیا لیکلو ته اړتیا درلوده. د پایلې په توګه، موږ د عصري پروسیسرونو څخه د لارښوونو پروسس کولو لپاره یو تخنیک په پور اخیستی دی: هر یو یې په کوچنیو مرحلو ویشل شوی او ډیری کړنې په موازي توګه په یوه دوره کې ترسره کیږي.
د کوډ د یو کوچني تطبیق وروسته، موږ د موازي معاملو پروسس کولو لپاره پایپ لاین جوړ کړ، په کوم کې چې لیږد د پایپ لاین په 4 مرحلو ویشل شوی و: د شبکې تعامل، اعتبار، اجرا کول او د پایلې خپرول
راځئ چې یو مثال وګورو. موږ دوه پروسس سیسټمونه لرو، سیریل او موازي. لومړۍ معامله راځي او په دواړو سیسټمونو کې د اعتبار لپاره لیږل کیږي. دوهم لیږد سمدلاسه راځي: په موازي سیسټم کې دا سمدلاسه کار ته وړل کیږي ، او په ترتیبي سیسټم کې دا په یوه کتار کې ایښودل کیږي چې د اوسني پروسس مرحلې ته د رسیدو لپاره لومړۍ لیږد ته انتظار باسي. دا، د پایپ لاین پروسس کولو اصلي ګټه دا ده چې موږ د لیږد کتار ګړندی پروسس کوو.
دا څنګه موږ د ASTS + سیسټم سره مخ شو.
ریښتیا ، هرڅه د لیږدونکو سره هم دومره اسانه ندي. راځئ چې ووایو موږ یوه معامله لرو چې د ګاونډ لیږد کې د معلوماتو سرې اغیزه کوي؛ دا د تبادلې لپاره یو عادي حالت دی. دا ډول معامله په پایپ لاین کې نشي ترسره کیدی ځکه چې دا ممکن په نورو اغیزه وکړي. دې حالت ته د ډیټا خطر ویل کیږي، او دا ډول لیږدونه په ساده ډول په جلا توګه پروسس کیږي: کله چې په کتار کې "چټک" لیږد پای ته ورسیږي، پایپ لاین ودریږي، سیسټم "ورو" لیږد پروسس کوي، او بیا پایپ لاین بیا پیل کوي. خوشبختانه، په ټولیز جریان کې د دې ډول معاملو تناسب خورا کوچنی دی، نو پایپ لاین په ندرت سره ودریږي چې دا په عمومي فعالیت اغیزه نه کوي.
بیا موږ د اعدام د دریو تارونو همغږي کولو ستونزه حل کول پیل کړل. پایله د ثابت اندازې حجرو سره د حلقوي بفر پراساس یو سیسټم و. په دې سیسټم کې، هرڅه د پروسس سرعت سره تړاو لري؛ ډاټا کاپي شوي ندي.
- ټول راتلونکې شبکې کڅوړې د تخصیص مرحلې ته ننوځي.
- موږ دوی په یو صف کې ځای په ځای کوو او د مرحلې # 1 لپاره د شتون په توګه یې په نښه کوو.
- دوهمه معامله راورسیده، دا بیا د مرحلې نمبر 1 لپاره شتون لري.
- د پروسس کولو لومړی تار شته لیږدونه ګوري، پروسس کوي، او د دویم پروسس کولو تار بل پړاو ته یې لیږدوي.
- دا بیا لومړی لیږد پروسس کوي او اړوند حجره بیرغ کوي
deleted- دا اوس د نوي استعمال لپاره شتون لري.
ټول قطار په دې ډول پروسس کیږي.
د هرې مرحلې پروسس یونټونه یا لسګونه مایکرو ثانیو وخت نیسي. او که موږ د معیاري OS همغږي کولو سکیمونه وکاروو ، نو موږ به پخپله همغږي کې ډیر وخت له لاسه ورکړو. له همدې امله موږ د سپن لاک کارول پیل کړل. په هرصورت، دا په ریښتیني وخت سیسټم کې خورا بد شکل دی، او RedHat په کلکه د دې کولو سپارښتنه نه کوي، نو موږ د 100 ms لپاره سپن لاک پلي کوو، او بیا د سیمفور حالت ته لاړ شو ترڅو د ځنډ احتمال له منځه یوسو.
د پایلې په توګه، موږ په هره ثانیه کې شاوخوا 8 ملیون لیږدونه ترسره کړل. او په حقیقت کې دوه میاشتې وروسته د LMAX ګډوډي په اړه موږ د ورته فعالیت سره د سرکټ توضیحات ولیدل.
اوس په یوه مرحله کې د اعدام څو تارونه کیدی شي. ټولې معاملې یو په یو پروسس شوې ، په ترتیب سره چې دوی ترلاسه شوي. د پایلې په توګه، لوړ فعالیت په هره ثانیه کې له 18 زره څخه 50 زره لیږد ته لوړ شو.
د تبادلې د خطر مدیریت سیسټم
د بشپړتیا لپاره هیڅ حد شتون نلري، او ډیر ژر موږ بیا عصري کول پیل کړل: د ASTS+ په چوکاټ کې، موږ د خطر مدیریت او د تصفیې سیسټمونه په خپلواکه برخو کې حرکت پیل کړ. موږ د انعطاف وړ عصري معمارۍ او نوي درجه بندي خطر ماډل رامینځته کړی، او هڅه مو وکړه چې د امکان تر حده ټولګي وکاروو fixed_point د ځای پرځای double.
مګر یوه ستونزه سمدلاسه راپورته شوه: څنګه د سوداګرۍ ټول منطق چې د ډیرو کلونو لپاره کار کوي همغږي کړئ او نوي سیسټم ته یې لیږدئ؟ د پایلې په توګه، د نوي سیسټم د پروټوټایپ لومړۍ نسخه باید پریښودل شي. دویمه نسخه، چې اوس مهال په تولید کې کار کوي، د ورته کوډ پر بنسټ والړ دی، کوم چې د سوداګرۍ او خطر دواړو برخو کې کار کوي. د پراختیا په جریان کې، د ترسره کولو ترټولو سخت کار د دوو نسخو ترمنځ د git ادغام و. زموږ همکار Evgeniy Mazurenok دا عملیات هره اونۍ ترسره کړل او هر ځل یې د اوږدې مودې لپاره لعنت ویل.
کله چې یو نوی سیسټم غوره کړو، موږ باید سمدستي د متقابل عمل ستونزه حل کړو. کله چې د ډیټا بس غوره کول، دا اړینه وه چې د باثباته جټر او لږترلږه ځنډ ډاډمن شي. د InfiniBand RDMA شبکه د دې لپاره غوره وه: د اوسط پروسس وخت د 4 G ایترنیټ شبکې په پرتله 10 ځله کم دی. مګر هغه څه چې واقعیا یې موږ جذب کړل د فیصدو توپیر و - 99 او 99,9.
البته، InfiniBand خپلې ننګونې لري. لومړی، یو مختلف API - د ساکټ پر ځای ibverbs. دوهم، د خلاصې سرچینې پیغام رسولو حل تقریبا په پراخه کچه شتون نلري. موږ هڅه وکړه چې خپل پروټوټایپ جوړ کړو، مګر دا خورا ستونزمن و، نو موږ یو سوداګریز حل غوره کړ - د محدودیت ټیټ ځنډ پیغام رسول (پخوا د IBM MQ LLM).
بیا د خطر سیسټم په سمه توګه ویشلو دنده پیل شوه. که تاسو په ساده ډول د خطر انجن لرې کړئ او منځمهاله نوډ جوړ نه کړئ، نو بیا د دوو سرچینو څخه لیږدونه مخلوط کیدی شي.
د الټرا ټیټ لیټینسي حلونه د بیا تنظیم کولو حالت لري: د دوه سرچینو څخه لیږدونه د رسیدلو وروسته په اړین ترتیب کې تنظیم کیدی شي؛ دا د امر په اړه د معلوماتو تبادلې لپاره د جلا چینل په کارولو سره پلي کیږي. مګر موږ لا تر اوسه دا طریقه نه کاروو: دا ټوله پروسه پیچلې کوي، او په یو شمیر حلونو کې دا په بشپړ ډول نه ملاتړ کیږي. برسېره پردې، هره معامله باید د ورته مهال ویش ټاکل شوي وي، او زموږ په سکیم کې دا میکانیزم په سمه توګه پلي کول خورا ستونزمن دي. له همدې امله ، موږ د پیغام بروکر سره کلاسیک سکیم کارولی ، دا د لیږونکي سره چې د خطر انجن ترمینځ پیغامونه توزیع کوي.
دویمه ستونزه د پیرودونکي لاسرسي پورې اړوند وه: که چیرې د خطر ډیری دروازې شتون ولري ، پیرودونکي اړتیا لري هر یو سره وصل شي ، او دا به د پیرودونکي پرت کې بدلونونو ته اړتیا ولري. موږ غوښتل پدې مرحله کې له دې څخه لیرې شو، نو د اوسني خطر ګیټ وے ډیزاین ټول ډیټا جریان پروسس کوي. دا په پراخه کچه د اعظمي تولید محدودوي، مګر د سیسټم ادغام خورا ساده کوي.
نقل کول
زموږ سیسټم باید د ناکامۍ یو ټکی ونه لري، دا دی، ټولې برخې باید نقل شي، په شمول د پیغام بروکر. موږ دا ستونزه د CLLM سیسټم په کارولو سره حل کړه: دا د RCMS کلستر لري په کوم کې چې دوه لیږونکي کولی شي د ماسټر غلام حالت کې کار وکړي، او کله چې یو ناکام شي، سیسټم په اتوماتيک ډول بل ته بدلیږي.
د بیک اپ ډیټا مرکز سره کار کول
InfiniBand د محلي شبکې په توګه د عملیاتو لپاره مطلوب دی، دا د ریک ماونټ تجهیزاتو سره نښلولو لپاره، او د InfiniBand شبکه نشي کولی د دوو جغرافیایي ویشل شوي ډیټا مرکزونو ترمنځ ځای پرځای شي. له همدې امله، موږ یو پل / لیږونکی پلي کړ، کوم چې د منظم ایترنیټ شبکې له لارې د پیغام ذخیره کولو سره نښلوي او ټولې لیږدونه د دویم IB شبکې ته رسوي. کله چې موږ د ډیټا مرکز څخه مهاجرت ته اړتیا لرو، موږ کولی شو د کوم ډیټا مرکز سره اوس کار وکړو.
پایلې
پورتني ټول په یو وخت کې ندي ترسره شوي؛ دا د نوي معمارۍ رامینځته کولو ډیری تکرارونه اخیستي. موږ په یوه میاشت کې پروټوټایپ جوړ کړ، مګر د کار حالت ته د رسیدو لپاره یې له دوو کلونو څخه زیات وخت واخیست. موږ هڅه وکړه چې د راکړې ورکړې پروسس کولو وخت زیاتولو او د سیسټم اعتبار زیاتولو ترمنځ غوره جوړجاړی ترلاسه کړو.
څرنګه چې سیسټم په پراخه کچه تازه شوی و، موږ د دوو خپلواکو سرچینو څخه د معلوماتو بیا رغونه پلي کړه. که د پیغام پلورنځی د کوم دلیل لپاره سم کار نه کوي، تاسو کولی شئ د لیږد لاګ له دویمې سرچینې څخه واخلئ - د خطر انجن څخه. دا اصول په ټول سیسټم کې لیدل کیږي.
د نورو شیانو په مینځ کې، موږ د مراجعینو API ساتلو توان درلود ترڅو نه بروکران او نه بل څوک د نوي جوړښت لپاره د پام وړ بیا کار ته اړتیا ولري. موږ باید ځینې انٹرفیسونه بدل کړو، مګر په عملیاتي ماډل کې د پام وړ بدلونونو ته اړتیا نشته.
موږ د خپل پلیټ فارم اوسنۍ نسخه Rebus ته وایو - په معمارۍ کې د دوه خورا پام وړ نوښتونو لپاره د لنډیز په توګه ، د خطر انجن او BUS.
په پیل کې، موږ غوښتل یوازې د پاکولو برخه تخصیص کړو، مګر پایله یې یو لوی ویشل شوی سیسټم و. پیرودونکي اوس کولی شي د سوداګرۍ دروازې، د پاکولو دروازې، یا دواړو سره اړیکه ونیسي.
هغه څه چې موږ په نهایت کې ترلاسه کړل:
د ځنډ کچه راټیټه کړه. د لیږد لږ مقدار سره، سیسټم د پخوانۍ نسخې په څیر کار کوي، مګر په ورته وخت کې کولی شي د ډیر لوړ بار سره مقاومت وکړي.
لوړ فعالیت په هره ثانیه کې له 50 زره څخه 180 زره لیږد ته لوړ شوی. یو بل زیاتوالی د نظم د سمون یوازینۍ جریان لخوا خنډ کیږي.
د لا ښه والي لپاره دوه لارې شتون لري: موازي کول او د ګیټ وے سره د کار کولو طریقه بدلول. اوس ټولې دروازې د نقل کولو سکیم سره سم کار کوي، کوم چې د داسې بار لاندې، په نورمال ډول فعالیت بندوي.
په نهایت کې ، زه کولی شم هغو کسانو ته یو څه مشوره ورکړم چې د تصدۍ سیسټم نهایی کوي:
- هر وخت د بدترین لپاره چمتو اوسئ. ستونزې تل په ناڅاپي ډول رامنځته کیږي.
- دا معمولا ناشونې ده چې ژر تر ژره د معمارۍ بیا جوړونه. په ځانګړي توګه که تاسو اړتیا لرئ په ډیری شاخصونو کې اعظمي اعتبار ترلاسه کړئ. څومره نور نوډونه، د ملاتړ لپاره ډیرو سرچینو ته اړتیا ده.
- ټول دودیز او ملکیت حلونه به د څیړنې، ملاتړ او ساتنې لپاره اضافي سرچینو ته اړتیا ولري.
- د ناکامۍ وروسته د سیسټم اعتبار او بیا رغولو مسلو حل کول مه ځنډوئ؛ د ډیزاین لومړني مرحله کې یې په پام کې ونیسئ.
سرچینه: www.habr.com