مشاركة عبر

النهج المعمارية لإنترنت الأشياء في حل متعدد المستأجرين

  • مقالة

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

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

يتم عرض هذه الاعتبارات والمتطلبات عادةً في ترتيب حسب أولوية تصميم الحل.

التحكموالتوافق

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

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

المقياس‬

من المهم تخطيط حجم الحلول الخاصة بك. غالبًا ما يتم النظر في الحجم عبر هذه الأبعاد الثلاثة:

  • كمية الأجهزة: تحتوي جميع خدمات إدارة أجهزة Azure - Azure IoT Central، وAzure IoT Hub Device Provisioning Service (DPS)، و Azure IoT Hub - على قيود في عدد من الأجهزة المدعومة في المثيل الواحد.

    تلميح

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

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

  • المستأجرون: قد يكون حجم نطاق المستأجر الواحد صغيرًا، ولكن عند ضربه في عدد المستأجرين، يمكن أن ينمو بسرعة.

الأداء والموثوقية

عزل Tenant

قد يكون للحلول المشتركة بالكامل جيران مزعجون. في حالات IoT Hub و IoT Central، قد يؤدي ذلك إلى رموز استجابة HTTP 429 ("طلبات كثيرة للغاية")، وهي حالات فشل شديدة يمكن أن تسبب تأثيرًا متعاقبًا. لمزيد من المعلومات، راجع Quotas and Throttling.

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

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

تخزين البيانات، والاستعلام، والاستخدام، والاستبقاء

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

الأمان

غالبا ما يكون لحلول IoT اعتبارات أمان في طبقات متعددة، خاصة في الحلول التي يتم نشرها في هندسة مرجع Purdue Enterprise المعدلة على السحابة أو حلول الصناعة 4.0. سيؤثر نهج التصميم المحدد من تلك الموجودة أدناه على طبقات الشبكة والحدود الموجودة؛ بمجرد تحديد التصميم الفعلي، يمكن تحديد تنفيذ الأمان. تتضمن الأدوات التي يمكن استخدامها في أي نهج ما يلي:

  • Microsoft Defender for IoT، وهو حل شامل لمراقبة IoT يجب مراعاته يوفر ترخيص EIoT لكل جهاز وتراخيص موقع OT لكل جهاز عميل و/أو موقع. اعتمادا على الأسلوب المحدد من وقت لاحق في هذه المقالة، قد لا يكون سيناريو ترخيص المستخدم المسمى Microsoft 365 ممكنا. في هذه الحالة، تتوفر خيارات ترخيص الموقع والجهاز، وهي خيارات ترخيص مستقلة عن تراخيص مستأجر Microsoft 365.

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

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

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

السياسات التي يجب مراعاتها

جميع الاعتبارات التي تقوم بها عادة في بنية IoT، لجميع المكونات الأساسية (مثل الإدارة، والاستيعاب، والمعالجة، والتخزين، والأمان، وما إلى ذلك)، هي جميع الخيارات التي لا يزال يتعين عليك اتخاذها عند السعي إلى حل متعدد المستأجرين. الفرق الأساسي هو كيفية ترتيب المكونات واستخدامها لدعم تعدد المستأجرين. على سبيل المثال، قد تحدد نقاط القرار الشائعة للتخزين ما إذا كنت ستستخدم SQL Server أو Azure Data Explorer، أو ربما على مستوى الإدخال والإدارة، فيمكنك الاختيار بين IoT Hub و IoT Central.

تتلاءم معظم حلول IoT مع نمط بنية الجذر، وهو مزيج من هدف النشر، ونموذج الإيجار ونمط النشر. تُحدّد المتطلبات والاعتبارات الرئيسية الموضحة أعلاه هذه العوامل.

إن إحدى أكبر نقاط القرار التي تحتاج إلى اتخاذها، ضمن مساحة IoT، هي الاختيار بين سياسات النظام الأساسي كخدمة لتطبيق (aPaaS) والنظام الأساسي كخدمة (PaaS). لمزيد من المعلومات، راجع مقارنة سياسات حل «إنترنت الأشياء» (IoT) (PaaS مقابل aPaaS).

هذه هي معضلة "البناء مقابل الشراء" الشائعة التي تواجهها العديد من المؤسسات في العديد من المشاريع. يعد تقييم مزايا وعيوب كلا الخيارين أمرًا مهمًا.

مفاهيم واعتبارات حلول aPaaS

قد يستخدم الحل المثالي لـ aPaaS المستخدم لـ Azure IoT Central، باعتباره أساس الحل، خدمات Azure PaaS و aPaaS التالية:

  • Azure Event Hubs كمحرك مراسلة وتدفق بيانات على مستوى المؤسسات، عبر الأنظمة الأساسية.
  • Azure Logic Apps كتكامل، أو عرض، للنظام الأساسي كخدمة، أو iPaaS.
  • Azure Data Explorer كنظام أساسي لتحليل البيانات.
  • Power BI كالنظام الأساسي للتصور وإعداد التقارير.

تعرض بنية I O T المستأجرين الذين يشاركون بيئة I O T Central وAzure Data Explorer وPower B I وAzure Logic Apps.

