په کافکا کې د اسینکرونس API سره د بیرته راستنیدو وسیلې خدمت رامینځته کولو کې تجربه

څه شی کولی شي د لامودا په څیر لوی شرکت د منظم پروسې او لسګونه یو بل سره تړلي خدماتو سره د پام وړ بدلون ته اړ کړي؟ هڅونه په بشپړ ډول توپیر کیدی شي: له مقننه څخه تر ټولو پروګرامرانو کې د تجربه کولو لیوالتیا پورې.

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

اعلامیه: دا مقاله د هغه غونډې د موادو پراساس ده چې سرګي په نومبر 2018 کې په HighLoad++ کې ترسره کړه. له کافکا سره د لامودا ژوندۍ تجربې د مهال ویش له نورو راپورونو څخه لږ اوریدونکي راجلب کړل. موږ فکر کوو چې دا د دې حقیقت یوه غوره بیلګه ده چې تاسو کولی شئ او تل باید ورته فکر لرونکي خلک ومومئ ، او د HighLoad++ تنظیم کونکي به د دې لپاره مناسبه فضا رامینځته کولو هڅې ته دوام ورکړي.

د پروسې په اړه

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

د پیښو لخوا پرمخ وړل شوي API سره د بیرته ورکولو وسیله

د پیښو لخوا پرمخ وړل شوي کلمه خورا پیچلې ده؛ یو څه نور به موږ په تفصیل سره تعریف کړو چې د دې معنی څه ده. زه به د هغه شرایطو سره پیل وکړم په کوم کې چې موږ پریکړه وکړه چې په کافکا کې د پیښو لخوا پرمخ وړل شوي API چلند هڅه وکړو.

په هر پلورنځي کې، د هغو امرونو سربیره چې پیرودونکي یې تادیه کوي، ځینې وختونه شتون لري کله چې پلورنځي د پیسو بیرته ستنیدو ته اړتیا لري ځکه چې محصول د پیرودونکي سره مناسب نه و. دا یو نسبتا لنډ بهیر دی: موږ معلومات روښانه کوو، که اړتیا وي، او پیسې لیږدوو.

مګر بیرته راستنیدنه په قانون کې د بدلونونو له امله خورا پیچلې شوه، او موږ باید د دې لپاره یو جلا مایکرو خدمت پلي کړو.

زموږ هڅونه:

1. قانون FZ-54 - په لنډه توګه، قانون د هرې پولي راکړې ورکړې په اړه د مالیې دفتر ته راپور ورکولو ته اړتیا لري، که دا بیرته راستنیدنه یا رسید وي، د څو دقیقو په کافي لنډ SLA کې. موږ، د ای کامرس شرکت په توګه، ډیری عملیات ترسره کوو. په تخنیکي توګه، دا د نوي مسؤلیت معنی لري (چې د نوي خدمت معنی لري) او په ټولو ښکیل سیسټمونو کې پرمختګونه.
2. د BOB ویش - د شرکت یوه داخلي پروژه چې BOB د لوی شمیر غیر اصلي مسؤلیتونو څخه خلاصوي او د هغې ټول پیچلتیا کموي.

دا ډیاګرام د لامودا اصلي سیسټمونه ښیې. اوس ډیری یې ډیر خوښ دي د 5-10 مایکرو سرویسونو برج د یو کمیدو مونولیت په شاوخوا کې. دوی ورو ورو وده کوي، مګر موږ هڅه کوو چې دوی کوچني کړو، ځکه چې په مینځ کې ټاکل شوي ټوټه ځای پرځای کول ډارونکي دي - موږ نشو کولی د راټیټیدو اجازه ورکړو. موږ مجبور یو چې ټول تبادلې (تیر) خوندي کړو او دا حقیقت په پام کې ونیسو چې هیڅ یو یې د شتون وړ نه وي.

په BOB کې ډیری تبادلې هم شتون لري: د تادیې سیسټمونه، د تحویل سیسټمونه، د خبرتیا سیسټمونه، او نور.

په تخنیکي توګه BOB دا دی:

• ~150k د کوډ لینونه + ~100k د ازموینې لینونه؛
• php7.2 + Zend 1 او سیمفوني اجزا 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 لپاره، لامودا په فعاله توګه سویګر کاروي. موږ یو API ډیزاین کوو، په سویګر کې یې تشریح کوو، او د پیرودونکي او سرور کوډ تولید کوو. موږ یو څه لوړ شوی JSON RPC 2.0 هم کاروو.

په ځینو ځایونو کې د ESB بسونه کارول کیږي، ځینې یې په فعال ایم کیو کې ژوند کوي، مګر، په عمومي توګه، RabbitMQ معیاري دی.

د Async تبادله TO BE

کله چې د پیښو - بس له لارې د تبادلې ډیزاین کول، یو مشابهت موندل کیدی شي. په ورته ډول، موږ د پیښو جوړښت توضیحاتو له لارې د راتلونکي ډیټا تبادله تشریح کوو. د یامل بڼه، موږ باید د کوډ تولید پخپله ترسره کړو، جنراتور د ځانګړتیاوو سره سم DTOs رامینځته کوي او مراجعینو او سرورونو ته د دوی سره کار کولو درس ورکوي. نسل په دوو ژبو کې دی: ګولنګ او php. دا د کتابتونونو دوامداره ساتلو کې مرسته کوي. جنراتور په ګولنګ لیکل شوی، له همدې امله ورته ګوګي نوم ورکړل شوی.

د کافکا په اړه د پیښو سرچینه کول یو عادي شی دی. د کافکا کنفلوینټ اصلي تصدۍ نسخه څخه حل شتون لري ، شتون لري ناکدي، زموږ د ډومین وروڼو Zalando څخه حل. زموږ د وینیلا کافکا سره د پیل کولو هڅونه - دا د حل لاره وړیا پریږدو تر هغه چې موږ په پای کې پریکړه نه وي کړې چې ایا موږ به دا په هر ځای کې وکاروو، او همدارنګه د چلولو او پرمختګونو لپاره ځان پریږدو: موږ د خپل ملاتړ لپاره غواړو. JSON RPC 2.0، د دوو ژبو لپاره جنراتورونه او راځئ چې نور څه وګورو.

دا د حیرانتیا خبره ده چې حتی په خوشبختۍ قضیه کې چې نږدې ورته ورته سوداګرۍ شتون لري ، زیلانډو ، چې نږدې ورته حل یې رامینځته کړی ، موږ نشو کولی دا په مؤثره توګه وکاروو.

په پیل کې د معمارۍ نمونه په لاندې ډول ده: موږ مستقیم له کافکا څخه لوستلو ، مګر یوازې د پیښو - بس له لارې لیکو. په کافکا کې د لوستلو لپاره ډیری چمتو شوي توکي شتون لري: بروکرز، بیلانسران، او دا د افقی اندازه کولو لپاره لږ یا لږ چمتو دی، ما غوښتل دا وساتم. ثبت کول، موږ غوښتل د یوې ګیټ وے عرف پیښو بس له لارې لاړ شو، او دلته یې ولې.

پیښې - بس

یا د پیښې بس. دا په ساده ډول یو بې دولت http gateway دی، کوم چې ډیری مهم رولونه ترسره کوي:

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

ولې

موږ په یوه لوی شرکت کې د منظم پروسې سره کار کوو. ولې یو څه بدل کړئ؟ دا یوه تجربه ده، او موږ د څو ګټو د ترلاسه کولو تمه لرو.

1: n + 1 تبادله (له یو څخه ډیری)

د کافکا سره دا خورا اسانه ده چې نوي پیرودونکي API ته وصل کړئ.

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

د بیرته ستنیدو وسیلې په حالت کې ، کوم چې د BOB یوه برخه ده ، دا زموږ لپاره اسانه ده چې دوی د کافکا له لارې همغږي وساتو. تادیه وايي چې پیسې بیرته راستانه شوي: BOB، RT په دې اړه پوه شو، د دوی حالتونه یې بدل کړل، د مالي کولو خدمت پدې اړه وموندل او یو چک یې صادر کړ.

