خادوم و رد 2: خفة اليد و عدم الاحتيال

هل يمكنني إخبار مطوري الواجهة الأمامية عن الهيكل الخالي من الخوادم بدون سحابة داخل AWS (Amazon Web Services) بطريقة بسيطة؟ لما لا. دعونا نقدم تطبيق AWS React / Redux ، ثم نتحدث عن إيجابيات وسلبيات AWS lambdas.


تعتمد المواد على نص تقرير مارينا ميرونوفيتش من مؤتمر الربيع HolyJS 2018 في سانت بطرسبرغ.

رسميًا ، تعد مارينا مطورًا رائدًا لـ EPAM. وهي الآن تعمل في مجموعة مهندسين حلول للعميل وبسبب هذا تشارك في عدد كبير من المشاريع. لذلك ، سيكون من الأسهل بالنسبة لنا تحديد دائرة اهتماماتها الحالية بدلاً من سرد جميع التقنيات التي تعمل بها.

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

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

الجزء 1. الخلفية

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

إلى حد ما ، تم إدراك الفكرة - تحدثت عن Serverless في FrontTalks 2017. ولكن اتضح أن 45 دقيقة ليست كافية لقصة بسيطة ومفهومة. لذلك ، تم تقسيم التقرير إلى جزأين ، والآن أمامك "السلسلة" الثانية. الذين لم يروا الأول - لا تقلق ، لن يضر هذا بفهم ما هو مكتوب أدناه. كما هو الحال في البرامج التلفزيونية اللائقة ، سأبدأ بملخص الجزء السابق. ثم سأنتقل إلى العصير نفسه - سنقوم بتقديم تطبيق React / Redux. وأخيرًا ، سأتحدث عن إيجابيات وسلبيات الوظائف السحابية من حيث المبدأ (على وجه الخصوص ، AWS lambdas) وما الذي يمكن القيام به معهم. آمل أن يكون هذا الجزء مفيدًا لجميع أولئك الذين هم على دراية بـ AWS lambda. الأهم من ذلك ، أن العالم لا ينتهي بـ Amazon ، لذلك دعونا نتحدث عن ما هو آخر في مجال وظائف السحابة.

ما سأستخدمه

لتقديم التطبيق ، سأستخدم العديد من خدمات أمازون:

1. S3 هو نظام ملفات في السحب. هناك سنقوم بتخزين الأصول الثابتة.
   
2. IAM (حقوق الوصول للمستخدمين والخدمات) - بشكل ضمني ، ولكن سيتم استخدامها في الخلفية بحيث تتواصل الخدمات مع بعضها البعض.
   
3. API Gateway (عنوان URL للوصول إلى الموقع) - سترى عنوان URL حيث يمكننا استدعاء لامدا لدينا.
   
4. CloudFormation (للنشر) - سيتم استخدامه ضمنيًا في الخلفية.
   
5. AWS Lambda - لقد جئنا إلى هنا من أجل هذا.
   

ما هو بدون خادم وما هو AWS Lambda؟

في الواقع Serverless هو عملية احتيال كبيرة ، بالطبع هناك خوادم: في مكان ما ، يبدأ كل شيء. لكن ما الذي يحدث هناك؟

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


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

كيفية نشر لامدا

ينشأ سؤال منطقي: إذا لم يكن لدينا خادم ، كيف ننشره؟ يوجد SSH على الخادم ، قمنا بتحميل الكود ، أطلقناه - كل شيء على ما يرام. ماذا تفعل مع لامدا؟

الخيار 1. لا يمكننا نشره.

قدم AWS في وحدة التحكم IDE لطيفًا ولطيفًا لنا ، حيث يمكننا القدوم وكتابة وظيفة هناك.



إنها جميلة ، لكنها ليست قابلة للتوسعة للغاية.

الخيار 2. يمكننا عمل ملف مضغوط وتنزيله من سطر الأوامر

كيف نصنع ملف مضغوط؟

zip -r build/lambda.zip index.js [node_modules/] [package.json]

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

aws lambda create-function...

سواء

aws lambda update-function-code...

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

يمكننا القيام بذلك بشكل أفضل وأسهل. لهذا ، لدينا أطر عمل.

أطر AWS Lambda

هناك العديد من هذه الأطر. هذا هو في الأساس AWS CloudFormation ، والذي يعمل بالاشتراك مع AWS CLI. CloudFormation هو ملف Json يصف خدماتك. أنت تصفها في ملف Json ، ثم من خلال AWS CLI قل "تنفيذ" ، وسوف يقوم تلقائيًا بإنشاء كل شيء لك في خدمة AWS.

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

