اې حبره!

د کورونویرس له امله د اوسنیو پیښو په رڼا کې، یو شمیر انټرنیټي خدماتو ډیر بار ترلاسه کول پیل کړي. د مثال په ډول، د انګلستان پرچون زنځیرونو څخه یو په ساده ډول خپل آنلاین امر کولو سایټ بند کړ.ځکه کافي ظرفیت نه درلود. او دا تل امکان نلري چې په ساده ډول د نورو پیاوړو تجهیزاتو په اضافه کولو سره سرور ګړندی کړئ ، مګر د پیرودونکي غوښتنې باید پروسس شي (یا دوی به سیالانو ته لاړ شي).

پدې مقاله کې به زه په لنډه توګه د مشهورو کړنو په اړه وغږیږم چې تاسو ته به اجازه درکړي چې ګړندي او د غلطۍ زغم خدمت رامینځته کړئ. په هرصورت، د ممکنه پرمختیایي سکیمونو څخه، ما یوازې هغه غوره کړل چې اوس مهال دي کارول اسانه دي. د هر توکي لپاره، تاسو یا هم چمتو شوي کتابتونونه لرئ، یا تاسو د کلاوډ پلیټ فارم په کارولو سره د ستونزې حل کولو فرصت لرئ.

افقی اندازه کول

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

د مثال په توګه ، زه به د بادل فایل ذخیره خلاص کړم ، دا د OwnCloud ، OneDrive ، او داسې نور ځینې انلاګونه دي.

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

د طریقو ترمنځ توپیر: په عمودی اندازه کولو کې، موږ چمتو یو چې د نوډونو ځواک زیات کړو، او په افقی پیمانه کې، موږ چمتو یو چې د بار ویشلو لپاره نوي نوډونه اضافه کړو.

CQRS

د پوښتنې د مسؤلیت جلا کولو قوماندې یو خورا مهم نمونه ، ځکه چې دا مختلف پیرودونکو ته اجازه ورکوي نه یوازې مختلف خدماتو سره وصل شي ، بلکه د ورته پیښې جریان ترلاسه کړي. د دې ګټې د ساده غوښتنلیک لپاره دومره څرګند ندي ، مګر دا د بوخت خدمت لپاره خورا مهم (او ساده) دی. د دې جوهر: راتلونکی او بهر ته د معلوماتو جریان باید سره یو ځای نشي. دا دی، تاسو نشئ کولی غوښتنه واستوئ او د ځواب تمه وکړئ؛ پرځای یې، تاسو خدمت A ته غوښتنه لیږئ، مګر د B خدمت څخه ځواب ترلاسه کوئ.

د دې تګلارې لومړی بونس د اوږدې غوښتنې پلي کولو پرمهال د اړیکې ماتولو وړتیا ده (د کلمې په پراخه معنی کې). د مثال په توګه، راځئ چې لږ یا لږ معیاري ترتیب واخلو:

پیرودونکي سرور ته غوښتنه لیږلې.
سرور اوږد پروسس وخت پیل کړ.
سرور د پایلې سره پیرودونکي ته ځواب ورکړ.

راځئ تصور وکړو چې په 2 نقطه کې پیوستون مات شو (یا شبکه بیا وصل شوه، یا کاروونکي بلې پاڼې ته لاړ، پیوستون مات شو). په دې حالت کې، دا به د سرور لپاره ستونزمن وي چې کاروونکي ته د هغه څه په اړه معلومات سره ځواب واستوي چې په ریښتیا پروسس شوي. د CQRS په کارولو سره، ترتیب به یو څه توپیر ولري:

پیرودونکي د تازه معلوماتو لپاره ګډون کړی دی.
پیرودونکي سرور ته غوښتنه لیږلې.
سرور ځواب ورکړ "غوښتنه منل شوې."
سرور د "1" نقطې څخه د چینل له لارې پایلې سره ځواب ورکړ.

