في هذا السيناريو، تقوم شركة من شركات التجارة الإلكترونية في صناعة السفر بترحيل تطبيق ويب قديم باستخدام Azure APIM. ستتم استضافة واجهة المستخدم الجديدة كتطبيق نظام أساسي كخدمة (PaaS) على Azure، وستعتمد على كل من واجهات برمجة تطبيقات HTTP الحالية والجديدة. ستشحن واجهات برمجة التطبيقات هذه بمجموعة من الواجهات المصممة بشكل أفضل، والتي ستمكن من أداء أفضل وتكامل أسهل وقابلية توسعة في المستقبل.
بناء الأنظمة
قم بتنزيل ملف Visio لهذه البنية.
سير العمل
- يستمر تطبيق الويب المحلي الحالي في استهلاك خدمات الويب المحلية الموجودة مباشرة.
- تظل المكالمات من تطبيق الويب الحالي إلى خدمات HTTP الحالية دون تغيير. هذه المكالمات داخلية لشبكة الشركة.
- يتم إجراء المكالمات الواردة من Azure إلى الخدمات الداخلية الموجودة:
- يسمح فريق الأمان لنسبة استخدام الشبكة من مثيل APIM بالمرور عبر جدار حماية الشركة إلى الخدمات المحلية الحالية باستخدام النقل الآمن (HTTPS أو SSL).
- يسمح فريق العمليات بالمكالمات الواردة إلى الخدمات فقط من مثيل APIM. يلبي هذا المطلب عن طريق إضافة عنوان IP لمثيل APIM إلى قائمة السماح داخل محيط شبكة الشركة.
- يتم تكوين وحدة نمطية جديدة في مسار الطلب المحلي لخدمات HTTP (للعمل على الاتصالات التي تنشأ خارجيا فقط ). يتحقق المسار من صحة شهادة توفرها إدارة واجهة برمجة التطبيقات.
- واجهة برمجة التطبيقات الجديدة:
- يتم عرض فقط من خلال مثيل APIM، الذي يوفر واجهة API. لا يتم الوصول إلى واجهة برمجة التطبيقات الجديدة مباشرة.
- يتم تطويره ونشره كتطبيق Azure PaaS Web API.
- تم تكوين (عبر إعدادات ميزة Web Apps في Azure App Service) لقبول عنوان IP الظاهري لإدارة واجهة برمجة التطبيقات (VIP) فقط.
- تتم استضافته في تطبيقات الويب مع تشغيل النقل الآمن (HTTPS أو SSL).
- تم تمكين التخويل، الذي توفره Azure App Service عبر معرف Microsoft Entra والتخويل المفتوح (OAuth) 2.
- يعتمد تطبيق الويب الجديد المستند إلى المستعرض على مثيل Azure API Management لكل من واجهة برمجة تطبيقات HTTP الحالية وواجهة برمجة التطبيقات الجديدة.
- يمكن لشركة التجارة الإلكترونية للسفر الآن توجيه بعض المستخدمين إلى واجهة المستخدم الجديدة (للمعاينة أو الاختبار) مع الحفاظ على واجهة المستخدم القديمة والوظائف الموجودة جنبا إلى جنب.
تم تكوين مثيل APIM لتعيين خدمات HTTP القديمة إلى عقد API جديد. في هذا التكوين، واجهة مستخدم الويب الجديدة غير مدركة للتكامل مع مجموعة من الخدمات/واجهات برمجة التطبيقات القديمة وواجهات برمجة التطبيقات الجديدة.
في المستقبل، سينقل فريق المشروع الوظائف تدريجياً إلى واجهات برمجة التطبيقات الجديدة وسحب الخدمات الأصلية. سيتعامل الفريق مع هذه التغييرات داخل تكوين APIM، تاركا واجهة المستخدم الأمامية غير متأثرة وتجنب عمل إعادة التطوير.
المكونات
- تلخص Azure API Management واجهات برمجة التطبيقات الخلفية بالإضافة إلى إضافة وظائف شاملة واكتشاف للمطورين والتطبيقات. في هذا السيناريو، أصبح من الممكن إعادة ترتيب واجهات برمجة التطبيقات الخلفية القديمة الحالية وإضافة وظائف واجهة برمجة التطبيقات الجديدة باستخدام APIM كواجهة لتطبيق العميل الجديد للاستهلاك باستمرار واستخدام المعايير الحديثة. نظرا لأن API Management تواجهة واجهات برمجة التطبيقات الحالية والجديدة، فمن الممكن للمطورين تحديث الواجهات الخلفية القديمة خلف واجهة APIM بطريقة متكررة وبحد أدنى إلى صفر تأثير على تطوير الواجهة الأمامية الجديدة.
- Azure App Service هي خدمة النظام الأساسي كخدمة (PaaS) لاستضافة الويب التي توفر ميزات خارج الصندوق مثل الأمان وموازنة التحميل والتحجيم التلقائي والإدارة التلقائية. تعد Azure App Service خيارا رائعا لواجهات برمجة التطبيقات الجديدة التي يتم تطويرها لهذا الحل لأنها توفر استضافة مرنة للمفتاح، ما يمكن فريق DevOps من التركيز على تقديم الميزات.
البدائل
إذا كانت المؤسسة تخطط لنقل بنيتها الأساسية بالكامل إلى Azure، بما في ذلك الأجهزة الظاهرية (VMs) التي تستضيف التطبيقات القديمة، فلا تزال APIM خيارا رائعا لأنها يمكن أن تعمل كواجهة لأي نقطة نهاية HTTP قابلة للعنوان.
إذا قررت المؤسسة الاحتفاظ بنقاط النهاية الحالية خاصة وعدم كشفها بشكل عام، يمكن ربط مثيل APIM الخاص بالمؤسسة بشبكة Azure الظاهرية:
- عندما تكون إدارة واجهة برمجة التطبيقات مرتبطة بشبكة Azure الظاهرية، يمكن للمؤسسة معالجة الخدمة الخلفية مباشرة من خلال عناوين IP الخاصة.
- في السيناريو المحلي، يمكن لمثيل APIM الوصول مرة أخرى إلى الخدمة الداخلية بشكل خاص عبر بوابة Azure VPN واتصال VPN لأمان بروتوكول الإنترنت (IPSec) من موقع إلى موقع أو Azure ExpressRoute. سيتحول هذا السيناريو بعد ذلك إلى هجين من Azure وفي أماكن العمل.
يمكن للمؤسسة الحفاظ على خصوصية مثيل APIM عن طريق نشره في الوضع الداخلي. يمكن للمؤسسة بعد ذلك استخدام النشر مع Azure Application Gateway لتمكين الوصول العام لبعض واجهات برمجة التطبيقات بينما يظل البعض الآخر داخليا. لمزيد من المعلومات، راجع تكامل APIM في شبكة ظاهرية داخلية باستخدام Application بوابة.
قد تقرر المؤسسة استضافة واجهات برمجة التطبيقات الخاصة بها محليا. قد يكون أحد أسباب هذا التغيير هو أن المؤسسة لم تتمكن من نقل تبعيات قاعدة بيانات انتقال البيانات من الخادم الموجودة في نطاق هذا المشروع إلى السحابة. إذا كان الأمر كذلك، فلا يزال بإمكان المؤسسة الاستفادة من APIM محليا باستخدام بوابة ذاتية الاستضافة.
البوابة ذاتية الاستضافة هي نشر حاوية لبوابة APIM التي تتصل مرة أخرى ب Azure على مأخذ توصيل صادر. الشرط الأساسي الأول هو أنه لا يمكن نشر البوابات المستضافة ذاتيا دون مورد أصل في Azure، والذي يحمل رسوما إضافية. ثانيا، المستوى المتميز لإدارة واجهة برمجة التطبيقات مطلوب.
تفاصيل السيناريو
تقوم شركة تجارة إلكترونية في صناعة السفر بتحديث حزمة البرامج القديمة المستندة إلى المستعرض. على الرغم من أن المكدس الموجود متجانس في الغالب، إلا أن بعض خدمات HTTP المستندة إلى بروتوكول الوصول إلى الكائنات البسيطة (SOAP) موجودة من مشروع حديث. وتنظر الشركة في إنشاء تدفقات إيرادات إضافية لتحقيق الدخل من بعض الملكية الفكرية الداخلية التي طورتها.
تشمل أهداف المشروع معالجة الأعمال الإضافية التقنية، وتحسين الصيانة المستمرة، وتسريع تطوير الميزات مع عدد أقل من أخطاء التراجع. سيستخدم المشروع عملية تكرارية لتجنب المخاطر، مع تنفيذ بعض الخطوات التالية على التوازي:
- سيقوم فريق التطوير بتحديث النهاية الخلفية للتطبيق، والتي تتكون من قواعد بيانات ارتباطية مستضافة على الأجهزة الظاهرية.
- سيقوم فريق التطوير الداخلي بكتابة وظائف أعمال جديدة سيتم الكشف عنها عبر واجهات برمجة تطبيقات HTTP الجديدة.
- سيقوم فريق تطوير العقد بإنشاء واجهة مستخدم جديدة قائمة على المستعرض، والتي سيتم استضافتها في Azure.
سيتم تسليم ميزات التطبيق الجديدة على مراحل. ستحل هذه الميزات تدريجيا محل وظيفة واجهة مستخدم العميل/الخادم المستندة إلى المستعرض (المستضافة محليا) التي تعمل الآن على تشغيل أعمال التجارة الإلكترونية للشركة.
لا يريد أعضاء فريق الإدارة التحديث دون داع. فهم يريدون أيضاً الحفاظ على التحكم في النطاق والتكاليف. للقيام بذلك، قرروا الحفاظ على خدمات SOAP HTTP الحالية الخاصة بهم. يعتزمون أيضاً تقليل التغييرات التي تطرأ على واجهة المستخدم الحالية. يمكنهم استخدام Azure API Management لمعالجة العديد من متطلبات المشروع وقيوده.
حالات الاستخدام المحتملة
يسلط هذا السيناريو الضوء على تحديث مكدسات البرامج القديمة المستندة إلى المستعرض.
يمكنك استخدام هذا السيناريو من أجل:
- تعرف على كيف يمكن لعملك الاستفادة من استخدام النظام البنائي ل Azure.
- التخطيط لترحيل الخدمات إلى Azure.
- تعرف على كيفية تأثير التحول إلى Azure على واجهات برمجة التطبيقات الحالية.
الاعتبارات
تنفذ هذه الاعتبارات ركائز إطار عمل Azure Well-Architected، وهو مجموعة من المبادئ التوجيهية التي تساعد على تحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.
الموثوقيه
تضمن الموثوقية أن التطبيق الخاص بك يمكن أن يفي بالالتزامات التي تتعهد بها لعملائك. لمزيد من المعلومات، راجع قائمة اختيار مراجعة التصميم للموثوقية.
- ضع في اعتبارك نشر مثيل إدارة واجهة برمجة تطبيقات Azure مع تمكين مناطق التوفر. يتوفر خيار نشر إدارة واجهة برمجة التطبيقات في مناطق التوفر فقط في طبقة الخدمة المتميزة.
- يمكن استخدام مناطق التوفر بالاقتران مع مثيلات البوابة الإضافية المنشورة في مناطق مختلفة. يؤدي ذلك إلى تحسين توفر الخدمة إذا كانت إحدى المناطق غير متصلة بالإنترنت. يتوفر النشر متعدد المناطق أيضا فقط في مستوى الخدمة المتميزة.
- ضع في اعتبارك التكامل مع Azure Application Insights، والذي يظهر أيضاً القياسات من خلال Azure Monitor للمراقبة. على سبيل المثال، يمكن استخدام مقياس السعة لتحديد الحمل الإجمالي على مورد APIM وما إذا كانت هناك حاجة إلى وحدات توسيع إضافية. يؤدي تعقب سعة الموارد والصحة إلى تحسين الموثوقية.
- تأكد من أن تبعيات انتقال البيانات من الخادم، على سبيل المثال خدمات الواجهة الخلفية التي تستضيف واجهات برمجة التطبيقات التي واجهات APIM، مرنة أيضا.
تحسين التكلفة
يركز تحسين التكلفة على البحث عن طرق للحد من النفقات غير الضرورية وتحسين الكفاءة التشغيلية. لمزيد من المعلومات، راجع قائمة اختيار مراجعة التصميم لتحسين التكلفة.
يتم تقديم إدارة واجهة برمجة التطبيقات في أربعة مستويات: المطور والأساسي والقياسي والمتميزة. للحصول على إرشادات مفصلة حول الاختلافات في هذه المستويات، راجع إرشادات تسعير Azure API Management.
يمكنك توسيع نطاق إدارة واجهة برمجة التطبيقات عن طريق إضافة الوحدات وإزالتها. كل وحدة لديها سعة تعتمد على طبقتها.
إشعار
يمكنك استخدام مستوى المطور لتقييم ميزات إدارة واجهة برمجة التطبيقات. لا تستخدمه للإنتاج.
لعرض التكاليف المتوقعة وتخصيصها لاحتياجات النشر الخاصة بك، يمكنك تعديل عدد وحدات المقياس ومثيلات App Service في حاسبة تسعير Azure.
المساهمون
تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.
الكاتب الرئيسي:
- Ben Gimblett | مهندس عملاء أول
لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.
الخطوات التالية
وثائق المنتج:
وحدات التعلم:
- استكشاف Azure App Service
- نشر موقع ويب إلى Azure باستخدام Azure App Service
- حماية واجهات برمجة التطبيقات الخاصة بك على Azure API Management