ميزات شبكة خدمة التطبيقات

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

يوجد نوعان رئيسيان من النشر لخدمة تطبيقات Azure:

• تستضيف الخدمة العامة متعددة المستأجرين خطط App Service في الوحدات لحفظ المخزون المجانية والمشتركة والأساسية والقياسية والمتميزة من الفئة 2 والمتميزة من الفئة 3.
• يوجد أيضًا بيئة App Service (ASE) المستأجرة الفردية التي تستضيف خطط App Service لوحدة حفظ المخزون المعزولة مباشرة في شبكة Azure الظاهرية.

سوف تعتمد الميزات التي تستخدمها على ما إذا كنت في خدمة متعددة المستأجرين أو في ASE.

إشعار

ميزات الشبكات غير متوفرة للتطبيقات المنشورة في Azure Arc.

ميزات شبكات App Service متعددة المستأجرين

خدمة Azure App Service هي نظام موزع. تسمى الأدوار التي تعالج طلبات HTTP أو HTTPS الواردة الواجهات الأمامية. تسمى الأدوار التي تستضيف حمل عمل العميل العمال. توجد كافة الأدوار في توزيع App Service في شبكة متعددة المستأجرين. نظراً لوجود العديد من العملاء المختلفين في الخوادم المخصصة لخدمة App Service نفسها، لا يمكنك توصيل شبكة خدمة App Service مباشرة بالشبكة الخاصة بك.

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

الميزات الواردة	الميزات الصادرة
عنوان معين بواسطة التطبيق	اتصالات مختلطة
قيود الوصول	تكامل الشبكة الظاهرية المطلوب من البوابة
نقاط نهاية الخدمة	تكامل الشبكة الظاهرية
نقاط النهاية الخاصة

بخلاف الاستثناءات المذكورة، يمكنك استخدام كافة الميزات معًا. يمكنك المزج بين الميزات لحل مشاكلك.

استخدام الحالات والميزات

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

حالة الاستخدام الواردة	ميزة
دعم احتياجات SSL المستندة إلى بروتوكول الإنترنت لتطبيقك	عنوان معين بواسطة التطبيق
دعم عنوان وارد مخصص غير مشترك لتطبيقك	عنوان معين بواسطة التطبيق
تقييد الوصول إلى تطبيقك من مجموعة من العناوين المحددة جيداً	قيود الوصول
تقييد الوصول إلى التطبيق الخاص بك من الموارد الموجودة في شبكة ظاهرية	نقاط تقديم الخدمة نقاط النهاية الخاصة لموازن التحميل الداخلي (ILB) ASE
الكشف عن التطبيق الخاص بك على IP خاص في شبكتك الظاهرية	ILB ASE نقطة النهاية الخاصة IP لنسبة استخدام الشبكة الواردة على مثيل بوابة التطبيق مع نقاط نهاية الخدمة
حماية التطبيق باستخدام جدار حماية تطبيق ويب (WAF)	Application Gateway وILB ASE Application Gateway مع نقاط النهاية الخاصة Application Gateway مع نقاط نهاية الموفر Azure Front Door مع قيود الوصول
تحميل نسبة استخدام الشبكة إلى التطبيقات الخاصة بك في مناطق مختلفة	Azure Front Door مزودة بقيود الوصول
نسبة استخدام الشبكة لموازنة التحميل في نفس المنطقة	Application Gateway مع نقاط نهاية الخدمة

تشير حالات الاستخدام الصادرة التالية إلى كيفية استخدام ميزات شبكة App Service لحل احتياجات الوصول الصادر للتطبيق الخاص بك:

حالة الاستخدام الصادر	ميزة
الوصول إلى الموارد في شبكة اتصال ظاهرية Azure في نفس المنطقة	تكامل الشبكة الظاهرية ASE
الوصول إلى الموارد في شبكة اتصال ظاهرية Azure في منطقة مختلفة	تكامل الشبكة الظاهرية والشبكة الظاهرية النظيرة تكامل الشبكة الافتراضية المطلوبة من البوابة الشبكة الظاهرية المطلوبة ASE ونظير الشبكة الظاهرية
الوصول إلى الموارد المؤمنة باستخدام نقاط نهاية الموفر	تكامل الشبكة الظاهرية ASE
الوصول إلى الموارد في الشبكة الخاصة غير متصلة بـ Azure	اتصالات مختلطة
الوصول إلى الموارد عبر دوائر تطبيق Azure ExpressRoute	تكامل الشبكة الظاهرية ASE
تأمين نسبة استخدام الشبكة الصادرة من تطبيق الويب الخاص بك	تكامل الشبكة الظاهرية ومجموعات الأمان الخاص بشبكة ASE
توجيه نسبة استخدام الشبكة الصادرة من تطبيق الويب الخاص بك	تكامل الشبكة الظاهرية وجداول التوجيه ASE

سلوك الشبكات الافتراضي

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

العناوين الصادرة

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

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

