قبلة العمارة. من microservice إلى متراصة

يخبرنا Andrey Kopylov ، المدير الفني لدينا ، عن النهج الذي يستخدمه فريق تطوير الويب AREALIDEA لتصميم بنية التطبيق ، وعن KISS Architecture ، تطويره جيد جدًا.

هناك العديد من الطرق لتصميم بنية التطبيق. MVC ، DDD ، الهندسة المعمارية النظيفة وغيرها الكثير.

MVC مناسب تمامًا للتطبيقات الصغيرة. عندما تحاول التوسع ، تتحول MVC إلى أكثر الهياكل المعمارية شيوعًا في عالم تكنولوجيا المعلومات - Big Lump of Dirt .

DDD هي بنية رائعة ، لكن لا أحد يفهمها. ما لم يكن الخالق نفسه واثنين من المهندسين المعماريين. الغرض من الهندسة المعمارية هو جعلها مفهومة لكل مطور.

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

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

يبدو بعد ذلك ، دعنا نأخذ MVC لخدمة microservice ونتوقف عن ذلك. لكن لا ، هذه الدراجة لا تناسبنا.

مكونات

يتم تجميع دراجة للمشاريع في وكالتنا من قطع الغيار من الأساليب المعمارية المختلفة.

فيما يلي المكونات التي تحتاجها لإنشاء بنية مفهومة وملائمة:

• الموجهات
• تحكم
• المشاهدات
• الخدمات
• النماذج

طبقات

جهاز التوجيه

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

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

المراقب المالي

وحدة التحكم هي طبقة بين جهاز التوجيه والخدمات. يجب ألا يكون هناك منطق عمل في وحدة التحكم.

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

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

المشاهدات

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

في الحالة القصوى ، يكون العرض هو JSON و XML وتنسيقات مشابهة.

الخدمات

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

تنقسم طبقة الخدمة إلى أوامر واستعلامات (أوامر واستعلامات). هذا هو النهج القياسي ل CQRS .

خدمة واحدة تؤدي وظيفة واحدة فقط. يمكن أن يكون هناك أي عدد من الوظائف الخاصة ، وعامة واحدة فقط. يبدأ اسم الخدمة بفعل. أمثلة: GetUsers ، GetPostById ، UpdateUser ، PublishPost. إنه اسم الخدمة التي تشير إلى الفصل الصحيح بين الوظيفة.

في الاستعلامات ، نضع الخدمات التي لا تعدل قاعدة البيانات. يحتوي الاستعلام على وظيفة الحصول على وظيفة عامة واحدة. في الأوامر ، نضع الخدمات التي تغير قاعدة البيانات. يحتوي الأمر على وظيفة تنفيذ عامة واحدة.

النماذج

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

إذا كان النموذج يعمل مع قاعدة بيانات ، فإن نموذجًا واحدًا يقدم جدولًا واحدًا أو عدة جداول فقط.

وصفات

Microservice

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

• جهاز توجيه واحد
• تحكم واحد
• وجهات نظر متعددة.
• خدمات متعددة
• نموذج واحد.

الخدمة

الخدمة تطبيق صغير. يحتوي على:

• جهاز توجيه واحد
• عدة وحدات تحكم
• وجهات نظر متعددة.
• خدمات متعددة
• عدة نماذج.

متراصة

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

متراصة يحتوي على:

• SuperRouter واحد ؛
• العديد من أجهزة التوجيه العادية.
• العديد من وحدات التحكم
• العديد من المشاهدات ، العديد من الخدمات ؛
• العديد من النماذج.

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

للحفاظ على وئام الهندسة المعمارية تحتاج:

1. أضف راوترًا واحدًا من المستوى الأعلى لحل المسارات العامة - SuperRouter.
2. توزيع الملفات في هيكل حسب الوحدة. وهذا هو ، وفقا لمستقبل قطع في الخدمات الفردية.

اختبار

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

إذا كنت ترغب في اختبار شيء آخر غير الخدمات ، فمن المحتمل أن يتم اختيار المكان المناسب للمنطق بشكل غير صحيح.

الخاتمة

في رأيي ، تعتبر KISS Architecture مناسبة لـ 80٪ من المشاريع وتوفر تطوراً سلساً للمشروع.

سيكون هذا النهج المعماري واضحًا لجميع المطورين ولتطبيقه في الممارسة العملية ، لن تحتاج إلى قراءة كتب سميكة حول DDD.