لا يتعلق Serverless بالغياب الفعلي للخوادم. هذا ليس قاتل الحاويات أو الاتجاه العابر. هذا نهج جديد لبناء الأنظمة في السحابة. في مقال اليوم سوف نتطرق إلى بنية التطبيقات بدون خادم، دعونا نرى الدور الذي يلعبه مزود الخدمة بدون خادم والمشاريع مفتوحة المصدر. أخيرًا، دعونا نتحدث عن مشكلات استخدام Serverless.
أرغب في كتابة جزء خادم من تطبيق (أو حتى متجر عبر الإنترنت). يمكن أن تكون هذه محادثة أو خدمة نشر محتوى أو موازن تحميل. على أية حال، سيكون هناك الكثير من المتاعب: سيتعين عليك إعداد البنية التحتية وتحديد تبعيات التطبيق والتفكير في نظام التشغيل المضيف. ستحتاج بعد ذلك إلى تحديث المكونات الصغيرة التي لا تؤثر على تشغيل باقي الوحدات المتراصة. حسنًا، دعونا لا ننسى التحجيم تحت الحمل.
ماذا لو أخذنا حاويات سريعة الزوال، حيث تم بالفعل تثبيت التبعيات المطلوبة مسبقًا، وتكون الحاويات نفسها معزولة عن بعضها البعض وعن نظام التشغيل المضيف؟ سنقوم بتقسيم الوحدة المتراصة إلى خدمات صغيرة، يمكن تحديث كل منها وتوسيع نطاقها بشكل مستقل عن الخدمات الأخرى. ومن خلال وضع الكود في مثل هذه الحاوية، يمكنني تشغيله على أي بنية تحتية. بالفعل أفضل.
ماذا لو كنت لا تريد تكوين الحاويات؟ لا أريد أن أفكر في توسيع نطاق التطبيق. لا أرغب في الدفع مقابل الحاويات الخاملة عندما يكون الحمل على الخدمة في حده الأدنى. أريد أن أكتب الكود. ركز على منطق الأعمال وقم بتقديم المنتجات إلى السوق بسرعة الضوء.
مثل هذه الأفكار قادتني إلى الحوسبة بدون خادم. بدون خادم في هذه الحالة يعني ليس الغياب الفعلي للخوادم، ولكن غياب مشاكل إدارة البنية التحتية.
الفكرة هي أن منطق التطبيق مقسم إلى وظائف مستقلة. لديهم هيكل الحدث. تؤدي كل وظيفة "مهمة صغيرة" واحدة. كل ما هو مطلوب من المطور هو تحميل الوظائف في وحدة التحكم التي يوفرها موفر السحابة وربطها بمصادر الأحداث. سيتم تنفيذ الكود عند الطلب في حاوية معدة تلقائيًا، وسأدفع فقط مقابل وقت التنفيذ.
دعونا نرى كيف ستبدو عملية تطوير التطبيق الآن.
من ناحية المطور
لقد بدأنا سابقًا الحديث عن تطبيق لمتجر إلكتروني. في النهج التقليدي، يتم تنفيذ المنطق الرئيسي للنظام من خلال تطبيق متجانس. والخادم مع التطبيق يعمل باستمرار، حتى لو لم يكن هناك تحميل.
للانتقال إلى العمل بدون خادم، نقوم بتقسيم التطبيق إلى مهام صغيرة. نكتب وظيفتنا الخاصة لكل منهم. الوظائف مستقلة عن بعضها البعض ولا تخزن معلومات الحالة (عديمة الحالة). ويمكن حتى أن تكون مكتوبة بلغات مختلفة. إذا "سقط" أحدهم، فلن يتوقف التطبيق بأكمله. ستبدو بنية التطبيق كما يلي:
يشبه التقسيم إلى وظائف في Serverless العمل مع الخدمات الصغيرة. لكن الخدمة الصغيرة يمكن أن تؤدي عدة مهام، ويجب أن تؤدي الوظيفة واحدة بشكل مثالي. لنتخيل أن المهمة هي جمع الإحصائيات وعرضها بناءً على طلب المستخدم. في نهج الخدمات الصغيرة، يتم تنفيذ المهمة بواسطة خدمة واحدة مع نقطتي دخول: الكتابة والقراءة. في الحوسبة بدون خادم، ستكون هاتان الوظيفتان مختلفتان وغير مرتبطتين ببعضهما البعض. يقوم المطور بحفظ موارد الحوسبة، على سبيل المثال، إذا تم تحديث الإحصائيات أكثر من تنزيلها.
يجب تنفيذ الوظائف بدون خادم في فترة زمنية قصيرة (مهلة)، وهو ما يحدده مزود الخدمة. على سبيل المثال، بالنسبة لـ AWS، تبلغ المهلة 15 دقيقة. وهذا يعني أنه سيتعين تغيير الوظائف طويلة الأمد لتناسب المتطلبات - وهذا ما يميز Serverless عن التقنيات الشائعة الأخرى اليوم (الحاويات والمنصة كخدمة).
نقوم بتعيين حدث لكل وظيفة. الحدث هو محفز للإجراء:
حدث
الإجراء الذي تنفذه الوظيفة
تم تحميل صورة المنتج إلى المستودع.
ضغط الصورة وتحميلها إلى الدليل
تم تحديث عنوان المتجر الفعلي في قاعدة البيانات
تحميل موقع جديد في الخرائط
يدفع العميل ثمن البضاعة
ابدأ معالجة الدفع
يمكن أن تكون الأحداث عبارة عن طلبات HTTP وبيانات متدفقة وقوائم انتظار رسائل وما إلى ذلك. مصادر الأحداث هي تغييرات أو تكرارات للبيانات. بالإضافة إلى ذلك، يمكن تشغيل الوظائف بواسطة مؤقت.
تم تطوير البنية، وأصبح التطبيق تقريبًا بدون خادم. بعد ذلك نذهب إلى مزود الخدمة.
من جهة المزود
عادة، يتم تقديم الحوسبة بدون خادم من قبل موفري الخدمات السحابية. يطلق عليهم بشكل مختلف: Azure Functions، AWS Lambda، Google Cloud Functions، IBM Cloud Functions.
سنستخدم الخدمة من خلال وحدة تحكم المزود أو الحساب الشخصي. يمكن تنزيل رمز الوظيفة بإحدى الطرق التالية:
- كتابة التعليمات البرمجية في برامج التحرير المضمنة عبر وحدة تحكم الويب،
- تحميل الارشيف بالكود,
- العمل مع مستودعات git العامة أو الخاصة.
هنا قمنا بإعداد الأحداث التي تستدعي الوظيفة. قد تختلف مجموعات الأحداث باختلاف مقدمي الخدمة.
قام الموفر ببناء نظام الوظيفة كخدمة (FaaS) وأتمتته على بنيته التحتية:
- ينتهي رمز الوظيفة بالتخزين على جانب الموفر.
- عند وقوع حدث ما، يتم نشر الحاويات ذات البيئة المعدة تلقائيًا على الخادم. يحتوي كل مثيل دالة على حاوية معزولة خاصة به.
- من وحدة التخزين، يتم إرسال الدالة إلى الحاوية وحسابها وإرجاع النتيجة.
- عدد الأحداث الموازية آخذ في الازدياد - عدد الحاويات آخذ في الازدياد. يقوم النظام بالتحجيم تلقائيًا. إذا لم يتمكن المستخدمون من الوصول إلى الوظيفة، فستكون غير نشطة.
- يقوم الموفر بتعيين وقت الخمول للحاويات - إذا لم تظهر الوظائف في الحاوية خلال هذا الوقت، فسيتم تدميرها.
بهذه الطريقة نخرج Serverless من الصندوق. سندفع مقابل الخدمة باستخدام نموذج الدفع أولاً بأول وفقط لتلك الوظائف المستخدمة، وفقط مقابل الوقت الذي تم استخدامها فيه.
ولتعريف المطورين بالخدمة، يقدم مقدمو الخدمة ما يصل إلى 12 شهرًا من الاختبار المجاني، ولكنهم يحدون من إجمالي وقت الحساب أو عدد الطلبات شهريًا أو الأموال أو استهلاك الطاقة.
الميزة الرئيسية للعمل مع مقدم الخدمة هي القدرة على عدم القلق بشأن البنية التحتية (الخوادم، الأجهزة الافتراضية، الحاويات). من جانبه، يمكن للمزود تنفيذ FaaS باستخدام تطوراته الخاصة واستخدام أدوات مفتوحة المصدر. دعونا نتحدث عنهم أكثر.
من الجانب مفتوح المصدر
لقد عمل مجتمع المصادر المفتوحة بنشاط على الأدوات بدون خادم خلال العامين الماضيين. يساهم أكبر اللاعبين في السوق أيضًا في تطوير منصات بدون خادم:
- شراء مراجعات جوجل يقدم للمطورين أداة مفتوحة المصدر - . شاركت IBM وRedHat وPivotal وSAP في تطويره؛
- IBM عملت على منصة بدون خادم والذي أصبح بعد ذلك مشروعًا لمؤسسة أباتشي؛
- مایکروسافت فتح رمز النظام الأساسي جزئيًا .
التطورات جارية أيضًا في اتجاه الأطر بدون خادم. и منتشرة داخل مجموعات Kubernetes المعدة مسبقًا، يعمل مع كل من Kubernetes وDocker Swarm. يعمل إطار العمل كنوع من وحدة التحكم - عند الطلب، يقوم بإعداد بيئة التشغيل داخل المجموعة، ثم يطلق وظيفة هناك.
تترك الأطر مساحة لتكوين الأداة لتناسب احتياجاتك. لذلك، في Kubeless، يمكن للمطور تكوين مهلة تنفيذ الوظيفة (القيمة الافتراضية هي 180 ثانية). يقترح الانشطار، في محاولة لحل مشكلة البداية الباردة، إبقاء بعض الحاويات قيد التشغيل طوال الوقت (على الرغم من أن هذا يستلزم تكاليف تعطل الموارد). ويقدم OpenFaaS مجموعة من المشغلات لكل الأذواق والألوان: HTTP، وKafka، وRedis، وMQTT، وCron، وAWS SQS، وNATs وغيرها.
يمكن العثور على تعليمات البدء في الوثائق الرسمية لأطر العمل. يتطلب العمل معهم مهارات أكثر بقليل مما يتطلبه العمل مع موفر الخدمة - وهذا على الأقل القدرة على تشغيل مجموعة Kubernetes عبر واجهة سطر الأوامر (CLI). على الأكثر، قم بتضمين أدوات أخرى مفتوحة المصدر (على سبيل المثال، مدير قائمة انتظار كافكا).
بغض النظر عن كيفية عملنا مع Serverless - من خلال مزود أو باستخدام مصدر مفتوح، سنحصل على عدد من مزايا وعيوب النهج بدون خادم.
من وجهة نظر المزايا والعيوب
تعمل Serverless على تطوير أفكار البنية التحتية للحاويات ونهج الخدمات الصغيرة، حيث يمكن للفرق العمل في وضع متعدد اللغات دون الارتباط بمنصة واحدة. تم تبسيط عملية إنشاء النظام كما أصبح تصحيح الأخطاء أسهل. تتيح لك بنية الخدمات المصغرة إضافة وظائف جديدة إلى النظام بشكل أسرع بكثير مما هو الحال في حالة التطبيق المتجانس.
بدون خادم يقلل وقت التطوير بشكل أكبر، السماح للمطور بالتركيز فقط على منطق عمل التطبيق والترميز. ونتيجة لذلك، يتم تقليل الوقت اللازم لتسويق التطورات.
كمكافأة، نحصل على مقياس تلقائي للتحميل، ونحن ندفع فقط مقابل الموارد المستخدمة وفقط في وقت استخدامها.
مثل أي تقنية، فإن Serverless له عيوب.
على سبيل المثال، قد يكون هذا العيب هو وقت البدء البارد (في المتوسط يصل إلى ثانية واحدة للغات مثل JavaScript وPython وGo وJava وRuby).
من ناحية، في الواقع، يعتمد وقت البدء البارد على العديد من المتغيرات: اللغة التي تكتب بها الوظيفة، وعدد المكتبات، وكمية التعليمات البرمجية، والتواصل مع الموارد الإضافية (نفس قواعد البيانات أو خوادم المصادقة). وبما أن المطور يتحكم في هذه المتغيرات، فيمكنه تقليل وقت بدء التشغيل. ولكن من ناحية أخرى، لا يستطيع المطور التحكم في وقت بدء تشغيل الحاوية - كل هذا يتوقف على الموفر.
يمكن أن تتحول البداية الباردة إلى بداية دافئة عندما تقوم إحدى الوظائف بإعادة استخدام الحاوية التي تم إطلاقها بواسطة حدث سابق. وستنشأ هذه الحالة في ثلاث حالات:
- إذا كان العملاء يستخدمون الخدمة بشكل متكرر وزاد عدد المكالمات إلى الوظيفة؛
- إذا كان الموفر أو النظام الأساسي أو إطار العمل يسمح لك بالحفاظ على تشغيل بعض الحاويات طوال الوقت؛
- إذا قام المطور بتشغيل الوظائف على مؤقت (على سبيل المثال كل 3 دقائق).
بالنسبة للعديد من التطبيقات، لا تمثل البداية الباردة مشكلة. هنا تحتاج إلى البناء على نوع الخدمة ومهامها. لا يعد تأخير البدء لمدة ثانية أمرًا بالغ الأهمية دائمًا لتطبيق الأعمال، ولكنه قد يصبح بالغ الأهمية للخدمات الطبية. في هذه الحالة، ربما لن يكون النهج بدون خادم مناسبًا بعد الآن.
العيب التالي لـ Serverless هو العمر القصير للوظيفة (المهلة التي يجب خلالها تنفيذ الوظيفة).
ولكن، إذا كان عليك العمل مع مهام طويلة الأمد، فيمكنك استخدام بنية مختلطة - قم بدمج Serverless مع تقنية أخرى.
لن تتمكن جميع الأنظمة من العمل باستخدام نظام Serverless.
ستظل بعض التطبيقات تخزن البيانات والحالة أثناء التنفيذ. ستبقى بعض البنيات متجانسة وستكون بعض الميزات طويلة الأمد. ومع ذلك (مثل التقنيات السحابية ثم الحاويات)، فإن Serverless هي تقنية ذات مستقبل عظيم.
وفي هذا السياق، أود أن أنتقل بسلاسة إلى مسألة استخدام النهج بدون خادم.
من الجانب التطبيقي
بالنسبة لعام 2018، النسبة المئوية للاستخدام بدون خادم . ومن بين الشركات التي طبقت التكنولوجيا بالفعل في خدماتها عمالقة السوق مثل Twitter وPayPal وNetflix وT-Mobile وCoca-Cola. في الوقت نفسه، عليك أن تفهم أن Serverless ليس حلاً سحريًا، ولكنه أداة لحل مجموعة معينة من المشكلات:
- تقليل وقت تعطل الموارد. ليست هناك حاجة للاحتفاظ باستمرار بجهاز افتراضي للخدمات التي تحتوي على عدد قليل من المكالمات.
- معالجة البيانات على الطاير. ضغط الصور، وقطع الخلفيات، وتغيير ترميز الفيديو، والعمل مع أجهزة استشعار إنترنت الأشياء، وإجراء العمليات الحسابية.
- "لصق" الخدمات الأخرى معًا. مستودع Git مع البرامج الداخلية وروبوت الدردشة في Slack مع Jira والتقويم.
- موازنة الحمل. دعونا نلقي نظرة فاحصة هنا.
لنفترض أن هناك خدمة تجذب 50 شخصًا. يوجد تحته جهاز افتراضي به أجهزة ضعيفة. من وقت لآخر، يزيد الحمل على الخدمة بشكل ملحوظ. ثم لا تستطيع الأجهزة الضعيفة التعامل معها.
يمكنك تضمين موازن في النظام يقوم بتوزيع الحمل، على سبيل المثال، عبر ثلاث أجهزة افتراضية. في هذه المرحلة، لا يمكننا التنبؤ بدقة بالحمل، لذلك نحتفظ بكمية معينة من الموارد قيد التشغيل "احتياطي". ونحن ندفع مبالغ زائدة مقابل التوقف.
في مثل هذه الحالة، يمكننا تحسين النظام من خلال نهج مختلط: نترك جهازًا افتراضيًا واحدًا خلف موازن التحميل ونضع رابطًا لنقطة النهاية بدون خادم مع الوظائف. إذا تجاوز التحميل الحد، يقوم الموازن بتشغيل مثيلات الوظيفة التي تتولى جزءًا من معالجة الطلب.
وبالتالي، يمكن استخدام Serverless عندما يكون من الضروري معالجة عدد كبير من الطلبات ليس كثيرًا، ولكن بشكل مكثف. في هذه الحالة، يعد تشغيل عدة وظائف لمدة 15 دقيقة أكثر ربحية من صيانة جهاز أو خادم افتراضي طوال الوقت.
مع كل مزايا الحوسبة بدون خادم، قبل التنفيذ، يجب عليك أولاً تقييم منطق التطبيق وفهم المشكلات التي يمكن أن تحلها بدون خادم في حالة معينة.
بدون خادم وSelectel
في Selectel نحن بالفعل من خلال لوحة التحكم الخاصة بنا نقوم الآن ببناء منصة FaaS الخاصة بنا. نريد أن يتمكن المطورون من حل مشكلاتهم باستخدام Serverless من خلال واجهة مريحة ومرنة.
إذا كانت لديك أفكار حول ما يجب أن تكون عليه منصة FaaS المثالية وكيف تريد استخدام Serverless في مشاريعك، شاركها في التعليقات. سنأخذ رغباتك بعين الاعتبار عند تطوير المنصة.
المواد المستخدمة في المقال:
المصدر: www.habr.com