تاریخچه معماری Dodo IS: مسیر پشت دفتر

هابر در حال تغییر جهان است. الان بیش از یک سال است که وبلاگ می نویسیم. حدود شش ماه پیش بازخورد کاملاً منطقی از Khabrovites دریافت کردیم: «دودو، شما همه جا می گویید که سیستم خود را دارید. و این سیستم چیست؟ و چرا یک پیتزا زنجیره ای به آن نیاز دارد؟

نشستیم، فکر کردیم و فهمیدیم حق با شماست. ما سعی می کنیم همه چیز را در انگشتان خود توضیح دهیم، اما به صورت تکه پاره بیرون می آید و هیچ کجا توصیف کاملی از سیستم وجود ندارد. بدین ترتیب یک سفر طولانی در جمع آوری اطلاعات، جستجوی نویسندگان و نوشتن مجموعه ای از مقالات در مورد Dodo IS آغاز شد. بیا بریم!

تشکر و قدردانی: از اینکه نظرات خود را با ما در میان گذاشتید متشکریم. با تشکر از او، ما در نهایت سیستم را توصیف کردیم، یک رادار فنی جمع آوری کردیم و به زودی توضیحات گسترده ای از فرآیندهای خود را ارائه خواهیم داد. بدون تو ما 5 سال دیگر آنجا می نشستیم.

مجموعه مقالات "دودو IS چیست؟" می گوید در مورد:

1. یکپارچگی اولیه در Dodo IS (2011-2015). (در حال پیش رفت...)
2. مسیر بک آفیس: پایه و اتوبوس مجزا. (تو اینجایی)
3. مسیر سمت مشتری: نما بر روی پایه (2016-2017). (در حال پیش رفت...)
4. تاریخچه میکروسرویس های واقعی (2018-2019). (در حال پیش رفت...)
5. اره کاری یکپارچه و تثبیت معماری به پایان رسید. (در حال پیش رفت...)

اگر علاقه مند به دانستن چیز دیگری هستید - در نظرات بنویسید.

نظر در مورد شرح زمانی از نویسنده
من به طور منظم جلسه ای برای کارمندان جدید با موضوع "معماری سیستم" برگزار می کنم. ما آن را «معرفی معماری Dodo IS» می نامیم و بخشی از فرآیند نصب برای توسعه دهندگان جدید است. با گفتن به یک شکل در مورد معماری ما، در مورد ویژگی های آن، من یک رویکرد تاریخی خاص برای توصیف ایجاد کرده ام.

به طور سنتی، ما به سیستم به عنوان مجموعه‌ای از اجزا (فنی یا سطح بالاتر)، ماژول‌های تجاری که برای رسیدن به هدفی با یکدیگر تعامل دارند، نگاه می‌کنیم. و اگر چنین دیدگاهی برای طراحی موجه باشد، برای توصیف و درک کاملاً مناسب نیست. در اینجا چند دلیل وجود دارد:

• واقعیت با آنچه روی کاغذ است متفاوت است. همه چیز طبق برنامه پیش نمی رود. و ما علاقه مندیم که بدانیم در واقع چگونه معلوم شده و چگونه کار می کند.
• ارائه مداوم اطلاعات در واقع، شما می توانید به صورت زمانی از ابتدا به وضعیت فعلی بروید.
• از ساده به پیچیده. نه جهانی، اما در مورد ما اینطور است. معماری از رویکردهای ساده تر به رویکردهای پیچیده تر حرکت کرد. اغلب از طریق پیچیدگی، مشکلات سرعت و پایداری پیاده سازی و همچنین ده ها ویژگی دیگر از لیست الزامات غیر کاربردی حل می شد.اینجا در مورد تضاد پیچیدگی با سایر الزامات به خوبی گفته شد).

در سال 2011، معماری Dodo IS به این صورت بود:

تا سال 2020، کمی پیچیده تر شده است و به این صورت شده است:

این تکامل چگونه اتفاق افتاد؟ چرا بخش های مختلف سیستم مورد نیاز است؟ چه تصمیمات معماری گرفته شد و چرا؟ بیایید در این سری مقالات بدانیم.

اولین مشکلات سال 2016: چرا خدمات باید یکپارچه را ترک کنند

