Snowball Finance تحول بنيتها النشطة-النشطة باستخدام APISIX

شارك Wenjie Shi، كبير مهندسي التطوير في فريق البنية التحتية في Snowball Finance، ممارسات Snowball Finance مع APISIX في Apache APISIX Summit ASIA 2022. تستند هذه المقالة إلى المشاركة، والتي تقدم كيفية استفادة Snowball Finance من Apache APISIX لتحقيق تطور في بنيتها الداخلية النشطة-النشطة، وبالتالي تحقيق إدارة أكثر مرونة للخدمات.

التحديات

• زيادة وحدات المصادقة المعقدة في SDK من تعقيد النظام والمخاطر الأمنية عند الوصول إلى مركز المستخدم عبر المناطق بسبب توفر البنية النشطة-النشطة فقط في وحدة خدمة السوق
• افتقار OpenResty إلى نظام مراقبة قوي لتحقيق المراقبة ويحتاج إلى نصوص مخصصة لتحقيق التوسع، مما يؤدي إلى تكاليف أعلى للتطوير والتشغيل
• مركز تسجيل NGINX غير مكتمل وبدون آلية نبض يقلل من التوفر والاستقرار، مما يجعله غير قادر على التعامل مع الأعطال بشكل فوري

الأهداف

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

النتائج

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

الخلفية

تأسست Snowball Finance في عام 2010 كمجتمع استثماري وأصبحت الآن منصة رائدة لإدارة التمويل عبر الإنترنت في الصين، تقدم خدمات متنوعة بما في ذلك المحتوى عالي الجودة، وخدمات السوق في الوقت الفعلي، وأدوات التداول، وإدارة الثروات للمستثمرين.

من بين هذه الخدمات، ترتبط خدمة السوق في الوقت الفعلي بعدة مصادر بيانات علوية وتقدم خدمات بيانات مستقرة للمستثمرين من خلال تدفق البيانات، التخزين، والتوزيع. لذلك، كانت خدمات السوق في الوقت الفعلي دائمًا مستهلكًا رئيسيًا للموارد في نظام Snowball Finance.

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

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

نقاط الألم في التحول النشط-النشط

في الفترة التي كانت تطبق فيها البنية المستقلة، كان يتم دخول حركة المستخدمين من خلال موازنة تحميل الخادم (SLB)، ثم تمريرها عبر البوابة لمعالجة المنطق المشترك البسيط، ثم يتم توجيهها إلى الخدمة الخلفية. كانت الخدمة الخلفية، من خلال وحدة مصادقة مدمجة، تبدأ مصادقة المستخدم مع مركز مستخدم Snowball باستخدام SDK وتستمر في المعالجة اللاحقة عند نجاح المصادقة.

في سيناريوهات الأعمال العملية، ظهرت بعض نقاط الألم تدريجيًا.

1. وحدات مصادقة SDK المعقدة

عند تنفيذ التحول النشط-النشط، لا يمكن نشر وحدات الخدمات الصغيرة وبدء تشغيلها بشكل متزامن. عندما تم إطلاق خدمة سوق Snowball Finance على السحابة لأول مرة، ولكن لم يتم دعم مركز المستخدم على السحابة بعد، حدثت مكالمات عبر مراكز البيانات. وفقًا لإحصائيات مركز المستخدم، وصلت مكالمات RPC إلى حوالي عشرات المليارات يوميًا، ويمكن أن تصل الذروة إلى 50,000 QPS، مما قد يؤدي إلى تأخير أعلى.

في الوقت نفسه، كان منطق المصادقة في Snowball Finance معقدًا. بالإضافة إلى بروتوكولات OAuth2.0/JWT، كان يجب مراعاة العديد من العوامل، مثل إصدارات العميل وتطبيقات Snowball Finance المتعددة. بالإضافة إلى ذلك، كانت وحدة المصادقة مدمجة في الخدمة مما جعل الترقية أكثر صعوبة.

