چگونه از نگرانی دست برداریم و زندگی بدون یکپارچگی را شروع کنیم

همه ما عاشق داستان هستیم. ما دوست داریم دور آتش بنشینیم و در مورد پیروزی‌ها، جنگ‌ها یا صرفاً تجربه کاری‌مان صحبت کنیم.

امروز دقیقاً چنین روزی است. و حتی اگر در حال حاضر در کنار آتش نیستید، ما برای شما داستانی داریم. داستان نحوه شروع کار با ذخیره سازی در Tarantool.

روزی روزگاری، شرکت ما چند «یکپارچه» و یک «سقف» برای همه داشت، که این یکپارچه‌ها به آرامی اما مطمئناً به آن نزدیک می‌شدند و پرواز شرکت ما، توسعه ما را محدود می‌کرد. و درک روشنی وجود داشت: روزی این سقف را سخت خواهیم زد.

اکنون ایدئولوژی غالب جدا کردن همه چیز و همه، از تجهیزات گرفته تا منطق تجاری است. در نتیجه، برای مثال، ما دو DC داریم که عملاً در سطح شبکه مستقل هستند. و سپس همه چیز کاملاً متفاوت بود.

امروزه ابزارها و ابزارهای زیادی برای ایجاد تغییرات در قالب CI/CD، K8S و ... وجود دارد. در زمان «یکپارچگی» ما به این همه واژه بیگانه نیاز نداشتیم. کافی بود به سادگی "ذخیره سازی" در پایگاه داده اصلاح شود.

اما زمان به جلو می رفت و تعداد درخواست ها نیز همراه با آن جلو می رفت و گاهی اوقات RPS فراتر از توانایی های ما شلیک می شد. با ورود کشورهای مستقل مشترک المنافع به بازار، بار روی پردازنده پایگاه داده اولین مونولیت کمتر از 90٪ نشد و RPS در سطح 2400 باقی ماند. و اینها فقط انتخابگرهای کوچک نبودند، بلکه پرس و جوهای سنگین با یک دسته ای از چک ها و JOIN ها که می توانند تقریباً برای نیمی از داده ها در پس زمینه IO بزرگ اجرا شوند.

هنگامی که فروش تمام عیار جمعه سیاه در صحنه ظاهر شد - و Wildberries یکی از اولین کسانی بود که آنها را در روسیه برگزار کرد - وضعیت کاملاً غم انگیز شد. از این گذشته ، بار در چنین روزهایی سه برابر افزایش می یابد.
آه، این "زمان های یکپارچه"! من مطمئن هستم که شما هم چنین چیزی را تجربه کرده اید و هنوز نمی توانید درک کنید که چگونه ممکن است این اتفاق برای شما بیفتد.

چه کاری می توانید انجام دهید - مد در فناوری ذاتی است. حدود 5 سال پیش، مجبور شدیم یکی از این مدها را در قالب یک سایت موجود در سرور دات نت و MS SQL که با دقت تمام منطق خود سایت را ذخیره می کرد، تجدید نظر کنیم. من آن را با دقت نگه داشتم که اره کردن چنین یکپارچه لذت طولانی و اصلاً آسانی نداشت.
یک حرکت کوچک.

در رویدادهای مختلف می گویم: "اگر یکپارچه ندیدی، پس رشد نکردی!" نظر شما را در این مورد علاقه مندم، لطفا در نظرات بنویسید.

صدای رعد و برق

بیایید به "آتش" خود برگردیم. برای توزیع بار عملکرد "یکپارچه"، تصمیم گرفتیم سیستم را به ریز سرویس‌ها بر اساس فناوری‌های منبع باز تقسیم کنیم. زیرا حداقل مقیاس آنها ارزانتر است. و ما 100٪ درک داشتیم که باید مقیاس (و خیلی زیاد) کنیم. از این گذشته ، در آن زمان امکان ورود به بازارهای کشورهای همسایه وجود داشت و تعداد ثبت نام ها و همچنین تعداد سفارش ها با شدت بیشتری شروع به رشد کردند.

پس از تجزیه و تحلیل اولین نامزدهای خروج از یکپارچه به میکروسرویس ها، متوجه شدیم که 80 درصد از نوشته های موجود در آنها از سیستم های پشتیبان و خواندن از دفتر اصلی می آید. اول از همه، این به چند زیرسیستم مهم برای ما مربوط می شود - داده های کاربر و سیستمی برای محاسبه هزینه نهایی کالا بر اساس اطلاعات مربوط به تخفیف ها و کوپن های اضافی مشتری.

تورفتگی. اکنون تصور ترسناک است، اما علاوه بر زیرسیستم های ذکر شده در بالا، کاتالوگ محصولات، سبد خرید کاربر، سیستم جستجوی محصول، سیستم فیلترینگ کاتالوگ محصولات و انواع مختلف سیستم های توصیه نیز از مجموعه ما حذف شدند. برای عملکرد هر یک از آنها، کلاس های جداگانه ای از سیستم های باریک طراحی شده وجود دارد، اما روزی روزگاری همه آنها در یک "خانه" زندگی می کردند.