اولین مقالات از چرخه در مورد خدماتی خواهد بود که برای اولین بار از یکپارچه جدا شدند. برای قرار دادن شما در شرایط، به شما می گویم که تا ابتدای سال 2016 چه مشکلاتی در سیستم داشتیم که مجبور شدیم با جداسازی خدمات مقابله کنیم.

یک پایگاه داده واحد MySql، که در آن تمام برنامه هایی که در آن زمان در Dodo IS وجود داشتند، سوابق خود را می نوشتند. پیامدها عبارت بودند از:

• بار سنگین (با 85٪ از درخواست ها برای خواندن).
• پایه رشد کرده است. به همین دلیل هزینه و پشتیبانی آن مشکل ساز شد.
• تنها نقطه شکست اگر یکی از برنامه‌هایی که در پایگاه داده می‌نویسد ناگهان شروع به انجام آن فعال‌تر کند، دیگر برنامه‌ها آن را روی خود احساس می‌کنند.
• ناکارآمدی در ذخیره سازی و پرس و جو. اغلب داده ها در ساختاری ذخیره می شدند که برای برخی سناریوها مناسب بود اما برای برخی دیگر مناسب نبود. شاخص ها برخی از عملیات ها را سرعت می بخشند، اما می توانند برخی از عملیات ها را کاهش دهند.
• برخی از مشکلات با حافظه پنهان ساخته شده با عجله و کپی خواندن در پایگاه ها حذف شدند (این مقاله جداگانه ای خواهد بود)، اما آنها فقط به آنها اجازه دادند تا زمان کسب کنند و اساساً مشکل را حل نکردند.

مشکل وجود خود یکپارچه بود. پیامدها عبارت بودند از:

• نسخه های تک و کمیاب.
• مشکل در رشد مشترک تعداد زیادی از افراد.
• ناتوانی در آوردن فناوری های جدید، چارچوب ها و کتابخانه های جدید.

مشکلات مربوط به پایه و یکپارچه بارها توصیف شده است، به عنوان مثال، در زمینه تصادفات در اوایل سال 2018 (مانند مونک یا چند کلمه در مورد بدهی فنی باشید, روزی که Dodo IS متوقف شد. اسکریپت ناهمزمان и داستان پرنده دودو از خانواده ققنوس. سقوط بزرگ دودو است)، بنابراین من زیاد درگیر نمی شوم. اجازه دهید فقط بگویم که ما می خواستیم در هنگام توسعه خدمات انعطاف پذیری بیشتری داشته باشیم. اول از همه، این مربوط به کسانی بود که بیشترین بارگذاری و ریشه در کل سیستم را داشتند - Auth و Tracker.

مسیر پشت آفیس: پایگاه ها و اتوبوس های جداگانه

ناوبری فصل

1. طرح یکپارچه 2016
2. شروع به تخلیه Monolith: Auth و Tracker Separation
   
3. Auth چه می کند؟
4. بارها از کجاست؟
5. در حال بارگیری Auth
6. ردیاب چه می کند؟
7. بارها از کجاست؟
8. تخلیه ردیاب

طرح یکپارچه 2016

در اینجا بلوک های اصلی Dodo IS 2016 یکپارچه وجود دارد و درست در زیر متنی از وظایف اصلی آنها است.

تحویل صندوقدار. حسابداری پیک، صدور سفارش به پیک.
مرکز تماس. پذیرش سفارش از طریق اپراتور.
سایت. وب سایت های ما (dodopizza.ru، dodopizza.co.uk، dodopizza.by، و غیره).
اتهام. خدمات مجوز و احراز هویت برای دفتر پشتیبان.
ردیاب. ردیاب سفارش در آشپزخانه. خدمات علامت گذاری وضعیت آمادگی هنگام تهیه سفارش.
میز نقدی رستوران. گرفتن سفارش در یک رستوران، رابط صندوقدار.
صادرات. بارگذاری گزارش ها در 1C برای حسابداری.
اطلاعیه ها و فاکتورها. دستورات صوتی در آشپزخانه (به عنوان مثال، "پیتزای جدید رسید") + چاپ فاکتور برای پیک.
مدیر شیفت. رابط های کار مدیر شیفت: لیست سفارشات، نمودارهای عملکرد، انتقال کارکنان به شیفت.
مدیر دفتر. رابط های کار حق رای و مدیر: پذیرش کارمندان، گزارش های مربوط به کار پیتزا فروشی.
جدول امتیاز رستوران. نمایش منو در تلویزیون های پیتزا فروشی.
مدیر. تنظیمات در یک پیتزا فروشی خاص: منو، قیمت ها، حسابداری، کدهای تبلیغاتی، تبلیغات، بنرهای وب سایت و غیره.
حساب شخصی کارمند. برنامه کاری کارکنان، اطلاعات در مورد کارمندان.
تابلوی انگیزه آشپزخانه. یک صفحه نمایش مجزا که در آشپزخانه آویزان است و سرعت پیتزاسازها را نمایش می دهد.
ارتباط. ارسال اس ام اس و ایمیل.
ذخیره سازی فایل. سرویس خود برای دریافت و صدور فایل های استاتیک.

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

