تحويل عملاق إدارة الأموال باستخدام APISIX

نظرة عامة

حول إنفيسكو جريت وول

إنفيسكو جريت وول لإدارة الصناديق المحدودة ("IGW") هي شركة صينية-أمريكية لإدارة الصناديق، تتمتع بقدرات استثمارية متعددة الأصول وخبرة رائدة في الأسهم. تشمل أعمال الشركة الرئيسية الاستثمار الكمي، الدخل النشط، والدخل الثابت. تبلغ أصول IGW تحت الإدارة أكثر من 850 مليار دولار أمريكي، وتقدم خدمات لأكثر من 60 مليون مستثمر.

تركز IGW بشكل أساسي على إدارة الأصول، وتوفر مجموعة متنوعة من استراتيجيات الاستثمار التي تشمل فئات أصول متعددة مثل الأسهم، الدخل الثابت، والاستراتيجيات الكمية.

التحديات

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

النتائج

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

الخلفية

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

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

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

تماشيًا مع استراتيجية السحابة في التكنولوجيا المالية والتحول الرقمي، بدأت IGW مشروع هجرتها إلى السحابة.

لماذا اختارت IGW APISIX

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

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

لذلك، مع مراعاة هذه النقاط الأربع، أجرى الفريق الفني في IGW مقارنة شاملة بين APISIX وKong، وهما بوابات API شائعة ومعترف بها على نطاق واسع في السوق:

• الإطار الفني: تم تطوير كل من APISIX وKong بناءً على OpenResty. فيما يتعلق بمركز الإعدادات، يعتمد APISIX على etcd، بينما يختار Kong PostgreSQL. يتميز APISIX كبوابة موزعة سحابية بسبب طبيعة etcd السحابية وميزات حالة APISIX. ومع ذلك، قد يؤدي اختيار Kong لمركز الإعدادات إلى إدخال مشاكل نقطة فشل واحدة، مما يتطلب دعمًا إضافيًا للبنية التحتية لضمان التوفر العالي.

• نشاط المجتمع: يتمتع كل من APISIX وKong بمجتمع نشط بمتوسط 20 عملية إيداع يوميًا في مستودعاتهم.

• الإضافات: يحتوي APISIX على 80+ إضافة ووثيقة واحدة فقط لكل إضافة؛ يحتوي Kong على 30+ إضافة و4-5 وثائق لكل إضافة؛ 100+ سطر برمجي لكل إضافة في APISIX و300+ في Kong.

• قابلية التوسع: يدعم APISIX العديد من لغات البرمجة ويدعم أيضًا WebAssembly. بينما يدعم Kong فقط استخدام Lua لكتابة الإضافات.

• إعادة التحميل الساخن: هذا ما يركز عليه الفريق. يدعم APISIX إعادة التحميل الساخن على مستوى المللي ثانية عند تمكين أو تعطيل الإضافات، وعند إضافة إضافات جديدة (مثل الإضافات المخصصة). كما يدعم APISIX التعديل الديناميكي لمعلمات البوابة. ومع ذلك، لم يكن Kong يدعم هذه الميزة عندما أجرت IGW اختيار التكنولوجيا.

• القدرة على المراقبة: يدعم كل من APISIX وKong OpenTelemetry، ولكن يمكن لـ APISIX أيضًا الاتصال بـ Elasticsearch، Prometheus، وSkyWalking. لم يكن Kong يدعم SkyWalking عندما أجرت IGW اختيار التكنولوجيا.

بناءً على المخاوف المذكورة أعلاه ونقاط المقارنة، اختار الفريق الفني في IGW أخيرًا APISIX كبوابة API.

سيناريوهات المستخدم والحلول لـ IGW

مقدمة عن بنية نظام IGW

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