ما بلافاصله برنامه ریزی کردیم که داده های مربوط به مشتریان خود را به سیستم خرد شده منتقل کنیم. حذف قابلیت محاسبه بهای تمام شده نهایی کالا مستلزم مقیاس پذیری خوبی برای خواندن بود، زیرا بیشترین بار RPS را ایجاد می کرد و اجرای آن برای پایگاه داده سخت ترین بود (داده های زیادی در فرآیند محاسبه دخیل هستند).

در نتیجه، ما به طرحی رسیدیم که به خوبی با Tarantool مطابقت دارد.

در آن زمان، برای بهره برداری از میکروسرویس ها، طرح هایی برای کار با چندین مرکز داده در ماشین های مجازی و سخت افزاری انتخاب شد. همانطور که در شکل ها نشان داده شده است، گزینه های تکرار Tarantool در هر دو حالت master-master و master-slave اعمال شدند.

معماری. گزینه 1. خدمات کاربر

در حال حاضر، 24 قطعه قطعه وجود دارد که هر کدام دارای 2 نمونه (یکی برای هر DC) هستند که همه در حالت Master-Master هستند.

در بالای پایگاه داده برنامه هایی قرار دارند که به نسخه های مشابه پایگاه داده دسترسی دارند. برنامه ها با Tarantool از طریق کتابخانه سفارشی ما کار می کنند، که رابط راننده Tarantool Go را پیاده سازی می کند. او همه ماکت ها را می بیند و می تواند با استاد برای خواندن و نوشتن کار کند. اساساً، مدل مجموعه replica را پیاده‌سازی می‌کند، که منطق را برای انتخاب کپی‌ها، انجام تلاش‌های مجدد، قطع کننده مدار و محدودیت نرخ اضافه می‌کند.

در این حالت، امکان پیکربندی سیاست انتخاب replica در زمینه shard ها وجود دارد. به عنوان مثال، راندروبین.

معماری. گزینه 2. خدمات برای محاسبه بهای تمام شده نهایی کالا

چند ماه پیش اکثر درخواست ها برای محاسبه بهای تمام شده نهایی کالا به سرویس جدیدی می رفت که اصولاً بدون بانک اطلاعاتی کار می کند، اما مدتی پیش همه چیز به صورت 100% توسط سرویسی با Tarantool زیر کاپوت پردازش شد.

پایگاه داده سرویس از 4 Master تشکیل شده است که همگام ساز داده ها را در آنها جمع آوری می کند و هر یک از این Master Replication داده ها را در Replica های فقط خواندنی توزیع می کند. هر استاد تقریباً 15 نسخه مشابه دارد.

در طرح اول یا دوم، اگر یک DC در دسترس نباشد، برنامه می تواند داده ها را در طرح دوم دریافت کند.

شایان ذکر است که Replication در Tarantool کاملاً منعطف است و در زمان اجرا قابل پیکربندی است. در سیستم های دیگر، مشکلات به وجود آمد. به عنوان مثال، تغییر پارامترهای max_wal_senders و max_replication_slots در PostgreSQL نیاز به راه اندازی مجدد ویزارد دارد که در برخی موارد می تواند منجر به قطع اتصالات بین برنامه و DBMS شود.

بگرد و پیدا کن!

چرا ما این کار را "مانند افراد عادی" انجام ندادیم، بلکه یک راه غیر معمول را انتخاب کردیم؟ بستگی به این دارد که چه چیزی طبیعی در نظر گرفته شود. بسیاری از مردم به طور کلی یک خوشه از Mongo می سازند و آن را در سه DC توزیع شده جغرافیایی پخش می کنند.

در آن زمان ما دو پروژه Redis را داشتیم. اولی یک حافظه پنهان و دومی یک ذخیره سازی دائمی برای داده های نه چندان مهم بود. با او بسیار سخت بود، تا حدی به تقصیر ما. گاهی اوقات حجم های بسیار زیادی در کلید قرار می گرفت و هر از گاهی سایت بد می شد. ما از این سیستم در نسخه master-slave استفاده کردیم. و موارد زیادی بود که برای استاد اتفاقی افتاد و replication خراب شد.

یعنی Redis برای کارهای بدون تابعیت خوب است، نه برای کارهای دولتی. در اصل، حل اکثر مسائل را امکان پذیر می کرد، اما تنها در صورتی که راه حل های کلیدی-مقدار با یک جفت شاخص باشند. اما ردیس در آن زمان با پشتکار و تکرار بسیار غمگین بود. علاوه بر این، شکایاتی در مورد عملکرد وجود داشت.