شروع به تخلیه Monolith: Auth و Tracker Separation

خدمات اصلی که پس از آن بیشتر از سایرین از پایگاه داده ضبط و خوانده شدند:

1. احراز هویت خدمات مجوز و احراز هویت برای دفتر پشتیبان.
2. ردیاب. ردیاب سفارش در آشپزخانه. خدمات علامت گذاری وضعیت آمادگی هنگام تهیه سفارش.

Auth چه می کند؟

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

به عنوان مثال، می خواهیم نمایشگری را با وضعیت سفارشات تمام شده در تلویزیون آویزان در سالن باز کنیم. سپس auth.dodopizza.ru را باز می کنیم، "ورود به عنوان دستگاه" را انتخاب می کنیم، کدی ظاهر می شود که می تواند در یک صفحه ویژه در رایانه مدیر شیفت وارد شود، که نوع دستگاه (دستگاه) را نشان می دهد. خود تلویزیون به رابط مورد نظر پیتزا فروشی خود می رود و شروع به نمایش نام مشتریانی می کند که سفارشات آنها در آنجا آماده است.

بارها از کجاست؟

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

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

در حال بارگیری Auth

Auth یک دامنه ایزوله دارد، یعنی داده‌های مربوط به کاربران، لاگین‌ها یا دستگاه‌ها وارد سرویس می‌شوند (فعلا) و در آنجا باقی می‌مانند. اگر کسی به آنها نیاز داشته باشد، برای داده به این سرویس می رود.

بود. طرح اولیه کار به شرح زیر بود:

من می خواهم کمی توضیح دهم که چگونه کار کرد:

1. یک درخواست از خارج به باطن می آید (Asp.Net MVC وجود دارد)، یک کوکی جلسه را با خود می آورد که برای دریافت داده های جلسه از Redis(1) استفاده می شود. این یا حاوی اطلاعاتی در مورد دسترسی ها است و سپس دسترسی به کنترل کننده باز است (3,4،XNUMX) یا خیر.
2. اگر دسترسی وجود ندارد، باید مراحل مجوز را طی کنید. در اینجا، برای سادگی، به عنوان بخشی از مسیر در همان ویژگی نشان داده شده است، اگرچه انتقال به صفحه ورود است. در صورت سناریوی مثبت، یک جلسه به درستی تکمیل شده دریافت می کنیم و به کنترلر Backoffice می رویم.
3. اگر داده وجود دارد، باید آن را برای ارتباط در پایگاه کاربر بررسی کنید. آیا نقش او تغییر کرده است، حالا نباید اجازه ورود به صفحه را بدهند؟ در این حالت پس از دریافت جلسه (1) باید مستقیماً به پایگاه داده رفته و با استفاده از لایه منطق احراز هویت (2) دسترسی کاربر را بررسی کنید. بعد، یا به صفحه ورود یا به کنترلر بروید. چنین سیستم ساده ای، اما نه کاملاً استاندارد.
4. اگر همه رویه‌ها تصویب شوند، از منطق کنترل‌کننده‌ها و متدها عبور می‌کنیم.

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

تبدیل شدن. بنابراین آنها چنین کردند:

این رویکرد یک سری مشکلات دارد. به عنوان مثال، فراخوانی یک متد در داخل یک فرآیند مشابه فراخوانی یک سرویس خارجی از طریق http نیست. تأخیر، قابلیت اطمینان، قابلیت نگهداری، شفافیت عملیات کاملاً متفاوت است. آندری موروفسکی در گزارش خود با جزئیات بیشتری در مورد چنین مشکلاتی صحبت کرد. "50 Shades of Microservices".

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