موږ پلان لرو چې یو متحد خبرتیا خدمت رامینځته کړو چې پیرودونکي ته د هغه د امر / بیرته ستنیدو په اړه خبرونو ته خبر ورکړي. اوس دا مسوولیت د نظامونو تر منځ خپور شوی دی. دا به زموږ لپاره کافي وي چې د خبرتیا خدماتو ته درس ورکړو ترڅو د کافکا څخه اړونده معلومات ترلاسه کړو او ورته عکس العمل وښیو (او دا خبرتیاوې په نورو سیسټمونو کې غیر فعال کړئ). هیڅ نوي مستقیم تبادلې ته اړتیا نشته.

د معلوماتو پراساس

د سیسټمونو ترمنځ معلومات شفاف کیږي - مهمه نده چې تاسو کوم "خونی شرکت" لرئ او مهمه نده چې ستاسو بیکلاګ څومره ډک وي. لامودا د ډیټا تحلیلاتو څانګه لري چې د سیسټمونو څخه ډیټا راټولوي او د سوداګرۍ او هوښیار سیسټمونو لپاره د بیا کارونې وړ شکل ته راوړي. کافکا تاسو ته اجازه درکوي چې ژر تر ژره دوی ته ډیری معلومات ورکړئ او دا معلومات تازه وساتئ.

د تکثیر log

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

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

بیا، د اسنادو یو څه بیا بیانول، د هغو کسانو لپاره چې له کافکا سره بلد نه دي (عکس هم د اسنادو څخه دی)

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

کافکا هم ورته خلاصون لري موضوع، په کوم کې چې تاسو پیغامونه لیکئ ، مګر د لوستلو وروسته ورک نه کیږي. د ډیفالټ په توګه، کله چې تاسو کافکا سره وصل شئ، تاسو ټول پیغامونه ترلاسه کوئ او د خوندي کولو اختیار لرئ چیرې چې تاسو پریښودل. دا دی، تاسو په ترتیب سره لوستل، تاسو ممکن پیغام د لوستلو په توګه په نښه نه کړئ، مګر هغه ID خوندي کړئ چې تاسو یې وروسته لوستلو ته دوام ورکوئ. هغه ID چې تاسو په کې میشته یاست د آفسیټ په نوم یادیږي، او میکانیزم ته د کمیټ آفسیټ ویل کیږي.

په دې اساس، مختلف منطق پلي کیدی شي. د مثال په توګه، موږ د مختلفو هیوادونو لپاره په 4 مواردو کې BOB لرو - لامودا په روسیه، قزاقستان، اوکراین، بیلاروس کې دی. څرنګه چې دوی په جلا توګه ګمارل شوي، دوی یو څه مختلف تشکیلات او د دوی خپل سوداګریز منطق لري. موږ په پیغام کې اشاره کوو چې دا کوم هیواد ته اشاره کوي. په هر هیواد کې د BOB هر پیرودونکي د مختلف ګروپ ID سره لوستل کوي، او که چیرې پیغام په هغه باندې تطبیق نشي، دوی یې پریږدي، د بیلګې په توګه. سمدلاسه د آفسیټ +1 ژمنې کوي. که زموږ د تادیې خدمت ورته موضوع ولولي، نو بیا دا د یوې جلا ډلې سره کوي، او له همدې امله آفسیټونه نه سره نښلوي.

د پیښې اړتیاوې:

• د معلوماتو بشپړتیا. زه غواړم پیښه کافي معلومات ولري ترڅو پروسس شي.

• بشپړتیا. موږ پیښو - بس ته دا چیک کوو چې پیښه ثابته ده او دا پروسس کولی شي.
• امر مهم دی. د بیرته راستنیدو په صورت کې، موږ مجبور یو چې د تاریخ سره کار وکړو. د خبرتیاو سره، امر مهم نه دی، که دوی یو شان خبرتیاوې وي، بریښنالیک به ورته وي پرته له دې چې کوم امر لومړی راشي. د بیرته ستنیدو په صورت کې، یو روښانه پروسه شتون لري؛ که موږ امر بدل کړو، نو بیا به استثناوې رامنځته شي، بیرته ستنیدنه به نه رامینځته کیږي یا پروسس کیږي - موږ به په بل حالت کې پای ته ورسیږو.
• تسلسل. موږ ذخیره لرو، او اوس موږ د APIs پرځای پیښې رامینځته کوو. موږ یوې لارې ته اړتیا لرو چې په چټکه او ارزانه توګه زموږ خدماتو ته د نویو پیښو او اوسنیو بدلونونو په اړه معلومات انتقال کړو. دا په جلا git ذخیره او کوډ جنراتورونو کې د عام توضیحاتو په کارولو سره ترلاسه کیږي. له همدې امله، په مختلفو خدماتو کې پیرودونکي او سرورونه زموږ سره مطابقت لري.

