تأثير الأداء على وجود طبقة/خدمة للوصول إلى البيانات؟

Question

أحتاج إلى تصميم نظام يحتوي على هذه المكونات الأساسية:

• خادم ويب سيحصل على 100 طلب/ثانية تقريبًا. يحتاج خادم الويب فقط إلى تفريغ البيانات في مستودع البيانات الخام.
• مستودع البيانات الخام الذي يحتوي على جدول واحد يحصل على 100 صف/S من خادم الويب.
• وحدة معالجة البيانات الخام (معالجة بسيطة ، وليس كثيرًا. إزالة البيانات الخام غير الصالحة ، وإدراج المكونات المفقودة في البيانات الأولية التالفة وما إلى ذلك)
• مستودع البيانات المعالجة

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

Answer 1

ماذا ترى تكاليف وجود طبقة خدمة منفصلة؟

كيف تقارن هذه التكاليف بالتكاليف يجب يتكبد؟ في حالتك يبدو أن على الأقل

1. قراءة شبكة للطلب
2. قاعدة بيانات تكتب للبيانات الأولية
3. قراءة قاعدة بيانات للبيانات الأولية
4. قاعدة بيانات للكتابة عن البيانات المصنعة

بالإضافة إلى بعض البيانات التي تتلاشى.

ما نوع الخدمات التي لديك عقل؟ ربما

• Saverawdata ()
• getNextrawdata ()
• WriteProcountData ()

لماذا تعتبر النفقات العامة أكثر من مجرد دعوة الإجراء؟ لا تحتاج الخدمة إلى "عملية منفصلة" أو "خدمة خدمة الويب".

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

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

Answer 2

إليك ما يمكن أن يحدث إلا إذا كنت تحرس ضده.

في التواصل بين الطبقات ، يتم اختيار بعض التنسيق ، مثل XML. ثم تقوم ببنائه وتشغيله واكتشاف الأداء غير مرضٍ.

ثم تعبث مع الباحثين الذين يتركونك تخمن ما هي المشكلة.

عندما عملت على مشكلة مثل هذه ، استخدمت تقنية Stackshot وسرعان ما وجدت المشكلة. كنت تعتقد أنه كان I/O. ليس. كان تحويل البيانات إلى XML ، وتحليل XML لاستعادة بنية البيانات ، كان يستغرق حوالي 80 ٪ من الوقت. لم يكن من الصعب جدًا إيجاد طريقة أفضل للقيام به الذي - التي. النتيجة - تسريع 5x.

Answer 3

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

يمكنك أن تبدأ بالبيانات عالية المستوى التالية التي يجب من خلالها بناء بنية النظام الخاصة بك حولها:

1. قم بتأكيد مجموعة المهارات الفنية لفريق التطوير وفريق العمليات/الدعم.
2. اتفق على قائمة أولية من الأنظمة التي ستدمج مع خدمتك ، والبروتوكولات التي تدعمها وبعض SLAs.
3. اتخاذ قرار بشأن استراتيجية المراسلة.
4. افهم كيف ستنشر خدمتك/نظامك.
5. قرر اختيار الوسيطة (ESBs ، وسطاء الرسائل ، وما إلى ذلك) ، وقواعد البيانات (SQL ، Oracle ، Memcache ، DB2 ، إلخ) وأدوات/أدوات الطرف الثالث.
6. قرر استراتيجية تأكيدك وتخزينك في زمن انتقال البيانات.
7. قم بتقسيم طلبك إلى مجالات مختلفة من مسؤولية العمل - سيتيح لك ذلك تقسيم العمل والسماح بتواصل أسهل للمعالم البارزة أثناء التطوير/الاختبار والتنفيذ.
8. تصميم كل مكون كما هو مطلوب لتلبية مجالات المسؤولية. يجب أن تقودك مجالات المسؤولية تلقائيًا إلى تحديد كيفية تصميم مكون أو تجميع أو خدمة.

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

حظا طيبا وفقك الله.

Answer 4

سوف يقدم التجريد والمستوى الكمون ، لكن السؤال الحقيقي هو ، ما الذي تكتسبه لجعل التكلفة (التكلفة) جديرة بالاهتمام؟ اقتران فضفاض ، الحوكمة ، قابلية التوسع ، الصيانة تستحق حقيقية.

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