2. وظائف محدودة لـ OpenResty

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

3. الاعتماد على مركز التسجيل المطور ذاتيًا

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

اختيار تقنية بوابة API

بناءً على نقاط الألم التي ظهرت تدريجيًا في سيناريوهات الأعمال العملية، بدأ فريق البنية التحتية في Snowball البحث عن منتجات البوابة.

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

تأمل Snowball Finance أن تفي بوابة API الجديدة بالمتطلبات التالية:

• أداء عالي
• قابلية توسع قوية
• دعم بروتوكولات متعددة
• تكلفة منخفضة لمصادقة البوابة

فيما يلي قائمة مفصلة باختيار تقنية بوابة API بين OpenResty، Spring Gateway، Kong، و APISIX.

البوابة	المزايا	العيوب	تكلفة التشغيل والصيانة	التوفر
OpenResty	قابلية تخصيص عالية واستقرار	مراقبة ضعيفة	عالية	عالية
Spring Gateway	ودية لتطوير Java	مستوى الأداء لا يلبي المتطلبات	متوسطة	متوسطة
Kong	قوي وغني بالوظائف	قاعدة بيانات PostgreSQL أحادية النقطة	منخفضة	متوسطة
APISIX	سحابية تدعم لغات برمجة متعددة ولديها قابلية توسع قوية	/	منخفضة	عالية

بعد النظر في المطالب الداخلية ومقارنة منتجات البوابات الشائعة في السوق، اختارت Snowball Finance في النهاية Apache APISIX للبنية اللاحقة.

الممارسات بناءً على Apache APISIX

البنية المعدلة

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

قامت Snowball Finance بإجراء التعديلات التالية بناءً على APISIX:

• توحيد وحدة المصادقة في طبقة الوكيل واستخدام APISIX للمصادقة الموحدة. بالنسبة لأنواع JWT، يمكن استخدام إضافة jwt-auth في APISIX للمصادقة المحلية مباشرة.
• التوافق مع OAuth 2.0، واستخدام APISIX للاتصال بمركز مستخدم Snowball Finance للمعالجة.
• الاتصال بمركز تسجيل خدمة RPC الخلفية في Snowball Finance لاستخدام خدماتها الخلفية للمصادقة عند فشل مصادقة JWT.

سيناريوهات التطبيق

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

السيناريو 1: مصادقة البوابة

كما ذكرنا سابقًا، لم يكن لدى بنية Snowball Finance السابقة طريقة موحدة للمصادقة. كانت إحدى الطرق تعتمد على جانب التطبيق الداخلي، الذي استخدم SDK للاتصال بمركز المستخدم للمصادقة، بينما استخدمت الأخرى مصادقة JWT. عندما تتعايش هاتان الطريقتان للمصادقة، تسبب ذلك في مشكلات في قابلية التوسع والصيانة.

1. بعد دمج APISIX كبوابة، استخدمت Snowball Finance طبقة بوابة APISIX لإدارة المصادقة بشكل موحد. تم استبدال طريقة مصادقة JWT الأصلية بإضافة jwt-auth الرسمية. تكوين واستخدام إضافة jwt-auth بسيط نسبيًا: فقط عن طريق تكوين المعلومات ذات الصلة مثل المسارات والمنبع في لوحة التحكم، سيتم تمكين الإضافة.
2. استخدمت Snowball Finance إضافة grpc-transcode لوكيل مكالمات خدمة المصادقة للتعامل مع طريقة المصادقة السابقة المتعلقة بـ OAuth 2.0.

نظرت Snowball Finance داخليًا في الحلول الثلاثة التالية لاستدعاء gRPC لتنفيذ المصادقة:

