ہم کانفرنس کی رپورٹ کا نقل دوبارہ شائع کر رہے ہیں۔ 2016، جو گزشتہ سال 7-8 نومبر کو ماسکو کے قریب Skolkovo میں ہوا تھا۔ OpenResty اور Lua کے ساتھ NGINX فعالیت کو بڑھانے کا طریقہ بتاتا ہے۔
سب کو ہیلو، میرا نام ولادیمیر پروٹاسوف ہے، میں Parallels میں کام کرتا ہوں۔ میں آپ کو اپنے بارے میں تھوڑا بتاتا ہوں۔ میں اپنی زندگی کا تین چوتھائی کوڈ لکھنے میں صرف کرتا ہوں۔ میں لفظی معنی میں بنیادی طور پر ایک پروگرامر بن گیا: کبھی کبھی میں اپنے خوابوں میں کوڈ دیکھتا ہوں۔ زندگی کا ایک چوتھائی صنعتی ترقی ہے، تحریری کوڈ جو براہ راست پیداوار میں جاتا ہے۔ ایک کوڈ جسے آپ میں سے کچھ استعمال کرتے ہیں لیکن اس کا احساس نہیں کرتے۔
تو آپ سمجھ گئے کہ یہ کتنا برا تھا۔ جب میں تھوڑا جونیئر تھا، میں آیا اور مجھے یہ دو ٹیرا بائٹ ڈیٹا بیس دیا گیا۔ اب یہاں سب کے لیے بہت زیادہ بوجھ ہے۔ میں کانفرنسوں میں گیا اور پوچھا: "دوستوں، مجھے بتائیں، آپ کے پاس بڑا ڈیٹا ہے، کیا سب کچھ اچھا ہے؟ آپ کے وہاں کتنے اڈے ہیں؟ انہوں نے مجھے جواب دیا: "ہمارے پاس 100 گیگا بائٹس ہیں!" میں نے کہا: "ٹھنڈا، 100 گیگا بائٹس!" اور میں اپنے آپ سے سوچ رہا تھا کہ اپنے پوکر چہرے کو احتیاط سے کیسے برقرار رکھوں۔ آپ سوچتے ہیں، ہاں، لڑکے اچھے ہیں، اور پھر آپ واپس جا کر ان ملٹی ٹیرابائٹ ڈیٹا بیس کے ساتھ ٹنکر کرتے ہیں۔ اور یہ - ایک جونیئر ہونا۔ کیا آپ سوچ سکتے ہیں کہ یہ کیسا دھچکا ہے؟
میں 20 سے زیادہ پروگرامنگ زبانیں جانتا ہوں۔ یہ وہ چیز ہے جس کا مجھے پتہ لگانا تھا جب میں نے کام کیا۔ وہ آپ کو ایرلنگ، C، C++، Lua، Python، Ruby، کچھ اور میں کوڈ دیتے ہیں، اور آپ کو یہ سب کاٹنا ہوگا۔ عام طور پر، مجھے کرنا پڑا. صحیح تعداد کا اندازہ لگانا ممکن نہیں تھا لیکن 20 کے آس پاس کہیں نمبر گم ہو گیا۔
چونکہ موجود ہر کوئی جانتا ہے کہ متوازی کیا ہے اور ہم کیا کرتے ہیں، میں اس بارے میں بات نہیں کروں گا کہ ہم کتنے اچھے ہیں اور ہم کیا کرتے ہیں۔ میں آپ کو صرف اتنا بتاؤں گا کہ ہمارے پاس دنیا بھر میں 13 دفاتر ہیں، 300 سے زیادہ ملازمین، ماسکو، ٹالن اور مالٹا میں ترقی۔ اگر آپ چاہیں تو آپ اسے لے کر مالٹا جا سکتے ہیں اگر سردیوں میں سردی ہو اور آپ کو اپنی کمر کو گرم کرنے کی ضرورت ہو۔
خاص طور پر، ہمارا محکمہ Python 2 میں لکھتا ہے۔ ہم کاروبار میں ہیں اور فیشن ایبل ٹیکنالوجیز کو لاگو کرنے کے لیے ہمارے پاس وقت نہیں ہے، اس لیے ہمیں نقصان اٹھانا پڑتا ہے۔ ہم جینگو کا استعمال کرتے ہیں کیونکہ اس میں سب کچھ ہے، اور ہم نے جو غیر ضروری تھا لے لیا اور اسے پھینک دیا۔ اس کے علاوہ MySQL، Redis اور NGINX۔ ہمارے پاس بہت سی دوسری عمدہ چیزیں بھی ہیں۔ ہمارے پاس MongoDB ہے، ہمارے پاس خرگوش دوڑتے پھرتے ہیں، ہمارے پاس سب کچھ ہے - لیکن یہ میرا نہیں ہے، اور میں یہ نہیں کرتا۔
اوپن ریسٹی
میں نے اپنے بارے میں بتایا۔ آئیے جانتے ہیں کہ میں آج کس کے بارے میں بات کرنے جا رہا ہوں:
- OpenResty کیا ہے اور اسے کس چیز کے ساتھ کھایا جاتا ہے؟
- جب ہمارے پاس Python، NodeJS، PHP، Go اور دیگر عمدہ چیزیں ہیں جن سے ہر کوئی خوش ہوتا ہے تو ایک اور پہیے کو دوبارہ کیوں ایجاد کریں؟
- اور زندگی سے چند مثالیں۔ مجھے رپورٹ کو بہت زیادہ کاٹنا پڑا کیونکہ اس میں مجھے 3,5 گھنٹے لگے، اس لیے چند مثالیں ہوں گی۔
OpenResty NGINX ہے۔ اس کا شکریہ، ہمارے پاس ایک مکمل ویب سرور ہے جو اچھی طرح سے لکھا جاتا ہے اور تیزی سے کام کرتا ہے۔ میرے خیال میں ہم میں سے بیشتر پیداوار میں NGINX استعمال کرتے ہیں۔ آپ سب جانتے ہیں کہ وہ تیز اور ٹھنڈا ہے۔ انہوں نے اس میں ٹھنڈا ہم وقت ساز I/O بنایا، لہذا ہمیں کسی بھی چیز کو سائیکل کرنے کی ضرورت نہیں ہے، جیسا کہ انہوں نے Python میں کیا تھا۔ Gevent بہت اچھا، بہت اچھا ہے، لیکن اگر آپ C کوڈ لکھتے ہیں اور کچھ غلط ہو جاتا ہے، تو Gevent کے ساتھ آپ اسے ڈیبگ کرنے میں پاگل ہو جائیں گے۔ مجھے تجربہ تھا: یہ معلوم کرنے میں پورے دو دن لگے کہ وہاں کیا غلط ہوا ہے۔ اگر کسی نے کئی ہفتوں تک ادھر ادھر نہ کھدائی ہوتی، مسئلہ نہ پایا ہوتا، انٹرنیٹ پر لکھا ہوتا، اور گوگل کو نہ ملتا تو ہم بالکل پاگل ہو جاتے۔
NGINX میں پہلے ہی کیشنگ اور جامد مواد ہو چکا ہے۔ آپ کو یہ فکر کرنے کی ضرورت نہیں ہے کہ یہ انسانی طریقے سے کیسے کریں، تاکہ آپ کہیں سست نہ ہو جائیں، تاکہ آپ کہیں وضاحتی کھو نہ جائیں۔ Nginx تعینات کرنے میں بہت آسان ہے، آپ کو یہ سوچنے کی ضرورت نہیں ہے کہ کیا لینا ہے - WSGI، PHP-FPM، Gunicorn، Unicorn۔ Nginx انسٹال کیا گیا تھا، منتظمین کو دیا گیا تھا، وہ جانتے ہیں کہ اس کے ساتھ کیسے کام کرنا ہے۔ Nginx ایک منظم انداز میں درخواستوں پر کارروائی کرتا ہے۔ اس بارے میں تھوڑی دیر بعد بات کروں گا۔ مختصراً، اس کا ایک مرحلہ ہوتا ہے جب اس نے صرف درخواست کو قبول کیا، کب اس پر کارروائی کی، اور جب اس نے صارف کو مواد پیش کیا۔
Nginx ٹھنڈا ہے، لیکن ایک مسئلہ ہے: یہ کافی لچکدار نہیں ہے، یہاں تک کہ ان تمام ٹھنڈی خصوصیات کے ساتھ جو لڑکوں نے کنفیگر کیے ہیں، اس کے باوجود کہ کنفیگر کیا جا سکتا ہے۔ یہ طاقت کافی نہیں ہے۔ یہی وجہ ہے کہ Taobao کے لڑکوں نے، بہت عرصہ پہلے، ایسا لگتا ہے کہ آٹھ سال پہلے، Lua کو اس میں بنایا تھا۔ یہ کیا دیتا ہے؟
- سائز. یہ چھوٹا ہے. LuaJIT تقریباً 100-200 کلو بائٹس میموری اوور ہیڈ اور کم سے کم کارکردگی اوور ہیڈ دیتا ہے۔
- رفتار. LuaJIT مترجم بہت سے حالات میں C کے قریب ہوتا ہے، کچھ حالات میں یہ Java سے ہار جاتا ہے، دوسروں میں یہ اس سے بہتر کارکردگی کا مظاہرہ کرتا ہے۔ کچھ عرصے سے اسے اسٹیٹ آف آرٹ سمجھا جاتا تھا، بہترین جے آئی ٹی مرتب کرنے والا۔ اب ٹھنڈے ہیں، لیکن وہ بہت بھاری ہیں، مثال کے طور پر، وہی V8۔ کچھ JS ترجمان اور Java HotSpot کچھ پوائنٹس پر تیز ہیں، لیکن کچھ جگہوں پر وہ اب بھی کھو دیتے ہیں۔
- سیکھنے میں آسان. اگر آپ کے پاس پرل کوڈ کی بنیاد ہے، اور آپ بکنگ نہیں کر رہے ہیں، تو آپ کو پرل پروگرامرز نہیں ملیں گے۔ چونکہ وہ موجود نہیں ہیں، ان سب کو چھین لیا گیا، اور ان کو پڑھانا طویل اور مشکل ہے۔ اگر آپ کسی اور چیز کے لیے پروگرامرز چاہتے ہیں، تو آپ کو انھیں دوبارہ تربیت دینا یا انھیں تلاش کرنا پڑ سکتا ہے۔ Lua کے معاملے میں، سب کچھ آسان ہے. کوئی بھی جونیئر تین دن میں لوا سیکھ سکتا ہے۔ مجھے یہ معلوم کرنے میں تقریباً دو گھنٹے لگے۔ دو گھنٹے بعد میں پہلے ہی پروڈکشن میں کوڈ لکھ رہا تھا۔ تقریباً ایک ہفتہ بعد وہ سیدھا پروڈکشن میں گیا اور چلا گیا۔
نتیجے کے طور پر، یہ اس طرح لگتا ہے:
یہاں بہت کچھ ہے۔ OpenResty نے ماڈیولز کا ایک گروپ جمع کیا ہے، دونوں luash اور انجن والے۔ اور آپ کے پاس سب کچھ تیار ہے - تعینات اور کام کر رہے ہیں۔
مثالیں
دھن کافی ہے، آئیے کوڈ کی طرف چلتے ہیں۔ یہاں ایک چھوٹا سا ہیلو ورلڈ ہے:
وہاں کیا ہے؟ یہ انجن کا مقام ہے۔ ہم فکر نہ کریں، ہم اپنی روٹنگ خود نہیں لکھتے، ہم کچھ ریڈی میڈ نہیں لیتے ہیں - یہ ہمارے پاس پہلے سے ہی NGINX میں موجود ہے، ہم ایک اچھی اور سست زندگی گزار رہے ہیں۔
content_by_lua_block ایک بلاک ہے جو کہتا ہے کہ ہم Lua اسکرپٹ کا استعمال کرتے ہوئے مواد پیش کر رہے ہیں۔ ہم انجن متغیر لیتے ہیں۔ remote_addr اور ڈالو string.format. یہ ویسا ہی ہے۔ sprintfصرف Lua میں، صرف درست۔ اور ہم اسے کلائنٹ کو دیتے ہیں۔
نتیجے کے طور پر، یہ اس طرح نظر آئے گا:
لیکن آئیے حقیقی دنیا کی طرف لوٹتے ہیں۔ کوئی بھی ہیلو ورلڈ کو پروڈکشن میں تعینات نہیں کرتا ہے۔ ہماری درخواست عام طور پر ڈیٹا بیس یا کہیں اور جاتی ہے اور زیادہ تر وقت جواب کا انتظار کرتی ہے۔
وہ صرف بیٹھ کر انتظار کرتا ہے۔ یہ بہت اچھا نہیں ہے۔ جب 100.000 صارفین آتے ہیں تو یہ ہمارے لیے بہت مشکل ہوتا ہے۔ تو آئیے مثال کے طور پر ایک سادہ ایپلیکیشن استعمال کریں۔ ہم مثال کے طور پر بلیوں کی تصاویر تلاش کریں گے۔ لیکن ہم صرف تلاش نہیں کریں گے، ہم مطلوبہ الفاظ کو بڑھا دیں گے اور، اگر صارف نے "بلی کے بچے" کو تلاش کیا تو ہمیں بلیاں، پیاری بلیاں وغیرہ ملیں گی۔ سب سے پہلے، ہمیں بیک اینڈ پر درخواست کا ڈیٹا حاصل کرنے کی ضرورت ہے۔ ایسا لگتا ہے:
دو لائنیں آپ کو GET پیرامیٹرز لینے کی اجازت دیتی ہیں، کوئی پیچیدگی نہیں۔ اس کے بعد، آئیے کہتے ہیں، کلیدی لفظ اور توسیع کے نشان والے ڈیٹا بیس سے، ہم یہ معلومات باقاعدہ SQL استفسار کا استعمال کرتے ہوئے حاصل کرتے ہیں۔ یہ آسان ہے. ایسا لگتا ہے:
لائبریری کو جوڑنا resty.mysql، جو ہمارے پاس پہلے سے ہی کٹ میں موجود ہے۔ ہمیں کچھ بھی انسٹال کرنے کی ضرورت نہیں ہے، سب کچھ تیار ہے۔ ہم اس بات کی نشاندہی کرتے ہیں کہ کس طرح جڑنا ہے اور SQL استفسار کرنا ہے:
یہ یہاں تھوڑا سا خوفناک ہے، لیکن سب کچھ کام کرتا ہے. یہاں 10 کی حد ہے۔ ہم 10 اندراجات نکالتے ہیں، ہم سست ہیں، ہم مزید نہیں دکھانا چاہتے۔ میں ایس کیو ایل میں حد کے بارے میں بھول گیا تھا۔
اگلا ہم تمام سوالات کے لیے تصاویر تلاش کرتے ہیں۔ ہم درخواستوں کا ایک گروپ جمع کرتے ہیں اور لوا ٹیبل کو بھرتے ہیں۔ reqs، اور ہم کرتے ہیں۔ ngx.location.capture_multi.
یہ تمام درخواستیں متوازی طور پر بھیجی جاتی ہیں، اور جوابات ہمیں واپس کیے جاتے ہیں۔ آپریٹنگ ٹائم سست ترین کے جوابی وقت کے برابر ہے۔ اگر ہم سب 50 ملی سیکنڈ میں گولی مارتے ہیں، اور ہم نے سو درخواستیں بھیجی ہیں، تو ہمیں 50 ملی سیکنڈ میں جواب موصول ہوگا۔
چونکہ ہم سست ہیں اور HTTP اور کیشنگ ہینڈلنگ نہیں لکھنا چاہتے، ہم NGINX کو ہمارے لیے سب کچھ کرنے پر مجبور کریں گے۔ جیسا کہ آپ نے دیکھا، کے لئے ایک درخواست تھی url/fetch، یہ رہا:
ہم اسے آسان بناتے ہیں۔ proxy_pass، ہم اشارہ کرتے ہیں کہ کیش کہاں کرنا ہے، اسے کیسے کرنا ہے، اور سب کچھ ہمارے لیے کام کرتا ہے۔
لیکن یہ کافی نہیں ہے، ہمیں اب بھی صارف کو ڈیٹا دینے کی ضرورت ہے۔ سب سے آسان خیال یہ ہے کہ JSON میں ہر چیز کو آسانی سے دو لائنوں میں ترتیب دیا جائے۔ ہم مواد کی قسم دیتے ہیں، ہم JSON دیتے ہیں۔
لیکن ایک مشکل ہے: صارف JSON پڑھنا نہیں چاہتا۔ ہمیں فرنٹ اینڈ ڈویلپرز کو راغب کرنے کی ضرورت ہے۔ بعض اوقات ہم شروع میں ایسا نہیں کرنا چاہتے۔ اور SEO ماہرین کہیں گے کہ اگر ہم تصویریں ڈھونڈ رہے ہیں، تو ان کے لیے کوئی فرق نہیں پڑتا۔ اور اگر ہم انہیں کچھ مواد دیتے ہیں، تو وہ کہیں گے کہ ہمارے سرچ انجن کچھ بھی انڈیکس نہیں کرتے۔
اس کے بارے میں کیا کرنا ہے؟ یقینا، ہم صارف کو HTML دیں گے۔ ہاتھ سے پیدا کرنا غلط نہیں ہے، لہذا ہم ٹیمپلیٹس استعمال کرنا چاہتے ہیں۔ اس کے لیے ایک لائبریری موجود ہے۔ lua-resty-template.
آپ نے شاید تین خوفناک حروف OPM دیکھے ہوں گے۔ OpenResty اپنے پیکج مینیجر کے ساتھ آتا ہے، جس کے ذریعے آپ مختلف ماڈیولز کا ایک گروپ انسٹال کر سکتے ہیں، خاص طور پر، lua-resty-template. یہ ایک سادہ ٹیمپلیٹ انجن ہے، جو جینگو ٹیمپلیٹس کی طرح ہے۔ وہاں آپ کوڈ لکھ سکتے ہیں اور متغیر متبادل کو انجام دے سکتے ہیں۔
نتیجے کے طور پر، سب کچھ اس طرح نظر آئے گا:
ہم نے ڈیٹا لیا اور ٹیمپلیٹ کو دوبارہ دو لائنوں میں پیش کیا۔ صارف خوش ہے، اس نے بلیاں وصول کیں۔ چونکہ ہم نے درخواست کو بڑھایا، اس نے بلی کے بچوں کے لیے کھال کی مہر بھی حاصل کی۔ آپ کبھی نہیں جانتے، شاید وہ بالکل اسی کی تلاش میں تھا، لیکن اپنی درخواست کو صحیح طریقے سے مرتب نہیں کر سکا۔
سب کچھ ٹھنڈا ہے، لیکن ہم ترقی میں ہیں اور اسے ابھی تک صارفین کو نہیں دکھانا چاہتے۔ آئیے اجازت دیتے ہیں۔ ایسا کرنے کے لیے، آئیے دیکھتے ہیں کہ کس طرح NGINX OpenResty شرائط میں درخواست کو ہینڈل کرتا ہے:
- پہلا مرحلہ - تک رسائی حاصل، جب صارف ابھی پہنچا، اور ہم نے اسے ہیڈرز، IP ایڈریس اور دوسرے ڈیٹا کے ذریعے دیکھا۔ اگر ہمیں یہ پسند نہیں ہے تو ہم اسے فوری طور پر کاٹ سکتے ہیں۔ اسے اجازت کے لیے استعمال کیا جا سکتا ہے، یا اگر ہمیں بہت سی درخواستیں موصول ہوتی ہیں، تو ہم اس مرحلے میں انہیں آسانی سے کاٹ سکتے ہیں۔
- دوبارہ لکھیں. ہم کچھ درخواست کے ڈیٹا کو دوبارہ لکھتے ہیں۔
- مواد. ہم صارف کو مواد فراہم کرتے ہیں۔
- ہیڈر فلٹر. ہم رسپانس ہیڈرز کو تبدیل کرتے ہیں۔ اگر ہم استعمال کرتے
proxy_pass، ہم صارف کو دینے سے پہلے کچھ ہیڈر دوبارہ لکھ سکتے ہیں۔ - جسم فلٹر. ہم جسم کو بدل سکتے ہیں۔
- لاگ ان کریں - لاگنگ آپ بغیر کسی اضافی پرت کے elasticsearch میں لاگ لکھ سکتے ہیں۔
ہماری اجازت کچھ اس طرح نظر آئے گی:
ہم اسے اس میں شامل کریں گے۔ location، جسے ہم نے پہلے بیان کیا، اور مندرجہ ذیل کوڈ کو وہاں رکھا:
ہم یہ دیکھتے ہیں کہ آیا ہمارے پاس کوکی ٹوکن ہے۔ اگر نہیں، تو ہم اجازت طلب کرتے ہیں۔ صارفین چالاک ہیں اور اندازہ لگا سکتے ہیں کہ انہیں کوکی ٹوکن سیٹ کرنے کی ضرورت ہے۔ لہذا، ہم اسے Redis میں بھی ڈالیں گے:
Redis کے ساتھ کام کرنے کا کوڈ بہت آسان ہے اور دوسری زبانوں سے مختلف نہیں ہے۔ ایک ہی وقت میں، تمام ان پٹ/آؤٹ پٹ، یہاں اور وہاں، بلاک نہیں ہو رہا ہے۔ اگر آپ ہم وقت ساز کوڈ لکھتے ہیں تو یہ متضاد طور پر کام کرتا ہے۔ تقریبا gevent کی طرح، لیکن اچھی طرح سے کیا.
آئیے اجازت خود کرتے ہیں:
ہم کہتے ہیں کہ ہمیں درخواست کا باڈی پڑھنے کی ضرورت ہے۔ ہمیں POST کے دلائل موصول ہوتے ہیں اور چیک کرتے ہیں کہ لاگ ان اور پاس ورڈ درست ہیں۔ اگر وہ غلط ہیں، تو ہم آپ کو اجازت کے لیے چیلنج کرتے ہیں۔ اور اگر درست ہو تو Redis میں ٹوکن لکھیں:
کوکی کو سیٹ کرنا نہ بھولیں، یہ بھی دو لائنوں میں کیا جاتا ہے:
مثال سادہ اور قیاس ہے۔ بلاشبہ، ہم ایسی خدمت نہیں کریں گے جو لوگوں کو بلی دکھاتی ہو۔ لیکن ہمیں کون جانتا ہے۔ تو آئیے دیکھتے ہیں کہ پیداوار میں کیا کیا جا سکتا ہے۔
- کم سے کم بیک اینڈ. بعض اوقات ہمیں بیک اینڈ پر تھوڑا سا ڈیٹا آؤٹ پٹ کرنے کی ضرورت ہوتی ہے: کہیں ہمیں تاریخ ڈالنے کی ضرورت ہوتی ہے، کہیں ہمیں ایک فہرست ظاہر کرنے کی ضرورت ہوتی ہے، یہ بتانے کی ضرورت ہوتی ہے کہ اس سائٹ پر کتنے صارفین ہیں، کاؤنٹر یا اعدادوشمار منسلک کریں۔ اتنی چھوٹی چیز۔ کچھ کم سے کم ٹکڑے بہت آسانی سے بنائے جا سکتے ہیں۔ یہ اسے تیز، آسان اور عظیم بنا دے گا۔
- ڈیٹا پری پروسیسنگ. بعض اوقات ہم اشتہارات کو اپنے صفحہ میں سرایت کرنا چاہتے ہیں، اور ہم API کی درخواستوں کا استعمال کرتے ہوئے یہ اشتہار وصول کرتے ہیں۔ یہ یہاں کرنا بہت آسان ہے۔ ہم اپنے بیک اینڈ کو لوڈ نہیں کرتے، جو پہلے ہی بیٹھ کر محنت کر رہا ہے۔ آپ اسے اٹھا کر یہاں جمع کر سکتے ہیں۔ ہم کچھ جے ایس کو اکٹھا کر سکتے ہیں یا اس کے برعکس، اسے جوڑے بنا سکتے ہیں اور کسی چیز کو صارف کو دینے سے پہلے پہلے سے پروسیس کر سکتے ہیں۔
- مائیکرو سروس کے لیے اگواڑا. یہ بھی بہت اچھا کیس ہے، میں نے اس پر عمل کیا۔ اس سے پہلے، میں نے Tenzor میں کام کیا، ایک کمپنی جو الیکٹرانک رپورٹنگ کا کام کرتی ہے اور ملک میں تقریباً نصف قانونی اداروں کو رپورٹنگ فراہم کرتی ہے۔ ہم نے ایک سروس بنائی، وہاں ایک ہی طریقہ کار کا استعمال کرتے ہوئے بہت سی چیزیں کی گئیں: روٹنگ، اجازت اور بہت کچھ۔
OpenResty کو آپ کی مائیکرو سروسز کے لیے گلو کے طور پر استعمال کیا جا سکتا ہے، جو ہر چیز تک ایک ہی رسائی اور ایک ہی انٹرفیس فراہم کرتا ہے۔ چونکہ مائیکرو سروسز کو اس طرح لکھا جا سکتا ہے کہ آپ کے پاس یہاں Node.js ہے، یہاں PHP ہے، یہاں Python ہے، یہاں کچھ Erlang چیز ہے، ہم سمجھتے ہیں کہ ہم ہر جگہ ایک ہی کوڈ کو دوبارہ نہیں لکھنا چاہتے۔ لہذا، OpenResty سامنے میں پلگ کیا جا سکتا ہے. - شماریات اور تجزیات. عام طور پر NGINX داخلی دروازے پر ہوتا ہے، اور تمام درخواستیں اس سے گزرتی ہیں۔ یہ اس جگہ پر ہے جسے جمع کرنا بہت آسان ہے۔ آپ فوری طور پر کسی چیز کا حساب لگا کر اسے کہیں اپ لوڈ کر سکتے ہیں، مثال کے طور پر، Elasticsearch، Logstash، یا اسے لاگ پر لکھ کر کہیں بھیج سکتے ہیں۔
- ملٹی یوزر سسٹم. مثال کے طور پر، آن لائن گیمز بنانے کے لیے بھی بہت اچھے ہیں۔ آج کیپ ٹاؤن میں، الیگزینڈر گلیڈیش اس بارے میں بات کریں گے کہ OpenResty کا استعمال کرتے ہوئے ملٹی پلیئر گیم کو تیزی سے پروٹو ٹائپ کیسے کیا جائے۔
- درخواست فلٹرنگ (WAF). آج کل ہر قسم کی ویب ایپلیکیشن فائر والز بنانا فیشن ہے؛ بہت سی خدمات ہیں جو انہیں فراہم کرتی ہیں۔ OpenResty کا استعمال کرتے ہوئے، آپ اپنے آپ کو ایک ویب ایپلیکیشن فائر وال بنا سکتے ہیں جو آپ کی ضروریات کے مطابق درخواستوں کو آسانی سے اور آسانی سے فلٹر کرے گا۔ اگر آپ کے پاس ازگر ہے، تو آپ سمجھتے ہیں کہ پی ایچ پی یقینی طور پر آپ کے اندر نہیں لگائی جائے گی، جب تک کہ، یقیناً، آپ اسے کنسول سے کہیں بھی پیدا نہیں کرتے۔ آپ جانتے ہیں کہ آپ کے پاس MySQL اور Python ہے۔ شاید، وہ کسی قسم کی ڈائرکٹری ٹراورسل کرنے کی کوشش کریں گے اور ڈیٹا بیس میں کچھ انجیکشن کریں گے۔ لہذا، آپ سامنے والے حصے میں عجیب و غریب سوالات کو تیزی سے اور سستے طریقے سے فلٹر کر سکتے ہیں۔
- برادری. چونکہ OpenResty NGINX پر بنایا گیا ہے، اس کا ایک بونس ہے - یہ NGINX کمیونٹی. یہ بہت بڑا ہے، اور سوالات کا ایک معقول حصہ جو آپ کے پاس پہلے ہی ہوگا وہ NGINX کمیونٹی نے پہلے ہی حل کر دیا ہے۔
لوا ڈویلپرز. کل میں نے ان لڑکوں سے بات کی جو HighLoad++ ٹریننگ ڈے پر آئے تھے اور سنا تھا کہ Lua میں صرف Tarantool لکھا ہوا تھا۔ یہ سچ نہیں ہے، لوا میں بہت سی باتیں لکھی ہوئی ہیں۔ مثالیں: OpenResty، Prosody XMPP سرور، Love2D گیم انجن، Lua اسکرپٹ میں Warcraft اور دوسری جگہوں پر۔ Lua کے بہت سے ڈویلپرز ہیں، ان کی ایک بڑی اور ذمہ دار کمیونٹی ہے۔ میرے Lua کے تمام سوالات چند گھنٹوں میں حل ہو گئے۔ جب آپ میلنگ لسٹ میں لکھتے ہیں، لفظی طور پر چند منٹوں کے اندر پہلے سے ہی جوابات کا ایک گروپ موجود ہوتا ہے، یہ بیان کرتا ہے کہ کیا اور کیسے، کیا ہے۔ یہ بہت اچھا ہے. بدقسمتی سے، ایسی مہربان، روحانی جماعت ہر جگہ نہیں ہے۔
OpenResty کے لیے GitHub ہے، جہاں کچھ ٹوٹ جانے کی صورت میں آپ کوئی مسئلہ کھول سکتے ہیں۔ گوگل گروپس پر ایک میلنگ لسٹ ہے، جہاں آپ عام مسائل پر بات کر سکتے ہیں، چینی میں ایک میلنگ لسٹ ہے - آپ کبھی نہیں جانتے، شاید آپ انگریزی نہیں بولتے، لیکن آپ چینی جانتے ہیں۔
کے نتائج
- مجھے امید ہے کہ میں یہ بتانے کے قابل تھا کہ OpenResty ویب کے لیے تیار کردہ ایک بہت ہی آسان فریم ورک ہے۔
- اس میں داخلے میں کم رکاوٹ ہے، چونکہ کوڈ اس سے ملتا جلتا ہے جس میں ہم لکھتے ہیں، اس لیے زبان کافی آسان اور کم سے کم ہے۔
- یہ کال بیکس کے بغیر غیر مطابقت پذیر I/O فراہم کرتا ہے، ہمارے پاس کوئی نوڈلز نہیں ہوں گے جیسا کہ ہم کبھی کبھی نوڈ جے ایس میں لکھ سکتے ہیں۔
- اس کی تعیناتی آسان ہے، کیونکہ ہمیں صرف ضروری ماڈیول اور اپنے کوڈ کے ساتھ NGINX کی ضرورت ہے، اور سب کچھ فوراً کام کرتا ہے۔
- بڑی اور ذمہ دار کمیونٹی۔
میں نے تفصیل سے نہیں بتایا کہ روٹنگ کیسے کی جاتی ہے، بہت لمبی کہانی نکلی۔
آپ کا شکریہ!
ماخذ: www.habr.com