قائمة مراجعة هندسة البرمجيات الخلفية: كيفية بناء منتج من الصفر

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

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

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

من أين جاء هذا الدليل

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

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

قررت أخيرًا إنشاء قائمة التحقق هذه للأشياء التي يجب مراعاتها قبل الضغط على زر النشر هذا لأول مرة.

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

اختر اللغة وإطار العمل الصحيحين (لمشروعك)

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

بعد قولي هذا ، يعد هذا نادرًا ، نظرًا لوجود عدد قليل جدًا من الأشخاص من Javascript Ninjas أو Python Panthers أو أي أسماء غير تقليدية موجودة هناك.

لذا اختر لغة تتمتع ببعض الدعم الجيد الحقيقي في الصناعة ، مثل Javascript أو Python أو Java أو Go على سبيل المثال لا الحصر. يمكنك اختيار أي لغة ، ما عليك سوى اختيار اللغة الأكثر راحة لك.

وتذكر - أنت تقوم ببناء MVP (الحد الأدنى من المنتج القابل للتطبيق) ، وستكون في طور إنشاء POC (إثبات المفهوم). لذا قم بإخراج منتجك في أسرع وقت ممكن. لا تحتاج إلى أن تتعثر في المشكلات التي قد تأتي من اللغة الجديدة في المدينة. لتجنب هذه المشكلات ، اختر لغة مستخدمة على نطاق واسع وموثقة جيدًا.

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

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

مورد جيد لمساعدتك على اتخاذ القرار -

//content.techgig.com/top-5-programming-languages-for-backend-web-development/articleshow/67337449.cms

تنفيذ خدمات المصادقة والتفويض المصغرة

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

رموز الويب JSON

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

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

لذا اكتشف إيجابيات وسلبيات كل نظام مصادقة واختر النظام الذي يناسب متطلباتك. أنا شخصياً أفضل JWTs (ولكن هذا هو خياري الخاص).

تفويض

لا تنس أبدًا تنفيذ إذن المستخدمين. لا تريد تسجيل الدخول User1 لتغيير تفاصيل User2. هذا يمكن أن يسبب فوضى نقية في نظامك.

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

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

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

ألق نظرة على مورد إطار عمل Django REST -

//www.django-rest-framework.org/tutorial/4-authentication-and-permissions/

قم بإنشاء نموذج قاعدة مجردة ليتم توريثه بواسطة كل نموذج آخر في قاعدة البيانات الخاصة بك

تذكر مبدأ الجفاف - لا تكرر نفسك؟ يجب أن يتبع ذلك حتى صميم هندسة البرمجيات.

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

لننتقل إلى هذا الكود وما يعنيه:

  • معرف - على الرغم من أنه لم يكتب هنا ، إلا أنه تم إنشاؤه تلقائيًا بواسطة إطار عمل Django. ولكن إذا لم يكن موجودًا في صفك ، فقم بتدوينه في هذا الفصل. إنه مجرد حقل متزايد تلقائيًا يمكن استخدامه كمفتاح أساسي في علاقة قاعدة البيانات الخاصة بك.
  • Creat_at - يشير هذا إلى وقت إدراج الحقل / الصف في الجدول الخاص بك ، ويتم ملؤه بواسطة إطار العمل نفسه. لا تحتاج إلى تعيينه صراحة.
  • updated_at - يشير هذا إلى وقت آخر تعديل / تحديث للحقل / الصف في الجدول الخاص بك ، ومرة ​​أخرى يتم ملؤه بواسطة إطار العمل نفسه.
  • delete_at + is_deleted - إذن هذا مجال مثير للجدل. ليس لدي إجابة دقيقة عما إذا كان يجب أن يكون موجودًا أم لا - لأكون صادقًا ، لا يتم حذف أي شيء على الإنترنت. يوضح هذا الحقل ، إذا تم ملؤه ، أنه تم حذف الصف من النظام (على الرغم من بقاء البيانات في النظام للمراجع المستقبلية ويمكن إزالتها من قاعدة البيانات وتخزينها في نسخ احتياطية)
  • uuid - يعتمد ذلك على ما إذا كنت تريد وضع هذا في الجدول الخاص بك أم لا. إذا كنت بحاجة إلى تعريض المفتاح الأساسي للجدول إلى نظام خارجي ، فمن الأفضل عرض هذا المفتاح بدلاً من حقل العدد الصحيح المتزايد تلقائيًا. قد تتساءل لماذا ...؟ حسنًا ، لماذا تريد إخبار نظام خارجي بأن لديك 10378 طلبًا في طاولتك؟ لكن مرة أخرى إنه اختيار شخصي.

