بضع كلمات في الدفاع عن متراصة

قارنا ميزات الخدمات المجهرية والهندسة المعمارية المتجانسة ، ومزاياها وعيوبها. تم إعداد المقالة لـ Habr بناءً على مواد Hot Backend الخاصة بنا ، والتي عقدت في Samara في 9 فبراير 2019. نحن نعتبر عوامل اختيار الهندسة المعمارية اعتمادا على مهمة محددة.

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

متراصة و microservices: أمثلة

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



تتضمن بنية Microservice التقسيم إلى وحدات تعمل كعمليات منفصلة ويمكن أن تحتوي على خوادم منفصلة. تعمل كل خدمة microservice مع قاعدة البيانات الخاصة بها ، ويمكن لجميع هذه الخدمات التواصل مع بعضها البعض بشكل متزامن (http) وغير متزامن. علاوة على ذلك ، لتحسين الهيكل ، من المستحسن تقليل العلاقة بين الخدمات.

المخطط أدناه مبسط ، فهو يعكس ، أولاً وقبل كل شيء ، مكونات العمل.

خدمات Microservices: الفوائد

هناك ما لا يقل عن أربع مزايا للهندسة المعمارية:

التحجيم والنشر المستقل

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

التنمية المستقلة

يمكن تطوير كل خدمة microservice (على سبيل المثال ، وحدة ذاكرة) بواسطة فريق واحد لزيادة سرعة إنشاء منتج برنامج.

استقرار

لا يؤثر فشل إحدى الخدمات الميكروية على أداء الوحدات الأخرى.

تنوع

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

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

دعونا نرى ما إذا كان الجميع يجب أن يتحولوا حقًا من مجموعة متجانسة إلى خدمات ميكروية باتباع مثال أكبر العلامات التجارية؟

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

المشكلة الأولى: التحلل

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

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



المشكلة الثانية: المعاملات

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

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

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



المشكلة الثالثة: الإبلاغ

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

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



المشكلة الرابعة: تعقيدات التنمية العالية

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

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

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

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





المشكلة الخامسة: تعقيد الاختبار والتعقب والتصحيح

لاختبار مشكلة ، تحتاج إلى تنزيل جميع الخدمات المصغرة المعنية. يصبح تصحيح الأخطاء مهمة غير تافهة ، ويجب جمع كل السجلات في مكان ما في مكان واحد. في هذه الحالة ، تحتاج إلى أكبر عدد ممكن من السجلات لمعرفة ما حدث. لتتبع المشكلة ، تحتاج إلى فهم المسار الكامل الذي سارت عليه الرسالة. اختبارات الوحدة ليست كافية هنا ، حيث من المحتمل حدوث أخطاء عند تقاطع الخدمات. عند إجراء التغييرات ، لا يمكن التحقق من إمكانية التشغيل إلا بعد التشغيل على الحامل. يمكننا حصر كل خدمة microservice في مقدار معين من الذاكرة (على سبيل المثال ، 500 ميجابايت) ، ولكن هناك أوقات ذروة الحمل عندما يستغرق ما يصل إلى غيغابايت اثنين. هناك أوقات عندما يبدأ النظام في التباطؤ. نتيجة لذلك ، يمكن إنفاق الموارد على شيء لا ينتمي إلى المهام المباشرة للعميل: على سبيل المثال ، لا يوجد سوى اثنين من خدمات الأعمال الصغيرة ، ويتم إنفاق نصف الموارد على ثلاث خدمات ميكروية إضافية تدعم عمل الآخرين.

Microservice أو متراصة: معايير الاختيار

عند الاختيار بين هندسة متجانسة و microservice ، قبل كل شيء ، تحتاج إلى المضي قدما من تعقيد مجال الموضوع والحاجة إلى التوسع.

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



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

يجب أن يكون لكل وحدة واجهة برمجة تطبيقات خاصة بها ، بحيث يمكن تخصيصها لاحقًا وجعل الوحدة وحدة microservice.



بعد تحديد حدود الوحدات ، يمكنك المتابعة في التحلل إلى الخدمات الصغيرة ، إذا لزم الأمر. في حوالي 90 ٪ من الحالات ، سيكون من الممكن البقاء على المتراصة ، ولكن إذا لزم الأمر سيكون أسهل وأرخص لتغيير الهيكل.

في ممارستنا للعمل مع متراصة والخدمات الصغيرة ، توصلنا إلى الاستنتاجات التالية:

• لا تقم بالتبديل إلى خدمات micros لمجرد استخدامها بواسطة Netflix و Twitter و Facebook
• ابدأ مع اثنين أو ثلاثة من الخدمات المصغرة التي تتفاعل مع بعضها البعض ، وتوصل بالتفصيل إلى جميع المتطلبات غير الوظيفية المتعلقة بها (الأمان والتسامح مع الأعطال وإمكانية التوسع وما إلى ذلك) ثم فقط انتقل إلى خدمات أخرى
• أتمتة كل شيء ممكن
• إعداد المراقبة
• اكتب الاختبارات التلقائية
• لا تستخدم المعاملات الموزعة (لكن هذا ليس سببًا لرفض ضمان سلامة البيانات).
• إذا كنت ترغب في استخدام بنية خدمات microservice ، فاستعد لحقيقة أن التطوير قد يكلفك أكثر بثلاث مرات من تكلفة متراصة. ومع ذلك ، كلتا التقنيتين لها عيوبها ومزاياها ؛ كل منها له مكانته الخاصة.