تاريخ عمارة دودو IS: متراصة مبكرة

أو أن كل شركة غير سعيدة مع متراصة غير سعيدة بطريقتها الخاصة.

بدأ تطوير نظام Dodo IS على الفور ، مثل شركة Dodo Pizza ، في عام 2011. كان يقوم على فكرة الرقمنة الكاملة والشاملة للعمليات التجارية ، و بمفردي، والتي تسببت حتى في عام 2011 في الكثير من التساؤلات والشكوك. لكن لمدة 9 سنوات حتى الآن كنا نتبع هذا المسار - من خلال تنميتنا الخاص ، الذي بدأ من قطعة واحدة.

هذه المقالة هي "إجابة" على الأسئلة "لماذا إعادة كتابة الهيكل وإجراء مثل هذه التغييرات واسعة النطاق وطويلة الأجل؟" العودة إلى المقال السابق "تاريخ عمارة دودو IS: طريق المكتب الخلفي". سأبدأ بالكيفية التي بدأ بها تطوير Dodo IS ، وكيف بدت الهندسة المعمارية الأصلية ، وكيف ظهرت الوحدات الجديدة ، وبسبب المشاكل التي يجب إجراء تغييرات واسعة النطاق.

سلسلة مقالات "ما هو طائر الدودو؟" تحدث عن:

1. متراصة مبكرة في Dodo IS (2011-2015). (أنت هنا)

2. مسار المكتب الخلفي: قواعد وحافلات منفصلة.

3. المسار الجانبي للعميل: الواجهة فوق القاعدة (2016-2017). (في تَقَدم...)

4. تاريخ الخدمات المصغرة الحقيقية. (2018-2019). (في تَقَدم...)

5. الانتهاء من نشر متراصة واستقرار العمارة. (في تَقَدم...)

العمارة الأولية

في عام 2011 ، بدت هندسة Dodo IS كما يلي:

الوحدة الأولى في الهندسة هي قبول الطلب. كانت عملية العمل:

• العميل يتصل بمطعم البيتزا ؛

• المدير يلتقط الهاتف ؛

• يقبل طلبًا عبر الهاتف ؛

• يملأه بالتوازي في واجهة قبول الطلب: يأخذ في الاعتبار معلومات حول العميل ، وبيانات حول تفاصيل الطلب ، وعنوان التسليم. 

بدت واجهة نظام المعلومات مثل هذا ...

الإصدار الأول من أكتوبر 2011:

تحسن طفيفًا في يناير 2012

دودو بيتزا نظام معلومات التوصيل مطعم بيتزا

كانت الموارد لتطوير وحدة أخذ الدرجة الأولى محدودة. كان علينا أن نفعل الكثير بسرعة وبفريق صغير. الفريق الصغير عبارة عن مطورين اثنين وضعوا الأساس للنظام المستقبلي بأكمله.

حدد قرارهم الأول مصير مجموعة التكنولوجيا:

• الواجهة الخلفية على لغة ASP.NET MVC و C #. كان المطورون dotnetchiki ، كانت هذه المجموعة مألوفة وممتعة لهم.

• الواجهة الأمامية في Bootstrap و JQuery: واجهات مستخدم على أنماط ونصوص مكتوبة ذاتيًا. 

• قاعدة بيانات MySQL: لا توجد تكاليف ترخيص ، سهلة الاستخدام.

• الخوادم على Windows Server ، لأن .NET عندها يمكن أن تكون فقط تحت Windows (لن نناقش Mono).

جسديًا ، تم التعبير عن كل هذا في "dedic at the hoster". 

طلب هندسة تطبيق المدخول

ثم كان الجميع يتحدثون بالفعل عن الخدمات المصغرة ، وتم استخدام SOA في المشاريع الكبيرة لمدة 5 سنوات ، على سبيل المثال ، تم إصدار WCF في عام 2006. لكنهم اختاروا بعد ذلك حلاً موثوقًا ومثبتًا.