إعداد خدمة مصغرة للإعلام

يحتاج كل منتج إلى إرسال تذكيرات وإشعارات إلى المستخدم لأغراض المشاركة والمعاملات. لذلك كل منتج سيحتاج هذا.

يجب عليك بالتأكيد التفكير في إنشاء خدمة صغيرة توفر خدمات الإعلام (مثل الإشعارات الفورية ورسائل البريد الإلكتروني والرسائل النصية القصيرة) للمستخدمين النهائيين.

يجب أن تكون هذه خدمة Microservice منفصلة تمامًا. لا تقم ببناء هذا داخل خدمة المصادقة المصغرة الخاصة بك أو خدمة التطبيق الخاصة بك (منطق الأعمال الفعلي).

هناك الكثير من مكتبات / خدمات الجهات الخارجية التي يمكن استخدامها لإنشائها لتطبيقك. الاستفادة منها وبناءها فوق ذلك.

تذكر بناء جميع الوظائف الثلاث:

  • دفع الإخطارات (APNS + FCM) ،
  • رسائل البريد الإلكتروني (فقط قم بدمج عميل SMTP للبدء)
  • و SMS

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

طريقة سهلة لتهيئة عميل SMTP الخاص بك في تطبيقك تستخدم هذا في إعداداتك:

لقد فعلت ذلك في Django ، لكن يمكنك أن تفعل الشيء نفسه في اللغة والإطار الذي اخترته.

إعداد تسجيل الأخطاء

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

هناك الكثير من أدوات تسجيل الأخطاء للجهات الخارجية في السوق. ما عليك سوى اختيار أي واحد يناسب متطلباتك. أنا في الغالب أستخدم Sentry / Airbrake.

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

الصفحة الرئيسية الرسمية لشركة Airbrake - //airbrake.io/

الصفحة الرئيسية الرسمية لـ Sentry - //sentry.io/welcome/

تنفيذ الطلب - الاستجابة وتسجيل التطبيق

السيناريو - يأتي المستخدم على دعمك ويقول إنه لم يتلق إيصال المعاملة لعملية الشراء التي أجراها على موقع الويب الخاص بك. ماذا ستفعل؟

إذا قمت بوضع Application Logging في نظامك ، فلا داعي للقلق. الآن ماذا أعني بذلك؟ من الأفضل دائمًا عرض مثال بدلاً من محاولة الشرح بالكلمات. حتى هنا هو عليه:

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

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

يعد ELK stack خيارًا جيدًا لهذا: ElasticSearch - Logstash - Kibana.

المزيد عن ELK stack - //www.elastic.co/what-is/elk-stack

ملاحظة - أثناء تسجيل الطلبات والردود ، احرص على ما يلي:

  • لا تسجل كلمات المرور.
  • لا تقم بتسجيل الرموز المميزة (رموز الوصول المستخدمة للمصادقة)
  • لا تسجل OTPs

قم بإدخال الاختناق في واجهات برمجة التطبيقات الخاصة بك والحد من المعدل على خوادم التطبيق

السيناريو - لقد أطلقت للتو خدمتك وقمت بتسويق المنتج على منصات التواصل الاجتماعي. اكتشف مخترق القبعة السوداء ذلك ، وأراد فقط اللعب بنظامك. لذلك خططوا لهجوم DOS (رفض الخدمة) على نظامك.

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