في الرسم التخطيطي السابق، يشارك المستأجرون بيئة IoT Central، و Azure Data Explorer، و Power BI، و Azure Logic Apps.

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

من المهم أن ندرك أنه نظرًا لأن IoT Central هي عرض aPaaS، فهناك قرارات معينة خارجة عن سيطرة المُنفّذ. تشمل هذه القرارات الآتي:

  • يستخدم IoT Central معرف Microsoft Entra كموفر الهوية الخاص به.
  • يتم تحقيق عمليات نشر IoT Central باستخدام كلاً من عمليات وحدة التحكم والبيانات، التي تجمع المستندات التعريفية مع التعليمات البرمجية الإلزامية.
  • في نمط متعدد المؤسسات، قد يفرض كل من الحد الأقصى للعُقدة في IoT Central الأقصى (الذي ينطبق على كل من الأصول والفروع) والحد الأقصى لعمق الشجرة، موفر الخدمة للحصول على مثيلات متعددة لـ IoT Central. في هذه الحالة، يجب مراعاة اتباع نمط «طابع النشر».
  • يفرض IoT Central حدود استدعاء واجهة برمجة التطبيقات للنظام، التي قد تؤثر على عمليات التنفيذ الكبرى.

مفاهيم واعتبارات حلول PaaS

قد تستخدم السياسة المستندة إلى PaaS خدمات Azure التالية:

  • Azure IoT Hub كنظام أساسي لعملية التكوين الأساسية للجهاز والاتصالات.
  • خدمة توفير جهاز Azure IoT كنظام أساسي لعملية نشر الجهاز والتكوين الأولي.
  • Azure Data Explorer لتخزين وتحليل بيانات السلسلة الزمنية في المسار الدافئ والبارد من أجهزة IoT.
  • Azure Stream Analytics لتحليل بيانات المسار الساخن من أجهزة IoT.
  • Azure IoT Edge لتشغيل الذكاء الاصطناعي (AI)، أو خدمات من الجهات الخارجية، أو منطق تسلسل عملك الخاص على أجهزة IoT Edge.

رسم تخطيطي يوضح حل I O T. يتصل كل مستأجر بتطبيق ويب مشترك، والذي يتلقى البيانات من I O T Hubs وتطبيق الوظائف. تتصل الأجهزة بخدمة تزويد الأجهزة و I O T Hubs.

في الرسم التخطيطي السابق، يتصل كل مستأجر بتطبيق ويب مشترك، يتلقى البيانات من IoT Hubs وتطبيق الوظائف. تتصل الأجهزة بخدمة تزويد الأجهزة و IoT Hubs.

يتطلب هذا النهج بذل المزيد من الجهود من جانب المطور لإنشاء الحل ونشره والاحتفاظ به (مقابل نهج aPaaS). يتم إنشاء عدد أقل من القدرات مسبقًا وقتما يريد المنفذ. يعني ذلك أن هذا النهج يوفر أيضًا مزيدًا من التحكم، بسبب تضمين افتراضات أقل في النظام الأساسي.

أنماط بنية الجذر

يسرد الجدول التالي الأنماط الشائعة لحلول IoT لمتعددة المؤسسات. يتضمن كل نمط المعلومات التالية:

  • اسم النمط، الذي يستند إلى خليط من الهدف، والنموذج، ونوع النشر.
  • هدف النشر، الممثل لاشتراك Azure لنشر الموارد إليه.
  • نموذج الإيجار المشار إليه من النمط، كما هو موضح في نماذج تعدد المؤسسات
  • نمط التوزيع، مشيرًا إلى نشر بسيط في حد أدنى من اعتبارات النشر، أو نمط Geode، أو نمط «طابع النشر».
النمط هدف التوزيع نموذج الإيجار نمط النشر
«خدمة تأجير البرامج البسيطة» اشتراك موفر الخدمة متعدد المؤسسات بالكامل بسيط
خدمة تأجير البرامج (SaaS) الأفقية اشتراك موفر الخدمة مُقسم أفقيًا «طابع النشر»
أتمتة المستأجر الواحد إما اشتراك موفر الخدمة أو العميل مستأجر واحد لكل عميل بسيط

«خدمة تأجير البرامج البسيطة»

رسم تخطيطي يوضح بنية I O T. يشارك المستأجرون بيئة I O T Central وAzure Data Explorer وPower B I وAzure Logic Apps.

هدف النشر نموذج الإيجار نمط النشر
اشتراك موفر الخدمة متعدد المؤسسات بالكامل بسيط

سياسة SaaS البسيطة هي أبسط تنفيذ لحل IoT في SaaS. كما هو مبين في الرسم التخطيطي السابق، تتم مشاركة البنية الأساسية بأكملها، ولا ينطبق طابع الجغرافيا أو المقياس على البنية الأساسية. في كثير من الأحيان، توجد البنية الأساسية ضمن الاشتراك الواحد لـ Azure.