دعونا نحاول تبسيطه. وهنا تظهر أطر مختلفة: APEX ، Zappa (فقط ل Python) ، Claudia.js. أدرجت فقط عدد قليل ، بشكل عشوائي.

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

تمت كتابة Zappa فقط لـ Python. وأريد شيئًا أكثر طموحًا. وهنا يأتي Terraform وحبي بلا خادم.

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

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

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

بلا خادم

لماذا أحب Serverless؟

1. يحتوي Serverless على نظام يسمح لك بإنشاء مكونات إضافية. في رأيي ، هذا خلاص من كل شيء. خادم - مفتوح المصدر. ولكن ليس من السهل دائمًا إضافة شيء ما إلى المصدر المفتوح. أنت بحاجة إلى فهم ما يحدث في الكود الحالي ، ومراعاة الإرشادات ، على الأقل نمط الكود ، وإرسال العلاقات العامة ، وسوف ينسون هذا العلاقات العامة وسيجمع الغبار لمدة ثلاث سنوات. وفقًا للنتائج ، فأنت تفرع ، وسيكون هذا مكانًا لك بشكل منفصل. كل هذا ليس بصحة جيدة. ولكن عندما تكون هناك مكونات إضافية ، يتم تبسيط كل شيء. تحتاج إلى إضافة شيء ما - فأنت على ركبتك تقوم بإنشاء مكون إضافي صغير خاص بك. للقيام بذلك ، لم تعد بحاجة إلى فهم ما يحدث داخل Serverless (إذا لم يكن هذا سؤالًا مخصصًا للغاية). يمكنك ببساطة استخدام واجهة برمجة التطبيقات المتاحة ، في مكان ما تحفظ فيه المكون الإضافي أو تنشره للجميع. وكل شيء يعمل من أجلك. بالإضافة إلى ذلك ، هناك بالفعل حديقة حيوانات كبيرة من الإضافات والأشخاص الذين يكتبون هذه الإضافات. أي أنه ربما تم تحديد شيء لك بالفعل.
   
2. Serverless يساعد على تشغيل لامدا محليا. النقص الكبير بما فيه الكفاية من لامدا هو أن AWS لم تفكر في كيفية تصحيحه واختباره. لكن Serverless يسمح لك بتشغيل كل شيء محليًا ، انظر ما يحدث (حتى أنه يفعل ذلك بالاقتران مع Gateway API).
   

مظاهرة

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


mkdir sls-holyjs
cd sls-holyjs
sls create --template aws-nodejs-ecma-script



npm install



اعتنى بنا المطورون الذين لا يمتلكون خوادم - مما جعل من الممكن إنشاء خدمات من القوالب. في هذه الحالة ، أستخدم nodejs-ecma-script ، الذي سينشئ لي بعض الملفات ، مثل تهيئة حزمة الويب و package.json وبعض الوظائف و serverless.yml:

ls



لست بحاجة إلى جميع الميزات. سأزيل الاسم الأول والثاني في Holyjs:



سأقوم بتعديل serveless.yml قليلاً ، حيث لدي وصف لجميع الخدمات الضرورية:



حسنًا ، سأقوم بعد ذلك بإصلاح الاستجابة التي ترجعها الدالة:



سأجعل HTML "Hello HolyJS" وأضيف مقبضًا للعرض.

التالي:

sls deploy

وفويلا! هناك عنوان URL حيث يمكنني أن أرى في الوصول العام ما يتم تقديمه:



ثق ولكن تحقق. سأذهب إلى وحدة تحكم AWS وتحقق من أنني قمت بإنشاء وظيفة Holyjs:



كما ترى ، قبل نشره ، سيقوم Serverless ببنائه باستخدام webpack. بالإضافة إلى ذلك ، سيتم إنشاء بقية البنية التحتية الموضحة هناك - API Gateway ، إلخ.

عندما أريد إزالة هذا:

sls remove

سيتم حذف جميع البنية التحتية الموصوفة في serverless.yml.



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

قم بتشغيل لامدا محليًا

ذكرت أنه يمكن تشغيل لامدا محليًا. هناك خياران لبدء التشغيل هنا.

الخيار 1. ندير كل شيء في المحطة

نحصل على ما ترجع وظيفتنا.