کافکا په لامودا کې

موږ د کافکا درې تاسیسات لرو:

1. لوګو
2. R&D;
3. پیښې - بس.

نن موږ یوازې د وروستي ټکي په اړه خبرې کوو. په پیښو کې - بس موږ ډیر لوی تاسیسات نلرو - 3 بروکرز (سرورونه) او یوازې 27 موضوعات. د یوې قاعدې په توګه، یوه موضوع یوه پروسه ده. مګر دا یو فرعي ټکی دی، او اوس به موږ په دې اړه اړیکه ونیسو.

پورته د rps ګراف دی. د بیرته ستنیدو پروسه د فیروزي لاین سره نښه شوې (هو، په ایکس محور کې یو)، او ګلابي کرښه د مینځپانګې تازه کولو پروسه ده.

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

ګلابي چوکۍ د محصول تازه معلومات دي، دا په محصولاتو کې بدلون دی. دا روښانه ده چې هلکانو عکسونه اخیستي، عکسونه یې اخیستي، او بیا بیا! - د پیښو یوه کڅوړه بار کړه.

Lamoda پیښې قضیې کاروي

موږ د لاندې عملیاتو لپاره جوړ شوی جوړښت کاروو:

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

اوس د لوی ټکرونو او په زړه پورې کشفونو په اړه خورا په زړه پورې برخه چې په تیرو شپږو میاشتو کې پیښ شوي.

د ډیزاین ستونزې

راځئ ووایو چې موږ غواړو یو نوی کار وکړو - د بیلګې په توګه، کافکا ته د سپارلو ټوله پروسه. اوس د پروسې یوه برخه په BOB کې د امر پروسس کولو کې پلي کیږي. د تحویلي خدمت ته د امر لیږد ترشا ، منځګړی ګودام ته حرکت او داسې نور ، د وضعیت ماډل شتون لري. دلته یو بشپړ واحد شتون لري ، حتی دوه ، او د تحویلۍ لپاره وقف شوي APIs یوه ډله. دوی د سپارلو په اړه ډیر څه پوهیږي.

دا ورته سیمې ښکاري، مګر وضعیت په BOB کې د امر پروسس کولو او د بار وړلو سیسټم لپاره توپیر لري. د مثال په توګه، ځینې کوریر خدمتونه منځګړیتوب حالتونه نه لیږي، مګر یوازې وروستي: "وړاندې شوي" یا " ورک شوي". نور، برعکس، د توکو د حرکت په اړه په تفصیل سره راپور ورکوي. هرڅوک خپل د تایید اصول لري: د ځینو لپاره، بریښنالیک اعتبار لري، پدې معنی چې دا به پروسس شي؛ د نورو لپاره دا د اعتبار وړ نه ده، مګر امر به بیا هم پروسس شي ځکه چې د اړیکو لپاره د تلیفون شمیره شتون لري، او ځینې به ووایي چې دا ډول امر به هیڅکله پروسس نشي.

د معلوماتو جریان

د کافکا په قضیه کې، د معلوماتو جریان تنظیم کولو پوښتنه راپورته کیږي. پدې کار کې د څو ټکو پراساس د ستراتیژۍ غوره کول شامل دي؛ راځئ چې د دوی ټولو ته لاړ شو.

په یوه موضوع کې یا په مختلفو موضوعاتو کې؟

