Serverless ليس عن الغياب الفعلي للخوادم. هذا ليس "قاتل" للحاويات وليس اتجاه عابر. هذا هو نهج جديد لبناء النظم في السحابة. في مقال اليوم ، سوف نتطرق إلى بنية التطبيقات Serverless ، ونرى الدور الذي يلعبه مزود الخدمة Serverless والمشاريع مفتوحة المصدر. في النهاية ، سنتحدث عن Serverless.
أريد أن أكتب جانب الخادم للتطبيق (نعم حتى متجر على الإنترنت). يمكن أن تكون محادثة أو خدمة لنشر المحتوى أو موازن التحميل. في أي حال ، سيكون هناك الكثير من الصداع: سيتعين عليك إعداد البنية التحتية وتحديد تبعيات التطبيق والتفكير في نظام التشغيل المضيف. ثم تحتاج إلى تحديث المكونات الصغيرة التي لا تؤثر على عمل بقية المتراصة. حسنا ، دعونا لا ننسى التحجيم تحت الحمل.
ولكن ماذا لو أخذنا حاويات سريعة الزوال تكون فيها التبعيات المطلوبة مثبتة بالفعل ، والحاويات نفسها معزولة عن بعضها البعض وعن نظام التشغيل المضيف؟ سنقوم بتقسيم المتراصة إلى خدمات مصغرة ، يمكن تحديث كل منها وتحجيمها بشكل مستقل عن الآخرين. بعد وضع الكود في مثل هذه الحاوية ، يمكنني تشغيلها على أي بنية تحتية. بالفعل أفضل.
وإذا كنت لا ترغب في تكوين الحاويات؟ لا أريد التفكير في توسيع نطاق التطبيق. لا أريد أن أدفع مقابل حاويات التشغيل الخاملة عندما يكون الحمل على الخدمة في حده الأدنى. اريد ان اكتب كود ركز على منطق الأعمال وتسويق المنتجات بسرعة الضوء.
هذه الأفكار دفعتني إلى الحوسبة الخالية من الخوادم. لا يعني Serverless في هذه الحالة
الغياب الفعلي للخوادم ، ولكن عدم وجود صداع لإدارة البنية التحتية.الفكرة هي أن منطق التطبيق ينقسم إلى وظائف مستقلة. لديهم هيكل الحدث. كل واحدة من الوظائف تؤدي "microtask" واحد. كل ما هو مطلوب من المطور هو تحميل الوظائف في وحدة التحكم التي يوفرها المزود السحابي وربطها بمصادر الحدث. سيتم تنفيذ الرمز عند الطلب في حاوية معدّة تلقائيًا ، وسأدفع فقط مقابل وقت التنفيذ.
دعونا نرى كيف ستبدو عملية تطوير التطبيق الآن.
من المطور
في وقت سابق ، بدأنا نتحدث عن تطبيق المتجر على الإنترنت. في النهج التقليدي ، يتم تنفيذ المنطق الرئيسي للنظام من خلال تطبيق متآلف. والخادم مع التطبيق يعمل باستمرار ، حتى لو لم يكن هناك تحميل.
للتبديل إلى serverless ، نقوم بتقسيم التطبيق إلى microtasks. تحت كل منهم نكتب وظيفتنا الخاصة. وظائف مستقلة عن بعضها البعض ولا تخزن معلومات الحالة. يمكن أن تكون مكتوبة بلغات مختلفة. إذا تعطل أحدهم ، فلن يتوقف التطبيق بالكامل. ستبدو بنية التطبيق كما يلي:
تقسيم إلى وظائف في Serverless يشبه العمل مع microservices. لكن يمكن أن تؤدي الخدمة المجهرية عدة مهام ، ومن الناحية المثالية ، يجب أن تؤدي الوظيفة واحدة. تخيل أن المهمة هي جمع الإحصاءات وعرضها بناءً على طلب المستخدم. في نهج الخدمة المجهرية ، يتم تنفيذ المهمة بواسطة خدمة واحدة من خلال نقطتي دخول: الكتابة والقراءة. في الحوسبة بدون خادم ، ستكون هاتان الوظيفتان مختلفتان غير مترابطتين. يحفظ مطور موارد الحوسبة ، على سبيل المثال ، يتم تحديث الإحصائيات أكثر من تنزيلها.
يجب تنفيذ وظائف الخادم في فترة زمنية قصيرة (المهلة) ، والتي يحددها مزود الخدمة. على سبيل المثال ، بالنسبة لـ AWS ، المهلة 15 دقيقة. هذا يعني أنه يجب تغيير الوظائف طويلة العمر (طويلة العمر) للوفاء بالمتطلبات - وهذا Serverless يختلف عن التقنيات الأخرى الشائعة اليوم (الحاويات والمنصة كخدمة).
نحن نخصص حدث لكل وظيفة. حدث ما هو المشغل لإجراء:
يمكن أن تكون الأحداث طلبات HTTP وتدفق البيانات وقوائم انتظار الرسائل وما إلى ذلك. مصادر الأحداث هي تغيير أو ظهور البيانات. بالإضافة إلى ذلك ، يمكن تشغيل الوظائف عن طريق الموقت.
عملت الهندسة المعمارية ، وأصبح التطبيق بدون خادم. بعد ذلك نذهب إلى مزود الخدمة.
من المزود
عادة ما يتم تقديم الحوسبة بدون خادم من قبل مزودي الخدمة السحابية. يطلقون عليه بشكل مختلف: وظائف Azure ، AWS Lambda ، وظائف Google Cloud ، وظائف IBM Cloud.
سنستخدم الخدمة من خلال وحدة التحكم أو الحساب الشخصي للمزود. يمكن تنزيل رمز الوظيفة بإحدى الطرق التالية:
- كتابة التعليمات البرمجية في برامج التحرير المضمنة عبر وحدة تحكم الويب ،
- قم بتنزيل الأرشيف مع الكود ،
- العمل مع مستودعات بوابة عامة أو خاصة.
نحن هنا تكوين الأحداث التي تستدعي الوظيفة. قد يكون لدى مقدمي خدمات مختلفين مجموعات أحداث مختلفة.
قام المزوّد الموجود في بنيته التحتية ببناء وأتمتة نظام الوظيفة كخدمة (FaaS):
- يحصل رمز الوظيفة على المستودع على جانب المزود.
- عند حدوث حدث ، يتم نشر الحاويات ذات البيئة المعدة تلقائيًا على الخادم. كل وظيفة مثيل لها حاوية معزولة.
- من وحدة التخزين ، يتم إرسال الوظيفة إلى الحاوية ، وتحسب ، وإرجاع النتيجة.
- عدد الأحداث الموازية في تزايد - عدد الحاويات في تزايد. نظام المقاييس تلقائيا. إذا لم يصل المستخدمون إلى الوظيفة ، فستكون غير نشطة.
- يقوم المزود بتحديد وقت الخمول للحاويات - إذا لم تظهر الوظائف في الحاوية خلال هذا الوقت ، فقد تم إتلافها.
لذلك نحصل على Serverless خارج الصندوق. سوف ندفع مقابل الخدمة وفقًا لنموذج الدفع الفوري ، وللوظائف التي يتم استخدامها وفقط للوقت الذي تم استخدامه فيه.
لتعريف المطورين بالخدمة ، يوفر مقدمو الخدمة ما يصل إلى 12 شهرًا من الاختبارات المجانية ، لكنهم يحدون من إجمالي وقت الحساب ، وعدد الطلبات في الشهر ، أو استهلاك المال أو الطاقة.
الميزة الرئيسية للعمل مع مزود هي القدرة على عدم القلق بشأن البنية التحتية (الخوادم ، الأجهزة الافتراضية ، الحاويات). من جانبه ، يمكن للمزود تطبيق FaaS على تطوراته الخاصة ، واستخدام أدوات مفتوحة المصدر. سنتحدث عنهم أكثر.
من المصدر المفتوح
على مدار العامين الماضيين ، كان مجتمع المصادر المفتوحة يعمل بنشاط على أدوات بدون خادم. على وجه الخصوص ، تساهم أكبر الجهات الفاعلة في السوق في تطوير منصات بدون خادم:
- تقدم Google للمطورين أداة مفتوحة المصدر - Knative . وتضمن تطويرها IBM و RedHat و Pivotal و SAP ؛
- عملت IBM على النظام الأساسي OpenWhisk Serverless ، الذي أصبح بعد ذلك مشروع Apache Foundation ؛
- فتح Microsoft جزئياً رمز النظام الأساسي Azure Functions .
كما يتم إجراء التطورات في اتجاه الأطر بدون خادم.
يتم نشر
Kubeless و
Fission ضمن مجموعات Kubernetes المعدة مسبقًا ، وتعمل
OpenFaaS مع كل من Kubernetes و Docker Swarm. يعمل الإطار كنوع من وحدات التحكم - عند الطلب ، فإنه يعد وقت التشغيل داخل الكتلة ، ثم يقوم بتشغيل وظيفة هناك.
تترك الأطر مجالًا لتكوين الأداة ليناسب احتياجاتك. لذلك ، في Kubeless ، يمكن للمطور تعيين مهلة لتنفيذ الوظيفة (القيمة الافتراضية هي 180 ثانية). الانشطار في محاولة لحل مشكلة البدء البارد يقدم للحفاظ على جزء من الحاويات تعمل طوال الوقت (على الرغم من أن هذا ينطوي على تكلفة التوقف). ويوفر OpenFaaS مجموعة من المشغلات لكل ذوق ولون: HTTP و Kafka و Redis و MQTT و Cron و AWS SQS و NATs وغيرها.
يمكن العثور على تعليمات للبدء في الوثائق الرسمية للأطر. ينطوي العمل معهم على مهارات أكثر قليلاً من العمل مع مزود - وهذا على الأقل القدرة على بدء مجموعة Kubernetes من خلال CLI. الحد الأقصى ، قم بتضمين أدوات أخرى مفتوحة المصدر (على سبيل المثال ، مدير قائمة انتظار كافكا).
بغض النظر عن الطريقة التي نتعامل بها مع Serverless - من خلال مزود أو باستخدام مصدر مفتوح ، نحصل على عدد من مزايا وعيوب نهج Serverless.
من منظور المزايا والعيوب
Serverless يطور أفكار البنية التحتية للحاوية ونهج الخدمة الصغيرة ، حيث يمكن للفرق العمل في وضع متعدد اللغات ، دون ربطها بمنصة واحدة. بناء النظام مبسط ، وتصحيح الأخطاء يصبح أسهل. تسمح لك بنية Microservice بإضافة وظائف جديدة إلى النظام بشكل أسرع بكثير من تطبيق متجانسة.
يقلل Serverless من وقت التطوير بدرجة أكبر عن طريق السماح للمطور بالتركيز فقط على منطق أعمال التطبيق والترميز. نتيجة لذلك ، يتم تقليل الوقت اللازم لتسويق التنمية.
على سبيل المكافأة ، نحصل على مقياس تلقائي للحمل ، ونحن ندفع فقط مقابل الموارد المستخدمة وفقط في وقت استخدامها.
مثل أي تقنية ، Serverless له عيوب.
على سبيل المثال ، قد يكون هذا العيب وقتًا باردًا لبدء التشغيل (يصل إلى ثانية واحدة في المتوسط للغات مثل JavaScript و Python و Go و Java و Ruby).من ناحية ، في الواقع ، يعتمد وقت البدء البارد على العديد من المتغيرات: اللغة التي تُكتب بها الوظيفة ، وعدد المكتبات ، ومقدار الكود ، والتواصل مع الموارد الإضافية (نفس قواعد البيانات أو خوادم المصادقة). لأن المطور يتحكم في هذه المتغيرات ، يمكنه تقصير وقت البدء. ولكن من ناحية أخرى ، لا يمكن للمطور التحكم في وقت تشغيل الحاوية - كل هذا يتوقف على المزود.
يمكن أن تتحول البداية الباردة إلى بداية دافئة عندما تعيد الوظيفة استخدام الحاوية التي تم إطلاقها بواسطة الحدث السابق. سيحدث هذا الموقف في ثلاث حالات:
- إذا كان العملاء يستخدمون الخدمة في كثير من الأحيان ويتزايد عدد المكالمات إلى الوظيفة ؛
- إذا كان الموفر أو النظام الأساسي أو الإطار يسمح لك بالإبقاء على جزء من الحاويات قيد التشغيل طوال الوقت ؛
- إذا كان المطور يقوم بتشغيل وظائف المؤقت (على سبيل المثال ، كل 3 دقائق).
بالنسبة للعديد من التطبيقات ، لا تعتبر البداية الباردة مشكلة. تحتاج هنا إلى البناء على نوع ومهام الخدمة. لا تعتبر البداية المتأخرة للثانية أمرًا مهمًا دائمًا لتطبيق الأعمال ، ولكن يمكن أن تصبح مهمة بالنسبة للخدمات الطبية. من المحتمل ، في هذه الحالة ، لن يكون النهج دون خادم مناسبًا.
العيب التالي لـ Serverless هو العمر القصير للوظيفة (المهلة التي يجب أن تنفذها الوظيفة).ولكن ، إذا كان عليك العمل بمهام طويلة الأمد ، فيمكنك استخدام بنية مختلطة - دمج Serverless مع التقنيات الأخرى.
لن تكون جميع الأنظمة قادرة على العمل وفقًا لنظام Serverless.ستظل بعض التطبيقات تخزن البيانات والحالة في وقت التشغيل. ستبقى بعض الهياكل متجانسة ، وستظل بعض الوظائف طويلة الأمد. ومع ذلك (كما اعتادت التقنيات السحابية ، ومن ثم الحاويات) ، فإن Serverless هي تكنولوجيا ذات مستقبل عظيم.
في هذا السياق ، أود الانتقال بسلاسة إلى مسألة تطبيق الأسلوب Serverless.
على جانب التطبيق
في عام 2018 ، زادت نسبة استخدام Serverless
بمقدار مرة ونصف . من بين الشركات التي طبقت بالفعل التكنولوجيا في خدماتها ، هناك شركات عملاقة في السوق مثل Twitter و PayPal و Netflix و T-Mobile و Coca-Cola. في الوقت نفسه ، عليك أن تفهم أن Serverless ليس حلاً سحريًا ، ولكنه أداة لحل مجموعة معينة من المهام:
- تقليل موارد التوقف. لا تحتاج إلى الاحتفاظ باستمرار بالجهاز الظاهري ضمن الخدمات التي لا يمكن الوصول إليها كثيرًا.
- "على الطاير" معالجة البيانات. ضغط الصور ، قص الخلفية ، تغيير ترميز الفيديو ، العمل مع أجهزة استشعار IoT ، إجراء عمليات حسابية.
- الغراء معا الخدمات الأخرى. احصل على مستودع للبرامج الداخلية ، وقم بالدردشة في برنامج Slack مع Jira ومع تقويم.
- موازنة الحمل. هنا نسكن في مزيد من التفاصيل.
دعنا نقول أن هناك خدمة يصل إليها 50 شخصًا. تحتها هو آلة افتراضية مع الأجهزة ضعيفة. بشكل دوري ، يزيد الحمل على الخدمة بشكل كبير. ثم الحديد الضعيف لا يستطيع التعامل.
يمكنك تضمين موازن في النظام يقوم بتوزيع التحميل ، على سبيل المثال ، على ثلاثة أجهزة افتراضية. في هذه المرحلة ، لا يمكننا التنبؤ بالتحميل بدقة ، لذلك نحافظ على قدر معين من الموارد "قيد الاحتياطي". ودفع مبالغ زائدة عن التوقف.
في هذه الحالة ، يمكننا تحسين النظام من خلال نهج مختلط: بالنسبة لموازن التحميل ، نترك جهازًا افتراضيًا واحدًا ونضع رابطًا لـ Serverless Endpoint مع الوظائف. إذا تجاوز التحميل الحد الأدنى ، يقوم الموازن بتشغيل مثيلات الوظائف التي تأخذ جزءًا من معالجة الطلب.
وبالتالي ، يمكن استخدام Serverless حيث لا يكون ذلك في كثير من الأحيان ، ولكن لمعالجة عدد كبير من الطلبات بشكل مكثف. في هذه الحالة ، يكون تشغيل العديد من الوظائف لمدة 15 دقيقة أكثر ربحية من الاحتفاظ بجهاز أو خادم افتراضي طوال الوقت.
مع كل مزايا الحوسبة بدون خادم ، قبل تنفيذها ، يجب أولاً وقبل كل شيء تقييم منطق التطبيق وفهم المهام التي يمكن لـ Serverless حلها في حالة معينة.
Serverless و Selectel
في Selectel ،
جعلنا العمل مع Kubernetes في
سحابة خاصة افتراضية أسهل من خلال لوحة التحكم الخاصة بنا. الآن نحن نبني منصة FaaS الخاصة بنا. نريد للمطورين أن يكونوا قادرين على حل مشكلاتهم مع Serverless من خلال واجهة مريحة ومرنة.
هل تريد متابعة عملية تطوير نظام FaaS الجديد؟ الاشتراك في النشرة الإخبارية Selectel "وظائف سحابة"
على صفحة الخدمة . سنتحدث عن عملية التطوير ونعلن عن الإصدار المغلق للوظائف السحابية.
إذا كانت لديك أية أفكار حول ما يجب أن يكون عليه نظام FaaS الأساسي وكيف تريد استخدام Serverless في مشاريعك ، فقم بمشاركتها في التعليقات. سنأخذ رغباتك في الاعتبار عند تطوير المنصة.
المواد المستخدمة في المقال: