مرحباً، هبر! أنا أرتيم كاراميشيف، رئيس فريق إدارة النظام . لقد شهدنا إطلاق العديد من المنتجات الجديدة خلال العام الماضي. أردنا التأكد من أن خدمات واجهة برمجة التطبيقات (API) قابلة للتطوير بسهولة، ومقاومة للأخطاء، وجاهزة للنمو السريع في تحميل المستخدم. تم تنفيذ منصتنا على OpenStack، وأريد أن أخبرك عن مشكلات تحمل أخطاء المكونات التي كان علينا إغلاقها للحصول على نظام متسامح مع الأخطاء. أعتقد أن هذا سيكون مثيرًا للاهتمام لأولئك الذين يقومون أيضًا بتطوير المنتجات على OpenStack.
يتم تحديد التسامح العام مع الأخطاء في المنصة من خلال استقرار مكوناتها. وسنعمل تدريجيا على مراجعة جميع المستويات التي حددنا فيها المخاطر وأغلقناها.
نسخة فيديو من هذه القصة، المصدر الأصلي لها كان عرضًا تقديميًا في مؤتمر Uptime day 4، الذي نظمته ، يمكنك إلقاء نظرة .
التسامح مع أخطاء الهندسة المعمارية المادية
يتمركز الجزء العام من سحابة MCS حاليًا في مركزين للبيانات من المستوى الثالث، يوجد بينهما ألياف داكنة خاصة، محجوزة على المستوى المادي من خلال طرق مختلفة، مع معدل إنتاج يبلغ 200 جيجابت في الثانية. يوفر المستوى الثالث المستوى المطلوب من التسامح مع الأخطاء للبنية التحتية المادية.
يتم حجز الألياف الداكنة على المستويين المادي والمنطقي. كانت عملية حجز القناة تكرارية، وظهرت مشاكل، ونحن نعمل باستمرار على تحسين الاتصال بين مراكز البيانات.
على سبيل المثال، قبل فترة ليست طويلة، أثناء العمل في بئر بالقرب من أحد مراكز البيانات، قامت حفارة بثقب أحد الأنابيب، وتم العثور على الكابلات الضوئية الرئيسية والاحتياطية داخل هذا الأنبوب. لقد تبين أن قناة الاتصال الآمنة لدينا مع مركز البيانات معرضة للخطر في نقطة ما، في البئر. وبالتالي فقدنا جزءًا من البنية التحتية. وقد توصلنا إلى استنتاجات واتخذنا عدداً من الإجراءات، بما في ذلك تركيب بصريات إضافية على طول البئر المجاورة.
توجد في مراكز البيانات نقاط حضور لمزودي الاتصالات، الذين نبث إليهم بادئاتنا عبر BGP. بالنسبة لكل اتجاه شبكة، يتم اختيار أفضل مقياس، مما يسمح لنا بتوفير أفضل جودة اتصال لعملاء مختلفين. إذا تم قطع الاتصال من خلال أحد المزودين، فإننا نقوم بإعادة بناء التوجيه الخاص بنا من خلال المزودين المتاحين.
في حالة فشل المزود، نقوم بالتبديل تلقائيًا إلى المزود التالي. في حالة تعطل أحد مراكز البيانات، يكون لدينا نسخة طبق الأصل من خدماتنا في مركز البيانات الثاني، والذي يتحمل الحمل بأكمله.
مرونة البنية التحتية المادية
ما نستخدمه للتسامح مع الأخطاء على مستوى التطبيق
تعتمد خدمتنا على عدد من المكونات مفتوحة المصدر.
إكساBGP - خدمة تنفذ عددًا من الوظائف باستخدام بروتوكول التوجيه الديناميكي المستند إلى BGP. نحن نستخدمها على نطاق واسع للإعلان عن عناوين IP البيضاء التي يستخدمها المستخدمون للوصول إلى واجهة برمجة التطبيقات (API).
HAProxy — موازن التحميل العالي الذي يسمح لك بتكوين قواعد موازنة حركة مرور مرنة للغاية في مستويات مختلفة من نموذج OSI. نحن نستخدمه لتحقيق التوازن في التحميل أمام جميع الخدمات: قواعد البيانات، وسطاء الرسائل، خدمات API، خدمات الويب، مشاريعنا الداخلية - كل شيء خلف HAProxy.
تطبيق API - تطبيق ويب مكتوب بلغة بايثون، وبمساعدته يتمكن المستخدم من إدارة البنية التحتية الخاصة به وخدماته.
طلب عامل (يشار إليه فيما بعد باسم العامل ببساطة) - في خدمات OpenStack، يعد هذا شيطانًا للبنية الأساسية يسمح بنقل أوامر API إلى البنية الأساسية. على سبيل المثال، يحدث إنشاء القرص في العامل، ويحدث طلب الإنشاء في تطبيق API.
هندسة تطبيقات OpenStack القياسية
تحاول معظم الخدمات التي تم تطويرها لـ OpenStack اتباع نموذج واحد. تتكون الخدمة عادةً من جزأين: واجهة برمجة التطبيقات والعاملين (أداء الواجهة الخلفية). بشكل عام، واجهة برمجة التطبيقات (API) هي تطبيق WSGI في Python، والذي يتم تشغيله إما كعملية مستقلة (daemon) أو باستخدام خادم ويب جاهز Nginx أو Apache. تعمل واجهة برمجة التطبيقات (API) على معالجة طلب المستخدم وتمرير المزيد من التعليمات إلى تطبيق العامل لتنفيذها. يتم إجراء النقل باستخدام وسيط الرسائل، عادةً RabbitMQ، ويتم دعم الآخرين بشكل سيئ. عندما تصل الرسائل إلى الوسيط، يتم معالجتها بواسطة العمال، وإذا لزم الأمر، يتم إرجاع الرد.
يتضمن هذا النموذج نقاط فشل مشتركة معزولة: RabbitMQ وقاعدة البيانات. ولكن RabbitMQ معزول داخل خدمة واحدة، ومن الناحية النظرية، يمكن أن يكون فرديًا لكل خدمة. لذلك، في MCS نقوم بفصل هذه الخدمات قدر الإمكان، لكل مشروع فردي نقوم بإنشاء قاعدة بيانات منفصلة، RabbitMQ منفصل. إن هذا النهج جيد لأنه في حالة وقوع حادث في بعض النقاط الضعيفة، فإن الخدمة لا تتعطل بالكامل، بل جزء منها فقط.
لا يوجد حد لعدد تطبيقات العمال، وبالتالي يمكن بسهولة توسيع نطاق واجهة برمجة التطبيقات أفقيًا خلف الموازنات لزيادة الأداء والتسامح مع الأخطاء.
تتطلب بعض الخدمات التنسيق داخل الخدمة - عندما تحدث عمليات متسلسلة معقدة بين واجهات برمجة التطبيقات والعاملين. في هذه الحالة، يتم استخدام مركز تنسيق واحد، وهو نظام مجموعة مثل Redis، أو Memcache، أو etcd، والذي يسمح لعامل واحد بإخبار عامل آخر بأن هذه المهمة مخصصة له ("من فضلك لا تأخذها"). نحن نستخدم etcd. كقاعدة عامة، يتواصل العمال بشكل نشط مع قاعدة البيانات، ويكتبون ويقرؤون المعلومات منها. كقاعدة بيانات نستخدم mariadb، والتي تقع في مجموعة متعددة الأسياد لدينا.
يتم تنظيم هذه الخدمة الفردية الكلاسيكية بالطريقة المقبولة عمومًا في OpenStack. يمكن اعتباره نظامًا مغلقًا حيث تكون طرق القياس والتسامح مع الأخطاء واضحة إلى حد ما. على سبيل المثال، لضمان تحمل أخطاء API، يكفي تثبيت موازن أمامها. يتم تحقيق التوسع في أعداد العمال من خلال زيادة عددهم.
نقطة الضعف في المخطط بأكمله هي RabbitMQ و MariaDB. وتستحق هندستهم المعمارية مقالاً منفصلاً. في هذه المقالة أريد التركيز على التسامح مع أخطاء واجهة برمجة التطبيقات (API).
هندسة تطبيقات Openstack. موازنة منصة السحابة والتسامح مع الأخطاء
جعل موازن تحميل HAProxy متسامحًا مع الأخطاء باستخدام ExaBGP
لجعل واجهات برمجة التطبيقات الخاصة بنا قابلة للتطوير وسريعة ومقاومة للأخطاء، قمنا بوضع موازن تحميل أمامها. لقد اخترنا HAProxy. في رأيي، لديه كل الخصائص اللازمة لمهمتنا: تحقيق التوازن على مستويات OSI متعددة، وواجهة الإدارة، والمرونة وقابلية التوسع، وعدد كبير من طرق تحقيق التوازن، ودعم جداول الجلسة.
كانت المشكلة الأولى التي تحتاج إلى حل هي قدرة الموازن على تحمل الأخطاء نفسها. يؤدي تثبيت الموازن أيضًا إلى إنشاء نقطة فشل: ينهار الموازن - تتوقف الخدمة. ولمنع حدوث ذلك، استخدمنا HAProxy بالاشتراك مع ExaBGP.
يسمح ExaBGP بتنفيذ آلية للتحقق من حالة الخدمة. لقد استخدمنا هذه الآلية للتحقق مما إذا كان HAProxy يعمل ولتعطيل خدمة HAProxy من BGP في حالة حدوث مشكلات.
مخطط ExaBGP+HAProxy
- نقوم بتثبيت البرامج اللازمة، ExaBGP و HAProxy، على ثلاثة خوادم.
- نقوم بإنشاء واجهة حلقة استرجاعية على كل خادم.
- على جميع الخوادم الثلاثة، نقوم بتسجيل نفس عنوان IP الأبيض على هذه الواجهة.
- يتم الإعلان عن عنوان IP الأبيض للإنترنت عبر ExaBGP.
يتم تحقيق التسامح مع الأخطاء من خلال الإعلان عن نفس عنوان IP من جميع الخوادم الثلاثة. من منظور الشبكة، يمكن الوصول إلى نفس العنوان من ثلاث قفزات تالية مختلفة. يرى جهاز التوجيه ثلاثة مسارات متطابقة، ويختار المسار ذو الأولوية الأعلى استنادًا إلى مقياسه الخاص (عادةً ما يكون هذا هو الخيار نفسه)، وتذهب حركة المرور إلى أحد الخوادم فقط.
في حالة حدوث مشكلات في تشغيل HAProxy أو فشل الخادم، يتوقف ExaBGP عن الإعلان عن المسار ويتحول المرور بسلاسة إلى خادم آخر.
بهذه الطريقة، حققنا التسامح مع الخطأ في الموازن.
تحمل أخطاء موازن تحميل HAProxy
لقد تبين أن المخطط غير مثالي: لقد تعلمنا كيفية حجز HAProxy، لكننا لم نتعلم كيفية توزيع الحمل داخل الخدمات. ولذلك، قمنا بتوسيع هذا المخطط قليلاً: انتقلنا إلى تحقيق التوازن بين العديد من عناوين IP البيضاء.
موازنة تعتمد على DNS بالإضافة إلى BGP
تظل مشكلة موازنة التحميل أمام HAProxy دون حل. ومع ذلك، فمن الممكن حلها بكل بساطة، كما فعلنا في حالتنا.
لتحقيق التوازن بين ثلاثة خوادم، ستحتاج إلى ثلاثة عناوين IP بيضاء ونظام DNS القديم الجيد. يتم تعريف كل من هذه العناوين على واجهة الحلقة الراجعة لكل HAProxy ويتم الإعلان عنها على الإنترنت.
يستخدم OpenStack كتالوج الخدمة لإدارة الموارد، والذي يحدد نقطة نهاية واجهة برمجة التطبيقات لخدمة معينة. في هذا الدليل، قمنا بتسجيل اسم المجال - public.infra.mail.ru، والذي يتم حله عبر DNS بواسطة ثلاثة عناوين IP مختلفة. ونتيجة لذلك، نحصل على توزيع الحمل بين ثلاثة عناوين عبر DNS.
ولكن نظرًا لأننا لا نتحكم في أولويات اختيار الخادم عند الإعلان عن عناوين IP البيضاء، فهذا الأمر غير متوازن بعد. عادةً، سيتم اختيار خادم واحد فقط استنادًا إلى أقدمية عنوان IP، وسيظل الخادمان الآخران خاملين نظرًا لعدم تحديد أي مقاييس في BGP.
لقد بدأنا في تقديم الطرق عبر ExaBGP باستخدام مقاييس مختلفة. يعلن كل موازن عن جميع عناوين IP البيضاء الثلاثة، ولكن يتم الإعلان عن واحد منها، وهو العنوان الرئيسي لهذا الموازن، باستخدام الحد الأدنى من المقياس. لذلك، بينما تكون جميع الموازنات الثلاثة جاهزة للتشغيل، تنتقل الطلبات إلى عنوان IP الأول إلى الموازن الأول، والطلبات إلى الموازن الثاني إلى الموازن الثاني، والطلبات إلى الموازن الثالث إلى الموازن الثالث.
ماذا يحدث عندما ينخفض أحد الموازنات؟ إذا فشل أي موازن، فسيتم الإعلان عن عنوانه الرئيسي من الاثنين الآخرين، ويتم إعادة توزيع حركة المرور بينهما. وبالتالي، فإننا نعطي المستخدم عدة عناوين IP في وقت واحد عبر DNS. من خلال تحقيق التوازن من خلال DNS ومقاييس مختلفة، نحقق توزيعًا متساويًا للحمل على جميع الموازنات الثلاثة. وفي نفس الوقت لا نفقد القدرة على التسامح مع الأخطاء.
موازنة تحميل HAProxy استنادًا إلى DNS + BGP
التفاعل بين ExaBGP وHAProxy
لذلك، قمنا بتنفيذ التسامح مع الأخطاء في حالة فشل الخادم، بناءً على إنهاء إعلانات المسار. ولكن يمكن أيضًا إيقاف تشغيل HAProxy لأسباب أخرى غير فشل الخادم: أخطاء الإدارة، والأعطال داخل الخدمة. نريد إزالة الموازن المكسور من تحت الحمل في هذه الحالات أيضًا، ونحن بحاجة إلى آلية مختلفة.
لذلك، من خلال توسيع المخطط السابق، قمنا بتنفيذ نبض القلب بين ExaBGP وHAProxy. هذا هو تنفيذ برمجي للتفاعل بين ExaBGP وHAProxy، حيث يستخدم ExaBGP نصوصًا مخصصة للتحقق من حالة التطبيقات.
للقيام بذلك، تحتاج إلى تكوين أداة فحص الصحة في تكوين ExaBGP، والتي ستكون قادرة على التحقق من حالة HAProxy. في حالتنا، قمنا بتكوين الواجهة الخلفية الصحية في HAProxy، ومن جانب ExaBGP نقوم بالتحقق من خلال طلب GET بسيط. إذا توقف الإعلان عن الحدوث، فمن المرجح أن HAProxy لا يعمل وليس هناك حاجة للإعلان عنه.
فحص صحة HAProxy
نظراء HAProxy: مزامنة الجلسة
الشيء التالي الذي كان يجب القيام به هو مزامنة الجلسات. عند العمل من خلال الموازنات الموزعة، يكون من الصعب تنظيم تخزين المعلومات حول جلسات العميل. ولكن HAProxy هو أحد الموازنات القليلة التي يمكنها القيام بذلك بفضل وظيفة Peers - القدرة على نقل جدول جلسة بين عمليات HAProxy المختلفة.
هناك طرق مختلفة للموازنة: طرق بسيطة، مثل ، والممتدة، عندما يتم تذكر جلسة العميل، وفي كل مرة يصل إلى نفس الخادم كما في السابق. أردنا تنفيذ الخيار الثاني.
يستخدم HAProxy جداول لاصقة لتخزين جلسات العميل لهذه الآلية. إنها تقوم بتخزين عنوان IP الأصلي للعميل، وعنوان الهدف المحدد (الخلفية)، وبعض معلومات الخدمة. تُستخدم جداول Stick عادةً لتخزين أزواج IP المصدر + IP الوجهة، وهو أمر مفيد بشكل خاص للتطبيقات التي لا يمكنها تمرير سياق جلسة المستخدم عند التبديل إلى موازن تحميل آخر، مثل وضع موازنة التحميل RoundRobin.
إذا قمنا بتعليم جدول العصا للتنقل بين عمليات HAProxy المختلفة (التي يحدث بينها التوازن)، فسوف تكون موازناتنا قادرة على العمل مع مجموعة واحدة من جداول العصا. سيؤدي هذا إلى تمكين التبديل السلس لشبكة العميل عند فشل أحد الموازنات؛ سيستمر العمل مع جلسات العميل على نفس الواجهات الخلفية التي تم تحديدها سابقًا.
لضمان التشغيل السليم، يجب حل عنوان IP المصدر للموازن الذي تم إنشاء الجلسة منه. في حالتنا، هذا هو عنوان ديناميكي على واجهة الحلقة الراجعة.
يتم تحقيق التشغيل الصحيح للأقران فقط في ظل ظروف معينة. وهذا يعني أن مهلة انتظار TCP يجب أن تكون كبيرة بما يكفي أو أن يكون التبديل سريعًا بما يكفي حتى لا يكون لدى جلسة TCP الوقت للتوقف. ومع ذلك، فإن هذا يسمح بالتبديل السلس.
لدينا خدمة IaaS تم إنشاؤها باستخدام نفس التكنولوجيا. هذا ، والتي تسمى أوكتافيا. يعتمد على عمليتين HAProxy ويتمتع بدعم أقران أصلي. لقد أثبتوا تفوقهم في هذه الخدمة.
تُظهر الصورة تخطيطيًا حركة جداول الأقران بين ثلاث مثيلات HAProxy، ويتم تقديم تكوين حول كيفية إعداد ذلك:
نظراء HAProxy (مزامنة الجلسة)
إذا قمت بتنفيذ نفس المخطط، فيجب اختبار تشغيله بعناية. ليس من المؤكد أن الأمر سيعمل بنفس الشكل في 100% من الحالات. ولكن على الأقل لن تفقد جداول العصا عندما تحتاج إلى تذكر عنوان IP المصدر للعميل.
الحد من عدد الطلبات المتزامنة من نفس العميل
يمكن لأي خدمة متاحة للجمهور، بما في ذلك واجهات برمجة التطبيقات الخاصة بنا، أن تكون عرضة لتدفقات من الطلبات. يمكن أن تكون أسباب ذلك مختلفة تمامًا، بدءًا من أخطاء المستخدم وحتى الهجمات المستهدفة. نحن نتعرض بشكل دوري لهجمات DDoS بواسطة عناوين IP. غالبًا ما يرتكب العملاء أخطاء في نصوصهم ويتسببون في حدوث هجمات DDoS صغيرة علينا.
بطريقة أو بأخرى، من الضروري توفير الحماية الإضافية. الحل الواضح هو الحد من عدد الطلبات الموجهة إلى واجهة برمجة التطبيقات وعدم إضاعة وقت المعالج في معالجة الطلبات الضارة.
لتنفيذ مثل هذه القيود، نستخدم حدود المعدلات، المنظمة على أساس HAProxy، باستخدام نفس الجداول الثابتة. يتم إعداد الحدود بكل بساطة وتسمح لك بتقييد المستخدم حسب عدد الطلبات المقدمة إلى واجهة برمجة التطبيقات. تتذكر الخوارزمية عنوان IP المصدر الذي يتم من خلاله تقديم الطلبات وتحد من عدد الطلبات المتزامنة من مستخدم واحد. بالطبع، قمنا بحساب متوسط ملف تعريف تحميل واجهة برمجة التطبيقات لكل خدمة وحددنا الحد الأقصى إلى 10 أضعاف تلك القيمة. نحن نواصل مراقبة الوضع عن كثب ونبقي إصبعنا على النبض.
كيف يبدو هذا في الممارسة العملية؟ لدينا عملاء يستخدمون واجهات برمجة التطبيقات الخاصة بنا للتوسع التلقائي طوال الوقت. إنهم يقومون بإنشاء ما يقرب من مائتين إلى ثلاثمائة جهاز افتراضي مع اقتراب الصباح، ثم يقومون بحذفها مع اقتراب المساء. بالنسبة لـ OpenStack، يتطلب إنشاء جهاز افتراضي، مع خدمات PaaS أيضًا، 1000 طلب API على الأقل، نظرًا لأن التفاعل بين الخدمات يحدث أيضًا من خلال API.
يؤدي هذا التحول في المهام إلى قدر كبير من التوتر. لقد قمنا بتقييم هذا الحمل، وجمع الذروات اليومية، وزيادتها عشرة أضعاف، وأصبح هذا هو الحد الأقصى للمعدل لدينا. نحن نضع إصبعنا على النبض. غالبًا ما نرى برامج روبوتية وأجهزة مسح ضوئي تحاول معرفة ما إذا كان لدينا أي نصوص CGA يمكن تشغيلها، ونقوم بقطعها بنشاط.
كيفية تحديث قاعدة التعليمات البرمجية الخاصة بك دون أن يلاحظ المستخدمون ذلك
كما نقوم أيضًا بتنفيذ التسامح مع الأخطاء على مستوى عمليات نشر التعليمات البرمجية. تحدث بعض حالات الفشل أثناء عمليات الطرح، ولكن يمكن تقليل تأثيرها على توفر الخدمة.
نحن نقوم بتحديث خدماتنا باستمرار ويجب علينا التأكد من أن عملية تحديث قاعدة التعليمات البرمجية لا تؤثر على المستخدمين. لقد تمكنا من حل هذه المشكلة باستخدام إمكانيات إدارة HAProxy وتنفيذ Graceful Shutdown في خدماتنا.
لحل هذه المشكلة، كان من الضروري ضمان إدارة الموازن وإيقاف الخدمات "بشكل صحيح":
- في حالة HAProxy، يتم إجراء التحكم من خلال ملف الإحصائيات، وهو عبارة عن مقبس في الأساس ويتم تعريفه في تكوين HAProxy. يمكنك تمرير الأوامر إليه عبر stdio. لكن أداة التحكم في التكوين الرئيسية لدينا هي ansible، لذا فهي تحتوي على وحدة مدمجة لإدارة HAProxy. والتي نستخدمها بشكل نشط.
- تدعم معظم خدمات API وEngine الخاصة بنا تقنيات إيقاف التشغيل السلس: عند إيقاف التشغيل، فإنها تنتظر حتى اكتمال المهمة الحالية، سواء كانت طلب http أو بعض مهام الخدمة، بشكل كامل. ويحدث الشيء نفسه مع العامل. إنه يعرف جميع المهام التي يقوم بها وينتهي عندما يكمل كل شيء بنجاح.
بفضل هاتين النقطتين، تبدو خوارزمية النشر الآمن لدينا على النحو التالي.
- يقوم المطور ببناء حزمة كود جديدة (في حالتنا هي RPM)، ويختبرها في بيئة التطوير، ويختبرها في المرحلة، ويتركها في مستودع المرحلة.
- يقوم المطور بتعيين مهمة للنشر مع الوصف الأكثر تفصيلاً لـ "القطع الأثرية": إصدار الحزمة الجديدة، ووصف الوظيفة الجديدة، وتفاصيل أخرى حول النشر إذا لزم الأمر.
- يبدأ مسؤول النظام عملية التحديث. يقوم بتشغيل دليل Ansible، والذي يقوم بدوره بما يلي:
- يأخذ حزمة من مستودع المرحلة ويقوم بتحديث إصدار الحزمة في مستودع المنتج بناءً عليها.
- يقوم بتجميع قائمة بالبرامج الخلفية للخدمة التي يتم تحديثها.
- يقوم بإيقاف تشغيل الخدمة الأولى التي سيتم تحديثها في HAProxy وينتظر حتى تنتهي عملياتها من التشغيل. بفضل الإغلاق السلس، نحن على ثقة من أن جميع طلبات العملاء الحالية سيتم إكمالها بنجاح.
- بعد التوقف الكامل لواجهة برمجة التطبيقات والعاملين وإغلاق HAProxy، يتم تحديث الكود.
- يبدأ Ansible الخدمات.
- بالنسبة لكل خدمة، يتم سحب "مقابض" معينة تقوم بإجراء اختبار الوحدة لعدد من اختبارات المفاتيح المحددة مسبقًا. يتم إجراء فحص أساسي للكود الجديد.
- إذا لم يتم العثور على أي أخطاء في الخطوة السابقة، فسيتم تنشيط الواجهة الخلفية.
- دعنا ننتقل إلى الواجهة الخلفية التالية.
- بعد تحديث كافة الواجهات الخلفية، يتم تشغيل الاختبارات الوظيفية. إذا كانت مفقودة، ينظر المطور إلى أي وظيفة جديدة قام بها.
وهذا يكمل عملية النشر.
دورة تحديث الخدمة
لن ينجح هذا المخطط إذا لم يكن لدينا قاعدة واحدة. نحن ندعم الإصدارين القديم والجديد في القتال. من المفترض مسبقًا، في مرحلة تطوير البرنامج، أنه حتى لو كانت هناك تغييرات في قاعدة بيانات الخدمة، فإنها لن تؤدي إلى كسر الكود السابق. ونتيجة لذلك، يتم تحديث قاعدة التعليمات البرمجية تدريجيا.
اختتام
من خلال مشاركة أفكاري الخاصة حول بنية الويب المقاومة للأخطاء، أود أن أسلط الضوء مرة أخرى على نقاطها الرئيسية:
- التسامح مع الخطأ المادي؛
- تحمل أخطاء الشبكة (الموازنات، BGP)؛
- التسامح مع الأخطاء في البرامج المستخدمة والمطورة.
أتمنى للجميع وقت تشغيل مستقر!
المصدر: www.habr.com
