يوم إطلاق المنتج هو كل شيء لـ Nike. إنه اليوم الذي تذهب فيه التصاميم الجديدة للبيع. إنه اليوم الذي يكون فيه الطلب أعظم، عندما تتقارب حملات التسويق، عندما يصطف العملاء العالميون في آن واحد. إنه أيضاً اليوم الذي تصل فيه حركة BOT إلى الذروة. منسقة، خبيثة، مصممة لاستنزاف المخزون المحدود بسرعة آلية. اضطر نظام ملف المستخدم لـ Nike إلى التعامل مع الحجم والنية المعادية، لكنه لم يستطع.
مشكلة يوم إطلاق المنتج
يتم هندسة إطلاقات المنتجات لتحقيق التأثير التجاري. يتم توقيت حملات التسويق لدفع الانتباه. ينسق المؤثرون قطرات. يشير جميع الجهاز التسويقي العالمي إلى لحظة واحدة في الوقت. من المفترض أن يظهر الجميع في آن واحد ويشتري الشيء الجديد.
تم بناء منصة التجارة الإلكترونية الخاصة بـ Nike لتكون موثوقة، لكنها لم تُبن لتكون مغمورة. وصلت بنية بيانات ملف المستخدم، التي تتعامل مع التسجيل وتسجيل الدخول، إلى سقف بـ 100 إلى 200 طلب في الثانية. لم يكن فشلاً تقنياً تماماً. كانت قيداً هيكلياً. تم بناء النظام لحمل وسط وطُلب منه التعامل مع ذروة.
عندما يفشل تسجيل الدخول في يوم إطلاق المنتج، Nike لا تفقد معاملة. Nike تفقد عملاء. يذهبون بعيداً. يذهبون في مكان آخر. يوم الإطلاق حدث بدون تسامح.
وضعت Nike هدفاً. احتاجت المنصة إلى التعامل مع 500 تسجيل دخول وتسجيلات في الثانية، المحتفظ بها لمدة تصل إلى 4 ساعات أثناء أحداث الإطلاق الذروة. الحالة الحالية كانت 100 إلى 200. كان يلزم تحسن بنسبة 250%.
لكن كانت هناك مشكلة أخرى مخفية داخل المشكلة. BOT sneaker، وكلاء البرامج المصممة لتنسيق عمليات الشراء على نطاق واسع بشكل آلي. حددت Nike مشتريات منتج BOT كتحد تجاري مستمر. أي إعادة بناء للبنية التحتية احتاجت إلى معالجة ذلك أيضاً.
لماذا كانت microservices على AWS هي البنية المعمارية الصحيحة
نظام ملف المستخدم أحادي اللون له اختناق متأصل. مع إضافة المستخدمين، مع إضافة الطلبات، كل عملية واحدة يجب أن تمر عبر نفس مسار الكود. التخزين المؤقت يساعد. تجميع الاتصال يساعد. لكن هناك سقف. البنى الأحادية تضرب جدران.
اختارت TechSparq نهجاً مختلفاً. بنية معمارية event-driven CQRS مبنية على AWS microservices. تعني CQRS فصل الأوامر والاستعلامات عن المسؤولية. افصل المسارات التي تكتب البيانات عن المسارات التي تقرأ البيانات. عمليات الكتابة تذهب إلى قناة الأمر. عمليات القراءة الاستعلام نسخ متسقة في النهاية المحسنة لكل نمط وصول. لم يعد النظام يضرب اختناق واحد لأن لا توجد بعد اختناقات واحدة.
Event-driven تعني أن تغييرات الحالة يتم تسجيلها كأحداث في الوقت. تتدفق تلك الأحداث عبر النظام بشكل غير متزامن. الخدمات تستهلكها، تحدث متاجرها البيانات، وتستجيب للتغييرات. يتم تقياس هذا النموذج حيث تنقسم البنى الأحادية لأن الخدمات مفكوكة بشكل فضفاض. كل خدمة يمكنها قياس بشكل مستقل. يمكن للنظام التعامل مع الحمل المنسق لأن الحمل موزع عبر عدة أنظمة بدلاً من تركيزه في واحد.
اختارت Nike مكدس Netflix OSS لأدوات الإدارة. سبع مجموعات من microservices، كل واحدة تتعامل مع جزء مختلف من دورة حياة ملف المستخدم. تم بناء الإمكانية العالية من البداية. تحمل الأخطاء لم تُلصق بدولا. تم تصميم النظام ليكون متسقاً في النهاية، مما يعني أن تغييرات البيانات تنتشر عبر النظام بمرور الوقت بدلاً من على الفور. تلك المقابلة مناسبة للملفات الشخصية للمستخدم. يمكن للمستخدمين تحمل اتساق نهائي موجز. لا يمكنهم تحمل نظام معطل.
استراتيجية متجر البيانات خلف عدم التدهور
كان أقوى قرار هو رفض استخدام متجر بيانات واحد لكل شيء. أنماط الوصول المختلفة تحتاج إلى بنية تحتية مختلفة. نشرت Nike عدة قواعد بيانات مبنية بغرض، كل واحدة محسّنة لحالة الاستخدام الخاصة بها.
يقوم Cassandra بتخزين الأحداث المستندة إلى الوقت. عندما تصل الأحداث، يتم تسجيلها بالترتيب الذي وصلت. تم بناء Cassandra لأحمال العمل الثقيلة الكتابة مع البيانات سلسلة زمنية. إنها ليست أفضل خيار لكل استعلام، لكنها مثالية لسجلات الأحداث.
يدعم Elastic Search إمكانيات البحث كامل النص. يحتاج العملاء إلى البحث عن الملفات الشخصية والإعدادات. يتفوق Elastic Search في هذا. لكنك لن تريد تخزين كل شيء في Elastic Search أو استخدامه للاتساق المعاملي. إنه متخصص.
يوفر Couchbase تخزين ملف المستخدم. عندما يسجل المستخدم الدخول، يجب قراءة بيانات ملفه الشخصي بسرعة. Couchbase هو ذاكرة تخزين مؤقت موزعة مصممة تماماً لحالة الاستخدام هذه. إنه سريع ويتسع أفقياً.
يخزن Redis جميع بيانات المرجعية الأخرى المبنية على المفاتيح. الإعدادات والتفضيلات والعلاقة الخرائط. يتم تحسين Redis لأنماط الوصول المفتاح والقيمة ويتم تخزين أنواع البيانات البسيطة. إنه سريع وينسجم بشكل جيد.
تمنع هذه الاستراتيجية الاختناقات لأن كل نمط وصول يتم خدمته بواسطة بنية تحتية مصممة لهذا النمط. الأحداث الثقيلة الكتابة تذهب إلى Cassandra. البحث كامل النص يذهب إلى Elastic Search. قراءة الملفات الشخصية تذهب إلى Couchbase. كل شيء آخر يذهب إلى Redis. لا يصبح متجر بيانات واحد اختناق.
كانت استراتيجية الاختبار بنفس الأهمية. استخدمت TechSparq محاكاة خدمة الويب. يمكن اختبار كل microservice بمعزل عن الإصدارات المقنعة من تبعياته. المطورون الذين يعملون على خدمة الملف الشخصي لا يحتاجون إلى تشغيل المنصة بأكملها. يعملون ضد الإصدارات المقنعة للخدمات الأخرى. سمح هذا للفرق بناء الحلول ضد المنصة بدون نشر مكدس كامل يعمل في عدة AWS VPCs.
يمنع هذا النهج مشكلة شائعة في الأنظمة الموزعة. لا يمكن للفرق الاختبار بمعزل، لذا لا يمكنهم التحرك بسرعة، لذا ينتظرون بيئات الاختبار المشتركة، لذا يتباطأ كل شيء. Microservices مع عزل الاختبار الصحيح يمنع ذلك.
النتيجة ومشكلة BOT المحلولة
تم اختبار النظام الجديد بشكل تدريجي. أظهر الاختبار Alpha 600 تسجيل دخول وتسجيلات في الثانية بدون تدهور النظام. تجاوز هذا الهدف الأصلي من 500. لم يكن الكلمة الأخيرة.
استمر الاختبار. تم إجهاد النظام إلى 1200 تسجيل دخول في الثانية. عدم تدهور النظام بدون مهلة. بدون أخطاء. ستة أضعاف الهدف الأصلي. لم يكن تحسناً هامشياً. كانت فئة مختلفة من البنية التحتية.
وصلت معدلات تحميل البيانات الأولية إلى مليون معاملة في الدقيقة. كان بإمكان النظام الامتصاص ومعالجة البيانات على نطاق كان سيسبب انهيار فوري للبنية التحتية الأحادية القديمة.
تم حل مشكلة BOT بعملية عمل جديدة. التحقق من الهاتف الجوال. عندما يسجل المستخدم الدخول أو يسجل الدخول أثناء أحداث حركة المرور العالية، يطلب النظام التحقق من الهاتف الجوال. إنه عامل ثانٍ لا يمكن للبوتات أن تؤتمتها بسهولة. انخفضت مشتريات BOT بشكل كبير.
يخدم نفس النظام الأساسي الآن تطبيقات iOS الجوال وتطبيقات Android الجوال والتطبيقات الويب التقليدية. منصة واحدة توفر إدارة الملفات الشخصية عبر النظام الرقمي بأكمله في Nike. تحسنت تجربة المستخدم لأن النظام أصبح موثوقاً. زادت معدلات نجاح تسجيل الدخول. انخفضت أوقات التسجيل. واجهت قاعدة عملاء Nike العالمية نقاط احتكاك أقل أثناء اللحظات الأعلى مخاطرة في رحلة تسوقهم.
ماذا تعني هذه البنية المعمارية لعلامات التجارة عالية الحركة
إطلاقات المنتجات ليست فريدة من نوعها في Nike. كل علامة تجارية للموضة لديها. لكل شركة إلكترونيات أيام الإطلاق. ذروات التجزئة الموسمية تحدث للسلع الرياضية والمنزل والحديقة والتسوق في العطلات. البيع الخاطف والقطرات الكمية المحدودة موجودة في كل مكان في التجارة الحديثة. أي علامة تجارية بها ارتفاعات حركة مدفوعة بالحدث تواجه نفس السقف.
ينشئ نظام ملف المستخدم الأحادي فخاً هيكلياً. لديك عمليات القراءة والكتابة تتدفق عبر نفس البنية التحتية. مع زيادة الحمل، يصبح المسار المشترك مشبعاً. التخزين المؤقت يساعد. تحسين قاعدة البيانات يساعد. لكنك تعمل ضمن قيود معمارية لا يمكن إزالتها. السقف مخبوز.
Microservices مع متاجر بيانات مبنية بغرض تمنع هذا السقف. كل خدمة تتسع بشكل مستقل. كل متجر بيانات محسّن لنمط وصوله. يفصل CQRS مسارات القراءة والكتابة بحيث يمكنها قياس بشكل غير متزامن. معالجة event-driven تعني أن النظام يمكنه امتصاص حمل منسق لأن الحمل موزع.
يصبح تخفيف BOT هيكلياً بدلاً من أن يكون مربوطاً. عندما يتم تصميم بنية ملف المستخدم من الصفر حول المصادقة والتحقق، يمكنك دمج قتال BOT في المنصة نفسها. التحقق من الهاتف الجوال، بصمة الجهاز، التحليل السلوكي. كل ذلك يصبح جزء من التدفق الطبيعي بدلاً من حالة خاصة مضافة لاحقاً.
البنية المعمارية تدعم أيضاً التجريب السريع. يمكن للفرق اختبار ميزات جديدة ضد خدمات مقنعة بدون ضرورة نشر المنصة بأكملها. تزداد سرعة تطوير الفريق. يزداد معدل تسليم الميزة. تصبح الأعمال أكثر استجابة.
- Event-based CQRS تتسع حيث تنقسم البنى الأحادية. يفصل القراءة والكتابة يعني أن لا يتعين على أحد ضرب نفس الاختناق.
- متاجر البيانات المبنية بغرض تمنع الاختناقات. كل نمط وصول يحصل على بنية تحتية مصممة له، لا تتنازل عنها.
- الاختبار بمعزل يمكن الفرق من البناء بدون نشر كامل المكدس. تزداد السرعة عندما لا يتعين على المطورين انتظار بيئات الاختبار المشتركة.
- تخفيف BOT مبني في طبقة المصادقة وليس مضافاً بعد. الحلول الهيكلية أقوى من الحلول المربوطة.
هل منصتك جاهزة لأكبر أيام البيع لديك؟
منصات التجارة الإلكترونية المدفوعة بالأحداث لم تعد تفضيلاً. إنها متطلبات تنافسية. إذا تم بناء البنية التحتية الخاصة بك للتعامل مع حمل متوسط، دعنا نتحدث عن كيفية إعادة بنائها للتعامل مع لحظات الذروة التي تهم عملك أكثر.
احجز استشارة