• الحل 1: استخدام Lua لاستدعاء gRPC مباشرة. نظرًا لأن هذا الحل يتطلب النظر في التطبيقات ذات الصلة مثل موازنة التحميل والمنبع الديناميكي، ستكون العملية أكثر إزعاجًا، لذلك تم التخلي عنه.
• الحل 2: استخدام Lua coroutine لاستدعاء منطق Golang. تخلت Snowball Finance عن هذه الطريقة بسبب نقص الخبرة العملية المقابلة.
• الحل 3: استخدام Lua لإجراء مكالمات HTTP، ويتم تنفيذ واجهة gRPC باستخدام إضافة grpc-transcode في APISIX. بفضل التكرارات السريعة لتحسين الإضافات في مجتمع APISIX، اختارت Snowball Finance أخيرًا هذا الخيار لتنفيذ مكالمات gRPC.

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

السيناريو 2: المراقبة متعددة الأبعاد تحت المراقبة

من الضروري مراقبة العديد من المقاييس بعد إطلاق المواقع في Snowball Finance، مع التركيز بشكل رئيسي على الأجزاء الثلاثة التالية:

• حالة اتصال NGINX وحجم حركة المرور الواردة/الصادرة
• معدل رمز حالة الخطأ HTTP (يستخدم لاستكشاف الأخطاء وإصلاحها في الخدمة أو المنبع/المصب)
• زمن انتقال طلب APISIX (الوقت المستغرق في تنفيذ المنطق عند توجيه APISIX للطلب)

على سبيل المثال، في بعض الحالات، يظهر زمن انتقال APISIX مرتفعًا (كما هو موضح في الشكل أدناه)، وهو مرتبط بمنطق حساب زمن الانتقال. حاليًا، المنطق هو الوقت المستغرق لطلب HTTP واحد على NGINX مطروحًا منه زمن انتقال هذا الطلب الموجه إلى المنبع. الفرق بين الوقتين المستغرقين هو مقاييس زمن انتقال APISIX.

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

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

السيناريو 3: توسيع مركز تسجيل ZooKeeper

في Snowball Finance، يتم تسجيل مكالمات gRPC واكتشافها بناءً على مركز تسجيل Zookeeper. في عملية تنفيذ المصادقة، عندما تفشل مصادقة JWT المحلية، تحتاج بوابة API إلى الوصول إلى خدمة gRPC في مركز مستخدم Snowball Finance لـ المصادقة، مما يتطلب من بوابة API الحصول على قائمة عناوين خدمة gRPC الخلفية من مركز التسجيل.

يمكن لإضافة apisix-seed الرسمية في APISIX دمج ZooKeeper لاكتشاف الخدمات. قامت Snowball Finance بإجراء بعض التخصيصات التي تكون أكثر تحديدًا لأعمالها الخاصة.

التنفيذ المحدد يكون بشكل رئيسي على عقدة محتوى في APISIX. عند بدء عملية Worker، تقوم بالاستطلاع على مجموعة ZK-Rest كما في الشكل أدناه، ثم تقوم بسحب بيانات المصدر ومعلومات الخدمة بأكملها بشكل دوري، وتحديثها في ذاكرة التخزين المؤقت المحلية لعملية Worker لتحديث قوائم الخدمات.

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

الخلاصة والتوقعات

حاليًا، يعمل Apache APISIX بشكل جيد كطبقة بوابة داخل Snowball Finance. على وجه التحديد:

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

في الاستخدام اللاحق، تخطط Snowball Finance أيضًا إلى:

• تطبيق APISIX Ingress Controller على مجموعة K8s.
• استخدام إضافة grpc-transcode لتحويل بروتوكول HTTP/gRPC لتحقيق واجهة خلفية موحدة.
• استخدام إضافة traffic-spilt لوضع علامات على حركة المرور، والاتصال بمركز تسجيل Nacos، وتنفيذ الإصدار التدريجي وإدارة الخدمات الأخرى.

في الخطط اللاحقة، سيتم استخدام Apache APISIX لاستبدال OpenResty الحالي وتحقيق إدارة حركة المرور الشمالية-الجنوبية الكاملة.