موږ ټول کیسې خوښوو. موږ د اور په شاوخوا کې ناست یو او د خپلو تیرو بریاوو، جګړو، یا په ساده ډول زموږ د کار تجربې په اړه خبرې کوو.
نن ورځ یوازې داسې ورځ ده. او حتی که تاسو همدا اوس په اور کې نه یاست، موږ ستاسو لپاره یوه کیسه لرو. د دې کیسه چې څنګه موږ په تارنول کې د ذخیره کولو سره کار پیل کړ.
په یو وخت کې، زموږ شرکت د ټولو لپاره یو څو "مونولیتس" او یو "چت" درلود، کوم چې دا مونولیتونه ورو ورو مګر یقینا نږدې وو، زموږ د شرکت الوتنې محدودوي، زموږ پراختیا. او یو روښانه پوهاوی شتون درلود: یوه ورځ به موږ دا چت سخت ووهلو.
دا اوس د تجهیزاتو څخه تر سوداګرۍ منطق پورې د هرڅه او هرچا جلا کولو غالب نظریه ده. د پایلې په توګه، موږ، د بیلګې په توګه، دوه DCs لرو چې په عملي توګه د شبکې په کچه خپلواک دي. او بیا هرڅه په بشپړ ډول توپیر درلود.
نن ورځ، د CI/CD، K8S، او نورو په بڼه کې د بدلونونو لپاره ډیری وسایل او وسایل شتون لري. په "مونولیتیک" وخت کې، موږ دومره بهرنیو کلمو ته اړتیا نه درلوده. دا په ساده ډول په ډیټابیس کې د "ذخیرې" سمولو لپاره کافي و.
مګر وخت مخ په وړاندې لاړ، او د غوښتنو شمیر د هغې سره مخ شو، ځینې وختونه زموږ د وړتیاوو څخه هاخوا RPS ډزې کوي. بازار ته د CIS هیوادونو د ننوتلو سره، د لومړي مونولیت ډیټابیس پروسیسر باندې بار له 90٪ څخه ښکته نه و، او RPS د 2400 په کچه پاتې شو. او دا یوازې کوچني انتخابونکي نه وو، مګر د یوې لویې پوښتنې سره. د چکونو او شمولیتونو ډله چې د لوی IO شالید پروړاندې نږدې نیمایي ډیټا چلولی شي.
کله چې د تور جمعې بشپړ پلور په صحنه کې څرګند شو - او وائلډ بیریز یو له لومړیو څخه و چې په روسیه کې یې ساتل - وضعیت په بشپړ ډول غمجن شو. په هرصورت، په داسې ورځو کې بار درې ځله زیاتیږي.
اوه، دا "مونولیټیک وختونه"! زه ډاډه یم چې تاسو ورته یو څه تجربه کړې وي، او تاسو لاهم نه پوهیږئ چې دا ستاسو سره څنګه پیښ کیدی شي.
تاسو څه کولی شئ - فیشن په ټیکنالوژۍ کې شامل دی. شاوخوا 5 کاله دمخه ، موږ باید د دې موډونو څخه یو په .NET او MS SQL سرور کې د موجوده سایټ په شکل کې له سره غور وکړو ، کوم چې د سایټ ټول منطق پخپله ذخیره کړی. ما دا په ډیر احتیاط سره ساتلی و چې د داسې مونولیت لیدل یو اوږد او هیڅ اسانه خوند نه و.
یو کوچنی انحراف.
په مختلفو پیښو کې زه وایم: "که تاسو یو مونولیت نه وي لیدلی، نو تاسو وده نه ده کړې!" زه پدې مسله ستاسو نظر سره علاقه لرم ، مهرباني وکړئ په نظرونو کې یې ولیکئ.
د تندر غږ
راځئ چې بیرته خپل "الون فائر" ته راستانه شو. د "مونولیتیک" فعالیت بار توزیع کولو لپاره ، موږ پریکړه وکړه چې سیسټم د خلاصې سرچینې ټیکنالوژیو پراساس مایکرو خدماتو ته وویشو. ځکه چې، لږترلږه، دوی د اندازې لپاره ارزانه دي. او موږ 100٪ پوهه درلوده چې موږ باید اندازه وکړو (او ډیر څه). په هرصورت، دمخه په هغه وخت کې دا ممکنه وه چې د ګاونډیو هیوادونو بازارونو ته ننوځي، او د راجسټریشن شمیر، او همدارنګه د امرونو شمیر، حتی په کلکه وده وکړي.
د مونولیت څخه مایکرو خدماتو ته د وتلو لپاره د لومړي نوماندانو تحلیل کولو سره ، موږ پوهیږو چې په دوی کې 80٪ لیکنې د شاته دفتر سیسټمونو څخه راځي ، او د مخکني دفتر څخه لوستل کیږي. له هرڅه دمخه ، دا زموږ لپاره یو څو مهم فرعي سیسټمونو پورې اړه لري - د کارونکي ډیټا او د پیرودونکو اضافي تخفیفونو او کوپنونو معلوماتو پراساس د توکو وروستي لګښت محاسبه کولو سیسټم.
انډیټ شوی. اوس دا د تصور کولو ویره ده، مګر د پورته ذکر شوي فرعي سیسټمونو سربیره، د محصول کتلاګ، د کاروونکي پیرود کارټ، د محصول لټون سیسټم، د محصول کتلاګ لپاره د فلټر کولو سیسټم، او د سپارښتنې مختلف ډوله سیسټمونه هم زموږ له مونولیت څخه لرې شوي. د دوی د هر یو د عملیاتو لپاره، د محدود ډوله سیسټمونو جلا ټولګي شتون لري، مګر یو وخت دوی ټول په یو "کور" کې ژوند کاوه.
موږ سمدلاسه پلان درلود چې زموږ د پیرودونکو په اړه معلومات شارډ شوي سیسټم ته انتقال کړو. د توکو د وروستي لګښت محاسبه کولو لپاره د فعالیت لرې کول د لوستلو لپاره ښه پیمانه کولو ته اړتیا لري ، ځکه چې دا خورا لوی RPS بار رامینځته کړی او د ډیټابیس لپاره پلي کول خورا ستونزمن و (ډیری ډیټا د محاسبې په پروسه کې ښکیل دي).
د پایلې په توګه، موږ د یو سکیم سره راغلو چې د ترنټول سره ښه فټ کوي.
په هغه وخت کې، د مایکرو خدماتو عملیات لپاره، په مجازی او هارډویر ماشینونو کې د ډیری ډیټا مرکزونو سره د کار کولو سکیمونه غوره شوي. لکه څنګه چې په ارقامو کې ښودل شوي، د ټرانټول نقل کولو اختیارونه په دواړو ماسټر-ماسټر او ماسټر-غلام حالتونو کې پلي شوي.
معمارۍ. اختیار 1. د کارونکي خدمت
په اوسني وخت کې، 24 شارډونه شتون لري، چې هر یو یې 2 مثالونه لري (یو د هر DC لپاره)، ټول د ماسټر ماسټر حالت کې.
د ډیټابیس په سر کې هغه غوښتنلیکونه دي چې د ډیټابیس نقلونو ته لاسرسی لري. غوښتنلیکونه زموږ د دودیز کتابتون له لارې د Tarantool سره کار کوي، کوم چې د Tarantool Go ډرایور انٹرفیس پلي کوي. هغه ټول نقلونه ګوري او کولی شي د ماسټر سره د لوستلو او لیکلو لپاره کار وکړي. په لازمي ډول ، دا د ریپلیکا سیټ ماډل پلي کوي ، کوم چې د عکسونو غوره کولو لپاره منطق اضافه کوي ، بیا هڅه کول ، سرکټ بریکر او د نرخ حد.
په دې حالت کې، دا ممکنه ده چې د شارډونو په شرایطو کې د نقل انتخاب پالیسي تنظیم کړئ. د مثال په توګه، roundrobin.
معمارۍ. اختیار 2. د توکو وروستی لګښت محاسبه کولو لپاره خدمت
څو میاشتې دمخه، د توکو د وروستي لګښت محاسبه کولو لپاره ډیری غوښتنې نوي خدمت ته لاړل، کوم چې په اصولو کې د ډیټابیس پرته کار کوي، مګر یو څه وخت دمخه هر څه 100٪ پروسس شوي و چې د ترانټول لاندې د خدمت لخوا ترسره شوي.
د خدماتو ډیټابیس د 4 ماسټرانو څخه جوړ دی چې په کې ترکیب کونکي ډاټا راټولوي، او هر یو د نقل کولو ماسټر ډاټا یوازې د لوستلو نقلونو لپاره توزیع کوي. هر ماسټر نږدې 15 ورته نقلونه لري.
یا په لومړي یا دوهم سکیم کې، که یو DC شتون نلري، غوښتنلیک کولی شي په دویمه کې ډاټا ترلاسه کړي.
دا د یادولو وړ ده چې په ټرینټول کې نقل کول خورا انعطاف وړ دي او د چلولو په وخت کې تنظیم کیدی شي. په نورو سیسټمونو کې، ستونزې رامنځته شوې. د مثال په توګه، په PostgreSQL کې د max_wal_senders او max_replication_slots پیرامیټرو بدلول د وزرډ بیا پیل ته اړتیا لري، کوم چې په ځینو مواردو کې د غوښتنلیک او DBMS ترمنځ د اړیکو د قطع کیدو لامل کیدی شي.
لټون وکړئ او تاسو به ومومئ!
ولې موږ دا د "عادي خلکو په څیر" ونه کړل، مګر یو غیر معمولي لاره غوره کړه؟ دا په هغه څه پورې اړه لري چې نورمال ګڼل کیږي. ډیری خلک عموما د مونګو څخه کلستر جوړوي او په دریو جیو ویشل شوي DC کې خپروي.
په هغه وخت کې، موږ دمخه د Redis دوه پروژې درلودې. لومړی یوه زیرمه وه، او دوهم د خورا مهم معلوماتو لپاره دوامداره ذخیره وه. دا د هغه سره خورا ستونزمن و، یو څه زموږ د ګناه له لارې. ځینې وختونه خورا لوی حجمونه په کیلي کې وو، او وخت په وخت سایټ ناروغه شو. موږ دا سیسټم د ماسټر غلام نسخه کې کارولی. او ډیری قضیې شتون درلود چیرې چې ماسټر ته یو څه پیښ شوي او نقل مات شوی.
دا دی، ریډیس د بې ریاسته کارونو لپاره ښه دی، نه دولتي. په اصولو کې، دا د ډیری ستونزو حل کولو ته اجازه ورکوي، مګر یوازې هغه وخت چې دوی د یو جوړه شاخصونو سره د کلیدي ارزښت حلونه وي. مګر ریډیس په هغه وخت کې د دوام او نقل سره خورا غمجن و. سربیره پردې، د فعالیت په اړه شکایتونه شتون درلود.
موږ د MySQL او PostgreSQL په اړه فکر کاوه. مګر لومړی یې یو څه زموږ سره ندی نیولی، او دوهم یې پخپله خورا پیچلي محصول دی، او دا به نامناسب وي چې ساده خدمتونه جوړ کړي.
موږ هڅه وکړه RIAK، Cassandra، حتی د ګراف ډیټابیس. دا ټول خورا مناسب حلونه دي چې د خدماتو رامینځته کولو لپاره د عمومي نړیوال وسیلې رول لپاره مناسب ندي.
په نهایت کې موږ په ترنتول کې میشت شو.
موږ دې ته مخ شو کله چې دا په 1.6 نسخه کې و. موږ په دې کې د کلیدي ارزښت د سمبوسیس او د اړونده ډیټابیس فعالیت سره علاقه درلوده. ثانوي شاخصونه، لیږدونه او ځایونه شتون لري، دا د میزونو په څیر دي، مګر ساده ندي، تاسو کولی شئ په دوی کې د کالم مختلف شمیر ذخیره کړئ. مګر د ترنټول وژونکي ځانګړتیا د کلیدي ارزښت او لیږد سره یوځای ثانوي شاخصونه وو.
ځواب ورکوونکې روسي ژبي ټولنه، چې په خبرو اترو کې مرستې ته چمتو ده، هم رول لوبولی. موږ دا په فعاله توګه کارولی او مستقیم په چیٹ کې ژوند کوو. او پرته له ښکاره غلطیو او غلطیو څخه د ښه دوام په اړه مه هیروئ. که تاسو د تارنول سره زموږ تاریخ ته وګورو، موږ د نقل کولو سره ډیر درد او ناکامۍ درلودې، مګر موږ هیڅکله د هغې د غلطۍ له امله ډاټا له لاسه نه ورکوو!
تطبيق يو سخت پيل شو
په هغه وخت کې، زموږ اصلي پراختیایي سټیک .NET و، کوم چې د Tarantool لپاره هیڅ نښلونکی نه و. موږ سمدلاسه په Go کې یو څه پیل کړل. دا د لوا سره هم ښه کار وکړ. په هغه وخت کې اصلي ستونزه د ډیبګ کولو سره وه: په .NET کې هرڅه د دې سره عالي دي ، مګر له هغې وروسته د سرایت شوي لوا نړۍ کې ډوب کول ګران وو ، کله چې تاسو د لاګونو پرته هیڅ ډیبګ نلرئ. برسېره پردې، د ځینو دلیلونو لپاره نقل په وخت سره جلا شو، نو زه باید د ترانټول انجن جوړښت ته لاړ شم. چیټ د دې سره مرسته وکړه، او تر یوې اندازې پورې، اسناد؛ ځینې وختونه موږ کوډ ته ګورو. په هغه وخت کې، اسناد داسې وو.
نو، د څو میاشتو په اوږدو کې، ما وکولی شو چې خپل سر ته ورسوم او د ترنټول سره کار کولو څخه ښې پایلې ترلاسه کړم. موږ په git کې د حوالې پرمختګونه تالیف کړل چې د نوي مایکرو خدماتو رامینځته کولو کې یې مرسته کړې. د مثال په توګه، کله چې یو کار رامینځته شو: د بل مایکرو سرویس رامینځته کولو لپاره ، پراختیا کونکي په ذخیره کې د حوالې حل سرچینې کوډ ته وکتل ، او د نوي رامینځته کولو لپاره یې له یوې اونۍ څخه ډیر وخت ونیوه.
دا ځانګړي وختونه وو. په دودیز ډول ، بیا تاسو کولی شئ په راتلونکي میز کې مدیر ته لاړ شئ او پوښتنه وکړئ: "ما ته یو مجازی ماشین راکړئ." شاوخوا دېرش دقیقې وروسته موټر ستاسو سره و. تاسو خپل ځان وصل کړی، هرڅه نصب کړي، او ټرافیک تاسو ته لیږل شوی.
نن ورځ دا به نور کار ونکړي: تاسو اړتیا لرئ خدمت ته نظارت او لاګنګ اضافه کړئ ، فعالیت د ازموینو سره پوښ کړئ ، د مجازی ماشین امر وکړئ یا کوبر ته تحویل کړئ ، او داسې نور. په عموم کې، دا به ښه وي، که څه هم دا به ډیر وخت ونیسي او ډیر ستونزمن وي.
تقسیم او حکومت وکړئ. د لوا سره څه معامله ده؟
یوه جدي ستونزه وه: ځینې ټیمونه ونشو کولی په لوا کې د ډیری منطق سره په خدمت کې د اعتبار وړ بدلونونه رامینځته کړي. دا ډیری وختونه د خدماتو سره کار نه کوي.
دا دی، پراختیا کونکي یو ډول بدلون چمتو کوي. ټرانټول مهاجرت پیل کوي، مګر نقل لاهم د زاړه کوډ سره دی؛ ځینې DDL یا بل څه هلته د نقل له لارې راځي، او کوډ په ساده ډول جلا کیږي ځکه چې دا په پام کې نه نیول کیږي. د پایلې په توګه، د مدیرانو لپاره د تازه کولو طرزالعمل په A4 شیټ کې ایښودل شوی و: د نقل کولو مخه ونیسئ، دا تازه کړئ، نقل کول فعال کړئ، دلته بند کړئ، هلته تازه کړئ. د شپې خوب!
د پایلې په توګه، اوس موږ ډیری وختونه هڅه کوو چې په لوا کې هیڅ ونه کړو. یوازې iproto وکاروئ (د سرور سره د متقابل عمل لپاره بائنری پروتوکول)، او دا دی. شاید دا د پراختیا کونکو ترمنځ د پوهې نشتوالی وي، مګر له دې نظره سیسټم پیچلی دی.
موږ تل دا سکریپټ په ړوند ډول نه تعقیبوو. نن ورځ موږ تور او سپین نلرو: یا هرڅه په لوا کې دي، یا هرڅه په تګ کې دي. موږ دمخه پوهیږو چې موږ څنګه کولی شو دوی سره یوځای کړو ترڅو وروسته د مهاجرت ستونزو سره مخ نه شو.
ترنتول اوس چیرته دی؟
Tarantool په خدمت کې د تخفیف کوپنونو په پام کې نیولو سره د توکو وروستی لګښت محاسبه کولو لپاره کارول کیږي، چې د "پروموټر" په نوم هم پیژندل کیږي. لکه څنګه چې ما مخکې وویل، هغه اوس تقاعد کیږي: هغه د مخکینۍ محاسبې قیمتونو سره د نوي کتلاګ خدمت لخوا بدل شوی، مګر شپږ میاشتې دمخه ټول حسابونه په پروموټیزر کې ترسره شوي. پخوا، د دې منطق نیمایي په لوا کې لیکل شوی و. دوه کاله دمخه، خدمت د ذخیره کولو په ځای بدل شو، او منطق په Go کې بیا لیکل شوی و، ځکه چې د تخفیف میکانیکونه یو څه بدل شوي او خدمت د فعالیت نشتوالی درلود.
یو له خورا مهم خدماتو څخه د کارونکي پروفایل دی. دا چې د Wildberries ټول کاروونکي په Tarantool کې زیرمه شوي، او شاوخوا 50 ملیونه یې شتون لري. یو سیسټم چې د کارن ID لخوا ویشل شوی، په څو DCs کې ویشل شوی چې د Go خدماتو سره وصل دی.
د RPS په وینا، پروموټر یو وخت مشر و، د 6 زرو غوښتنو ته رسیدو. په یو وخت کې موږ 50-60 نقلونه درلودل. اوس په RPS کې مشر د کارونکي پروفایلونه دي، شاوخوا 12 زره. دا خدمت د دودیز شارډینګ کاروي، د کارن IDs په سلسله ویشل شوي. خدمت له 20 څخه ډیر ماشینونه وړاندې کوي، مګر دا خورا ډیر دي؛ موږ پالن لرو چې تخصیص شوي سرچینې کم کړو، ځکه چې د 4-5 ماشینونو ظرفیت د دې لپاره کافي دی.
د سیشن خدمت زموږ په vshard او کارتریج کې لومړی خدمت دی. د vshard تنظیم کول او د کارتریج تازه کول زموږ څخه یو څه هڅو ته اړتیا لري ، مګر په پای کې هرڅه سم شول.
په ویب پاڼه او ګرځنده اپلیکیشن کې د مختلف بینرونو ښودلو خدمت یو له لومړیو څخه و چې په مستقیم ډول په Tarantool کې خپور شو. دا خدمت د دې حقیقت لپاره د پام وړ دی چې دا د 6-7 کلن دی، دا لاهم په فعالیت کې دی او هیڅکله بیا نه دی پیل شوی. د ماسټر ماسټر نقل کارول شوی. هیڅکله هیڅ شی نه مات شوی.
د ګودام سیسټم کې د ګړندي حوالې فعالیت لپاره د ټارنټول کارولو مثال شتون لري ترڅو په ځینو قضیو کې د معلوماتو ګړندي دوه ځله چیک کړي. موږ هڅه وکړه چې د دې لپاره Redis وکاروو، مګر په حافظه کې ډاټا د Tarantool په پرتله ډیر ځای نیولی.
د انتظار لیست خدمتونه ، د پیرودونکي ګډون ، اوس مهال فیشني کیسې او ځنډول شوي توکي هم د ترانتول سره کار کوي. په حافظه کې وروستی خدمت شاوخوا 120 GB وخت نیسي. دا د پورتنیو ټولو پراخه خدمت دی.
پایلې
د کلیدي ارزښت او راکړې ورکړې سره یوځای شوي ثانوي شاخصونو څخه مننه ، ټرانټول د مایکرو خدماتو پراساس جوړښتونو لپاره مناسب دی. په هرصورت، موږ له ستونزو سره مخ شو کله چې په لوا کې د ډیری منطق سره خدماتو ته بدلونونه وړاندې کول - خدمتونه ډیری وختونه کار بندوي. موږ په دې بریالي نشول، او د وخت په تیریدو سره موږ د لوا او ګو مختلف ترکیبونو ته ورسیدو: موږ پوهیږو چې چیرې یوه ژبه وکاروو او چیرې بله ژبه وکاروو.
په موضوع نور څه لوستل
- د ټرانټول په کارولو سره له سکریچ څخه د لوړ بار غوښتنلیک رامینځته کول
- په ترانتول کارتریج کې د باور وړ مشر انتخاب
- د ټیلیګرام چینل ترنتول د محصول په اړه خبرونو سره
- د ټولنې په خبرو اترو کې د ترنټول په اړه بحث وکړئ
سرچینه: www.habr.com