لقطة من فيلم "عالمنا السري: الحياة الخفية للخلية"

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

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

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

لتلبية الاحتياجات الحالية ووضع الأساس للترقيات المستقبلية ، قمنا بتطوير جوهر الأعمال الاستثمارية القائمة على تارانتول.

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

خلفية

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

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

متطلبات الحل الجديدة

أدركت الأعمال أن التطور التكنولوجي أمر حيوي لمزيد من التطوير. تم تكليفنا بالمهام:

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

بالإضافة إلى ذلك ، حدد مهندسونا شروطهم:

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

لقد سلكنا الطريقة القياسية: صياغة المتطلبات واتصلنا بقسم المشتريات. من هناك لدينا قائمة بالشركات التي تكون مستعدة بشكل عام للقيام بذلك. أخبروا الجميع عن المهمة ، وحصل ستة منهم على تقييم للحلول.

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

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

بعد ذلك ، سأتحدث عن كيفية نمو نظامنا ، وكيف تطور ، وماذا فعلنا ولماذا.

تطوير

بادئ ذي بدء ، تساءلنا عن كيفية الحصول على البيانات من أنظمتنا الحالية. قررنا أن HTTP مناسب تمامًا لنا ، لأن جميع الأنظمة الحالية تتواصل مع بعضها البعض ، وإرسال XML أو JSON عبر HTTP.

نستخدم خادم Tarantool HTTP المضمن ، لأننا لسنا بحاجة إلى إنهاء جلسات SSL وأدائه كافٍ بالنسبة لنا.

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

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

بعد التحقق ، يجب حفظ البيانات. نقوم بذلك باستخدام vshard (لدينا نسخ متماثلة من الشظايا).

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

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

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

تطبيق نظام المصادقة.

ثم لاحظوا أن العديد من الأدوار تبلورت في حلنا. الدور هو نوع من تجميع الوظائف. كقاعدة ، تحتوي الأدوار على ملفات تعريف مختلفة لاستخدام المعدات:

T-Connect: يعالج الاتصالات الواردة ، محدودة بالمعالج ، تستهلك القليل من الذاكرة ، ولا تخزن الحالة.
IB-Core: يقوم بتحويل البيانات التي يتلقاها عبر بروتوكول Tarantool ، أي أنه يعمل مع الأجهزة اللوحية. أيضا لا يخزن الدولة ويمكن تحجيمها.
التخزين: يحفظ البيانات فقط ، ولا يستخدم أي منطق. يتم تنفيذ أبسط الواجهات في هذا الدور. تحجيم بفضل vshard.

أي أنه بمساعدة الأدوار ، فككنا عن بعضنا البعض من أجزاء مختلفة من المجموعة يمكن تحجيمها بشكل مستقل عن بعضها البعض.

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

اختبارات

منذ بداية المشروع ، تقرر أن نحاول غرس التطوير المدفوع باختبار. نكتب اختبارات الوحدة في Lua باستخدام إطار tarantool / tap ، اختبارات التكامل في Python باستخدام إطار pytest. في الوقت نفسه ، يشارك كل من المطورين والمحللين في كتابة اختبارات التكامل.

كيف نطبق التطوير القائم على الاختبار؟

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

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

ومع ذلك ، نحن نحب اختبار الإجهاد قبل كل شيء ، فنحن نعتبره الأهم ونجريه بانتظام.

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

كنا حزينين جدا. نحن ننظر إلى تحميل الخادم ، وتبين أنها خاملة.

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

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

علاوة على ذلك ، تم استخدام الذاكرة فقط لمعالجة الاتصالات الواردة والكائنات المؤقتة.

على العكس من ذلك ، على خوادم التخزين ، زاد حمل المعالج ، ولكن بشكل أبطأ بكثير من الخوادم التي تتعامل مع الاتصالات.

ونما استهلاك الذاكرة بنسبة مباشرة مع كمية البيانات المحملة.

خدمات

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

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

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

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

الأنظمة القديمة

لا يمكن لجميع أنظمتنا القديمة الاتصال بنا عبر HTTP واستخدام GraphQL ، على الرغم من أنها تدعم هذا البروتوكول. لذلك ، قمنا بعمل آلية لتكرار البيانات على هذه الأنظمة.

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

تحسينات جديدة

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

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

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

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

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

استنتاج

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

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

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

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

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

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

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

كيف فعلنا جوهر أعمال الاستثمار في ألفا بنك على أساس تارانتول