السيناريو - نقطة نهاية API / otp / التحقق من صحة تأخذ 4 أرقام OTPs لمصادقة المستخدم وتعطي الرموز المميزة لاستخدامها لواجهات برمجة التطبيقات المصادق عليها. يحصل المستخدم الضار على رقم mobile_number لأحد عملائك ، ويبدأ في الوصول إلى نقطة نهاية واجهة برمجة التطبيقات مع هجوم القوة الغاشمة الذي يغير عناوين IP ، وهو هجوم DDOS (رفض الخدمة الموزع). محدد المعدل غير قادر على إيقاف المستخدم ، لأن عنوان IP يتغير باستمرار مع كل طلب يتم تقديمه.

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

الاختناق في إطار عمل REST لـ Django -

//www.django-rest-framework.org/api-guide/throttling/

إنشاء وتكوين اتصال غير متزامن من اليوم الأول

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

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

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

أحد الأمثلة الجيدة على ذلك من عالم بايثون هو عامل الكرفس. فقط ضع المهمة التي يجب أداؤها في وسيط الرسائل (Rabbit MQ / SQS ، إلخ). سيستمع الكرفس إلى هذا ويرسل المهمة إلى العامل المعين. سيقوم هذا العامل بعد ذلك بمعالجة الطلب ووضع النتيجة في خلفية النتيجة التي يمكن أن تكون نظام ذاكرة التخزين المؤقت / نظام قاعدة البيانات. (Redis / PostgreSQL على سبيل المثال).

يمكنك مراقبة هذه المهام وقوائم الانتظار مع الكثير من مكتبات الطرف الثالث. وخير مثال على ذلك هو زهرة الكرفس التي تراقب كل هذا.

يمكنك قراءة المزيد عن RabbitMQ هنا - //www.rabbitmq.com/

والكرفس - //docs.celeryproject.org/en/stable/django/first-steps-with-django.html

وأخيرًا ، زهرة الكرفس - //flower.readthedocs.io/en/latest/

قم بإعداد وظائف كرون

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

يمكن تنفيذ المهمة أعلاه بسهولة باستخدام وظيفة cron. يمكن تكوينه بسهولة في كل إطار. الشيء المهم الذي يجب أن تضعه في الاعتبار هو أنه لا يجب وضع وظائف cron مباشرة في ملف crontab لخادمك. يجب أن تدع الإطار يتعامل معه.

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

في عالم Django ، يمكنك استخدام داء الكرفس لتكوين حباتك باستخدام عمال الكرفس.

تعرف على المزيد حول ضربات الكرفس هنا - // docs.celeryproject.org/en/latest/userguide/periodic-tasks.html

إدارة أسرارك بشكل صحيح (ملف المعلمات)