تحتوي App Service على نقاط نهاية خدمة مستخدمة متعددة لإدارة الخدمة. نشر العناوين في مستند منفصل وهي أيضًا في AppServiceManagement علامة خدمة IP. استخدام العلامة AppServiceManagement فقط في App Service Environments حيث تحتاج إلى السماح بنسبة استخدام الشبكة هذه. تتبع عناوين App Service الواردة AppService في علامة خدمة IP. لا توجد علامة خدمة IP تحتوي على العناوين الصادرة المستخدمة من قبل خدمة التطبيقات.

عنوان معين بواسطة التطبيق

ميزة العنوان المعين من قبل التطبيق هي فرع من إمكانية SSL المستندة إلى IP. يمكنك الوصول إليه عن طريق إعداد SSL مع التطبيق الخاص بك. يمكنك استخدام الميزة لمكالمات SSL المستندة إلى IP. يمكنك أيضًا استخدامه لإعطاء التطبيق عنوانًا يحتوي عليه فقط.

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

• دعم احتياجات SSL المعتمدة على بروتوكول الإنترنت للتطبيق الخاص بك.
• عين عنوان مخصص لتطبيقك غير مشترك.

لمعرفة كيفية تعيين عنوان على التطبيق، راجع إضافة شهادة TLS/SSL في خدمة تطبيقات Azure.

قيود الوصول

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

تسمح لك الميزة بإنشاء قائمة السماح ورفض القواعد التي يتم تقييمها بترتيب الأولوية. وهي مشابهة لميزة مجموعة أمان الشبكة (NSG) في شبكة Azure. يمكنك استخدام الميزة في ASE أو في الخدمة متعددة المستأجرين. عند استخدامه مع ASE ILB يمكنك تقييد الوصول من كتل العناوين الخاصة. لمعرفة كيفية تمكين الميزة، راجع تكوين قيود الوصول.

إشعار

يمكن تكوين ما يصل إلى 512 قاعدة تقييد الوصول لكل تطبيق.

نقطة النهاية الخاصة

نقطة النهاية الخاصة هي واجهة شبكة اتصال تربطك بشكل خاص وآمن بتطبيق الويب الخاص بك بواسطة ارتباط Azure الخاص. تستخدم نقطة النهاية الخاصة بعنوان IP خاص من شبكتك الافتراضية، ما يؤدي إلى إدخال تطبيق الويب بشكل فعال إلى شبكتك الافتراضية. هذه الميزة هي فقط للتدفقات الواردة إلى تطبيق الويب الخاص بك. لمزيد من المعلومات، راجع استخدام نقاط النهاية الخاصة لتطبيق Azure على ويب.

بعض الحالات المستخدمة لهذه الميزة:

• تقييد الوصول إلى التطبيق من الموارد الموجودة في شبكة افتراضية.
• كشف التطبيق الخاص بك على IP خاص في الشبكة الافتراضية الخاصة بك.
• حماية التطبيق الخاص بك مع WAF.

تعطي نقاط النهاية الخاصة تسرب البيانات لأن الشيء الوحيد الذي يمكنك الوصول إليه عبر نقطة النهاية الخاصة هو التطبيق الذي تم تكوينه به.

اتصالات مختلطة

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

إنشاء App Service Hybrid Connections على إمكانية Azure Relay Hybrid Connections. تستخدم خدمة التطبيقات شكلاً متخصصًا من الميزة يدعم فقط إجراء مكالمات صادرة من تطبيقك إلى مضيف ومنفذ TCP. يحتاج المضيف والمنفذ فقط إلى حل على المضيف حيث يتم تثبيت إدارة الاتصال المختلط.

عندما يقوم التطبيق، في خدمة التطبيقات، بالبحث عن DNS على المضيف والمنفذ المحدد في الاتصال المختلط، فإن نسبة استخدام الشبكة تعيد توجيهها تلقائيا للانتقال عبر الاتصال المختلط والخروج من إدارة الاتصال المختلط. لمعرفة المزيد، راجع App Service Hybrid Connections.

تستخدم الميزة بشكل شائع لـ:

• الوصول إلى الموارد في الشبكات الخاصة غير المتصلة بـ Azure باستخدام VPN أو ExpressRoute.
• دعم ترحيل التطبيقات المحلية إلى App Service دون الحاجة إلى نقل قواعد البيانات المدعمة.
• توفير الوصول مع الأمان المحسن إلى مضيف واحد ومنفذ لكل اتصال مختلط. معظم ميزات شبكة الاتصال فتح الوصول إلى شبكة اتصال. باستخدام Hybrid Connections، يمكنك فقط الوصول إلى المضيف والمنفذ الفردي.
• تغطية سيناريوهات غير مشمولة بطرق الاتصال الصادرة الأخرى.
• إجراء التطوير في خدمة التطبيقات بطريقة تسمح للتطبيقات باستخدام الموارد المحلية بسهولة.

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

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

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

تكامل الشبكة الظاهرية

يتيح تكامل الشبكة الظاهرية ل App Service لتطبيقك إجراء طلبات صادرة إلى شبكة Azure الظاهرية.

