مرحبا يا هبر! نحن في RBKmoney كتبنا معالجة دفع جديدة. من الصفر. حسنا ، أليس هذا حلما؟
ومع ذلك ، كما هو الحال دائمًا ، في الطريق إلى الحلم ، كان على معظم الطريق السباحة على طول الأنهار مع المزالق ، جزئيًا - لركوب الدراجات المجمعة الخاصة بك. بهذه الطريقة ، تلقينا الكثير من المعرفة المفيدة والمفيدة التي نود مشاركتها معك.
سنخبرك بكيفية كتابة معالجة مدفوعات RBKmoney بالكامل ، كما أطلقنا عليها. كيف جعلوها مقاومة للأعطال وفشل المعدات ، وكيف توصلوا إلى إمكانية التوسع الأفقي الخطي تقريبًا.
وفي النهاية ، عندما انطلقنا جميعًا ، دون أن ننسى راحة من في الداخل ، تم إنشاء نظام الدفع لدينا بفكرة كونه مثيرًا للاهتمام في المقام الأول للمطورين ، أولئك الذين يقومون بإنشائه.
من خلال هذا المنشور ، نفتح سلسلة من المقالات التي سنشارك فيها كلًا من الأشياء التقنية المحددة والأساليب والتطبيقات ، بالإضافة إلى الخبرة في تطوير أنظمة موزعة كبيرة من حيث المبدأ. المقال الأول عبارة عن مقالة مراجعة ، حيث نحدد المعالم التي سنكشف عنها بالتفصيل ، وأحيانًا بتفصيل كبير.
تنويهمنذ آخر نشر في مدونتنا ، مرت ما لا يقل عن 5 سنوات. خلال هذا الوقت ، تم تحديث فريق التطوير لدينا بشكل ملحوظ ، والآن على رأس الشركة أشخاص جدد.
عند إنشاء نظام دفع ، تحتاج إلى التفكير في مجموعة من الأشياء المختلفة وتطوير الكثير من الحلول. من المعالجة التي يمكن أن تعالج آلاف الطلبات المتزامنة المتزامنة لخصم الأموال إلى واجهات سهلة الاستخدام. Trite ، إذا كنت لا تأخذ في الاعتبار الفروق الدقيقة الصغيرة.
الحقيقة القاسية هي أن هناك منظمات للدفع وراء معالجة الدفع ، لا تقبل على الإطلاق الأذرع المفتوحة التي تقبل مثل هذه الحركة ، وحتى تطلب أحيانًا "عدم إرسال أكثر من 3 طلبات في الثانية". والأشخاص الذين ربما ، للمرة الأولى على الإنترنت قرروا الدفع مقابل شيء ما ، انظروا إلى الواجهات. وأي ذراع UX ، عدم فهم وتأخير - هذه مناسبة للذعر.
سلة يمكنك من خلالها شراء مشترياتك حتى أثناء الأعاصير
نهجنا في إنشاء معالجة الدفع هو توفير القدرة على بدء الدفع دائمًا . لا يهم ما يحدث في داخلنا - الخادم احترق ، ارتبك المسؤول في الشبكات ، انقطعت الكهرباء في المبنى / المنطقة / المدينة ، لدينا ديزل هم ... فقدنا. لا يهم. ستظل الخدمة تسمح لك ببدء الدفع.
يبدو النهج مألوفًا ، أليس كذلك؟
نعم ، لقد استلهمنا المفهوم الموصوف في Amazon Dynamo Paper . قام الأشخاص من أمازون أيضًا ببناء كل شيء حتى يتمكن المستخدم من وضع الكتاب في السلة ، بغض النظر عن الرعب الذي يحدث على الجانب الآخر من شاشته.
بالطبع ، نحن لا ننتهك قوانين الفيزياء ولم نكتشف كيفية دحض نظرية CAP . إنها ليست حقيقة أن يتم الدفع على الفور - بعد كل شيء ، قد تكون هناك مشاكل في جانب البنوك ، ولكن الخدمة ستنشئ طلبًا وسيشاهد المستخدم أن كل شيء يعمل. نعم ، وما زلنا من الناحية المثالية عشرات القوائم المتراكمة مع دين تقني ، وهو خطيئة ، يمكننا الإجابة على 504 من حين لآخر.
دعونا ننظر في المخبأ ، بمجرد الإعصار خارج النافذة
كان من الضروري إتاحة بوابة الدفع لدينا دائمًا. سواء ازدادت ذروة الحمل ، فقد حدث شيء ما أو خضع للصيانة في DC - يجب على المستخدم النهائي عدم ملاحظة ذلك على الإطلاق.
تم تحديد ذلك من خلال تقليل الأماكن التي يتم فيها تخزين حالة النظام - من الواضح أن التطبيقات عديمة الجنسية يسهل قياسها إلى الأفق.
التطبيقات نفسها تدور في حاويات Docker ، السجلات التي ندمجها بشكل موثوق في مستودع Elasticearch المركزي ؛ يجدون بعضهم البعض من خلال Service Discovery ، ويتم إرسال البيانات عبر IPv6 داخل خدمة Macro .
جميع الخدمات الصغيرة التي يتم جمعها والعمل معًا ، جنبًا إلى جنب مع الخدمات ذات الصلة ، هي خدمة كلية ، والتي توفر لك في النهاية بوابة دفع ، كما تراها من الخارج كواجهة برمجة التطبيقات العامة لدينا.
يراقب SaltStack الطلب ، الذي يصف حالة Macroservice بأكملها.
سنعود مع وصف مفصل لهذه المزرعة بأكملها.
مع التطبيقات أسهل.
ولكن إذا قمت بتخزين الحالة في مكان ما ، فتأكد من ذلك في قاعدة بيانات تكون فيها تكلفة فشل جزء من العقد ضئيلة. أيضا ، بحيث لا تحتوي على عقدة رئيسية مع البيانات. وذلك مع وقت انتظار متوقع للرد على الطلبات. هل هو حلمك هنا؟ ثم ، حتى لخدمتها ، لم يكن ذلك ضروريًا بشكل خاص ، وأن مطوري الإيرلانجيين أحبوها.
نعم ، ألم نقول أن الجزء الكامل عبر الإنترنت من معالجتنا في Erlang مكتوب؟
كما خمّن الكثيرون بالفعل ، لم يكن لدينا خيار على هذا النحو.
يتم تخزين الحالة الكاملة للجزء عبر الإنترنت من نظامنا في Basho Riak . سنخبرك أيضًا بكيفية طهي Riak وعدم كسر أصابعك (لأنك ستكسر دماغك) ، ولكن دعنا نواصل الآن.
أين المال يا ليبوسكي؟
إذا كنت تأخذ كمية لا حصر لها من المال ، فقد تتمكن من بناء معالجة موثوقة بلا حدود. لكن هذا ليس دقيقا. ولا يعطونا الكثير من المال. الحق على مستوى الخادم "الجودة ، ولكن الصين".
لحسن الحظ ، أدى هذا إلى آثار إيجابية. عندما تفهم أنه كمطور ، سيكون من الصعب إلى حد ما أن تحصل على 40 نواة فعلية تعالج 512 جيجا بايت من ذاكرة الوصول العشوائي ، عليك الخروج وكتابة تطبيقات صغيرة. ولكن يمكن نشرها كما تشاء - لا تزال الخوادم غير مكلفة.
حتى في عالمنا ، لا تميل أي خوادم إلى العودة إلى الحياة بعد إعادة التشغيل ، أو حتى اكتشاف انقطاع التيار الكهربائي في أكثر الأوقات غير المناسبة.
من خلال النظر في كل هذه الأهوال ، تعلمنا كيفية بناء نظام متوقعًا أن ينكسر أي جزء منه فجأة. من الصعب تذكر ما إذا كان هذا النهج قد تسبب في أي إزعاج لتطوير جزء المعالجة عبر الإنترنت. ربما يرتبط هذا بطريقة أو بأخرى بفلسفة Erlangists ومفهومهم الشهير LetItCrash ؟
ولكن مع الخوادم أسهل.
اكتشفنا مكان وضع التطبيقات ، وهناك الكثير منها ، فهي قابلة للتطوير. يتم توزيع القاعدة أيضًا ، ولا يوجد عقد رئيسي ، والعقد المحروقة ليست شفقة ، يمكننا بسرعة تحميل العربة بالخوادم ، والقدوم إلى العاصمة وتركها مع الشوك في الرفوف.
ولكن هذا ليس هو الحال مع صفائف القرص! فشل حتى تخزين القرص الصغير هو فشل جزء من خدمة الدفع ، التي لا يمكننا تحملها. تخزين مكرر؟ غير عملي للغاية.
ونحن لا نريد شراء مصفوفات الأقراص ذات العلامات التجارية باهظة الثمن. حتى من إحساس بسيط بالجمال - لن ينظروا بجانب الرفوف حيث تكون الأسماء معبأة في صفوف حتى. وهي مكلفة بشكل غير معقول.
في النهاية ، قررنا عدم استخدام صفائف القرص على الإطلاق. جميع أجهزة البلوك التي لدينا تشغل CEPH على نفس الخوادم الرخيصة - يمكننا وضعها في رفوف بكميات كبيرة نحتاجها.
مع أجهزة الشبكة ، لا يختلف النهج كثيرًا. نأخذ الفلاحين الأوسطين ، نحصل على معدات جيدة ومناسبة للمهمة غير مكلفة للغاية. في حالة فشل التبديل ، يعمل الثاني بالتوازي ، ويتم تكوين OSPF على الخوادم ، ويضمن التقارب.
وبالتالي ، لدينا نظام عالمي ملائم ومتسامح مع الأخطاء - رف مليء بالخوادم الرخيصة البسيطة والعديد من المفاتيح. الموقف التالي. وهكذا دواليك.
بسيطة ومريحة وعموما - موثوق بها للغاية.
الاستماع إلى قواعد السلوك على متن الطائرة
لم نرغب أبدًا في القدوم إلى المكتب والقيام بالعمل والحصول على أموال نقدية. إن المكون المالي مهم للغاية ، لكنه لن يحل محل متعة العمل الجيد. لقد كتبنا بالفعل أنظمة دفع ، بما في ذلك في أماكن العمل السابقة. وتصورنا تقريبًا ما لا نريد القيام به. ولم أكن أريد حلولًا قياسية ، ولكن أثبتت جدواها ، لم أكن أريد مؤسسة مملة.
وقررنا سحب أقصى نضارة في العمل. في تطوير أنظمة الدفع ، غالبًا ما تكون الحلول الجديدة محدودة ، كما يقولون ، لماذا تحتاج إلى عامل إرساء على الإطلاق ، دعنا نذهب بدونها. وبشكل عام. ليس بالأمن. رفض.
قررنا عدم حظر أي شيء ، بل تشجيع كل شيء جديد. لذلك ، في إنتاجنا ، قمنا ببناء خدمة ماكرو من كومة ضخمة من التطبيقات في حاويات دوكر ، تدار من خلال SaltStack ، مجموعات Riak ، القنصل كخدمة اكتشاف ، تنفيذ أصلي لتتبع الاستعلام في نظام موزع ، والعديد من التقنيات الرائعة الأخرى.
وكل هذا آمن للغاية بحيث يمكنك نشر برنامج Bugbounty على hackerone.com دون خجل.
بالطبع ، كانت الخطوات الأولى على طول هذا الطريق مليئة ببعض الكميات غير اللائقة من الجرافات. عندما نراجعها ، سنخبرك أيضًا ، على سبيل المثال ، عن سبب عدم وجود بيئة اختبار ، ويمكن نشر جميع المعالجة على الكمبيوتر المحمول الخاص بالمطور باستخدام make up بسيط.
مثل مجموعة من الأشياء المثيرة للاهتمام.
شكرا لك على اختيار شركة الطيران لدينا!
ملاحظة: المحتوى الأصلي! جميع الصور في المنشور هي مشاهد من حياة مكتبنا.