لن نناقش ما إذا كانت بيئة PHP أو JSP أو .NET هنا. نحن ننظر إلى المشكلة من منظور الهندسة المعمارية. تنفيذ اللغة ليس مشكلة. تكمن ميزة اللغة في التنفيذ وليس جيدًا أو سيئًا. بغض النظر عن اللغة التي تختارها ، يجب أن تواجه الهندسة المعمارية.
1. معالجة البيانات الضخمة
كما نعلم جميعًا ، بالنسبة لبعض المواقع الصغيرة نسبيًا ، فإن كمية البيانات ليست كبيرة جدًا. حدد وتحديث يمكن أن يحل المشكلات التي نواجهها. الحمل نفسه ليس كبيرًا جدًا ، ويمكن القيام ببعض الفهارس على الأكثر. بالنسبة لمواقع الويب الكبيرة ، قد تكون كمية البيانات يوميًا الملايين. إذا كانت العلاقة التي تم تصميمها بشكل سيء للغاية لا توجد مشكلة في المرحلة المبكرة ، ولكن مع نمو المستخدم ، ستنمو كمية البيانات هندسيًا. في هذا الوقت ، عندما نختار وتحديث جدول (ناهيك عن الاستعلام المشترك للجداول المتعددة) ، تكون التكلفة مرتفعة للغاية.
2. معالجة تزامن البيانات
في مرحلة ما ، يحتوي 2.0 CTO على سيف Shangfang ، وهو ذاكرة التخزين المؤقت. بالنسبة إلى ذاكرة التخزين المؤقت ، إنها أيضًا مشكلة كبيرة عند تنفيذ التزامن العالي والمعالجة العالية. في التطبيق بأكمله ، تتم مشاركة ذاكرة التخزين المؤقت على مستوى العالم. ومع ذلك ، عندما نقوم بإجراء تعديلات ، إذا كان طلبان أو أكثر يتطلب تحديثات إلى ذاكرة التخزين المؤقت في نفس الوقت ، فسوف يموت التطبيق مباشرة. في هذا الوقت ، هناك حاجة إلى استراتيجية جيدة لمعالجة تزامن البيانات واستراتيجية التخزين المؤقت.
بالإضافة إلى ذلك ، فهي مشكلة قاعدة البيانات. ربما لا نشعر عادة أن احتمالية حدوث حالات الجمود في التزامن مرتفع للغاية ، وأن التخزين المؤقت للقرص يمثل مشكلة كبيرة.
3. مشكلات تخزين الملفات
بالنسبة لبعض المواقع التي تدعم ملفات الملفات 2.0 ، عندما نكون محظوظين لأن سعة القرص الصلب تزداد وأكبر ، يجب أن نفكر في كيفية تخزين الملفات وفهرستها بشكل فعال. الحل الشائع هو تخزين الملفات حسب التاريخ والنوع. ومع ذلك ، عندما يكون حجم الملف ضخمًا ، إذا كان القرص الثابت يخزن 500 جم من الملفات التافهة ، فإن IO من القرص يمثل مشكلة كبيرة أثناء الصيانة والاستخدام. حتى لو كان عرض النطاق الترددي كافيًا ، فقد لا يستجيب القرص الخاص بك. إذا كان التحميل متورطًا في هذا الوقت ، فسوف ينتهي القرص بسهولة.
ربما يمكن أن يؤدي استخدام خوادم التخزين المخصصة وخوادم التخزين المخصصة إلى حل المشكلة الحالية ، ولكن هناك مشكلة أخرى تتمثل في مشاكل الوصول في أماكن مختلفة. ربما يكون خادمنا في بكين ، ربما في سرعة وصول Yunnan أو Xinteng؟ إذا تم توزيعه ، فكيف ينبغي التخطيط لتفسير الملفات والهندسة المعمارية الخاصة بنا.
لذلك علينا أن نعترف بأن تخزين الملفات مشكلة صعبة للغاية
4. معالجة علاقات البيانات
يمكننا بسهولة التخطيط لقاعدة بيانات تتوافق مع العادي الثالث ، وهو مليء بالعلاقات العديدة إلى العدد ويمكن أن يحل أيضًا محل عمود indentify مع GUID. ومع ذلك ، في عصر 2.0 حيث يتم إغراق العلاقات العديدة إلى العدد ، والثالث الطبيعي هو الأول الذي ينبغي التخلي عنه. يجب تقليل استعلام المفصل متعدد الطاولة بشكل فعال.
5. مشكلة فهرسة البيانات
كما نعلم جميعًا ، فإن الفهرسة هي الحل الأكثر تكلفة وأسهل لتحسين استعلامات كفاءة قاعدة البيانات. ومع ذلك ، في حالة التحديث العالي ، ستكون تكلفة التحديث والحذف مرتفعة ولا يمكن تصورها. واجه المؤلف موقفًا حيث يستغرق الأمر 10 دقائق لإكماله عند تحديث فهرس مركّز ، لذلك بالنسبة للموقع ، لا يطاق بشكل لا يطاق.
الفهرسة والتحديث هي زوج من الأعداء الطبيعيين. الأسئلة A و D و E هي القضايا التي يتعين علينا مراعاتها عند القيام بالهندسة المعمارية ، وقد تكون أيضًا المشكلات التي تستغرق معظم الوقت.
6. المعالجة الموزعة
بالنسبة إلى 2.0 مواقع ويب ، نظرًا لتفاعلها العالي ، يكون التأثير الذي حققه CDN هو في الأساس 0 ، ويتم تحديث المحتوى في الوقت الفعلي ، وهو معالجتنا العادية. من أجل ضمان سرعة الوصول في أماكن مختلفة ، نحتاج إلى مواجهة مشكلة كبيرة ، أي كيفية تحقيق فعالية تزامن البيانات وتحديثها وتحقيق التواصل في الوقت الفعلي للخوادم في أماكن مختلفة يجب النظر فيها.
7. تحليل إيجابيات وسلبيات Ajax
النجاح هو Ajax ، الفشل هو Ajax ، وأصبح Ajax الاتجاه السائد ، ووجدت فجأة أن Post و Get على أساس XMLHTTP سهل للغاية. يحصل العميل على البيانات أو ينشرها إلى الخادم ، ويعيد الخادم بعد تلقي طلب البيانات. هذا هو طلب AJAX طبيعي جدا. ومع ذلك ، عند معالجة Ajax ، إذا استخدمنا أداة التقاط الحزم ، فإن إرجاع البيانات ومعالجتها واضحة في لمحة. بالنسبة لبعض طلبات Ajax ذات حجم حسابية عالية ، يمكننا إنشاء مقاول ، والذي يمكن أن يقتل خادم الويب بسهولة.
8. تحليل أمان البيانات
بالنسبة لبروتوكول HTTP ، يتم إرسال حزم البيانات في نص عادي. ربما يمكننا القول أنه يمكننا استخدام التشفير ، ولكن بالنسبة لمشكلة G ، قد تكون عملية التشفير نصًا عاديًا (على سبيل المثال ، QQ نعلم أنه يمكن أن يحكم بسهولة على تشفيره وكتابة طريقة تشفير وفك التشفير مثلها). عندما لا تكون حركة مرور موقعك كبيرة جدًا ، لن يهتم أحد بك ، ولكن عندما تظهر حركة المرور الخاصة بك ، فإن ما يسمى بالمكونات الإضافية وما يسمى بإرسال الكتلة ستتبع واحدة تلو الأخرى (يمكن رؤية القرائن من الكتلة التي ترسل في بداية QQ). ربما يمكننا أن نقول كثيرًا أنه يمكننا استخدام الأحكام ذات المستوى الأعلى أو حتى HTTPS لتحقيق ذلك. لاحظ أنه عند القيام بهذه المعالجة ، ستدفع الكثير من قواعد البيانات وتكاليف IO و CPU. بالنسبة لبعض عمليات البث الجماعية ، فمن المستحيل في الأساس. يمكن للمؤلف بالفعل تحقيق النشر الجماعي لـ Baidu Space و QQ Space. ليس من الصعب على الجميع تجربته.
9. مشاكل مزامنة البيانات ومعالجة الكتلة
عندما يكون أحد Databaseservers لدينا غارقًا ، نحتاج إلى إجراء أحمال ومجموعات قائمة على قاعدة البيانات. قد تكون هذه المشكلة الأكثر إثارة للقلق. تعتمد البيانات على نقل الشبكة. تأخير البيانات يمثل مشكلة فظيعة ومشكلة حتمية. وبهذه الطريقة ، نحتاج إلى استخدام وسائل أخرى لضمان التفاعل الفعال في غضون بضع ثوان أو أكثر من هذا التأخير. على سبيل المثال ، تجزئة البيانات والتجزئة ومعالجة المحتوى وغيرها من المشكلات.
10. قنوات مشاركة البيانات واتجاهات OpenAPI
أصبح Openapi اتجاهًا لا مفر منه ، من Google و Facebook و MySpace إلى الجامعات في المنزل ، ويتم النظر في هذه المشكلة. يمكن أن يحتفظ بالمستخدمين بشكل أكثر فعالية وتحفيز المزيد من الاهتمامات والسماح لمزيد من الأشخاص بمساعدتك في القيام بالتطور الأكثر فعالية. في هذا الوقت ، للحصول على منصة فعالة لمشاركة البيانات ، يصبح النظام الأساسي المفتوح للبيانات وسيلة لا غنى عنها. يعد ضمان أمان البيانات والأداء مع واجهات مفتوحة مشكلة أخرى يجب أن ننظر فيها بجدية.