تخلَّ عن Spring Cloud Gateway! كيف تستخدم Huanbei، تطبيق Fintech، Apache APISIX

الحب والكراهية لجافا

لماذا تفضل الأنظمة المالية جافا

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

في السنوات الـ15 إلى الـ20 الماضية، اختارت العديد من الأنظمة المالية جافا كتقنية أساسية. بعد بعض التحقيقات، توصلنا إلى المزايا التالية لجافا:

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

وضع جافا في عصر الحوسبة السحابية الأصلية

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

أولاً، أداء جافا ضعيف؛ يمكنك فهم سبب قولي هذا بمقارنة جافا مع تقنيات مرتبطة بـC.

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

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

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

لماذا اختارت هوانبي APISIX

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

Spring Cloud Gateway هو بوابة تهدف إلى إدارة أفضل للخدمات المصغرة تحت نظام Spring Cloud البيئي. Spring Cloud Gateway هو بوابة API جيدة للشركات التي تستخدم جافا كلغة تطوير أساسية. ومع ذلك، في التحديث الأخير لبوابة API، تخلت هوانبي عن Spring Cloud Gateway التي كانت تستخدمها لفترة طويلة وبدأت في استخدام Apache APISIX.

الاختلافات المعمارية بين Spring Cloud Gateway وAPISIX

استخدمت هوانبي ثلاث أنظمة مختلفة لبوابة API قبل اعتماد APISIX. استخدمت هوانبي Spring Cloud Gateway كبوابة لأنظمة التشغيل والخروج، واستخدمت OpenResty كبوابة لنظام الأعمال.

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

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

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

التطبيق العملي لـ APISIX

كان على هوانبي تعديل تكوين APISIX في سيناريوهات الأعمال الحقيقية حيث لم تتمكن من استخدام Apache APISIX مباشرة بسبب وجود أطر عمل بوابات متعددة داخليًا.

بناء ونشر APISIX

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

لم يستخدم تغليف الأكواد المخصصة lua_package_path لتحديد دليل الأكواد؛ بدلاً من ذلك، قام بتغطية الصورة الافتراضية apisix تحت دليل الأكواد المصدر إذا كان هناك ملف بنفس الاسم. يظهر Dockerfile أدناه:

FROM registry.xxx.net:5001/apisix-shuhe:v1.5
ENV APP_NAME={{APP_NAME}}
COPY {{PRODUCT_FILE}} /tmp/deploy2/artifact.tar.gz

