مقدمة
من أجل حل المشكلات المختلفة التي يلفها نموذج تطوير الويب التقليدي ، قمنا بتجهيز العديد من المحاولات ، ولكن بسبب الفجوة المادية بين النهايات الأمامية والخلفية ، فإن الحلول التي جربناها متشابهة. التعلم من الألم ، اليوم نعيد التفكير في تعريف "الواجهة الأمامية والخلفية" ونقدم Nodejs ، وهو مألوف للطلاب الأماميين ، في محاولة لاستكشاف وضع الفصل الأمامي الجديد.
مع ظهور المحطات المختلفة (PAD/Mobile/PC) ، فإن المطورين لديهم متطلبات عالية بشكل متزايد. لم تعد استجابة جانب المتصفح الخالص تلبية المتطلبات العالية لتجربة المستخدم. غالبًا ما نحتاج إلى تطوير إصدارات مخصصة للمحطات المختلفة. من أجل تحسين كفاءة التنمية ، يتم تقييم الحاجة إلى فصل النهايات الأمامية والخلفية بشكل متزايد. النهاية الخلفية هي المسؤولة عن واجهات الأعمال/البيانات ، والطرف الأمامي مسؤول عن منطق العرض/التفاعل ، ويمكننا تخصيص وتطوير إصدارات متعددة من واجهة البيانات نفسها.
تمت مناقشة هذا الموضوع كثيرًا مؤخرًا ، وبعض حافلات Alibaba تقوم أيضًا ببعض المحاولات. بعد مناقشة طويلة ، قرر فريقنا استكشاف مجموعة من مخطط الفصل بين الواجهة الأمامية والخلفية على أساس NodeJs. كان هناك بعض التفاهمات والأفكار المتغيرة في هذه العملية. لقد سجلته هنا. آمل أيضًا أن يشارك الطلاب الذين رأيتهم في المناقشة وساعدنا في تحسينه.
1. ما هو الفصل الأمامي؟
خلال المناقشة الأولية داخل المجموعة ، وجدت أن كل شخص لديه فهم مختلف للفصل الأمامي. من أجل التأكد من تمكنهم من مناقشة نفس القناة ، سنصل أولاً إلى اتفاق حول ماهية "فصل الظهير الأمامي".
مثال على الفصل الأمامي الذي يتفق عليه الجميع هو SPA (تطبيق صفحة واحدة). يتم توفير جميع بيانات العرض التقديمي المستخدمة بواسطة الواجهة الخلفية من خلال الواجهة غير المتزامنة (AJAX/JSONP) ، ويعرضها الواجهة الأمامية فقط.
بمعنى ما ، يحقق SPA فصلًا أماميًا ، ولكن هناك مشكلتان في هذه الطريقة:
من بين خدمات الويب ، تمثل سبا نسبة صغيرة جدًا. في العديد من السيناريوهات ، يوجد أيضًا وضع هجين متزامن/متزامن + غير متزامن ، ولا يمكن استخدام SPA كحل عام.
في نموذج تطوير السبا الحالي ، يتم توفير الواجهة عادة وفقًا لمنطق العرض. في بعض الأحيان ، من أجل تحسين الكفاءة ، ستساعدنا الواجهة الخلفية في التعامل مع بعض منطق العرض ، مما يعني أن الواجهة الخلفية لا تزال متورطة في عمل طبقة العرض ، وليس الانفصال الحقيقي للواجهة الأمامية والخلفية.
يتم تمييز الفصل الأمامي على غرار SPA عن الطبقة المادية (أعتقد أنه طالما أنه العميل ، الواجهة الأمامية ، والخلفية الخلفية هي الخادم). لم يعد بإمكان هذا التصنيف تلبية احتياجاتنا لفصل الواجهة الأمامية. نعتقد أنه من خلال تقسيم المسؤوليات فقط يمكننا تلبية سيناريوهات الاستخدام الحالية لدينا:
الواجهة الأمامية: مسؤولة عن طبقات العرض ووحدة التحكم.
الواجهة الخلفية: فقط مسؤولة عن طبقة النموذج ، ومعالجة الأعمال/البيانات ، إلخ.
لماذا ستتم مناقشة تقسيم المسؤوليات هذا لاحقًا.
2. لماذا يجب أن نفصل بين الأمام والخلفية؟
فيما يتعلق بهذه المشكلة ، تشرح مقالة يو بو بشكل شامل للغاية في تطور نموذج البحث والتطوير على الويب. دعونا نراجعه بإيجاز:
2.1 السيناريوهات المعمول بها لنماذج التطوير الحالية
تتمتع نماذج التطوير التي ذكرها كل من Yu Bo بسيناريوهات خاصة بها ، ولا يحل أي منها محل الآخر تمامًا.
على سبيل المثال ، بالنسبة إلى MVC ، والذي يعتمد بشكل أساسي على الواجهة الخلفية ، من الفعال للغاية القيام ببعض أعمال العرض المتزامنة ، ولكن عند مواجهة صفحة متزامنة وغير متزامنة ، سيكون من الصعب التواصل مع تطوير الخلفية.
Ajax هو نموذج تطوير SPA الرئيسي ، وهو أكثر ملاءمة لتطوير سيناريوهات نوع التطبيق ، ولكنه مناسب فقط لصنع التطبيقات ، لأنه يصعب حل محركات البحث (SEO والمشاكل الأخرى ". بالنسبة للعديد من أنواع الأنظمة ، فإن طريقة التطوير هذه ثقيلة للغاية.
2.2 مسؤوليات النهاية الأمامية والخلفية غير واضحة
في الأنظمة ذات المنطق التجاري المعقد ، نخشى أكثر من الحفاظ على الكود المخلوط مع النهايات الأمامية والخلفية. نظرًا لعدم وجود قيد ، قد تظهر رمز الطبقات الأخرى من MVC في كل طبقة. بمرور الوقت ، لا توجد صيانة على الإطلاق.
على الرغم من أن فصل النهايات الأمامية والخلفية لا يمكن أن يحل هذه المشكلة تمامًا ، إلا أنه يمكن تخفيفه إلى حد كبير. لأنه مضمون من المستوى المادي الذي لا يمكنك القيام بذلك.
2.3 قضايا كفاءة التنمية
تعتمد شبكة Taobao بشكل أساسي على WebX MVC Framework ، وتحدد البنية أن الواجهة الأمامية يمكن أن تعتمد فقط على الواجهة الخلفية.
لذلك لا يزال نموذج التطوير الخاص بنا هو أن الواجهة الأمامية تكتب عروضًا عروضًا ثابتة وأن الواجهة الخلفية تترجمها إلى قوالب VM. لن أتحدث عن المشكلة في هذا النموذج ، وقد تعرضت لانتقادات لفترة طويلة.
من المؤلم أيضًا التطوير المباشر على أساس البيئة الخلفية ، ومن المقلق تكوين وتثبيت واستخدام. من أجل حل هذه المشكلة ، اخترعنا العديد من الأدوات ، مثل Vmarket ، ولكن لا يزال يتعين على الواجهة الأمامية كتابة VMs ، والاعتماد على البيانات الخلفية ، وبالتالي فإن الكفاءة لا تزال غير مرتفعة.
بالإضافة إلى ذلك ، لا يمكن للواجهة الخلفية التخلص من التركيز القوي على العرض وبالتالي التركيز على تطوير طبقة منطق الأعمال.
2.4 القيود على الأداء الأمامي
إذا تم إجراء تحسين الأداء فقط على الواجهة الأمامية ، فغالبًا ما نحتاج إلى تعاون خلفي لإنشاء الشرارات. ومع ذلك ، نظرًا لقيود إطار الواجهة الخلفية ، من الصعب علينا استخدام Comet و BigPipe والحلول الفنية الأخرى لتحسين الأداء.
من أجل حل بعض المشكلات المذكورة أعلاه ، قمنا بتجديد العديد من المحاولات وقمنا بتطوير أدوات مختلفة ، ولكن لم يكن هناك أي تحسن كبير ، وذلك أساسًا لأننا لا نستطيع إلا استخدام قطعة صغيرة من المساحة التي يقسمناها في الواجهة الخلفية. فقط عن طريق فصل الأطراف الأمامية والخلفية حقًا ، يمكننا حل المشكلات المذكورة أعلاه تمامًا.
3. كيف تفصل بين الأمام والخلفي؟
كيف تفصل بين الأمام والخلف؟ في الواقع ، هناك إجابة في القسم الأول:
الواجهة الأمامية: مسؤولة عن طبقات العرض ووحدة التحكم.
الواجهة الخلفية: مسؤولة عن طبقة النماذج ، ومعالجة الأعمال/البيانات ، إلخ.
فقط تخيل ، إذا كانت وحدة التحكم في الواجهة الأمامية ، يمكننا القيام بتصميم عنوان URL ، يمكننا أن نقرر ما إذا كان سيتم مزامنة العرض على الخادم وفقًا للمشهد ، أو إخراج بيانات JSON استنادًا إلى بيانات طبقة العرض ، ويمكننا أيضًا القيام بسهولة بيغبيب أو مذنب ومقبس ، إلخ. وفقًا لاحتياجات طبقة العرض التقديمية. إنها طريقة الاستخدام تمامًا التي تحددها المتطلبات.
3.1 تطوير "المكدس الكامل" على أساس NodeJS
إذا كنت ترغب في تنفيذ طبقات الشكل أعلاه ، فستحتاج حتماً إلى خدمة ويب لمساعدتنا على إدراك ما نقوم به قبل الواجهة الخلفية وبعدها ، لذلك هناك عنوان "تطوير الكامل على أساس NodeJS"
تبدو هذه الصورة بسيطة وسهلة الفهم ، لكنها لم تجربها وستكون هناك العديد من الأسئلة.
في وضع SPA ، قدمت الواجهة الخلفية واجهة البيانات المطلوبة ، ويمكن بالفعل التحكم في الواجهة الأمامية. لماذا تضيف طبقة nodejs؟
ماذا عن إضافة طبقة أخرى؟
إضافة طبقة أخرى ستزيد من عبء العمل في الواجهة الأمامية؟
ستؤدي إضافة طبقة أخرى إلى طبقة أخرى من المخاطر. كيف تكسره؟
يمكن أن تفعل Nodejs أي شيء ، لماذا لا تزال بحاجة إلى Java؟
ليس من السهل شرح هذه القضايا بوضوح. اسمحوا لي أن أتحدث عن عملية فهمي أدناه.
3.2 لماذا إضافة طبقة من nodejs؟
في هذه المرحلة ، نقوم بتطوير نموذج MVC الخلفي. يعيق هذا النموذج بشكل خطير كفاءة التنمية الأمامية ويمنع الواجهة الخلفية من التركيز على تطوير الأعمال.
يتمثل الحل في تمكين الواجهة الأمامية للتحكم في طبقة وحدة التحكم ، ولكن من الصعب القيام بذلك في إطار نظام التكنولوجيا الحالي ، لأنه من المستحيل السماح لجميع الواجهة الأمامية بتعلم Java ، وتثبيت بيئة التطوير الخلفية ، وكتابة VMs.
يمكن لـ Nodejs حل هذه المشكلة بشكل جيد للغاية. يمكننا أن نفعل ما ساعدنا التطور في القيام به من قبل ، ويبدو أن كل شيء طبيعي للغاية.
3.3 قضايا الأداء
تتضمن الطبقات التواصل بين كل طبقة ، وسيكون هناك بالتأكيد خسائر معينة في الأداء. ومع ذلك ، فإن التقسيم الطبقي المعقول يمكن أن يجعل المسؤوليات واضحة وتعاونية ، مما سيحسن كفاءة التطوير بشكل كبير. من المؤكد أن الخسائر الناجمة عن التقسيم الطبقي ستتم تعويضها في الجوانب الأخرى.
بالإضافة إلى ذلك ، بمجرد أن نقرر التعادل ، يمكننا تقليل الخسائر عن طريق تحسين طرق الاتصال وبروتوكولات الاتصال.
على سبيل المثال:
بعد أن تكون صفحة تفاصيل Baby Taobao ثابتة ، لا يزال هناك الكثير من المعلومات التي يجب الحصول عليها في الوقت الفعلي ، مثل الخدمات اللوجستية ، والعروض الترويجية ، وما إلى ذلك لأن هذه المعلومات في أنظمة أعمال مختلفة ، يحتاج الواجهة الأمامية إلى إرسال 5 أو 6 طلبات غير متزامنة لإعادة تثبيت هذه المحتويات.
مع Nodejs ، يمكن للواجهة الأمامية أن تكون هذه الطلبات الخمسة غير المتزامنة في NodeJs ، ويمكن بسهولة القيام BigPipe. يمكن لهذا التحسين تحسين كفاءة العرض بأكملها كثيرًا.
قد تعتقد أنه من المقبول إرسال 5 أو 6 طلبات غير متزامنة على الكمبيوتر الشخصي ، ولكن على الجانب اللاسلكي ، من المفيد للغاية إنشاء طلب HTTP على الهاتف المحمول للعميل. مع هذا التحسين ، تم تحسين الأداء عدة مرات.
تعتمد تفاصيل Taobao على تحسين NodeJS. نحن قيد التقدم. بعد إطلاقه ، سأشارك عملية التحسين.
3.4 هل زاد عبء العمل في الواجهة الأمامية؟
مقارنةً فقط بقطع الصفحات/العروض التوضيحية ، يجب أن تكون أكثر من ذلك بقليل ، ولكن هناك روابط واتصالات في الوضع الحالي. تستغرق هذه العملية الكثير من الوقت ، وتميل إلى الحشرات ، ومن الصعب الحفاظ عليها.
لذلك ، على الرغم من أن عبء العمل سيزيد قليلاً ، إلا أنه سيتم تحسين كفاءة التطوير الكلية بشكل كبير.
بالإضافة إلى ذلك ، يمكن توفير تكاليف الاختبار كثيرًا. تهدف الواجهات التي تم تطويرها في الماضي إلى طبقة العرض التقديمي ، ومن الصعب كتابة حالات الاختبار. إذا تم فصل الفصل الأمامي والخلفي ، يمكن فصل الاختبار. تتخصص مجموعة من الأشخاص في اختبار الواجهة وتركز المجموعة الأخرى من الأشخاص على اختبار واجهة المستخدم (يمكن استبدال هذا الجزء من العمل بأدوات).
3.5 كيفية التحكم في المخاطر التي تسببها إضافة طبقة العقدة؟
مع الاستخدام الواسع النطاق للعقدة ، سينضم الطلاب من قسم النظام/التشغيل والصيانة/الأمن بالتأكيد إلى بناء البنية التحتية. سوف يساعدوننا في تحسين المشكلات المحتملة في كل رابط وضمان استقرار القسم.
3.6 يمكن للعقدة أن تفعل أي شيء ، لماذا لا تزال بحاجة إلى Java؟
نيتنا الأصلية هي فصل النهايات الأمامية والخلفية. إذا نظرنا إلى هذه القضية ، فسيكون ذلك مخالفًا بعض الشيء لنيتنا الأصلية. حتى إذا استخدمنا العقدة لاستبدال Java ، لا يمكننا أن نضمن أننا لن نواجه أي مشاكل نواجهها اليوم ، مثل المسؤوليات غير الواضحة. هدفنا هو التطور بطريقة ذات طبقات ، والأشخاص المهنيين ، والتركيز على القيام بالأشياء المهنية. البنية التحتية القائمة على Java هي بالفعل قوية ومستقرة للغاية ، وهي أكثر ملاءمة لفعل ما هو الآن الهندسة المعمارية.
4. الفصل الأمامي القائم على عقدة توباو
الصورة أعلاه هي ما أفهمه على الفصل بين الواجهة الأمامية والخلفية في تاوباو ، بالإضافة إلى عقدة ، وكذلك نطاق مسؤوليات العقدة. شرح موجز:
الطرف العلوي هو الخادم ، وهو ما نسميه في كثير من الأحيان الواجهة الخلفية. بالنسبة لنا ، فإن الواجهة الخلفية عبارة عن مجموعة من الواجهات ، ويوفر الخادم واجهات مختلفة لاستخدامها. نظرًا لوجود طبقة عقدة ، فليس هناك حاجة للحد من شكل الخدمة. لتطوير الواجهة الخلفية ، يستخدمون فقط واجهات تهتم برمز العمل.
الخادم تحت تطبيق العقدة.
هناك طبقة من وكيل النموذج في تطبيق العقدة الذي يتواصل مع الخادم. تُستخدم هذه الطبقة بشكل أساسي لتنعيم الطريقة التي نسمي بها واجهات مختلفة وتغليف بعض النماذج التي تحتاجها طبقة العرض.
يمكن لطبقة العقدة أيضًا تحقيق VMCommon الأصلي ، TMS (نقلا عن نظام إدارة محتوى Taobao) والمتطلبات الأخرى.
ما هو إطار العمل الذي يجب استخدامه لطبقة العقدة متروك للمطور لتقريره. ومع ذلك ، يوصى باستخدام مزيج من Express + xplate ، والذي يمكن استخدامه للنهايات الأمامية والخلفية.
يقرر الجميع كيفية استخدام العقدة ، ولكن ما هو مثير هو أنه يمكننا أخيرًا استخدام العقدة لتنفيذ طريقة الإخراج التي نريدها بسهولة: JSON/JSONP/RESTFLE/HTML/BIGPIPE/COMET/SOCKET/SOCKETNOUS وغير متزامن. يمكن القيام به كل ما تريد ، ويتم تحديده بالكامل بناءً على السيناريو الخاص بك.
لم تتغير طبقة المتصفح في بنيةنا ، ولا نريد تغيير فهمك السابق للتطور في المتصفح بسبب إدخال العقدة.
تقديم العقدة هو فقط لتسليم جزء التحكم في الواجهة الأمامية التي يجب التحكم فيها بواسطة الواجهة الأمامية.
لدينا مشروعان في التطوير في هذا النموذج. على الرغم من أنها لم يتم إطلاقها بعد ، فقد تذوقنا بالفعل الحلاوة من حيث كفاءة التطوير وتحسين الأداء.
5. ماذا نحتاج إلى فعله؟
دمج عملية تطوير Node في عملية SCM الحالية من Taobao.
بناء البنية التحتية ، مثل الجلسة والمسجل والوحدات العامة الأخرى.
أفضل ممارسات التطوير
قصص النجاح عبر الإنترنت
فهم الجميع لمفهوم فصل العقدة الأمامية والخلفية ينتهي
أمان
أداء
...
لن يكون هناك الكثير من التكنولوجيا التي تحتاج إلى الابتكار والبحث ، وكان هناك الكثير من التراكم الجاهز. في الواقع ، المفتاح هو فتح بعض العمليات وتراكم الحلول العامة. أعتقد أنه مع المزيد من ممارسات المشروع ، ستصبح هذا المجال تدريجياً عملية مستقرة.
6. "جزيرة ميدواي"
على الرغم من أن نموذج "التطوير الكامل على أساس NodeJS" مثير ، إلا أنه لا يزال هناك الكثير للذهاب لتحويل التطوير الكامل على أساس العقدة إلى شيء يمكن للجميع قبوله. مشروعنا المستمر "Midway" هو حل هذه المشكلة. على الرغم من أننا لم يمض وقت طويل على ذلك ، إلا أننا نقترب أكثر فأكثر من هدفنا! !