هناك العديد من الطرق لإدارة أسرار المعلمات في خوادم الإنتاج. ومنهم:

  • إنشاء ملف سر وتخزينه في حاوية s3 خاصة ، وسحبها أثناء نشر التطبيق الخاص بك.
  • تعيين المعلمات في متغيرات البيئة أثناء نشر التطبيق الخاص بك (تخزينها في s3 مرة أخرى)
  • كشف الأسرار في بعض خدمات الإدارة السرية (على سبيل المثال //aws.amazon.com/secrets-manager/) ، واستخدامها للحصول على الأسرار في تطبيقك.

يمكنك اختيار أي من هذه الطرق وفقًا لراحتك وحالة الاستخدام. (يمكنك اختيار الاحتفاظ بملفات سرية مختلفة للبيئات المحلية والتشغيلية والإنتاجية أيضًا.)

إصدار واجهات برمجة التطبيقات الخاصة بك من اليوم الأول

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

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

اتخذ قرارًا بشأن عمليات التحقق من إصدار التحديثات الثابتة واللينة لعملاء الواجهة الأمامية

إذن ما الفرق بين التحديثات الثابتة واللينة؟

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

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

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

يمكنك القيام بذلك عن طريق تنفيذه أو تكوينه في متجر Play أو متجر التطبيقات. هناك طريقة أخرى وهي إنشاء واجهة برمجة تطبيقات في تطبيق الواجهة الخلفية الخاص بك والتي سيتم ضربها في كل مرة يتم فيها تشغيل تطبيق الهاتف المحمول. سيؤدي ذلك إلى إرسال مفتاحين: hard_update -> true / false و soft_update -> true / false ، اعتمادًا على إصدار المستخدم وإصدارات التحديث الثابتة واللينة المحددة في نظام الواجهة الخلفية.

مكان جيد لتخزين هذه الإصدارات هو في ذاكرة التخزين المؤقت (Redis / Memcache) ، والتي يمكنك تغييرها بسرعة دون الحاجة إلى نشر تطبيقك.

أدخل التكامل المستمر (CI) من اليوم الأول

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

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

هناك الكثير من الخيارات المتاحة في السوق. يمكنك إما اختيار تنفيذ أحدهما بنفسك (Jenkins CI / CD) ، أو يمكنك استخدام TravisCI و CircleCI وما إلى ذلك لنفسه.

اقرأ على TravisCI هنا - //travis-ci.org/

و CircleCI - //circleci.com/

تمكين دعم Docker (تفضيل شخصي)

قم بإنشاء Dockerfile و docker-compose.yml لتطبيقك بحيث يقوم الجميع بتشغيل التطبيق باستخدام Docker منذ البداية. أحد الأسباب الرئيسية لاستخدام مثل هذا النهج هو أن يكون لديك تناسق عبر البيئة المحلية / المرحلية / الإنتاج ، بحيث لا يمكن لأي مطور أن يقول هذا مرة أخرى:

لكنها ركضت على جهازي.

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

إليك مزيد من المعلومات حول Docker Hub - //hub.docker.com/

استخدم أداة APM

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

السيناريو - القرص الصلب لخادم cron الخاص بك ممتلئ تقريبًا ولا يمكنه تشغيل مهام cron. نظرًا لأنه لا يمكن العثور على مساحة على القرص ، فإن crons لا تعمل. إذن كيف يتم إخطارك عند حدوث ذلك؟

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

اقرأ المزيد عن New Relic هنا - //newrelic.com/

استخدم ElasticSearch لتشغيل عمليات البحث على مستوى التطبيق في تطبيقات العميل

حسب ويكيبيديا ،

Elasticsearch هو محرك بحث يعتمد على مكتبة Lucene. إنه يوفر محرك بحث نص كامل موزع وقادر على تعدد المستأجرين مع واجهة ويب HTTP ومستندات JSON خالية من المخططات. تم تطوير Elasticsearch في Java.

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

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

فيما يلي نظرة عامة جيدة على Elasticsearch لتبدأ.

ومستندات ElasticSearch - //www.elastic.co/guide/index.html

ضع جدار حماية في خادم الإنتاج الخاص بك

يجب عليك بالتأكيد القيام بذلك - إنه أمر لا بد منه. ضع جدارًا ناريًا في خادم الإنتاج الخاص بك وأغلق جميع المنافذ باستثناء تلك التي سيتم استخدامها لواجهات برمجة التطبيقات (اتصالات https). قم بتوجيه نقاط نهاية API باستخدام خادم ويب وكيل عكسي ، مثل NGiNX أو Apache. يجب ألا يكون أي منفذ متاحًا للوصول إلى العالم الخارجي بخلاف تلك التي تسمح بها NGiNX.

لماذا يجب عليك استخدام NGiNX:

  • //www.nginx.com/resources/wiki/community/why_use_it/
  • //blog.serverdensity.com/why-we-use-nginx/
  • //www.freecodecamp.org/news/an-introduction-to-nginx-for-developers-62179b6a458f/

تغليف

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

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

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