تاریخچه معماری Dodo IS: An Early Monolith

یا هر شرکت ناراضی با یکپارچه به روش خود ناراضی است.

توسعه سیستم Dodo IS بلافاصله مانند کسب و کار Dodo Pizza در سال 2011 آغاز شد. این بر اساس ایده دیجیتالی شدن کامل و کامل فرآیندهای تجاری و خودشان، که حتی در آن زمان در سال 2011 سوالات و تردیدهای زیادی را به همراه داشت. اما اکنون 9 سال است که ما این مسیر را دنبال می کنیم - با توسعه خودمان که با یکپارچگی آغاز شد.

این مقاله پاسخی است به این سؤال که «چرا معماری را بازنویسی کنیم و چنین تغییرات بزرگ و بلندمدتی ایجاد کنیم؟» بازگشت به مقاله قبلی "تاریخچه معماری Dodo IS: راه بک آفیس". من با این شروع خواهم کرد که توسعه Dodo IS چگونه آغاز شد، معماری اصلی چگونه به نظر می رسید، ماژول های جدید چگونه ظاهر شدند و به دلیل مشکلاتی که باید تغییرات در مقیاس بزرگ ایجاد می شد.

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

1. یکپارچگی اولیه در Dodo IS (2011-2015). (تو اینجایی)

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

3. مسیر سمت مشتری: نما بر روی پایه (2016-2017). (در حال پیش رفت...)

4. تاریخچه میکروسرویس های واقعی (2018-2019). (در حال پیش رفت...)

5. اره کاری یکپارچه و تثبیت معماری به پایان رسید. (در حال پیش رفت...)

معماری اولیه

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

اولین ماژول در معماری پذیرش سفارش است. فرآیند کسب و کار این بود:

• مشتری با پیتزا فروشی تماس می گیرد.

• مدیر تلفن را برمی دارد؛

• سفارش تلفنی را می پذیرد؛

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

رابط سیستم اطلاعات چیزی شبیه به این بود ...

اولین نسخه از اکتبر 2011:

در ژانویه 2012 اندکی بهبود یافته است

سیستم اطلاعات پیتزا دودو تحویل رستوران پیتزا

منابع برای توسعه اولین ماژول گرفتن سفارش محدود بود. ما باید خیلی کارها را سریع و با یک تیم کوچک انجام می دادیم. یک تیم کوچک 2 توسعه دهنده هستند که پایه و اساس کل سیستم آینده را بنا نهادند.

اولین تصمیم آنها سرنوشت پشته فناوری را تعیین کرد:

• Backend در ASP.NET MVC، زبان C#. توسعه دهندگان dotnetchiki بودند، این پشته برای آنها آشنا و دلپذیر بود.

• Frontend در Bootstrap و JQuery: رابط های کاربری در سبک ها و اسکریپت های خودنویس. 

• پایگاه داده MySQL: بدون هزینه مجوز، آسان برای استفاده.

• سرورهای روی ویندوز سرور، زیرا دات نت تنها می تواند تحت ویندوز باشد (ما در مورد Mono بحث نمی کنیم).

از نظر فیزیکی، همه اینها در "دیدیک در میزبان" بیان شد. 

سفارش معماری کاربردی ورودی

سپس همه قبلاً در مورد میکروسرویس ها صحبت می کردند و SOA به مدت 5 سال در پروژه های بزرگ استفاده شد ، به عنوان مثال WCF در سال 2006 منتشر شد. اما سپس آنها یک راه حل قابل اعتماد و اثبات شده را انتخاب کردند.

ایناهاش.

Asp.Net MVC Razor است که به درخواست فرم یا مشتری، یک صفحه HTML را با رندر سرور ارائه می کند. در کلاینت، اسکریپت های CSS و JS از قبل اطلاعاتی را نمایش می دهند و در صورت لزوم، درخواست های AJAX را از طریق JQuery انجام می دهند.

درخواست‌های روی سرور به کلاس‌های *Controller ختم می‌شوند، جایی که پردازش و تولید صفحه نهایی HTML در روش انجام می‌شود. کنترل‌کننده‌ها درخواست‌هایی را به لایه‌ای از منطق به نام سرویس‌ها ارسال می‌کنند. هر یک از خدمات با جنبه ای از تجارت مطابقت داشت:

• به عنوان مثال، DepartmentStructureService اطلاعاتی در مورد پیتزا فروشی ها، در بخش ها ارائه کرد. دپارتمان گروهی از پیتزافروشی ها است که توسط یک فرنچایز اداره می شود.

