بوابة API لـ Web3: كيف يعزز APISIX قوة Hyperchain

نظرة عامة

كشركة رائدة عالميًا في توفير البنية التحتية لحلول سلاسل الكتل (Blockchain) على مستوى المؤسسات، تلتزم Hyperchain Technologies ببناء بنية تحتية مبتكرة وتمكين التطور الرقمي للمجتمع. خلال نموها السريع، واجهت Hyperchain العديد من المشكلات عند إنشاء منصة Hyperchain blockchain، كما يلي:

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

جربت Hyperchain استخدام Kong وNGINX، ولكن للأسف، لم تتمكن هذه الأدوات من تلبية سيناريوهات أعمال Hyperchain. ومع ذلك، بعد اعتماد Apache APISIX، تم حل جميع المشكلات المذكورة أعلاه، مما منح منصة Hyperchain blockchain حيوية لا تنتهي.

حول منصة Hyperchain Blockchain

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

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

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

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

تطبيق APISIX في منصة Hyperchain Blockchain

أدناه رسم تخطيطي لتطبيق APISIX في منصة Hyperchain blockchain. تقوم خدمة الخلفية بتسجيل معلومات الخدمة مع etcd وفقًا لخصائص أعمالها، ثم تسجيل الخدمة مع APISIX من خلال وحدة تسجيل المسار.

يعمل APISIX كنقطة دخول موحدة للخدمات الدقيقة الداخلية في النظام. يتم إرسال الطلبات الخارجية أولاً إلى APISIX؛ ثم تصل إلى طبقة الوصول عبر API بعد اجتياز المصادقة، وبعد ذلك تصل إلى الخدمات الأساسية عبر RPC (استدعاء الإجراءات البعيدة).

توجيه المسار

في بعض الأحيان، يُتوقع أن تكون واجهات برمجة التطبيقات (APIs) معروضة تحت نفس اسم النطاق. في هذه الحالة، يمكننا إضافة بعض البادئات إلى مسار API لنفس الخدمة، مثل /baas-core أو /baas-other. عندما يطلب العميل هذه الواجهات، تحتاج بوابة API إلى إزالة هذه البادئات المضافة ثم توجيه الطلب إلى خدمة الخلفية. يمكن لـ برنامج proxy-rewrite plugin في APISIX مساعدتنا في التعامل مع مثل هذه الحالات بسهولة.

على سبيل المثال: عند زيارة: http://apisix:8080/baas-{service}/api/v1/… يمكن توجيه الطلب إلى http://{service}/api/v1/… عن طريق كتابة تعبير عادي: ^/baas-core/(.*)$,/$1

إدارة حدود الحركة المرورية

يمكن للمستخدمين اختيار سلاسل الكتل التابعة وفقًا لاحتياجاتهم، ليس فقط تلك الخاصة بـ Hyperchain ولكن أيضًا IBM data Fabric، Baidu XuperChain، إلخ. لذلك، تحتاج Hyperchain إلى إدارة دورة الحياة لجميع سلاسل الكتل التابعة في النظام.

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

كل استدعاء لمكونات القابلة للتوصيل هو عملية تحتاج إلى تحديد، خاصة عندما يكون العدد كبيرًا. وبالتالي، يمكن لـ برنامج limit-req plugin في APISIX أن يكون مفيدًا في تقييد حركة المرور الداخلة والخارجة من المنصة لتأمين استقرارها.

يسمح برنامج limit-req plugin بتكوين مخصص حول المعدل والانفجار.

التحكم الأمني وإدارة الصلاحيات

للتكامل مع APISIX، طورت Hyperchain برنامجًا لحالات النشر الخاصة. غالبًا ما يفضل الطرف الأول استخدام خدمات المصادقة الخاصة به أو نظام حسابات الخدمة. عندما تزور حركة المرور الأمامية الموقع، ستمر أولاً عبر برنامج Access-auth plugin، ويمكنها الوصول إلى BFF (Backend for Frontend) فقط إذا اجتازت المصادقة.

وفقًا لمعايير Restful القياسية الثلاثة (معلومات المصادقة، مسار Restful، وأفعال HTTP مثل GET، POST، PUT، DELETE، PATCH، إلخ)، يتم تنفيذ مصادقة حساب-دور-صلاحية. إذا تمت المصادقة بنجاح، سيتم إرجاع معلومات المستخدم في الرأس؛ إذا لم تتم، سيتم إرجاع 403.

إعادة التحميل الساخن

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

لماذا ليس Kong؟

