مرحبا بالجميع! أنا متأكد من أن العديد منكم قد اشترى قميصًا أو كرة أو أحذية رياضية أو بعض المعدات الرياضية الأخرى في متاجرنا ، ولكن قلة من الناس يعرفون ما هي Sportmaster من وجهة نظر تقنية.
قليلا من 2003 Sportmaster من web.archive.orgاسمي ديمتري ، أنا مطور جافا كبير في Sportmaster ، واليوم أود أن أتحدث عن متجرنا على الإنترنت ، حول المسار الذي سلكه ليصبح بالطريقة التي تعرفه الآن: كيف بدأنا ، وكيف طورنا ما حدث وما لا ، وحول المشاكل اليوم ، وخطط للمستقبل. المهتمة؟ مرحبا بكم في القط!
بدأ تاريخ وجود شركتنا على الويب بالفعل في عام 1999 من خلال الموقع الأول لـ Sportmaster ، والذي كان مجرد بطاقة أعمال وكتالوج للبضائع لمشتري الجملة. في الواقع المتجر الالكتروني للشركة له تاريخه منذ عام 2001. في تلك الأيام ، لم يكن لدى الشركة فريق خاص بها لتطوير مشاريع عبر الإنترنت ، وتمكّن المتجر عبر الإنترنت من تغيير العديد من المنصات ذاتية الصنع (الآن لا نتذكر عددها). تم إنشاء أول حل مستقر نسبيًا من قِبل المُدمج التالي في عام 2011 في PHP ، استنادًا إلى CMS 1C Bitrix. تبين أن الموقع بسيط ، في الواقع ، تم استخدام وظيفة محاصر Bitrix ، مع تخصيصات صغيرة لتقديم طلب. بالنسبة للأجهزة ، تضمن تكوين البدء خادمي تطبيق وخادم قاعدة بيانات واحد.
في غضون ذلك ، بدأت الشركة في بناء كفاءاتها الخاصة في مجال المبيعات عبر الإنترنت ، وبشكل أساسي في جانب العمل ، والذي يجب أن أقوله سريعًا جدًا ، وقد اضطر فريق التطوير للنمو السريع بكل معنى الكلمة لتلبية احتياجاته. في أقل من عام ، بدأت ثلاثة فرق على الفور في الإجابة عن تطوير ودعم الموقع - المُدمج نفسه ، والفريق الداخلي لـ Sportmaster ، والذي كان يتألف في ذلك الوقت من عدد قليل من الناس ، ومقاول آخر - كان مظهره ، في الواقع ، يرجع إلى حقيقة أن المُدمج في تلك اللحظة لم أستطع توفير القدرات التي نحتاجها للناس.
ما هي المشاكل التي واجهناها في ذلك الوقت؟ كانت هناك العديد من المشاكل ، لكن الأهم هو التشغيل غير المستقر لمتجرنا على الإنترنت.
يمكن أن ننطلق حتى من حقيقة أن الشركة قد نفذت نوعًا من النشرة الإخبارية ، وبعدها جاء حوالي 2000-2500 شخصًا إلى الموقع ، أو ، كما أتذكر الآن ، أرسلنا لافتة إعلانية على Yandex إلى ضربة قاضية عميقة. بالطبع ، هذه الأشياء غير مقبولة ، لأن هذا ليس فقط الأرباح الضائعة ، ولكن أيضًا صورة الشركة - بشكل عام ، لقد فهمنا أن هناك حاجة إلى تغيير شيء ما. بادئ ذي بدء ، تم إدراك أن الحلول القياسية ذات أعباء العمل لدينا (في ذلك الوقت ليست كبيرة جدًا ، ولكنها لا تزال صغيرة) لن تنجح. ثم كان لدينا حوالي 1000 زائر عبر الإنترنت بشكل طبيعي ، و 2500 زائر في ذروتها ، بالإضافة إلى خطط التطوير x2 سنويًا.
كثفت على الفور من حيث الأجهزة: أضفنا 2 خوادم التطبيقات الأخرى وجعلنا مجموعة من خوادم قاعدة البيانات 2. كومة لدينا في ذلك الوقت كان nginx ، الخلية ، PHP. في موازاة ذلك ، حاولنا تحسين الحل الحالي - بحثنا عن الاختناقات ، حاولنا إعادة كتابة كل ما كان ممكنًا. نظرًا لأن عنق الزجاجة كان الأساس ، فقد كان دائمًا أول من "يموتون" ، قررنا تفريغه إلى الحد الأقصى. تم تنفيذ أبو الهول للبحث عن النص الكامل وإخراج بلاطات السلع مع الأوجه بواسطة المرشحات المحددة والمخازن المؤقتة المتصلة. وفويلا - تلك الأحمال التي كانت قاتلة بالنسبة لنا أمس ، بدأنا في التمسك بكل سهولة.
إلى جانب ذلك ، تم إطلاق تجربة تجريبية بالتوازي ، في إطارها أرادوا إجراء تحديث تقني للموقع - نقل إلى منصة مختلفة اختلافًا جذريًا. كانت هناك العديد من الأفكار والأفكار - في ذلك الوقت ، كان إضفاء الطابع الشخصي على كل شيء وكل شيء ، والتوصيات الشخصية ، والمراسلات ، والخصومات وغيرها من الأشياء المفيدة تكتسب شعبية ، وكنا بالطبع نريد استخدام كل هذا. نظرنا إلى ما هو متوفر في السوق من هذا ، حسنًا ، واشترينا المنصة الأغلى على مبدأ "مرة أخرى أغلى ثم أبرد". تم التخطيط للتنفيذ بمساعدة أحد الدمجين ، وما زلنا نحظى بدعم وتطوير IM الفوري المشروط حتى تم تشغيل الجديد على النظام الأساسي الجديد.
ولكن نظرًا لأن سرعة التطوير الوظيفي للموقع الحالي كانت عالية جدًا ، فقد قررنا أن نبدأ في تنفيذ منصة التجارة الإلكترونية الجديدة من متجر أصغر وأكثر بساطة في ذلك الوقت عبر الإنترنت لسلسلة البيع بالتجزئة في أوستن ، والتي يخدمها أيضًا فريق IT Sportmaster. في هذه العملية ، أدركنا أن الشيء كان ضخمًا ومتطورًا وظيفيًا ، ولكنه عفا عليه الزمن من الناحية التكنولوجية ، ووجد أن العثور على أشخاص لتنفيذه بالكامل يمثل مشكلة كبيرة. بالإضافة إلى ذلك ، أدى تغيير الحجم الذي تم إجراؤه قبل بدء المشروع إلى انخفاض كبير في متطلبات الأجهزة وعدد التراخيص - تبين أن الحياة كانت أكثر قسوة. بشكل عام ، فهمنا شيئًا واحدًا: لن نقوم بعمل مشرف رياضي عليه. ونظرًا لأن فريق الترحيل إلى المنصة كان بالفعل في عملية التوظيف ، فقد قرر الشباب البدء في وضع نماذج أولية لحلهم الخاص ، استنادًا إلى المتطلبات التي حددتها الشركة للمنصة الجديدة.
تم اختيار رصة التكنولوجيا على النحو التالي: Java ، Spring ، Tomcat ، ElasticSearch ، Hazelcast.
نتيجة لذلك ، بحلول نهاية عام 2014 ، كان لدينا نسخة جديدة من الرسائل الفورية جاهزة بالكامل مكتوبة ذاتيا ، والتي تحولنا إليها بنجاح. إنها الإصدار الأول من الموقع الذي تراه اليوم. بطبيعة الحال ، فإن الإصدار الحالي هو أكثر وظيفية وتكنولوجية ، ولكن النظام الأساسي هو نفسه.
المهام الرئيسية
بطبيعة الحال ، عندما نتحدث عن متجر كبير على الإنترنت ، فإننا نتحدث عن الاستعداد للتعامل ليس فقط مع يوميًا ، ولكن أيضًا مع أحمال الذروة - لتكون مستقرة للأعمال التجارية والمستخدمين النهائيين.
تتمثل الطرق الرئيسية هنا في القدرة على القياس أفقيًا وتطبيق أساليب تخزين البيانات في مستويات مختلفة. والآن ، كما حدث منذ بعض الوقت ، قررنا تحسين الوصول إلى بياناتنا. ولكن لا يمكننا استخدام التخزين المؤقت للصفحة العادية. عموما. هذا مطلب تجاري ، والشرط معقول - إذا قمت بعرض السعر الخاطئ أو عدم توفر السلع في لحظة معينة لمستخدم الموقع ، فمن المحتمل أن يؤدي ذلك إلى رفض الشراء وانخفاض في ولاء العميل.
لا بأس إذا طلب العميل 15 زوجًا من الجوارب مقابل 299 روبل ، وفي المتجر اكتشف أنه في الحقيقة لا يوجد سوى 14 زوجًا و 300 روبل - يمكنك العيش معه بطريقة أو بأخرى. تقبل ، وشراء ما هو ، والعيش مع هذه الندبة في روحك. ولكن إذا كانت التناقضات في الأرقام خطيرة ، أو كنت تبحث عن حجم معين - وتم شراؤه أثناء قراءة مراجعات أصحاب الشورتات السعيدة المقطوعة ، فكل شيء سيكون بالفعل أكثر حزنًا. وهذا هو ، على الفور فقدان عميل راض (حتى هذه النقطة) ، وفقدان الوقت والمال على عمل مركز الاتصال ، حيث سيتصل هذا العميل لمعرفة ما حدث ولماذا.
لذلك ، يجب على المستخدم دائمًا الاطلاع على أحدث الأسعار وأحدث البيانات عن أرصدة السلع ، وبالتالي فإن ذاكرتنا المخبأة ذكية وتعرف متى تتغير البيانات الموجودة في قاعدة البيانات. للتخزين المؤقت نستخدم Hazelcast.
بالمناسبة ، عن بقايا الطعام
من المهم الإشارة إلى أن عمق بقايا السلع صغير جدًا. وهناك عدد كبير للغاية من الطلبات تذهب للاستلام (جدا). لذلك ، يجب على العميل عادةً حجز البضائع في المتجر الصحيح وتتبع الأرصدة. في وقت واحد ، على Bitrix ، تم تناول مشكلة المخلفات من خلال حقيقة أنها تعتبر ببساطة أي بقايا لأكثر من 10 وحدات لا متناهية. وهذا يعني أن كل ما يزيد عن 10 يساوي دائمًا 10 ، ولكن القيم الأقل أهمية بالفعل بالنسبة لنا لحسابنا ونأخذها في الاعتبار ، ونقوم بتحميلها على الموقع.
الآن لم يعد من الممكن القيام بذلك ، لذلك نقوم بتنزيل بقايا الطعام من جميع المتاجر في كل 15 دقيقة. ولدينا حوالي 500 متجر ، بالإضافة إلى عدد من المستودعات الإقليمية ، بالإضافة إلى العديد من سلاسل البيع بالتجزئة. وكل هذا يجب تحديثه على الفور. الكرز هنا هو حقيقة أن ظروف عمل شركات البريد السريع تتغير في كثير من الأحيان على نطاق الاتحاد الروسي ، وبالتالي ، يجب أيضًا تحميل معلمات التسليم. بالإضافة إلى ذلك ، هناك تدفق مستمر للبضائع إلى مستودعات الشركة ، ولهذا السبب من المتوقع أن تتغير كمية البضائع في المستودعات. لذلك ، فإنه يحتاج أيضا إلى سحبها مرة أخرى.
وهنا كيف يتم تشكيل معرفات العناصر السلعية (SKUs). لدينا حوالي 40،000 ، ما يسمى نماذج اللون من البضائع. إذا ذهبنا أبعد من ذلك إلى حجم البضاعة ، نحصل على حوالي 200000 SKU. ولهذا كله ، يجب تحديث 200000 على مقياس 500 متجر.
لدينا أيضًا عشرات الآلاف من المدن والقرى التي ننقل إليها البضائع من المتاجر أو من المستودعات. لذلك ، اتضح أن تباين ذاكرة التخزين المؤقت لصفحة منتج واحدة فقط (المدينة * SKU) هو ملايين من القيمة. النهج الذي نتبعه هو: حساب مدى توفر وحدة سلعة معينة يحدث سريعًا عند قيام المستخدم بإدخال بطاقة المنتج. نحن ننظر إلى عمل شركات النقل في منطقة المستخدم ، وننظر في جدول أعمالهم ، ونحسب سلسلة التسليم ونفكر في مدتها. إلى جانب ذلك ، يتم تحليل البقايا في المتاجر القريبة بالتوازي ، والتي يمكن من خلالها ترتيب النقل.
لتسهيل إدارة كل هذا ، لدينا عدد معين من ذاكرات التخزين المؤقت السريعة جدًا في التطبيق - وبفضل هذا ، يمكننا الحصول بسرعة على جميع البيانات اللازمة حسب المعرف ، وفرزها سريعًا. نفس الشيء مع شركات النقل - نقوم بتجميعهم في مجموعات ، ثم يتم حفظ المجموعات بالفعل في قاعدة البيانات. كل 15 دقيقة ، يتم تحديث كل هذا ، لكل طلب وارد ، نقوم بحساب مجموعة معيّنة من شركات النقل باستخدام المعلمات اللازمة ، ونجمعها ونمنحها للمشتري بسرعة - كل شيء على ما يرام ، لدينا بالتأكيد شورتات خضراء ذات حجم 50 ، يمكنك إما اختر الأقلام في هذه المتاجر الثلاثة القريبة الآن ، أو اطلب من متجر عبر الطريق (أو حتى المنزل) لمدة 3 أيام ، اختر.
بالنسبة لموسكو ، قد يبدو هذا الموقف غير ضروري ، ولكن بالنسبة للمناطق ، فهذه مسألة مختلفة تمامًا ، فهي في كثير من الأحيان تطلب البضائع إلى بعض المتاجر (والتي ربما تحتاج أيضًا إلى الوصول إليها بشكل خاص).
الأرقام
يتلقى الموقع الآن الآلاف من الطلبات في الثانية الواحدة ، مع مراعاة الإحصائيات و 500-1000 طلب في الثانية لخوادم التطبيقات. لم يتغير عدد خوادم التطبيقات ، لكن التكوين الخاص بها قد زاد بشكل كبير. يتم الحصول على ما متوسطه حوالي 3،000،000 مشاهدة يوميًا.
توجد أحيانًا وحدات DDoS على الموقع. في الوقت نفسه ، يطرقون شبكات الروبوت ، علاوة على ذلك ، أقاربنا من الاتحاد الروسي. منذ وقت طويل كانت هناك حالات محاولات لضرب شبكات الروبوت من المكسيك وتايوان ، ولكن الآن لم يعد الأمر كذلك.
هناك عدد من الحلول لحماية السحابة من DDoS في السوق ، نعم ، وحلول جيدة للغاية. ولكن بالنسبة لبعض سياسات الأمان ، لا يمكننا استخدام هذا النوع من الحلول السحابية.
ماذا الان
نبدأ في إنشاء حل للنظام الأساسي ، بفصل الفرق بشكل غير رأسي (رأى بعضهم موقعًا ، والآخر يرى موقعًا آخر) ، ولكن بشكل أفقي ، تسليط الضوء على طبقة النظام الأساسي المشتركة ، وتقسيمها إلى أجزاء ، وتكوين فريق من حوله. ونقوم بالفعل بإغلاق الموقع وليس فقط ، بما في ذلك أي عملاء للشركة ، خارجيًا وداخليًا. لذلك ، لدينا الكثير من العمل المعقد والمثير للاهتمام.
لم يتغير هذا المكدس في المقدمة ، لأسباب واضحة ، حقًا خلال هذا الوقت - لا تزال Java و Spring و Tomcat و ElasticSearch و Hazelcast جيدة لتلبية احتياجاتنا. شيء آخر هو أن الكثير من أنظمة المكاتب الخلفية على تقنيات مختلفة مخفية وراء الموقع. وبالطبع ، هناك عملية إعادة هندسة جارية (نظرًا لأن طلبات الأنظمة الداخلية والعمل معها ككل تحتاج إلى التحسين ، بالإضافة إلى أننا لا ننسى متطلبات العمل ووظائف الأعمال الجديدة).
ويمكنك أن ترمي بأمان في أي اقتراحات شخصية (أو في تعليقات) حول تحسين الموقع - سواء من حيث الميزات الجديدة أو المكون المرئي وتجربة المستخدم الإجمالية. سنحاول الاستجابة بسرعة وتأخذ في الاعتبار كل شيء. وإذا كنت تريد أن تصبح جزءًا من الفريق ورأيت كل شيء من الداخل -
مرحبًا بك .