کافکا پر ایک غیر مطابقت پذیر API کے ساتھ ریفنڈ ٹول سروس تیار کرنے کا تجربہ

لاموڈا جیسی بڑی کمپنی کو ایک منظم عمل اور درجنوں باہم منسلک خدمات کے ساتھ، اپنے نقطہ نظر کو نمایاں طور پر تبدیل کرنے پر کیا مجبور کر سکتا ہے؟ حوصلہ افزائی بالکل مختلف ہوسکتی ہے: قانون سازی سے لے کر تمام پروگرامرز میں موروثی تجربہ کرنے کی خواہش تک۔

لیکن اس کا مطلب یہ نہیں ہے کہ آپ اضافی فوائد پر اعتماد نہیں کر سکتے۔ Sergey Zaika آپ کو بتائے گا کہ اگر آپ کافکا (کم)۔ یقینی طور پر بڑے شاٹس اور دلچسپ دریافتوں کے بارے میں بھی بات ہوگی - تجربہ ان کے بغیر نہیں ہوسکتا ہے۔

اعلان دستبرداری: یہ مضمون سرجی نے نومبر 2018 میں ہائی لوڈ++ پر ہونے والی میٹنگ کے مواد پر مبنی ہے۔ کافکا کے ساتھ کام کرنے کے لامودا کے لائیو تجربے نے سامعین کو اپنی طرف متوجہ کیا شیڈول پر دیگر رپورٹس سے کم نہیں۔ ہمارے خیال میں یہ اس حقیقت کی ایک بہترین مثال ہے کہ آپ ہمیشہ ہم خیال لوگوں کو تلاش کر سکتے ہیں اور کرنا چاہیے، اور HighLoad++ کے منتظمین اس کے لیے سازگار ماحول بنانے کی کوشش جاری رکھیں گے۔

عمل کے بارے میں

لاموڈا ایک بڑا ای کامرس پلیٹ فارم ہے جس کا اپنا رابطہ مرکز، ڈیلیوری سروس (اور بہت سے ملحقہ ادارے)، ایک فوٹو اسٹوڈیو، ایک بہت بڑا گودام ہے، اور یہ سب اس کے اپنے سافٹ ویئر پر چلتا ہے۔ ادائیگی کے درجنوں طریقے ہیں، b2b پارٹنرز جو ان میں سے کچھ یا تمام خدمات استعمال کر سکتے ہیں اور اپنی مصنوعات کے بارے میں تازہ ترین معلومات جاننا چاہتے ہیں۔ اس کے علاوہ، Lamoda روسی فیڈریشن کے علاوہ تین ممالک میں کام کرتا ہے اور وہاں سب کچھ تھوڑا مختلف ہے۔ مجموعی طور پر، ایک نئے آرڈر کو ترتیب دینے کے شاید سو سے زیادہ طریقے ہیں، جن پر اپنے طریقے سے عمل کیا جانا چاہیے۔ یہ سب درجنوں خدمات کی مدد سے کام کرتا ہے جو کبھی کبھی غیر واضح طریقوں سے بات چیت کرتی ہیں۔ ایک مرکزی نظام بھی ہے جس کی بنیادی ذمہ داری آرڈر کی حیثیت ہے۔ ہم اسے BOB کہتے ہیں، میں اس کے ساتھ کام کرتا ہوں۔

واقعات سے چلنے والے API کے ساتھ رقم کی واپسی کا آلہ

واقعات سے چلنے والا لفظ بالکل ہیکنی ہے؛ تھوڑا آگے ہم مزید تفصیل سے وضاحت کریں گے کہ اس سے کیا مراد ہے۔ میں اس سیاق و سباق سے شروع کروں گا جس میں ہم نے کافکا میں واقعات پر مبنی API اپروچ کو آزمانے کا فیصلہ کیا ہے۔

کسی بھی اسٹور میں، ان آرڈرز کے علاوہ جن کے لیے گاہک ادائیگی کرتے ہیں، ایسے اوقات ہوتے ہیں جب اسٹور کو پیسے واپس کرنے کی ضرورت ہوتی ہے کیونکہ پروڈکٹ گاہک کے مطابق نہیں تھی۔ یہ نسبتاً مختصر عمل ہے: اگر ضروری ہو تو ہم معلومات کو واضح کرتے ہیں اور رقم منتقل کرتے ہیں۔

لیکن قانون سازی میں تبدیلیوں کی وجہ سے واپسی مزید پیچیدہ ہوگئی، اور ہمیں اس کے لیے ایک علیحدہ مائیکرو سروس نافذ کرنا پڑی۔

ہماری حوصلہ افزائی:

1. قانون FZ-54 - مختصراً، قانون کا تقاضا ہے کہ ہر مالیاتی لین دین کے بارے میں ٹیکس آفس کو اطلاع دی جائے، خواہ وہ واپسی ہو یا رسید، چند منٹوں کے کافی مختصر SLA کے اندر۔ ہم، ایک ای کامرس کمپنی کے طور پر، بہت سارے کام انجام دیتے ہیں۔ تکنیکی طور پر، اس کا مطلب ہے نئی ذمہ داری (اور اس لیے ایک نئی سروس) اور تمام متعلقہ نظاموں میں بہتری۔
2. BOB تقسیم BOB کو بڑی تعداد میں غیر بنیادی ذمہ داریوں سے فارغ کرنے اور اس کی مجموعی پیچیدگی کو کم کرنے کے لیے کمپنی کا ایک اندرونی منصوبہ ہے۔

یہ خاکہ لاموڈا کے مرکزی نظام کو ظاہر کرتا ہے۔ اب ان میں سے زیادہ تر ہیں۔ سکڑتے ہوئے یک سنگی کے گرد 5-10 مائیکرو سروسز کا ایک نکشتر. وہ آہستہ آہستہ بڑھ رہے ہیں، لیکن ہم انہیں چھوٹا کرنے کی کوشش کر رہے ہیں، کیونکہ درمیان میں منتخب کردہ ٹکڑے کو تعینات کرنا خوفناک ہے - ہم اسے گرنے کی اجازت نہیں دے سکتے۔ ہم تمام تبادلے (تیر) کو محفوظ رکھنے پر مجبور ہیں اور اس حقیقت کو مدنظر رکھتے ہیں کہ ان میں سے کوئی بھی دستیاب نہ ہو۔

BOB میں بہت سارے تبادلے بھی ہیں: ادائیگی کے نظام، ترسیل کے نظام، اطلاع کے نظام وغیرہ۔

تکنیکی طور پر BOB ہے:

• کوڈ کی ~150k لائنیں + ٹیسٹ کی ~100k لائنیں؛
• php7.2 + Zend 1 اور Symfony اجزاء 3؛
• >100 APIs اور ~50 آؤٹ باؤنڈ انضمام؛
• 4 ممالک جن کی اپنی کاروباری منطق ہے۔

