مشاركة عبر

النهج المعمارية لتكامل المستأجر والوصول إلى البيانات

  • مقالة

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

إشعار

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

الاعتبارات والمتطلبات الرئيسية

اتجاه تدفق البيانات

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

  • التصدير، ما يعني أن البيانات تتدفق من النظام متعدد المستأجرين إلى أنظمة المستأجرين الفرديين.
  • الاستيراد، ما يعني أن البيانات تأتي من أنظمة المستأجرين إلى نظامك متعدد المستأجرين.

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

الوصول الكامل أو المفوض من قبل المستخدم

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

على سبيل المثال، ضع في اعتبارك Microsoft Power BI، وهي خدمة متعددة المستأجرين توفر التقارير والمعلومات المهنية أعلى مخازن البيانات المملوكة للعملاء. عند تكوين Power BI، يمكنك تكوين مصادر البيانات لسحب البيانات من قواعد البيانات وواجهات برمجة التطبيقات ومخازن البيانات الأخرى. يمكنك تكوين مخازن البيانات بطريقتين مختلفتين:

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

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

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

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

في الوقت الحقيقي أو الدفعة

ضع في اعتبارك ما إذا كنت ستعمل مع البيانات في الوقت الحقيقي، أو إذا كانت البيانات سيتم إرسالها على دفعات.

بالنسبة للتكاملات في الوقت الحقيقي، تكون هذه الأساليب شائعة:

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

في المقابل، غالبا ما تتم إدارة عمليات تكامل الدفعات من خلال وظيفة خلفية، والتي قد يتم تشغيلها في أوقات معينة من اليوم. عادة، تتم عمليات تكامل الدفعات من خلال موقع مرحلي، مثل حاوية تخزين كائن ثنائي كبير الحجم، لأن مجموعات البيانات المتبادلة يمكن أن تكون كبيرة.

وحدة تخزين البيانات

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

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

تنسيقات البيانات

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

  • تنسيق الملف، مثل JSON أو Parquet أو CSV أو XML.
  • المخطط، مثل قائمة الحقول التي سيتم تضمينها وتنسيقات التاريخ وقابلية القيم الخالية للحولات.

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

الوصول إلى أنظمة المستأجرين

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

الوصول إلى الشبكة

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

  • الاتصال عبر الإنترنت. إذا قمت بالاتصال عبر الإنترنت، كيف سيتم تأمين الاتصال، وكيف سيتم تشفير البيانات؟ إذا كان المستأجرون يخططون لتقييدها استنادا إلى عناوين IP الخاصة بك، فتأكد من أن خدمات Azure التي يستخدمها الحل الخاص بك يمكن أن تدعم عناوين IP الثابتة للاتصالات الصادرة. على سبيل المثال، ضع في اعتبارك استخدام بوابة NAT لتوفير عناوين IP ثابتة، إذا لزم الأمر. إذا كنت تحتاج إلى VPN، ففكر في كيفية تبادل المفاتيح بأمان مع المستأجرين.
  • يمكن للوكلاء، الذين يتم توزيعهم في بيئة المستأجر، توفير نهج مرن ويمكن أن يساعدك على تجنب الحاجة إلى السماح للمستأجرين بالاتصالات الواردة.
  • توفر المرحلات، مثل Azure Relay، أيضا نهجا لتجنب الاتصالات الواردة.

لمزيد من المعلومات، راجع الإرشادات المتعلقة بنهج الشبكات متعددة المستأجرين.

المصادقة

ضع في اعتبارك كيفية المصادقة مع كل مستأجر عند بدء اتصال. ضع في اعتبارك الأساليب التالية:

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

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

وصول المستأجرين إلى أنظمتك

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

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

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

التوافق

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

مناهج وأنماط يجب مراعاتها

كشف واجهات برمجة التطبيقات

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

  • من الذي يمنح حق الوصول إلى واجهة برمجة التطبيقات؟
  • كيف ستصادق مستخدمي واجهة برمجة التطبيقات؟
  • هل هناك حد لعدد الطلبات التي يمكن لمستخدم واجهة برمجة التطبيقات إجراؤها على مدى فترة زمنية؟
  • كيف ستوفر معلومات حول واجهات برمجة التطبيقات والوثائق لكل واجهة برمجة تطبيقات؟ على سبيل المثال، هل تحتاج إلى تنفيذ مدخل مطور؟

