كيف يتم ترتيب البنك الحديث؟ يوجد مكتب خلفي حيث يتم تنفيذ العمليات المختلفة ، ويتم الاحتفاظ بالحسابات والتقارير. هناك مكتب متوسط حيث يتم اتخاذ القرارات وتقييم المخاطر ، حيث يتم تقييم مخاطر الائتمان ومقاومة المحتالين. وهناك مكتب أمامي حيث يخدمون العملاء وهم مسؤولون عن تفاعلهم مع البنك من خلال قنوات مختلفة.
لدى سبيربنك المئات من الأنظمة ذات التوفر والموثوقية المتفاوتة. لديها تطويرها الخاص ، والحلول المعبأة بدرجات متفاوتة من التخصيص ، واتفاقيات مستوى الخدمة المختلفة. يتم دمج جميع الأنظمة مع بعضها البعض في عدد كبير من الطرق. في هذا المنشور ، سنخبرك بكيفية بناء تلة النمل الأمامية هذه بالكامل بطريقة توفر خدمة عملاء مستمرة.
لنبدأ بالنظرية. يمكن استعارة المبادئ الرئيسية التي يتم من خلالها بناء نظام آمن من الغواصة من غواصة:
- تنقسم الغواصة إلى مقصورات مستقلة. إذا غمرت مقصورة واحدة ، فإن الباقي لا يزال على قيد الحياة.
- جميع المكونات الهامة محفوظة. المحركات وخزانات الأكسجين. واحتفظ فريق البيتلز أيضًا بمناظير مع فتحات.
- الغواصة محمية من الظروف الحرجة على السطح - إذا لزم الأمر ، يمكن أن تذهب أعمق وتعمل هناك كما لو لم يحدث شيء.
نوضح المبدأ الأول بمثال من ممارستنا. كان لدينا نظام ذاكرة التخزين المؤقت الموزعة. وبمجرد تحميله ، فشلت إحدى عُقد بيانات ذاكرة التخزين المؤقت. لا بأس: للحفاظ على النسخ المتماثل المناسب ، قامت وحدة التحكم بإعادة توزيع البيانات إلى العقد المتبقية. ولكن نتيجة لإعادة التوزيع ، قفزت حركة مرور الشبكة وبدأت تفقد الحزم - بما في ذلك التخزين المؤقت. في مرحلة ما ، قررت وحدة التحكم أن عقدة بيانات أخرى فشلت ، وأعادت توزيع البيانات مرة أخرى ، وزادت حركة المرور ... ونتيجة لذلك ، في أقل من دقيقة توقف النظام تمامًا. لحسن الحظ ، كانت دائرة تحميل ولم يصب أحد. لكننا قضينا الكثير من الوقت في البحث عن السبب.
يمكن القول أن هذا لا يحدث مع قواعد البيانات المجمعة والخوادم المتطورة - هناك فائض مدمج على مستوى الأجهزة. على حد تعبير Werner Vogels ، CTO Amazon: "كل شيء يفشل طوال الوقت." سقطنا ومجموعات قواعد البيانات ، والخادم الراقي. سقطت بسبب أخطاء في التكوين ، بسبب مشاكل في برنامج الإدارة. مع حل كل مشكلة ، انخفضت ثقتنا في هذه الحلول. نتيجة لذلك ، توصلنا إلى استنتاج: فقط تلك الأنظمة التي تنقسم إلى أجزاء مستقلة عن بعضها البعض - مستقلة في المقام الأول في الإدارة - لا ترفض.
عمارة متعددة الكتل
كان الحل لمشاكلنا العمارة متعددة الكتل. في ذلك ، يتم تقسيم جميع مكونات الأجهزة ، بما في ذلك قواعد البيانات ، إلى كتل غير مترابطة تقريبًا ومستقلة تقريبًا. تخدم كل كتلة جزء من العملاء ، كما هو الحال عند التقسيم في قواعد البيانات. يتم حجز العقد داخل كل كتلة على جميع المستويات ، بما في ذلك التكرار الجغرافي. أي مشكلة في كتلة واحدة لا تؤثر على الآخرين. مع زيادة عدد العملاء ، يمكننا بسهولة إضافة كتل جديدة ومواصلة العمل بشكل طبيعي.
العمارة العامة. يتم حجز جميع الكتل وفقًا لمخطط 2N. يحتوي كل مركز بيانات على موازن تحميل قوي للأجهزة. ترتبط مراكز البيانات بواسطة 2-3 قنوات اتصال مستقلة.يتم توزيع الخوادم في كتل من خمسة أنواع:
- جهاز التوجيه - وحدة تحكم توزع العملاء على بقية الوحدات
- كتلة العميل - الكتلة الرئيسية التي تخدم ما يصل إلى 10 مليون عميل
- كتلة تجريبية - هنا نقوم باختبار إصدارات جديدة من التطبيقات على العملاء المخلصين (حوالي 300 ألف شخص ، معظمهم من موظفي سبيربنك)
- وحدة الضيف - يتم تقديم خدمة للمستخدمين غير المصادق عليهم ؛ هؤلاء ، على سبيل المثال ، الذين يأتون من خلال الموقع
- كتلة احتياطي - كتلة أمان قوية بما يكفي لاستبدال كتلتين من العملاء في وقت واحد
داخل كل كتلة ، يتم فصل خادم التطبيق وخادم الويب عن طريق قنوات الخدمة ، ولكن قواعد البيانات شائعة. لذا يمكننا عزل سيناريوهات الفشل الأكثر شيوعًا حتى لا تتجاوز حدود قناتنا.
كيف يعمل؟
أولاً ، يدخل المستخدم وحدة الموجه. تتحقق هذه الكتلة من العميل الذي يحظر الشخص الذي ينتمي إليه ويرسله إلى هناك (أو إلى كتلة الضيف). علاوة على ذلك ، يعمل الشخص بهدوء داخل كتلته. في حالة حدوث فشل في الوحدة الأصلية ، يعود الشخص إلى جهاز التوجيه ويتلقى تلقائيًا الاتجاه إلى وحدة النسخ الاحتياطي لمزيد من العمل.
ماذا يحدث للبيانات أثناء العملية؟ يتم نسخ المعلومات حول تفاعل العميل مع البنك باستمرار من كتل العميل إلى قاعدة بيانات الأرشيف. بعد التعرف على المستخدم ، تقوم وحدة النسخ الاحتياطي بسحب المعلومات الضرورية عنه من قاعدة بيانات الأرشيف ، وإذا لزم الأمر ، توفر البيانات - حتى لا يتجمد المستخدم عند حدوث مشاكل من جانبنا.
يتم تخزين العمليات التي تتم في وحدة النسخ الاحتياطي فيها. عندما تتم استعادة كتلة العميل الأصلية للمستخدم ، فإنها تعود. يتم نقل العمليات المتراكمة في كتلة النسخ الاحتياطي بشكل غير متزامن إلى كتل العميل الضرورية. بينما يتم تقليل البيانات إلى الاتساق ، يرى العميل رسالة تفيد بأنه تم قبول جميع العمليات وحفظها ، ولكن نظرًا للعمل الفني ، قد لا يتم عرض أحدث العمليات.
المخطط العام للنظامفي بعض الحالات ، يتم التخطيط للتبديل إلى كتلة النسخ الاحتياطي مقدمًا - على سبيل المثال ، عند التحديث في كتلة العميل. ثم لا تلتقط وحدة النسخ الاحتياطي جلسات العملاء ، ولكن في لحظة معينة تبدأ ببساطة جميع العمليات الجديدة بدلاً من ذلك. إذا كنت بحاجة ماسة إلى التبديل إلى وحدة النسخ الاحتياطي ، يمكن للمسؤول تعطيل جميع الجلسات. في هذه الحالة ، ستتم مقاطعة جلسة المستخدم ، وسيبدأ جلسة جديدة على وحدة النسخ الاحتياطي. بالمناسبة ، وحدة التوجيه لديها وحدة احتياطية خاصة بها. لذلك لم يبق أحد بدون عجلة احتياطية.
تحديث الأنظمة
يتم نشر إصدارات البرامج الجديدة أولاً على الكتلة التجريبية ويتم عرضها لجمهور محدود. ثم تدريجيا على كتل العميل ، وفي النهاية - على الاحتياطيات. لذلك إذا كانت هناك مشاكل في كتلة العميل مع الإصدار الجديد من البرنامج ، يمكننا نقل العملاء إلى كتلة النسخ الاحتياطي من الإصدار القديم.
عندما تدور وظيفة جديدة على كتلة ، لا يتم تشغيلها تلقائيًا. يقوم المسؤولون بذلك باستخدام مربعات الاختيار - تبديل الميزة. يمكنك تبديل العملاء إلى الإصدار الجديد حسب المجموعات - هذه هي الطريقة التي نتحقق من رد فعل التحديثات على نمو الجمهور.
الحكم الذاتي
نظامنا في حد ذاته موثوق به ، ولكنه لا يزال يعتمد على الواجهة الخلفية المستخدمة للعمليات. كيف تحمي نفسك من المشاكل؟ نستخدم ثلاث أدوات.
- الطلبات المعلقة . يطلب العميل إتمام العملية. نحفظه في قاعدة بياناتنا ونحاول تنفيذه في الخلفية. إذا لم تستجب الخلفية ، فإننا نعرض للعميل رسالة مفادها أن العملية قد تم قبولها وأنه قيد المعالجة. عندما ترتفع الواجهة الخلفية ، يقرأ "عامل ميناء" منفصل عمليات غير مكتملة من قاعدة البيانات ، و "يدفعها" إلى دفعات في نظام الواجهة الخلفية. حتى لا نفرط في تحميل الجدول الرئيسي بالعمليات التي تحتوي على عدد كبير من الاستعلامات منخفضة الكفاءة ، فإننا نستخدم أيضًا ما يسمى جدول الرموز المميزة - قائمة بمعرفات العمليات غير المكتملة. من أجل عدم إسقاط الخلفية التي ارتفعت للتو بمئات الآلاف من العمليات ، نستخدم التجميع - نحن نسقط مائتي عملية وننتظر ، على سبيل المثال ، لبضع ثوان.
ولكن ماذا لو حدثت تغييرات مهمة بين طلب المستخدم واسترداد الخلفية؟ على سبيل المثال ، هل انتقلت أسعار الصرف؟ في هذه الحالة ، يتم تشغيل التحقق المزدوج. يتم حفظ هذه العمليات عند الدخول ، ثم التحقق منها عند التنفيذ. إذا لم يتقارب شيء ما ، فسيتم تعديل العملية أو رفضها.
- التخزين المؤقت للبيانات . عندما يدخل مستخدم ، على سبيل المثال ، Sberbank Online ، تكون جميع المعلومات الضرورية عنه مرئية بالفعل - الفواتير والبطاقات والقروض ، إلخ. يتم طلب هذه البيانات من خلال ناقل خدمة من اثني عشر نظامًا. إذا تم جمع الاستجابة بسرعة ، في بضع ثوانٍ ، فإننا نعرض البيانات للعميل ونحفظها في ذاكرة التخزين المؤقت للنظام في قاعدة بياناتنا. إذا لم يكن الأمر كذلك ، فإننا نبحث في قاعدة البيانات عن البيانات المخزنة مؤقتًا مسبقًا ونعرضها على العميل. بالطبع ، لهذا ، يجب ألا تكون ذاكرة التخزين المؤقت أكبر من عمر معين. عندما يقوم ناقل الخدمة مع ذلك بجمع البيانات اللازمة عند الطلب ، يتم تحديثها في ذاكرة التخزين المؤقت لقاعدة البيانات وإرسالها إلى العميل بدلاً من القديمة.
عند استخدام التطبيق ، هذا يعني أن الشخص سيرى حالة حسابه بعد بضع ثوانٍ من الدخول. على الرغم من أن البيانات قد تكون قديمة إلى حد ما. إذا حدث هذا ، فعادةً بعد بضع ثوانٍ يتم استبدال البيانات بالبيانات الفعلية - مما يعني أن ناقل الخدمة قد جمع كل ما تحتاجه.
بالإضافة إلى ذلك ، لدينا التخزين المؤقت المسبق باستخدام النسخ المتماثل. في الغالب لبيانات مرجعية مختلفة. نقوم بتحميل هذه البيانات مسبقًا في الواجهة الخلفية ، ويقوم العميل بهدوء بطلب العملية ، ونرسلها. حتى إذا لم تعمل الأنظمة المسؤولة عن الحفاظ على البيانات ، فلن يضطر المستخدم إلى الانتظار مرة أخرى.
- فواصل فنية . إذا تعطل نظام الواجهة الخلفية أو كان يخضع للصيانة ، فإننا نبلغ عنه. ثم يقابل الرفض العمليات التي تمر عبره على الفور. لذا فإننا نحفظ خادم التطبيق من التدفق الزائد مع الطلبات التي تنتظر الرد حسب المهلة. في هذا الوضع ، يمكن استخدام التخزين المؤقت للعمليات والبيانات التي وصفناها سابقًا. يتم تعيين فترات الراحة الفنية لكل سيناريو التكامل ، يدويًا بواسطة المسؤول أو تلقائيًا ، بناءً على عدد الطلبات.
على أي حال ، نسعى لتقليل توقعات المستخدم - إذا كانت هناك مشاكل ، فإنه يتلقى رسالة على الفور حول استحالة العملية. نحن نحاول تقليل عدد هذه الرسائل ، وبالتالي نزيد من عمر بعض البيانات المخزنة مؤقتًا - وهذا يسمح لنا بتوسيع التفاعل الطبيعي مع خدمات البنك.
في بعض السيناريوهات ، لا يجب إجراء التخزين المؤقت بعيدًا - على سبيل المثال ، عند إصدار النقود. من المحتمل الغش من جانب العميل. هذه العمليات في أجهزة الصراف الآلي والفروع ليست مخبأة. في بنك الإنترنت ، هذا أسهل - نحن نقبل التطبيق ، ثم نعالجه أو نرفضه.
ونتيجة لذلك ، بمراعاة المبادئ الموضحة في المقالة ، يمكنك الحصول على أنظمة بنسبة توفر 99.99٪ وأعلى.
خططنا
الآن ، تهدف الخطط إلى تقليل الوقت المستغرق في السوق لنظامنا الفردي ، لضمان القدرة الشاملة ، مع مراعاة الميزات الفنية والتجارية للقنوات. وكذلك ترحيل الأنظمة القديمة مع الحفاظ على قابليتها للتشغيل أثناء النقل.
نشكر رومان شيخوفتسوف للمساعدة النشطة في إعداد هذا المنصب