ها هو.

Asp.Net MVC هو Razor ، والذي يقوم ، بناءً على طلب من نموذج أو من عميل ، بعرض صفحة HTML مع عرض الخادم. على العميل ، تعرض البرامج النصية لـ CSS و JS بالفعل المعلومات ، وإذا لزم الأمر ، قم بتنفيذ طلبات AJAX من خلال JQuery.

تنتهي الطلبات على الخادم في فئات * Controller ، حيث تتم معالجة وإنشاء صفحة HTML النهائية في الطريقة. تقدم أجهزة التحكم طلبات إلى طبقة من المنطق تسمى * الخدمات. تتوافق كل خدمة مع بعض جوانب العمل:

• على سبيل المثال ، قدمت DepartmentStructureService معلومات عن مطاعم البيتزا ، في الأقسام. القسم عبارة عن مجموعة من مطاعم البيتزا يديرها صاحب امتياز واحد.

• ReceivingOrdersService قبلت وحساب تكوين الأمر.

• وأرسلت SmsService رسائل SMS عن طريق الاتصال بخدمات API لإرسال الرسائل القصيرة.

خدمات معالجة البيانات من قاعدة البيانات ، ومنطق الأعمال المخزنة. كان لكل خدمة مستودعات واحدة أو أكثر * بالاسم المناسب. لقد احتوتوا بالفعل على استعلامات للإجراءات المخزنة في قاعدة البيانات وطبقة من مصممي الخرائط. كان هناك منطق عمل في المخازن ، وخاصة الكثير في تلك التي أصدرت بيانات التقارير. لم يتم استخدام ORM ، اعتمد الجميع على SQL المكتوبة بخط اليد. 

كانت هناك أيضًا طبقة من نموذج المجال وفئات المساعدة المشتركة ، على سبيل المثال ، فئة Order التي تخزن الأمر. في نفس المكان ، في الطبقة ، كان هناك مساعد لتحويل نص العرض وفقًا للعملة المحددة.

كل هذا يمكن تمثيله بمثل هذا النموذج:

طريقة الطلب

فكر في طريقة أولية مبسطة لإنشاء مثل هذا الأمر.

في البداية ، كان الموقع ثابتًا. كان عليها أسعار ، وفوقها - رقم هاتف ونقش "إذا كنت تريد بيتزا - اتصل بالرقم واطلب". للطلب ، نحتاج إلى تنفيذ تدفق بسيط: 

• يزور العميل موقعًا ثابتًا مع الأسعار ويختار المنتجات ويتصل بالرقم المدرج في الموقع.

• يقوم العميل بتسمية المنتجات التي يريد إضافتها إلى الطلب.

• يعطي عنوانه واسمه.

• المشغل يقبل الطلب.

• يتم عرض الطلب في واجهة الطلبات المقبولة.

كل شيء يبدأ بعرض القائمة. يقبل المستخدم الذي قام بتسجيل الدخول طلبًا واحدًا فقط في كل مرة. لذلك ، يمكن تخزين عربة التسوق في جلسته (يتم تخزين جلسة المستخدم في الذاكرة). يوجد عنصر سلة يحتوي على المنتجات ومعلومات العملاء.

يقوم العميل بتسمية المنتج ، وينقر المشغل + بجانب المنتج ، ويتم إرسال طلب إلى الخادم. يتم سحب المعلومات المتعلقة بالمنتج من قاعدة البيانات وإضافة معلومات حول المنتج إلى سلة التسوق.

لاحظ. نعم هنا لا يمكنك سحب المنتج من قاعدة البيانات ولكن نقله من الواجهة الأمامية. ولكن من أجل الوضوح ، أوضحت بالضبط المسار من قاعدة البيانات. 

بعد ذلك ، أدخل عنوان واسم العميل. 

عند النقر فوق "إنشاء طلب":

• يتم إرسال الطلب إلى OrderController.SaveOrder ().