موږ د پیښې مشخصات لرو. په BOB کې موږ لیکو چې دا ډول امر باید تحویل شي، او په ګوته کوي: د امر شمیره، د هغې مینځپانګې، ځینې SKUs او بار کوډونه، او داسې نور. کله چې توکي ګودام ته راشي ، تحویلي به د دې وړتیا ولري چې حالتونه ، مهال ویشونه او هرڅه چې ورته اړتیا وي ترلاسه کړي. مګر بیا موږ غواړو په BOB کې د دې معلوماتو تازه معلومات ترلاسه کړو. موږ د تحویلۍ څخه د معلوماتو ترلاسه کولو یوه برعکس پروسه لرو. ایا دا ورته پیښه ده؟ یا دا یو جلا تبادله ده چې د خپل موضوع مستحق دی؟

ډیری احتمال، دوی به ډیر ورته وي، او د یوې موضوع جوړولو لپاره لیوالتیا بې بنسټه نه ده، ځکه چې جلا موضوع معنی لري جلا پیرودونکي، جلا ترتیبونه، د دې ټولو جلا نسل. خو دا یو حقیقت نه دی.

نوی ډګر یا نوې پیښه؟

مګر که تاسو ورته پیښې وکاروئ نو بیا بله ستونزه رامینځته کیږي. د مثال په توګه، د تحویلي ټول سیسټمونه نشي کولی د DTO ډول تولید کړي چې BOB یې تولید کولی شي. موږ دوی ته ID لیږو ، مګر دوی یې نه خوندي کوي ځکه چې دوی ورته اړتیا نلري ، او د پیښې بس پروسې پیل کولو له نظره ، دا ساحه اړینه ده.

که موږ د پیښې بس لپاره یو قاعده معرفي کړو چې دا ساحه اړینه ده، نو موږ مجبور یو چې په BOB یا د پیل پیښې هینډلر کې د تایید اضافي قواعد تنظیم کړو. تایید په ټول خدمت کې خپریږي - دا خورا اسانه ندي.

بله ستونزه د زیاتیدونکي پراختیا لالچ دی. موږ ته ویل شوي چې په پیښه کې یو څه اضافه کولو ته اړتیا ده، او شاید که موږ د هغې په اړه فکر وکړو، دا باید یو جلا پیښه وي. مګر زموږ په سکیم کې، یوه جلا پیښه جلا موضوع ده. یوه جلا موضوع ټوله پروسه ده چې ما پورته تشریح کړه. پراختیا کونکی په ساده ډول د JSON سکیما ته د بل ساحه اضافه کولو لپاره لیوالتیا لري او بیا یې تولیدوي.

د بیرته ستنیدو په صورت کې، موږ په شپږو میاشتو کې پیښې ته ورسیدو. موږ یوه میټا پیښه درلوده چې د بیرته ستنیدو تازه په نوم یادیږي ، کوم چې یو ډول ساحه درلوده چې تشریح کوي دا تازه معلومات واقعیا څه دي. د دې له امله ، موږ د اعتبار کونکو سره "په زړه پوري" سویچونه درلودل چې موږ ته یې وویل چې څنګه د دې ډول سره دا پیښه تایید کړو.

د پیښې نسخه

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

د تقسیمونو د لوستلو ترتیب تضمین شوی

د کافکا دننه موضوعات په برخو ویشل شوي دي. دا خورا مهم نه دی کله چې موږ د ادارو او تبادلو ډیزاین کوو، مګر دا مهمه ده کله چې موږ پریکړه وکړو چې څنګه یې مصرف کړو او اندازه یې کړو.

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

کافکا دوی څنګه ویشي؟ هر پیغام یو بدن لري (په کوم کې چې موږ JSON ذخیره کوو) او یو کیلي. تاسو کولی شئ په دې کیلي کې د هش فنکشن ضمیمه کړئ، کوم چې دا به معلومه کړي چې پیغام به کومې برخې ته ځي.

زموږ د بیرته ستنیدو په قضیه کې ، دا مهم دی ، که موږ دوه برخې واخلو ، نو د دې امکان شتون لري چې یو موازي مصرف کونکي به د لومړۍ پیښې دمخه دوهم پیښه پروسس کړي او ستونزه به وي. د هش فنکشن ډاډ ورکوي چې د ورته کیلي سره پیغامونه په ورته برخه کې پای ته رسیږي.