لکه څنګه چې تاسو لیدلی شئ، سکیم یو څه ډیر پیچلی دی. برسېره پردې، د ارادې غوښتنې ځواب چلند دلته ورک دی. په هرصورت ، لکه څنګه چې تاسو لیدلی شئ ، د غوښتنې پروسس کولو پرمهال د پیوستون ماتول به د خطا لامل نشي. سربیره پردې ، که چیرې واقعیا کارونکي د ډیری وسیلو څخه خدمت سره وصل وي (د مثال په توګه ، د ګرځنده تلیفون او ټابلیټ څخه) ، تاسو کولی شئ ډاډ ترلاسه کړئ چې ځواب دواړه وسیلو ته راځي.

په زړه پورې خبره دا ده چې د راتلونکو پیغامونو پروسس کولو لپاره کوډ یو شان کیږي (نه 100٪) دواړه د پیښو لپاره چې پخپله د پیرودونکي لخوا اغیزمن شوي، او د نورو پیښو لپاره، په شمول د نورو پیرودونکو څخه.

په هرصورت ، په حقیقت کې موږ د دې حقیقت له امله اضافي بونس ترلاسه کوو چې غیر مستقیم جریان په فعال سټایل کې اداره کیدی شي (د RX او ورته کارول). او دا دمخه یو جدي پلس دی ، ځکه چې په اصل کې غوښتنلیک په بشپړ ډول عکس العمل رامینځته کیدی شي ، او همدارنګه د فعال چلند په کارولو سره. د غوړ برنامو لپاره، دا کولی شي د پام وړ پراختیا او مالتړ سرچینې خوندي کړي.

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

د پیښې سرچینې

لکه څنګه چې تاسو پوهیږئ، د ویشل شوي سیسټم یو له اصلي ځانګړتیاوو څخه د ګډ وخت نشتوالی، د یوې ګډې مهمې برخې نشتوالی دی. د یوې پروسې لپاره ، تاسو کولی شئ همغږي وکړئ (په ورته متیکسونو کې) ، په کوم کې چې تاسو ډاډه یاست چې بل څوک دا کوډ نه پلي کوي. په هرصورت، دا د ویشل شوي سیسټم لپاره خطرناک دی، ځکه چې دا به سر ته اړتیا ولري، او د پیمان کولو ټول ښکلا به هم ووژني - ټولې برخې به لاهم یو ته انتظار وکړي.

له دې ځایه موږ یو مهم حقیقت ترلاسه کوو - یو ګړندی توزیع شوی سیسټم نشي کولی همغږي شي ، ځکه چې بیا به موږ فعالیت کم کړو. له بلې خوا، موږ ډیری وختونه د اجزاوو ترمنځ یو مشخص ثبات ته اړتیا لرو. او د دې لپاره تاسو کولی شئ دا طریقه وکاروئ حتمي ثبات، چیرې چې دا تضمین شوی چې که چیرې د وروستي تازه کولو وروسته د ځینې مودې لپاره د معلوماتو بدلون نه وي ("په پای کې") ، ټولې پوښتنې به وروستی تازه شوي ارزښت بیرته راستانه کړي.

دا مهمه ده چې پوه شئ چې د کلاسیک ډیټابیسونو لپاره دا ډیری وختونه کارول کیږي قوي ثبات، چیرې چې هر نوډ ورته معلومات لري (دا اکثرا په هغه حالت کې ترلاسه کیږي چیرې چې معامله یوازې د دوهم سرور ځواب ویلو وروسته رامینځته کیږي). دلته د انزوا کچې له امله ځینې آرامۍ شتون لري ، مګر عمومي نظر ورته پاتې دی - تاسو کولی شئ په بشپړ ډول همغږي نړۍ کې ژوند وکړئ.

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

د دې طریقې مهمې ځانګړتیاوې:

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

اجازه راکړئ تاسو ته یادونه وکړم چې موږ د آنلاین فایل ذخیره کولو قضیه په پام کې نیسو. په دې حالت کې، سیسټم به داسې ښکاري:

دا مهمه ده چې په ډیاګرام کې خدمتونه د جلا سرور معنی نلري. حتی پروسه ممکن ورته وي. بله مهمه خبره دا ده: په نظریاتي توګه، دا شیان په داسې ډول جلا شوي چې افقی پیمانه په اسانۍ سره پلي کیدی شي.

او د دوه کاروونکو لپاره ډیاګرام به داسې ښکاري (خدمتونه چې د مختلف کاروونکو لپاره په مختلف رنګونو کې ښودل شوي):

د دې ډول ترکیب څخه بونس:

د معلوماتو پروسس کولو خدمتونه جلا شوي دي. کتارونه هم جلا شوي دي. که موږ اړتیا لرو چې د سیسټم انډول زیات کړو، نو موږ اړتیا لرو چې په ډیرو سرورونو کې نور خدمتونه پیل کړو.
کله چې موږ د یو کارونکي څخه معلومات ترلاسه کوو، موږ اړتیا نلرو تر هغه چې ډاټا په بشپړه توګه خوندي شي. برعکس، موږ یوازې د "ښه" ځواب ته اړتیا لرو او بیا په تدریجي توګه کار پیل کوو. په ورته وخت کې ، کتار د چوکیو څخه خلاصیږي ، ځکه چې د نوي شی اضافه کول په چټکۍ سره پیښیږي ، او کارونکي اړتیا نلري د ټول دورې له لارې بشپړ پاس ته انتظار وکړي.
د مثال په توګه ، ما د نقل کولو خدمت اضافه کړ چې د ورته فایلونو ضمیمه کولو هڅه کوي. که دا په 1٪ قضیو کې د اوږدې مودې لپاره کار وکړي، پیرودونکي به په سختۍ سره دا په پام کې ونیسي (پورته وګورئ)، کوم چې یو لوی پلس دی، ځکه چې موږ نور اړتیا نه لرو چې XNUMX٪ سرعت او د اعتماد وړ وي.

په هرصورت، زیانونه په چټکۍ سره لیدل کیږي:

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

لکه څنګه چې تاسو لیدلی شئ، د پیښې سرچینې د CQRS سره ښه کار کوي. سربیره پردې ، د مؤثره او مناسب کتارونو سره د سیسټم پلي کول ، مګر د معلوماتو جریان جلا کولو پرته ، پخپله پخپله ستونزمن کار دی ، ځکه چې تاسو باید د همغږي کولو ټکي اضافه کړئ چې د قطارونو بشپړ مثبت تاثیر به بې طرفه کړي. په یوځل کې د دواړو طریقو پلي کول، دا اړینه ده چې د پروګرام کوډ لږ څه تنظیم کړئ. زموږ په قضیه کې، کله چې سرور ته فایل لیږل کیږي، ځواب یوازې "ښه" راځي، چې یوازې دا معنی لري چې "د فایل اضافه کولو عملیات خوندي شوي." په رسمي توګه، دا پدې معنی ندي چې ډاټا لا دمخه په نورو وسیلو کې شتون لري (د مثال په توګه، د نقل کولو خدمت کولی شي شاخص بیا جوړ کړي). په هرصورت، د یو څه وخت وروسته، پیرودونکي به د "فایل ایکس خوندي شوی" په بڼه یو خبرتیا ترلاسه کړي.

په پایله کښې:

د فایل لیږلو حالتونو شمیر مخ په ډیریدو دی: د کلاسیک "دوتنه لیږل شوي" پرځای موږ دوه ترلاسه کوو: "دوتنه په سرور کې قطار ته اضافه شوې" او "دوتنه په ذخیره کې خوندي شوې." وروستنۍ معنی دا ده چې نور وسایل کولی شي دمخه د فایل ترلاسه کول پیل کړي (د دې حقیقت لپاره تنظیم شوی چې کتارونه په مختلف سرعت سره کار کوي).
د دې حقیقت له امله چې د سپارلو معلومات اوس د مختلف چینلونو له لارې راځي، موږ اړتیا لرو د فایل پروسس حالت ترلاسه کولو لپاره د حلونو سره راشي. د دې په پایله کې: د کلاسیک غوښتنې ځواب برعکس ، پیرودونکي د فایل پروسس کولو پرمهال له سره پیل کیدی شي ، مګر پخپله د دې پروسس حالت به سم وي. سربیره پردې ، دا توکي په اصل کې د بکس څخه بهر کار کوي. د پایلې په توګه: موږ اوس د ناکامۍ ډیر زغم لرو.

