لقطة من فيلم "عالمنا السري: الحياة الخفية للخلية"
تعد الأعمال الاستثمارية واحدة من أكثر المجالات تعقيدًا في العالم المصرفي، لأنه لا توجد القروض والاقتراضات والودائع فحسب، بل توجد أيضًا الأوراق المالية والعملات والسلع والمشتقات وجميع أنواع التعقيدات في شكل منتجات منظمة.
لقد شهدنا مؤخرًا زيادة في الثقافة المالية لدى السكان. المزيد والمزيد من الناس يشاركون في التداول في أسواق الأوراق المالية. ظهرت حسابات الاستثمار الفردية منذ وقت ليس ببعيد. فهي تسمح لك بالتداول في أسواق الأوراق المالية والحصول على تخفيضات ضريبية أو تجنب دفع الضرائب. ويرغب جميع العملاء الذين يأتون إلينا في إدارة محفظتهم الاستثمارية ورؤية التقارير في الوقت الفعلي. علاوة على ذلك، غالبًا ما تكون هذه المحفظة متعددة المنتجات، أي أن الأشخاص هم عملاء في مجالات أعمال مختلفة.
وبالإضافة إلى ذلك، فإن احتياجات الهيئات التنظيمية، سواء الروسية أو الأجنبية، آخذة في الازدياد.
لتلبية الاحتياجات الحالية ووضع الأساس للترقيات المستقبلية، قمنا بتطوير جوهر الأعمال الاستثمارية على أساس Tarantool.
بعض الإحصائيات. توفر الأعمال الاستثمارية لدى Alfa-Bank خدمات الوساطة للأفراد والكيانات القانونية لإتاحة الفرصة للتداول في أسواق الأوراق المالية المختلفة، وخدمات الإيداع لتخزين الأوراق المالية، وخدمات إدارة الثقة للأفراد ذوي رؤوس الأموال الخاصة والكبيرة، وخدمات إصدار الأوراق المالية للشركات الأخرى. . تتضمن الأعمال الاستثمارية لـ Alfa-Bank أكثر من 3 آلاف عرض أسعار في الثانية، والتي يتم تنزيلها من منصات التداول المختلفة. ويتم خلال يوم العمل إبرام أكثر من 300 ألف صفقة في الأسواق نيابة عن البنك أو عملائه. يتم تنفيذ ما يصل إلى 5 آلاف أمر في الثانية على منصات خارجية وداخلية. وفي الوقت نفسه، يرغب جميع العملاء، الداخليين والخارجيين، في رؤية مراكزهم في الوقت الفعلي.
قبل التاريخ
في مكان ما منذ بداية العقد الأول من القرن الحادي والعشرين، تطورت مجالات أعمالنا الاستثمارية بشكل مستقل: تداول العملات، وخدمات الوساطة، وتداول العملات، والتداول خارج البورصة في الأوراق المالية والمشتقات المختلفة. ونتيجة لذلك وقعنا في فخ الآبار الوظيفية. ما هو؟ كل خط عمل له أنظمته الخاصة التي تكرر وظائف بعضها البعض. كل نظام لديه نموذج بيانات خاص به، على الرغم من أنها تعمل بنفس المفاهيم: المعاملات، والأدوات، والأطراف المقابلة، وعروض الأسعار، وما إلى ذلك. ومع تطور كل نظام بشكل مستقل، ظهرت مجموعة متنوعة من التقنيات.
بالإضافة إلى ذلك، فإن قاعدة التعليمات البرمجية للأنظمة قديمة بالفعل، لأن بعض المنتجات نشأت في منتصف التسعينيات. وفي بعض المناطق، أدى هذا إلى إبطاء عملية التطوير، وكانت هناك مشاكل في الأداء.
متطلبات الحل الجديد
لقد أدركت الشركات أن التحول التكنولوجي أمر حيوي لمزيد من التطوير. تم تكليفنا بمهام:
- اجمع كل بيانات الأعمال في وحدة تخزين واحدة سريعة وفي نموذج بيانات واحد.
- يجب ألا نفقد هذه المعلومات أو نغيرها.
- من الضروري إصدار البيانات، لأنه في أي لحظة قد تطلب الجهة المنظمة إحصائيات للسنوات السابقة.
- لا يجب علينا فقط تقديم بعض أنظمة إدارة قواعد البيانات الجديدة والعصرية، بل يجب علينا أيضًا إنشاء منصة لحل مشكلات العمل.
بالإضافة إلى ذلك، يضع مهندسونا شروطهم الخاصة:
- يجب أن يكون الحل الجديد على مستوى المؤسسات، أي أنه يجب اختباره بالفعل في بعض الشركات الكبيرة.
- يجب أن يكون وضع تشغيل الحل بالغ الأهمية. وهذا يعني أننا يجب أن نكون موجودين في عدة مراكز بيانات في وقت واحد وأن ننجو بهدوء من انقطاع مركز بيانات واحد.
- يجب أن يكون النظام قابلاً للتطوير أفقيًا. والحقيقة هي أن جميع أنظمتنا الحالية قابلة للتطوير عموديًا فقط، وقد وصلنا بالفعل إلى الحد الأقصى بسبب النمو المنخفض لطاقة الأجهزة. ولذلك، فقد حان الوقت الذي نحتاج فيه إلى نظام قابل للتطوير أفقيًا من أجل البقاء.
- ومن بين أمور أخرى، قيل لنا إن الحل يجب أن يكون رخيصًا.
لقد اتبعنا المسار القياسي: قمنا بصياغة المتطلبات واتصلنا بقسم المشتريات. ومن هناك تلقينا قائمة بالشركات المستعدة بشكل عام للقيام بذلك نيابةً عنا. أخبرنا الجميع بالمشكلة، وتلقينا تقييمًا للحلول من ستة منهم.
في البنك، نحن لا نأخذ كلام أي شخص على محمل الجد، ونحب أن نختبر كل شيء بأنفسنا. لذلك، كان الشرط الإلزامي لمنافستنا في المناقصة هو اجتياز اختبارات التحميل. لقد قمنا بصياغة مهام اختبار الحمل، وقد وافقت ثلاث شركات من أصل ست شركات بالفعل على تنفيذ حل نموذجي يعتمد على تقنيات الذاكرة الداخلية على نفقتها الخاصة من أجل اختباره.
لن أخبرك كيف اختبرنا كل شيء وكم من الوقت استغرق الأمر، سألخص فقط: تم عرض أفضل أداء في اختبارات التحميل من خلال حل نموذج أولي يعتمد على Tarantool من فريق تطوير Mail.ru Group. وقعنا اتفاقية وبدأنا التطوير. كان هناك أربعة أشخاص من مجموعة Mail.ru، ومن Alfa-Bank كان هناك ثلاثة مطورين، وثلاثة محللي أنظمة، ومهندس حلول، ومالك منتج، وخبير Scrum.
بعد ذلك، سأخبرك عن كيفية نمو نظامنا، وكيف تطور، وماذا فعلنا ولماذا حدث ذلك بالضبط.
تطوير
كان السؤال الأول الذي طرحناه على أنفسنا هو كيفية الحصول على البيانات من أنظمتنا الحالية. قررنا أن HTTP مناسب تمامًا لنا، لأن جميع الأنظمة الحالية تتواصل مع بعضها البعض عن طريق إرسال XML أو JSON عبر HTTP.
نحن نستخدم خادم HTTP المدمج في Tarantool لأننا لا نحتاج إلى إنهاء جلسات SSL، وأدائه يكفي بالنسبة لنا.
كما قلت سابقًا، تعيش جميع أنظمتنا في نماذج بيانات مختلفة، وعند الإدخال نحتاج إلى إحضار الكائن إلى النموذج الذي نصفه بأنفسنا. كانت هناك حاجة إلى لغة تسمح بتحويل البيانات. لقد اخترنا لوا الحتمية. نقوم بتشغيل جميع أكواد تحويل البيانات في وضع الحماية - وهذا مكان آمن لا تتجاوزه التعليمات البرمجية الجاري تشغيلها. للقيام بذلك، نقوم ببساطة بتحميل التعليمات البرمجية المطلوبة، وإنشاء بيئة ذات وظائف لا يمكنها حظر أو إسقاط أي شيء.
بعد التحويل، يجب التحقق من توافق البيانات مع النموذج الذي نقوم بإنشائه. لقد ناقشنا لفترة طويلة ما يجب أن يكون عليه النموذج وما هي اللغة التي يجب استخدامها لوصفه. لقد اخترنا Apache Avro لأن اللغة بسيطة وتحظى بدعم Tarantool. يمكن تشغيل الإصدارات الجديدة من النموذج والتعليمات البرمجية المخصصة عدة مرات يوميًا، حتى تحت التحميل أو بدونه، في أي وقت من اليوم، والتكيف مع التغييرات بسرعة كبيرة.
بعد التحقق، يجب حفظ البيانات. نقوم بذلك باستخدام vshard (لدينا نسخ متماثلة من الأجزاء الموزعة جغرافيًا).
علاوة على ذلك، فإن الخصوصية تجعل معظم الأنظمة التي ترسل لنا البيانات لا تهتم بما إذا كنا قد تلقيناها أم لا. لهذا السبب قمنا بتنفيذ قائمة انتظار الإصلاح منذ البداية. ما هو؟ إذا لم يخضع الكائن لتحويل البيانات أو التحقق منها لسبب ما، فإننا نستمر في تأكيد الاستلام، ولكن في نفس الوقت نحفظ الكائن في قائمة انتظار الإصلاح. إنه ثابت وموجود في مستودع بيانات الأعمال الرئيسي. لقد كتبنا على الفور واجهة مسؤول لها ومقاييس وتنبيهات مختلفة. ونتيجة لذلك، فإننا لا نفقد البيانات. حتى لو تغير شيء ما في المصدر، إذا تغير نموذج البيانات، فسنكتشفه على الفور ويمكننا التكيف معه.
أنت الآن بحاجة إلى معرفة كيفية استرداد البيانات المحفوظة. لقد قمنا بتحليل أنظمتنا بعناية ورأينا أن المجموعة الكلاسيكية من Java وOracle تحتوي بالضرورة على نوع من ORM الذي يحول البيانات من علائقية إلى كائن. فلماذا لا نعطي الأشياء للأنظمة على الفور في شكل رسم بياني؟ لذلك اعتمدنا بكل سرور GraphQL، الذي لبى جميع احتياجاتنا. يسمح لك بتلقي البيانات في شكل رسوم بيانية وسحب ما تحتاجه الآن فقط. يمكنك أيضًا إصدار واجهة برمجة التطبيقات بقدر كبير من المرونة.
أدركنا على الفور تقريبًا أن البيانات التي كنا نستخرجها لم تكن كافية. لقد أنشأنا وظائف يمكن ربطها بالكائنات الموجودة في النموذج - وهي في الأساس حقول محسوبة. أي أننا نعلق وظيفة معينة على الحقل، والتي، على سبيل المثال، تحسب متوسط سعر العرض. والمستهلك الخارجي الذي يطلب البيانات لا يعرف حتى أن هذا حقل محسوب.
تم تنفيذ نظام المصادقة.
ثم لاحظنا أن عدة أدوار تبلورت في قرارنا. الدور هو نوع من تجميع الوظائف. عادةً ما يكون للأدوار ملفات تعريف مختلفة لاستخدام المعدات:
- T-Connect: يتعامل مع الاتصالات الواردة، وحدة المعالجة المركزية محدودة، استهلاك منخفض للذاكرة، عديم الحالة.
- IB-Core: يقوم بتحويل البيانات التي يتلقاها عبر بروتوكول Tarantool، أي أنه يعمل مع الجداول. كما أنه لا يخزن الحالة وقابل للتطوير.
- التخزين: يخزن البيانات فقط، ولا يستخدم أي منطق. ينفذ هذا الدور أبسط الواجهات. قابلة للتطوير بفضل vshard.
وهذا يعني أنه باستخدام الأدوار، قمنا بفصل أجزاء مختلفة من المجموعة عن بعضها البعض، والتي يمكن قياسها بشكل مستقل عن بعضها البعض.
لذلك، قمنا بإنشاء تسجيل تدفق بيانات المعاملات غير المتزامن وقائمة انتظار الإصلاح مع واجهة المسؤول. التسجيل غير متزامن من وجهة نظر الأعمال: إذا كنا نضمن كتابة البيانات لأنفسنا، بغض النظر عن المكان، فسنؤكد ذلك. إذا لم يتم تأكيده، فهذا يعني أن هناك خطأ ما ويجب إرسال البيانات. هذا هو التسجيل غير المتزامن.
تجريب
منذ بداية المشروع، قررنا أننا سنحاول تنفيذ التطوير القائم على الاختبار. نكتب اختبارات الوحدة في Lua باستخدام إطار عمل Tarantool/tap، واختبارات التكامل في Python باستخدام إطار عمل pytest. وفي الوقت نفسه، نقوم بإشراك كل من المطورين والمحللين في كتابة اختبارات التكامل.
كيف نستخدم التطوير القائم على الاختبار؟
إذا أردنا بعض الميزات الجديدة، نحاول كتابة اختبار لها أولاً. عندما نكتشف خطأ ما، نتأكد من كتابة اختبار أولاً، وبعد ذلك فقط نقوم بإصلاحه. في البداية، كان من الصعب العمل بهذه الطريقة، وكان هناك سوء فهم من جانب الموظفين، بل وحتى تخريب: "دعونا نصلح الأمر بسرعة الآن، ونفعل شيئًا جديدًا، ثم نغطيه بالاختبارات". فقط هذا "لاحقًا" لا يأتي أبدًا.
لذلك، عليك أن تجبر نفسك على كتابة الاختبارات أولاً وتطلب من الآخرين القيام بذلك. صدقني، التطوير القائم على الاختبار يجلب فوائد حتى على المدى القصير. وستشعر أن حياتك أصبحت أسهل. نشعر أن 99% من التعليمات البرمجية تمت تغطيتها الآن بواسطة الاختبارات. يبدو هذا كثيرًا، ولكن ليس لدينا أية مشكلات: يتم إجراء الاختبارات عند كل التزام.
ومع ذلك، فإن أكثر ما نحبه هو اختبار التحميل، الذي نعتبره الأكثر أهمية ونجريه بانتظام.
سأخبرك قصة صغيرة حول كيفية تنفيذنا للمرحلة الأولى من اختبار التحميل لأحد الإصدارات الأولى. قمنا بتثبيت النظام على الكمبيوتر المحمول الخاص بالمطور، وقمنا بتشغيل التحميل وحصلنا على 4 آلاف معاملة في الثانية. نتيجة جيدة لجهاز كمبيوتر محمول. لقد قمنا بتثبيته على منصة تحميل افتراضية مكونة من أربعة خوادم، وهو أضعف مما كان عليه في الإنتاج. منتشرة إلى الحد الأدنى. نقوم بتشغيله، ونحصل على نتيجة أسوأ من جهاز كمبيوتر محمول في موضوع واحد. محتوى الصدمة.
كنا حزينين جدا. نحن ننظر إلى تحميل الخادم، ولكن اتضح أنه خامل.
نتصل بالمطورين، ويشرحون لنا، نحن الأشخاص الذين يأتون من عالم Java، أن Tarantool أحادي الخيط. ولا يمكن استخدامه بفعالية إلا من خلال نواة معالج واحدة تحت الحمل. ثم قمنا بنشر أكبر عدد ممكن من مثيلات Tarantool على كل خادم، وقمنا بتشغيل التحميل واستقبلنا بالفعل 14,5 ألف معاملة في الثانية.
اسمحوا لي أن أشرح مرة أخرى. نظرًا للتقسيم إلى أدوار تستخدم الموارد بشكل مختلف، فإن أدوارنا المسؤولة عن معالجة الاتصالات وتحويل البيانات تحمل المعالج فقط، وتتناسب تمامًا مع الحمل.
في هذه الحالة، تم استخدام الذاكرة فقط لمعالجة الاتصالات الواردة والكائنات المؤقتة.
على العكس من ذلك، على خوادم التخزين، زاد تحميل المعالج، ولكن أبطأ بكثير من الخوادم التي تعالج الاتصالات.
ونما استهلاك الذاكرة بما يتناسب بشكل مباشر مع كمية البيانات المحملة.
الخدمات
لتطوير منتجنا الجديد على وجه التحديد كنظام أساسي للتطبيقات، قمنا بإنشاء مكون لنشر الخدمات والمكتبات عليه.
الخدمات ليست مجرد أجزاء صغيرة من التعليمات البرمجية التي تعمل في بعض المجالات. يمكن أن تكون هياكل كبيرة ومعقدة جدًا تشكل جزءًا من مجموعة، وتتحقق من البيانات المرجعية، وتقوم بتشغيل منطق الأعمال وإرجاع الاستجابات. نقوم أيضًا بتصدير مخطط الخدمة إلى GraphQL، ويتلقى المستهلك نقطة وصول عالمية إلى البيانات، مع الاستبطان عبر النموذج بأكمله. أنها مريحة للغاية.
نظرًا لأن الخدمات تحتوي على العديد من الوظائف، فقد قررنا أنه يجب أن تكون هناك مكتبات سننقل فيها التعليمات البرمجية المستخدمة بشكل متكرر. لقد أضفناها إلى البيئة الآمنة، بعد أن تأكدنا مسبقًا من أنها لا تكسر أي شيء بالنسبة لنا. والآن يمكننا تخصيص بيئات إضافية للوظائف على شكل مكتبات.
أردنا أن يكون لدينا منصة ليس فقط للتخزين، ولكن أيضًا للحوسبة. وبما أن لدينا بالفعل مجموعة من النسخ المتماثلة والشظايا، فقد قمنا بتنفيذ نوع من الحوسبة الموزعة وأطلقنا عليها اسم "تقليل الخريطة"، لأنها أصبحت مشابهة لتقليل الخريطة الأصلية.
الأنظمة القديمة
لا تستطيع جميع أنظمتنا القديمة الاتصال بنا عبر HTTP واستخدام GraphQL، على الرغم من أنها تدعم البروتوكول. ولذلك، أنشأنا آلية تسمح بنسخ البيانات في هذه الأنظمة.
إذا تغير شيء ما بالنسبة لنا، فسيتم تشغيل المشغلات الفريدة في دور التخزين وتنتهي الرسالة التي تحتوي على التغييرات في قائمة انتظار المعالجة. ويتم إرساله إلى نظام خارجي باستخدام دور النسخ المتماثل المنفصل. هذا الدور لا يخزن الحالة.
تحسينات جديدة
كما تتذكر، من وجهة نظر الأعمال، قمنا بالتسجيل غير المتزامن. ولكن بعد ذلك أدركوا أن هذا لن يكون كافيا، لأن هناك فئة من الأنظمة التي تحتاج إلى تلقي استجابة على الفور حول حالة العملية. لذلك قمنا بتوسيع GraphQL الخاص بنا وأضفنا طفرات. إنها تتلاءم عضويًا مع النموذج الحالي للعمل مع البيانات. بالنسبة لنا، هذه نقطة واحدة للقراءة والكتابة لفئة أخرى من الأنظمة.
لقد أدركنا أيضا أن الخدمات وحدها لن تكون كافية بالنسبة لنا، لأن هناك تقارير ثقيلة للغاية تحتاج إلى بناء مرة واحدة في اليوم، في الأسبوع، في الشهر. يمكن أن يستغرق هذا وقتًا طويلاً، وقد تؤدي التقارير أيضًا إلى حظر حلقة أحداث Tarantool. ولذلك، قمنا بإنشاء أدوار منفصلة: المجدول والعداء. العدائين لا يخزنون الحالة. إنهم يقومون بمهام ثقيلة لا يمكننا حسابها بسرعة. ويقوم دور المجدول بمراقبة جدول إطلاق هذه المهام، الموضح في التكوين. يتم تخزين المهام نفسها في نفس مكان تخزين بيانات العمل. عندما يحين الوقت المناسب، يأخذ المجدول المهمة ويعطيها لبعض العداء الذي يقوم بعدها وحفظ النتيجة.
ليس من الضروري تشغيل كافة المهام وفقًا لجدول زمني. يجب قراءة بعض التقارير عند الطلب. بمجرد وصول هذا المطلب، يتم إنشاء مهمة في وضع الحماية وإرسالها إلى العداء للتنفيذ. بعد مرور بعض الوقت، يتلقى المستخدم استجابة غير متزامنة بأن كل شيء قد تم حسابه وأن التقرير جاهز.
في البداية، التزمنا بنموذج تخزين كافة البيانات وإصدارها وعدم حذفها. لكن في الحياة، من وقت لآخر، لا يزال يتعين عليك حذف شيء ما، معظمه بعض المعلومات الأولية أو المتوسطة. بناءً على انتهاء الصلاحية، أنشأنا آلية لتنظيف مساحة التخزين من البيانات القديمة.
نحن نفهم أيضا أنه عاجلا أم آجلا سيأتي الوضع عندما لن تكون هناك مساحة كافية لتخزين البيانات في الذاكرة، ولكن مع ذلك يجب تخزين البيانات. لهذه الأغراض، سنقوم قريبًا بإنشاء تخزين على القرص.
اختتام
لقد بدأنا بمهمة تحميل البيانات في نموذج واحد وأمضينا ثلاثة أشهر في تطويره. كان لدينا ستة أنظمة لتزويد البيانات. يبلغ رمز التحويل بالكامل إلى نموذج واحد حوالي 30 ألف سطر في Lua. ومعظم العمل لا يزال أمامنا. في بعض الأحيان يكون هناك نقص في التحفيز من الفرق المجاورة، وهناك العديد من الظروف التي تعقد العمل. إذا واجهت مهمة مماثلة، فاضرب الوقت الذي يبدو طبيعيا لتنفيذه بثلاثة، أو حتى أربعة.
تذكر أيضًا أن المشكلات الحالية في العمليات التجارية لا يمكن حلها باستخدام نظام إدارة قواعد البيانات الجديد، حتى لو كان مثمرًا للغاية. الذي أقصده؟ في بداية مشروعنا، خلقنا انطباعًا لدى العملاء بأننا الآن سنجلب قاعدة بيانات سريعة جديدة وسنعيش! سوف تسير العمليات بشكل أسرع، وكل شيء سيكون على ما يرام. في الواقع، التكنولوجيا لا تحل المشاكل التي تواجه العمليات التجارية، لأن العمليات التجارية هي الناس. وتحتاج إلى العمل مع الناس، وليس التكنولوجيا.
يمكن أن يكون التطوير القائم على الاختبار مؤلمًا ويستغرق وقتًا طويلاً في المراحل المبكرة. لكن التأثير الإيجابي سيكون ملحوظًا حتى على المدى القصير، عندما لا تحتاج إلى القيام بأي شيء لإجراء اختبار الانحدار.
من المهم للغاية إجراء اختبار الحمل في جميع مراحل التطوير. كلما لاحظت بعض الخلل في البنية، كلما كان من الأسهل إصلاحه، مما سيوفر لك الكثير من الوقت في المستقبل.
لا يوجد شيء خاطئ مع لوا. يمكن لأي شخص أن يتعلم الكتابة فيها: مطور Java، مطور JavaScript، مطور Python، الواجهة الأمامية أو الخلفية. حتى محللينا يكتبون عنها.
عندما نتحدث عن حقيقة أننا لا نملك SQL، فهذا يخيف الناس. "كيف تحصل على البيانات بدون SQL؟ هل هذا ممكن؟ بالتأكيد. في نظام فئة OLTP، ليست هناك حاجة إلى SQL. هناك بديل في شكل نوع من اللغة يعيدك على الفور إلى طريقة عرض موجهة نحو المستند. على سبيل المثال، GraphQL. وهناك بديل في شكل الحوسبة الموزعة.
إذا فهمت أنك ستحتاج إلى التوسع، فقم بتصميم الحل الخاص بك على Tarantool بطريقة يمكن تشغيله بالتوازي على العشرات من مثيلات Tarantool. إذا لم تقم بذلك، فسيكون الأمر صعبًا ومؤلمًا لاحقًا، نظرًا لأن Tarantool يمكنه فقط استخدام نواة معالج واحدة بشكل فعال.
المصدر: www.habr.com