يوضح الرسم البياني أعلاه بنية نظام IGW. تستخدم طبقة تجميع أمان البوابة إطارات عمل متعددة مثل Zuul، Spring Cloud Gateway، Kong، وNGINX. لم تكن إدارة البنية موحدة وكانت الإدارة مرهقة نسبيًا.

الحل

من أجل حل هذه التحديات، ركزت IGW على تحويل تجميعات البوابة إلى APISIX. نظرًا لأن APISIX يتم نشره على تجمعات Kubernetes، فإنه يسمح بالإدارة الموحدة لواجهات برمجة التطبيقات (APIs) من خلال YAML بطريقة تصريحية. بالإضافة إلى ذلك، يراقب APISIX Ingress Controller التغييرات في موارد Kubernetes تلقائيًا، مما يتيح المزامنة الفورية لإعدادات APISIX، بما في ذلك ApisixRoute، SSL، والمزيد.

أدناه يظهر تسلسل مزامنة المسارات لـ IGW بعد استخدام APISIX.

سيناريوهات المستخدم

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

التوجيه الذكي الفعال

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

بعد الاختبار في البيئة، حتى إذا تم حذف البيانات، فإن Kubernetes قادر على المزامنة السريعة والتلقائية مع APISIX، مما يحل مشكلة فقدان البيانات.

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

تعزيز المصادقة

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

قبل إدخال البوابة الموحدة، تم فك تشفير شهادات HTTPS للخدمات في نقطة النهاية عالية التوفر (HA)، مما زاد من التعقيد، عبء العمل، والمخاطر الأمنية.

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

من خلال الانتقال إلى APISIX، يمكن التخفيف من هذه العيوب. يمكن لـ APISIX التعامل مع إنهاء HTTPS، تحميل شهادات SSL بشكل ديناميكي، وتوفير إدارة مركزية وآمنة للمهام الأمنية، مما يحسن أداء النظام العام ومرونته.

ما وراء المراقبة

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

لذلك، كان الفريق الفني في IGW يهدف إلى دمج العديد من الإضافات التي توفرها APISIX بسرعة، مثل مراقبة السجلات والتتبع، لتعزيز قدرات المراقبة.

علاوة على ذلك، كان الفريق يبحث بنشاط ويستفيد من Apache SkyWalking للتتبع الموزع، Prometheus لأغراض المراقبة، وELK لجمع السجلات بكفاءة. بشكل مفاجئ، يدعم APISIX جميع هذه الإضافات وبالتالي أثبت أنه الحل المثالي الذي يلبي تمامًا توقعات ومتطلبات الفريق الفني في IGW، مما جعله الخيار المفضل.

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

إتقان التحكم في حركة المرور

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

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

بناءً على سياسة الوزن، يتم توفير خدمات الآلات الافتراضية والحاويات للخارج بشكل متوازي. على سبيل المثال، 90% من حركة المرور تصل إلى خدمة الآلة الافتراضية و10% تصل إلى خدمة السحابة للتحقق من استقرار خدمة السحابة. حاليًا، تم تكوين بيئة الإنتاج في IGW مع إصدار تدريجي يعتمد على الوزن.

الإنجازات بعد استخدام APISIX

بناء بوابة API موحدة

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

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

تحسين استقرار نشر المسارات والخدمات

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

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

إعادة التحميل الساخن تعزز الأداء وزمن التشغيل

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

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

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

الخلاصة

قدم الفريق الفني في IGW أيضًا توقعات لتعزيز وظائف، الموثوقية، وأداء APISIX بشكل أكبر للتشغيل السلس في المستقبل.

أدى التنفيذ الناجح لـ APISIX في إنفيسكو جريت وول إلى تحقيق فوائد كبيرة ونتائج إيجابية. مع APISIX، حقق فريق IGW إطار بوابة API موحد، مما أدى إلى تبسيط العمليات وتقليل التكاليف. كما أدى التكامل إلى تعزيز استقرار المسارات والخدمات، مما أدى إلى تحسين الأداء وتقليل الاضطرابات.

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