هيكل مكدس ذاكرة مؤقتة لبدء التشغيل الأساسي

Azure App Service
Azure Blob Storage
Azure Content Delivery Network
Azure Database for PostgreSQL
Azure Virtual Network

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

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

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

حالات الاستخدام المحتملة

تقدم هذه المقالة مثالا على مكدس الذاكرة المؤقتة لبدء التشغيل الأساسي البسيط، وتناقش مكوناته.

الهندسة

قامت شركة ناشئة، Contoso، ببناء نموذج أولي للتطبيق مع خلفية Ruby on Rails وواجهة أمامية React مكتوبة بلغة TypeScript. يقوم فريق Contoso بتشغيل عروض توضيحية على أجهزة الكمبيوتر المحمولة الخاصة بهم. الآن يريدون توزيع تطبيقهم لأول اجتماعات مبيعات العملاء.

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

Diagram that shows the core startup stack architecture Contoso used to deploy their application.

قم بتنزيل ملف Visio لهذه البنية.

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

في هيكل مكدس الذاكرة المؤقتة لبدء التشغيل الأساسي هذا:

  • توفر خدمة Azure App Service خادم تطبيق بسيط لتوزيع تطبيقات قابلة للتوسع دون تكوين الخوادم أو موازنات التحميل أو البنية الأساسية الأخرى.
  • قاعدة بيانات Azure لـ PostgreSQL هي خدمة قاعدة بيانات Azure لنظام إدارة قاعدة بيانات ارتباطية ذي مصدر مفتوح رائد (RDBMS). يمكنك التركيز على تطوير التطبيق الخاص بك بدلاً من إدارة خوادم قاعدة البيانات.
  • تقسم شبكة Azure الظاهرية نسبة استخدام الشبكة وتحافظ على حماية الخدمات الداخلية من تهديدات الإنترنت. تستخدم خوادم التطبيقات الخاصة بك تكامل الشبكة الظاهرية للاتصال بقاعدة البيانات دون التعرض للإنترنت.
  • تنشئ إجراءات GitHub التكامل المستمر والتوزيع المستمر (CI/CD) في إدارة التعليمات البرمجية المصدر. تتمتع إجراءات GitHub بدعم واسع للغات مختلفة، والتكامل القوي مع خدمات Azure.
  • يخزن Azure Blob Storage الأصول الثابتة وينقل التحميل بعيداً عن خوادم التطبيق.
  • تقوم شبكة تسليم المحتوى من Azure (CDN) بتسريع تسليم المحتوى للمستخدمين من خلال شبكة عمومية.
  • يقوم Azure Monitor بمراقبة وتحليل ما يحدث عبر البنية الأساسية للتطبيق الخاص بك.

مكونات مكدس الذاكرة المؤقتة لبدء التشغيل الأساسي

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

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

A block diagram that shows a core startup stack.

شبكة تسليم المحتوى

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

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

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

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

المحتوى الثابت

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

قاعدة بيانات

بمجرد تشغيل تطبيقك، تحتاج إلى تخزين بياناتك في قاعدة بيانات. بالنسبة لمعظم الحالات، قاعدة البيانات الارتباطية هي الحل الأفضل. تحتوي قاعدة البيانات الارتباطية على أساليب وصول متعددة وسرعة حل اختبار الوقت. تتضمن قاعدة البيانات الارتباطية قاعدة بيانات Azure SQL وقاعدة بيانات Azure لـ PostgreSQL وقاعدة بيانات Azure لـ MariaDB. تحتاج بعض حالات الاستخدام إلى قاعدة بيانات مستند أو قاعدة بيانات NoSQL مثل MongoDB أو Azure Cosmos DB.

تجميع السجل

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

CI/CD

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

نشر هذا السيناريو

المفاهيم والتقنيات هي نفسها لمعظم المشاريع التي تقوم بإنشائها باستخدام Dockerfile.

المساهمون

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

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

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