sls invoke local -f [fn_name]

الخيار 2. إطلاق لامدا محليًا دون اتصال بالإنترنت

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

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

sls offline --port 8000 start

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

كان هذا ملخصا للجزء الأول من التقرير. الآن ننتقل إلى الجزء الرئيسي.

الجزء 2. التقديم مع AWS

المشروع الموضح أدناه موجود بالفعل على GitHub. إذا كنت مهتمًا ، يمكنك تنزيل الرمز هناك.

لنبدأ بكيفية عمل كل شيء.



افترض أن هناك مستخدم - لي.

• أفتح الموقع.
  
• في عنوان URL معين ، نصل إلى واجهة برمجة تطبيقات البوابة. أريد أن أشير إلى أن Gateway API هي بالفعل خدمة AWS ، نحن بالفعل في السحب.
  
• سيتصل Gateway API بلمدا.
  
• ستقوم لامدا بعرض الموقع ، وسيعود كل هذا إلى المتصفح.
  
• سيبدأ المتصفح في العرض ويدرك أن بعض الملفات الثابتة مفقودة. ثم سيتحول إلى دلو S3 (نظام الملفات الخاص بنا ، حيث سنقوم بتخزين جميع الإحصائيات ؛ في دلو S3 يمكنك وضع كل شيء - الخطوط ، الصور ، CSS ، JS).
  
• ستعود البيانات من مجموعة S3 إلى المتصفح.
  
• المتصفح سيعرض الصفحة.
  
• الجميع سعداء.
  

دعنا نراجع قليلا ما كتبته.

إذا ذهبت إلى GitHub ، فسترى بنية الملف التالية:

lambda-react
README.md
config
package.json
public
scripts
serverless.yml
src
yarn.lock

يتم إنشاء كل هذا تلقائيًا في مجموعة أدوات React / Redux. في الواقع ، سنهتم هنا بملفين فقط ويجب تصحيحهما قليلاً:

• التكوين
  
• حزمة
  
• serverless.yml - لأننا سننشر ،
  
• src - في أي مكان بدونها.
  

لنبدأ مع التكوين

للحصول على كل شيء معًا على الخادم ، نحتاج إلى إضافة webpack.config آخر:



سيتم إنشاء webpack.config هذا بالفعل من أجلك إذا كنت تستخدم القالب. وهناك يتم استبدال المتغير slsw.lib.entries تلقائيًا ، والذي slsw.lib.entries إلى معالجات لامدا الخاصة بك. إذا كنت تريد ، يمكنك تغييره بنفسك عن طريق تحديد شيء آخر.



سنحتاج إلى تقديم كل شيء للعقدة ( target: 'node' ). من حيث المبدأ ، تظل جميع اللوادر الأخرى كما هي في حالة استخدام التفاعل العادي.

مزيد من package.json

سنضيف فقط اثنين من النصوص البرمجية - تم إنشاء البداية والبناء بالفعل مع React / Redux - لا شيء يتغير. أضف نصًا برمجيًا لتشغيل لامدا ونصًا برمجيًا لنشر لامدا.

خادم بدون خادم

ملف صغير للغاية - 17 سطراً فقط ، جميعها أدناه:



ما هو المثير للاهتمام فينا؟ بادئ ذي بدء ، معالج. المسار الكامل للملف src/lambda/handler ( src/lambda/handler ) ويتم تحديد وظيفة المعالج من خلال النقطة.

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

الأكثر إثارة للاهتمام هو src

هنا هو تطبيق React / Redux ضخم (في حالتي ليس ضخمًا - إلى الصفحة). في مجلد لامدا الإضافي ، كل ما نحتاجه لتقديم لامدا:



هذه ملفات 2:



لنبدأ بالمعالج. الأهم خط 13. هذا هو العارض ، وهو لامدا جدا سيتم استدعاؤه في السحب:



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

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



الشيء الأكثر إثارة للاهتمام هنا هو وظيفة render ، والتي ستعرض صفحتنا:



تأتي هذه الوظيفة إلينا من adver.js. دعونا نرى ما هناك.

يتم تقديم تطبيق متماثل هناك. علاوة على ذلك ، يتم تقديمه على أي خادم - لا يهم ما إذا كان لامدا أم لا.

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



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

لكي لا تخسر أحدا ، أنا فقط اصعد ، أخبر ما يحدث هناك.
بادئ ذي بدء ، نحن بحاجة لتقديم هذا مع HTML / React / Redux.