شریکول

لکه څنګه چې پورته تشریح شوي، د پیښو سرچینې سیسټمونه سخت ثبات نلري. دا پدې مانا ده چې موږ کولی شو ډیری ذخیره وکاروو پرته لدې چې د دوی ترمینځ همغږي شي. زموږ ستونزې ته رسیدو سره، موږ کولی شو:

د ډول له مخې فایلونه جلا کړئ. د مثال په توګه، عکسونه/ویډیوګانې ډیکوډ کیدی شي او یو ډیر مؤثره بڼه غوره کیدی شي.
د هیواد لخوا جلا حسابونه. د ډیری قوانینو له امله، دا ممکن اړین وي، مګر دا د جوړښت سکیم په اتوماتيک ډول ورته فرصت چمتو کوي

که تاسو غواړئ ډاټا له یو ذخیره څخه بل ته انتقال کړئ، نو معیاري وسیله نور کافي ندي. له بده مرغه، پدې حالت کې، تاسو اړتیا لرئ چې قطار ودروئ، مهاجرت وکړئ، او بیا یې پیل کړئ. په عمومي حالت کې، ډاټا نشي لیږدول کیدی "په الوتنه کې"، په هرصورت، که چیرې د پیښې کتار په بشپړه توګه ذخیره شوی وي، او تاسو د پخوانیو ذخیره کولو حالتونو عکسونه لرئ، نو موږ کولی شو پیښې په لاندې ډول بیا پیل کړو:

د پیښې سرچینې کې، هره پیښه خپل پیژندونکی لري (په مثالي توګه، غیر کمیدل). دا پدې مانا ده چې موږ کولی شو ذخیره کې ساحه اضافه کړو - د وروستي پروسس شوي عنصر ID.
موږ قطار نقل کوو ترڅو ټولې پیښې د څو خپلواکو ذخیرو لپاره پروسس شي (لومړی هغه دی چې معلومات یې دمخه زیرمه شوي ، او دوهم یې نوی دی ، مګر لاهم خالي دی). دوهم کتار، البته، لا تر اوسه پروسس شوی نه دی.
موږ دوهم کتار پیل کوو (دا دی ، موږ د پیښو بیا پیلول پیل کوو).
کله چې نوی کتار نسبتا خالي وي (دا د عنصر اضافه کولو او ترلاسه کولو تر مینځ د اوسط وخت توپیر د منلو وړ دی)، تاسو کولی شئ نوي ذخیره ته د لوستونکو بدلول پیل کړئ.

لکه څنګه چې تاسو لیدلی شئ، موږ په خپل سیسټم کې سخت ثبات نه درلود، او اوس هم نه لرو. یوازې د پیښې ثبات شتون لري، دا یو تضمین دی چې پیښې په ورته ترتیب کې پروسس کیږي (مګر ممکن د مختلف ځنډونو سره). او، د دې په کارولو سره، موږ کولی شو په نسبتا اسانۍ سره د سیسټم د بندولو پرته د نړۍ بل لوري ته ډاټا انتقال کړو.

پدې توګه ، د آنلاین فایل ذخیره کولو په اړه زموږ مثال ته دوام ورکول ، دا ډول جوړښت دمخه موږ ته یو شمیر بونس راکوي:

موږ کولی شو شیان په متحرک ډول کاروونکو ته نږدې کړو. پدې توګه تاسو کولی شئ د خدماتو کیفیت ښه کړئ.
موږ ممکن په شرکتونو کې ځینې معلومات ذخیره کړو. د مثال په توګه، د تصدۍ کاروونکي اکثرا اړتیا لري چې خپل معلومات د کنټرول شوي ډیټا مرکزونو کې زیرمه کړي (د ډیټا لیک څخه مخنیوي لپاره). د شارډینګ له لارې موږ کولی شو په اسانۍ سره د دې ملاتړ وکړو. او دا کار حتی ساده دی که چیرې پیرودونکي مناسب بادل ولري (د مثال په توګه، Azure پخپله کوربه دی).
او ترټولو مهمه خبره دا ده چې موږ باید دا کار ونه کړو. په هرصورت، د پیل کولو لپاره، موږ به د ټولو حسابونو لپاره د یو ذخیره کولو سره خورا خوښ یو (د چټک کار پیل کولو لپاره). او د دې سیسټم کلیدي ځانګړتیا دا ده چې که څه هم دا د پراختیا وړ دی، په لومړي پړاو کې دا خورا ساده دی. تاسو اړتیا نلرئ سمدلاسه کوډ ولیکئ چې د ملیون جلا خپلواک کتارونو سره کار کوي ، او داسې نور. که اړتیا وي، دا په راتلونکي کې ترسره کیدی شي.

د جامد منځپانګې کوربه کول

دا ټکی ممکن خورا څرګند ښکاري ، مګر دا لاهم د ډیر یا لږ معیاري بار شوي غوښتنلیک لپاره اړین دی. د دې جوهر ساده دی: ټول جامد مینځپانګه د ورته سرور څخه نه ویشل کیږي چیرې چې غوښتنلیک موقعیت لري ، مګر د ځانګړي څخه چې په ځانګړي توګه دې دندې ته وقف شوي. د پایلې په توګه، دا عملیات ګړندي ترسره کیږي (مشروط نګینکس د جاوا سرور په پرتله ډیر ګړندي او لږ ګران فایلونه وړاندې کوي). پلس د CDN جوړښت (د مینځپانګې رسولو شبکه) موږ ته اجازه راکوي چې خپل فایلونه پای کاروونکو ته نږدې ومومئ، کوم چې د خدمت سره د کار کولو اسانتیا باندې مثبت اغیزه لري.

د جامد مینځپانګې ترټولو ساده او خورا معیاري مثال د ویب پا forې لپاره د سکریپټونو او عکسونو سیټ دی. د دوی سره هرڅه ساده دي - دوی دمخه پیژندل شوي ، بیا آرشیف د CDN سرورونو ته اپلوډ کیږي ، له هغه ځایه دوی پای کاروونکو ته توزیع کیږي.

په هرصورت، په واقعیت کې، د جامد مینځپانګې لپاره، تاسو کولی شئ د لامبډا معمارۍ ته یو څه ورته طریقه وکاروئ. راځئ چې بیرته خپل کار (آنلاین فایل ذخیره) ته ورشو، په کوم کې چې موږ کاروونکو ته د فایلونو ویشلو ته اړتیا لرو. ترټولو ساده حل د داسې خدمت رامینځته کول دي چې د هر کارونکي غوښتنې لپاره ټول اړین چکونه (اجازه ورکول ، او نور) کوي ، او بیا فایل مستقیم زموږ له ذخیره څخه ډاونلوډ کوي. د دې تګلارې اصلي زیان دا دی چې جامد مینځپانګه (او د یو ځانګړي بیاکتنې سره فایل په حقیقت کې جامد مینځپانګه ده) د ورته سرور لخوا توزیع کیږي چې د سوداګرۍ منطق لري. پرځای یې، تاسو کولی شئ لاندې انځور جوړ کړئ:

سرور د ډاونلوډ URL چمتو کوي. دا کیدای شي د فایل_id + کیلي بڼه وي، چیرې چې کیلي یو کوچنی ډیجیټل لاسلیک دی چې د راتلونکو XNUMX ساعتونو لپاره سرچینې ته د لاسرسي حق ورکوي.
فایل د ساده نګینکس لخوا د لاندې اختیارونو سره ویشل شوی:
- د مینځپانګې کیچ کول. څرنګه چې دا خدمت په جلا سرور کې موقعیت لري، موږ خپل ځان د راتلونکي لپاره په ډیسک کې د ټولو وروستي ډاونلوډ شوي فایلونو ذخیره کولو وړتیا سره پریږدو.
- د پیوستون جوړولو په وخت کې کیلي چک کول
اختیاري: د مینځپانګې پروسس کول. د مثال په توګه، که موږ په خدمت کې ټول فایلونه کمپرس کړو، نو موږ کولی شو په مستقیم ډول په دې ماډل کې غیر زپ وکړو. د پایلې په توګه: د IO عملیات ترسره کیږي چیرې چې دوی تړاو لري. په جاوا کې آرشیور به په اسانۍ سره ډیری اضافي حافظې تخصیص کړي ، مګر د سوداګرۍ منطق سره په Rust/C++ شرایطو کې د خدمت بیا لیکل ممکن هم غیر مؤثر وي. زموږ په قضیه کې، مختلف پروسې (یا حتی خدمتونه) کارول کیږي، او له همدې امله موږ کولی شو په مؤثره توګه د سوداګرۍ منطق او IO عملیات جلا کړو.

دا سکیم د جامد مینځپانګې توزیع کولو سره ورته نه دی (ځکه چې موږ بشپړ جامد کڅوړه په کوم ځای کې نه اپلوډ کوو) ، مګر په حقیقت کې ، دا طریقه دقیقا د بدلیدونکي ډیټا ویشلو پورې اړه لري. سربیره پردې ، دا سکیم نورو قضیو ته عمومي کیدی شي چیرې چې مینځپانګه یوازې جامد نه وي ، مګر د بدلیدونکي او نه حذف کیدو بلاکونو سیټ په توګه ښودل کیدی شي (که څه هم دوی اضافه کیدی شي).

د بل مثال په توګه (د تقویه کولو لپاره): که تاسو د جینکنز/TeamCity سره کار کړی وي، نو تاسو پوهیږئ چې دواړه حلونه په جاوا کې لیکل شوي. دا دواړه د جاوا پروسه ده چې دواړه د آرکیسټریشن او مینځپانګې مدیریت اداره کوي. په ځانګړې توګه، دوی دواړه دندې لري لکه "د سرور څخه د فایل / فولډر لیږد." د مثال په توګه: د هنري اثارو صادرول، د سرچینې کوډ لیږدول (کله چې اجنټ کوډ په مستقیم ډول د ذخیره کولو څخه ډاونلوډ نه کړي، مګر سرور یې د هغه لپاره کوي)، لاګونو ته لاسرسی. دا ټولې دندې د دوی په IO بار کې توپیر لري. دا دی، دا معلومه شوه چې سرور د پیچلي سوداګرۍ منطق لپاره مسؤل دی باید په ورته وخت کې د دې وړتیا ولري چې د خپل ځان له لارې د ډیټا لوی جریان په مؤثره توګه فشار راوړي. او هغه څه چې خورا په زړه پوري دي دا دي چې دا ډول عملیات د ورته سکیم مطابق ورته نینګکس ته سپارل کیدی شي (پرته له دې چې د ډیټا کیلي باید غوښتنې ته اضافه شي).

په هرصورت، که موږ خپل سیسټم ته راستانه شو، موږ ورته انځور ترلاسه کوو:

لکه څنګه چې تاسو لیدلی شئ، سیسټم خورا پیچلی شوی دی. اوس دا یوازې یو کوچنی پروسه نه ده چې فایلونه په ځایی توګه ذخیره کوي. اوس هغه څه ته اړتیا ده چې ساده ملاتړ نه دی، د API نسخه کنټرول، او داسې نور. له همدې امله، وروسته له دې چې ټول ډیاګرامونه رسم شوي، دا غوره ده چې په تفصیل سره و ارزول شي چې ایا توسع کول د لګښت ارزښت لري. په هرصورت، که تاسو غواړئ سیسټم پراخ کړئ (پشمول د ډیرو کاروونکو سره کار کول)، نو تاسو باید د ورته حلونو لپاره لاړ شئ. مګر، د پایلې په توګه، سیسټم په معمارۍ کې د زیاتوالي لپاره چمتو دی (تقریبا هره برخه د افقی اندازه کولو لپاره کلون کیدی شي). سیسټم د بندیدو پرته تازه کیدی شي (په ساده ډول ځینې عملیات به یو څه ورو شي).

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

