مقدمة
عند الحديث عن Serverless (الحوسبة بدون خادم)، فإن Kubernetes موضوع لا يمكن تجنبه.
في درس اليوم، سنواصل تعلم كيفية إعداد بيئة Serverless خاصة. تحديدًا، سنبني البنية التحتية لـ Serverless استنادًا إلى نشر K8s المحلي من الدرس السابق. ثم سنقوم بتثبيت مكونات إضافية لتوسيع قدرات مجموعة K8s، مما يتيح في النهاية للمجموعة المحلية دعم Serverless.
المتطلبات الأساسية لبناء Serverless
قبل أن نبدأ، دعنا نوضح سؤالًا أثير خلال الدورة التمهيدية حول الحوسبة بدون خادم، وخاصة FaaS. سأل بعض الطلاب: “ما العلاقة بين الخدمات المصغرة (Microservices) و Service Mesh و Serverless؟”
تظهر هذه المفاهيم بشكل متكرر في النقاشات، لكن لا تشعر بالضغط. لقد كنت أيضًا مرتبكًا بهذه المفاهيم عندما بدأت تعلم Serverless لأول مرة. دعنا نعود أولاً إلى الخدمات المصغرة. عند استخدام الخدمات المصغرة لإنشاء BaaS، قد تلاحظ أن العديد من مفاهيم الخدمات المصغرة تشبه إلى حد كبير تلك الموجودة في Serverless.
ببساطة، Service Mesh هو حل اتصال شبكي للخدمات المصغرة يعمل دون أن تكون الخدمات المصغرة نفسها على دراية به. يمكننا أيضًا تفويض الاتصال الشبكي في بنية Serverless إلى Service Mesh. من خلال Service Mesh، يمكن لمكونات Serverless العمل بشكل وثيق مع مجموعة K8s، مما يدعم في النهاية تطبيقاتنا المنشورة بطريقة Serverless. دعنا نلقي نظرة على مخطط البنية التالي:
من المخطط، يمكننا أن نرى بوضوح أن البنية التحتية الأساسية لـ Serverless يمكن بناؤها على Service Mesh. ومع ذلك، فإن Service Mesh هو مجرد أحد الحلول لتنفيذ الاتصال الشبكي لـ Serverless. هناك خيارات أخرى مثل RSocket و gRPC و Dubbo. اخترت Service Mesh لأن هذا الحل يمكن أن يعتمد على مكونات K8s ويوفر أدوات تصور تساعدنا على فهم آلية عمل Serverless، مثل كيفية تحقيق وقت بدء تشغيل صفري والتحكم في حركة المرور للإصدارات التدريجية. إذا كنت ترغب في الممارسة، فإن Service Mesh بلا شك هو الخيار الأول.
البنية التحتية لـ Serverless: Service Mesh
يطلق البعض على تقنيات Kubernetes و Service Mesh و Serverless اسم “الأعمدة الثلاثة” لتطوير التطبيقات السحابية الأصلية. بحلول الآن، أفترض أنك تفهم السبب وراء ذلك. ومع ذلك، يجب أن أوضح أنه في الدروس التالية، سنقدم العديد من المصطلحات الجديدة. لقد أعطيتك نظرة عامة على هذه المصطلحات حتى تتمكن من الحصول على فهم واسع. إذا كان لديك وقت، يجب أن تتعمق فيها.
الآن، دعنا نعود إلى الموضوع الرئيسي ونلقي نظرة فاحصة على مبادئ Service Mesh.
عندما ناقشنا الخدمات المصغرة، قمنا فقط بتغطية الإرشادات النظرية حول التحليل والتكامل، دون التطرق إلى التنفيذ المحدد. إذا انتقلنا إلى التنفيذ، فإن الصناعة لديها بالفعل العديد من أطر الخدمات المصغرة، ولكن معظمها يقتصر على SDKs بلغات محددة، وخاصة أطر Java للخدمات المصغرة.
إطار الخدمات المصغرة في شكل SDK عادة ما يكون له تركيز كبير على تنفيذ الاتصال الشبكي بين الخدمات المصغرة، مثل إعادة محاولة طلبات الخدمة الفاشلة، وتوزيع الحمل عبر مثيلات خدمة متعددة، وتحديد حركة المرور أثناء أحجام طلبات الخدمة العالية. غالبًا ما يتطلب هذا المنطق اهتمام مطوري الخدمات المصغرة ويحتاج إلى تنفيذه بشكل متكرر في كل لغة SDK. لذا، هل من الممكن استخراج منطق الاتصال الشبكي للخدمات المصغرة من SDK، مما يجعل خدماتنا المصغرة أخف وزناً وحتى يلغي الحاجة إلى القلق بشأن الاتصال الشبكي؟
الإجابة هي Service Mesh.
إذا قمنا بنشر التطبيقات المفككة إلى Pods في مجموعة K8s، فإن العملية كما هو موضح في الرسم البياني أدناه، حيث سيقوم تطبيق MyApp باستدعاء الخدمة المصغرة للمستخدم والخدمة المصغرة للمهام مباشرة داخل المجموعة عبر HTTP.
ولكن ماذا عن مشكلات الأمان التي تنشأ من الوصول المباشر عبر HTTP؟ إذا قام شخص بتشغيل حاوية BusyBox في مجموعتنا، ألن يتمكن من مهاجمة الخدمة المصغرة للمستخدم والخدمة المصغرة للمهام مباشرة؟ أيضًا، عندما يكون لدينا مثيلات متعددة للخدمة المصغرة للمستخدم، كيف نوزع حركة المرور؟
تقليديًا، كنا نستخدم SDK لبنية الخدمات المصغرة، والذي يحتوي على الكثير من هذا المنطق والعديد من الاستراتيجيات التي نحتاج إلى تحديد موعد تنشيطها عند استدعاء SDK. سيكون كودنا أيضًا مرتبطًا بشدة بـ SDK بنية الخدمات المصغرة.
ومع ذلك، يتبع Service Mesh نهجًا مختلفًا عن طريق استخراج منطق الاتصال الشبكي من الخدمة المصغرة وإدارة حركة المرور الشبكية بطريقة غير تدخلية، مما يسمح لنا بعدم القلق بعد الآن بشأن SDK الثقيل للخدمات المصغرة. دعنا نرى كيف يحل Service Mesh هذه المشكلة.
يمكن تقسيم Service Mesh إلى مستوى بيانات ومستوى تحكم. مستوى البيانات مسؤول عن إدارة الاتصال الشبكي، بينما يتحكم مستوى التحكم ويراقب حالة الاتصال الشبكي. يعترض Service Mesh جميع حركة المرور الشبكية عن طريق حقن Sidecar.
في مستوى البيانات، تبدو تطبيقاتنا وخدماتنا المصغرة وكأنها تتواصل مباشرة مع Sidecar، ولكن في الواقع، يمكن لـ Sidecar تحقيق ذلك من خلال اختطاف حركة المرور. لذلك، عادة ما تكون تطبيقاتنا وخدماتنا المصغرة غير مدركة لذلك ولا تتطلب أي تعديل، فقط استخدام طلبات HTTP لنقل البيانات.
يكون مستوى التحكم أكثر تعقيدًا وهو جوهر عمليات Service Mesh. Pilot هو محرك مستوى التحكم بأكمله، المسؤول عن اكتشاف الخدمة وإدارة حركة المرور والتوسع. Citadel هي قلعة الحماية لمستوى التحكم، المسؤولة عن شهادات الأمان والمصادقة. Mixer هو ضابط الاتصالات، يوزع سياسات مستوى التحكم ويجمع حالة تشغيل كل خدمة.
الآن يجب أن يكون لديك فهم واضح لماهية Service Mesh، وكيف يستخرج منطق الاتصال الشبكي للخدمات المصغرة من SDK، ولماذا نقول إن Service Mesh هو أساس الاتصال الشبكي لـ Serverless.
العلاقة بين Serverless ومحركات الحاويات
القيمة الأساسية لـ Serverless تكمن في عدم الحاجة إلى إدارة الخوادم، مما يسمح بالتركيز على منطق الأعمال. توفر تقنية الحاويات البنية التحتية القوية والقدرات المرنة للجدولة اللازمة لـ Serverless، خاصة عند دمجها مع أدوات التنسيق مثل Kubernetes.
توفر الحاويات مزايا مثل التغليف الخفيف وعزل الموارد والبدء السريع. تقوم الحاويات بتغليف التطبيقات وتبعياتها، مما يضمن اتساق بيئة التشغيل، مما يسهل النشر السريع وبدء تشغيل مثيلات التطبيق على منصة Serverless. بالإضافة إلى ذلك، توفر الحاويات بيئات تشغيل معزولة، مما يضمن عدم تداخل التطبيقات المختلفة مع بعضها البعض، وبالتالي تحسين الاستقرار العام للمنصة. علاوة على ذلك، فإن بدء تشغيل الحاوية أسرع من بدء تشغيل الأجهزة الافتراضية، مما يلبي المتطلبات العالية لتطبيقات Serverless للتوسع المرن.
باعتبار Kubernetes جوهر جدولة Serverless، فإن له وظائف مثل النشر الآلي والتوسع المرن واكتشاف الخدمة. يمكنه نشر التطبيقات المعبأة في حاويات تلقائيًا بناءً على قواعد محددة مسبقًا دون تدخل يدوي، وضبط عدد مثيلات التطبيق وفقًا للحمل الفوري، مما يضمن الأداء مع تحسين استخدام الموارد، وتوفير آليات اكتشاف الخدمة لتسهيل الاتصال بين المكونات داخل منصة Serverless.
لبناء منصة Serverless قائمة على الحاويات، أولاً، تحتاج إلى حزم التطبيقات وتبعياتها في صور حاويات، مما يضمن إمكانية نشر التطبيقات وتشغيلها بسرعة على المنصة. ثم، اختر منصة سحابية مناسبة أو قم بإعداد مجموعة Kubernetes ذاتية الاستضافة كبنية تحتية لمنصة Serverless. بعد ذلك، قم بتطوير مكونات منصة Serverless، بما في ذلك بوابة API لاستقبال وتوجيه الطلبات الخارجية، وبيئة تشغيل الوظائف لتحميل وتشغيل كود الوظيفة وإدارة دورة حياة الوظيفة، ومشغلات الأحداث التي تستمع إلى مصادر الأحداث المختلفة وتحول الأحداث إلى استدعاءات وظائف. أخيرًا، استخدم Deployment في Kubernetes لإدارة نشر وتحديث مثيلات التطبيق، واستخدم Service لاكتشاف الخدمة وتوزيع الحمل، واستخدم HPA لتحقيق التوسع المرن التلقائي.
تقدم منصة Serverless القائمة على الحاويات مرونة عالية وقدرة تخصيص قوية وفعالية من حيث التكلفة. يمكن للمطورين اختيار تقنية الحاويات الأساسية ومنصة Kubernetes بحرية، وتخصيص وظائف وميزات منصة Serverless وفقًا لاحتياجاتهم، واستخدام قدرات جدولة الموارد في Kubernetes لتحسين استخدام الموارد وتقليل التكاليف.
يوفر الجمع بين تقنية الحاويات و Kubernetes أدوات وطرقًا قوية لبناء منصات Serverless فعالة ومرنة وقابلة للتوسع، مما يتيح للمطورين بناء منصات Serverless الخاصة بهم بسهولة، والتركيز على تطوير منطق الأعمال، وتحسين كفاءة التطوير.
Novita AI Serverless
في Novita AI، قمنا بتطوير محرك الحاويات الخاص بنا، Nexus. بالاستفادة من قدرات Nexus القوية في الحوسبة الموزعة وجدولة الموارد، بنت Novita AI خدمة Serverless موجهة نحو الجيل التالي من الذكاء الاصطناعي التوليدي. يحتاج المستخدمون فقط إلى التركيز على ابتكار الأعمال دون القلق بشأن موارد الحوسبة الأساسية. الحجوزات مفتوحة الآن؛ انضم إلى قائمة الانتظار لتكون أول من يجرب Novita AI Serverless.
Novita AI هي المنصة السحابية الشاملة التي تمكن طموحاتك في الذكاء الاصطناعي. واجهات برمجة تطبيقات متكاملة، Serverless، مثيل GPU — الأدوات الفعالة من حيث التكلفة التي تحتاجها. تخلص من البنية التحتية، ابدأ مجانًا، وحقق رؤيتك في الذكاء الاصطناعي.
قراءة موصى بها
التوسع عند الطلب: كيف يتعامل Serverless مع قمم حركة المرور بسهولة