ما به MySQL و PostgreSQL فکر کردیم. اما اولین مورد به نوعی مورد توجه ما قرار نگرفت، و دومی به خودی خود یک محصول نسبتاً پیچیده است و ساخت سرویس های ساده بر روی آن نامناسب است.
ما RIAK، Cassandra، حتی یک پایگاه داده گراف را امتحان کردیم. اینها همه راه حل های نسبتاً ویژه ای هستند که برای نقش یک ابزار جهانی عمومی برای ایجاد خدمات مناسب نیستند.

در نهایت ما در Tarantool مستقر شدیم.

زمانی که در نسخه 1.6 بود به آن روی آوردیم. ما با همزیستی کلید-مقدار و عملکرد یک پایگاه داده رابطه ای به آن علاقه مند شدیم. ایندکس‌ها، تراکنش‌ها و فضاهای ثانویه وجود دارد، این‌ها مانند جداول هستند، اما ساده نیستند، می‌توانید تعداد ستون‌های مختلفی را در آنها ذخیره کنید. اما ویژگی قاتل Tarantool ایندکس های ثانویه همراه با ارزش کلیدی و تراکنشی بود.

جامعه روسی زبان پاسخگو که آماده کمک در چت بود نیز نقش داشت. ما به طور فعال از این استفاده کردیم و مستقیماً در چت زندگی می کنیم. و پایداری مناسب را بدون اشتباهات و اشتباهات آشکار فراموش نکنید. اگر به تاریخچه ما با Tarantool نگاه کنید، درد و نارسایی زیادی با Replication داشتیم، اما به خاطر تقصیر آن هرگز اطلاعات را از دست ندادیم!

پیاده سازی شروع سختی داشت

در آن زمان، پشته توسعه اصلی ما دات نت بود که هیچ رابطی برای Tarantool وجود نداشت. ما بلافاصله شروع به انجام کاری در Go کردیم. با لوا هم خوب کار کرد. مشکل اصلی در آن زمان اشکال زدایی بود: در دات نت همه چیز با این کار عالی است، اما پس از آن غوطه ور شدن در دنیای Lua تعبیه شده دشوار بود، زمانی که هیچ اشکال زدایی به جز لاگ ندارید. علاوه بر این، به دلایلی، تکرار به طور دوره ای از بین می رفت، بنابراین من مجبور شدم ساختار موتور Tarantool را بررسی کنم. چت به این امر کمک کرد، و تا حدی مستندات؛ گاهی اوقات ما به کد نگاه می‌کردیم. در آن زمان اسناد و مدارک چنین بود.

بنابراین، در طول چندین ماه، موفق شدم به نتیجه برسم و از کار با Tarantool نتایج مناسبی بگیرم. ما پیشرفت‌های مرجع در git را گردآوری کردیم که به شکل‌گیری میکروسرویس‌های جدید کمک کرد. به عنوان مثال، هنگامی که یک وظیفه ایجاد شد: ایجاد یک میکروسرویس دیگر، توسعه دهنده به کد منبع راه حل مرجع در مخزن نگاه کرد و بیش از یک هفته طول کشید تا یک مورد جدید ایجاد کند.

این زمان های خاصی بود. به طور معمول، می‌توانید به سراغ مدیر جدول بعدی بروید و بپرسید: «یک ماشین مجازی به من بدهید». حدود سی دقیقه بعد ماشین از قبل همراه شما بود. خودت وصل شدی، همه چیز را نصب کردی و ترافیک برایت ارسال شد.

امروز این دیگر کار نخواهد کرد: باید نظارت و ورود به سرویس را اضافه کنید، عملکرد را با آزمایشات پوشش دهید، یک ماشین مجازی سفارش دهید یا تحویل به Kuber و غیره کنید. به طور کلی، این روش بهتر خواهد بود، اگرچه بیشتر طول می کشد و دردسر بیشتری خواهد داشت.

تفرقه بینداز و حکومت کن. ماجرای لوا چیست؟

یک معضل جدی وجود داشت: برخی از تیم ها نتوانستند به طور قابل اعتماد تغییراتی را در سرویسی با منطق زیاد در Lua اعمال کنند. این اغلب با کار نکردن سرویس همراه بود.

یعنی توسعه دهندگان در حال آماده سازی نوعی تغییر هستند. Tarantool شروع به انجام مهاجرت می کند، اما ماکت هنوز با کد قدیمی است. مقداری از DDL یا چیز دیگری از طریق Replication به آنجا می رسد و کد به سادگی از بین می رود زیرا در نظر گرفته نمی شود. در نتیجه، روش به روز رسانی برای مدیران در صفحه A4 گذاشته شد: تکرار را متوقف کنید، این را به روز کنید، تکرار را روشن کنید، اینجا را خاموش کنید، آنجا را به روز کنید. کابوس!

