أعمل في مجال الاستعانة بمصادر خارجية، حيث يمكن وصف المبدأ الرئيسي بعبارة "بيع كثيرًا، افعل ذلك بسرعة". كلما قمنا بذلك بشكل أسرع، كلما كسبنا المزيد. ومن المرغوب فيه أن كل شيء لا يعمل على العكازات والمخاط، ولكن بمستوى مقبول من الجودة. سأخبرك عن تجربتي عندما كان من الضروري تطوير خدمة ترويجية في فترة زمنية قصيرة.
الممنوحة: حساب جذر على AWS، ولا توجد قيود على اختيار مجموعة التكنولوجيا، وواجهة خلفية واحدة، وشهر واحد للتطوير.
المشكلة: تنفيذ خدمة ترويجية حيث يقوم المستخدمون بتحميل ما بين مقطع فيديو واحد إلى أربعة مقاطع فيديو تتراوح مدتها من ثانية إلى أربع ثوانٍ، ثم يتم تضمينها بعد ذلك في سلسلة مقاطع الفيديو الأصلية.
حل
إن كتابة خدمة الدراجات الخاصة بك في مثل هذا الوقت القصير ليست فكرة جيدة. بالإضافة إلى ذلك، لكي تتمكن الخدمة من التعامل مع الحمل ولكي يحصل الجميع على الفيديو المطلوب، ستكون هناك حاجة إلى بنية تحتية. ويفضل ألا يكون ذلك مع ثمن الطائرة. ولذلك، فإننا نركز على الفور على الحلول الجاهزة مع الحد الأدنى من التخصيص.
الحل القياسي للعمل مع الفيديو هو FFmpeg، وهي أداة مساعدة لوحدة التحكم عبر الأنظمة الأساسية تسمح لك، من خلال الوسائط، بقص الصوت وزيادة الصوت. كل ما تبقى عليك فعله هو كتابة غلاف وإطلاقه في الحياة. نكتب نموذجًا أوليًا يجمع مقطعي فيديو معًا، و... تبدأ المتعة. تعتمد المكتبة على .NET Core 2، ويجب تشغيلها على أي جهاز افتراضي، لذلك نأخذ مثيل AWS EC2 وسيعمل كل شيء
النص المخفيلا، لن ينجح
.
على الرغم من أن FFmpeg يبسط المهمة، إلا أنه للحصول على حل فعال حقًا، فإنك تحتاج إلى إنشاء مثيل EC2 وتصميم بنية أساسية للشبكة له، بما في ذلك Load Balancer. تصبح المهمة البسيطة المتمثلة في النشر من الصفر أكثر تعقيدًا "قليلاً"، وتبدأ البنية التحتية في المطالبة بالمال على الفور - كل ساعة يتم سحب مبلغ وقت التشغيل من حساب العميل.
لا تتضمن خدمتنا عمليات طويلة الأمد، ولا تتطلب قاعدة بيانات علائقية كبيرة وكبيرة، وتتناسب تمامًا مع البنية القائمة على الأحداث مع سلسلة من مكالمات الخدمات الصغيرة. يقترح الحل نفسه - يمكننا التخلي عن EC2 وتنفيذ تطبيق حقيقي بدون خادم، مثل Image Resizer القياسي المستند إلى AWS Lambda.
بالمناسبة، على الرغم من الكراهية الواضحة لمطوري AWS لـ .NET، إلا أنهم يدعمون .NET Core 2.1 كوقت تشغيل، مما يوفر مجموعة كاملة من فرص التطوير.
والكرز على الكعكة - توفر AWS خدمة منفصلة للعمل مع ملفات الفيديو - AWS Elemental MediaConvert.
جوهر العمل بسيط للغاية: نأخذ رابط S3 للفيديو الصادر، ونكتب من خلال وحدة تحكم AWS، أو .NET SDK أو ببساطة JSON ما نريد أن نفعله بالفيديو ونتصل بالخدمة. فهو يقوم بنفسه بتنفيذ قوائم الانتظار لمعالجة الطلبات الواردة، وتحميل النتيجة إلى S3 نفسه، والأهم من ذلك، إنشاء حدث CloudWatch لكل تغيير في الحالة. يتيح لنا ذلك تنفيذ مشغلات لامدا لإكمال معالجة الفيديو.
وهذا ما تبدو عليه البنية النهائية:
الواجهة الخلفية بأكملها موجودة في اثنين من لامدا. خيار آخر مخصص لتدوير مقاطع الفيديو الرأسية، حيث لا يمكن تنفيذ هذا العمل في مسار واحد.
سنضع الواجهة في شكل تطبيق SPA مكتوبًا بلغة JS ويتم تجميعه عبر Pug في حاوية S3 العامة. لتنزيل مقاطع الفيديو نفسها، لا نحتاج إلى أي رمز خادم - نحتاج فقط إلى فتح نقاط نهاية REST التي توفرها لنا S3. الشيء الوحيد هو عدم نسيان تكوين السياسات وCORS.
المزالق
- لسبب غير معروف، يقوم AWS MediaConvert بتطبيق الصوت فقط على كل جزء من الفيديو بشكل منفصل، ولكننا نحتاج إلى أغنية مبهجة من شاشة التوقف بأكملها.
- يجب معالجة مقاطع الفيديو العمودية بشكل منفصل. لا تحب AWS الأشرطة السوداء وتضع البكرات عند 90 درجة.
حلبة تزلج سهلة
على الرغم من كل جمال Stateless، إلا أنك تحتاج إلى متابعة ما يجب فعله بالفيديو: لصق الصوت أو إضافته إلى تسلسل الفيديو النهائي. لحسن الحظ، يدعم MediaConvert تمرير البيانات التعريفية من خلال وظائفه، ويمكننا دائمًا استخدام علامة بسيطة على شكل "isMasterSoundJob"، لتحليل هذه البيانات التعريفية في أي مرحلة.
يسمح Serverless بالعمل مع NoOps بشكل مثالي - وهو نهج يفترض عدم ضرورة وجود فريق منفصل مسؤول عن البنية التحتية للمشروع. لذلك، كان الأمر بسيطًا - لقد قمنا بنشر الحل على AWS دون مشاركة مسؤولي النظام، الذين لديهم دائمًا ما يفعلونه على أي حال.
ولتسريع كل هذا، نقوم بأتمتة البرنامج النصي للنشر قدر الإمكان على AWS CloudFormation، مما يسمح لك بالنشر بزر واحد مباشرة من VS. ونتيجة لذلك، يسمح لك ملف مكون من 200 سطر من التعليمات البرمجية بطرح حل جاهز، على الرغم من أن بناء جملة CloudFormation يمكن أن يكون صادمًا إذا لم تكن معتادًا عليه.
في المجموع
Serverless ليس حلا سحريا. ولكنها ستجعل الحياة أسهل بكثير في المواقف ذات الحدود الثلاثة: "الموارد المحدودة - المدى القصير - القليل من المال".
خصائص التطبيقات المناسبة للأنظمة التي لا تحتوي على خادم
- بدون عمليات طويلة الأمد. الحد الأقصى لبوابة API هو 29 ثانية، والحد الأقصى لـ lambda هو 5 دقائق؛
- موصوفة بالهندسة المعمارية المبنية على الأحداث؛
- ينقسم إلى مكونات مترابطة بشكل غير محكم مثل SOA؛
- لا يتطلب الكثير من العمل مع حالتك؛
- مكتوب في .NET الأساسية. للعمل مع .NET Framework، ستظل بحاجة إلى Docker على الأقل مع وقت التشغيل المناسب.
فوائد النهج بدون خادم
- ويقلل من تكاليف البنية التحتية؛
- ويقلل من تكلفة تقديم الحل؛
- قابلية التوسع التلقائي؛
- التنمية في طليعة التقدم التكنولوجي.
العيوب، مع مثال محدد
- التتبع والتسجيل الموزع - تم حله جزئيًا من خلال AWS X-Ray وAWS CloudWatch؛
- تصحيح غير مريح
- البدء البارد في حالة عدم وجود حمل؛
- تعد واجهة المستخدم المعادية لـ AWS مشكلة عالمية :)
المصدر: www.habr.com