استراتيجيات إصدار API مع API Gateway
December 22, 2022
بمجرد أن تقوم بفصل النشر والإصدار بشكل كافٍ، تكون الخطوة التالية هي اختيار آليات للتحكم في الإصدار التدريجي للميزات. من الضروري اختيار استراتيجية إصدار تسمح لك بتقليل المخاطر في الإنتاج. لأنه بغض النظر عن مدى اختبارك لإصدار جديد من واجهة برمجة التطبيقات (API) قبل الإصدار، فإن الاختبار الفعلي يحدث عندما تضعها أخيرًا أمام العملاء.
يمكننا تحقيق تقليل هذا الخطر من خلال إجراء اختبار أو تجربة مع جزء صغير من حركة المرور والتحقق من النتيجة. عندما تكون النتيجة ناجحة، يتم تشغيل الإصدار لجميع حركة المرور. هناك استراتيجيات محددة تناسب سيناريوهات معينة بشكل أفضل من غيرها وتتطلب درجات متفاوتة من الخدمات والبنية التحتية الإضافية. في هذا المنشور، سنستكشف 3 استراتيجيات شائعة لإصدار واجهات برمجة التطبيقات التي تستخدم بوابة API في الوقت الحالي.
لماذا نستخدم بوابة API في نشر واجهات برمجة التطبيقات
إحدى فوائد الانتقال إلى بنية قائمة على واجهات برمجة التطبيقات هي أننا نستطيع التكرار بسرعة ونشر تغييرات جديدة على خدماتنا. لدينا أيضًا مفهوم حركة المرور والتوجيه الذي تم تأسيسه مع بوابة API للجزء الحديث من البنية. توفر بوابة API مراحل تسمح لك بالحصول على واجهات برمجة تطبيقات متعددة منشورة خلف نفس البوابة وهي قادرة على التحديثات في المكان دون توقف. استخدام بوابة API يتيح لك الاستفادة من العديد من ميزات إدارة واجهات برمجة التطبيقات الخاصة بالخدمة، مثل المصادقة، والحد من المعدل، والمراقبة (المقاييس المهمة لواجهات برمجة التطبيقات)، إصدارات متعددة لواجهات برمجة التطبيقات، وإدارة نشر المراحل (نشر واجهة برمجة التطبيقات في مراحل متعددة مثل التطوير، الاختبار، المرحلة، والإنتاج).
تقدم بوابات API مفتوحة المصدر (Apache APISIX و Traefik)، وشبكة الخدمات (Istio و Linkerd) حلولًا قادرة على تقسيم حركة المرور وتنفيذ وظائف مثل الإصدار التدريجي (Canary Release) والنشر الأزرق-الأخضر (Blue-Green). مع الاختبار التدريجي، يمكنك إجراء فحص دقيق لإصدار جديد من واجهة برمجة التطبيقات عن طريق اختيار جزء صغير فقط من قاعدة مستخدميك. سنغطي الإصدار التدريجي في القسم التالي.
الإصدار التدريجي (Canary Release)
الإصدار التدريجي يقدم إصدارًا جديدًا من واجهة برمجة التطبيقات ويوجه نسبة صغيرة من حركة المرور إلى الإصدار الجديد. في بوابات API، يجعل تقسيم حركة المرور من الممكن التحول التدريجي أو نقل حركة المرور من إصدار واحد من الخدمة المستهدفة إلى آخر. على سبيل المثال، يمكن نشر إصدار جديد، v1.1، من الخدمة جنبًا إلى جنب مع الإصدار الأصلي، v1.0. يتيح لك التحول في حركة المرور إجراء اختبار تدريجي أو إصدار خدمتك الجديدة عن طريق توجيه نسبة صغيرة فقط من حركة مرور المستخدمين، لنقل 1%، إلى v1.1، ثم تحويل كل حركة المرور إلى الخدمة الجديدة بمرور الوقت.
هذا يسمح لك بمراقبة الخدمة الجديدة، والبحث عن المشاكل التقنية، مثل زيادة زمن الوصول أو معدلات الخطأ، والبحث عن التأثير التجاري المطلوب، مثل زيادة مؤشرات الأداء الرئيسية مثل نسبة تحويل العملاء أو متوسط قيمة الدفع في التسوق. تقسيم حركة المرور يتيح لك إجراء اختبارات A/B أو اختبارات متعددة المتغيرات عن طريق تقسيم حركة المرور الموجهة لخدمة مستهدفة بين إصدارات متعددة من الخدمة. على سبيل المثال، يمكنك تقسيم حركة المرور 50/50 بين إصدارات v1.0 و v1.1 من الخدمة المستهدفة ومعرفة أيها يؤدي بشكل أفضل خلال فترة زمنية محددة. تعرف على المزيد حول ميزة تقسيم حركة المرور في Apache APISIX Ingress Controller.
عندما يكون ذلك مناسبًا، يعتبر الإصدار التدريجي خيارًا ممتازًا، حيث يتم التحكم بشكل كبير في نسبة حركة المرور المعرضة للإصدار الجديد. المقايضة هي أن النظام يجب أن يكون لديه مراقبة جيدة في مكانها لتكون قادرة على تحديد المشكلة بسرعة والتراجع إذا لزم الأمر (والتي يمكن أن تكون مؤتمتة). يوضح لك هذا الدليل كيفية استخدام Apache APISIX و Flagger لتنفيذ حل الإصدار التدريجي بسرعة.
انعكاس حركة المرور (Traffic Mirroring)
بالإضافة إلى استخدام تقسيم حركة المرور لإجراء التجارب، يمكنك أيضًا استخدام انعكاس حركة المرور لنسخ أو تكرار حركة المرور وإرسالها إلى موقع إضافي أو سلسلة من المواقع. غالبًا مع انعكاس حركة المرور، لا يتم إرجاع نتائج الطلبات المكررة إلى الخدمة التي أطلقتها أو المستخدم النهائي. بدلاً من ذلك، يتم تقييم الاستجابات خارج النطاق للتأكد من صحتها، مثل مقارنة النتائج التي تم إنشاؤها بواسطة خدمة معاد تصميمها وخدمة موجودة، أو يتم مراقبة مجموعة من الخصائص التشغيلية أثناء تعامل إصدار جديد من الخدمة مع الطلب، مثل زمن الاستجابة أو وحدة المعالجة المركزية المطلوبة.
يتيح لك استخدام انعكاس حركة المرور "إصدار مظلم" للخدمات، حيث يتم إبقاء المستخدم في الظلام حول الإصدار الجديد ولكن يمكنك مراقبة التأثير المطلوب داخليًا.
أصبح تنفيذ انعكاس حركة المرور عند حواف الأنظمة شائعًا بشكل متزايد على مر السنين. يوفر APISIX البرنامج المساعد proxy-mirror لانعكاس طلبات العملاء. يقوم بتكرار حركة المرور الحقيقية عبر الإنترنت إلى خدمة الانعكاس وتمكين تحليل محدد لحركة المرور عبر الإنترنت أو محتوى الطلب دون مقاطعة الخدمة عبر الإنترنت.
النشر الأزرق-الأخضر (Blue-Green)
عادة ما يتم تنفيذ النشر الأزرق-الأخضر في نقطة في البنية التي تستخدم جهاز توجيه أو بوابة أو موازن حمل، خلفها يوجد بيئة زرقاء كاملة وبيئة خضراء. تمثل البيئة الزرقاء الحالية البيئة الحية الحالية، وتمثل البيئة الخضراء الإصدار التالي من المكدس. يتم فحص البيئة الخضراء قبل التبديل إلى حركة المرور الحية، وعند الانتقال يتم تحويل حركة المرور من الأزرق إلى الأخضر. البيئة الزرقاء الآن "مغلقة" ولكن إذا تم اكتشاف مشكلة، فإن التراجع سريع. التغيير التالي سيكون من الأخضر إلى الأزرق، يتأرجح من الإصدار الأول فصاعدًا.
يعمل النشر الأزرق-الأخضر بشكل جيد بسبب بساطته وهو أحد خيارات النشر الأفضل للخدمات المترابطة. كما أنه أسهل في إدارة الخدمات المستمرة، على الرغم من أنك لا تزال بحاجة إلى الحذر في حالة التراجع. كما أنه يتطلب ضعف عدد الموارد لتكون قادرة على التشغيل البارد بالتوازي مع البيئة النشطة حاليًا.
إدارة حركة المرور مع Argo Rollouts
الاستراتيجيات التي تمت مناقشتها تضيف الكثير من القيمة، ولكن عملية النشر نفسها هي مهمة لا تريد أن تضطر إلى إدارتها يدويًا. هذا هو المكان الذي تكون فيه أداة مثل Argo Rollouts ذات قيمة لإظهار بعض المخاوف التي تمت مناقشتها عمليًا.
باستخدام Argo، يمكنك تحديد Rollout CRD (تعريف مورد مخصص) الذي يمثل الاستراتيجية التي يمكنك اتخاذها لنشر إصدار جديد من واجهة برمجة التطبيقات الخاصة بك. يسمح CRD لـ Argo بتمديد واجهة برمجة تطبيقات Kubernetes لدعم سلوك النشر. CRDs هي نمط شائع مع Kubernetes، وتسمح للمستخدم بالتفاعل مع واجهة برمجة تطبيقات واحدة مع التمديد لدعم ميزات مختلفة.
يمكنك استخدام Apache APISIX و Apache APISIX Ingress Controller لإدارة حركة المرور مع Argo Rollouts. يوضح لك هذا الدليل كيفية دمج ApisixRoute مع Argo Rollouts باستخدامه كموازن حمل دائري مرجح.
ملخص
مع صعود نهج التسليم التدريجي، والمتطلبات المتقدمة داخل التسليم المستمر قبل ذلك، فإن القدرة على فصل النشر والإصدار للخدمة (وواجهة برمجة التطبيقات المقابلة) هي تقنية قوية. القدرة على إصدار الخدمات بشكل تدريجي والاستفادة من ميزات تقسيم حركة المرور وانعكاسها في بوابة API يمكن أن توفر ميزة تنافسية لعملك في كل من تخفيف مخاطر الإصدار السيئ وفهم متطلبات عملائك بشكل أكثر فعالية.