يتم ذلك من خلال طريقة renderToString القياسية - تقديم إلى renderToString :



بعد ذلك ، نحتاج إلى تقديم الأنماط حتى لا يومض المحتوى الخاص بنا. هذه ليست مهمة تافهة للغاية. هناك العديد من حزم npm التي تحلها. على سبيل المثال ، استخدمت styleTag node-style-loader ، والتي ستجمع كل شيء معًا في styleTag ، ثم يمكنك لصقه في HTML.



إذا كانت هناك حزم أفضل - فهي حسب تقديرك.

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


الآن أقرب قليلا إلى لامدا.

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



بعد ذلك ، نحتاج إلى استبدال عناوين URL الخاصة بنا بملفات ثابتة. ولهذا نحتاج إلى معرفة أين تجري لامدا - محليًا أو في مكان ما في السحب. كيف تعرف؟

سنفعل ذلك من خلال متغيرات البيئة:



…
const bundleUrl = process.env.NODE_ENV === 'AWS' ?
AWS_URL : LOCAL_URL;

سؤال مثير للاهتمام: كيف تلتقي متغيرات البيئة في لامدا. في الواقع سهلة بما فيه الكفاية. في yml ، يمكنك تمرير أي متغيرات إلى environment . عندما يتم قفلها ، ستكون متاحة:



حسنًا ، مكافأة - بعد أن نشرنا لامدا ، نريد نشر جميع الأصول الثابتة. للقيام بذلك ، قمنا بالفعل بكتابة مكون إضافي حيث يمكنك تعيين سلة S3 حيث تريد نشر شيء ما:


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

الآن دعونا نتحدث قليلاً عن النظرية - إيجابيات وسلبيات لامدا.

لنبدأ بالسيء.

وظائف سلبيات لامدا

قد تتضمن السلبيات (أو ربما لا) وقت البدء البارد. على سبيل المثال ، بالنسبة إلى لامدا على Node.js التي نكتبها الآن ، فإن وقت البدء البارد لا يعني الكثير.

يوضح الرسم البياني أدناه وقت البدء البارد. ويمكن أن يكون هذا أمرًا كبيرًا ، خاصة بالنسبة إلى Java و C # (انتبه إلى النقاط البرتقالية) - لا تريد أن يستغرق الأمر خمس أو ست ثوانٍ لبدء الرمز.

بالنسبة إلى Node.js ، يكون وقت البدء صفرًا تقريبًا - 30 - 50 مللي ثانية. بالطبع ، بالنسبة للبعض قد يكون هذا مشكلة. ولكن يمكن تسخين الوظائف (على الرغم من أن هذا ليس موضوع هذا التقرير). إذا كان أي شخص مهتمًا بكيفية إجراء هذه الاختبارات ، فمرحبًا بك في acloud.guru ، سيخبرك بكل شيء ( في المقالة ).



إذن ما هي السلبيات؟

قيود حجم رمز الوظيفة

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

قيود وقت التشغيل

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

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



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

عدد الوظائف المتوازية في الدقيقة

أعلاه هو حد 500 إلى 3000 ، حسب المنطقة التي تتواجد فيها. في رأيي ، في أوروبا ما يقرب من 500. 3000 مدعوم في الولايات المتحدة.

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

يأتي الطلب إلينا ونحصل على لامدا. أثناء تنفيذ هذه اللمدا ، يأتي إلينا طلبان آخران - نبدأ اثنين آخرين من لامدا. يبدأ الناس في القدوم إلى موقعنا ، وتظهر الطلبات ويتم إطلاق lambdas ، أكثر وأكثر.



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

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

إذا كان تحميل 3000 طلب عادي بالنسبة لك ، يمكنك الكتابة في AWS وسوف يرفعون الحد.

عديم الجنسية

هذا هو الأخير ، مرة أخرى ، ناقص مثير للجدل.

ما هو عديم الجنسية؟ هنا تأتي نكتة عن الأسماك الذهبية - فهي ببساطة لا تحمل السياق:



لامدا ، التي تسمى المرة الثانية ، لا تعرف شيئًا عن المكالمة الأولى.

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

يأتي المستخدم ويقول: إرسال نموذج SMS رقم 1. ويرسله النظام إلى جهاز حقيقي.