• ReceivingOrdersService ترکیب سفارش را پذیرفت و محاسبه کرد.

• و SmsService با تماس با سرویس های API برای ارسال پیامک، پیامک ارسال کرد.

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

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

همه اینها را می توان با چنین مدلی نشان داد:

راه سفارش

یک راه اولیه ساده برای ایجاد چنین نظمی را در نظر بگیرید.

در ابتدا، سایت ثابت بود. قیمت روی آن بود و در بالا - یک شماره تلفن و نوشته "اگر پیتزا می خواهید - با شماره تماس بگیرید و سفارش دهید." برای سفارش، باید یک جریان ساده را پیاده سازی کنیم: 

• مشتری از یک سایت ثابت با قیمت بازدید می کند، محصولات را انتخاب می کند و با شماره درج شده در سایت تماس می گیرد.

• مشتری محصولاتی را که می خواهد به سفارش اضافه کند نام می برد.

• آدرس و نامش را می دهد.

• اپراتور سفارش را می پذیرد.

• سفارش در رابط سفارشات پذیرفته شده نمایش داده می شود.

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

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

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

سپس آدرس و نام مشتری را وارد کنید. 

وقتی روی "ایجاد سفارش" کلیک می کنید:

• درخواست به OrderController.SaveOrder() ارسال می شود.

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

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

• پایگاه داده دارای جداول با ترتیب، ترکیب سفارش، مشتری است و همه آنها به هم متصل هستند.

• رابط نمایش سفارش می رود و آخرین سفارش ها را بیرون می آورد و آنها را نمایش می دهد.

ماژول های جدید

گرفتن سفارش مهم و ضروری بود. اگر سفارشی برای فروش نداشته باشید، نمی‌توانید تجارت پیتزا انجام دهید. بنابراین، سیستم شروع به کسب عملکرد کرد - تقریباً از سال 2012 تا 2015. در طول این مدت، بسیاری از بلوک های مختلف سیستم ظاهر شد که من آنها را فرا خواهم خواند ماژول ها، برخلاف مفهوم خدمات یا محصول. 

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

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

از نظر فنی، ماژول ها به صورت Area طراحی شدند (چنین ایده ای حتی در آن باقی ماند هسته asp.net). فایل‌های جداگانه‌ای برای frontend، مدل‌ها و همچنین کلاس‌های کنترلر خودشان وجود داشت. در نتیجه، سیستم از این ...

... در این مورد:

برخی از ماژول ها به دلیل عملکردی کاملاً مجزا و تا حدودی به دلیل توسعه کمی مجزا و متمرکزتر توسط سایت های جداگانه (پروژه اجرایی) پیاده سازی می شوند. این:

• سایت - اولین نسخه سایت dodopizza.ru.

• صادرات: آپلود گزارش از Dodo IS برای 1C. 

• شخصی - حساب شخصی کارمند این به طور جداگانه توسعه یافته است و دارای نقطه ورودی و طراحی جداگانه خود است.

• fs - پروژه ای برای میزبانی استاتیک. بعداً از آن دور شدیم و تمام استاتیک ها را به Akamai CDN منتقل کردیم. 

بقیه بلوک ها در برنامه BackOffice بودند. 

توضیح نام:

• صندوقدار - صندوقدار رستوران.

• ShiftManager - رابط های نقش "Shift Manager": آمار عملیاتی فروش پیتزا فروشی، امکان قرار دادن محصولات در لیست توقف، تغییر ترتیب.

• OfficeManager - رابط هایی برای نقش های "مدیر پیتزا فروشی" و "فرانچایز". در اینجا توابع برای راه اندازی یک پیتزا فروشی، تبلیغات پاداش آن، دریافت و کار با کارمندان، گزارش ها جمع آوری شده است.

• PublicScreens - رابط های تلویزیون و تبلت های آویزان در پیتزا فروشی. تلویزیون ها منوها، اطلاعات تبلیغاتی، وضعیت سفارش را هنگام تحویل نمایش می دهند. 

آنها از یک لایه سرویس مشترک، یک بلوک کلاس دامنه Dodo.Core و یک پایگاه مشترک استفاده کردند. گاهی اوقات آنها هنوز هم می توانند در امتداد انتقال به یکدیگر هدایت شوند. از جمله سایت های فردی، مانند dodopizza.ru یا personal.dodopizza.ru، به خدمات عمومی رفتند.