• نحصل على عربة التسوق من الجلسة ، هناك منتجات بالكمية التي نحتاجها.

• نحن نكمل سلة التسوق بمعلومات حول العميل ونمررها إلى طريقة AddOrder لفئة ReceivingOrderService ، حيث يتم حفظها في قاعدة البيانات. 

• تحتوي قاعدة البيانات على جداول بالترتيب وتكوين الأمر والعميل وكلها متصلة.

• تنتقل واجهة عرض الطلب وتسحب أحدث الطلبات وتعرضها.

وحدات جديدة

كان أخذ الأمر مهمًا وضروريًا. لا يمكنك القيام بأعمال بيتزا إذا لم يكن لديك أمر بيع. لذلك ، بدأ النظام في اكتساب الوظائف - تقريبًا من عام 2012 إلى عام 2015. خلال هذا الوقت ، ظهرت العديد من الكتل المختلفة للنظام ، والتي سأسميها الوحدات، على عكس مفهوم الخدمة أو المنتج. 

الوحدة النمطية هي مجموعة من الوظائف التي توحدها بعض الأهداف التجارية المشتركة. في نفس الوقت ، هم فعليًا في نفس التطبيق.

يمكن أن تسمى الوحدات النمطية كتل النظام. على سبيل المثال ، هذه وحدة إعداد التقارير ، واجهات المسؤول ، تعقب الطعام في المطبخ، تفويض. هذه كلها واجهات مستخدم مختلفة ، وبعضها له أنماط مرئية مختلفة. في نفس الوقت ، كل شيء يقع في إطار تطبيق واحد ، عملية واحدة قيد التشغيل. 

من الناحية الفنية ، تم تصميم الوحدات النمطية كـ Area (ظلت هذه الفكرة موجودة في asp.net الأساسية). كانت هناك ملفات منفصلة للواجهة الأمامية والنماذج بالإضافة إلى فئات وحدة التحكم الخاصة بهم. نتيجة لذلك ، تم تحويل النظام من هذا ...

...في هذا:

يتم تنفيذ بعض الوحدات من خلال مواقع منفصلة (مشروع قابل للتنفيذ) ، بسبب وظيفة منفصلة تمامًا وجزئيًا بسبب تطوير منفصل قليلاً وأكثر تركيزًا. هذا:

• موقع - الاصدار الاول موقع 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) ، حيث يمكن أن تأتي فجأة الكثير من الطلبات في أي وقت. 

لم يتم تجميع البيانات وتم إجراء العديد من الحسابات بسرعة باستخدام القاعدة. هذا خلق حسابات غير ضرورية وحمل إضافي. 

غالبًا ما كان الرمز يذهب إلى قاعدة البيانات عندما لا يمكنه فعل ذلك. في مكان ما لم تكن هناك عمليات مجمعة كافية ، سيكون من الضروري في مكان ما نشر طلب واحد في العديد من خلال الكود من أجل تسريع وزيادة الموثوقية. 

التماسك والتعتيم في الكود

الوحدات التي كان من المفترض أن تكون مسؤولة عن الجزء الخاص بها من العمل لم تفعل ذلك بأمانة. البعض منهم لديه ازدواجية في الوظائف للأدوار. على سبيل المثال ، كان على المسوق المحلي المسؤول عن النشاط التسويقي للشبكة في مدينته استخدام واجهة "المسؤول" (لإنشاء العروض الترويجية) وواجهة "مدير المكتب" (لعرض تأثير العروض الترويجية على العمل). بالطبع ، داخل كلتا الوحدتين تستخدم نفس الخدمة التي عملت مع الترقيات الإضافية.

يمكن للخدمات (الفئات ضمن مشروع كبير واحد مترابط) الاتصال ببعضها البعض لإثراء بياناتها.

مع فئات النموذج نفسها التي تخزن البيانات ، تم تنفيذ العمل في الكود بشكل مختلف. في مكان ما كان هناك منشئون يمكن من خلالها تحديد الحقول المطلوبة. في مكان ما تم ذلك من خلال الممتلكات العامة. بالطبع ، كان الحصول على البيانات وتحويلها من قاعدة البيانات متنوعًا. 