پایلې

دا ټولې لارې مخکې پیژندل شوې وې. ورته VK له اوږدې مودې راهیسې د عکسونو ښودلو لپاره د جامد مینځپانګې کوربه توب مفکوره کاروي. ډیری آنلاین لوبې د لوبغاړو ویشلو یا د لوبې ځایونو جلا کولو لپاره د شارډینګ سکیم کاروي (که نړۍ پخپله یوه وي). د پیښې سرچینې طریقه په فعاله توګه په بریښنالیک کې کارول کیږي. ډیری سوداګریز غوښتنلیکونه چیرې چې ډاټا په دوامداره توګه ترلاسه کیږي په حقیقت کې د CQRS طریقې باندې جوړ شوي ترڅو ترلاسه شوي ډاټا فلټر کړي. ښه، افقی اندازه کول د اوږدې مودې لپاره په ډیری خدماتو کې کارول شوي.

په هرصورت، ترټولو مهم، دا ټولې نمونې په عصري غوښتنلیکونو کې پلي کول خورا اسانه شوي (که دوی مناسب وي، البته). بادل سمدلاسه د شارډینګ او افقی اندازه کولو وړاندیز کوي ، کوم چې پخپله په مختلف ډیټا مرکزونو کې د مختلف وقف شوي سرورونو امر کولو څخه خورا اسانه دی. CQRS خورا اسانه شوی ، که یوازې د RX په څیر د کتابتونونو پراختیا له امله. شاوخوا 10 کاله دمخه، یو نادر ویب پاڼه د دې ملاتړ کولی شي. د پیښې سرچینې د اپاچی کافکا سره د چمتو شوي کانټینرونو څخه مننه تنظیم کول خورا په زړه پوري اسانه دي. 10 کاله وړاندې به دا یو نوښت و، اوس دا معمول دی. دا د جامد مینځپانګې کوربه توب سره ورته دی: د خورا اسانه ټیکنالوژیو له امله (د حقیقت په شمول چې مفصل اسناد او د ځوابونو لوی ډیټابیس شتون لري) ، دا طریقه نوره هم ساده شوې.

د پایلې په توګه، د یو شمیر پیچلي معماري نمونو پلي کول اوس خورا ساده شوي، پدې معنی چې دا غوره ده چې مخکې له دې نږدې نږدې کتنه وکړو. که په لس کلن غوښتنلیک کې پورته حلونو څخه یو یې د پلي کولو او عملیاتو د لوړ لګښت له امله پریښودل شوی و ، اوس ، په نوي غوښتنلیک کې ، یا د ریفکتور کولو وروسته ، تاسو کولی شئ داسې خدمت رامینځته کړئ چې دمخه به په معماري ډول دواړه توزیع کیدی شي ( د فعالیت په شرایطو کې) او د پیرودونکو څخه نوي غوښتنو ته چمتو شوي (د مثال په توګه ، د شخصي معلوماتو ځایی کولو لپاره).

او تر ټولو مهم: مهرباني وکړئ دا طریقې مه کاروئ که تاسو ساده غوښتنلیک لرئ. هو ، دا ښکلي او په زړه پوري دي ، مګر د یوې سایټ لپاره چې د 100 خلکو لوړ لید سره ، تاسو ډیری وختونه د کلاسیک مونولیت سره ترلاسه کولی شئ (لږترلږه په بهر کې ، دننه هرڅه په ماډلونو ویشل کیدی شي ، او داسې نور).

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

مناسب معماري نمونې