هنگامی که ماژول های جدید ظاهر شدند، سعی کردیم از کد سرویس های ایجاد شده، رویه ها و جداول ذخیره شده در پایگاه داده تا حداکثر استفاده مجدد کنیم. 

برای درک بهتر مقیاس ماژول های ساخته شده در سیستم، در اینجا نموداری از سال 2012 با برنامه های توسعه آورده شده است:

تا سال 2015، همه چیز روی نقشه بود و حتی بیشتر در حال تولید بود.

• پذیرش سفارش به یک بلوک جداگانه از مرکز تماس تبدیل شده است که در آن سفارش توسط اپراتور پذیرفته می شود.

• نمایشگرهای عمومی با منوها و اطلاعات در پیتزا فروشی ها آویزان بود.

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

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

به موازات آن، از سال 2012 تا 2015، بیش از 10 توسعه دهنده ظاهر شدند، 35 پیتزا فروشی باز شدند، سیستم را در رومانی مستقر کردند و برای افتتاح شعبه در ایالات متحده آماده شدند. توسعه دهندگان دیگر با تمام وظایف سروکار نداشتند، بلکه به تیم هایی تقسیم شدند. هر کدام در بخش خاص خود از سیستم متخصص هستند. 

مشکلات

از جمله به دلیل معماری (اما نه تنها).

هرج و مرج در پایه

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

اما طی 4 سال توسعه، پایگاه داده حدود 600 جدول، 1500 رویه ذخیره شده داشت که بسیاری از آنها منطقی نیز داشتند. افسوس که رویه های ذخیره شده در هنگام کار با MySQL مزیت چندانی ندارند. آنها توسط پایه ذخیره نمی شوند و ذخیره منطق در آنها توسعه و اشکال زدایی را پیچیده می کند. استفاده مجدد از کد نیز دشوار است.

بسیاری از جداول نمایه های مناسبی نداشتند، در جایی، برعکس، شاخص های زیادی وجود داشت که درج را دشوار می کرد. لازم بود حدود 20 جدول اصلاح شود - تراکنش برای ایجاد یک سفارش می تواند حدود 3-5 ثانیه طول بکشد. 

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

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

داده ها تجمیع نشدند و بسیاری از محاسبات در پرواز با استفاده از پایه انجام شد. این محاسبات غیر ضروری و بار اضافی ایجاد کرد. 

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

انسجام و مبهم در کد

ماژول هایی که قرار بود مسئولیت بخشی از کسب و کار خود را بر عهده بگیرند، صادقانه این کار را انجام ندادند. برخی از آنها عملکردهای تکراری برای نقش ها داشتند. به عنوان مثال، یک بازاریاب محلی که مسئولیت فعالیت بازاریابی شبکه در شهر خود را بر عهده دارد، باید هم از رابط "Admin" (برای ایجاد تبلیغات) و هم از رابط "Office Manager" (برای مشاهده تأثیر تبلیغات بر روی تجارت) استفاده می کرد. البته در داخل هر دو ماژول از همان سرویسی استفاده می شد که با تبلیغات جایزه کار می کرد.

سرویس ها (کلاس ها در یک پروژه بزرگ یکپارچه) می توانند با یکدیگر تماس بگیرند تا داده های خود را غنی کنند.

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

منطق یا در کنترلرها بود یا در کلاس های سرویس. 

به نظر می‌رسد اینها مسائل جزئی هستند، اما توسعه را بسیار کند کرده و کیفیت را کاهش داده و منجر به بی‌ثباتی و باگ می‌شود. 

پیچیدگی یک توسعه بزرگ

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

در برخی از قسمت های سیستم می توان از پایگاه های داده مناسب تر برای این کار استفاده کرد.. به عنوان مثال، بعداً ما مورد استفاده از انتقال از Redis به CosmosDB برای ذخیره سبد سفارش را داشتیم. 

تیم‌ها و توسعه‌دهندگان درگیر در حوزه خود به وضوح خواهان استقلال بیشتری برای خدمات خود بودند، هم از نظر توسعه و هم از نظر عرضه. تضادها را ادغام کنید، مسائل را رها کنید. اگر برای 5 توسعه دهنده این مشکل ناچیز باشد، با 10، و حتی بیشتر از آن با رشد برنامه ریزی شده، همه چیز جدی تر می شود. و در آینده قرار بود توسعه یک اپلیکیشن موبایل باشد (در سال 2017 شروع شد و در سال 2018 سقوط بزرگ). 

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

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