استخدمت Hyperchain Kong من قبل ولكن استبدلته أخيرًا بـ Apache APISIX بشكل رئيسي بسبب:

• تكلفة عالية للنشر والصيانة

  يحتاج تجمع Kong إلى التعاون مع قاعدة بيانات Postgresql ويتطلب مسؤول قاعدة بيانات معين لضمان التوفر العالي. نشر تجمع قاعدة بيانات Postgresql صعب نسبيًا في التنفيذ ويزيد من تكلفة التشغيل والصيانة لاحقًا.

• زيادة تعقيد النظام ومعدل الفشل

  تستخدم منصة Hyperchain blockchain قاعدة بيانات My SQL، مما يؤدي إلى وجود قاعدتي بيانات علاقيتين في النظام إذا تم اعتماد Kong، مما يجعل النظام أكثر تعقيدًا. كما يزيد من معدل الفشل في تحسين التوافق بين مجموعتي قواعد البيانات.

تطبيق APISIX في عقدة البلوكشين

توفير التكاليف على عناوين IP العامة

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

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

يدير APISIX جميع طلبات الزيارة ويوزع حركة المرور على عقد البلوكشين المقابلة. بهذه الطريقة، وفرت Hyperchain تكلفة عالية.

التحكم المريح في الأذونات

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

حاليًا، يمكن استخدام برنامج key-auth plugin في APISIX لحل هذه المشكلة بكفاءة. يمكن للمستخدمين المصرح لهم الوصول مباشرة إلى البلوكشين دون القلق بشأن تكوين الأذونات، حيث يوحد APISIX الطبقة الأساسية للسلسلة.

تحسين استقرار العقد من خلال التجميع

كما ذكرنا سابقًا، يتم زيارة العقد بشكل متكرر. يوجد تزامن عالي في معظم مستخدمي البنوك حيث يمكن أن يصل TPS (المعاملات في الثانية) إلى 40,000-50,000 مرة.

اتضح أن عقدة واحدة على البلوكشين معرضة للخطر لأن كل معاملة ستؤثر على العقدة التي تمت زيارتها.

نشرت Hyperchain Apache APISIX على K8s مع Horizontal Pod Autoscaler. نظرًا لأن APISIX يستخدم etcd مع قابلية توسع ديناميكية جيدة، يمكنه حل مشكلة تأثير حركة المرور على نقطة واحدة بشكل فعال.

دعم بروتوكولات متعددة

بروتوكولات السلاسل غير المتجانسة على منصة Hyperchain blockchain متنوعة، مثل بروتوكول HTTP، بروتوكول Websocket، بروتوكول gRPC، بروتوكول TCP، بروتوكول UDP، إلخ.

يدعم APISIX بروتوكولات متعددة، مما يتكيف بمرونة مع الطبقات الأساسية لسلاسل الكتل المختلفة، مما يقلل من تكاليف التطوير.

لماذا ليس NGINX؟

يبدو أن Hyperchain يمكنها استخدام NGINX لحل مشكلاتها. ومع ذلك، بعد التجربة، تخلت عنها لأن:

• غير مناسب للتوسع الديناميكي

  تحتاج Hyperchain إلى إضافة وحذف العقد في منصة البلوكشين بشكل متكرر، مما لا يمكن أن يكون فعالًا إلا بعد إعادة التشغيل، وهو أمر غير مريح للمطورين. بالإضافة إلى ذلك، يجب على المطورين كتابة كود قواعد معقدة للبرامج في ملف conf الخاص بـ NGINX.

• صعوبة في التجميع

  لا يدعم NGINX التجميع، وهو أمر معقد نسبيًا وغير ودود للمستخدمين.

• عدم دعم مباشر لـ TCP وUDP

  يمكن لـ NGINX فقط وكيل بروتوكول الطبقة السابعة بدلاً من بروتوكول الطبقة الرابعة ولا يمكنه دعم بروتوكولات TCP وUDP مباشرة. علاوة على ذلك، لا يتم تجميع الوحدة بشكل افتراضي، مما يتطلب معالجة إضافية.

• عدم وجود لوحة تحكم

  لا توجد واجهة مرئية لـ NGINX، مما يجعل من الصعب على المطورين والمشغلين إدارة العديد من العقد.

ملخص

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

نأمل أن يدعم APISIX المزيد من شركات البلوكشين للدخول في مرحلة تطوير أخرى. مرحبًا بكم لمعرفة المزيد عن Apache APISIX. يمكنكم الاتصال بنا عبر https://api7.ai/contact.