VOL51: How Netflix Migrates Critical Traffic at Scale With No Downtime
أهلًا وسهلا بكم في العدد الواحد والخمسين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الواحد والخمسين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية، من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة، ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
How Netflix Migrates Critical Traffic at Scale With No Downtime
Linux Commands Cheatsheet
Serverless Architecture
Optimistic Locking vs Pessimistic Locking in DotNet and EFCore
How Browser Renders Web Pages - DOM & CSSOM
How Netflix Migrates Critical Traffic at Scale With No Downtime
نتفليكس عندها مئات الملايين من المستخدمين اللي بيتفرجوا كل يوم، وطبعًا المستخدمين دول متوقعين إن الخدمة تفضل شغالة من غير أي مشاكل وده لإنهم بكل تأكيد مشتركين بفلوس. وعلشان ده يحصل ويتحقق، نتفليكس عندها backend systems ضخمة بتشتغل ورا الكواليس عشان توفر تجربة مشاهدة سلسة للمستخدمين.
بس المشكلة هنا إن الـ backend systems دي مش ثابتة، بل بالعكس، بتتطور بشكل مستمر وبيتضاف لها تحسينات علشان تواكب احتياجات المنتج والمستخدمين مع الوقت. والمشكلة الحقيقية بتكمن في إن أي migration هيتم لنظام جديد ممكن يكون فيه مخاطر كبيرة جدًا، خصوصًا لو النظام ده كان بيخدم Traffic عالي أو بيأثر بشكل مباشر على تجربة المستخدم. وبقاله فترة ومدة طويلة Stable.
فاحنا لما بنيجي نعمل migration من نظام قديم لجديد، أكبر تحدي بيقابلنا هو إننا نضمن إن كل حاجة شغالة زي ما هي، من غير حدوث أي downtime، ومن غير ما المستخدم يحس بأي مشكلة.
فخلونا نشوف ايه هي المفاهيم والأدوات والتقنيات اللي نتفليكس استخدمتها علشان تقدر تنقل الـ traffic العالي اللي بيجيلهم بدون أي تأثير سلبي ونتعلم من تجربتهم.
Netflix Migration Challenges
نتفليكس معتمدة على Highly Distributed Micro-Service Architecture، وده معناه إن فيه عدد ضخم من الـ services اللي بتشتغل مع بعض في وقت واحد، وكل service ليها دور معين في تشغيل المنصة.
علشان كده، أي migration مش بيحصل مرة واحدة، لكنه بيتم على مراحل مختلفة، زي مثلًا:
الـ Migration على مستوى الـ edge API اللي بيستقبل الـ Requests من المستخدمين.
الـ Migration بين الـ edge services والـ Mid-Tier Services.
الـ Migration بين الـ Mid-Tier Services واللـ databases.
ومش بس كده، فيه كمان عامل تاني مهم ألا وهو إن فيه فرق بين الـ Migration لأنظمة بتتميز بطابع إنها stateless APIs (اللي مش بتحتفظ ببيانات المستخدم بين الـ Requests وبعضها)، وبين الـ Migration لأنظمة بتتميز بإنها stateful APIs (اللي محتاجة تحتفظ بحالة المستخدم زي الـ sessions).
Netflix Migration Strategies
نتفليكس استخدمت استراتيجيات منظمة علشان تقلل من المخاطر اللي ممكمن تحصل، وقسموا الـ Migration لمراحل:
1. Pre-Migration Validation
في المرحلة دي، بيتم اختبار الأنظمة الجديدة عشان يتأكدوا من:
صحة الـ Functionality بتاعتها وإنها شغالة زي ماهم عاوزين.
قابليتها للتوسع (Scalability).
أدائها تحت الضغط (Performance).
استقرارها في ظروف مختلفة (Resilience).
2. Gradual Traffic Migration
بعد ما يتأكدوا إن النظام الجديد سليم، بيبدأوا ينقلوا الـ traffic بالتدريج، وده بيتم من خلال:
مراقبة مستمرة للأداء.
مقارنة الـ Service Level Agreements اللي هي الـ SLAs والـ Business Key Performance Indicators اللي هي الـ KPIs بين النظام القديم والجديد.
التأكد من إن جودة الخدمة Quality of Experience عند المستخدم (QoE) ما تأثرتش.
الهدف هنا في المرحلة دي إن أي مشكلة تحصل، يتم اكتشافها بسرعة قبل ما الـ Migration يتم بالكامل.
Replay Traffic Testing
الـ Replay Traffic هو ببساطة الـ Traffic الحقيقي بتاع الـ production وبنعمله clone ونشغله على مسار مختلف تاني داخل الـ service call graph، وده بيدينا فرصة نجرب الأنظمة الجديدة أو المحدثة في ظروف شبه حقيقية من غير ما نأثر على المستخدمين الفعليين.
الفكرة هنا إننا بناخد نسخة من الـ production traffic، ونشغلها على الإصدار الجديد والقديم من النظام في نفس الوقت، وده بيساعدنا نعمل أي validations مهمة قبل ما ننقل الـ Traffic الفعلي.
المميزات
نقدر نختبر النظام الجديد بأمان من غير أي تأثير على تجربة المستخدم.
بنشوف الأداء والاستجابة تحت ضغط حقيقي لكن في بيئة sandboxed من نفس الـ Production Traffic.
بما إننا بنستخدم real traffic، بنقدر نغطي كل أنواع المدخلات المختلفة اللي بتيجي من الأجهزة المتنوعة وإصدارات الـ software المختلفة وده مهم جدًا كمان في الـ complex APIs اللي بتتعامل مع بيانات كتير متنوعة ومدخلات مختلفة.
بنقدر نختبر كمان السيناريوهات النادرة والـ edge cases اللي ممكن تكون مش واضحة في الـ unit tests العادية.
بنتأكد إن النظام الجديد بيشتغل صح وظيفيًا (functional correctness).
نقدر نستخدمه كمان في الـ load testing عشان نشوف أداء النظام تحت الضغط.
بيساعدنا إننا نظبط الـ scaling parameters بناءً على النتائج اللي بنحصل عليها عشان نحقق الأداء الأمثل واللي عاوزينه.
بنقدر نقيس Metrics مهمة زي الـ latency وavailability تحت ظروف الـ production traffic المختلفة.
بنشوف تأثير التغيرات في أنماط الـ Traffic المتوقعة وغير المتوقعة على أداء السيستم.
بنتأكد إن كل حاجة شغالة كويس، زي metrics, logging, alerting قبل ما ننقل الـ Traffic الفعلي للسيستم الجديد.
ده بيدينا فرصة نضبط أي مشاكل قبل ما نأثر على المستخدمين الحقيقين.
Replay Traffic Solution
علشان الـ Replay Traffic Testing يشتغل بكفاءة، فيه مكونين أساسيين لازم يكونوا موجودين:
Traffic Duplication and Correlation
أول خطوة هي إننا نعمل clone وfork للـ production traffic بحيث نبعته على المسار الجديد بجانب المسار القديم. لكن الموضوع مش مجرد نسخ الـ Traffic وخلاص، إحنا كمان محتاجين:
نسجل كل الـ Requests والـ Responses من المسارين (القديم والجديد).
نربط الاستجابات ببعض بحيث نقدر نقارنهم بعد كده ونعمل (Correlation).
Comparative Analysis and Reporting
بعد ما بنجمع كل البيانات، بنحتاج framework يساعدنا نحلل الفروقات بين الاستجابات اللي جت من المسارين، بحيث نطلع تقرير واضح عن:
هل في اختلافات في النتايج؟
هل النظام الجديد بيشتغل بنفس كفاءة القديم؟
هل فيه أي مشاكل في الأداء performance issues أو سلوك غير متوقع؟
Linux Commands Cheatsheet
نظام التشغيل Linux بقى واحد من أكتر الأنظمة اللي بيستخدمها المطورين، خاصة في تطوير البرمجيات وإدارة الـ Servers والـ Cloud Infrastructure. وده لإن Linux نظام مفتوح المصدر ومرن، وبيدي للمطورين سيطرة كاملة على البيئة اللي بيشتغلوا فيها، فده بيخلي تعلمنا وفهمنا لأوامر الـ Linux حاجة أساسية لو عاوزين نبقى شغالين بكفاءة وفعالية أكتر.
الـ Linux بيعتمد بشكل كبير على الـ Command Line Interface أو زي ما بنقول عليها "Terminal"، واللي هي أداة قوية جدًا وبتسمح للمطورين يعملوا مهام كتيرة زي إدارة الملفات، مراقبة العمليات، تثبيت البرامج، وكمان التحكم في الأذونات.
لما نتعلم أوامر Linux، هنقدر اننا نـ Automate أغلب مهام الشغل اليومي بتاعتنا ونسهل حاجات كتير في شغلنا، وكمان هنقدر نتحكم في كل حاجة في النظام بتاعنا بسهولة.
Serverless Architecture
من زمان والناس نفسها انه تتيح للـ Developers الفرصة أنهم يركزوا على جزء الـ Development وانهم يكونوا قادرين على بناء Services قوية ويبدعوا فيها بدون عوائق الـ Infrastructure أو التفكير فيها ..
بحيث يركزوا على الـ Core Product أو المنتج اللي مهتمين بيه بمعنى أصح ، من غير ما يهتموا بازاي هيديروا البنية التحتية للـ Product ده
وعشان كده ظهر الـ Serverless Architecture كطريقة أو نمط للتصميم يسمح للـ Developers بتحقيق الأمنية دي , وإن هم يبقوا قادرين على بناء الـ Software بدون الاهتمام بالبنية التحتية واداراتها
ازاي Serverless Architecture بتشتغل ؟
كلنا عارفين أن الـ Servers عشان تسمح للـ Users بإنهم يتواصلوا مع أي تطبيق والـ Business Logic بتاعه , ده هيتطلب Resources وبنية تحتية هتطلب موارد واهتمام وادارة زي :
Server Hardware
Security Updates
Backups
Resources Management
ومن خلال اتباع الـ Serverless Architecture احنا بنشيل العبء ده كله وبنخلي الـ Developers يهتموا بس بجزء الـ Business Logic / Core Product وانهم يكتبوا الـ Application Code وبنشيل عبء البنية التحتية ونخليها مسئولية Third Party Provider زي الـ Cloud Services اللي موجودة دلوقتي ومن أشهرهم AWS , Google Cloud , Microsoft Azure
أحد أشهر الـ Serverless Architecture هي الـ FaaS واللي هي اختصار لـ Function as a Service , واللي من خلالها الـ Developers بيكتبوا الـ Application بتاعهم والـ Core Product اكنه بالظبط عبارة عن مجموعة محددة من الـ Functions اللي بتتنفذ واللي بيحصلها Triggering من خلال الـ Events زي مثلا ان حد يبعت رسالة لحد , أو ان يتبعت Email أو ان يحصل HTTP Request بشكل معين.
وبالشكل ده انت كـ Developer مسئول عن :
كتابة الـ Function أو الـ Application Code على هيئة الـ Functions دي وتعملها Upload / Deploy على الـ Cloud Provider
تحدد الـ Trigger أو ايه هو الحدث اللي هيتسبب في إن الـ Function بتاعتك يحصلها Invocation ويتم تنفيذها ؟ يعني امتة بالظبط الـ Cloud Provider ينادي عليها وينفذها ؟
وبعد ما تعمل ده أول مالـ Cloud Provider بيعرف أن حصل Trigger بيبدأ هو يعمل Execution للـ Function بتاعتك على أحد الـ Servers واللي ده بيكون من اختصاصه هو, ولو ماكنش فيه Servers وقتها قايمة فدوره انه يعمل Spawning لواحد ويبدأ ينفذ عليه الـ Function بتاعتك.
وبالشكل ده الـ Developer بيكون معزول تماما عن ايه بيحصل من ناحية البنية التحتية , ولكن بيكون تركيزه منصب في الـ Function Logic فقط
خصم 50% على جميع خطط الاشتراك السنوية لفترة محدودة، تقدروا دلوقتي تشتركوا في اقرأ-تِك وتستمتعوا بكافة المقالات في كل ما يخص هندسة البرمجيات باللغة العربية والمحتوى المميز من ورقة وقلم ومدونات فطين اللي بيتميزوا بتصاميم ذات جودة عالية وكل ده بحرية كاملة وكمان مفاجآت اقرأ-تِك الجاية 🚀
وبرضو متاح الاشتراك من خلال InstaPay و VodafoneCash 🎁
بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship واحنا بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.
دورك كشريك أو راعي هيكون محوري في دعم المحتوى وتوسيع نطاق تأثيره. فانضم لرحلتنا وكن جزءًا من صناعة مستقبل التكنولوجيا في المنطقة 🚀
تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
Optimistic Locking vs Pessimistic Locking in DotNet and EFCore
في البداية تعالى نتخيل مثال من الواقع اللي بنعيشه كل يوم عشان نبدا نفهم عنوان المقال بتاعنا.
تخيل صديقي العزيز انك في مطعم زحمة جدا وكل الناس اللي قاعدين على طاولات الطعام بيتنافسوا مين يلفت انتباه الراجل اللي بيجي ياخد الطلبات عشان ياخد باله ويجيلهم ويجيب لهم الاوردر بتاعهم طبعا هتلاقي كل الناس عاوزين يوصلو للراجل ده في نفس الوقت!
نفس الكلام ياصديقي بيحصل في عالم قواعد البيانات و انظمة الكمبيوتر لما يتنافس عدة مستخدمين او عمليات للوصول لنفس البيانات في نفس الوقت.
ايه هو الـ Locking
هنا بقى بيكون دور ال locking كأنه حارس بيتحكم في تدفق العملاء المتحمسين يعني بيتحكم في ال flow اعتبره شرطى المرور اللي بيضمن ان ميحصلش فوضي لو في عدة مستخدمين هيعملو access او قرأو و هيعدول نفس قطعة البيانات بشكل concurrently.
يبقى دور ال locking هنا هو الحفاظ على سلامة وامن البيانات ومنع التعارض اللي ممكن يحصل على البيانات لو في concurrent operations هتحصل عليها او concurrent users عاوزين ي access هذه البيانات.
يعني هنحمي الراجل بتاع المطعم وننظم عملية الوصول ل ايه لعمل الطلبات قبل مالناس تزهق وتقوم تضربه 😅
أنواع الـ Locking
استراتيجية ال locking دي بقى بتتقسم لنوعين وكل نوع منهم ليه اسلوبه في الحفاظ على امن وسلامة البيانات ومنع تعارض ال data النوع الأول اسمه Pessimistic Locking والنوع التاني اسمه Optimistic Locking.
How Browser Renders Web Pages - DOM & CSSOM
لو سألت نفسك إزاي المتصفح بيقدر يعرض صفحة ويب كاملة قدامك بعد ما تضغط على لينك؟ الموضوع دا بيعدي بكذا خطوة مهمة، وكل خطوة ليها شغل مختلف وبتأثر بشكل مباشر على سرعة تحميل الصفحة وتجربة المستخدم.
بناء شجرتين DOM و CSSOM
عشان المتصفح يقدر يعرض (يـ render) الصفحة، أول حاجة بيعملها إنه يبني شجرتين شجرة الـ DOM وشجرة الـ CSSOM.
الـ "DOM "Document Object Model: دي شجرة بتمثل كل عنصر HTML في الصفحة.
الـ "CSSOM "CSS Object Model: دي شجرة بتمثل الـ styles اللي بتحدد شكل الصفحة (الـ CSS).
المتصفح محتاج يبني الشجرتين دول عشان يعرف إزاي هيتعامل مع كل عنصر في الصفحة وأشكاله من الـ CSS.
ليه بناء الشجرتين دول مهم؟
الـ DOM بيحدد المحتوى اللي هيظهر، والـ CSSOM بيحدد شكله، وبالتالي المتصفح لازم يعرف التنسيق النهائي لكل عنصر في الصفحة قبل ما يرسمه (يـ render). بعد ما المتصفح يبني الشجرتين دول، بيبدأ يجمعهم في خطوة مهمة اسمها "شجرة العرض" (render tree)، ودي اللي بتربط المحتوى بالتصميم وتخلي المتصفح يقدر يرسم العناصر بالشكل المطلوب.
الإصدار الأول - ورقة وقلم 🚀
في الإصدار ده جمعنا أكتر من 50 موضوع في مختلف مجالات هندسة البرمجيات بأكتر من 170 صفحة + تصاميم بجودة عالية وكل ده بالعربي وبشكل مميز ومتقسم لفصول سهل تنتقلوا من فصل وموضع للتاني بدون مشاكل 💎
تقدروا تشوفوا النسخة كاملة من هنا كـ E-Book ، وحاولنا نخليها بسعر رمزي يناسب الجميع 👇
ولو عندكوا أي مشكلة في الدفع ، تقدروا تتواصلوا معانا وهنكون مبسوطين باننا نوفر بدايل زي InstaPay و VodafoneCash 🎁
ولو عاوزين تعاينوا جودة الـ E-Book قبل ما تشتروه ، تقدروا تحملوا النسخة المجانية واللي بتضم حوالي 30 موضوع فيما لايزيد عن 100 صفحة من هنا 😉
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
