وظائف بدون خادم: اقتصاديات التوسع إلى الصفر
توقف عن الدفع مقابل وحدات المعالجة المركزية (CPU) الخاملة. دليل فني لـ AWS Lambda، وVercel Edge Functions، والبنية المستندة إلى الأحداث.
في نموذج الاستضافة التقليدي (EC2، DigitalOcean)، يمكنك استئجار جهاز كمبيوتر. أنت تدفع 50 دولارًا شهريًا. إذا لم يقم أحد بزيارة موقعك في الساعة 3:00 صباحًا، فسيظل الكمبيوتر خاملاً. لا تزال تدفع. إذا قام 100.000 شخص بزيارة الموقع في الساعة 10:00 صباحًا، فسيتعطل جهاز الكمبيوتر. تخسر الإيرادات.
هذه هي معضلة تخطيط القدرات. يجب عليك بشكل صارم الإفراط في توفير التعامل مع فترات الذروة، مما يعني أنك تدفع أكثر من اللازم بنسبة 99٪ من الوقت.
بدون خادم (FaaS) يقلب النموذج. أنت لا تستأجر جهاز كمبيوتر. قمت بتحميل الكود. أنت تدفع لكل استدعاء.
- 0 زيارات = 0.00 دولار.
- 1 مليون زيارة = تقوم AWS بتدوير 1000 وظيفة متزامنة. أنت تدفع بالضبط مليون ثانية تنفيذ.
في Maison Code Paris، نستخدم Serverless ليس فقط من أجل التكلفة، ولكن من أجل البساطة التشغيلية. نحن لا نقوم بتصحيح نواة Linux. نحن لا نقوم بتدوير مفاتيح SSH. نحن نركز على المنطق.
لماذا تتحدث Maison Code عن هذا
في Maison Code Paris، نعمل كضمير معمari لعملائنا. غالبًا ما نرث حزمًا “حديثة” تم بناؤها دون فهم أساسي للحجم.
نناقش هذا الموضوع لأنه يمثل نقطة تحول حاسمة في النضج الهندسي. التنفيذ الصحيح يميز MVP الهش عن منصة مؤسسية مرنة يمكنها التعامل مع حركة مرور الجمعة السوداء.
لماذا تتبنى Maison Code الخدمة بدون خادم أولاً
نحن نتعامل مع البنية التحتية باعتبارها التزامًا، وليس أحد الأصول. كل خادم نديره هو خادم يمكن أن يتعطل. تتوافق فلسفتنا “التوسع إلى الصفر” مع الربح والخسارة لعملائنا:
- الكفاءة: لقد قمنا بترحيل وظائف cron القديمة للعميل من EC2 المخصص بقيمة 100 دولار شهريًا إلى Lambda. انخفضت التكلفة إلى 0.12 دولار شهريًا.
- المرونة: خلال يوم الجمعة الأسود، ارتفع عدد نقاط النهاية بدون خادم لدينا إلى 5000 عملية تنفيذ متزامنة دون مهلة واحدة.
- التركيز: يقضي مهندسونا 100% من وقتهم في منطق الأعمال (التسعير، سلة التسوق، الخروج)، وليس على تنسيق Docker.
الهندسة المعمارية: أنماط تعتمد على الأحداث
يعد Serverless هو الأفضل عندما يكون غير متزامن.
بينما يمكنك تشغيل واجهة برمجة التطبيقات القياسية (GET /users)، فإن القوة الحقيقية تكمن في مصادر الأحداث.
نمط المخزن المؤقت (SQS + Lambda)
السيناريو: تقوم بتشغيل Flash Sale. 10.000 مستخدم يقومون بالخروج في ثانية واحدة. إذا قمت بتوصيل Lambda مباشرة بـ ERP (SAP/NetSuite)، فسوف تقوم بإلغاء الخدمة (DDoS) لتخطيط موارد المؤسسات (ERP) الخاص بك. لا يمكنه التعامل مع 10 كيلو اتصالات.
الحل:
- بوابة واجهة برمجة التطبيقات: تقبل طلب HTTP. إرجاع “تم قبول 202”.
- SQS (خدمة قائمة الانتظار البسيطة): يخزن الطلب في قائمة الانتظار. يمكنه حمل ملايين الرسائل.
- لامدا: يستطلع قائمة الانتظار. يقوم بمعالجة الرسائل بمعدل متحكم فيه (على سبيل المثال، 50 رسالة في المرة الواحدة).
- النتيجة: يتلقى نظام تخطيط موارد المؤسسات (ERP) الخاص بك تدفقًا مستمرًا من الطلبات، وليس تسونامي. يحصل المستخدم على استجابة سريعة.
معالجة الفشل: قائمة انتظار الرسائل الميتة (DLQ)
في خادم Node.js، إذا تعطل الطلب، فسيتم فقده. في Serverless، نقوم بتكوين إعادة المحاولة. ستعيد AWS Lambda محاولة وظيفة المزامنة الفاشلة مرتين تلقائيًا. إذا استمر الفشل (على سبيل المثال، خطأ في التعليمات البرمجية)، فإنه ينقل الحدث إلى Dead Letter Queue (DLQ). يمكن للمهندسين فحص DLQ وإصلاح الخلل و”إعادة تشغيل” الرسائل. يتم فقدان أية بيانات.
مشكلة البداية الباردة
الموارد ليست مجانية. لتوفير المال، تقوم AWS بإيقاف تشغيل الحاوية الخاصة بك إذا لم يتم استخدامها لمدة 15 دقيقة تقريبًا. يؤدي الطلب التالي إلى تشغيل البداية الباردة.
- تقوم AWS بتخصيص microVM (Firecracker).
- تنزيل التعليمات البرمجية الخاصة بك.
- يبدأ تشغيل Node.js.
- يقوم بتشغيل المعالج الخاص بك.
زمن الوصول: ~300 مللي ثانية - 1 ثانية (Node.js). ~3ث (جافا). التأثير: مناسب للوظائف الخلفية. سيئة بالنسبة لواجهات برمجة التطبيقات الخاصة بالخروج.
الحل: Vercel Edge Runtime (V8 المعزولة)
قدم Vercel (وCloudflare Workers) وقت تشغيل جديدًا. بدلاً من تشغيل حاوية Node.js كاملة (VM + OS + Node)، فإنها تعمل على V8 Isolates. هذا هو نفس المحرك الذي يقوم بتشغيل JavaScript في Chrome.
- البدء البارد: ~0 مللي ثانية.
- الحدود: لا يمكنك استخدام واجهات برمجة تطبيقات Node.js مثل
fsأوchild_processأو الثنائيات الأصلية. - حالة الاستخدام: البرامج الوسيطة، وإعادة توجيه المصادقة، ومجموعات اختبار A/B، والتوجيه الجغرافي.
مصيدة قاعدة البيانات: تجمع الاتصالات
هذا هو المكان الذي يفشل فيه 90٪ من المبتدئين.
تفتح مكتبة Postgres القياسية (pg) اتصال TCP.
في خادم متراص، يمكنك فتح اتصال واحد ومشاركته.
في Serverless، كل وظيفة عبارة عن حاوية معزولة.
إذا كان لديك 1000 مستخدم متزامن، فيمكنك فتح 1000 اتصال قاعدة بيانات.
ينفد Postgres من ذاكرة الوصول العشوائي ويتعطل. فادح: فتحات الاتصال المتبقية محجوزة.
الحل 1: تجميع الاتصالات (PgBouncer) خدمة وسيطة تقع أمام Postgres. إنه يحتوي على 1000 اتصال عميل ولكنه يقوم بتعيينها إلى 10 اتصالات قاعدة بيانات حقيقية. يقوم DigitalOcean وAWS RDS Proxy بإيقاف هذه الخدمة كخدمة.
الحل 2: قواعد البيانات المستندة إلى HTTP
يقدم موفرو قواعد البيانات الجدد (Neon وPlanetScale وSupabase) واجهات برمجة تطبيقات HTTP.
لا تفتح مقبس TCP. أنت جلب ('https://db.neon.tech/query').
HTTP عديم الحالة. إنه يتدرج بشكل مثالي مع Serverless.
// استخدام النيون (Postgres بدون خادم)
استيراد {نيون} من '@neondatabase/serverless'؛
const sql = neon(process.env.DATABASE_URL);
تصدير معالج وظيفة غير متزامن (الحدث) {
نتيجة const = انتظار sql`SELECT * FROM users`;
العودة { الجسم: JSON.stringify (نتيجة) }؛
}
إدارة الحالة: لا توجد ذاكرة
في الخادم العادي، يمكنك القيام بما يلي:
دع requestCount = 0; app.get('/', () => requestCount++);
في Serverless، سيكون requestCount دائمًا 1 أو 0.
يتم تدمير الحاوية بعد التنفيذ. يتم مسح المتغيرات العالمية.
القاعدة: كل الحالات يجب أن تكون خارجية.
- بيانات الجلسة -> Redis.
- بيانات المستخدم -> قاعدة البيانات.
- تحميلات الملفات -> S3 / تخزين Blob.
لا تكتب إلى
/tmp(يختفي). لا تستخدم المتغيرات العالمية.
تحليل التكلفة: نقطة التحول
إن الخدمة بدون خادم ليست دائمًا أرخص. يحتوي على “ترميز” على الحوسبة الأولية (حوالي 2x تكلفة لكل دورة وحدة المعالجة المركزية مقارنة بـ EC2). يأتي التوفير من 0% وقت الخمول.
- ** حركة مرور منخفضة / حركة مرور سبايكي **: الخدمة بدون خادم أرخص بنسبة 90%.
- تحميل مرتفع مستمر: إذا كانت لديك عملية تعمل على مدار الساعة طوال أيام الأسبوع (مثل خادم WebSocket أو معالجة البيانات الثقيلة)، فإن EC2 أرخص. نقوم بإجراء عمليات تدقيق TCO (التكلفة الإجمالية للملكية) للعملاء. في كثير من الأحيان، التكلفة التشغيلية لإدارة EC2 (التصحيح والأمان) تجعل Serverless هو الفائز حتى عند الكميات الكبيرة.
الكود: طريق Vercel API (أفضل الممارسات)
نحن نبني وظائفنا لتكون قابلة للاختبار، ونفصل المنطق عن الشبكة.
// app/api/checkout/route.ts (جهاز توجيه تطبيق Next.js)
استيراد { NextResponse } من "الخادم/التالي"؛
استيراد { createCheckout } من '@/lib/checkout'؛ // منطق الأعمال
// المعالج (طبقة الشبكة)
تصدير وظيفة غير متزامنة POST(طلب: طلب) {
حاول {
جسم ثابت = انتظار request.json();
// التحقق من صحة الإدخال (Zod)
إذا (!body.cartId) {
return NextResponse.json({ error: 'معرف سلة التسوق مفقود' }، { الحالة: 400 });
}
// منطق الاتصال
const url = انتظار createCheckout(body.cartId);
إرجاع NextResponse.json({ url });
} التقاط (خطأ) {
console.error(error); // السجلات إلى CloudWatch / Datadog
إرجاع NextResponse.json({ خطأ: 'خطأ داخلي' }، { الحالة: 500 });
}
}
10. إمكانية الملاحظة: التتبع الموزع
في كتلة متراصة، يمكنك استخدام grep server.log.
في الوضع بدون خادم، يقوم طلب مستخدم واحد بالضغط على API Gateway -> Lambda A -> SQS -> Lambda B -> DynamoDB.
وإذا فشلت، أين فشلت؟
لا يمكنك grep السجلات عبر 5 خدمات.
نقوم بتنفيذ التتبع الموزع (OpenTelemetry / AWS X-Ray).
نقوم بتمرير رأس “trace_id” عبر كل خدمة.
يؤدي هذا إلى إنشاء “رسم بياني لهب” يوضح بالضبط مكان حدوث ارتفاع زمن الاستجابة (على سبيل المثال، “استغرق Lambda B 3 ثوانٍ لأن DynamoDB كان يخنق”).
11. أسطورة حبس البائع
غالبًا ما يقول المراجعون: “بدون خادم يقفلك في AWS”. حقيقي. لكن Docker يحبسك في Linux Kernel. React يقفلك في Virtual DOM. الحجز أمر لا مفر منه. السؤال هو: “هل يستحق القفل هذه السرعة؟” يمكننا إعادة كتابة دالة Lambda في Go/Rust خلال يوم واحد. تكلفة الترحيل بعيدًا عن Serverless منخفضة لأن وحدات التعليمات البرمجية صغيرة. تكلفة عدم استخدام Serverless (إدارة أساطيل EC2) مرتفعة ومستمرة.
13. الأمان: الامتياز الأقل (IAM)
لامدا واحد = دور واحد.
لا تمنح جهاز Lambda الخاص بك “وصول المسؤول”.
إذا تم اختراق Lambda (حقن التبعية)، فإن المهاجم يمتلك حسابك.
أعطها: s3:GetObject على bucket-a فقط.
يتفوق نموذج الأمان الدقيق هذا على Monolith حيث يتمتع الخادم بأكمله بحق الوصول الجذري إلى قاعدة البيانات.
تعمل أدوات مثل SST (Serverless Stack) على أتمتة عملية إنشاء السياسة هذه:
يقوم bucket.grantRead(lambda) بإنشاء سياسة IAM الصارمة تلقائيًا.
14. أطر العمل: لماذا نستخدم SST
تشكيل السحابة الخام أمر مؤلم. Terraform مطول. نحن نستخدم SST (مكدس بدون خادم). يسمح لنا بتحديد البنية التحتية في TypeScript. إنه يتيح “Live Lambda Development” (وكلاء البيئة المحلية لـ AWS). يمكنك تعيين نقاط التوقف في VS Code، والوصول إلى نقطة النهاية، ويتوقف مؤقتًا داخل Lambda الذي يعمل على AWS. هذه هي الطريقة الوحيدة لتطوير Serverless بشكل معقول.
15. الاستنتاج
الوظائف بدون خادم هي الغراء للإنترنت الحديث. إنها تسمح لمهندسي الواجهة الأمامية بأن يصبحوا “Full Stack” دون الحاجة إلى شهادة في إدارة Linux. إنها تتسع إلى ما لا نهاية. أنها لا تكلف شيئا عندما تكون خاملة. ولكنها تتطلب عقلية منضبطة “عديمة الجنسية”.
هل تدفع مقابل وقت التشغيل الخامل؟
هل تقوم بتشغيل خادم بقيمة 100 دولار لمهمة تستغرق 5 ثوانٍ يوميًا؟ قم بتوظيف مهندسينا.