پیښې او امرونه

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

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

له یوې خوا، دا وړاندیز کوي چې پیښه به څنګه وکارول شي. له بلې خوا، دا د عادي پیښې نوم په څیر ډیر لږ ښکاري. سربیره پردې ، دا د do_something ټیم څخه لرې ندی. مګر تاسو هیڅ تضمین نلرئ چې څوک دا پیښه ولولي؛ او که تاسو یې ولولئ، نو تاسو یې په بریالیتوب سره ولولئ؛ او که تاسو دا په بریالیتوب سره ولولئ، نو تاسو یو څه وکړل، او دا یو څه بریالی و. کله چې یوه پیښه ترسره شي، فیډبیک اړین کیږي، او دا یوه ستونزه ده.

په RabbitMQ کې غیر متناسب تبادله کې، کله چې تاسو پیغام ولولئ او http ته لاړ شئ، تاسو یو ځواب لرئ - لږترلږه دا چې پیغام ترلاسه شوی و. کله چې تاسو کافکا ته لیکئ، یو پیغام شتون لري چې تاسو کافکا ته لیکلي، مګر تاسو پدې اړه هیڅ نه پوهیږئ چې دا څنګه پروسس شوی.

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

ناڅاپي

یوه څرګنده ستونزه شتون لري: که تاسو د یوې موضوع څخه په ترتیب سره ولولئ، او تاسو یو څه بد پیغام لرئ، پیرودونکي به راټیټ شي، او تاسو به نور لاړ نه شئ. تاسو اړتیا لرئ ټول مصرف کونکي ودروي، لوستلو ته دوام ورکولو لپاره نور بند کړئ.

موږ د دې په اړه پوهیږو، موږ په دې اړه بانکداري وکړه، او دا په هرصورت پیښ شوي. او دا پیښ شوي ځکه چې پیښه د پیښو له لید څخه معتبره وه - بس ، پیښه د غوښتنلیک اعتبار کونکي له نظره اعتباري وه ، مګر دا د PostgreSQL له نظره اعتبار نلري ، ځکه چې زموږ په سیسټم کې MySQL د نه لاسلیک شوي INT سره، او په نوي لیکل شوي سیسټم کې په ساده ډول د INT سره PostgreSQL درلود. د هغه اندازه یو څه کوچنۍ ده، او ID مناسب نه و. سمفوني په استثنا سره مړ شو. موږ، البته، استثنا ترلاسه کړه ځکه چې موږ په دې تکیه کوله او د دې معافیت ژمنه کوو، مګر مخکې له دې موږ غوښتل چې د ستونزې مقابله زیاته کړو، ځکه چې پیغام په ناکامۍ سره پروسس شوی و. په دې پروژه کې شمیرونکي هم په ډیټابیس کې دي، او سیمفوني لا دمخه د ډیټابیس سره اړیکه بنده کړې، او دویم استثناء پرته له دې چې د آفسیټ ژمنې فرصت پرته ټوله پروسه له منځه یوسي.

خدمت د یو څه وخت لپاره پاتې شو - خوشبختانه ، د کافکا سره دا دومره ویره نلري ، ځکه چې پیغامونه پاتې دي. کله چې کار بحال شي، تاسو کولی شئ د دوی لوستل پای ته ورسوئ. دا آرام دی.

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

یو بل اهمیت دی د نقل کولو log vs rdkafka.so - زموږ د پروژې ځانګړتیاو پورې اړه لري. موږ PHP کاروو، او په PHP کې، د یوې قاعدې په توګه، ټول کتابتونونه د کافکا سره د rdkafka.so ذخیره کولو له لارې اړیکه نیسي، او بیا یو ډول ریپر شتون لري. شاید دا زموږ شخصي مشکلات وي، مګر دا معلومه شوه چې په ساده ډول د هغه څه لوستل چې موږ مخکې لوستلي وو، دومره اسانه ندي. په عموم کې، د سافټویر ستونزې شتون درلود.