در نتیجه، اکنون ما اغلب سعی می کنیم در لوا هیچ کاری انجام ندهیم. فقط از iproto (یک پروتکل باینری برای تعامل با سرور) استفاده کنید و تمام. شاید این کمبود دانش در بین توسعه دهندگان باشد، اما از این نظر سیستم پیچیده است.

ما همیشه کورکورانه از این فیلمنامه پیروی نمی کنیم. امروز ما سیاه و سفید نداریم: یا همه چیز در لوا است یا همه چیز در گو است. ما قبلاً درک کرده ایم که چگونه می توانیم آنها را ترکیب کنیم تا بعداً با مشکلات مهاجرت مواجه نشویم.

ترانتول الان کجاست؟
Tarantool در سرویس محاسبه بهای تمام شده نهایی کالا با در نظر گرفتن کوپن های تخفیف که به آن «پروموتر» نیز گفته می شود، استفاده می شود. همانطور که قبلاً گفتم، او اکنون در حال بازنشستگی است: او با یک سرویس کاتالوگ جدید با قیمت های از پیش محاسبه شده جایگزین می شود، اما شش ماه پیش همه محاسبات در Promotizer انجام شد. قبلاً نیمی از منطق آن به زبان لوا نوشته می شد. دو سال پیش این سرویس به انبار تبدیل شد و منطق آن در Go بازنویسی شد، زیرا مکانیزم تخفیف ها کمی تغییر کرده بود و سرویس فاقد عملکرد بود.

یکی از مهم ترین خدمات، نمایه کاربر است. یعنی همه کاربران Wildberries در Tarantool ذخیره می‌شوند و حدود 50 میلیون نفر از آنها وجود دارد. سیستمی که توسط شناسه کاربر تقسیم شده است که در چندین DC متصل به سرویس Go توزیع شده است.
به گفته RPS، Promoter زمانی رهبر بود و به 6 هزار درخواست رسید. یک زمانی 50-60 نسخه داشتیم. در حال حاضر رهبر در RPS پروفایل های کاربر است، حدود 12 هزار. این سرویس از اشتراک گذاری سفارشی، تقسیم بر محدوده شناسه های کاربر استفاده می کند. این سرویس به بیش از 20 دستگاه سرویس می دهد، اما این تعداد زیاد است؛ ما قصد داریم منابع تخصیص یافته را کاهش دهیم، زیرا ظرفیت 4-5 دستگاه برای آن کافی است.

سرویس Session اولین سرویس ما در vshard و Cartridge است. راه‌اندازی vshard و به‌روزرسانی کارتریج به تلاش ما نیاز داشت، اما در نهایت همه چیز درست شد.

سرویس نمایش بنرهای مختلف در وب سایت و اپلیکیشن موبایل جزو اولین سرویس هایی بود که به صورت مستقیم در Tarantool منتشر شد. این سرویس به این دلیل قابل توجه است که 6-7 ساله است، هنوز در حال کار است و هرگز راه اندازی مجدد نشده است. Master-Master Replication استفاده شد. هیچ چیز هرگز شکسته نشد.

نمونه ای از استفاده از Tarantool برای عملکرد مرجع سریع در یک سیستم انبار برای بررسی سریع اطلاعات در برخی موارد وجود دارد. ما سعی کردیم از Redis برای این کار استفاده کنیم، اما داده های حافظه فضای بیشتری را نسبت به Tarantool اشغال کردند.

خدمات لیست انتظار، اشتراک مشتری، داستان های مد روز و کالاهای معوق نیز با Tarantool کار می کند. آخرین سرویس در حافظه حدود 120 گیگابایت را اشغال می کند. این جامع ترین سرویس از موارد فوق است.

نتیجه

به لطف شاخص‌های ثانویه همراه با ارزش کلیدی و تراکنشی، Tarantool برای معماری‌های مبتنی بر میکروسرویس مناسب است. با این حال، هنگام ایجاد تغییرات در خدمات با منطق زیاد در Lua با مشکلاتی مواجه شدیم - خدمات اغلب از کار می‌افتند. ما نتوانستیم بر این مسئله غلبه کنیم و با گذشت زمان به ترکیب‌های مختلفی از Lua و Go رسیدیم: می‌دانیم کجا از یک زبان و کجا از زبان دیگر استفاده کنیم.

چه چیز دیگری در مورد موضوع بخوانید

• ایجاد یک برنامه با بار بالا از ابتدا با استفاده از Tarantool habr.com/ru/company/mailru/blog/510440
• انتخاب رهبر مورد اعتماد در کارتریج Tarantool habr.com/ru/company/mailru/blog/513912
• کانال تلگرام ترانتول با اخبار محصول t.me/tarantool_news
• درباره Tarantool در چت جامعه بحث کنید t.me/tarantoolru

منبع: www.habr.com