BOB کی تعیناتی مہنگا اور تکلیف دہ ہے، اس سے حل ہونے والے کوڈ اور مسائل کی مقدار ایسی ہے کہ کوئی بھی یہ سب کچھ اپنے سر میں نہیں ڈال سکتا۔ عام طور پر، اسے آسان بنانے کی بہت سی وجوہات ہیں۔

واپسی کا عمل

ابتدائی طور پر، دو نظام اس عمل میں شامل ہیں: BOB اور ادائیگی۔ اب دو اور ظاہر ہوتے ہیں:

• فِسکلائزیشن سروس، جو کہ مالیاتی اور بیرونی خدمات کے ساتھ مواصلت کے مسائل کا خیال رکھے گی۔
• رقم کی واپسی کا ٹول، جس میں صرف نئے تبادلے ہوتے ہیں تاکہ BOB میں اضافہ نہ ہو۔

اب عمل اس طرح لگتا ہے:

1. BOB کو رقم کی واپسی کی درخواست موصول ہوتی ہے۔
2. BOB اس ریفنڈ ٹول کے بارے میں بات کرتا ہے۔
3. رقم کی واپسی کا آلہ ادائیگی کو بتاتا ہے: "پیسے واپس کر دو۔"
4. ادائیگی رقم واپس کرتی ہے۔
5. ریفنڈ ٹول اور BOB اسٹیٹس کو ایک دوسرے کے ساتھ سنکرونائز کرتے ہیں، کیونکہ فی الحال دونوں کو اس کی ضرورت ہے۔ ہم ابھی تک مکمل طور پر ریفنڈ ٹول پر جانے کے لیے تیار نہیں ہیں، کیوں کہ BOB کے پاس UI ہے، اکاؤنٹنگ کے لیے رپورٹس، اور عام طور پر بہت سا ڈیٹا ہے جسے اتنی آسانی سے منتقل نہیں کیا جا سکتا۔ آپ کو دو کرسیوں پر بیٹھنا ہے۔
6. مالیاتی کی درخواست دور ہوجاتی ہے۔

نتیجے کے طور پر، ہم نے کافکا پر ایک قسم کی ایونٹ بس بنائی - ایونٹ بس، جس پر سب کچھ شروع ہوا۔ ارے، اب ہمارے پاس ناکامی کا ایک ہی نقطہ (طنز) ہے۔

فوائد اور نقصانات کافی واضح ہیں۔ ہم نے ایک بس بنائی، جس کا مطلب ہے کہ اب تمام خدمات اس پر منحصر ہیں۔ یہ ڈیزائن کو آسان بناتا ہے، لیکن سسٹم میں ناکامی کا ایک نقطہ متعارف کراتا ہے۔ کافکا کریش ہو جائے گا، عمل رک جائے گا۔

واقعات سے چلنے والا API کیا ہے۔

اس سوال کا ایک اچھا جواب مارٹن فاؤلر (GOTO 2017) کی رپورٹ میں ہے۔ "واقعہ سے چلنے والے فن تعمیر کے بہت سے معنی".

مختصراً ہم نے کیا کیا:

1. کے ذریعے تمام غیر مطابقت پذیر تبادلے کو سمیٹیں۔ واقعات کا ذخیرہ. نیٹ ورک پر ہر دلچسپی رکھنے والے صارف کو اسٹیٹس کی تبدیلی کے بارے میں مطلع کرنے کے بجائے، ہم ایک مرکزی اسٹوریج میں اسٹیٹس کی تبدیلی کے بارے میں ایک واقعہ لکھتے ہیں، اور موضوع میں دلچسپی رکھنے والے صارفین وہاں سے ظاہر ہونے والی ہر چیز کو پڑھتے ہیں۔
2. اس معاملے میں واقعہ ایک اطلاع ہے (اطلاعاتکہ کہیں کچھ بدل گیا ہے۔ مثال کے طور پر، آرڈر کی حیثیت بدل گئی ہے۔ ایک صارف جو اسٹیٹس کی تبدیلی کے ساتھ کچھ ڈیٹا میں دلچسپی رکھتا ہے جو نوٹیفکیشن میں شامل نہیں ہے وہ خود اس کی حیثیت کا پتہ لگا سکتا ہے۔
3. زیادہ سے زیادہ آپشن مکمل ایونٹ سورسنگ ہے، ریاست کی منتقلی, جس ایونٹ میں پروسیسنگ کے لیے ضروری تمام معلومات ہوتی ہیں: یہ کہاں سے آئی اور کس حیثیت میں گئی، ڈیٹا کیسے بدلا، وغیرہ۔ صرف سوال یہ ہے کہ فزیبلٹی اور معلومات کی مقدار جسے آپ ذخیرہ کرنے کے متحمل ہو سکتے ہیں۔

ریفنڈ ٹول کے آغاز کے حصے کے طور پر، ہم نے تیسرا آپشن استعمال کیا۔ اس نے ایونٹ کی پروسیسنگ کو آسان بنا دیا کیونکہ تفصیلی معلومات کو نکالنے کی ضرورت نہیں تھی، اس کے علاوہ اس نے اس منظر نامے کو ختم کر دیا جہاں ہر نیا ایونٹ صارفین کی جانب سے درخواستوں کو حاصل کرنے کے لیے واضح طور پر پیدا کرتا ہے۔

ریفنڈ ٹول سروس لوڈ نہیںتو کافکا کے پاس ضرورت سے زیادہ قلم کا ذائقہ ہے۔ مجھے نہیں لگتا کہ اگر ریفنڈ سروس ایک زیادہ بوجھ والا پروجیکٹ بن جائے تو کاروبار خوش ہوگا۔

Async ایکسچینج AS IS

غیر مطابقت پذیر تبادلے کے لیے، PHP ڈیپارٹمنٹ عام طور پر RabbitMQ استعمال کرتا ہے۔ ہم نے درخواست کے لیے ڈیٹا اکٹھا کیا، اسے ایک قطار میں لگایا، اور اسی سروس کے صارف نے اسے پڑھ کر بھیج دیا (یا نہیں بھیجا)۔ خود API کے لیے، Lamoda فعال طور پر Swagger استعمال کرتا ہے۔ ہم ایک API ڈیزائن کرتے ہیں، اسے Swagger میں بیان کرتے ہیں، اور کلائنٹ اور سرور کوڈ تیار کرتے ہیں۔ ہم تھوڑا بہتر JSON RPC 2.0 بھی استعمال کرتے ہیں۔

کچھ جگہوں پر ESB بسیں استعمال ہوتی ہیں، کچھ ایکٹیو ایم کیو پر رہتی ہیں، لیکن عام طور پر، RabbitMQ - معیاری.

Async ایکسچینج TO BE

واقعات-بس کے ذریعے تبادلے کو ڈیزائن کرتے وقت، ایک مشابہت کا پتہ لگایا جا سکتا ہے۔ ہم اسی طرح مستقبل کے ڈیٹا کے تبادلے کو ایونٹ کی ساخت کی وضاحت کے ذریعے بیان کرتے ہیں۔ یامل فارمیٹ، ہمیں کوڈ جنریشن خود کرنا تھا، جنریٹر تفصیلات کے مطابق ڈی ٹی اوز بناتا ہے اور کلائنٹس اور سرورز کو ان کے ساتھ کام کرنا سکھاتا ہے۔ نسل دو زبانوں میں چلی جاتی ہے۔ گولنگ اور پی ایچ پی. اس سے لائبریریوں کو مستقل رکھنے میں مدد ملتی ہے۔ جنریٹر گولانگ میں لکھا جاتا ہے، اسی لیے اسے گوگی کا نام دیا گیا۔

کافکا پر ایونٹ سورسنگ ایک عام چیز ہے۔ کافکا کنفلوئنٹ کے مرکزی انٹرپرائز ورژن سے ایک حل موجود ہے، وہاں ہے۔ ناکڈی، ہمارے ڈومین برادران زلینڈو کی طرف سے ایک حل۔ ہماری ونیلا کافکا کے ساتھ شروع کرنے کی ترغیب - اس کا مطلب یہ ہے کہ حل کو آزاد چھوڑ دینا جب تک کہ ہم آخر کار یہ فیصلہ نہ کریں کہ آیا ہم اسے ہر جگہ استعمال کریں گے، اور ساتھ ہی ساتھ اپنے آپ کو پینتریبازی اور بہتری کے لیے گنجائش چھوڑ دیں: ہم اپنے لیے تعاون چاہتے ہیں۔ JSON RPC 2.0دو زبانوں کے لیے جنریٹر اور آئیے دیکھتے ہیں کہ اور کیا ہے۔

یہ ستم ظریفی ہے کہ اتنے خوش کن معاملے میں بھی، جب تقریباً اسی طرح کا کاروبار، Zalando، جس نے تقریباً اسی طرح کا حل بنایا، ہم اسے مؤثر طریقے سے استعمال نہیں کر سکتے۔

لانچ کے وقت آرکیٹیکچرل پیٹرن اس طرح ہے: ہم براہ راست کافکا سے پڑھتے ہیں، لیکن صرف واقعات بس کے ذریعے لکھتے ہیں۔ کافکا میں پڑھنے کے لیے بہت کچھ تیار ہے: بروکرز، بیلنسرز، اور یہ افقی پیمانے کے لیے کم و بیش تیار ہے، میں اسے رکھنا چاہتا تھا۔ ہم ایک گیٹ وے عرف ایونٹس بس کے ذریعے ریکارڈنگ مکمل کرنا چاہتے تھے، اور اس کی وجہ یہ ہے۔

تقریبات بس

یا ایونٹ بس۔ یہ محض ایک اسٹیٹ لیس HTTP گیٹ وے ہے، جو کئی اہم کردار ادا کرتا ہے:

• توثیق کی پیداوار - ہم چیک کرتے ہیں کہ واقعات ہماری وضاحتوں پر پورا اترتے ہیں۔
• ایونٹ ماسٹر سسٹم، یعنی، یہ کمپنی کا بنیادی اور واحد نظام ہے جو اس سوال کا جواب دیتا ہے کہ کن واقعات کے ساتھ کن ڈھانچے کو درست سمجھا جاتا ہے۔ توثیق میں مواد کی سختی سے وضاحت کرنے کے لیے صرف ڈیٹا کی قسمیں اور enums شامل ہوتے ہیں۔
• ہیش فنکشن شارڈنگ کے لیے - کافکا پیغام کا ڈھانچہ کلیدی قدر ہے اور کلید کے ہیش کا استعمال کرتے ہوئے اس کا حساب لگایا جاتا ہے کہ اسے کہاں رکھنا ہے۔

کیوں

ہم ایک بڑی کمپنی میں ایک منظم عمل کے ساتھ کام کرتے ہیں۔ کیوں کچھ بدلیں؟ یہ ایک تجربہ ہے۔، اور ہم بہت سے فوائد حاصل کرنے کی توقع کرتے ہیں۔

1:n+1 ایکسچینجز (ایک سے کئی)

کافکا نئے صارفین کو API سے جوڑنا بہت آسان بناتا ہے۔

فرض کریں کہ آپ کے پاس ایک ڈائرکٹری ہے جسے آپ کو ایک ساتھ کئی سسٹمز میں اپ ٹو ڈیٹ رکھنے کی ضرورت ہے (اور کچھ نئے میں)۔ اس سے پہلے، ہم نے ایک بنڈل ایجاد کیا تھا جو سیٹ-API کو نافذ کرتا تھا، اور ماسٹر سسٹم کو صارفین کے پتے سے آگاہ کیا جاتا تھا۔ اب ماسٹر سسٹم موضوع پر اپ ڈیٹس بھیجتا ہے، اور ہر کوئی جو دلچسپی رکھتا ہے اسے پڑھتا ہے۔ ایک نیا نظام ظاہر ہوا ہے - ہم نے اسے موضوع کے لیے سائن اپ کیا ہے۔ ہاں، بنڈل بھی، لیکن آسان۔

ریفنڈ ٹول کے معاملے میں، جو BOB کا ایک ٹکڑا ہے، ہمارے لیے یہ آسان ہے کہ ہم انہیں کافکا کے ذریعے ہم آہنگ رکھیں۔ ادائیگی کا کہنا ہے کہ رقم واپس کردی گئی: BOB، RT کو اس کے بارے میں پتہ چلا، ان کے اسٹیٹس تبدیل کیے گئے، مالیاتی سروس کو اس کے بارے میں پتہ چلا اور ایک چیک جاری کیا۔

ہمارے پاس ایک متحد نوٹیفیکیشن سروس بنانے کا منصوبہ ہے جو کلائنٹ کو اس کے آرڈر/واپسی سے متعلق خبروں کے بارے میں مطلع کرے گی۔ اب یہ ذمہ داری نظاموں کے درمیان پھیلی ہوئی ہے۔ ہمارے لیے نوٹیفیکیشن سروس کو کافکا سے متعلقہ معلومات حاصل کرنے اور اس کا جواب دینے کے لیے (اور دوسرے سسٹمز میں ان اطلاعات کو غیر فعال کرنا) سکھانا کافی ہوگا۔ کسی نئے براہ راست تبادلے کی ضرورت نہیں ہوگی۔

ڈیٹا سے چلنے والا

سسٹمز کے درمیان معلومات شفاف ہو جاتی ہیں - اس سے کوئی فرق نہیں پڑتا ہے کہ آپ کے پاس کوئی بھی "خونی کاروبار" ہے اور اس سے کوئی فرق نہیں پڑتا ہے کہ آپ کا بیک لاگ کتنا ہی بولڈ ہے۔ Lamoda کے پاس ڈیٹا اینالیٹکس کا شعبہ ہے جو سسٹمز سے ڈیٹا اکٹھا کرتا ہے اور اسے دوبارہ قابل استعمال شکل میں رکھتا ہے، کاروبار اور ذہین نظام دونوں کے لیے۔ کافکا آپ کو فوری طور پر انہیں بہت سا ڈیٹا دینے اور اس معلومات کو تازہ ترین رکھنے کی اجازت دیتا ہے۔

نقل لاگ

پیغامات پڑھنے کے بعد غائب نہیں ہوتے ہیں، جیسا کہ RabbitMQ میں ہے۔ جب کسی ایونٹ میں پروسیسنگ کے لیے کافی معلومات ہوتی ہیں، تو ہمارے پاس آبجیکٹ میں حالیہ تبدیلیوں کی تاریخ ہوتی ہے، اور اگر چاہیں تو، ان تبدیلیوں کو لاگو کرنے کی اہلیت۔

نقل کے لاگ کا ذخیرہ کرنے کا دورانیہ اس موضوع پر لکھنے کی شدت پر منحصر ہے؛ کافکا آپ کو سٹوریج کے وقت اور ڈیٹا کے حجم کی حد مقرر کرنے کی اجازت دیتا ہے۔ گہرے موضوعات کے لیے، یہ ضروری ہے کہ تمام صارفین کے پاس معلومات کے غائب ہونے سے پہلے اسے پڑھنے کا وقت ہو، حتیٰ کہ قلیل مدتی ناکارہ ہونے کی صورت میں بھی۔ کے لیے ڈیٹا ذخیرہ کرنا عام طور پر ممکن ہے۔ دنوں کی اکائیاںجو کہ حمایت کے لیے کافی ہے۔

اس کے بعد، دستاویزات کا تھوڑا سا دوبارہ بیان، ان لوگوں کے لیے جو کافکا سے واقف نہیں ہیں (تصویر بھی دستاویزات سے ہے)

AMQP کی قطاریں ہیں: ہم صارفین کے لیے ایک قطار میں پیغامات لکھتے ہیں۔ عام طور پر، ایک قطار ایک ہی کاروباری منطق کے ساتھ ایک سسٹم کے ذریعہ پروسیس کی جاتی ہے۔ اگر آپ کو متعدد سسٹمز کو مطلع کرنے کی ضرورت ہے، تو آپ ایپلیکیشن کو کئی قطاروں میں لکھنا سکھا سکتے ہیں یا فین آؤٹ میکانزم کے ساتھ تبادلے کو ترتیب دے سکتے ہیں، جو انہیں خود کلون کرتا ہے۔

کافکا کا بھی اسی طرح کا خلاصہ ہے۔ موضوعجس میں آپ میسج لکھتے ہیں لیکن پڑھنے کے بعد غائب نہیں ہوتے۔ پہلے سے طے شدہ طور پر، جب آپ کافکا سے منسلک ہوتے ہیں، تو آپ کو تمام پیغامات موصول ہوتے ہیں اور آپ کے پاس محفوظ کرنے کا اختیار ہوتا ہے جہاں آپ نے چھوڑا تھا۔ یعنی آپ ترتیب وار پڑھتے ہیں، آپ پیغام کو پڑھا ہوا نشان نہیں لگا سکتے، لیکن اس آئی ڈی کو محفوظ کریں جس سے آپ پڑھنا جاری رکھ سکتے ہیں۔ جس آئی ڈی پر آپ نے سیٹل کیا اسے آفسیٹ کہا جاتا ہے، اور میکانزم کمٹ آفسیٹ ہے۔

اس کے مطابق، مختلف منطق کو لاگو کیا جا سکتا ہے. مثال کے طور پر، ہمارے پاس مختلف ممالک کے لیے 4 مثالوں میں BOB ہے - Lamoda روس، قازقستان، یوکرین، بیلاروس میں ہے۔ چونکہ وہ الگ سے تعینات کیے گئے ہیں، ان کے پاس قدرے مختلف کنفیگرز اور ان کی اپنی کاروباری منطق ہے۔ ہم پیغام میں اشارہ کرتے ہیں کہ یہ کس ملک کا حوالہ دیتا ہے۔ ہر ملک میں ہر BOB صارف ایک مختلف گروپ آئی ڈی کے ساتھ پڑھتا ہے، اور اگر پیغام ان پر لاگو نہیں ہوتا ہے، تو وہ اسے چھوڑ دیتے ہیں، یعنی فوری طور پر آفسیٹ +1 کا ارتکاب کرتا ہے۔ اگر اسی موضوع کو ہماری ادائیگی کی خدمت پڑھتی ہے، تو یہ ایک الگ گروپ کے ساتھ ایسا کرتی ہے، اور اس لیے آفسیٹس آپس میں نہیں بٹتے ہیں۔

ایونٹ کی ضروریات:

• ڈیٹا کی تکمیل۔ میں چاہوں گا کہ ایونٹ میں کافی ڈیٹا ہو تاکہ اس پر کارروائی کی جا سکے۔

• سالمیت۔ ہم ایونٹس بس کو اس توثیق کی ذمہ داری سونپتے ہیں کہ ایونٹ مطابقت رکھتا ہے اور وہ اس پر کارروائی کر سکتا ہے۔
• حکم اہم ہے۔ واپسی کی صورت میں ہم تاریخ سے کام لینے پر مجبور ہیں۔ نوٹیفیکیشنز کے ساتھ، آرڈر اہم نہیں ہے، اگر وہ یکساں اطلاعات ہیں، تو ای میل ایک جیسی ہو گی، قطع نظر اس سے کہ پہلے آرڈر آیا ہو۔ رقم کی واپسی کی صورت میں، ایک واضح عمل ہے؛ اگر ہم آرڈر کو تبدیل کرتے ہیں تو مستثنیات پیدا ہوں گے، رقم کی واپسی کی تخلیق یا کارروائی نہیں کی جائے گی - ہم ایک مختلف حیثیت میں ختم ہوجائیں گے۔
• مستقل مزاجی. ہمارے پاس ایک اسٹور ہے، اور اب ہم API کے بجائے ایونٹس بناتے ہیں۔ ہمیں اپنی خدمات میں نئے واقعات اور موجودہ واقعات میں تبدیلیوں کے بارے میں معلومات کو فوری اور سستے طریقے سے منتقل کرنے کا ایک طریقہ درکار ہے۔ یہ ایک الگ گٹ ریپوزٹری اور کوڈ جنریٹرز میں مشترکہ تفصیلات کا استعمال کرتے ہوئے حاصل کیا جاتا ہے۔ لہذا، مختلف خدمات میں گاہکوں اور سرورز کو مربوط کیا جاتا ہے.

لامودا میں کافکا

ہمارے پاس تین کافکا تنصیبات ہیں:

1. نوشتہ جات
2. R&D;
3. تقریبات بس۔

آج ہم صرف آخری نکتے پر بات کر رہے ہیں۔ ایونٹس بس میں، ہمارے پاس بہت بڑی تنصیبات نہیں ہیں - 3 بروکرز (سرور) اور صرف 27 عنوانات۔ ایک اصول کے طور پر، ایک موضوع ایک عمل ہے. لیکن یہ ایک لطیف نکتہ ہے، اور ہم اب اس پر بات کریں گے۔

اوپر آر پی ایس گراف ہے۔ رقم کی واپسی کے عمل کو فیروزی لائن (جی ہاں، X محور پر) کے ساتھ نشان زد کیا گیا ہے، اور گلابی لائن مواد کو اپ ڈیٹ کرنے کا عمل ہے۔

Lamoda کیٹلاگ میں لاکھوں مصنوعات شامل ہیں، اور ڈیٹا کو ہر وقت اپ ڈیٹ کیا جاتا ہے۔ کچھ مجموعے فیشن سے باہر ہو جاتے ہیں، ان کی جگہ لینے کے لیے نئے جاری کیے جاتے ہیں، اور نئے ماڈلز کیٹلاگ میں مسلسل آ رہے ہیں۔ ہم یہ پیشین گوئی کرنے کی کوشش کرتے ہیں کہ کل ہمارے صارفین کے لیے کیا دلچسپ ہوگا، اس لیے ہم مسلسل نئی چیزیں خریدتے ہیں، ان کی تصویر کشی کرتے ہیں اور ڈسپلے کیس کو اپ ڈیٹ کرتے ہیں۔

گلابی چوٹیاں مصنوعات کی تازہ کارییں ہیں، یعنی مصنوعات میں تبدیلیاں۔ دیکھا جا سکتا ہے کہ لڑکوں نے تصویریں کھینچیں، تصویریں کھینچیں، اور پھر! - واقعات کا ایک پیکٹ لوڈ کیا۔

لاموڈا ایونٹس کیسز کا استعمال کرتے ہیں۔

ہم مندرجہ ذیل کاموں کے لیے تعمیر شدہ فن تعمیر کا استعمال کرتے ہیں:

• واپسی کی حیثیت سے باخبر رہنا: تمام شامل نظاموں سے کال ٹو ایکشن اور اسٹیٹس ٹریکنگ۔ ادائیگی، حیثیت، مالیاتی، اطلاعات۔ یہاں ہم نے نقطہ نظر کا تجربہ کیا، ٹولز بنائے، تمام کیڑے اکٹھے کیے، دستاویزات لکھیں اور اپنے ساتھیوں کو بتایا کہ اسے کیسے استعمال کیا جائے۔
• پروڈکٹ کارڈز کو اپ ڈیٹ کرنا: ترتیب، میٹا ڈیٹا، خصوصیات۔ ایک سسٹم پڑھتا ہے (جو دکھاتا ہے) اور کئی لکھتے ہیں۔
• ای میل، پش اور ایس ایم ایس: آرڈر جمع ہو گیا، آرڈر آ گیا، واپسی قبول ہو گئی، وغیرہ، ان میں سے بہت کچھ ہیں۔
• اسٹاک، گودام کی تجدید - اشیاء کی مقداری اپ ڈیٹ، صرف نمبر: گودام میں آمد، واپسی۔ یہ ضروری ہے کہ سامان محفوظ کرنے سے وابستہ تمام نظام جدید ترین ڈیٹا کے ساتھ کام کریں۔ فی الحال، اسٹاک اپ ڈیٹ کا نظام کافی پیچیدہ ہے؛ کافکا اسے آسان بنائے گا۔
• ڈیٹا انیلیسیز کی (آر اینڈ ڈی ڈیپارٹمنٹ)، ایم ایل ٹولز، تجزیات، شماریات۔ ہم چاہتے ہیں کہ معلومات شفاف ہوں - کافکا اس کے لیے موزوں ہے۔

اب ان بڑے ٹکڑوں اور دلچسپ دریافتوں کے بارے میں زیادہ دلچسپ حصہ جو پچھلے چھ مہینوں میں ہوئی ہیں۔

ڈیزائن کے مسائل

ہم کہتے ہیں کہ ہم ایک نیا کام کرنا چاہتے ہیں - مثال کے طور پر، پورے ترسیل کے عمل کو کافکا کو منتقل کریں۔ اب اس عمل کا ایک حصہ BOB میں آرڈر پروسیسنگ میں لاگو ہوتا ہے۔ ڈیلیوری سروس میں آرڈر کی منتقلی، انٹرمیڈیٹ گودام میں نقل و حرکت، وغیرہ کے پیچھے ایک سٹیٹس ماڈل ہوتا ہے۔ یہاں ایک مکمل یک سنگی، یہاں تک کہ دو، نیز ترسیل کے لیے وقف APIs کا ایک گروپ ہے۔ وہ ترسیل کے بارے میں بہت کچھ جانتے ہیں۔

بظاہر یہ ایک جیسے علاقے ہیں، لیکن BOB میں آرڈر پروسیسنگ اور شپنگ سسٹم کی حیثیت مختلف ہے۔ مثال کے طور پر، کچھ کورئیر سروسز انٹرمیڈیٹ سٹیٹس نہیں بھیجتی ہیں، بلکہ صرف آخری: "ڈیلیور شدہ" یا "گمشدہ"۔ دوسرے، اس کے برعکس، سامان کی نقل و حرکت کے بارے میں بہت تفصیل سے رپورٹ کرتے ہیں۔ ہر ایک کے اپنے توثیق کے اصول ہیں: کچھ کے لیے، ای میل درست ہے، جس کا مطلب ہے کہ اس پر کارروائی کی جائے گی۔ دوسروں کے لیے یہ درست نہیں ہے، لیکن پھر بھی آرڈر پر کارروائی کی جائے گی کیونکہ رابطہ کے لیے ایک فون نمبر موجود ہے، اور کوئی کہے گا کہ اس طرح کے حکم پر عمل نہیں کیا جائے گا۔

ڈیٹا اسٹریم

کافکا کے معاملے میں ڈیٹا کے بہاؤ کو منظم کرنے کا سوال پیدا ہوتا ہے۔ اس کام میں کئی نکات کی بنیاد پر حکمت عملی کا انتخاب شامل ہے؛ آئیے ان سب کو دیکھتے ہیں۔

ایک موضوع میں یا مختلف میں؟

ہمارے پاس ایونٹ کی تفصیلات ہیں۔ BOB میں ہم لکھتے ہیں کہ فلاں اور فلاں آرڈر ڈیلیور کرنے کی ضرورت ہے، اور اشارہ کرتے ہیں: آرڈر نمبر، اس کی ساخت، کچھ SKUs اور بار کوڈز وغیرہ۔ جب سامان گودام میں پہنچتا ہے، ڈیلیوری اسٹیٹس، ٹائم اسٹیمپ اور ہر وہ چیز حاصل کر سکے گی جس کی ضرورت ہے۔ لیکن پھر ہم BOB میں اس ڈیٹا پر اپ ڈیٹس حاصل کرنا چاہتے ہیں۔ ہمارے پاس ڈیلیوری سے ڈیٹا وصول کرنے کا ایک الٹا عمل ہے۔ کیا یہ وہی واقعہ ہے؟ یا یہ ایک الگ تبادلہ ہے جو اپنے موضوع کا مستحق ہے؟

زیادہ تر امکان ہے کہ وہ بہت ملتے جلتے ہوں گے، اور ایک موضوع بنانے کا لالچ بے بنیاد نہیں ہے، کیونکہ ایک الگ موضوع کا مطلب ہے الگ صارفین، الگ کنفیگرز، ان سب کی الگ نسل۔ لیکن حقیقت نہیں۔

نیا میدان یا نیا واقعہ؟

لیکن اگر آپ انہی واقعات کو استعمال کرتے ہیں تو پھر ایک اور مسئلہ پیدا ہو جاتا ہے۔ مثال کے طور پر، تمام ڈیلیوری سسٹم اس قسم کا DTO پیدا نہیں کر سکتے جو BOB پیدا کر سکتا ہے۔ ہم انہیں آئی ڈی بھیجتے ہیں، لیکن وہ اسے محفوظ نہیں کرتے کیونکہ انہیں اس کی ضرورت نہیں ہے، اور ایونٹ بس عمل شروع کرنے کے نقطہ نظر سے، یہ فیلڈ درکار ہے۔

اگر ہم ایونٹ بس کے لیے ایک اصول متعارف کراتے ہیں کہ یہ فیلڈ درکار ہے، تو ہمیں BOB میں یا سٹارٹ ایونٹ ہینڈلر میں توثیق کے اضافی اصول مرتب کرنے پر مجبور کیا جاتا ہے۔ توثیق پوری سروس میں پھیلنا شروع ہو جاتی ہے - یہ بہت آسان نہیں ہے۔

ایک اور مسئلہ بڑھتی ہوئی ترقی کا لالچ ہے۔ ہمیں بتایا جاتا ہے کہ ایونٹ میں کچھ شامل کرنے کی ضرورت ہے، اور شاید، اگر ہم اس کے بارے میں سوچتے ہیں، تو یہ ایک الگ واقعہ ہونا چاہیے تھا۔ لیکن ہماری اسکیم میں ایک الگ واقعہ ایک الگ موضوع ہے۔ ایک الگ موضوع وہ سارا عمل ہے جسے میں نے اوپر بیان کیا ہے۔ ڈویلپر کو صرف JSON اسکیما میں ایک اور فیلڈ شامل کرنے اور اسے دوبارہ تخلیق کرنے کا لالچ دیا جاتا ہے۔

رقم کی واپسی کے معاملے میں، ہم آدھے سال میں ہونے والے واقعات کے موقع پر پہنچے۔ ہمارے پاس ایک میٹا ایونٹ تھا جسے ریفنڈ اپ ڈیٹ کہتے ہیں، جس میں ایک قسم کا فیلڈ تھا جس میں بتایا گیا تھا کہ یہ اپ ڈیٹ اصل میں کیا ہے۔ اس کی وجہ سے، ہمارے پاس توثیق کرنے والوں کے ساتھ "شاندار" سوئچز تھے جنہوں نے ہمیں بتایا کہ اس قسم کے ساتھ اس ایونٹ کی توثیق کیسے کی جائے۔

ایونٹ ورژننگ

کافکا میں پیغامات کی توثیق کرنے کے لیے آپ استعمال کر سکتے ہیں۔ یورو، لیکن اسے فوری طور پر اس پر رکھنا اور Confluent استعمال کرنا ضروری تھا۔ ہمارے معاملے میں، ہمیں ورژن بنانے میں محتاط رہنا ہوگا۔ نقل کے لاگ سے پیغامات کو دوبارہ پڑھنا ہمیشہ ممکن نہیں ہوگا کیونکہ ماڈل میں "بائیں" ہے۔ بنیادی طور پر، یہ ورژن بنانے کے لیے نکلتا ہے تاکہ ماڈل پیچھے کی طرف مطابقت رکھتا ہو: مثال کے طور پر، کسی فیلڈ کو عارضی طور پر اختیاری بنائیں۔ اگر اختلافات بہت مضبوط ہیں، تو ہم ایک نئے موضوع میں لکھنا شروع کر دیتے ہیں، اور کلائنٹس کو منتقل کر دیتے ہیں جب وہ پرانے کو پڑھ کر ختم کر دیتے ہیں۔

پارٹیشنز کے پڑھنے کے آرڈر کی ضمانت

کافکا کے اندر کے موضوعات کو پارٹیشنز میں تقسیم کیا گیا ہے۔ جب ہم ہستیوں اور تبادلے کو ڈیزائن کر رہے ہیں تو یہ بہت اہم نہیں ہے، لیکن یہ فیصلہ کرتے وقت اہم ہے کہ اسے کس طرح استعمال کیا جائے اور اس کی پیمائش کیسے کی جائے۔

عام صورت میں، آپ کافکا میں ایک موضوع لکھتے ہیں۔ پہلے سے طے شدہ طور پر، ایک پارٹیشن استعمال کیا جاتا ہے، اور اس موضوع کے تمام پیغامات اس پر جاتے ہیں۔ اور اس کے نتیجے میں صارف ان پیغامات کو ترتیب وار پڑھتا ہے۔ چلیں اب ہمیں سسٹم کو وسعت دینے کی ضرورت ہے تاکہ پیغامات دو مختلف صارفین پڑھ سکیں۔ اگر، مثال کے طور پر، آپ ایس ایم ایس بھیج رہے ہیں، تو آپ کافکا کو ایک اضافی تقسیم کرنے کے لیے کہہ سکتے ہیں، اور کافکا پیغامات کو دو حصوں میں تقسیم کرنا شروع کر دے گا - آدھا یہاں، آدھا یہاں۔

کافکا انہیں کیسے تقسیم کرتا ہے؟ ہر پیغام میں ایک باڈی ہوتی ہے (جس میں ہم JSON اسٹور کرتے ہیں) اور ایک کلید۔ آپ اس کلید کے ساتھ ایک ہیش فنکشن منسلک کر سکتے ہیں، جو اس بات کا تعین کرے گا کہ پیغام کس پارٹیشن میں جائے گا۔

ہمارے ریفنڈ کے معاملے میں، یہ ضروری ہے، اگر ہم دو پارٹیشن لیتے ہیں، تو اس بات کا امکان ہے کہ ایک متوازی صارف دوسرے ایونٹ کو پہلے سے پہلے پروسیس کرے گا اور پریشانی ہوگی۔ ہیش فنکشن اس بات کو یقینی بناتا ہے کہ ایک ہی کلید والے پیغامات ایک ہی پارٹیشن میں ختم ہوں۔

واقعات بمقابلہ کمانڈز

یہ ایک اور مسئلہ ہے جس کا ہم نے سامنا کیا۔ واقعہ ایک خاص واقعہ ہے: ہم کہتے ہیں کہ کہیں کچھ ہوا (something_happened)، مثال کے طور پر، کوئی آئٹم منسوخ کر دیا گیا یا رقم کی واپسی ہوئی۔ اگر کوئی ان واقعات کو سنتا ہے، تو "آئٹم کینسل" کے مطابق ریفنڈ ہستی بنائی جائے گی، اور سیٹ اپ میں کہیں کہیں لکھا جائے گا "ریفنڈ ہوا"۔

لیکن عام طور پر، جب آپ ایونٹس کو ڈیزائن کرتے ہیں، تو آپ انہیں بیکار نہیں لکھنا چاہتے - آپ اس حقیقت پر بھروسہ کرتے ہیں کہ کوئی انہیں پڑھے گا۔ کچھ نہ کچھ_ہوا (آئٹم_منسوخ شدہ، رقم کی_ریفنڈ) نہیں بلکہ کچھ_ہونا_ہونا_ہونا لکھنے کا بہت بڑا لالچ ہے۔ مثال کے طور پر، آئٹم واپس کرنے کے لیے تیار ہے۔

ایک طرف، یہ بتاتا ہے کہ ایونٹ کیسے استعمال کیا جائے گا. دوسری طرف، یہ ایک عام واقعہ کے نام کی طرح بہت کم لگتا ہے۔ اس کے علاوہ، do_something کمانڈ یہاں سے زیادہ دور نہیں ہے۔ لیکن آپ کو اس بات کی کوئی ضمانت نہیں ہے کہ کسی نے یہ واقعہ پڑھا ہے۔ اور اگر آپ اسے پڑھتے ہیں، تو آپ اسے کامیابی سے پڑھتے ہیں۔ اور اگر آپ نے اسے کامیابی سے پڑھا، تو آپ نے کچھ کیا، اور وہ کچھ کامیاب ہوا۔ جس لمحے کوئی واقعہ do_something بن جاتا ہے، فیڈ بیک ضروری ہو جاتا ہے، اور یہ ایک مسئلہ ہے۔

RabbitMQ میں غیر مطابقت پذیر تبادلے میں، جب آپ پیغام کو پڑھتے ہیں، http پر جائیں، آپ کے پاس جواب ہوتا ہے - کم از کم یہ کہ پیغام موصول ہوا تھا۔ جب آپ کافکا کو لکھتے ہیں، تو ایک پیغام ہوتا ہے جو آپ نے کافکا کو لکھا تھا، لیکن آپ اس کے بارے میں کچھ نہیں جانتے کہ اس پر عمل کیسے ہوا۔

لہٰذا، ہمارے معاملے میں، ہمیں ایک رسپانس ایونٹ متعارف کروانا پڑا اور مانیٹرنگ قائم کرنی پڑی تاکہ اگر اتنے واقعات بھیجے جائیں تو فلاں وقت کے بعد اتنی ہی تعداد میں ریسپانس ایونٹس پہنچیں۔ ایسا نہ ہوا تو لگتا ہے کچھ گڑبڑ ہو گئی ہے۔ مثال کے طور پر، اگر ہم نے "item_ready_to_refund" ایونٹ بھیجا ہے، تو ہم توقع کرتے ہیں کہ ریفنڈ ہو جائے گا، رقم کلائنٹ کو واپس کر دی جائے گی، اور "money_refunded" ایونٹ ہمیں بھیجا جائے گا۔ لیکن یہ یقینی نہیں ہے، لہذا نگرانی کی ضرورت ہے.

Nuances

ایک واضح مسئلہ ہے: اگر آپ کسی موضوع سے ترتیب وار پڑھتے ہیں، اور آپ کے پاس کوئی برا پیغام ہے، تو صارف گر جائے گا، اور آپ آگے نہیں بڑھیں گے۔ آپ کو ضرورت ہے تمام صارفین کو روکیں۔پڑھنا جاری رکھنے کے لیے مزید آفسیٹ کا عہد کریں۔

ہم اس کے بارے میں جانتے تھے، ہم نے اس پر اعتماد کیا، اور پھر بھی یہ ہوا۔ اور ایسا اس لیے ہوا کیونکہ ایونٹ ایونٹس بس کے نقطہ نظر سے درست تھا، ایپلیکیشن ویلیڈیٹر کے نقطہ نظر سے واقعہ درست تھا، لیکن PostgreSQL کے نقطہ نظر سے یہ درست نہیں تھا، کیونکہ ہمارے سسٹم میں MySQL غیر دستخط شدہ INT کے ساتھ سسٹم میں پوسٹگری ایس کیو ایل صرف INT کے ساتھ تھا۔ اس کا سائز تھوڑا چھوٹا ہے، اور آئی ڈی فٹ نہیں ہے. سیمفونی کی موت ایک استثناء کے ساتھ ہوئی۔ ہم نے، یقیناً، استثناء کو پکڑا کیونکہ ہم اس پر بھروسہ کرتے تھے، اور اس آفسیٹ کا ارتکاب کرنے جا رہے تھے، لیکن اس سے پہلے ہم مسئلہ کاؤنٹر کو بڑھانا چاہتے تھے، کیونکہ پیغام پر ناکام کارروائی ہوئی تھی۔ اس پروجیکٹ کے کاؤنٹر بھی ڈیٹا بیس میں ہیں، اور Symfony نے ڈیٹا بیس کے ساتھ مواصلات کو پہلے ہی بند کر دیا ہے، اور دوسری رعایت نے آفسیٹ کا ارتکاب کرنے کے موقع کے بغیر پورے عمل کو ختم کر دیا۔

سروس کچھ دیر کے لیے لیٹ رہی - خوش قسمتی سے، کافکا کے ساتھ یہ اتنا برا نہیں ہے، کیونکہ پیغامات باقی ہیں۔ کام بحال ہونے پر، آپ انہیں پڑھنا مکمل کر سکتے ہیں۔ یہ آرام دہ ہے۔

کافکا ٹولنگ کے ذریعے صوابدیدی آف سیٹ سیٹ کرنے کی صلاحیت رکھتا ہے۔ لیکن ایسا کرنے کے لیے، آپ کو تمام صارفین کو روکنے کی ضرورت ہے - ہمارے معاملے میں، ایک علیحدہ ریلیز تیار کریں جس میں کوئی صارفین، دوبارہ تعیناتی نہیں ہوگی۔ پھر کافکا میں آپ آفسیٹ کو ٹولنگ کے ذریعے شفٹ کر سکتے ہیں، اور پیغام گزر جائے گا۔

ایک اور نزاکت - نقل لاگ بمقابلہ rdkafka.so - ہمارے منصوبے کی تفصیلات سے متعلق ہے۔ ہم پی ایچ پی کا استعمال کرتے ہیں، اور پی ایچ پی میں، ایک اصول کے طور پر، تمام لائبریریاں کافکا کے ساتھ rdkafka.so ریپوزٹری کے ذریعے بات چیت کرتی ہیں، اور پھر ایک قسم کا ریپر ہوتا ہے۔ شاید یہ ہماری ذاتی مشکلات ہیں، لیکن معلوم ہوا کہ جو کچھ ہم پہلے پڑھ چکے ہیں اسے دوبارہ پڑھنا اتنا آسان نہیں ہے۔ عام طور پر، سافٹ ویئر کے مسائل تھے.

پارٹیشنز کے ساتھ کام کرنے کی تفصیلات پر واپس آتے ہوئے، یہ دستاویزات میں ہی لکھا گیا ہے۔ صارفین >= ٹاپک پارٹیشنز. لیکن مجھے اس کے بارے میں بہت بعد میں پتہ چلا جتنا میں پسند کروں گا۔ اگر آپ پیمانہ بنانا چاہتے ہیں اور دو صارفین ہیں تو آپ کو کم از کم دو پارٹیشنز کی ضرورت ہے۔ یعنی، اگر آپ کے پاس ایک پارٹیشن تھا جس میں 20 ہزار پیغامات جمع ہوئے تھے، اور آپ نے ایک نیا بنایا، تو پیغامات کی تعداد جلد برابر نہیں ہوگی۔ لہذا، دو متوازی صارفین رکھنے کے لیے، آپ کو پارٹیشنز سے نمٹنے کی ضرورت ہے۔

نگرانی

مجھے لگتا ہے کہ جس طرح سے ہم اس کی نگرانی کریں گے وہ اور بھی واضح ہو جائے گا کہ موجودہ نقطہ نظر میں کیا مسائل ہیں۔

مثال کے طور پر، ہم حساب لگاتے ہیں کہ حال ہی میں ڈیٹا بیس میں کتنی مصنوعات نے اپنی حیثیت تبدیل کی ہے، اور، اس کے مطابق، ان تبدیلیوں کی بنیاد پر واقعات رونما ہونے چاہیے تھے، اور ہم یہ نمبر اپنے مانیٹرنگ سسٹم کو بھیجتے ہیں۔ پھر کافکا سے ہمیں دوسرا نمبر ملتا ہے کہ حقیقت میں کتنے واقعات ریکارڈ کیے گئے۔ ظاہر ہے، ان دو نمبروں کے درمیان فرق ہمیشہ صفر ہونا چاہیے۔

اس کے علاوہ، آپ کو یہ مانیٹر کرنے کی ضرورت ہے کہ پروڈیوسر کیسا کام کر رہا ہے، آیا ایونٹس-بس کو پیغامات موصول ہوئے، اور صارف کیسا کر رہا ہے۔ مثال کے طور پر، نیچے دیئے گئے چارٹس میں، ریفنڈ ٹول اچھی کارکردگی کا مظاہرہ کر رہا ہے، لیکن BOB میں واضح طور پر کچھ مسائل ہیں (نیلی چوٹیوں)۔

میں نے پہلے ہی صارف گروپ وقفہ کا ذکر کیا ہے۔ موٹے طور پر، یہ بغیر پڑھے ہوئے پیغامات کی تعداد ہے۔ عام طور پر، ہمارے صارفین تیزی سے کام کرتے ہیں، اس لیے وقفہ عام طور پر 0 ہوتا ہے، لیکن بعض اوقات قلیل مدتی چوٹی بھی ہو سکتی ہے۔ کافکا یہ کام آؤٹ آف دی باکس کر سکتا ہے، لیکن آپ کو ایک خاص وقفہ طے کرنے کی ضرورت ہے۔

ایک پروجیکٹ ہے۔ دفنجو آپ کو کافکا کے بارے میں مزید معلومات فراہم کرے گا۔ یہ صرف صارف گروپ API کا استعمال کرتا ہے تاکہ یہ اسٹیٹس دیا جا سکے کہ یہ گروپ کیسے کام کر رہا ہے۔ OK اور Failed کے علاوہ، ایک انتباہ بھی ہے، اور آپ یہ جان سکتے ہیں کہ آپ کے صارفین پیداوار کی رفتار کا مقابلہ نہیں کر سکتے ہیں - ان کے پاس لکھی ہوئی چیزوں کو پروف ریڈ کرنے کا وقت نہیں ہے۔ سسٹم کافی سمارٹ اور استعمال میں آسان ہے۔

API کا جواب ایسا لگتا ہے۔ یہ ہے گروپ bob-live-fifa، partition refund.update.v1، اسٹیٹس OK، lag 0 - آخری فائنل آف سیٹ فلاں فلاں۔

نگرانی update_at SLA (پھنس گیا) میں نے پہلے ہی ذکر کیا ہے۔ مثال کے طور پر، پروڈکٹ اس حیثیت میں بدل گئی ہے کہ وہ واپسی کے لیے تیار ہے۔ ہم کرون انسٹال کرتے ہیں، جو کہتا ہے کہ اگر 5 منٹ میں یہ اعتراض ریفنڈ کے لیے نہیں گیا ہے (ہم ادائیگی کے نظام کے ذریعے بہت جلد رقم واپس کر دیتے ہیں)، تو یقینی طور پر کچھ غلط ہو گیا ہے، اور یہ یقینی طور پر سپورٹ کا معاملہ ہے۔ لہذا، ہم صرف کرون لیتے ہیں، جو ایسی چیزوں کو پڑھتا ہے، اور اگر وہ 0 سے زیادہ ہیں، تو یہ ایک الرٹ بھیجتا ہے۔

خلاصہ کرنے کے لئے، واقعات کا استعمال کرنا آسان ہے جب:

• کئی نظاموں کے لیے معلومات کی ضرورت ہوتی ہے۔
• پروسیسنگ کا نتیجہ اہم نہیں ہے؛
• کچھ واقعات یا چھوٹے واقعات ہیں۔

ایسا لگتا ہے کہ مضمون کا ایک خاص موضوع ہے - کافکا پر غیر مطابقت پذیر API، لیکن اس کے سلسلے میں میں ایک ساتھ بہت سی چیزوں کی سفارش کرنا چاہوں گا۔
پہلے، اگلا ہائی لوڈ++ ہمیں نومبر تک انتظار کرنا ہوگا؛ اپریل میں سینٹ پیٹرزبرگ کا ورژن ہوگا، اور جون میں ہم نووسیبرسک میں زیادہ بوجھ کے بارے میں بات کریں گے۔
دوم، رپورٹ کے مصنف، سرگئی زائیکا، علم کے انتظام پر ہماری نئی کانفرنس کی پروگرام کمیٹی کے رکن ہیں۔ KnowledgeConf. کانفرنس ایک روزہ ہے، 26 اپریل کو ہو گی، لیکن اس کا پروگرام بہت شدید ہے۔
اور یہ مئی میں ہوگا۔ پی ایچ پی روس и RIT++ (جس میں DevOpsConf شامل ہے) - آپ وہاں اپنا موضوع بھی تجویز کر سکتے ہیں، اپنے تجربے کے بارے میں بات کر سکتے ہیں اور اپنے بھرے کونز کے بارے میں شکایت کر سکتے ہیں۔

ماخذ: www.habr.com