يتحدث جوش إيفانز عن العالم الفوضوي والملون لخدمات Netflix الصغيرة، بدءًا من الأساسيات ذاتها - تشريح الخدمات الصغيرة، والتحديات المرتبطة بالأنظمة الموزعة، وفوائدها. وبناءً على هذا الأساس، يستكشف الممارسات الثقافية والمعمارية والتشغيلية التي تؤدي إلى إتقان الخدمات الصغيرة.
على عكس الانجراف التشغيلي، يعد إدخال لغات جديدة لتدويل الخدمة والتقنيات الجديدة مثل الحاويات قرارات واعية لإضافة تعقيد جديد إلى البيئة. قام فريق العمليات الخاص بي بتوحيد معايير أفضل خريطة طريق تقنية لـ Netflix، والتي تم دمجها في أفضل الممارسات المحددة مسبقًا استنادًا إلى Java وEC2، ولكن مع نمو الأعمال، بدأ المطورون في إضافة مكونات جديدة مثل Python وRuby وNode-JS وDocker.
أنا فخور جدًا بأننا كنا أول من دافع عن منتجنا ليعمل بشكل رائع دون انتظار شكاوى العملاء. بدأ كل شيء بسيطًا بما فيه الكفاية - كان لدينا برامج تشغيل في Python وعدد قليل من تطبيقات المكتب الخلفي في Ruby، ولكن الأمور أصبحت أكثر إثارة للاهتمام عندما أعلن مطورو الويب لدينا أنهم سيتخلصون من JVM وسيقومون بنقل الويب تطبيق على منصة برنامج Node.js. بعد تقديم Docker، أصبحت الأمور أكثر تعقيدًا. لقد اتبعنا المنطق وأصبحت التقنيات التي توصلنا إليها حقيقة عندما قمنا بتنفيذها للعملاء لأنها كانت منطقية للغاية. سأخبرك لماذا يحدث هذا.
تمتلك API Gateway في الواقع القدرة على دمج البرامج النصية الرائعة التي يمكن أن تكون بمثابة نقاط نهاية لمطوري واجهة المستخدم. لقد قاموا بتحويل كل من هذه البرامج النصية بطريقة تمكنهم بعد إجراء التغييرات من نشرها إلى الإنتاج ثم إلى أجهزة المستخدم، وتمت مزامنة كل هذه التغييرات مع نقاط النهاية التي تم تشغيلها في بوابة API.
ومع ذلك، فقد كرر هذا مشكلة إنشاء وحدة متراصة جديدة حيث تم تحميل خدمة واجهة برمجة التطبيقات (API) بشكل زائد بالكود بطريقة أدت إلى حدوث سيناريوهات فشل مختلفة. على سبيل المثال، تمت إزالة بعض نقاط النهاية، أو تم إنشاء البرامج النصية بشكل عشوائي للعديد من إصدارات شيء ما بحيث استهلكت الإصدارات كل الذاكرة المتوفرة لخدمة واجهة برمجة التطبيقات.
كان من المنطقي أخذ نقاط النهاية هذه وسحبها من خدمة API. للقيام بذلك، قمنا بإنشاء مكونات Node.js التي تعمل كتطبيقات صغيرة في حاويات Docker. هذا سمح لنا بعزل أي مشاكل وأعطال ناجمة عن تطبيقات العقدة هذه.
تكلفة هذه التغييرات كبيرة جدًا وتتكون من العوامل التالية:
- أدوات الإنتاجية. تتطلب إدارة التقنيات الجديدة أدوات جديدة لأن فريق واجهة المستخدم، الذي يستخدم نصوصًا برمجية جيدة جدًا لإنشاء نموذج فعال، لم يضطر إلى قضاء الكثير من الوقت في إدارة البنية التحتية، وكان عليهم فقط كتابة النصوص البرمجية والتحقق من وظائفها.
رؤية الفرص وفرزها - من الأمثلة الرئيسية على ذلك الأدوات الجديدة اللازمة للكشف عن معلومات برنامج تشغيل الأداء. وكان من الضروري معرفة مقدار انشغال المعالج، وكيفية استخدام الذاكرة، وجمع هذه المعلومات يتطلب أدوات مختلفة. - تجزئة الصور الأساسية - أصبحت AMI الأساسية البسيطة أكثر تجزئة وتخصصًا.
- إدارة العقدة. لا تتوفر بنية أو تقنية جاهزة تسمح لك بإدارة العقد في السحابة، لذلك قمنا ببناء Titus، وهو نظام أساسي لإدارة الحاويات يوفر نشرًا موثوقًا وقابلاً للتطوير للحاويات وتكاملًا سحابيًا مع Amazon AWS.
- ازدواجية مكتبة أو منصة. يتطلب توفير تقنيات جديدة بنفس الوظائف الأساسية للنظام الأساسي تكرارها في أدوات مطور Node.js المستندة إلى السحابة.
- منحنى التعلم والخبرة الصناعية. إن إدخال تقنيات جديدة يؤدي حتماً إلى خلق تحديات جديدة يجب التغلب عليها والتعلم منها.
وبالتالي، لم يكن بوسعنا أن نقتصر على "طريق مرصوف" واحد، وكان علينا أن نبني باستمرار طرقًا جديدة لتطوير تقنياتنا. لخفض التكاليف، قمنا بتقييد الدعم المركزي وركزنا على JVM والعقد الجديدة وDocker. لقد أعطينا الأولوية للتأثير الفعال، وأبلغنا الفرق بتكلفة قراراتهم، وشجعناهم على البحث عن طرق لإعادة استخدام الحلول عالية التأثير التي قاموا بتطويرها بالفعل. لقد استخدمنا هذا النهج عند ترجمة الخدمة إلى اللغات الأجنبية لتسليم المنتج للعملاء الدوليين. تتضمن الأمثلة مكتبات عملاء بسيطة نسبيًا يمكن إنشاؤها تلقائيًا، بحيث يكون من السهل جدًا إنشاء إصدار Python، وإصدار Ruby، وإصدار Java، وما إلى ذلك.
كنا نبحث باستمرار عن فرص لاستخدام التقنيات التي أثبتت جدواها والتي أثبتت فعاليتها في مكان واحد وفي مواقف أخرى مماثلة.
دعونا نتحدث عن العنصر الأخير - التغييرات، أو الاختلافات. انظر كيف يختلف استهلاك منتجنا بشكل غير متساوٍ حسب يوم الأسبوع والساعة طوال اليوم. يمكنك القول أن الساعة 9 صباحًا هي أصعب الأوقات بالنسبة لـ Netflix، عندما يصل الحمل على النظام إلى الحد الأقصى.
كيف يمكننا تحقيق سرعة عالية في تنفيذ الابتكارات البرمجية، أي إجراء تغييرات جديدة على النظام باستمرار، دون التسبب في انقطاع تقديم الخدمة ودون خلق أي إزعاج لعملائنا؟ حققت Netflix ذلك من خلال استخدام Spinnaker، وهي منصة عالمية جديدة للإدارة السحابية والتسليم المستمر (CD).
والأهم من ذلك، أن Spinnaker تم تصميمه لدمج أفضل الممارسات لدينا بحيث يمكننا، عند نشر المكونات في الإنتاج، دمج المخرجات مباشرةً في تقنية توصيل الوسائط الخاصة بنا.
لقد تمكنا من دمج تقنيتين في خط أنابيب التسليم لدينا ونقدرهما بشدة: تحليل الكناري الآلي والنشر المرحلي. يعني تحليل Canary أننا نقوم بتوجيه عدد قليل من حركة المرور إلى الإصدار الجديد من الكود، وتمرير بقية حركة الإنتاج من خلال الإصدار القديم. ثم نتحقق من كيفية تعامل الكود الجديد مع المهمة - أفضل أو أسوأ من الكود الحالي.
يعني الطرح المتدرج أنه إذا واجه الطرح في منطقة ما مشكلات، فإننا ننتقل إلى الطرح في منطقة أخرى. في هذه الحالة، يجب تضمين قائمة المراجعة المذكورة أعلاه في خط أنابيب الإنتاج. سأوفر عليك بعض الوقت وأوصيك بمراجعة حديثي السابق، "هندسة عمليات Netflix العالمية في السحابة"، إذا كنت مهتمًا بالتعمق أكثر في هذا الموضوع. يمكن مشاهدة تسجيل الفيديو للخطاب باتباع الرابط الموجود أسفل الشريحة.
وفي نهاية الحديث سأتحدث بإيجاز عن تنظيم وهندسة Netflix. في البداية كان لدينا مخطط يسمى التسليم الإلكتروني، والذي كان الإصدار الأول من دفق الوسائط NRDP 1.x. يمكن استخدام مصطلح "backstream" هنا لأنه في البداية لا يمكن للمستخدم تنزيل المحتوى إلا لتشغيله لاحقًا على الجهاز. بدت أول منصة تسليم رقمية لـ Netflix، في عام 2009، شيئًا كهذا.
يحتوي جهاز المستخدم على تطبيق Netflix، والذي يتكون من واجهة مستخدم ووحدات أمان وتنشيط الخدمة وتشغيلها، استنادًا إلى منصة NRDP - منصة Netflix Ready Device Platform.
في ذلك الوقت كانت واجهة المستخدم بسيطة للغاية. كان يحتوي على ما يسمى بـ Queque Reader، وكان المستخدم يذهب إلى الموقع لإضافة شيء ما إلى Queque ومن ثم عرض المحتوى المضاف على أجهزته. كان الأمر الإيجابي هو أن فريق الواجهة الأمامية وفريق الواجهة الخلفية ينتميان إلى نفس منظمة التسليم الإلكتروني وكانت بينهما علاقة عمل وثيقة. تم إنشاء الحمولة بناءً على XML. وفي الوقت نفسه، تم إنشاء Netflix API لأعمال أقراص DVD، مما شجع تطبيقات الطرف الثالث على توجيه حركة المرور إلى خدمتنا.
ومع ذلك، كانت واجهة برمجة تطبيقات Netflix مُجهزة جيدًا لمساعدتنا من خلال واجهة مستخدم مبتكرة، تحتوي على بيانات وصفية لكل المحتوى، ومعلومات حول الأفلام المتوفرة، مما أدى إلى إنشاء القدرة على إنشاء قوائم المشاهدة. كان لديه واجهة برمجة تطبيقات REST عامة تعتمد على مخطط JSON، ورمز استجابة HTTP، وهو نفس الكود المستخدم في الهندسة المعمارية الحديثة، ونموذج أمان OAuth، وهو ما كان مطلوبًا في ذلك الوقت لتطبيق الواجهة الأمامية. وقد جعل هذا من الممكن الانتقال من النموذج العام لتسليم المحتوى المتدفق إلى النموذج الخاص.
كانت مشكلة النقل هي التجزئة، حيث يقوم نظامنا الآن بتشغيل خدمتين بناءً على مبادئ تشغيل مختلفة تمامًا - واحدة على Rest وJSON وOAuth، والأخرى على RPC وXML وآلية أمان المستخدم القائمة على نظام الرمز المميز NTBA. وكانت هذه أول بنية هجينة.
كان هناك في الأساس جدار حماية بين فريقينا لأن واجهة برمجة التطبيقات (API) في البداية لم تتوسع بشكل جيد مع NCCP مما أدى إلى احتكاك بين الفريقين. كانت الاختلافات في الخدمات والبروتوكولات والدوائر ووحدات الأمان، وكان على المطورين في كثير من الأحيان التبديل بين سياقات مختلفة تمامًا.
وفي هذا الصدد، أجريت حواراً مع أحد كبار المهندسين في الشركة، ووجهت إليه سؤالاً: "ما هي البنية المناسبة على المدى الطويل؟"، فطرح السؤال المضاد: "ربما تكون أكثر قلقاً". حول العواقب التنظيمية - ماذا يحدث إذا قمنا بدمج هذه الأشياء، وكسرت ما تعلمنا القيام به بشكل جيد؟ يرتبط هذا النهج ارتباطًا وثيقًا بقانون كونواي: "المنظمات التي تصمم الأنظمة مقيدة بتصميم يكرر بنية الاتصال لتلك المنظمة". هذا تعريف مجرد للغاية، لذا أفضّل تعريفًا أكثر تحديدًا: "أي جزء من البرنامج يعكس الهيكل التنظيمي الذي أنشأه". هذا هو الاقتباس المفضل لدي من إريك ريموند: "إذا كان لديك أربعة فرق من المطورين تعمل على مترجم، فسوف ينتهي بك الأمر مع مترجم رباعي التمرير." حسنًا، لدى Netflix مترجم رباعي التمريرات، وهذه هي الطريقة التي نعمل بها.
يمكننا القول أنه في هذه الحالة يهز الذيل الكلب. أولويتنا الأولى ليست الحل، بل المنظمة، إنها المنظمة التي تقود البنية التي لدينا. تدريجيًا، من خليط من الخدمات، انتقلنا إلى بنية أطلقنا عليها اسم Blade Runner، لأننا هنا نتحدث عن خدمات الحافة وقدرة NCCP على الانفصال والتكامل مباشرة في وكيل Zuul وبوابة API والوظائف المقابلة تم تحويل "القطع" إلى خدمات صغيرة جديدة مع ميزات أمان وإعادة تشغيل وفرز بيانات أكثر تقدمًا وما إلى ذلك.
وبالتالي، يمكن القول أن هياكل الإدارات وديناميكيات الشركة تلعب دورًا مهمًا في تشكيل تصميم النظام وهي عامل يعزز التغيير أو يعوقه. إن بنية الخدمات المصغرة معقدة وعضوية، وصحتها تعتمد على الانضباط والفوضى.
بعض الاعلانات
أشكركم على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المحتوى المثير للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية للأصدقاء ، , تناظرية فريدة من خوادم المستوى المبتدئ ، اخترعناها من أجلك: (متوفر مع RAID1 و RAID10 ، حتى 24 مركزًا وحتى 40 جيجا بايت DDR4).
Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ هنا فقط في هولندا! Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960 جيجا بايت SSD 1 جيجا بايت في الثانية 100 تيرا بايت - من 99 دولارًا! أقرأ عن
المصدر: www.habr.com