ارے حبر!
کورونا وائرس کی وجہ سے موجودہ واقعات کی روشنی میں انٹرنیٹ کی متعدد سروسز پر بوجھ بڑھنا شروع ہو گیا ہے۔ مثال کے طور پر، کیونکہ کافی صلاحیت نہیں تھی۔ اور یہ ہمیشہ ممکن نہیں ہوتا کہ کسی سرور کو صرف زیادہ طاقتور آلات شامل کرکے تیز کیا جائے، لیکن کلائنٹ کی درخواستوں پر کارروائی ہونی چاہیے (یا وہ حریفوں کے پاس جائیں گی)۔
اس مضمون میں میں مختصر طور پر مقبول طریقوں کے بارے میں بات کروں گا جو آپ کو ایک تیز رفتار اور غلطی برداشت کرنے والی سروس بنانے کی اجازت دیں گے۔ تاہم، ممکنہ ترقیاتی اسکیموں میں سے، میں نے صرف وہی منتخب کیا جو اس وقت ہیں۔ استعمال میں آسان. ہر آئٹم کے لیے، یا تو آپ کے پاس ریڈی میڈ لائبریریاں ہیں، یا آپ کے پاس کلاؤڈ پلیٹ فارم کا استعمال کرکے مسئلہ حل کرنے کا موقع ہے۔
افقی اسکیلنگ
سب سے آسان اور سب سے مشہور نقطہ۔ روایتی طور پر، لوڈ کی تقسیم کی سب سے عام دو اسکیمیں افقی اور عمودی اسکیلنگ ہیں۔ آپ خدمات کو متوازی طور پر چلانے کی اجازت دیتے ہیں، اس طرح ان کے درمیان بوجھ تقسیم ہوتا ہے۔ آپ زیادہ طاقتور سرور آرڈر کرتے ہیں یا کوڈ کو بہتر بناتے ہیں۔
مثال کے طور پر، میں خلاصہ کلاؤڈ فائل سٹوریج لوں گا، یعنی OwnCloud، OneDrive وغیرہ کے کچھ اینالاگ۔
اس طرح کے سرکٹ کی ایک معیاری تصویر نیچے ہے، لیکن یہ صرف نظام کی پیچیدگی کو ظاہر کرتی ہے۔ سب کے بعد، ہمیں کسی نہ کسی طرح خدمات کو مطابقت پذیر کرنے کی ضرورت ہے. اگر صارف ٹیبلیٹ سے فائل محفوظ کرتا ہے اور پھر اسے فون سے دیکھنا چاہتا ہے تو کیا ہوگا؟
نقطہ نظر کے درمیان فرق: عمودی اسکیلنگ میں، ہم نوڈس کی طاقت بڑھانے کے لیے تیار ہیں، اور افقی اسکیلنگ میں، ہم بوجھ کو تقسیم کرنے کے لیے نئے نوڈس شامل کرنے کے لیے تیار ہیں۔
CQRS
ایک بہت اہم نمونہ، کیونکہ یہ مختلف کلائنٹس کو نہ صرف مختلف سروسز سے منسلک ہونے کی اجازت دیتا ہے، بلکہ ایک ہی ایونٹ کے سلسلے کو بھی حاصل کر سکتا ہے۔ اس کے فوائد ایک سادہ ایپلیکیشن کے لیے اتنے واضح نہیں ہیں، لیکن یہ ایک مصروف سروس کے لیے انتہائی اہم (اور آسان) ہے۔ اس کا جوہر: آنے والے اور جانے والے ڈیٹا کے بہاؤ کو آپس میں نہیں ہونا چاہیے۔ یعنی، آپ درخواست نہیں بھیج سکتے اور جواب کی توقع نہیں کر سکتے؛ اس کے بجائے، آپ سروس A کو درخواست بھیجتے ہیں، لیکن سروس B سے جواب موصول ہوتا ہے۔
اس نقطہ نظر کا پہلا بونس ایک طویل درخواست پر عمل کرتے ہوئے کنکشن (لفظ کے وسیع معنی میں) کو توڑنے کی صلاحیت ہے۔ مثال کے طور پر، آئیے کم و بیش معیاری ترتیب لیتے ہیں:
- کلائنٹ نے سرور کو ایک درخواست بھیجی۔
- سرور نے ایک طویل پروسیسنگ کا وقت شروع کیا۔
- سرور نے نتیجہ کے ساتھ کلائنٹ کو جواب دیا۔
آئیے تصور کریں کہ پوائنٹ 2 میں کنکشن ٹوٹ گیا تھا (یا نیٹ ورک دوبارہ منسلک ہو گیا تھا، یا صارف کنکشن کو توڑ کر کسی دوسرے صفحے پر چلا گیا تھا)۔ اس صورت میں، سرور کے لیے صارف کو اس بارے میں معلومات کے ساتھ جواب بھیجنا مشکل ہو جائے گا کہ اصل میں کیا کارروائی ہوئی تھی۔ CQRS کا استعمال کرتے ہوئے، ترتیب قدرے مختلف ہوگی:
- کلائنٹ نے اپ ڈیٹس کو سبسکرائب کیا ہے۔
- کلائنٹ نے سرور کو ایک درخواست بھیجی۔
- سرور نے جواب دیا "درخواست قبول کر لی گئی۔"
- سرور نے نقطہ "1" سے چینل کے ذریعے نتیجہ کے ساتھ جواب دیا۔
جیسا کہ آپ دیکھ سکتے ہیں، اسکیم تھوڑی زیادہ پیچیدہ ہے۔ مزید یہ کہ، بدیہی درخواست کے جواب کا نقطہ نظر یہاں غائب ہے۔ تاہم، جیسا کہ آپ دیکھ سکتے ہیں، درخواست پر کارروائی کے دوران کنکشن ٹوٹنے سے غلطی نہیں ہوگی۔ مزید برآں، اگر حقیقت میں صارف کئی ڈیوائسز سے سروس سے منسلک ہے (مثال کے طور پر، موبائل فون اور ٹیبلیٹ سے)، تو آپ اس بات کو یقینی بنا سکتے ہیں کہ جواب دونوں ڈیوائسز پر آتا ہے۔
دلچسپ بات یہ ہے کہ آنے والے پیغامات پر کارروائی کرنے کا کوڈ ایک جیسا ہو جاتا ہے (100% نہیں) دونوں واقعات کے لیے جو خود کلائنٹ سے متاثر ہوئے تھے، اور دیگر واقعات کے لیے، بشمول دوسرے کلائنٹس کے۔
تاہم، حقیقت میں ہمیں اس حقیقت کی وجہ سے ایک اضافی بونس ملتا ہے کہ یک سمت بہاؤ کو فنکشنل انداز میں (RX اور اسی طرح کا استعمال کرتے ہوئے) ہینڈل کیا جا سکتا ہے۔ اور یہ پہلے سے ہی ایک سنگین پلس ہے، کیونکہ اصل میں درخواست کو مکمل طور پر رد عمل بنایا جا سکتا ہے، اور ایک فعال نقطہ نظر کا استعمال کرتے ہوئے. چربی کے پروگراموں کے لیے، یہ ترقی اور معاون وسائل کو نمایاں طور پر بچا سکتا ہے۔
اگر ہم اس نقطہ نظر کو افقی اسکیلنگ کے ساتھ جوڑتے ہیں، تو بونس کے طور پر ہمیں ایک سرور کو درخواستیں بھیجنے اور دوسرے سے جوابات حاصل کرنے کی اہلیت ملتی ہے۔ اس طرح، کلائنٹ اس سروس کا انتخاب کر سکتا ہے جو اس کے لیے آسان ہو، اور اندر کا نظام اب بھی واقعات کو درست طریقے سے پروسیس کر سکے گا۔
ایونٹ سورسنگ
جیسا کہ آپ جانتے ہیں، تقسیم شدہ نظام کی اہم خصوصیات میں سے ایک مشترکہ وقت، مشترکہ تنقیدی حصے کی عدم موجودگی ہے۔ ایک عمل کے لیے، آپ ایک ہم وقت سازی کر سکتے ہیں (اسی mutexes پر)، جس کے اندر آپ کو یقین ہے کہ کوئی اور اس کوڈ پر عمل نہیں کر رہا ہے۔ تاہم، یہ تقسیم شدہ نظام کے لیے خطرناک ہے، کیونکہ اس کے لیے اوور ہیڈ کی ضرورت ہوگی، اور اسکیلنگ کی تمام خوبصورتی کو بھی ختم کردے گا - تمام اجزاء اب بھی ایک کا انتظار کریں گے۔
یہاں سے ہمیں ایک اہم حقیقت ملتی ہے - تیزی سے تقسیم شدہ نظام کو ہم آہنگ نہیں کیا جا سکتا، کیونکہ تب ہم کارکردگی کو کم کر دیں گے۔ دوسری طرف، ہمیں اکثر اجزاء کے درمیان ایک خاص مستقل مزاجی کی ضرورت ہوتی ہے۔ اور اس کے لئے آپ کے ساتھ نقطہ نظر استعمال کر سکتے ہیں ، جہاں اس بات کی ضمانت دی جاتی ہے کہ اگر آخری اپ ڈیٹ ("بالآخر") کے بعد کچھ عرصے کے لیے ڈیٹا میں کوئی تبدیلی نہیں ہوتی ہے، تو تمام استفسارات آخری اپ ڈیٹ شدہ قدر واپس کریں گے۔
یہ سمجھنا ضروری ہے کہ کلاسک ڈیٹا بیس کے لیے یہ اکثر استعمال ہوتا ہے۔ ، جہاں ہر نوڈ میں ایک جیسی معلومات ہوتی ہیں (یہ اکثر اس صورت میں حاصل ہوتا ہے جہاں دوسرے سرور کے جواب کے بعد ہی لین دین کو قائم سمجھا جاتا ہے)۔ تنہائی کی سطح کی وجہ سے یہاں کچھ نرمیاں ہیں، لیکن عام خیال وہی رہتا ہے - آپ مکمل طور پر ہم آہنگ دنیا میں رہ سکتے ہیں۔
بہرحال آئیے اصل کام کی طرف لوٹتے ہیں۔ اگر نظام کا حصہ بنایا جا سکتا ہے۔ ، پھر ہم مندرجہ ذیل خاکہ بنا سکتے ہیں۔
اس نقطہ نظر کی اہم خصوصیات:
- ہر آنے والی درخواست کو ایک قطار میں رکھا جاتا ہے۔
- درخواست پر کارروائی کرتے وقت، سروس دیگر قطاروں میں کام بھی رکھ سکتی ہے۔
- ہر آنے والے ایونٹ کا ایک شناخت کنندہ ہوتا ہے (جو نقل کے لیے ضروری ہے)۔
- قطار نظریاتی طور پر "صرف شامل کریں" اسکیم کے مطابق کام کرتی ہے۔ آپ اس سے عناصر کو نہیں ہٹا سکتے ہیں یا انہیں دوبارہ ترتیب نہیں دے سکتے ہیں۔
- قطار FIFO اسکیم کے مطابق کام کرتی ہے (Tutology کے لیے معذرت)۔ اگر آپ کو متوازی عمل درآمد کرنے کی ضرورت ہے، تو ایک مرحلے پر آپ کو اشیاء کو مختلف قطاروں میں منتقل کرنا چاہیے۔
میں آپ کو یاد دلاتا ہوں کہ ہم آن لائن فائل اسٹوریج کے معاملے پر غور کر رہے ہیں۔ اس صورت میں، نظام کچھ اس طرح نظر آئے گا:
یہ ضروری ہے کہ خاکہ میں موجود خدمات کا مطلب علیحدہ سرور نہ ہو۔ یہاں تک کہ عمل ایک ہی ہوسکتا ہے۔ ایک اور چیز اہم ہے: نظریاتی طور پر، ان چیزوں کو اس طرح الگ کیا جاتا ہے کہ افقی پیمانہ آسانی سے لاگو کیا جا سکتا ہے.
اور دو صارفین کے لیے خاکہ کچھ یوں نظر آئے گا (مختلف صارفین کے لیے مختلف رنگوں میں بتائی گئی خدمات):
اس طرح کے مجموعہ سے بونس:
- انفارمیشن پروسیسنگ سروسز کو الگ کر دیا گیا ہے۔ قطاریں بھی الگ ہیں۔ اگر ہمیں سسٹم تھرو پٹ بڑھانے کی ضرورت ہے، تو ہمیں صرف مزید سرورز پر مزید سروسز شروع کرنے کی ضرورت ہے۔
- جب ہم کسی صارف سے معلومات حاصل کرتے ہیں، تو ہمیں ڈیٹا کے مکمل طور پر محفوظ ہونے تک انتظار نہیں کرنا پڑتا۔ اس کے برعکس ہمیں صرف "ٹھیک ہے" کا جواب دینا ہوگا اور پھر آہستہ آہستہ کام شروع کرنا ہوگا۔ ایک ہی وقت میں، قطار چوٹیوں کو ہموار کرتی ہے، کیونکہ ایک نئی چیز کو شامل کرنا تیزی سے ہوتا ہے، اور صارف کو پورے چکر میں مکمل گزرنے کا انتظار نہیں کرنا پڑتا۔
- مثال کے طور پر، میں نے ڈپلیکیشن سروس شامل کی ہے جو ایک جیسی فائلوں کو ضم کرنے کی کوشش کرتی ہے۔ اگر یہ 1% معاملات میں طویل عرصے تک کام کرتا ہے، تو کلائنٹ کو مشکل سے اس پر نظر آئے گا (اوپر دیکھیں)، جو کہ ایک بڑا فائدہ ہے، کیونکہ اب ہمیں XNUMX% رفتار اور قابل اعتماد ہونے کی ضرورت نہیں ہے۔
تاہم، نقصانات فوری طور پر ظاہر ہوتے ہیں:
- ہمارا نظام اپنی مستقل مزاجی کھو چکا ہے۔ اس کا مطلب یہ ہے کہ اگر، مثال کے طور پر، آپ مختلف سروسز کو سبسکرائب کرتے ہیں، تو نظریاتی طور پر آپ کو ایک مختلف حالت مل سکتی ہے (کیونکہ کسی ایک سروس کے پاس اندرونی قطار سے اطلاع موصول کرنے کا وقت نہیں ہوسکتا ہے)۔ ایک اور نتیجہ کے طور پر، نظام اب کوئی عام وقت نہیں ہے. یعنی، یہ ناممکن ہے، مثال کے طور پر، تمام واقعات کو صرف آمد کے وقت کے مطابق ترتیب دینا، کیونکہ سرورز کے درمیان گھڑیاں مطابقت پذیر نہیں ہوسکتی ہیں (مزید برآں، دو سرورز پر ایک ہی وقت ایک یوٹوپیا ہے)۔
- اب کوئی بھی ایونٹ آسانی سے واپس نہیں لایا جا سکتا ہے (جیسا کہ ڈیٹا بیس کے ساتھ کیا جا سکتا ہے)۔ اس کے بجائے، آپ کو ایک نیا ایونٹ شامل کرنے کی ضرورت ہے۔ ، جو آخری حالت کو مطلوبہ حالت میں بدل دے گا۔ اسی طرح کے علاقے کی مثال کے طور پر: تاریخ کو دوبارہ لکھے بغیر (جو کچھ معاملات میں خراب ہے)، آپ گٹ میں کمٹ بیک نہیں کر سکتے، لیکن آپ ایک خصوصی بنا سکتے ہیں۔ ، جو بنیادی طور پر صرف پرانی حالت کو لوٹاتا ہے۔ تاہم، غلط عہد اور رول بیک دونوں تاریخ میں رہیں گے۔
- ڈیٹا سکیما ریلیز سے ریلیز میں تبدیل ہو سکتا ہے، لیکن پرانے ایونٹس کو اب نئے معیار پر اپ ڈیٹ نہیں کیا جا سکے گا (چونکہ واقعات کو اصولی طور پر تبدیل نہیں کیا جا سکتا)۔
جیسا کہ آپ دیکھ سکتے ہیں، ایونٹ سورسنگ CQRS کے ساتھ اچھی طرح کام کرتی ہے۔ مزید برآں، موثر اور آسان قطاروں کے ساتھ، لیکن ڈیٹا کے بہاؤ کو الگ کیے بغیر، نظام کو نافذ کرنا پہلے ہی اپنے آپ میں مشکل ہے، کیونکہ آپ کو مطابقت پذیری پوائنٹس شامل کرنے ہوں گے جو قطاروں کے پورے مثبت اثر کو بے اثر کر دیں گے۔ دونوں طریقوں کو ایک ساتھ لاگو کرتے ہوئے، پروگرام کوڈ کو قدرے ایڈجسٹ کرنا ضروری ہے۔ ہمارے معاملے میں، سرور پر فائل بھیجتے وقت، جواب صرف "اوکے" آتا ہے، جس کا مطلب صرف یہ ہوتا ہے کہ "فائل کو شامل کرنے کا عمل محفوظ ہو گیا تھا۔" رسمی طور پر، اس کا مطلب یہ نہیں ہے کہ ڈیٹا پہلے سے ہی دوسرے آلات پر دستیاب ہے (مثال کے طور پر، ڈپلیکیشن سروس انڈیکس کو دوبارہ بنا سکتی ہے)۔ تاہم، کچھ وقت کے بعد، کلائنٹ کو "فائل X محفوظ کر دی گئی ہے" کے انداز میں ایک اطلاع موصول ہوگی۔
اس کے نتیجے میں:
- فائل بھیجنے کے سٹیٹس کی تعداد بڑھ رہی ہے: کلاسک "فائل بھیجی گئی" کے بجائے ہمیں دو ملتے ہیں: "فائل کو سرور پر قطار میں شامل کر دیا گیا ہے" اور "فائل کو اسٹوریج میں محفوظ کر لیا گیا ہے۔" مؤخر الذکر کا مطلب ہے کہ دوسرے آلات پہلے ہی فائل وصول کرنا شروع کر سکتے ہیں (اس حقیقت کے لئے ایڈجسٹ کیا گیا ہے کہ قطاریں مختلف رفتار سے کام کرتی ہیں)۔
- اس حقیقت کی وجہ سے کہ جمع کرانے کی معلومات اب مختلف چینلز کے ذریعے آتی ہیں، ہمیں فائل کی پروسیسنگ کی حیثیت حاصل کرنے کے لیے حل تلاش کرنے کی ضرورت ہے۔ اس کے نتیجے کے طور پر: کلاسک درخواست کے جواب کے برعکس، فائل پر کارروائی کرتے وقت کلائنٹ کو دوبارہ شروع کیا جاسکتا ہے، لیکن اس پروسیسنگ کی حیثیت خود درست ہوگی۔ اس کے علاوہ، یہ آئٹم کام کرتا ہے، بنیادی طور پر، باکس سے باہر. نتیجے کے طور پر: اب ہم ناکامیوں کو زیادہ برداشت کر رہے ہیں۔
شارڈنگ
جیسا کہ اوپر بیان کیا گیا ہے، ایونٹ سورسنگ سسٹم میں سخت مستقل مزاجی کا فقدان ہے۔ اس کا مطلب ہے کہ ہم ان کے درمیان کسی بھی ہم آہنگی کے بغیر کئی اسٹوریج استعمال کر سکتے ہیں۔ اپنے مسئلے کو حل کرتے ہوئے، ہم یہ کر سکتے ہیں:
- قسم کے لحاظ سے فائلوں کو الگ کریں۔ مثال کے طور پر، تصاویر/ویڈیوز کو ڈی کوڈ کیا جا سکتا ہے اور زیادہ موثر فارمیٹ کا انتخاب کیا جا سکتا ہے۔
- ملک کے لحاظ سے الگ الگ اکاؤنٹس۔ بہت سے قوانین کی وجہ سے، اس کی ضرورت ہوسکتی ہے، لیکن یہ آرکیٹیکچر اسکیم خود بخود ایسا موقع فراہم کرتی ہے۔
اگر آپ ڈیٹا کو ایک اسٹوریج سے دوسرے اسٹوریج میں منتقل کرنا چاہتے ہیں، تو معیاری ذرائع اب کافی نہیں ہیں۔ بدقسمتی سے، اس معاملے میں، آپ کو قطار کو روکنے، منتقلی کرنے اور پھر اسے شروع کرنے کی ضرورت ہے۔ عام صورت میں، ڈیٹا کو "اون دی فلائی" منتقل نہیں کیا جا سکتا، تاہم، اگر ایونٹ کی قطار مکمل طور پر محفوظ ہے، اور آپ کے پاس پچھلی سٹوریج سٹیٹس کے سنیپ شاٹس ہیں، تو ہم مندرجہ ذیل واقعات کو دوبارہ چلا سکتے ہیں:
- ایونٹ سورس میں، ہر ایونٹ کا اپنا شناخت کنندہ ہوتا ہے (مثالی طور پر، غیر کم ہونے والا)۔ اس کا مطلب ہے کہ ہم اسٹوریج میں ایک فیلڈ شامل کر سکتے ہیں - آخری پروسیس شدہ عنصر کی شناخت۔
- ہم قطار کو ڈپلیکیٹ کرتے ہیں تاکہ تمام واقعات کو کئی آزاد اسٹوریجز کے لیے پروسیس کیا جا سکے (پہلا وہ ہے جس میں ڈیٹا پہلے سے محفوظ ہے، اور دوسرا نیا ہے، لیکن پھر بھی خالی ہے)۔ دوسری قطار، یقیناً، ابھی تک کارروائی نہیں کی جا رہی ہے۔
- ہم دوسری قطار شروع کرتے ہیں (یعنی ہم واقعات کو دوبارہ چلانا شروع کرتے ہیں)۔
- جب نئی قطار نسبتاً خالی ہو (یعنی کسی عنصر کو شامل کرنے اور اسے بازیافت کرنے کے درمیان اوسط وقت کا فرق قابل قبول ہے) تو آپ قارئین کو نئے اسٹوریج میں تبدیل کرنا شروع کر سکتے ہیں۔
جیسا کہ آپ دیکھ سکتے ہیں، ہمارے نظام میں سخت مستقل مزاجی نہیں تھی، اور اب بھی نہیں ہے۔ صرف حتمی مستقل مزاجی ہے، یعنی اس بات کی ضمانت ہے کہ واقعات پر ایک ہی ترتیب سے عمل ہوتا ہے (لیکن ممکنہ طور پر مختلف تاخیر کے ساتھ)۔ اور، اس کا استعمال کرتے ہوئے، ہم نظام کو دنیا کے دوسری طرف روکے بغیر نسبتاً آسانی سے ڈیٹا منتقل کر سکتے ہیں۔
اس طرح، فائلوں کے لیے آن لائن سٹوریج کے بارے میں ہماری مثال کو جاری رکھتے ہوئے، اس طرح کا فن تعمیر ہمیں پہلے ہی بہت سے بونس دیتا ہے:
- ہم اشیاء کو متحرک انداز میں صارفین کے قریب لے جا سکتے ہیں۔ اس طرح آپ سروس کے معیار کو بہتر بنا سکتے ہیں۔
- ہم کمپنیوں کے اندر کچھ ڈیٹا محفوظ کر سکتے ہیں۔ مثال کے طور پر، انٹرپرائز کے صارفین اکثر اپنے ڈیٹا کو کنٹرولڈ ڈیٹا سینٹرز میں ذخیرہ کرنے کی ضرورت کرتے ہیں (ڈیٹا لیک ہونے سے بچنے کے لیے)۔ شارڈنگ کے ذریعے ہم آسانی سے اس کی حمایت کر سکتے ہیں۔ اور کام اور بھی آسان ہے اگر گاہک کے پاس مطابقت پذیر کلاؤڈ ہو (مثال کے طور پر، ).
- اور سب سے اہم بات یہ ہے کہ ہمیں ایسا کرنے کی ضرورت نہیں ہے۔ سب کے بعد، شروع کرنے کے لیے، ہم تمام اکاؤنٹس کے لیے ایک اسٹوریج سے کافی خوش ہوں گے (جلد کام شروع کرنے کے لیے)۔ اور اس سسٹم کی اہم خصوصیت یہ ہے کہ اگرچہ یہ قابل توسیع ہے لیکن ابتدائی مرحلے میں یہ کافی آسان ہے۔ آپ کو فوری طور پر کوڈ لکھنے کی ضرورت نہیں ہے جو ایک ملین علیحدہ علیحدہ قطاروں وغیرہ کے ساتھ کام کرتا ہے۔ اگر ضروری ہو تو، یہ مستقبل میں کیا جا سکتا ہے.
جامد مواد ہوسٹنگ
یہ نقطہ بالکل واضح معلوم ہوسکتا ہے، لیکن یہ اب بھی کم و بیش معیاری بھری ہوئی ایپلی کیشن کے لیے ضروری ہے۔ اس کا جوہر آسان ہے: تمام جامد مواد اسی سرور سے نہیں تقسیم کیا جاتا ہے جہاں ایپلیکیشن موجود ہے، بلکہ اس کام کے لیے خاص طور پر وقف کردہ خصوصی افراد سے تقسیم کیا جاتا ہے۔ نتیجے کے طور پر، یہ آپریشنز تیزی سے انجام پاتے ہیں (مشروط nginx فائلوں کو جاوا سرور کے مقابلے میں زیادہ تیزی سے اور کم مہنگا کام کرتا ہے)۔ پلس CDN فن تعمیر () ہمیں اپنی فائلوں کو آخری صارفین کے قریب تلاش کرنے کی اجازت دیتا ہے، جس کا سروس کے ساتھ کام کرنے کی سہولت پر مثبت اثر پڑتا ہے۔
جامد مواد کی سب سے آسان اور معیاری مثال ویب سائٹ کے لیے اسکرپٹ اور تصاویر کا ایک سیٹ ہے۔ ان کے ساتھ سب کچھ آسان ہے - وہ پہلے سے معلوم ہوتے ہیں، پھر آرکائیو کو CDN سرورز پر اپ لوڈ کیا جاتا ہے، جہاں سے وہ آخری صارفین میں تقسیم کیے جاتے ہیں۔
تاہم، حقیقت میں، جامد مواد کے لیے، آپ کسی حد تک لیمبڈا فن تعمیر سے ملتا جلتا طریقہ استعمال کر سکتے ہیں۔ آئیے اپنے کام (آن لائن فائل اسٹوریج) پر واپس آتے ہیں، جس میں ہمیں فائلوں کو صارفین میں تقسیم کرنے کی ضرورت ہے۔ سب سے آسان حل یہ ہے کہ ایک ایسی سروس بنائی جائے جو، ہر صارف کی درخواست کے لیے، تمام ضروری جانچ پڑتال کرے (آتھورائزیشن وغیرہ)، اور پھر فائل کو براہ راست ہمارے اسٹوریج سے ڈاؤن لوڈ کرے۔ اس نقطہ نظر کا بنیادی نقصان یہ ہے کہ جامد مواد (اور ایک مخصوص نظر ثانی والی فائل درحقیقت جامد مواد ہے) کو اسی سرور کے ذریعے تقسیم کیا جاتا ہے جس میں کاروباری منطق ہوتی ہے۔ اس کے بجائے، آپ مندرجہ ذیل خاکہ بنا سکتے ہیں:
- سرور ایک ڈاؤن لوڈ URL فراہم کرتا ہے۔ یہ فائل_آئی ڈی + کلید کی شکل میں ہوسکتا ہے، جہاں کلید ایک منی ڈیجیٹل دستخط ہے جو اگلے 24 گھنٹوں تک وسائل تک رسائی کا حق دیتی ہے۔
- فائل کو سادہ nginx کے ذریعہ درج ذیل اختیارات کے ساتھ تقسیم کیا گیا ہے۔
- مواد کیشنگ۔ چونکہ یہ سروس ایک علیحدہ سرور پر واقع ہوسکتی ہے، اس لیے ہم نے اپنے آپ کو مستقبل کے لیے محفوظ رکھ دیا ہے جس میں تمام تازہ ترین ڈاؤن لوڈ فائلوں کو ڈسک پر اسٹور کرنے کی صلاحیت ہے۔
- کنکشن بنانے کے وقت کلید کو چیک کرنا
- اختیاری: سلسلہ بندی کے مواد کی پروسیسنگ۔ مثال کے طور پر، اگر ہم سروس میں تمام فائلوں کو کمپریس کرتے ہیں، تو ہم اس ماڈیول میں براہ راست ان زپ کر سکتے ہیں۔ نتیجے کے طور پر: IO آپریشنز وہیں کیے جاتے ہیں جہاں وہ تعلق رکھتے ہیں۔ جاوا میں ایک آرکائیور آسانی سے بہت زیادہ اضافی میموری مختص کرے گا، لیکن کاروباری منطق کے ساتھ کسی سروس کو Rust/C++ مشروط میں دوبارہ لکھنا بھی غیر موثر ہو سکتا ہے۔ ہمارے معاملے میں، مختلف عمل (یا حتیٰ کہ خدمات) استعمال کیے جاتے ہیں، اور اس لیے ہم کاروباری منطق اور IO آپریشنز کو کافی مؤثر طریقے سے الگ کر سکتے ہیں۔
یہ اسکیم جامد مواد کی تقسیم سے بہت ملتی جلتی نہیں ہے (چونکہ ہم پورے جامد پیکج کو کہیں اپ لوڈ نہیں کرتے ہیں)، لیکن حقیقت میں، یہ نقطہ نظر بالکل متغیر ڈیٹا کی تقسیم سے متعلق ہے۔ مزید برآں، اس اسکیم کو دوسرے معاملات میں عام کیا جا سکتا ہے جہاں مواد صرف جامد نہیں ہے، بلکہ اسے ناقابل تبدیل اور غیر حذف شدہ بلاکس کے سیٹ کے طور پر پیش کیا جا سکتا ہے (حالانکہ وہ شامل کیے جا سکتے ہیں)۔
ایک اور مثال کے طور پر (کمک کے لیے): اگر آپ نے جینکنز/ٹیم سٹی کے ساتھ کام کیا ہے، تو آپ جانتے ہیں کہ دونوں حل جاوا میں لکھے گئے ہیں۔ یہ دونوں ایک جاوا عمل ہیں جو بلڈ آرکیسٹریشن اور مواد کے انتظام دونوں کو ہینڈل کرتا ہے۔ خاص طور پر، ان دونوں کے پاس "سرور سے فائل/فولڈر کی منتقلی" جیسے کام ہیں۔ مثال کے طور پر: نمونے جاری کرنا، سورس کوڈ کی منتقلی (جب ایجنٹ براہ راست ریپوزٹری سے کوڈ ڈاؤن لوڈ نہیں کرتا ہے، لیکن سرور اس کے لیے کرتا ہے)، لاگز تک رسائی۔ یہ تمام کام ان کے IO بوجھ میں مختلف ہیں۔ یعنی، یہ پتہ چلتا ہے کہ پیچیدہ کاروباری منطق کے لیے ذمہ دار سرور کو ایک ہی وقت میں اپنے ذریعے ڈیٹا کے بڑے بہاؤ کو مؤثر طریقے سے آگے بڑھانے کے قابل ہونا چاہیے۔ اور سب سے دلچسپ بات یہ ہے کہ اس طرح کے آپریشن کو بالکل اسی اسکیم کے مطابق ایک ہی nginx کے سپرد کیا جاسکتا ہے (سوائے اس کے کہ ڈیٹا کی کو درخواست میں شامل کیا جائے)۔
تاہم، اگر ہم اپنے سسٹم پر واپس آتے ہیں، تو ہمیں ایک ایسا ہی خاکہ ملتا ہے:
جیسا کہ آپ دیکھ سکتے ہیں، نظام بنیادی طور پر زیادہ پیچیدہ ہو گیا ہے. اب یہ صرف ایک منی پروسیس نہیں ہے جو فائلوں کو مقامی طور پر اسٹور کرتا ہے۔ اب جس چیز کی ضرورت ہے وہ آسان ترین سپورٹ، API ورژن کنٹرول وغیرہ نہیں ہے۔ لہٰذا، تمام خاکوں کو تیار کرنے کے بعد، بہتر ہے کہ تفصیل سے اندازہ لگایا جائے کہ آیا توسیع پذیری لاگت کے قابل ہے۔ تاہم، اگر آپ سسٹم کو بڑھانے کے قابل ہونا چاہتے ہیں (بشمول صارفین کی ایک بڑی تعداد کے ساتھ کام کرنا)، تو آپ کو اسی طرح کے حل کے لیے جانا پڑے گا۔ لیکن، نتیجے کے طور پر، نظام تعمیراتی طور پر بڑھے ہوئے بوجھ کے لیے تیار ہے (تقریباً ہر جزو کو افقی پیمانے کے لیے کلون کیا جا سکتا ہے)۔ سسٹم کو بغیر روکے اپ ڈیٹ کیا جا سکتا ہے (بس کچھ آپریشنز قدرے سست ہو جائیں گے)۔
جیسا کہ میں نے شروع میں کہا تھا، اب انٹرنیٹ سروسز کی ایک بڑی تعداد میں اضافہ لوڈ ہونا شروع ہو گیا ہے۔ اور ان میں سے کچھ نے صحیح طریقے سے کام کرنا بند کرنا شروع کر دیا۔ درحقیقت، نظام اس وقت بالکل ناکام ہو گئے جب کاروبار کو پیسہ کمانا تھا۔ یعنی، موخر ڈیلیوری کے بجائے، صارفین کو "آنے والے مہینوں کے لیے اپنی ڈیلیوری کا منصوبہ بنائیں" کا مشورہ دینے کے بجائے، سسٹم نے صرف اتنا کہا کہ "اپنے حریفوں کے پاس جاؤ۔" درحقیقت، یہ کم پیداواری صلاحیت کی قیمت ہے: نقصان بالکل اسی وقت ہوگا جب منافع سب سے زیادہ ہوگا۔
حاصل يہ ہوا
یہ تمام طریقے پہلے سے معلوم تھے۔ وہی VK طویل عرصے سے تصاویر کو ظاہر کرنے کے لیے Static Content Hosting کا خیال استعمال کر رہا ہے۔ بہت سارے آن لائن گیمز کھلاڑیوں کو علاقوں میں تقسیم کرنے یا گیم کے مقامات کو الگ کرنے کے لیے Sharding سکیم کا استعمال کرتے ہیں (اگر دنیا خود ایک ہے)۔ ایونٹ سورسنگ کا طریقہ ای میل میں فعال طور پر استعمال ہوتا ہے۔ زیادہ تر تجارتی ایپلی کیشنز جہاں ڈیٹا مسلسل موصول ہوتا رہتا ہے دراصل CQRS اپروچ پر بنایا جاتا ہے تاکہ موصول ہونے والے ڈیٹا کو فلٹر کیا جا سکے۔ ٹھیک ہے، افقی پیمانہ بہت طویل عرصے سے بہت ساری خدمات میں استعمال ہوتا رہا ہے۔
تاہم، سب سے اہم بات یہ ہے کہ یہ تمام نمونے جدید ایپلی کیشنز میں لاگو کرنا بہت آسان ہو گئے ہیں (اگر وہ مناسب ہوں تو یقیناً)۔ کلاؤڈز فوراً شارڈنگ اور افقی اسکیلنگ پیش کرتے ہیں، جو کہ مختلف ڈیٹا سینٹرز میں مختلف سرشار سرورز کو خود آرڈر کرنے سے کہیں زیادہ آسان ہے۔ CQRS بہت آسان ہو گیا ہے، اگر صرف RX جیسی لائبریریوں کی ترقی کی وجہ سے۔ تقریباً 10 سال پہلے، ایک نایاب ویب سائٹ اس کی حمایت کر سکتی تھی۔ اپاچی کافکا کے ساتھ تیار کنٹینرز کی بدولت ایونٹ سورسنگ کو ترتیب دینا بھی ناقابل یقین حد تک آسان ہے۔ 10 سال پہلے یہ بدعت ہوتی تھی، اب یہ عام بات ہے۔ جامد مواد کی میزبانی کے ساتھ بھی ایسا ہی ہے: زیادہ آسان ٹیکنالوجیز کی وجہ سے (بشمول یہ حقیقت کہ تفصیلی دستاویزات اور جوابات کا ایک بڑا ڈیٹا بیس موجود ہے)، یہ نقطہ نظر اور بھی آسان ہو گیا ہے۔
نتیجے کے طور پر، بہت سے پیچیدہ آرکیٹیکچرل پیٹرن کا نفاذ اب بہت آسان ہو گیا ہے، جس کا مطلب یہ ہے کہ پہلے سے ہی اس پر قریبی نظر ڈالنا بہتر ہے. اگر دس سال پرانی ایپلی کیشن میں مندرجہ بالا حلوں میں سے ایک کو لاگو کرنے اور آپریشن کی زیادہ لاگت کی وجہ سے ترک کر دیا گیا تھا، تو اب، ایک نئی ایپلی کیشن میں، یا ری فیکٹرنگ کے بعد، آپ ایک ایسی سروس بنا سکتے ہیں جو پہلے سے ہی تعمیراتی طور پر دونوں قابل توسیع ہو گی۔ کارکردگی کے لحاظ سے) اور کلائنٹس کی نئی درخواستوں کے لیے تیار ہے (مثال کے طور پر، ذاتی ڈیٹا کو مقامی بنانا)۔
اور سب سے اہم: اگر آپ کے پاس سادہ ایپلیکیشن ہے تو براہ کرم ان طریقوں کو استعمال نہ کریں۔ ہاں، وہ خوبصورت اور دلچسپ ہیں، لیکن 100 لوگوں کی چوٹی پر جانے والی سائٹ کے لیے، آپ اکثر کلاسک یک سنگی کے ساتھ جا سکتے ہیں (کم از کم باہر کی طرف، اندر کی ہر چیز کو ماڈیولز وغیرہ میں تقسیم کیا جا سکتا ہے)۔
ماخذ: www.habr.com