RUN mkdir /tmp/deploy/ && tar -xf /tmp/deploy2/artifact.tar.gz -C /tmp/deploy/ && \
cp -R /tmp/deploy/apisix/ /usr/local/apisix/ && \
cp /tmp/deploy/bin/apisix /usr/bin/apisix && \
cp /tmp/deploy/conf/apisix-$APP_NAME.yaml /usr/local/apisix/conf/apisix.yaml && \
cp /tmp/deploy/conf/config-$APP_NAME.yaml /usr/local/apisix/conf/config.yaml && \
set -x && \
bin='#! /usr/local/openresty/luajit/bin/luajit\npackage.path = "/usr/local/apisix/?.lua;" .. package.path' && \
sed -i "1s@.*@$bin@" /usr/bin/apisix && \
rm -rf /tmp/*

يتم تخزين سجل APISIX محليًا (يمكن جمعه بواسطة Syslog أو إضافات أخرى)؛ يمكننا تعديل قالب تكوين NGINX والتحقق من الملف الشخصي المستخدم لتحديد ما إذا كنا نريد تخزين السجلات محليًا أو تخزينها في FLUENTD عبر Syslog. نحتاج أيضًا إلى استبدال متغير FLUENTD_HOST عند بناء الصور كما هو موضح أدناه:

{% **if** gw_profile and **string**.find( gw_profile,'local') then %}
access_log logs/access.**log** main;error_log logs/
**error**.**log** warn;
{%else%}
access_log syslog:server=${FLUENTD_HOST}:5141 json_format;
error_log syslog:server=${FLUENTD_HOST}:5142 warn;
{%end%}

في قالب تكوين NGINX، قامت هوانبي ليس فقط بتعديل تخزين السجلات ولكن أيضًا بإضافة متغيرات بيئة ENV و lua_shared_dicts في الحلقات وإصلاح بعض معلمات تحسين NGINX.

تقوم هوانبي بفصل حركة المرور بناءً على احتياجات الأعمال المختلفة وإنشاء بوابات متعددة ذات وظائف متشابهة. لذلك، تستخدم هوانبي خطة "مصدر واحد ولكن تطبيقات بوابات متعددة" داخليًا. أولاً، تقوم هوانبي بتكوين ملف config-xxx.yaml لكل بوابة باستخدام وظيفة الملف الشخصي، ثم يمكنها بناء صور Docker للبوابات المختلفة بناءً على اسم التطبيق أثناء بناء الصور عبر منصة DevOps.

الإضافات المخصصة على مستوى المؤسسة

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

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

في سيناريوهات الأعمال، هناك دائمًا احتياجات لا يمكن للإضافات الأصلية تلبيتها، مما يتطلب تطويرًا مخصصًا. يوفر APISIX العديد من الأدوات التي يمكن أن تساعد في تخصيص الإضافات الأصلية بسهولة. يوضح الجدول التالي بعض الإضافات المخصصة التي تم تطويرها بناءً على APISIX داخل هوانبي:

الإصدار التدريجي للبوابة

في السابق، استخدمت هوانبي OpenShift كحاويات K8s (تم ترقيتها حاليًا إلى مجموعة ACK)، وتم بناء Ingress باستخدام Haproxy.

نظرًا لأن Haproxy الخاص بـ Ingress K8s للشبكة العامة لا يمكنه تقسيم حركة المرور لنطاق واحد إلى مسارين مختلفين في Namespace، نحتاج إلى النظر في نشر البوابة الجديدة في نفس Namespace بدلاً من البوابة القديمة. بمعنى آخر، سيكون لكل نطاق مسار خدمة متعدد، ويمكننا التحكم في حركة المرور للبوابة الجديدة والقديمة عن طريق تخصيص نسب مختلفة من إجمالي حركة المرور.

يظهر تدفق التنفيذ الفعلي أدناه، حيث سيتم إضافة المجموعات c وd لنشر بوابة جديدة تحت Namespace البوابة القديمة، ويمكن التحكم في نسبة حركة المرور للبوابة الجديدة والقديمة.

العوامل المتعلقة بجافا في البوابة

سيختار العديد من مطوري جافا Spring Cloud في الهندسة المعمارية للخدمات المصغرة حيث أن Spring Cloud يمكن أن يدعم جافا بسلاسة، ويقوم بتضمين مكتبات الفئات في الأكواد المصدر. ومع ذلك، تظهر صعوبات في الترقية في الممارسة. على سبيل المثال، إذا كان الفريق يحتاج إلى الحفاظ على مكتبات فئات متعددة، وهناك 10 لغات مختلفة مع 10 إصدارات مختلفة، فإن هذا الفريق يحتاج إلى الحفاظ على 100 مكتبة فئات مختلفة.

الآن، يمكننا بسهولة استخدام وكيل (بوابة API) لحل مشاكل الإصدارات المتعددة واللغات المتعددة. إذن ما هي الفوائد للشركات التي تستخدم تقنية جافا وتختار APISIX كبوابة API؟ نستنتج بناءً على جانبين من الخبرة العملية لهوانبي.

بالنسبة للشركة

1. وظائف وأداء رائعين

يمكن أن تصل QPS لـ APISIX إلى 80k إذا استخدمت هوانبي آلات افتراضية رباعية النوى بدون أي إضافات لاختبار الضغط على APISIX. علاوة على ذلك، يحل APISIX بشكل مثالي مشكلة أداء Spring Cloud Gateway عند استقبال حركة المرور من المستهلكين، وتحسن أدائه بنسبة 30% في بيئة الإنتاج مقارنة بالبوابات السابقة.

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

2. تقليل تكاليف الأعمال

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

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

بالنسبة للمطورين

1. تلبية متطلبات الأعمال

يجب أن تخدم جميع البرمجيات أو التقنيات المستخدمة في الأعمال الاحتياجات. ومع ذلك، من نتائج الاختبارات العملية والبحث، يتمتع APISIX بثبات ومراقبة وقابلية تمدد أفضل.

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

2. تقليل رسوم الصيانة

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

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

الخلاصة: اتجاهات تطور الصناعة المالية

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

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

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

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

سيقوم الموظفون الفنيون فقط بالتفكير في تكلفة هذه التقنية الجديدة.