لقد كتبنا مؤخرًا عن كيفية عمل مهندسي تكنولوجيا المعلومات ، والآن سنخبرك بالتفاصيل حول إحدى حالاتنا ونعرض مخطط النظام. في هذا المشروع ، ساعدنا في استبدال تطبيق مصرفي "مربع" بخدمات صغيرة RBS ، مع إنشاء إصدار سريع للإصدارات - في المتوسط ، مرة واحدة في الأسبوع.
: , , -. NDA – , , , -.
«»
من بين الشركات المتوسطة والصغيرة ، هناك طلب على حلول تكنولوجيا المعلومات الجاهزة ، والتي يمكن تخصيصها وإصدارها بشعارها الخاص. السلبيات - وظائف التطبيقات "خارج الصندوق" محدودة ، وغالبًا ما يتعين إجراء التحديثات لفترة طويلة وحصريًا من خلال البائع.
استخدم أحد عملائنا مثل هذا النظام "الصندوقي" للخدمات المصرفية عن بُعد (RBS). كان البنك عبر الإنترنت تطبيقًا مترابطًا مع مجموعة صغيرة إلى حد ما من الوظائف.
لكي لا يكون أدنى من المنافسين ، كان على البنك إدخال تحسينات وميزات جديدة باستمرار. ومع ذلك ، حتى لنقل الأزرار ببساطة في التطبيق ، كان عليك الاتصال بالبائع. تم إصدار التحديثات في المتوسط مرة واحدة كل ثلاثة أشهر.
وبالتالي ، كان من الصعب تطوير المنتج بسبب عدد من القيود:
- , «» .
- - «» -.
- , .
- , . .
- , .
- - , , , .
ونتيجة لذلك ، اتخذ البنك قرارًا بالتخلي تدريجياً عن "الصندوق" وتطوير نظامه المصرفي الخاص به عن بُعد ، بهندسة خدمات مصغرة ، من أجل تسريع تطوير الوظائف وتوفير الراحة والأمان للمستخدمين.
من أين بدأنا
بدأ إنشاء بنك عبر الإنترنت بتصميم بنية عالية المستوى ، وتوظيف مطورين من بين الموظفين ، وربط فريقنا المتخصص. في الوقت نفسه ، كان لابد من وضع الهيكل بهامش أمان ، معتمداً على التوسع المستقبلي.
في البداية ، شارك فريق تطوير الواجهة الخلفية لدينا في تنفيذ وظائف أساسية معينة: على سبيل المثال ، تحويل الأموال. ومع ذلك ، كان لدينا الكثير من الخبرة في العمل مع البنوك عبر الإنترنت ، وقد دخل أحد مشاريعنا بحلول هذا الوقت في التصنيف الصناعي لشركة Markswebb ، لذلك قدمنا المساعدة المصرفية في التصميم المعماري - وتلقينا الضوء الأخضر.
هندسة معمارية
بالاشتراك مع مالك المنتج ، قررنا استخدام Spring Cloud ، الذي يوفر جميع الوظائف اللازمة لتنفيذ بنية الخدمات المصغرة: هذا هو اكتشاف الخدمة - Eureka ، و Api Gateway - Zuul ، وخادم التكوين ، وغير ذلك الكثير. تم اختيار OpenShift كنظام حاويات لصور Docker ، نظرًا لشحذ البنية التحتية للبنك لهذه الأداة.
قمنا أيضًا بتحليل ميزات "الصندوق" القديم التي يمكن أن تعقد عمل المستخدمين. كان أحد العوائق الرئيسية هو أن النظام يعمل بشكل متزامن من خلال ناقل البيانات ، وكل إجراء للمستخدم يتسبب في الوصول إلى الناقل. بسبب الأحمال الثقيلة ، غالبًا ما تفشل الحافلة ، وتوقف التطبيق بأكمله عن العمل. بالإضافة إلى ذلك ، كما هو الحال في العديد من المنتجات المصرفية القديمة ، تراكم الإرث - "الإرث" في شكل نظام ABS الأساسي القديم والثقيل ، والذي سيكون من الصعب والمكلف إعادة كتابته.
لقد اقترحنا عددًا من التحسينات:
- الإصدار
في السابق ، كان "الصندوق" يدعم إصدارًا واحدًا فقط ، ولكن في البنك الجديد عبر الإنترنت ، اقترحنا بنية جديدة تسمح لنا بدعم العديد من الإصدارات المختلفة في نفس الوقت واستبدالها إذا لزم الأمر.
نظام الإصدارات هو كما يلي: إذا تم تغيير الإصدار الثانوي في الخدمة ، فسيتم إعادة بناء الخدمة ونشرها تلقائيًا ، لتحل محل الإصدار القديم. إذا وضعنا الإصدار الرئيسي ، فسيتم نشر نسخة جديدة من الخدمة بالإصدار الجديد. وبالتالي ، فإن تطوير وظائف جديدة مع تغيير في واجهة برمجة التطبيقات للخدمة لا يؤثر على تطبيق الهاتف المحمول ، بينما يتم تقليل وقت الاختبار. مكّن هذا النظام من تقديم الدعم حتى للإصدارات القديمة من تطبيقات الهاتف المحمول إذا لم يكن لدى المستخدم فرصة للتحديث.
- عدم التزامن
لقد قمنا بتنفيذ مكتبة يمكن استخدامها في الخدمات التي تتطلب عملاً غير متزامن. تقوم المكتبة بتنفيذ المهام غير المتزامنة ، وهي مناسبة للاستخدام على أي عدد من نسخ الخدمات ، ولا تتداخل مع بعضها البعض. تتم المزامنة بين النسخ المختلفة باستخدام قائمة انتظار رسائل كافكا.
ساعد هذا الحل في تحسين استقرار التطبيق. أصبح تطبيق الهاتف المحمول الآن مستقلًا عن الحافلة ، فنحن نكرر البيانات اللازمة للمستخدم في خدماتنا ونحدثها في الخلفية عندما يكون هناك وصول إلى ناقل البنك. يتم وضع جميع إجراءات المستخدم في قائمة الانتظار للتنفيذ ، بمجرد أن تكون جاهزة ، يتم استلام إشعارات PUSH حول النتائج.
- التخزين المؤقت
لتسريع التطبيق وتقليل العبء على الموارد المصرفية الداخلية ، يتم تنظيم تخزين البيانات مؤقتًا باستخدام Redis. ذاكرة التخزين المؤقت هي KeyDB ، والتي تظهر نتائج جيدة ومتوافقة مع العديد من الأنظمة التي تستخدم Redis. لا يتم تخزين البيانات مؤقتًا بعد طلب المستخدم ، ولكن عند تغيير بيانات المستخدم ، مما يسمح بالوصول إليها بشكل مستقل عن الأنظمة المصرفية الداخلية.
ما الذي تغير في النظام
كما هو مذكور أعلاه ، في البنك القديم عبر الإنترنت ، تم تنفيذ الواجهة الخلفية في بنية متجانسة ، وتم نشر التطبيق على جهاز منفصل. مع زيادة الحمل ، كان لابد من نشر خوادم جديدة. عندما تعطل الخادم ، لم يعمل تطبيق الهاتف المحمول لبعض المستخدمين.
يستخدم الحل الجديد بنية الخدمات المصغرة ، والتي تتيح لك نشر أكبر عدد ممكن من نسخ الخدمات حسب الحاجة لوظيفة معينة. لقد أضفنا التخزين المؤقت للبيانات المستند إلى KeyDB ليس فقط لزيادة سرعة استرداد المعلومات ، ولكن أيضًا لتقليل الحمل على قاعدة البيانات.
دعونا نلقي نظرة على مثال للحصول على بيانات عن حسابات المستخدمين في البنية الجديدة. ينتقل طلب المستخدم من تطبيق الهاتف المحمول من خلال الموازن إلى البوابة ، والتي تتعرف على الخدمات التي سيتم إرسال الطلب إليها. بعد ذلك ، نصل إلى واجهة برمجة تطبيقات خدمة الحساب. تتحقق الخدمة أولاً مما إذا كانت هناك بيانات مستخدم فعلية في ذاكرة التخزين المؤقت. في حالة نجاحها ، تقوم بإرجاع البيانات ، وإلا فإنها ترسل طلبًا إلى خدمة الحساب الأوسط.
يمكن أن يحدث تحديث البيانات في الخدمة في حالات مختلفة. على سبيل المثال ، بناءً على طلب مباشر من المستخدم ، تنشئ الخدمة مهمة تحديث بيانات تعمل بشكل غير متزامن ، ويتم تحديث البيانات المستلمة من ESB. تستقبل الخدمة أيضًا رسائل من قائمة انتظار الرسائل وتستجيب لها. على سبيل المثال ، تتلقى خدمة رسالة حول تسجيل دخول مستخدم إلى تطبيق ما وتقوم على الفور بتحديث بيانات الحساب ، وتتلقى بيانات عن معاملات الحساب من خدمات أخرى ، وتقوم بتحديث بياناتها. وبالتالي ، يرى المستخدم دائمًا بيانات محدثة على حساباته.
من بين أهم التغييرات ما يلي:
- تحجيم المرونة
لزيادة التسامح مع الخطأ في النظام ، يتم توزيع الخدمات عبر خوادم مختلفة. يسمح لك هذا بالحفاظ على النظام في حالة جيدة في حالة سقوط أحدهم. للاستجابة في الوقت المناسب للمواقف غير القياسية ، قدمنا نظام مراقبة ، والذي ساعد ، إذا لزم الأمر ، على توسيع نطاق الخدمات في الوقت المحدد. لقد قمنا بتوصيل DevOps لتكوين CI / CD من البداية على خوادم العميل ، وإنشاء عمليات نشر ودعم للتطبيق المستقبلي على خوادم متعددة.
- تسريع الإصدارات بسبب تعيين الإصدار
في السابق ، عند تحديث إصدار الهاتف المحمول ، قام بعض المستخدمين بالفعل بتطبيق الإصدار الجديد ، بينما لم يفعل الآخرون ذلك ، ولكن عدد الأخير كان ضئيلاً. عند تطوير RBS جديد ، قمنا بتنفيذ الإصدار والقدرة على إصدار الإصدارات دون المخاطرة بتوقف التطبيق عن العمل لجزء كبير من العملاء. الآن ، عند تنفيذ الوظائف الفردية في الإصدارات الجديدة ، فإننا لا نكسر الإصدارات القديمة ، مما يعني أنه لا داعي للتراجع. ساعد هذا في تسريع وتيرة الإصدارات بما لا يقل عن 15 مرة - يتم الآن إصدار الإصدارات في المتوسط مرة واحدة في الأسبوع. يمكن لفرق Backend و Mobile العمل بشكل متزامن ومستقل على وظائف جديدة.
تلخيص لما سبق
في هذا المثال ، تحدثنا عن تصميم بنية الخدمات المصغرة لأحد البنوك ، والتي حلت محل الحل الأحادي "المعبأ". عمل فريق موزع في هذا المشروع ، والذي تضمن مطورين داخليين ومتعاقدين خارجيين.
عند تطوير بنك عبر الإنترنت ، حاولنا تنفيذ نفس نطاق الوظائف في التطبيق الجديد كما هو الحال في صندوق واحد ، وقمنا بتطويره تدريجياً.
من أجل منع اضطراب العملاء ، كان من الضروري إنشاء عملية خالية من المتاعب للتطبيق ، دون إخفاقات أو توقف ، وإصدار منتظم للإصدارات والتحديثات. تم تحقيق ذلك بفضل التحسينات في الهندسة المعمارية. على وجه الخصوص ، بعد تقليل الحمل على قاعدة البيانات ، حققنا توفرًا ثابتًا للتطبيق ، وبسبب الإصدار ، قمنا بتقليل وقت الاختبار ، وضمان إمكانية العمل المستقل على الوظائف وإصدار الإصدارات مرة واحدة في الأسبوع.
تعتمد بنية التطبيق على النمو الإضافي للمنتج وأدوات التطوير التي يستخدمها فريق العمل المصرفي الداخلي بحيث يمكن لمالك المنتج إجراء أي تحسينات على RBS بشكل مستقل. كانت شروط التطوير النشط لإصدار ألفا حوالي عام ، بعد 3 أشهر أخرى تم إصدار النسخة التجريبية لجميع المستخدمين.
نأمل أن يكون مخطط العمل الموصوف مفيدًا عند إنشاء منتجات تقنية مالية أخرى.
شكرآ لك على أهتمامك!