تم إعداد ترجمة لهذه المادة لطلاب دورة ممارسات وأدوات DevOps في مشروع OTUS التعليمي.
عندما بدأت البرامج التعليمية الأولى في استخدام AWS Lambda و Gateway API في عام 2015 ، لم يكن مفاجئًا أن يركزوا بشكل أساسي على نسخ بنية الخدمات المصغرة. ولكن بالنسبة لأولئك الذين استخدموا AWS Lambda على نطاق واسع ، فقد أصبح من الواضح مع مرور الوقت أن هناك قيودًا كبيرة على تطبيق نهج microservice على AWS Lambda ... على الأقل كانت هناك قيود على ما يعنيه معظم الناس عن طريق البناء الصحيح للخدمات الدقيقة.
دعونا نتحدث عن السبب وراء الخدمات المجهرية
ظهرت Microservices في المقام الأول بسبب الإحباط مع التطبيقات متجانسة. Monolith هو تطبيق يكون فيه كل المنطق في قاعدة شفرة منطقية واحدة.
كانت هناك أوقات ، بسبب ارتفاع تكلفة الخوادم ، كان من الشائع نشر التطبيق بالكامل على خادم واحد. يعني نشر متراصة أنك تقوم بنشر جزء من التطبيق أو جزء منه على الخادم.
وأيضًا ، نشر متراصة يعني أنه يجب عليك التأكد من أنك لن تكسر أي شيء. في كثير من الأحيان ، تؤدي التغييرات الصغيرة إلى فشل الخادم بأكمله والتطبيق بأكمله.
لذلك ، عندما ظهرت السحب مع إمكانية تزويد الحالات بنقرة واحدة في غضون دقائق (بدلاً من أيام أو أسابيع) ، أصبحت إمكانية الفصل بين المهام واضحة.
أصبح تدمير المتراصة فكرة واضحة ، ولدت فكرة الخدمات المجهرية.
بدلاً من إنشاء متراصة مع كل المنطق على خادم / مثيل واحد ، يمكنك وضع أجزاء من التطبيق على خوادم مختلفة وتوصيلها معًا باستخدام نوع من بروتوكول خفيف الوزن - عادةً HTTP API.
وبالتالي ، انتقلت بنية التطبيق من متراصة إلى الخدمات الصغيرة.
رغم ذلك ، أتساءل لماذا؟ إن قيمة هذا الأسلوب هي أنه عند تحرير الكود ، تقوم بتغيير قاعدة الكود الخاصة بالتطبيق ليس بالكامل ، ولكن الخدمة الميكروية - فقط جزء المكون من التطبيق. هذا يعني أنه لا يمكنك كسر التطبيق بأكمله.
على الرغم من أن هذا نظريًا فقط ، إلا أن هذه النظرية أفضل من المتراصة ، رغم أنها ليست مثالية.
عنصر أساسي لكل خدمة هو ...
واجهة الخدمة
هذا غالبًا شكل من أشكال واجهة HTTP (على الأقل هذا هو الأسلوب الأكثر شيوعًا). كقاعدة عامة ، هذه ليست مشكلة ، إلا عندما يكون لديك عدد كبير من الخدمات وقد تكون هناك مشكلة في التنسيق.
التحرك نحو الهندسة المعمارية serverless
لذلك ، كان النهج الأولي لبناء تطبيقات بدون خادم على AWS هو "دعنا ننشئ خدمات ميكروية" ...
هذا يعني إنشاء واجهة برمجة تطبيقات عبّارة مع وظيفة Lambda وراءها وبيان تبديل يعمل كموجه.
أصبح كل بوابة API واجهة خدمة ، وبدا ذلك منطقيا.
يمكنك تقديم العديد من الخدمات التي تتدرج بشكل منفصل عن بعضها البعض ، والتي في بعض الحالات قد تكون مهمة للغاية.
إلا أنه لا معنى عندما تدرك أن وظيفتي AWS Lambda و FaaS بشكل عام لا ينبغي اعتبارهما مثيلًا / خادمًا.
لأنه على الرغم من وجود خوادم تحت الغطاء (مهلا ، هناك خوادم تحت معظم الأشياء التي تعمل على الإنترنت ، ولكن لا أحد يقول "لا يزال S3 خوادم" أو "BigTable لا يزال لديه خوادم" أو "Azure Active Directory all لا يزال لديه خوادم "...) ، هناك رأي مفاده أنه يجب عليك التعامل مع وظيفة FaaS مثل الخدمة ..." minilith "، كما يسميها البعض.
المشكلة هي أن هنا يفتقد ما هو ، في رأيي ، مفتاح هندسة بدون خادم:
العمارة بدون خادم تدور حول الأحداث
Serverless الهندسة المعمارية ، والأحداث ، والمشغلات
تعد أنظمة Serverless أنظمة بطبيعتها تستند إلى الحدث ، وبالتالي فهي تمثل بنية تستند إلى الحدث. يغير نهجك في التصميم والإدارة والهندسة المعمارية.
في حالة الخدمات المصغرة ، فإن الخلاصة هي الاستجابة لواجهة - هذه هي الآلية الرئيسية للتفاعل مع المنطق.
الحل بدون خادم يتعلق بالرد على الأحداث ، و API هي في الواقع مجرد آلية لإنشاء الأحداث.
كجزء من نظام AWS البيئي ، الذي يعد أكثر الحلول نضجا للخوادم ، لا يُنظر إلى واجهة برمجة التطبيقات على أنها الواجهة الأساسية. الأحداث أكثر أهمية بكثير.
وهذا هو السبب في وجود حوالي 50 حدثًا يمكنها تشغيل وظيفة Lambda من خدمات AWS الأخرى.
نصيحة هي أنه إذا كنت تستطيع تشغيل وظيفة Lambda دون المرور عبر واجهة برمجة تطبيقات Gateway ، فستكون أسرع بكثير وأكثر كفاءة من استخدام Gateway API ، خاصة إذا قمت بتشغيلها من واجهة AWS أخرى.
ألق نظرة على أفضل ممارسات Serverless ، سترى عددًا من النقاط التي تختلف عن عدد خدمات التصميم المصغرة.
بادئ ذي بدء ، وظائف أحادية الاتجاه. تستخدم معظم الخدمات المصغرة عادةً بنية استجابة - استجابة لأن معظم تطبيقات الويب تعمل بهذه الطريقة. وظائف في تطبيق بدون خادم ، كقاعدة عامة ، هي أحادية الاتجاه ، ويتم استخدام قوائم الانتظار كـ "قاطع الدائرة" ، لذلك يصبح استجابة الطلب أقل شيوعًا.
تتم إدارة طبقة البيانات أيضًا وفهمها بطرق مختلفة. أفضل ممارسة هي الحصول على وظائف متعددة ، بدلاً من وظيفة وكيل واحدة مع عبارة تبديل.
توفر فكرة الوظائف المتعددة أيضًا مزايا إضافية على الخدمات المصغرة. إذا ألغيت دالة خطأً ، فسيؤثر ذلك على هذه الوظيفة فقط ، وليس على بقية التطبيق ، لأن الوظيفة ليس لها حالة (على الأقل ينبغي أن تكون!). وهذا هو سبب وجيه للغاية لعدم القيام "minilith"!
لذلك ، على الرغم من أن تجربة بناء الخدمات المصغرة تمنحك بعض المزايا عند تصميم حلول بدون خادم ، إلا أنه في الواقع يمكنك أن تفوت معظم ما يجعل التطبيقات الخالية من الخوادم ذات قيمة.
تختلف خدمات Microservices عادةً عن تطبيق بدون خوادم مصمم جيدًا بعدة طرق. هذا يعني أنه على الرغم من أنه من الممكن إنشاء خدمات micros بواجهة خلفية بدون خادم ، في الواقع لا يوجد مسار مباشر من الخدمات الصغيرة إلى بنية بدون خادم.
الطريق من الخدمات الصغيرة إلى الهندسة المعمارية دون خادم
لذلك ، ما هو المسار من الخدمات الصغيرة إلى حلول بدون خادم؟ هل هناك طريقة سريعة لتعلم الأساسيات لتبسيط الانتقال من واحدة إلى أخرى ، نظرًا لأن الخدمات المجهرية واسعة الانتشار؟
أعتقد أن هذا ما يحير به العالم بدون خادم. في الآونة الأخيرة ، كان هناك نقاش كبير على تويتر تحدثنا فيه عن هذا الموضوع. تجدر الإشارة هنا إلى ذلك ، لمعرفة فقط ما الذي يتحدث عنه المجتمع (انظر إلى الإجابات المتنوعة وستشاهد العديد من الآراء حول هذا الموضوع ، على الرغم من أن لا أحد يذكر مباشرة الخدمات المجهرية).
يتحدثون عن بعض الأدوات التي سيتم إخبارها لتسهيل إنشاء تطبيقات بدون خادم ، ولكن في النهاية سوف يصبحون المنصة التي يجب أن تبني عليها كل شيء. لا أعتقد أنه سيفيد أو يساعد شخصًا ما على فهم الأسلوب المعماري بشكل أفضل.
كمجتمع ، نحن نفهم أن الهندسة المعمارية بدون خادم هي المستقبل. لكن الانتقال من الأنماط المعمارية القديمة لن يكون دائمًا أمرًا سهلاً ، حتى عندما تكون البنية الخالية من الخوادم هي الاختيار الصحيح (وأحيانًا لا يكون هو الخيار الصحيح).
هناك سبب لذلك. ليس من السهل تغيير تفكير الشخص. من السهل بناء وظيفة Lambda. لكن إنشاء تطبيق serverless مصمم بشكل جيد ليس بالأمر السهل. لأنه يتطلب تغييرًا في التفكير ، وهو صعب نسبيًا.
وكما قلت عدة مرات ، يجب أن نتوقف عن تعليم الناس "مرحباً العالم" والتوقف عند هذا لأن الكثير من الناس يعتقدون أن هذا سيكون كافياً لهم.
كان السبب وراء كتابتي أفضل ممارسات Serverless هو مساعدة الناس على فهم أنه لا ينبغي عليهم وضع افتراضات حول كيفية إنشاء تطبيقات بدون خادم بناءً على المعرفة الحالية.
الأدوات التي نستخدمها الآن لإنشاء حلول بدون خادم هي نفس الأدوات التي نستخدمها لإنشاء تطبيقات "cloud 1.0" ، لكنها ليست مناسبة تمامًا لهذه الأغراض. هذه الأدوات غير كاملة ، لكننا نحاول شرحها وجعلها جيدة قدر الإمكان.
ماذا نحتاج منك
أعتقد أن المجتمع ، في الواقع ، منفتح جدًا لمساعدة الأشخاص في التدريب والتطوير في إنشاء حلول بدون خادم.
لذلك نحن كمجتمع نحتاج إلى أسئلتك:
- ما هي الصعوبات الخاصة بك؟
- أين هي الثغرات؟
- ما هي الدروس المفقودة؟
وشيء من هذا القبيل.
أنا مستعد لمساعدة الشركات على إجراء هذا الانتقال. لقد عملت مع الإدارة العليا والمديرين التنفيذيين والمديرين التنفيذيين للمساعدة في تحديد القيمة التي تخلقها الشركة باستخدام نهج بدون خادم ، ويسعدني مساعدة الشركات الأخرى.
أنا سعيد جدا للمساعدة. الاتصال ينكدين هنا .