من الممارسات الجيدة استخدام بوابة API، مثل Azure API Management، للتعامل مع هذه المخاوف وغيرها الكثير. تمنحك بوابات واجهة برمجة التطبيقات مكانا واحدا لتنفيذ النهج التي تتبعها واجهات برمجة التطبيقات الخاصة بك، وتبسط تنفيذ أنظمة واجهة برمجة التطبيقات الخلفية. لمعرفة المزيد حول كيفية دعم APIM للبنية متعددة المستأجرين، راجع استخدام Azure API Management في حل متعدد المستأجرين.

نمط مفتاح الخادم

في بعض الأحيان، قد يحتاج المستأجر إلى الوصول المباشر إلى مصدر بيانات، مثل Azure Storage. ضع في اعتبارك اتباع نمط Valet Key لمشاركة البيانات بشكل آمن وتقييد الوصول إلى مخزن البيانات.

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

وبالمثل، يمكنك إنشاء توقيع وصول مشترك مع أذونات للكتابة إلى كائن ثنائي كبير الحجم معين. عند توفير توقيع وصول مشترك إلى مستأجر، يمكنهم كتابة بياناتهم إلى الكائن الثنائي كبير الحجم. باستخدام تكامل Event Grid ل Azure Storage، يمكن إعلام التطبيق الخاص بك لمعالجة ملف البيانات واستيراده.

خطاف الويب

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

إذا اخترت إنشاء نظام أحداث خطاف الويب الخاص بك، ففكر في اتباع معيار CloudEvents لتبسيط متطلبات تكامل المستأجرين.

بدلا من ذلك، يمكنك استخدام خدمة مثل Azure Event Grid لتوفير وظائف webhook. تعمل Event Grid في الأصل مع CloudEvents، وتدعم مجالات الأحداث، والتي تعد مفيدة للحلول متعددة المستأجرين.

إشعار

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

وصول المستخدم المفوض

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

على سبيل المثال، افترض أن خدمتك متعددة المستأجرين تقوم بتشغيل نماذج التعلم الآلي عبر بيانات المستأجرين. تحتاج إلى الوصول إلى مثيلات كل مستأجر من الخدمات، مثل Azure Synapse Analytics وAzure Storage وAzure Cosmos DB وغيرها. كل مستأجر لديه دليل Microsoft Entra الخاص به. يمكن منح الحل الخاص بك حق الوصول المفوض إلى مخزن البيانات، بحيث يمكنك استرداد البيانات التي يمكن لمستخدم معين الوصول إليها.

يكون الوصول المفوض أسهل إذا كان مخزن البيانات يدعم مصادقة Microsoft Entra. تدعم العديد من خدمات Azure هويات Microsoft Entra.

على سبيل المثال، افترض أن تطبيق الويب متعدد المستأجرين وعمليات الخلفية تحتاج إلى الوصول إلى Azure Storage باستخدام هويات مستخدمي المستأجرين من معرف Microsoft Entra. قد تقوم بالخطوات التالية:

  1. إنشاء تسجيل تطبيق Microsoft Entra متعدد المستأجرين يمثل الحل الخاص بك.
  2. امنح التطبيق الإذن المفوض للوصول إلى Azure Storage كمستخدم سجل الدخول.
  3. تكوين التطبيق الخاص بك لمصادقة المستخدمين باستخدام معرف Microsoft Entra.

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

المراسلة

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

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

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

مكونات التكامل القابلة للتكوين

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

يتمثل النهج الشائع في التكامل في إنشاء واختبار الخطوات الفردية التي تنفذ الأنواع التالية من الإجراءات:

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

عادة ما تقوم بإنشاء هذه العناصر الفردية باستخدام خدمات مثل Azure Functions وAzure Logic Apps. ثم تقوم بتعريف عملية التكامل الشاملة باستخدام أداة مثل Logic Apps أو Azure Data Factory، وتستدعي كل خطوة من الخطوات المعرفة مسبقا.

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

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

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

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

أنماط مضادة لتجنب

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

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكتاب الرئيسيون:

المساهم الآخر:

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

الخطوات التالية

مراجعة الأساليب المعمارية للمراسلة في الحلول متعددة المستأجرين.