د برخې سره د کار کولو ځانګړتیاو ته بیرته راستنیدل، دا په اسنادو کې سم لیکل شوي مصرف کونکي >= د موضوع برخې. مګر ما د دې په اړه ډیر وروسته پوهیدل چې ما به یې خوښ کړي وي. که تاسو اندازه کول غواړئ او دوه پیرودونکي ولرئ، تاسو لږترلږه دوه برخې ته اړتیا لرئ. دا دی، که تاسو یوه برخه درلوده چې په هغه کې 20 زره پیغامونه راټول شوي، او تاسو یو نوی جوړ کړی، د پیغامونو شمیر به ژر مساوي نه وي. له همدې امله، د دې لپاره چې دوه موازي مصرف کونکي ولرئ، تاسو اړتیا لرئ د ویشونو سره معامله وکړئ.

څارنه

زه فکر کوم هغه لاره چې موږ یې څارو دا به لا روښانه وي چې په موجوده چلند کې کومې ستونزې شتون لري.

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

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

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

یوه پروژه ده غوړ, کوم چې به تاسو ته د کافکا په اړه نور معلومات درکړي. دا په ساده ډول د مصرف کونکي ګروپ API حالت ورکوي، لکه دا ګروپ سوداګرۍ لري. د سم او ناکام سربیره ، یو خبرداری شتون لري ، او تاسو به وکولی شئ ومومئ چې ستاسو پیرودونکي نشي کولی د تولید سرعت سره مقابله وکړي - دوی وخت نلري چې د لیکلو ثبوت ولوستل شي. سیسټم خورا هوښیار او د کارولو لپاره اسانه دی.

دا هغه څه دي چې د API ځواب ورته ښکاري. دلته د ګروپ bob-live-fifa، partition refund.update.v1 دی، حالت سم دی، lag 0 وروستی وروستی آفسیټ دی داسې او داسې نور.

څارنه update_at SLA (بند شوی) ما مخکې هم یادونه کړې ده. د مثال په توګه، محصول هغه حالت ته لیږدول شوی چې دا د بیرته راستنیدو لپاره چمتو دی. موږ کرون نصب کوو ، کوم چې وايي که په 5 دقیقو کې دا اعتراض بیرته راستنیدو ته نه وي تللی (موږ د تادیې سیسټمونو له لارې خورا ګړندي پیسې راستوو) ، نو یقینا یو څه غلط شوی ، او دا یقینا د ملاتړ قضیه ده. له همدې امله ، موږ په ساده ډول کرون اخلو ، کوم چې دا ډول شیان لوستل کیږي ، او که دوی له 0 څخه لوی وي ، نو دا خبرداری لیږي.

د لنډیز لپاره، د پیښو کارول اسانه دي کله چې:

• معلومات د څو سیسټمونو لخوا اړین دي؛
• د پروسس پایله مهمه نه ده؛
• لږې پیښې یا کوچنۍ پیښې شتون لري.

داسې بریښي چې مقاله خورا ځانګړې موضوع لري - په کافکا کې غیر متزلزل API ، مګر د دې په تړاو زه غواړم په یوځل کې ډیری شیان وړاندیز کړم.
لومړی، بل لوړ لوډ++ موږ اړتیا لرو تر نومبر پورې انتظار وکړو، په اپریل کې به د سینټ پیټرزبورګ نسخه وي، او د جون په میاشت کې به موږ په نووسیبیرسک کې د لوړ بارونو په اړه وغږیږو.
دوهم، د راپور لیکوال، سرګي زیکا، د پوهې مدیریت په اړه زموږ د نوي کنفرانس د پروګرام کمیټې غړی دی KnowledgeConf. دا کنفرانس یو ورځنی دی، د اپریل په ۲۶ به جوړیږي، خو پروګرام یې ډېر بوخت دی.
او دا به د می په میاشت کې وي پی ایچ پی روسیه и RIT++ (د DevOpsConf سره شامل دي) - تاسو کولی شئ هلته خپله موضوع هم وړاندیز کړئ ، د خپلې تجربې په اړه وغږیږئ او ستاسو د ډک شوي ټپونو په اړه شکایت وکړئ.

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