كان المنطق إما في وحدات التحكم أو في فئات الخدمة. 

يبدو أن هذه مشكلات ثانوية ، ولكنها أدت إلى إبطاء التطور بشكل كبير وانخفاض الجودة ، مما أدى إلى عدم الاستقرار والأخطاء. 

تعقيد تطور كبير

نشأت صعوبات في التطوير نفسه. كان من الضروري عمل كتل مختلفة من النظام وبالتوازي. أصبح من الصعب بشكل متزايد ملاءمة احتياجات كل مكون في رمز واحد. لم يكن من السهل الاتفاق وإرضاء جميع المكونات في نفس الوقت. يضاف إلى ذلك القيود المفروضة على التكنولوجيا ، خاصة فيما يتعلق بالقاعدة والواجهة الأمامية. كان من الضروري التخلي عن jQuery نحو أطر عالية المستوى ، خاصة فيما يتعلق بخدمات العملاء (موقع الويب).

في بعض أجزاء النظام ، يمكن استخدام قواعد بيانات أكثر ملاءمة لذلك.. على سبيل المثال ، في وقت لاحق لدينا حالة استخدام الانتقال من Redis إلى CosmosDB لتخزين سلة الطلبات. 

من الواضح أن الفرق والمطورين المشاركين في مجالهم أرادوا المزيد من الاستقلالية لخدماتهم ، من حيث التطوير والتطبيق. دمج الصراعات وإصدار القضايا. إذا كانت هذه المشكلة غير مهمة لخمسة مطورين ، فعندئذٍ مع 5 ، وحتى أكثر من ذلك مع النمو المخطط له ، سيصبح كل شيء أكثر خطورة. كان من المقرر تطوير تطبيق للهاتف المحمول (بدأ في عام 10 ، وفي عام 2017 كان كذلك سقوط كبير). 

تتطلب أجزاء مختلفة من النظام مستويات مختلفة من الاستقرار، ولكن بسبب الاتصال القوي للنظام ، لم نتمكن من توفير ذلك. ربما حدث خطأ في تطوير وظيفة جديدة في لوحة الإدارة في قبول طلب على الموقع ، لأن الرمز شائع وقابل لإعادة الاستخدام ، وقاعدة البيانات والبيانات هي نفسها أيضًا.

من المحتمل أن يكون من الممكن تجنب هذه الأخطاء والمشاكل في إطار مثل هذه البنية المعيارية المتجانسة: قم بتقسيم المسؤولية ، وإعادة تشكيل الكود وقاعدة البيانات ، وفصل الطبقات بوضوح عن بعضها البعض ، ومراقبة الجودة كل يوم. لكن الحلول المعمارية المختارة والتركيز على التوسع السريع لوظائف النظام أدت إلى مشاكل من حيث الاستقرار.

كيف تضع مدونة The Power of the Mind سجلات النقد في المطاعم

إذا استمر نمو شبكة مطاعم البيتزا (والحمل) بنفس الوتيرة ، فعندئذٍ بعد فترة من الوقت سيكون الانخفاض بحيث لا يرتفع النظام. حسنًا ، يوضح المشكلات التي بدأنا نواجهها بحلول عام 2015 ، إليكم هذه القصة. 

في المدونة "قوة العقل"أداة عرضت بيانات حول الإيرادات لسنة الشبكة بأكملها. وصلت القطعة إلى واجهة برمجة تطبيقات Dodo العامة ، والتي توفر هذه البيانات. هذه الإحصائية متاحة حاليًا في http://dodopizzastory.com/. تم عرض الأداة في كل صفحة وقدمت طلبات على عداد كل 20 ثانية. ذهب الطلب إلى api.dodopizza.ru وطلب:

• عدد مطاعم البيتزا في الشبكة ؛

