مرحبا الزملاء. ننشر اليوم ترجمة للمراجعة التالية من موقع بن نيدل - سيثير هذا الموقع بالتأكيد اهتمامك بالأصل. سنتحدث هذه المرة عن كتاب "
الأنظمة الموزعة. أنماط التصميم " ، والذي يكمل كتاب "
Master Kubernetes " الذي تم نشره في بداية هذا العام ، وهو في جوهره نسخة مماثلة من GoF لتصميم الأنظمة الموزعة.
هل لديك قراءة لطيفة.
خلال عطلة نهاية الأسبوع ، قرأت كتاب النظم الموزعة. أنماط التصميم ، من قبل
بريندان بيرنز . أحببت حقًا الكتاب ، رغم أنني يجب أن أعترف ، كنت أتوقع أن أجد فيه مواد مختلفة قليلاً. لذلك ، في وصف كتاب الحاويات المذكورة فقط في عابرة. في الوقت نفسه ، على الرغم من أن الأنماط الموضحة في الكتاب قابلة للتطبيق ليس فقط على الحاويات ، فإن جميع الأنماط الموضحة هنا تقريبًا ترد في سياق الحاوية ، وبعد ذلك يتم النظر فيها في خط أنابيب نشر Kubernetes. اتضح بالمناسبة. لقد بدأت للتو في التعرف على التطوير والنشر الموجودين في الحاويات ، ومناقشة الأنماط المعمارية من وجهة نظر "الحاوية" هذه كانت بمثابة كشف لي. ساعدني هذا النهج في فهم جيد لكيفية تمييز الخدمات الصغيرة بشكل صحيح في المشهد الجزئي ، ولكل منها فرصة محددة.
مؤلف الكتاب ، بريندان بيرنز ، هو المؤسس المشارك لمشروع مفتوح المصدر Kubernetes. لذلك ، فليس من المستغرب أن يتم بناء جميع أمثلة التطبيقات الخاصة به حول نشر الحاويات بناءً على ملفات تكوين Kubernetes. في وقت قراءة الكتاب ، كنت ضليعًا في Docker ولم أكن أعرف شيئًا عن Kubernetes. وهكذا ، حاولت معرفة "الغرض" من ملفات تكوين Kubernetes بمجرد قراءتها. ومع ذلك ، أعتقد أن الكتاب سيكون أكثر فائدة إذا كان للقارئ بعض الخبرة على الأقل مع Kubernetes.
عند قراءة الكتاب ، لم أتمكن من التخلص من الارتباطات مع عمل "
قوالب التكامل لتطبيقات المؤسسات " للمخرجين Gregor Hope و Bobby Wolf. تشبه العديد من الأنماط التي ناقشها بيرنز أنماط قوائم انتظار الرسائل التي ناقشها هوب وولف. في الواقع ، يجب أن أقول أن العديد من الأنماط يشار إليها في كلا الكتابين بنفس الطريقة (على سبيل المثال ، مبعثر / جمع). هذا منطقي ، نظرًا لأن موضوع كلا الكتابين هو تقسيم الأنظمة المتجانسة المعقدة إلى مجموعة من الخدمات الصغيرة القابلة لإعادة الاستخدام المصممة بإحكام. أعتقد أنه يمكن القول أن بيرنز تحدد مناهج محددة من شأنها أن تكون مفيدة في تنفيذ خدمات المنتجين وخدمات المستهلك التي تشارك في سير مهام العمل القائمة على الرسائل ، وتلك الموصوفة في كتاب "قوالب تكامل تطبيقات المؤسسات".
مرة أخرى ، أعتقد أن أوجه الشبه المتبادلة بين هذين الكتابين تشهد على قوة أنماط التصميم. سواء من حيث أنها تقودنا إلى حلول مجربة ، وفي حقيقة أن أنماط التصميم تسهل الاتصال التقني ، لأنها تتيح لنا التفكير في لغة مشتركة.
في الوقت نفسه ، تم وصف أحد الأساليب التي أعجبتني أكثر في كتاب "الأنظمة الموزعة. ترتبط أنماط التصميم بالتحديد باستهلاك قائمة انتظار الرسائل. ينصح بيرنز بعدم إجبار حاوية العمل على سحب الرسائل مباشرة من النظام (على غرار الطريقة التي يتم بها في نظام خدمة قائمة انتظار Simple (SQS)) من أمازون ، ولكن لإنشاء "سفير" (نمط السفير). سيتم نشر حاوية "السفير" هذه مع حاوية العمل وستوفر واجهة برمجة تطبيقات معممة لمعالجة قوائم الانتظار. يسمح لك الحاوية Ambassador بتجريد تفاصيل التنفيذ المتعلقة بالتخزين الدائم للعناصر في قائمة انتظار الرسائل ، بحيث تكون حاوية العمل مستقلة تمامًا عن أي حلول تكنولوجية محددة.
"سفير حاوية مصدر قائمة انتظار العمل" هو مجرد مثال واحد من موضوع شامل يمتد عبر الكتاب كخيط أحمر: استخدم مجموعات من الحاويات الصغيرة بحيث يمكن لكل حاوية فردية التركيز على مهمة محددة والحصول عليها قابلة لإعادة الاستخدام قدر الإمكان. يستكشف Burns هذا المفهوم على مستوى الحاوية الفردية ، ويتحدث عن تحديد معلمات الحاويات باستخدام وسيطات سطر الأوامر ومتغيرات البيئة. ثم يرتفع مستوى واحد ، ويتحدث عن السيارة الجانبية متعددة الحاويات وأنماط السفراء في سياق عقدة واحدة. أخيرًا ، يوضح كيفية إنشاء بنية خدمات دقيقة باستخدام أنماط متعددة الحاويات.
أعتقد أن بيرنز كان قادرًا على التعبير عن "حلم" المشهد الطبيعي الكامل للخدمات:
يحتوي منهج microservice على العديد من المزايا ، يرتبط الكثير منها بالموثوقية والمرونة. تقسم Microservices التطبيق إلى أجزاء صغيرة ، يكون كل منها مسؤولاً عن تقديم خدمة محددة. من خلال تضييق نطاق الخدمات ، تكون كل خدمة قادرة على تطوير وصيانة فريق يمكن تغذيته ببيتزا.
تقليل حجم الفريق يقلل أيضًا من تكلفة الحفاظ على أنشطته.
بالإضافة إلى ذلك ، فإن ظهور واجهة رسمية بين الخدمات الصغيرة يضعف ترابط الفرق ويؤسس عقدًا موثوقًا بين الخدمات. يقلل هذا العقد الرسمي من الحاجة إلى التزامن الدقيق للفريق ، لأن الفريق الذي يوفر واجهة برمجة التطبيقات يفهم مدى ضرورة ضمان التوافق ، ويمكن للفريق الذي يستهلك واجهة برمجة التطبيقات الاعتماد على خدمة مستقرة دون الحاجة إلى القلق بشأن تفاصيل تنفيذ الخدمة المستهلكة. يسمح مثل هذا التحلل للفرق بالتحكم بشكل مستقل في وتيرة التطوير والجدول الزمني لإصدار إصدارات جديدة ، مما يتيح لهم الفرصة للتكرار ، وبالتالي تحسين رمز الخدمة.
أخيرًا ، يؤدي التقسيم إلى خدمات مجهرية إلى زيادة قابلية التوسع. نظرًا لتخصيص كل مكون لخدمة منفصلة ، يمكن تحجيمه بشكل مستقل عن المكونات الأخرى
(ص. 79-80 في الترجمة الروسية)
أنا أتحدث عن "الحلم" لأنه ، كما يعترف بيرنز نفسه ، من الصعب تصميم نظام خدمة ميكروية وتصميم هندسته المعمارية. ومراقبة وتصحيح مثل هذا النظام أكثر تعقيدًا بكثير من مراقبة وتصحيح تناظرية متجانسة. فقط مع هذا يمكنني أن أتفق بسهولة. وفقًا لخبرتي المحدودة في العمل مع الخدمات المصغرة ، أؤكد أن الخدمات المشتركة سرعان ما أصبحت مرتبطة بشكل كبير ، وأن "العقود الموثوقة" بين الخدمات تتحول بسرعة إلى هدف متحرك ، وتخضع لمزيد من التغييرات الجديدة.
في الختام ، أود أن أتطرق إلى مفهوم FaaS - "وظائف كخدمات". نظم مثل خدمة الامدا لامدا تجعلني أشعر مختلطة. بمعنى تجريدي للغاية ، أحب هذه الأنظمة ، لكن ليس لدي أي فكرة عن كيفية تجسيدها في تطبيق معين. يتطرق بيرنز إلى FaaS في الجزء الثاني حول "أنماط تصميم أنظمة الخدمة" ، لكن لسوء الحظ ، لا يوضح هذا الأمر مشكلة Faas بالكامل بالنسبة لي.
أحببت حقًا أن يوصي Burns باستخدام FaaS لحل مجموعة فرعية فقط من المشكلات المعروفة:
كما هو الحال مع الأدوات الأخرى لتطوير الأنظمة الموزعة ، قد ترغب في استخدام حل معين (على سبيل المثال ، معالجة موجهة للأحداث) كأداة عالمية. والحقيقة هي أن حل معين عادة ما يحل مشاكل معينة. في سياق معين ، سيثبت أنه أداة قوية ، لكن سحبها من الأذنين لحل المشكلات الشائعة يخلق هياكل معقدة وهشة.
(ص. 135 في الترجمة الروسية)
علاوة على ذلك ، شكرا جزيلا له على ذكر الصعوبات التي تنشأ عند استخدام FaaS:
كما ذكرنا في القسم السابق ، فإن تطوير النظام باستخدام نهج FaaS يفرض عليك أن تجعل مكونات النظام متقاربة بشكل فضفاض. كل وظيفة مستقلة بحكم التعريف. كل التفاعل يتم عبر الشبكة. لا تحتوي مثيلات الوظائف على ذاكرة خاصة بها ؛ وبالتالي ، فإنها تتطلب تخزينًا مشتركًا لتخزين الحالة. يمكن أن يؤدي الضعف القسري لتوصيل عناصر النظام إلى زيادة المرونة وسرعة تطوير الخدمة ، ولكن في نفس الوقت يمكن أن يعقد دعمه بشكل كبير.
على وجه الخصوص ، من الصعب جدًا رؤية الهيكل الشامل للخدمة ، وتحديد كيفية دمج الوظائف مع بعضها البعض ، لفهم سبب الخطأ ولماذا حدث في حالة حدوث عطل. بالإضافة إلى ذلك ، فإن طبيعة الوظائف الموجهة نحو الاستعلامات والخوادم لا تعني أن بعض المشكلات سيكون من الصعب اكتشافها.
(ص. 136-137 في الترجمة الروسية)
مرة أخرى ، فوجئت بحقيقة أن معظم أنظمة FaaS ليست جيدة جدًا لحل المهام التي تتطلب معالجة نشطة:
... بالإضافة إلى ذلك ، نظرًا للتنفيذ بدون خادم للخدمات ، يكون وقت تنفيذ مثيل الوظيفة محدودًا في العادة. هذا يعني أن نهج FaaS غير مناسب للتطبيقات التي تتطلب معالجة بيانات خلفية طويلة. (ص 138 في الترجمة الروسية)
أخيرًا ، كنت سعيدًا بالملاحظة القائلة بأن FaaS أصبحت غير مكلفة اقتصاديًا إذا كان من المستحيل ضمان التشغيل الطويل دون انقطاع للمعالج:
ولكن إذا كان لديك العديد من الطلبات التي تعمل الوظيفة باستمرار ، فمن المحتمل أن تدفع مبالغ زائدة عن عدد الطلبات التي تمت معالجتها.
... مع نمو الخدمة ، يزداد عدد الطلبات التي تتم معالجتها إلى مستوى يجعل المعالج مشغولا باستمرار بمعالجتها. في هذه المرحلة ، تصبح رسوم عدد الطلبات غير مربحة. تنخفض تكلفة وحدة وقت وحدة المعالجة المركزية للأجهزة الافتراضية السحابية مع إضافة النوى ، وكذلك عن طريق حجز الموارد والخصومات للاستخدام طويل الأجل. تزداد تكلفة الدفع لعدد الطلبات عادةً مع زيادة عدد الطلبات.
(ص 139-140 في الترجمة الروسية)
نتيجة لذلك ، ما زلت لم أفهم: متى من الأفضل استخدام "وظائف كخدمات"؟ لاحظ أن Burns يصف باختصار العمل مع المهام قصيرة الأجل الموجهة نحو الأحداث والتي لا تقوم بتحميل المعالج كثيرًا ، مثل المصادقة ثنائية العامل (2FA). ومع ذلك ، بالنظر إلى أننا نتحدث عن مهام قصيرة الأجل صغيرة بتكاليف منخفضة ، فإن السؤال الذي يطرح نفسه هو: لماذا يجب أن يتم تحجيمها بشكل مستقل؟ لماذا لا تدرج هذه الميزات في خدمة حاويات أخرى ترتبط ارتباطًا وثيقًا بالخدمة الأولى؟
آمل أن أتعامل بشكل أفضل مع هذه المشكلات عندما أحصل على استخدام تقنيات FaaS في الممارسة العملية.
بصرف النظر عن بعض الالتباس مع FaaS ، أحببت الكتاب حقًا. يتم قراءتها بسرعة ، ينظر بسهولة. يذكرنا مرة أخرى بالإمكانات الهائلة المتمثلة في إضعاف العلاقة بين المكونات على جميع مستويات تطوير التطبيقات. أخيرًا ، سيكون الآن من الأسهل بالنسبة لي متابعة محادثة مع زملائي حول مواضيع مثل "حاويات Sidecar".