Thundra رعت هذا المنصب.

Sarjeel Yusuf

Sarjeel هو مدير المنتج في Atlassian ، وهو مسؤول عن توجيه أدوات Atlassian لتسهيل قدرات DevOps في مجموعات الميزات الخاصة بهم.

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

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

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

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

استخدام Async-like Sync

تميل التطبيقات التي لا تحتوي على خادم إلى العمل بشكل أفضل عندما تكون غير متزامنة. هذا هو المفهوم الذي بشر به إريك جونسون في حديثه في أيام بلا خوادم اسطنبول ، بعنوان “ Thinking Async with Serverless .” ذهب لاحقًا لتقديم نسخة أطول من الحديث في ServerlessDays Nashville .

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

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

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

ماذا يجب أن تلاحظ؟

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

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

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

الحاجة إلى المشاركة

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

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

مثال على ظهور مثل هذه المشكلات هو التعلم الآلي ، حيث يجب مشاركة المكتبات الكبيرة عبر مختلف الوظائف المستخدمة في المعالجة الاختبار والتحقق ومجموعات البيانات التدريبية . توفر AWS طبقات Lambda في محاولة لتقديم بعض الدقة ، ولكن هذا قد لا يكون الحل الأمثل دائمًا.

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

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

ما الذي يجب أن تلاحظه؟

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

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

الوظائف الحبيبية

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

ماذا يجب أن تلاحظ ؟

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

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

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

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

خاتمة

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

لا تزال الملاحظة في مرحلة النضج ، ويستجيب موردو السحابة الآن للمكالمة. ومع ذلك ، لا تزال حلول المراقبة المضمنة لا تفي بالاحتياجات الإجمالية ولا تقدم سوى إمكانية الملاحظة الأساسية. لتحقيق إمكانية الملاحظة الحقيقية وفقًا للركائز الثلاث “المقاييس” و “الآثار” و “السجلات” ، يُنصح بالبحث عن أداة مراقبة خارجية متخصصة للوظيفة.

Amazon Web Services هي إحدى رعاة The New Stack.

صورة مميزة عبر بيكساباي .

٪٪ item_read_more_button ٪٪

ترك الرد

من فضلك ادخل تعليقك
من فضلك ادخل اسمك هنا