تمكنك ميزة تكامل الشبكة الظاهرية من وضع النهاية الخلفية لتطبيقك في شبكة فرعية في شبكة ظاهرية ل Resource Manager. يجب أن تكون الشبكة الظاهرية في نفس منطقة تطبيقك. لا تتوفر الميزة من بيئة خدمة التطبيقات الموجودة بالفعل في شبكة افتراضية. الحالات المستخدمة لهذه الميزة:

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

لمعرفة المزيد، راجع pp Service virtual network integration.

تكامل الشبكة الظاهرية المطلوب من البوابة

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

يسمح لك التكامل المطلوب للبوابة بالاتصال مباشرة بشبكة ظاهرية في منطقة أخرى دون نظير والاتصال بشبكة ظاهرية كلاسيكية. تقتصر الميزة على خطط App Service Windows ولا تعمل مع الشبكات الظاهرية المتصلة ب ExpressRoute. يوصى باستخدام تكامل الشبكة الظاهرية الإقليمية. لمزيد من المعلومات عن هذه الميزة، راجع App Service virtual network integration.

بيئة خدمة التطبيق

بيئة خدمة التطبيقات (ASE) هي توزيع مستأجر واحد لخدمة تطبيقات Azure التي يتم تشغيلها في الشبكة الظاهرية. بعض الحالات مثل لهذه الميزة:

• الوصول إلى الموارد في الشبكة الظاهرية.
• الوصول إلى الموارد من خلال ExpressRoute.
• كشف التطبيقات الخاصة بك باستخدام عنوان خاص في الشبكة الظاهرية.
• الوصول إلى الموارد من خلال نقاط نهاية الخدمة.
• الوصول إلى الموارد من خلال نقاط النهاية الخاصة.

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

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

بعض الأشياء غير الممكنة حاليًا من الخدمة متعددة المستأجرين ولكنها ممكنة من ASE. فيما يلي بعض الأمثلة:

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

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

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

التجميع بين الميزات

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

وضع التطبيق في الشبكة الافتراضية

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

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

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

إنشاء تطبيقات متعددة المستويات

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

• استضافة كل من الواجهة الأمامية والتطبيق API في نفس ASE ILB، وفضح التطبيق الأمامي إلى الإنترنت باستخدام بوابة التطبيق.
• استضافة الواجهة الأمامية في الخدمة متعددة المستأجرين والنهاية الخلفية في تطبيق ILB ASE.
• استضافة كل من الواجهة الأمامية وواجهة برمجة التطبيقات في الخدمة متعددة المستأجرين.

إذا كنت تستضيف كلاً من الواجهة الأمامية وتطبيق واجهة برمجة التطبيقات لتطبيق متعدد المستويات، بإمكانك:

• كشف تطبيق API الخاص بك باستخدام نقاط نهاية الخدمة الخاصة في شبكتك الظاهرية:

  

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

  

فيما يلي بعض الاعتبارات لمساعدتك في تحديد الطريقة التي يتعين استخدامها:

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

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

تطبيقات خط الأعمال

تطبيقات خط العمل (LOB) تعتبر تطبيقات داخلية لا يتم عرضها عادة للوصول من الإنترنت. استدعاء التطبيقات من داخل شبكات الشركات حيث يمكن التحكم في الوصول بدقة. إذا كنت تستخدم ILB ASE، فمن السهل استضافة تطبيقات خط الأعمال الخاصة بك. إذا كنت تستخدم الخدمة متعددة المستأجرين، فإنه يمكنك إما استخدام نقاط النهاية الخاصة أو استخدام نقاط نهاية الخدمة جنبا إلى جنب مع بوابة التطبيق. يوجد سببان لاستخدام عبارة تطبيق مع نقاط نهاية الخدمة بدلاً من استخدام نقاط النهاية الخاصة:

• ستحتاج إلى حماية WAF على تطبيقات LOB الخاصة بك.
• تريد تحميل الرصيد إلى مثيلات متعددة لتطبيقات LOB.

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

سوف يؤدي تكوين نقاط النهاية الخاصة إلى عرض تطبيقاتك على عنوان خاص، ولكنك ستحتاج إلى تكوين DNS للوصول إلى هذا العنوان من الموقع المحلي. لجعل التكوين يعمل، ستحتاج إلى إعادة توجيه منطقة Azure DNS الخاصة التي تحتوي على نقاط النهاية الخاصة بك إلى خوادم DNS المحلية. لا تدعم المناطق الخاصة ل Azure DNS إعادة توجيه المنطقة، ولكن يمكنك دعم إعادة توجيه المنطقة باستخدام محلل Azure DNS الخاص.

منافذ خدمة التطبيقات

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

استخدام	المنفذ أو المنافذ
HTTP/HTTPS	80, 443
الإدارة	454، 455
FTP/FTPS	21، 990، 10001-10300
Visual Studio المتعلق بتصحيح الأخطاء عن بعد	4020، 4022، 4024
خدمة توزيع ويب	8172
استخدام البنية الأساسية	7654, 1221