چرا جدایی اینقدر طول کشید؟
مشکلات زیادی در این مسیر وجود داشت که ما را کند کرد:

1. ما می‌خواستیم داده‌های کاربر، دستگاه و احراز هویت را از پایگاه‌های داده خاص کشور به یکی منتقل کنیم. برای انجام این کار، ما مجبور شدیم تمام جداول و استفاده را از شناسه int به شناسه جهانی UUId ترجمه کنیم (این کد اخیراً دوباره کار شده است. رومن بوکین "Uuid - داستان بزرگ یک سازه کوچک" و پروژه متن باز اولیه). ذخیره سازی داده های کاربر (از آنجایی که اطلاعات شخصی است) محدودیت های خود را دارد و برای برخی از کشورها لازم است آنها به طور جداگانه ذخیره شوند. اما شناسه جهانی کاربر باید باشد.
2. بسیاری از جداول در پایگاه داده دارای اطلاعات ممیزی در مورد کاربری است که عملیات را انجام داده است. این نیاز به یک مکانیسم اضافی برای سازگاری داشت.
3. پس از ایجاد سرویس های api، یک دوره طولانی و تدریجی انتقال به سیستم دیگری وجود داشت. سوئیچینگ باید برای کاربران بدون درز باشد و نیاز به کار دستی داشت.

طرح ثبت دستگاه در یک پیتزا فروشی:

معماری عمومی پس از استخراج سرویس Auth and Devices:

یادداشت. برای سال 2020، ما روی نسخه جدیدی از Auth کار می کنیم که بر اساس استاندارد مجوز OAuth 2.0 است. این استاندارد بسیار پیچیده است، اما برای توسعه یک سرویس احراز هویت عبوری مفید است. در مقاله "نکات ظریف مجوز: مروری بر فناوری OAuth 2.0» ما الکسی چرنیایف سعی کردیم تا حد امکان ساده و واضح در مورد استاندارد صحبت کنیم تا در مطالعه آن در زمان صرفه جویی کنید.

ردیاب چه می کند؟

اکنون در مورد دومین سرویس بارگذاری شده است. ردیاب یک نقش دوگانه را انجام می دهد:

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

هنگامی که یک محصول جدید در یک سفارش ظاهر می شود (مثلاً پیتزا)، به ایستگاه ردیاب Rolling out می رود. در این ایستگاه، یک پیتزاساز وجود دارد که یک نان به اندازه لازم را می گیرد و آن را می غلتاند، پس از آن روی تبلت ردیاب یادداشت می کند که کار خود را انجام داده است و پایه خمیر نورد شده را به ایستگاه بعدی - "شروع" منتقل می کند. .

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

صفحه نمایش تبلت در ایستگاه ردیاب "راسکاتکا" اینگونه به نظر می رسد

بارها از کجاست؟

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

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

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

بود. معماری اولیه این بود:

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

تخلیه ردیاب

مشکل اصلی ردیاب این است که داده ها باید بین پایگاه داده های مختلف همگام شوند. این نیز تفاوت اصلی آن با جداسازی سرویس Auth است، ترتیب و وضعیت آن می تواند تغییر کند و باید در سرویس های مختلف نمایش داده شود.

ما سفارشی را در صندوق رستوران می پذیریم (این یک سرویس است)، در پایگاه داده در وضعیت "پذیرفته شده" ذخیره می شود. پس از آن، او باید به ردیاب برسد، جایی که وضعیت خود را چندین بار تغییر می دهد: از "آشپزخانه" به "بسته بندی شده". در همان زمان، برخی از تأثیرات خارجی از صندوقدار یا رابط مدیر Shift ممکن است با سفارش رخ دهد. وضعیت سفارش ها را با توضیحات آنها در جدول می دهم:

طرح تغییر وضعیت سفارش به این صورت است:

وضعیت ها بین سیستم های مختلف تغییر می کند. و در اینجا ردیاب یک سیستم نهایی نیست که در آن داده ها بسته شده باشد. ما چندین روش ممکن برای پارتیشن بندی در چنین موردی دیده ایم:

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

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

