افصل أنواع العمل
قيم طلبات الويب والمهام الطويلة بصورة مستقلة لتحديد مصدر الضغط. عند توزيع العمل على عمليات مختلفة، حدد داخل التطبيق سلوك الفشل وإعادة المحاولة.
الحلول / SAAS
تعامل مع واجهة تطبيق SaaS والمهام الخلفية والبيانات بوصفها احتياجات منفصلة. صمم بنية باستخدام منتجات FibaCloud مع مراعاة عزل العملاء والسعة ومسؤوليات التشغيل. اجعل قرارات البداية تستوعب احتياجات المنتج الحالية والتغييرات التي قد تفرضها مراحل النمو التالية.
01 / نظرة عامة
اختيار حجم الخادم ليس القرار الوحيد عند تشغيل SaaS. قد يؤثر نشاط عميل كثيف على العملاء الآخرين الذين يتشاركون الموارد، كما تعتمد حدود الوصول إلى البيانات على تصميم التطبيق. وضح المكونات المسؤولة عن الطلبات والمهام الخلفية والبيانات الدائمة.
اختر موارد الحوسبة وفق سلوك التطبيق، ثم قيم احتياجات الملفات وقاعدة البيانات والاستعادة بصورة مستقلة. هذا التصور نقطة بداية لبرمجيات تنشرها وتديرها، وليس وصفا لتطبيق SaaS جاهز أو خدمة تتولى إدارة العملاء تلقائيا.
قيم طلبات الويب والمهام الطويلة بصورة مستقلة لتحديد مصدر الضغط. عند توزيع العمل على عمليات مختلفة، حدد داخل التطبيق سلوك الفشل وإعادة المحاولة.
صمم المصادقة والصلاحيات والوصول إلى بيانات العميل معا. استخدام خوادم منفصلة لا يعالج وحده أخطاء التحكم في الوصول داخل التطبيق.
تختلف احتياجات البيانات الحية والملفات والنسخ الاحتياطية. اربط قرارات الاحتفاظ والحذف والاستعادة بالتزامات منتجك تجاه العملاء.
02 / البنية
بنية توضيحية تفصل طلبات العملاء ومعالجة التطبيق والبيانات. يعتمد نشر المكونات ونطاق الخدمة على الإعداد الذي تختاره.
دليل الاختيار03 / دليل الاختيار
| معيار الاختيار | كيف تقرر؟ | لماذا يهم؟ |
|---|---|---|
| عزل العملاء | حدد المكونات المشتركة والمخصصة، وتحقق من هوية العميل في كل عملية وصول إلى البيانات. | حدود البنية لا تحل محل صلاحيات التطبيق. |
| السعة | قس سلوك المعالج والذاكرة والاستعلامات باستخدام بيانات ومسارات عمل تمثل العملاء. | قد يكشف العميل الأكثر نشاطا حدودا لا تظهر في المتوسطات. |
| استمرارية العمل | حدد مقدار فقد البيانات المقبول ووقت الاستعادة المستهدف باعتبارهما متطلبات عمل. | تحتاج إلى إجراء استعادة واضح إضافة إلى جدول النسخ الاحتياطي. |
| توزيع التكلفة | قيم الحوسبة والتخزين ونقل البيانات والخدمات الإضافية وفق سيناريوهات استخدام واقعية. | نمو عدد العملاء لا يرفع جميع عناصر التكلفة بالنسبة نفسها. |
04 / حالات الاستخدام
راقب مدة الطلبات والاستخدام المتزامن واتصالات قاعدة البيانات معا. حدد إن كان البطء من الحوسبة أو الاستعلامات أو خدمة خارجية قبل زيادة الموارد.
فكر في فصل التقارير والبريد واستيراد البيانات عن الطلبات التفاعلية. حدد طريقة التعامل مع تأخر المهام وإعادة المحاولة وتنفيذ المهمة نفسها أكثر من مرة.
تعامل مع ملفات العملاء بصورة مستقلة عن إصدارات التطبيق. اجعل الصلاحيات ومدة الاحتفاظ والاستعادة أساسا لاختيار التخزين.
05 / من التخطيط إلى التشغيل
سجل مكونات التطبيق وحدود بيانات العملاء والخدمات الخارجية. حدد المسؤول عن كل مكون والخطوات المطلوبة عند تعطل عمله.
افصل التطوير عن الإنتاج. ابدأ بتقدير للموارد ثم تحقّق بقياسات تطبيقك، دون اعتبار نتائج اختبارات تطبيقات أخرى دليلا على أدائه.
راجع تغييرات التطبيق وقاعدة البيانات معا. تحقق من توافق الإصدار السابق مع بنية البيانات الجديدة قبل الاعتماد على خطة الرجوع.
تابع زمن الاستجابة والمهام الفاشلة والسعة والضغط المرتبط بعملاء محددين. لا تربط قرار التوسع بإجمالي الزيارات وحده.
لا. قد يكون ترتيب أبسط للخوادم أنسب للتطبيق والفريق. قيم Kubernetes وفقا لاحتياجات النشر وخبرة التشغيل ومتطلبات التطبيق، ولا تعتبره شرطا لبدء خدمة SaaS.
لا توجد بنية واحدة تناسب الجميع. يعتمد الاختيار على العزل والحمل والتكلفة والمتطلبات التعاقدية. تبقى صلاحيات التطبيق ضرورية سواء كانت الموارد مشتركة أم منفصلة.
نطاق النسخة واتساق التطبيق عاملان أساسيان. راجع قاعدة البيانات والملفات والخدمات الخارجية معا، ثم اختبر إمكانية استعادة بيانات العميل المتوقعة فعليا.
حدد موارد الحوسبة اللازمة لمعالجة الطلبات وطريقة تخزين البيانات. قارن Shared CPU وDedicated CPU وخيارات التخزين وفق هذا الحمل، ثم راجع الإعدادات والأسعار الحالية.
اربط اختيار المنتجات بمعرفة التثبيت والإعداد والتشغيل.
تشرح هذه المراجع المفاهيم التقنية الواردة في الصفحة. تحدد معلومات منتجات FibaCloud والطلب التكوينات المتاحة ونطاق الخدمة.
FIBACLOUD / SaaS
شاركنا تطبيقك والاستخدام المتوقع واحتياجات التشغيل، لنناقش خيارات الموارد معًا.