يلزم إنشاء العديد من التطبيقات الحديثة عبر المؤسسة ، وأحيانًا عبر الإنترنت. يجب أن يفي كل تطبيق بمتطلبات قابلية التوسع والتوافر والأمان والموثوقية والمرونة.
في هذه المقالة ، سأقدم بعض أنماط التصميم التي يمكن أن تساعدك بسهولة في تحقيق الإمكانات المذكورة أعلاه. سأغطي كل نمط ، وكيفية استخدام هذا النمط في السحابة ، ومتى يتم استخدامه ومتى لا.
بعض هذه الأنماط ليست جديدة تمامًا ، ولكنها مفيدة جدًا في عالم سحابة الإنترنت اليوم.
فيما يلي قائمة بالأنماط التي سأناقشها في هذه المقالة:
- قاطع دائرة
- الفصل بين مسؤولية الأوامر والاستعلام (CQRS)
- مصادر الحدث
- Sidecar
- الواجهة الخلفية للواجهة الأمامية
- الخانق
اذا هيا بنا نبدأ.
1. قواطع دوائر
يجب تصميم الأنظمة الموزعة مع وضع الأعطال في الاعتبار. هناك خدمات مصغرة في العالم في الوقت الحاضر ، وتعتمد هذه الخدمات بشكل أساسي على خدمات أخرى بعيدة. قد لا تستجيب هذه الخدمات البعيدة في الوقت المناسب لأسباب مختلفة مثل الشبكة وتنزيل التطبيقات وما إلى ذلك. في معظم الحالات ، يجب أن يكون تنفيذ عمليات إعادة المحاولة قادراً على حل المشكلات.
ولكن في بعض الأحيان يمكن أن تكون هناك مشاكل خطيرة مثل تدهور الخدمات أو الفشل الكامل للخدمات في حد ذاته. ليس من المنطقي الاستمرار في المحاولة مرة أخرى في مثل هذه الحالات. في هذه الحالة ، يمكن أن يكون نموذج قاطع الدائرة مفيدًا.
يوضح الرسم البياني أعلاه تنفيذ دارة قاطع الدائرة حيث عندما تدرك الخدمة 1 أن خدمة الاتصال 2 بها حالات فشل / مهلات مستمرة بدلاً من إعادة المحاولة ، تقوم الخدمة 1 بقطع الاتصال بالخدمة 2 وإرجاع استجابة في حالة الفشل.
توجد مكتبات شائعة مفتوحة المصدر مثل Netflix Hystrix
أو Reselience4J والتي يمكن استخدامها لتنفيذ هذا النمط بسهولة بالغة.
إذا كنت تستخدم بوابات API أو وكلاء
مثل Envoy ، فيمكن تحقيق ذلك على مستوى الوكيل نفسه.
ملحوظة:من المهم جدًا تنفيذ ما يكفي من السجلات والتحذيرات عندما تكون السلسلة مفتوحة لتتبع الطلبات المستلمة خلال هذا الوقت وأن يكون فريق العمليات على علم بذلك.
يمكنك أيضًا تنفيذ قاطع نصف دائرة لمواصلة خدمة العملاء مع ضعف الخدمة.
متى تستخدم هذا النمط
- عندما تعتمد خدمة ما على خدمة أخرى عن بعد ، وفي بعض السيناريوهات ، من المحتمل أن تفشل.
- عندما يكون للخدمة تبعية قوية جدًا (مثل خدمات البيانات الرئيسية).
عندما لا تستخدم هذا النمط
- عند التعامل مع التبعيات المحلية ، يمكن لقاطع الدائرة الكهربائية إنشاء عبء.
2. Command and Query Responsibility Segregation (CQRS) ( (CQRS))
CQRS هو نموذج مفيد للغاية لتطبيقات مستودعات البيانات الحديثة. وهو يقوم على مبدأ فصل عمليات القراءة (الاستعلام) والكتابة / التحديث (الأمر) في مخزن البيانات.
لنفترض أنك تبني تطبيقًا يتطلب تخزين البيانات في قاعدة بيانات مثل MySQL / PostgreSQL ، إلخ. كما يعلم الجميع ، عند كتابة البيانات إلى التخزين ، يجب أن تمر العملية بعدة مراحل - على سبيل المثال ، التحقق من الصحة والنمذجة والمثابرة - وبالتالي تستغرق عمليات الكتابة / التحديث النموذجية وقتًا أطول من عمليات القراءة البسيطة.
عند استخدام مخزن بيانات واحد لإجراء عمليات القراءة والكتابة في نفس الوقت وعلى نطاق واسع ، يمكنك البدء في رؤية مشكلات الأداء.
في مثل هذه الحالات ، يمكن أن يكون نموذج CQRS مفيدًا. يقترح نمط CQRS استخدام نماذج بيانات مختلفة لعمليات القراءة والكتابة. تقترح بعض الاختلافات أيضًا استخدام مخازن بيانات منفصلة لهذه النماذج.
ملاحظة: توفر معظم قواعد بيانات PaaS هذه الأيام القدرة على إنشاء نسخ متماثلة قابلة للقراءة ( Google Cloud SQL و Azure SQL DB و Amazon RDS
وما إلى ذلك) لمخازن البيانات ، مما يسهل كثيرًا تحقيق نسخ البيانات.
توفر العديد من قواعد بيانات المؤسسة أيضًا هذه الإمكانية إذا كنت تتعامل مع قواعد بيانات محلية.
ملاحظة: يختار بعض الأشخاص هذه الأيام أيضًا تنفيذ نسخ متماثلة قابلة للقراءة كقواعد بيانات NoSQL سريعة وفعالة مثل MongoDB و Elasticsearch.
متى تستخدم هذا النمط
- عندما تنظر إلى توسيع نطاق تطبيق تتوقع قدرًا هائلاً من عمليات القراءة والكتابة
- عندما تريد إعداد عمليات القراءة والكتابة بشكل منفصل.
- عندما تكون عمليات القراءة الخاصة بك قريبة من الحقيقة أو متسقة في النهاية.
عندما لا تستخدم هذا النمط
- عندما تقوم ببناء تطبيق CRUD عادي لا يتوقع قدرًا كبيرًا من عمليات القراءة والكتابة دفعة واحدة.
3. مصادر الحدث
مصدر الحدث هو نمط تصميم مثير للاهتمام يتم فيه تخزين سلسلة من أحداث المجال كسجل ، ويعطي عرض السجل المجمع الحالة الحالية للتطبيق.
يستخدم هذا النمط بشكل شائع للأنظمة التي لا تستطيع تحمل تكاليف أقفال تخزين البيانات والتي تحتاج إلى الاحتفاظ بسجل التدقيق والأحداث - على سبيل المثال ، التطبيقات مثل حجز الفنادق / المؤتمرات / المقاعد.
نظرًا لنظام حجز غرف الفندق حيث من المتوقع أن يقوم المستخدمون بالحجز أو إلغاء الحجز. هنا تحتاج إلى تخزين الحجز والإلغاء كسلسلة من الأحداث. يتم عرض الغرف المتاحة في ملخص قبل كل حجز من خلال مراجعة سجلات الأحداث.
ملحوظة:يدعم معظم مزودي الخدمات السحابية خدمات المراسلة مثل Google Pub / Sub و Azure Service Bus و AWS SQS وما إلى ذلك. يمكن استخدام هذه الخدمات ، جنبًا إلى جنب مع مخازن البيانات القوية المتسقة ، لتنفيذ هذا المخطط.
متى تستخدم هذا النمط
- عندما لا تكون عمليات CRUD العادية جيدة بما يكفي لتلبية المتطلبات
- مناسب عادة لأنظمة حجز المقاعد مثل الحافلات والقطارات والمؤتمرات ودور السينما ، إلخ. - أو لأنظمة التجارة الإلكترونية ، والتي تتكون من أنشطة مثل عربات التسوق والمدفوعات وما إلى ذلك.
- عندما تكون هناك حاجة للتدقيق القوي وإعادة تشغيل الأحداث لإنشاء الحالة الحالية والسابقة للتطبيقات.
عندما لا تستخدم هذا النمط
- عندما تكون عمليات CRUD العادية جيدة بما يكفي لتلبية احتياجات المستخدم.
4. Sidecar (نمط تصميم Sidecar)
أصبح نمط Sidecar شائعًا مع ظهور الخدمات المصغرة. في هذا المخطط ، يتم نشر مكون التطبيق في عملية أو حاوية منفصلة. هذا يساعد على تحقيق التجريد والتغليف.
Envoy Proxy هو أحد أكثر خوادم بروكسي sidecar شيوعًا ويستخدم على نطاق واسع. يساعدك على فصل الوظائف الرئيسية للتطبيق عن طريق استخدام آلة جانبية لعزل الوظائف الشائعة مثل الشبكات وإمكانية المراقبة والأمان.
يمكن أن يساعد هذا النوع من السيارات الجانبية في نوع الاتصال المجرد L4 / L7. تساعد العروض الجانبية مثل Envoy Proxies في تحقيق مستوى أمان أعلى من خلال تطبيق TLS المتبادل.
يمكنك استخدام هذا مع شبكة خدمة لتحقيق اتصال وأمان أفضل بين الخدمات المصغرة المختلفة. يمكنك قراءة المزيد عن هذا في مقالتي السابقة .
متى تستخدم هذا النمط
- عندما تتعامل مع العديد من الخدمات الصغيرة وغير المتجانسة في مجموعة منتجات.
- عند التعامل مع التطبيقات القديمة التي تميل إلى الفشل في التعامل مع قابلية التشغيل البيني وتحديات الأمان في العصر الجديد.
عندما لا تستخدم هذا النمط
- عندما تتعامل مع عدد محدود من الخدمات التي تحتاج إلى التواصل مع بعضها البعض.
- التطبيقات الصغيرة حيث قد يكون نشر الكراسي المتحركة الجانبية غير اقتصادي أو غير مريح للعمل
5. Backend-for-Front (BFF)
في دورة تطوير المنتج النموذجية ، يكون مهندسو الواجهة الخلفية مسؤولين عن إنشاء خدمات تتفاعل مع مستودعات البيانات ، بينما يهتم مهندسو الواجهة الأمامية بإنشاء واجهات مستخدم. يجب تصميم التطبيقات في هذه الأيام مع وضع كل من الأجهزة المحمولة وسطح المكتب في الاعتبار.
بينما تقترب الفجوة بين الأجهزة المحمولة وأجهزة سطح المكتب من حيث الأجهزة ، لا يزال الاتصال والاستخدام يمثلان تحديًا للأجهزة المحمولة.
في مثل هذه السيناريوهات ، تصبح قوالب BFF سهلة الاستخدام. هنا ، يُتوقع منك إنشاء / تكوين خدمات داخلية لواجهة أمامية محددة.
لتحسين أداء عملاء الأجهزة المحمولة ، قد ترغب في إنشاء خدمة خلفية منفصلة تستجيب بردود خفيفة ومرقمة.
قد ترغب أيضًا في استخدام هذا النمط لتجميع خدمات متنوعة لتقليل اتصال البيانات بين الواجهة الخلفية والواجهة الأمامية.
ملاحظة: في هذه الأيام ، إذا كنت تستخدم بوابة API ، فيمكن تنفيذ نمط BFF بسهولة في البوابة نفسها ، ولن تحتاج إلى تقديم خدمات منفصلة.
متى تستخدم هذا النمط
- عندما تريد تقديم منتج / خدمة للعديد من العملاء مثل عملاء سطح المكتب والأجهزة المحمولة.
- عندما تريد تحسين استجابتك لنوع معين من العملاء.
- عندما تريد الحد من الدردشة بين عملاء الهاتف المحمول والخدمات المختلفة.
- , .
- , .
6. Strangler ( )
إذا كنت تعمل في مؤسسة في طريقها إلى تحديث التطبيقات ، فإن نمط تصميم Strangler أمر لا بد منه. يدعو نمط Strangler إلى إنشاء تراكب واجهة فوق تطبيقك القديم والجديد ، مما يمنح المستهلكين القدرة على النظر إلى الأشياء بموضوعية.
يفصل هذا النمط العملاء عن نشاط الترحيل بين الأجزاء القديمة والجديدة من التطبيق.
ملاحظة: في مؤسسة تقنية معلومات نموذجية ، إذا كنت تقوم بالترحيل من نظام ERP إلى آخر ، فسيكون هذا النوع من المخططات مفيدًا للغاية. إذا كنت تستخدم بوابة API ، فسيكون من الأسهل تنفيذ ذلك في بوابة الوكيل نفسها.
تحتاج إلى تحديد ما إذا كنت تريد الاحتفاظ بالوظيفة الإضافية (الواجهة) في نهاية الترحيل أو إزالتها.
متى تستخدم هذا النمط
- عندما تقوم بترحيل أو ترقية تطبيق معقد شديد الاعتماد مثل ترحيل ERP
عندما لا تستخدم هذا النمط
- عندما يكون الترحيل سهلاً ويكون الاستبدال المباشر هو الخيار الأفضل.