ستون حاوية على خادم واحد
صندوق معدن عارٍ واحد يشغّل عشرات إلى مئات حاويات Hoody. تجعل KSM وإزالة التكرار في BTRFS التكلفة الهامشية قريبة من الصفر.
تتيح SaaS الخاصّة بك لكلّ عميل جدولة توليد تقاريره. التصميم الساذج: مُجدوِل واحد مشترك، معرّف العميل في حمولة المهمّة، أصابع متشابكة لئلّا يجوّع أحدهم الآخر. تصميم Hoody يمنح كلّ مستأجر حاويته الخاصّة وخدمة hoody-cron الخاصّة به.
ثلاث حالات لدورة الحياة، واجهة HTTP API واحدة. PROVISION يضيف الإدخالات، نبضات cron تشغّلها، DELETE يعلِّقها. cron كل مستأجر يعيش داخل حاويته الخاصة — لا قائمة انتظار مشتركة، لا خطر جار مزعج.
كلّ حاوية عميل تكشف API الـ HTTP لـ hoody-cron. لتحديد جدوله، تستبدل crontab بـ PUT واحد. لا طابور مشترك، لا مسار أولويّة، لا إعداد مُجدوِل تعيد نشره.
# POST managed entry for acme-corp tenant
POST acme-cron.hoody.com/users/root/entries
Content-Type: application/json
{
"schedule": "0 9 * * *",
"command": "/usr/local/bin/digest.sh",
"comment": "daily digest",
"enabled": true
}HTTP/1.1 201 Created
Content-Type: application/json
{
"id": "7d3f2a1b-8c4e-4f9a-b2d5",
"schedule": "0 9 * * *",
"schedule_human": "At 09:00",
"enabled": true,
"user": "root"
}تستبدل النقطة crontab بأكمله ذرّيّاً. تُعاد القيود المحذوفة في الردّ ليتمكّن مستوى التحكّم لديك من تدقيق الانحراف. cron كلّ مستأجر يعيش داخل حاويته الخاصّة؛ لا شيء من جدول acme-corp مرئيّ لـ globex-saas، ومهمّة هاربة في حاوية لا يمكنها تجويع المُجدوِل في أخرى.
ثلاث خصائص تنبثق من التصميم مجّاناً، لأنّ العزل هو الأساس، لا ميزة كتبتها.
حين يتعطل scrape.js الخاص بـ initech-inc، يُطلق ملخّص acme-corp في الساعة التاسعة صباحاً كالعادة. crontabs مختلفة، شجرات عمليات مختلفة، أنظمة ملفات مختلفة.
POST إدخال جديد فيلتقطه خدمة hoody-cron الخاصة بالمستأجر فوراً. لا مجدول مركزي لإعادة تحميله، لا بث للإرسال.
حين يسأل globex-saas لماذا تشغّل ملخّصهم لسادسة مساءً مرتين، تقرأ سجل حاوية واحدة — لا grep مشترك عبر جدول مركزي على تسع آلات.
ثلاثة محاور يفرض فيها التصميم القديم ضرائب على فريقك، ولا يفعل تصميم Hoody.
العمود القديم هو ما يكتبه كلّ فريق أوّل مرّة يشحن جدولة متعدّدة المستأجرين. العمود الجديد هو ما تشحنه حين تمنحك المنصّة لكلّ مستأجر حاويته افتراضيّاً.
ما يفعله صندوق معدن عارٍ واحد من Hoody حين يحصل كلّ عميل على crontab الخاصّ به.
ستّون حاوية عميل على عقدة معدن عارٍ واحدة، لكلّ منها خدمة hoody-cron تعمل. لا مُجدوِل مشترك يُشكّل عنق الزجاجة.
من طلب PUT حتى أوّل نبضة من الجدول الجديد، مُلاحظة عبر أسطول من 60 حاوية على عقدة 64-core نموذجيّة.
حرفيّاً لا يوجد طابور مشترك أو مسار أولويّة أو خيط مُجدوِل يتنافس عليه مستأجران. العزل هو الأساس.
أرقام السعة قيم نموذجيّة مُلاحظة على عقدة معدن عارٍ 64-core / 256GB تعمل بكثافة حاويات Hoody القياسيّة. السعة الفعليّة تتوقّف على ميزانيّات CPU والذاكرة لكلّ مستأجر وعلى ما تفعله كلّ مهمّة cron. الصفر في الطوابير العابرة للمستأجرين بنيويّ، ليس قياساً.
cron عميل لا يستطيع تجويع cron عميل آخر لأنّهما ليسا على نفس crontab.
البِنى التي تشيّدها الفرق لمشاركة crontab واحد بين المستأجرين. Hoody يضع كلّ مستأجر في crontab الخاصّ به — لا موجّه، لا طابور إنصاف، لا جار مزعج.
كفّ عن كتابة tenant_id في كلّ مكان. امنح كلّ عميل حاويته الخاصّة ودع cron يفعل ما يفعله cron دائماً، في عزلة.