في مرحلة ما ، يعبر المنتج عن رغبته في معرفة ما سيذهب إلى هناك ، والتحقق من عدم حدوث أي كسر في هذا النظام في أي مكان. للقيام بذلك ، سنستبدل الجهاز الحقيقي بنوع من رقم الاختبار - على سبيل المثال ، يمكن لـ Twilio القيام بذلك. سيتصل بـ Webhook ، ويرسل نص SMS ، وسوف نقوم بمعالجة نص SMS هذا في التطبيق (نحتاج إلى التحقق من أن القالب الخاص بنا أصبح SMS الصحيح).

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



دعونا نحاول أن نفعل نفس الشيء على لامدا.

ستقوم لامدا بإرسال رسائل نصية قصيرة ، وسوف تصل الرسائل القصيرة إلى Twilio.



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

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

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



البنغو!

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

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

إيجابيات وظائف لامدا

هناك عدد أقل منهم ، ولكن يبدو لي أكثر متعة.

• بادئ ذي بدء ، ننسى حقًا أن هناك خادمًا. بصفتي مطورًا ، أكتب دالة في جافا سكريبت ، وهذا كل ما في الأمر. أنا متأكد من أن العديد منكم كتب وظائف في جافا سكريبت ، لا تحتاج إلى معرفة المزيد عن هذا الأمر.
  
• لا حاجة للتفكير في ذاكرة التخزين المؤقت ، ولا حول التحجيم ، الرأسي أو الأفقي. ما كتبته سيعمل. لا يهم إذا جاء شخص واحد إلى موقعك في الشهر أو سيكون هناك مليون زيارة.
  
• في حالة AWS lambdas ، لديهم بالفعل تكامل خاص بهم مع جميع خوادمهم تقريبًا (DynamoDB و Alexa و API Gateway وما إلى ذلك).
  

ما الذي يمكن فعله على لامداس؟

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

من حيث المبدأ ، على lambdas يمكنك القيام بأي شيء ... بعلامة النجمة.

• خدمات HTTP هي ما كنت أتحدث عنه. REST API ، كل API endpoint هو lambda واحد. تطابق تماما. النظر بشكل خاص في كيفية استخدام المؤسسة غالبًا node.js لإنشاء برامج وسيطة. لدينا جافا يقوم بكل التكاليف ، ثم نكتب طبقة على شبيبة تعالج الطلبات بسهولة بالغة. يمكن إعادة كتابته في lambdas وسيكون أكثر برودة.
  
• IoT — , Alexa - -, , .
  
• Chat Bots — , IoT.
  
• Image/Video conversions.
  
• Machine learning.
  
• Batch Jobs — - , Batch Job .
  

الآن ، بالإضافة إلى Amazon و Google و Azure و IBM و Twillio ، تريد جميع الخدمات الكبيرة تقريبًا تنفيذ وظائف السحابة في منازلهم. إذا قام Roskomnadzor بحظر كل شيء ، فإننا نبدأ خادمًا مفضلًا صغيرًا في مرآبنا وننشر الحوسبة السحابية هناك. للقيام بذلك ، نحتاج إلى مصدر مفتوح (وكل هذا بسبب أن عليك أن تدفع مقابل الخدمات ، والمصدر المفتوح مجاني). والمصدر المفتوح لا يقف ساكنا. لقد قاموا بالفعل بتنفيذ قدر غير واقعي من عمليات التنفيذ لكل هذا. سأقول الآن كلمات مخيفة للواجهات - Docker Swarm ، Kubernetes - كل شيء يعمل بهذه الطريقة.

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

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

• وظائف الحديد
  
• Fnproject
  
• Openfaas
  
• اباتشي OpenWhisk
  
• Kubeless
  
• الانشطار
  
• Funktion
  

لقد جربت Fnproject وقضيت بضع ساعات فقط لنقل هذا التطبيق المتشابه إلى Fnproject وتشغيله محليًا باستخدام حاوية Kubernetes.

انها لا تزال قابلة للتطوير بسرعة. سيكون لديك مجموعة من واجهات API للبوابة (بالطبع ، بدون بقية الخدمات) ، ولكن لا يزال لديك عنوان URL يستدعي لامدا. وفي الواقع ، يمكن للجميع تقريبًا نسيان الخوادم ، كما وعد ، باستثناء شخص واحد سينشر هذا الإطار وتكوين تنسيق Kubernetes بحيث يمكن للمطورين السعداء استخدامه في وقت لاحق.

. HolyJS 2018 Moscow, 24-25 . , Early Bird-.