• إجمالي إيرادات الشبكة منذ بداية العام ؛

• الإيرادات لهذا اليوم.

تم توجيه طلب الإحصائيات الخاصة بالإيرادات مباشرة إلى قاعدة البيانات وبدأ في طلب البيانات الخاصة بالطلبات ، وتجميع البيانات أثناء التنقل وإعطاء المبلغ. 

ذهبت المكاتب النقدية في المطاعم إلى نفس جدول الطلبات ، وأفرغت قائمة الطلبات المستلمة لهذا اليوم ، وأضيفت طلبات جديدة إليها. تقدم أجهزة تسجيل النقد طلباتها كل 5 ثوانٍ أو عند تحديث الصفحة.

بدا الرسم التخطيطي كما يلي:

في إحدى السقوط ، كتب فيودور أوفشينيكوف مقالة طويلة وشائعة على مدونته. جاء الكثير من الأشخاص إلى المدونة وبدأوا في قراءة كل شيء بعناية. بينما كان كل شخص جاء يقرأ المقال ، عملت أداة الإيرادات بشكل صحيح وطلبت واجهة برمجة التطبيقات كل 20 ثانية.

استدعت واجهة برمجة التطبيقات إجراءً مخزنًا لحساب مجموع جميع الطلبات منذ بداية العام لجميع مطاعم البيتزا في الشبكة. استند التجميع إلى جدول الطلبات ، وهو أمر شائع جدًا. جميع مكاتب الدفع النقدي لجميع المطاعم المفتوحة في ذلك الوقت تذهب إليها. توقفت المكاتب النقدية عن الاستجابة ، ولم يتم قبول الطلبات. كما لم يتم قبولهم من الموقع ، ولم يظهروا على المتعقب ، ولم يتمكن مدير الوردية من رؤيتهم في واجهته. 

هذه ليست القصة الوحيدة. بحلول خريف عام 2015 ، كان الحمل على النظام كل يوم جمعة أمرًا بالغ الأهمية. عدة مرات قمنا بإيقاف تشغيل واجهة برمجة التطبيقات العامة ، ومرة ​​واحدة ، اضطررنا إلى إيقاف تشغيل الموقع ، لأنه لم يساعد شيء. حتى أنه كانت هناك قائمة من الخدمات مع أمر إيقاف التشغيل تحت الأحمال الثقيلة.

من الآن فصاعدًا ، يبدأ صراعنا مع الأحمال واستقرار النظام (من خريف 2015 إلى خريف 2018). هذا عندما حدث "سقوط كبير". علاوة على ذلك ، حدثت حالات فشل أيضًا في بعض الأحيان ، وكان بعضها حساسًا للغاية ، ولكن يمكن اعتبار الفترة العامة لعدم الاستقرار قد مرت الآن.

نمو الأعمال السريع

لماذا لا يتم ذلك على الفور؟ مجرد إلقاء نظرة على الرسوم البيانية التالية.

أيضًا في 2014-2015 كان هناك افتتاح في رومانيا وكان يتم الإعداد للانفتاح في الولايات المتحدة الأمريكية.

نمت الشبكة بسرعة كبيرة ، وافتتحت بلدان جديدة ، وظهرت أشكال جديدة من مطاعم البيتزا ، على سبيل المثال ، تم افتتاح مطعم بيتزا في قاعة الطعام. كل هذا يتطلب اهتمامًا كبيرًا على وجه التحديد لتوسيع وظائف Dodo IS. بدون كل هذه الوظائف ، دون تتبع في المطبخ ، وحساب المنتجات والخسائر في النظام ، وعرض إصدار أمر في قاعة محكمة الطعام ، فإننا بالكاد نتحدث عن الهندسة "الصحيحة" والنهج "الصحيح" التطوير الآن.

كانت أزمة 2014 عقبة أخرى أمام مراجعة الهيكلية في الوقت المناسب والاهتمام بشكل عام بالمشاكل التقنية. أثرت أشياء مثل هذه بشدة على فرص نمو الفرق ، خاصة بالنسبة للأعمال التجارية الناشئة مثل Dodo Pizza.

حلول سريعة ساعدت

المشاكل بحاجة إلى حلول. تقليديا ، يمكن تقسيم الحلول إلى مجموعتين:

• تلك السريعة التي تطفئ النار وتعطي هامش أمان صغيرًا وتكسب لنا الوقت للتغيير.

• منهجي ، وبالتالي طويل. إعادة هندسة عدد من الوحدات النمطية ، وتقسيم بنية متجانسة إلى خدمات منفصلة (معظمها ليست على الإطلاق صغيرة ، ولكنها خدمات ماكرو ، وهناك شيء عنها تقرير أندريه موريفسكي). 

القائمة الجافة للتغييرات السريعة هي كما يلي:

توسيع نطاق الأساسي الأساسي

بالطبع ، أول شيء يتم القيام به للتعامل مع الأحمال هو زيادة سعة الخادم. تم القيام بذلك لقاعدة البيانات الرئيسية وخوادم الويب. للأسف ، هذا ممكن فقط إلى حد معين ، ثم يصبح مكلفًا للغاية.

منذ عام 2014 ، انتقلنا إلى Azure ، وكتبنا أيضًا عن هذا الموضوع في ذلك الوقت في المقالة "كيف تقدم Dodo Pizza البيتزا باستخدام Microsoft Azure Cloud". ولكن بعد سلسلة من الزيادات في الخادم الأساسي ، واجهوا التكلفة. 

النسخ المتماثلة الأساسية للقراءة

تم عمل نسختين طبق الأصل للقاعدة:

قراءة لطلبات المرجع. يتم استخدامه لقراءة الدلائل ، والنوع ، والمدينة ، والشارع ، ومطعم البيتزا ، والمنتجات (المجال الذي تم تغييره ببطء) ، وفي تلك الواجهات حيث يكون التأخير البسيط مقبولاً. كان هناك نسختان من هذه النسخ المتماثلة ، وقد حرصنا على توفرها بنفس الطريقة مثل الماجستير.

ReadReplica لطلبات التقرير. كانت قاعدة البيانات هذه أقل توفرًا ، لكن جميع التقارير ذهبت إليها. دعهم يتلقون طلبات ثقيلة لإعادة حسابات البيانات الضخمة ، لكنهم لا يؤثرون على قاعدة البيانات الرئيسية والواجهات التشغيلية. 

مخبأ في التعليمات البرمجية

لم تكن هناك مخابئ في أي مكان في الكود (على الإطلاق). أدى ذلك إلى طلبات إضافية ، ليست ضرورية دائمًا ، إلى قاعدة البيانات المحملة. كانت ذاكرات التخزين المؤقت في البداية في الذاكرة وفي خدمة ذاكرة التخزين المؤقت الخارجية ، وهي Redis. تم إبطال كل شيء بمرور الوقت ، تم تحديد الإعدادات في الكود.

خوادم خلفية متعددة

تحتاج الواجهة الخلفية للتطبيق أيضًا إلى التحجيم للتعامل مع أعباء العمل المتزايدة. كان من الضروري إنشاء كتلة من خادم iis واحد. لقد أعدنا الجدولة جلسة التطبيق من الذاكرة إلى RedisCache ، مما جعل من الممكن إنشاء عدة خوادم خلف موازن تحميل بسيط باستخدام round robin. في البداية ، تم استخدام نفس Redis مثل ذاكرات التخزين المؤقت ، ثم تم تقسيمها إلى عدة. 

نتيجة لذلك ، أصبحت الهندسة المعمارية أكثر تعقيدًا ...

... ولكن تمت إزالة بعض التوتر.

ثم كان من الضروري إعادة المكونات المحملة ، والتي تعهدنا بها. سنتحدث عن هذا في الجزء التالي.

المصدر: www.habr.com