در آن زمان، ما قبلا RabbitMQ را در پشته داشتیم، بنابراین تصمیم نهایی برای استفاده از آن به عنوان واسطه پیام گرفته شد. نمودار انتقال یک سفارش از صندوق رستوران از طریق ردیاب را نشان می دهد، جایی که وضعیت آن و نمایش آن در رابط سفارشات مدیر تغییر می کند. تبدیل شدن:

مراحل را مرحله به مرحله سفارش دهید
مسیر سفارش از یکی از خدمات منبع سفارش شروع می شود. صندوقدار رستوران اینجاست:

1. در هنگام پرداخت، سفارش کاملا آماده است و زمان ارسال آن به ردیاب است. رویدادی که ردیاب در آن مشترک شده است پرتاب می شود.
2. ردیاب با پذیرش سفارش برای خود، آن را در پایگاه داده خود ذخیره می کند، رویداد "سفارش توسط ردیاب پذیرفته شد" و ارسال آن به RMQ.
3. چندین کنترل کننده در حال حاضر در اتوبوس رویداد در هر سفارش مشترک شده اند. برای ما، چیزی که همگام سازی را با پایه یکپارچه انجام می دهد مهم است.
4. کنترل کننده یک رویداد را دریافت می کند، از آن داده هایی را انتخاب می کند که برای آن مهم است: در مورد ما، این وضعیت سفارش "پذیرفته شده توسط ردیاب" است و موجودیت سفارش خود را در پایگاه داده اصلی به روز می کند.

اگر شخصی به سفارشی از سفارشات جدول یکپارچه نیاز دارد، می توانید آن را از آنجا نیز بخوانید. به عنوان مثال، رابط سفارشات در Shift Manager به این نیاز دارد:

همه خدمات دیگر همچنین می توانند برای سفارش رویدادها از ردیاب مشترک شوند تا از آنها برای خود استفاده کنند.

اگر پس از مدتی سفارش وارد کار شد، ابتدا وضعیت آن در پایگاه داده (پایگاه داده Tracker) تغییر می کند و بلافاصله رویداد OrderIn Progress تولید می شود. همچنین وارد RMQ می شود، از آنجا در یک پایگاه داده یکپارچه همگام سازی می شود و به سرویس های دیگر تحویل می شود. ممکن است مشکلات مختلفی در این راه وجود داشته باشد، جزئیات بیشتر در مورد آنها را می توان در گزارش ژنیا پشکوف یافت در مورد جزئیات پیاده سازی سازگاری نهایی در ردیاب.

معماری نهایی پس از تغییرات در Auth و Tracker

جمع بندی نتیجه میانی: در ابتدا، من این ایده را داشتم که تاریخ نه ساله سیستم Dodo IS را در یک مقاله جمع کنم. می خواستم سریع و ساده در مورد مراحل تکامل صحبت کنم. با این حال، نشستن برای مطالب، متوجه شدم که همه چیز بسیار پیچیده تر و جالب تر از آن چیزی است که به نظر می رسد.

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

امیدوارم آشنایی با مسیر ما برای شما مفید و جالب بوده باشد. اکنون با انتخابی روبرو هستم که کدام بخش از سیستم Dodo IS را در مقاله بعدی شرح دهم: در نظرات بنویسید یا رای دهید.

فقط کاربران ثبت نام شده می توانند در نظرسنجی شرکت کنند. ورود، لطفا.

دوست دارید در مقاله بعدی درباره چه بخشی از Dodo IS بدانید؟

• ٪۱۰۰یکپارچگی اولیه در Dodo IS (2011-2015)14

• ٪۱۰۰مسائل اول و راه حل آنها (2015-2016)14

• ٪۱۰۰مسیر سمت مشتری: نما روی پایه (2016-2017)12

• ٪۱۰۰تاریخچه میکروسرویس های واقعی (2018-2019)21

• ٪۱۰۰اره زنی کامل یکپارچه و تثبیت معماری26

• ٪۱۰۰درباره برنامه های بعدی برای توسعه سیستم17

• ٪۱۰۰من نمی خواهم چیزی در مورد Dodo IS11 بدانم

58 کاربر رای دادند. 6 کاربر رای ممتنع دادند.

منبع: www.habr.com