Azure IoT Central يدعم مفهوم المؤسسات. تُمكّن المؤسسات موفر الحلول من فصل المستأجرين بسهولة بطريقة آمنة، في تدرج هرمي، مع مشاركة التصميم الأساسي للتطبيق عبر جميع المستأجرين.

يتم إجراء الاتصالات بالأنظمة خارج IoT Central، مثل تحليل البيانات على المدى الطويل، بجانب مسار بارد أو اتصال مع عمليات الأعمال التجارية، من خلال عروض Microsoft PaaS و aPaaS الأخرى. قد تتضمن هذه العروض الإضافية الخدمات التالية:

  • Azure Event Hubs كمحرك مراسلة وتدفق البيانات على مستوى المؤسسات، عبر الأنظمة الأساسية.
  • Azure Logic Apps كتكامل للنظام الأساسي كخدمة، أو iPaaS.
  • Azure Data Explorer كنظام أساسي لتحليل البيانات.
  • Power BI كالنظام الأساسي للتصور وإعداد التقارير.

إذا قارنت نهج SaaS البسيط مع نموذج aPaaS التلقائي للمستأجر الفردي، تتشابه العديد من الخصائص. إن الفرق الأساسي بين النموذجين هو أنه في النموذج التلقائي للمستأجر الفردي، يمكنك نشر مثيل IoT Central المميز لكل مستأجر، بينما في نموذج SaaS «البسيط» مع aPaaS، يمكنك بالأحرى نشر مثيل مُشترك لعدة عملاء، وإنشاء مؤسسة IoT Central لكل مستأجر.

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

الفوائد:

  • أسهل في الإدارة والعمل بالنسبة للسياسات الأخرى المعروضة هنا.

المخاطر:

  • قد لا يتسع نطاق هذا النهج بسهولة إلى عدد كبير للغاية من الأجهزة، أو الرسائل، أو المستأجرين.

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

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

«خدمة تأجير البرامج الأفقية»

هدف التوزيع نموذج الإيجار نمط النشر
اشتراك موفر الخدمة مُقسم أفقيًا «طابع النشر»

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

ضمن حل IoT، هناك العديد من المكونات التي يمكن تقسيمها أفقيًا. عادة ما يتم ترتيب الأنظمة الفرعية المُقسمة أفقيًا باستخدام نمط «طابع النشر» الذي يتكامل مع الحل الأكبر.

مثال على خدمة تأجير البرامج الأفقية

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

رسم تخطيطي لحل I O T. كل مستأجر لديه مؤسسة I O T Central الخاصة به، والتي ترسل بيانات تتبع الاستخدام إلى تطبيق وظائف مشترك وتجعله متاحا لمستخدمي الأعمال المستأجرين من خلال تطبيق ويب.

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

الفوائد:

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

المخاطر:

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

فيما يلي المكونات الأكثر شيوعًا التي عادة ما تُلائم التقسيم الأفقي.

قواعد البيانات

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

قم بفصل قواعد البيانات لكل مستأجر، للحصول على الفوائد التالية:

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

إدارة الأجهزة، والاتصالات، والإدارة

غالبا ما يمكن نشر «خدمات تزويد أجهزة» Azure IoT Hub، و IoT Hub وتطبيقات IoT Central كمكونات مقسمة أفقيًا. إذا اتبعت هذا النهج، ستحتاج إلى خدمة إضافية لإعادة توجيه الأجهزة إلى «خدمة تزويد الأجهزة» المناسبة إلى مستوى المحدد لإدارة المستأجر، والتحكم، وبيانات تتبع الاستخدام. لمزيد من المعلومات، راجع المستند التقني، توسيع نطاق حل Azure IoT لدعم الملايين من الأجهزة.

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

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

المعالجة المتدفقة

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

أتمتة المستأجر الواحد

يستند النهج التلقائي للمستأجر الواحد إلى عملية قرار مماثلة وتصميم لحل المؤسسة.

رسم تخطيطي يوضح بنية I O T لثلاثة مستأجرين. لكل مستأجر بيئة مماثلة ومعزولة خاصة به مع مؤسسة I O T Central ومكونات أخرى مخصصة لهم.

لكل مستأجر بيئة مماثلة، ومعزولة خاصة به، وسط مؤسسة IoT Central ومكونات أخرى مخصصة لهم.

هدف النشر نموذج الإيجار نمط النشر
إما اشتراك موفر الخدمة أو العميل مستأجر واحد لكل عميل بسيط

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

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

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

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

إن النهج التلقائي للمستأجر الواحد مشابه لنموذج SaaS البسيط aPaaS. إن الفرق الأساسي بين النموذجين هو أنه في النهج التلقائي للمستأجر الفردي، يمكنك نشر مثيل IoT Central المميز لكل مستأجر، بينما في نموذج SaaS «البسيط» مع aPaaS، يمكنك نشر مثيل مُشترك لـ IoT Central مع مؤسسات متعددة في IoT Central.

الفوائد:

  • يسهل نسبيًا إدارتها وتشغيلها.
  • إن عزل المستأجر مضمون بشكل أساسي.

المخاطر:

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

زيادة حجم SaaS

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

المساهمون

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

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

مساهمون آخرون:

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