چگونه وبلاگ Power of the Mind صندوق های پول را در رستوران ها قرار می دهد

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

در وبلاگ "قدرت ذهنویجتی بود که داده‌های درآمد سالیانه کل شبکه را نشان می‌داد. ویجت به API عمومی Dodo که این داده ها را ارائه می دهد، دسترسی پیدا کرد. این آمار در حال حاضر در دسترس است http://dodopizzastory.com/. ویجت در هر صفحه نشان داده می‌شد و هر 20 ثانیه یک بار درخواست‌ها را روی یک تایمر ارائه می‌کرد. این درخواست به api.dodopizza.ru رفت و درخواست کرد:

• تعداد پیتزا فروشی ها در شبکه؛

• کل درآمد شبکه از ابتدای سال؛

• درآمد برای امروز

درخواست برای آمار درآمد مستقیماً به پایگاه داده رفت و شروع به درخواست داده در مورد سفارشات، جمع آوری داده ها در پرواز و ارائه مبلغ کرد. 

میزهای نقدی رستوران ها به همان جدول سفارشات رفتند، لیستی از سفارش های دریافتی امروز را خالی کردند و سفارش های جدید به آن اضافه شد. صندوق‌ها درخواست‌های خود را هر 5 ثانیه یا در رفرش صفحه ارسال می‌کردند.

نمودار به این صورت بود:

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

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

این تنها داستان نیست. تا پاییز 2015، هر جمعه بار سیستم بحرانی بود. چندین بار API عمومی را خاموش کردیم و حتی یک بار مجبور شدیم سایت را خاموش کنیم، زیرا هیچ کمکی نکرد. حتی لیستی از خدمات با دستور خاموشی تحت بارهای سنگین وجود داشت.

از این پس مبارزه ما با بارها و برای تثبیت سیستم آغاز می شود (از پاییز 2015 تا پاییز 2018). آن وقت بود که این اتفاق افتاد"پاییز عالی". علاوه بر این، گاهی اوقات شکست هایی نیز رخ می دهد، برخی از آنها بسیار حساس بودند، اما دوره عمومی بی ثباتی را می توان اکنون گذرانده در نظر گرفت.

رشد سریع کسب و کار

چرا نمی توان آن را فورا انجام داد؟ فقط به نمودارهای زیر نگاه کنید.

همچنین در سال 2014-2015 یک افتتاحیه در رومانی و افتتاحیه در ایالات متحده آمریکا در حال آماده سازی بود.

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

یکی دیگر از موانع بازنگری به موقع معماری و به طور کلی توجه به مشکلات فنی، بحران سال 2014 بود. مواردی از این دست به شدت به فرصت‌های تیم‌ها برای رشد، به‌ویژه برای کسب‌وکار جوانی مانند پیتزا دودو ضربه می‌زند.

راه حل های سریع که کمک کرد

مشکلات نیاز به راه حل دارند. به طور معمول، راه حل ها را می توان به 2 گروه تقسیم کرد:

• سریع هایی که آتش را خاموش می کنند و حاشیه کمی از امنیت می دهند و برایمان زمان می خرند تا تغییر کنیم.

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

لیست خشک تغییرات سریع به شرح زیر است:

استاد پایه را افزایش دهید

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

از سال 2014، ما به Azure نقل مکان کردیم، همچنین در آن زمان در مورد این موضوع در مقاله نوشتیم.چگونه Dodo Pizza پیتزا را با استفاده از ابر مایکروسافت Azure تحویل می دهد". اما پس از یک سری افزایش در سرور برای پایه، آنها با هزینه روبرو شدند. 

ماکت های پایه برای خواندن

دو ماکت برای پایه ساخته شد:

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

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

حافظه پنهان در کد

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

چندین سرور باطن

باطن برنامه نیز برای مدیریت بارهای کاری افزایش یافته نیاز به مقیاس بندی داشت. لازم بود از یک iis-server یک خوشه بسازیم. ما دوباره برنامه ریزی کردیم جلسه برنامه از حافظه گرفته تا RedisCache، که امکان ساخت چندین سرور را در پشت یک متعادل کننده بار ساده با دور رابین فراهم می کرد. در ابتدا از همان Redis برای کش استفاده شد، سپس به چند قسمت تقسیم شد. 

در نتیجه، معماری پیچیده تر شده است ...

... اما مقداری از تنش برداشته شد.

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

منبع: www.habr.com