يبدو أن مجال الإعلان عبر الإنترنت يجب أن يكون متقدمًا تقنيًا وآليًا قدر الإمكان. بالطبع، لأن هؤلاء العمالقة والخبراء في مجالهم، مثل Yandex، Mail.Ru، Google و Facebook يعملون هناك. ولكن، كما اتضح فيما بعد، ليس هناك حد للكمال، وهناك دائمًا شيء يمكن تشغيله تلقائيًا.
مجموعة الاتصالات شبكة دنتسو إيجيس روسيا هي أكبر لاعب في سوق الإعلانات الرقمية وتستثمر بنشاط في التكنولوجيا، وتحاول تحسين عملياتها التجارية وأتمتتها. أصبحت إحدى المشكلات التي لم يتم حلها في سوق الإعلان عبر الإنترنت هي مهمة جمع الإحصائيات حول الحملات الإعلانية من منصات الإنترنت المختلفة. أدى حل هذه المشكلة في النهاية إلى إنشاء منتج D1.رقمي (اقرأ باسم DiVan)، الذي نريد التحدث عنه.
لماذا؟
1. في وقت بداية المشروع، لم يكن هناك منتج واحد جاهز في السوق يحل مشكلة أتمتة جمع الإحصائيات حول الحملات الإعلانية. وهذا يعني أنه لا أحد غير أنفسنا سوف يلبي احتياجاتنا.
توفر خدمات مثل Improvado وRoistat وSupermetrics وSegmentStream التكامل مع المنصات والشبكات الاجتماعية وGoogle Analitycs، وتتيح أيضًا إمكانية إنشاء لوحات معلومات تحليلية للتحليل الملائم والتحكم في الحملات الإعلانية. قبل أن نبدأ في تطوير منتجنا، حاولنا استخدام بعض هذه الأنظمة لجمع البيانات من المواقع، لكنها للأسف لم تتمكن من حل مشاكلنا.
وكانت المشكلة الرئيسية هي أن المنتجات التي تم اختبارها اعتمدت على مصادر البيانات، وعرض إحصائيات المواضع حسب الموقع، ولم توفر إمكانية تجميع الإحصائيات حول الحملات الإعلانية. لم يسمح لنا هذا النهج برؤية إحصائيات من مواقع مختلفة في مكان واحد وتحليل حالة الحملة ككل.
وكان العامل الآخر هو أن المنتجات في المراحل الأولية كانت موجهة إلى السوق الغربية ولم تدعم التكامل مع المواقع الروسية. وبالنسبة لتلك المواقع التي تم تنفيذ التكامل معها، لم يتم دائمًا تنزيل جميع المقاييس اللازمة بتفاصيل كافية، ولم يكن التكامل دائمًا مريحًا وشفافًا، خاصة عندما كان من الضروري الحصول على شيء غير موجود في واجهة النظام.
بشكل عام، قررنا عدم التكيف مع منتجات الطرف الثالث، ولكننا بدأنا في تطوير منتجاتنا الخاصة...
2. ينمو سوق الإعلان عبر الإنترنت من عام لآخر، وفي عام 2018، من حيث ميزانيات الإعلان، تفوق على أكبر سوق إعلان تلفزيوني تقليديًا. لذلك هناك مقياس.
3. على عكس سوق الإعلانات التلفزيونية، حيث يتم احتكار بيع الإعلانات التجارية، هناك الكثير من أصحاب المخزون الإعلاني الفردي بأحجام مختلفة يعملون على الإنترنت بحساباتهم الإعلانية الخاصة. نظرًا لأن الحملة الإعلانية، كقاعدة عامة، تعمل على عدة مواقع في وقت واحد، لفهم حالة الحملة الإعلانية، فمن الضروري جمع التقارير من جميع المواقع ودمجها في تقرير واحد كبير يعرض الصورة بأكملها. وهذا يعني أن هناك إمكانية للتحسين.
4. بدا لنا أن أصحاب المخزون الإعلاني على الإنترنت لديهم بالفعل البنية التحتية اللازمة لجمع الإحصائيات وعرضها في الحسابات الإعلانية، وسيكون بمقدورهم توفير واجهة برمجة التطبيقات (API) لهذه البيانات. وهذا يعني أنه من الممكن من الناحية الفنية تنفيذه. لنفترض على الفور أن الأمر لم يكن بهذه البساطة.
بشكل عام، جميع متطلبات تنفيذ المشروع كانت واضحة لنا، وبادرنا لإخراج المشروع إلى الحياة...
الخطة الكبرى
في البداية، قمنا بتكوين رؤية للنظام المثالي:
- يجب تحميل الحملات الإعلانية من نظام الشركة 1C تلقائيًا بأسمائها وفتراتها وميزانياتها ومواضعها على منصات مختلفة.
- بالنسبة لكل موضع ضمن حملة إعلانية، يجب تنزيل جميع الإحصائيات الممكنة تلقائيًا من المواقع التي يتم فيها الموضع، مثل عدد مرات الظهور والنقرات والمشاهدات وما إلى ذلك.
- يتم تتبع بعض الحملات الإعلانية باستخدام مراقبة طرف ثالث من خلال ما يسمى بأنظمة عرض الإعلانات مثل Adriver وWeborama وDCM وغيرها. يوجد أيضًا عداد إنترنت صناعي في روسيا - شركة Mediascope. وفقًا لخطتنا، يجب أيضًا تحميل بيانات المراقبة المستقلة والصناعية تلقائيًا في الحملات الإعلانية المقابلة.
- تستهدف معظم الحملات الإعلانية على الإنترنت إجراءات مستهدفة معينة (الشراء، الاتصال، الاشتراك لاختبار القيادة، وما إلى ذلك)، والتي يتم تتبعها باستخدام Google Analytics، كما تعد إحصاءاتها مهمة أيضًا لفهم حالة الحملة و ينبغي تحميلها في أداتنا.
أول فطيرة محلاة
نظرًا لالتزامنا بالمبادئ المرنة لتطوير البرمجيات (المرونة، كل الأشياء)، قررنا أولاً تطوير MVP ثم التحرك نحو الهدف المقصود بشكل متكرر.
قررنا بناء MVP بناءً على منتجنا DANBo (لوحة شبكة Dentsu Aegis)وهو تطبيق ويب يحتوي على معلومات عامة عن الحملات الإعلانية لعملائنا.
بالنسبة لـ MVP، تم تبسيط المشروع قدر الإمكان من حيث التنفيذ. لقد اخترنا قائمة محدودة من المنصات للتكامل. كانت هذه هي المنصات الرئيسية، مثل Yandex.Direct، وYandex.Display، وRB.Mail، وMyTarget، وAdwords، وDBM، وVK، وFB، وأنظمة الإعلانات الرئيسية Adriver وWeborama.
للوصول إلى إحصائيات المواقع عبر واجهة برمجة التطبيقات (API)، استخدمنا حسابًا واحدًا. كان على مدير مجموعة العملاء الذي أراد استخدام المجموعة التلقائية للإحصائيات في حملة إعلانية أن يفوض أولاً الوصول إلى الحملات الإعلانية الضرورية على المواقع إلى حساب النظام الأساسي.
التالي هو مستخدم النظام دانبو كان عليك تحميل ملف بتنسيق معين في نظام Excel، والذي يحتوي على جميع المعلومات حول الموضع (الحملة الإعلانية، النظام الأساسي، التنسيق، فترة التنسيب، المؤشرات المخططة، الميزانية، إلخ) ومعرفات الحملات الإعلانية المقابلة على المواقع والعدادات في أنظمة الإعلانات.
بدا الأمر مرعبًا بصراحة:
تم حفظ البيانات التي تم تنزيلها في قاعدة بيانات، ثم قامت الخدمات المنفصلة بجمع معرفات الحملة على المواقع منها وتنزيل الإحصائيات عليها.
لكل موقع، تمت كتابة خدمة Windows منفصلة، \u200b\u200bوالتي كانت تخضع مرة واحدة يوميًا لحساب خدمة واحد في واجهة برمجة تطبيقات الموقع وتنزيل الإحصائيات لمعرفات الحملة المحددة. حدث الشيء نفسه مع أنظمة الإعلانات.
تم عرض البيانات التي تم تنزيلها على الواجهة في شكل لوحة معلومات صغيرة مخصصة:
وبشكل غير متوقع بالنسبة لنا، بدأ MVP العمل وبدأ في تنزيل الإحصائيات الحالية للحملات الإعلانية على الإنترنت. قمنا بتطبيق النظام على العديد من العملاء، ولكن عند محاولة التوسع، واجهنا مشكلات خطيرة:
- كانت المشكلة الرئيسية هي تعقيد إعداد البيانات للتحميل في النظام. كما كان لا بد من تحويل بيانات الموضع إلى تنسيق ثابت تمامًا قبل التحميل. كان من الضروري تضمين معرفات الكيانات من مواقع مختلفة في ملف التنزيل. نحن نواجه حقيقة أنه من الصعب جدًا على المستخدمين غير المدربين تقنيًا شرح مكان العثور على هذه المعرفات على الموقع والمكان الذي يجب إدخاله فيه في الملف. وبالنظر إلى عدد الموظفين في الأقسام التي تدير الحملات على المواقع ومعدل دوران الموظفين، فقد أدى ذلك إلى قدر كبير من الدعم من جانبنا، وهو الأمر الذي لم نكن سعداء به على الإطلاق.
- وكانت المشكلة الأخرى هي أنه ليس لدى جميع منصات الإعلان آليات لتفويض الوصول إلى الحملات الإعلانية لحسابات أخرى. ولكن حتى لو كانت آلية التفويض متاحة، لم يكن جميع المعلنين على استعداد لمنح حق الوصول إلى حملاتهم لحسابات الطرف الثالث.
- كان أحد العوامل المهمة هو السخط الذي أثاره المستخدمون من حقيقة أن جميع المؤشرات المخططة وتفاصيل التنسيب التي أدخلوها بالفعل في نظام المحاسبة 1C الخاص بنا، يجب عليهم إعادة إدخالها دانبو.
أعطانا هذا فكرة أن المصدر الأساسي للمعلومات حول التنسيب يجب أن يكون نظام 1C الخاص بنا، حيث يتم إدخال جميع البيانات بدقة وفي الوقت المحدد (النقطة هنا هي أنه يتم إنشاء الفواتير بناءً على بيانات 1C، لذا قم بإدخال البيانات بشكل صحيح في 1C هي أولوية للجميع KPI). وهكذا ظهر مفهوم جديد للنظام..
مفهوم
أول شيء قررنا القيام به هو فصل نظام جمع إحصائيات الحملات الإعلانية على الإنترنت إلى منتج منفصل - D1.رقمي.
في المفهوم الجديد، قررنا التحميل D1.رقمي معلومات عن الحملات الإعلانية والمواضع الموجودة بداخلها من 1C، ثم سحب الإحصائيات من المواقع وأنظمة AdServing إلى هذه المواضع. كان من المفترض أن يؤدي ذلك إلى تبسيط حياة المستخدمين بشكل كبير (وكالعادة إضافة المزيد من العمل للمطورين) وتقليل مقدار الدعم.
كانت المشكلة الأولى التي واجهناها ذات طبيعة تنظيمية وكانت مرتبطة بحقيقة أننا لم نتمكن من العثور على مفتاح أو علامة يمكننا من خلالها مقارنة الكيانات من أنظمة مختلفة مع الحملات والمواضع من 1C. الحقيقة هي أن العملية في شركتنا مصممة بحيث يتم إدخال الحملات الإعلانية في أنظمة مختلفة بواسطة أشخاص مختلفين (مخططو وسائل الإعلام، والشراء، وما إلى ذلك).
لحل هذه المشكلة، كان علينا أن نخترع مفتاحًا مجزأًا فريدًا، DANBoID، والذي من شأنه أن يربط الكيانات في أنظمة مختلفة معًا، ويمكن التعرف عليه بسهولة وبشكل فريد في مجموعات البيانات التي تم تنزيلها. يتم إنشاء هذا المعرف في نظام 1C الداخلي لكل موضع فردي ويتم نقله إلى الحملات والمواضع والعدادات في جميع المواقع وفي جميع أنظمة AdServing. استغرق تنفيذ ممارسة وضع DANBoID في جميع المواضع بعض الوقت، لكننا تمكنا من القيام بذلك :)
ثم اكتشفنا أنه ليست كل المواقع تحتوي على واجهة برمجة تطبيقات لجمع الإحصائيات تلقائيًا، وحتى تلك التي لديها واجهة برمجة تطبيقات، فإنها لا تُرجع جميع البيانات الضرورية.
في هذه المرحلة، قررنا تقليص قائمة منصات التكامل بشكل كبير والتركيز على المنصات الرئيسية التي تشارك في الغالبية العظمى من الحملات الإعلانية. تتضمن هذه القائمة جميع أكبر اللاعبين في سوق الإعلانات (Google، وYandex، وMail.ru)، والشبكات الاجتماعية (VK، وFacebook، وTwitter)، وأنظمة خدمة الإعلانات والتحليلات الرئيسية (DCM، وAdriver، وWeborama، وGoogle Analytics) ومنصات أخرى.
تحتوي غالبية المواقع التي اخترناها على واجهة برمجة التطبيقات (API) التي توفر المقاييس التي نحتاجها. في الحالات التي لم تكن فيها واجهة برمجة التطبيقات (API) أو لم تكن تحتوي على البيانات اللازمة، استخدمنا التقارير التي يتم إرسالها يوميًا إلى البريد الإلكتروني لمكتبنا لتحميل البيانات (في بعض الأنظمة، من الممكن تكوين مثل هذه التقارير، وفي أنظمة أخرى اتفقنا على تطوير مثل هذه التقارير لنا).
عند تحليل البيانات من مواقع مختلفة، اكتشفنا أن التسلسل الهرمي للكيانات ليس هو نفسه في الأنظمة المختلفة. علاوة على ذلك، يجب تنزيل المعلومات بتفاصيل مختلفة من أنظمة مختلفة.
لحل هذه المشكلة، تم تطوير مفهوم SubDANBoID. فكرة SubDANBoID بسيطة للغاية، نقوم بوضع علامة على الكيان الرئيسي للحملة على الموقع باستخدام DANBoID الذي تم إنشاؤه، ونقوم بتحميل جميع الكيانات المتداخلة بمعرفات موقع فريدة وشكل SubDANBoID وفقًا لمبدأ DANBoID + معرف المستوى الأول الكيان المتداخل + معرف الكيان المتداخل من المستوى الثاني +... سمح لنا هذا الأسلوب بربط الحملات الإعلانية في أنظمة مختلفة وتنزيل إحصائيات تفصيلية عنها.
كان علينا أيضًا حل مشكلة الوصول إلى الحملات على منصات مختلفة. كما كتبنا أعلاه، فإن آلية تفويض الوصول إلى الحملة إلى حساب فني منفصل لا تنطبق دائمًا. لذلك، كان علينا تطوير بنية تحتية للتخويل التلقائي عبر OAuth باستخدام الرموز المميزة وآليات تحديث هذه الرموز المميزة.
سنحاول لاحقًا في المقالة أن نصف بمزيد من التفصيل بنية الحل والتفاصيل الفنية للتنفيذ.
بنية الحل 1.0
عند البدء في تنفيذ منتج جديد، فهمنا أننا نحتاج على الفور إلى توفير إمكانية ربط المواقع الجديدة، لذلك قررنا اتباع مسار بنية الخدمات الصغيرة.
عند تصميم البنية، قمنا بفصل الموصلات لجميع الأنظمة الخارجية - 1C ومنصات الإعلان وأنظمة الإعلانات - إلى خدمات منفصلة.
الفكرة الرئيسية هي أن جميع الموصلات إلى المواقع لها نفس واجهة برمجة التطبيقات (API) وهي عبارة عن محولات تعمل على توصيل واجهة برمجة تطبيقات الموقع إلى واجهة مناسبة لنا.
يوجد في قلب منتجنا تطبيق ويب، وهو عبارة عن وحدة متراصة تم تصميمها بطريقة يمكن تفكيكها بسهولة إلى خدمات. هذا التطبيق مسؤول عن معالجة البيانات التي تم تنزيلها، وجمع الإحصائيات من الأنظمة المختلفة وتقديمها لمستخدمي النظام.
للتواصل بين الموصلات وتطبيق الويب، كان علينا إنشاء خدمة إضافية أطلقنا عليها اسم Connector Proxy. ينفذ وظائف اكتشاف الخدمة وجدولة المهام. تقوم هذه الخدمة بتشغيل مهام جمع البيانات لكل موصل كل ليلة. كانت كتابة طبقة الخدمة أسهل من الاتصال بوسيط الرسائل، وكان من المهم بالنسبة لنا الحصول على النتيجة في أسرع وقت ممكن.
ومن أجل البساطة وسرعة التطوير، قررنا أيضًا أن تكون جميع الخدمات عبارة عن Web APIs. وقد أتاح هذا إمكانية تجميع إثبات المفهوم بسرعة والتحقق من نجاح التصميم بأكمله.
كانت المهمة المنفصلة والمعقدة إلى حد ما هي إعداد الوصول لجمع البيانات من حسابات مختلفة، والتي، كما قررنا، يجب أن يتم تنفيذها من قبل المستخدمين من خلال واجهة الويب. ويتكون من خطوتين منفصلتين: أولاً، يضيف المستخدم رمزًا مميزًا للوصول إلى الحساب عبر OAuth، ثم يقوم بتكوين جمع البيانات للعميل من حساب معين. يعد الحصول على رمز مميز عبر OAuth ضروريًا لأنه، كما كتبنا بالفعل، ليس من الممكن دائمًا تفويض الوصول إلى الحساب المطلوب على الموقع.
لإنشاء آلية عالمية لاختيار حساب من المواقع، كان علينا إضافة طريقة إلى واجهة برمجة تطبيقات الموصلات التي تُرجع مخطط JSON، والذي يتم تقديمه في نموذج باستخدام مكون JSONEditor المعدل. وبهذه الطريقة، تمكن المستخدمون من تحديد الحسابات التي سيتم تنزيل البيانات منها.
للامتثال لحدود الطلب الموجودة على المواقع، نقوم بدمج طلبات الإعدادات ضمن رمز مميز واحد، ولكن يمكننا معالجة الرموز المميزة المختلفة بالتوازي.
لقد اخترنا MongoDB كمخزن للبيانات المحملة لكل من تطبيق الويب والموصلات، مما سمح لنا بعدم القلق كثيرًا بشأن بنية البيانات في المراحل الأولى من التطوير، عندما يتغير نموذج كائن التطبيق كل يومين.
سرعان ما اكتشفنا أنه لا تتناسب جميع البيانات بشكل جيد مع MongoDB، على سبيل المثال، من الملائم أكثر تخزين الإحصائيات اليومية في قاعدة بيانات علائقية. لذلك، بالنسبة للموصلات التي تكون بنية بياناتها أكثر ملاءمة لقاعدة بيانات علائقية، بدأنا في استخدام PostgreSQL أو MS SQL Server كمخزن.
لقد أتاحت لنا البنية والتقنيات المختارة بناء منتج D1.Digital وإطلاقه بسرعة نسبية. على مدار عامين من تطوير المنتجات، قمنا بتطوير 23 رابطًا للمواقع، واكتسبنا خبرة لا تقدر بثمن في العمل مع واجهات برمجة التطبيقات التابعة لجهات خارجية، وتعلمنا تجنب مخاطر المواقع المختلفة، والتي كان لكل منها موقعه الخاص، وساهمنا في تطوير واجهة برمجة التطبيقات لما لا يقل عن 3 المواقع، وتنزيل المعلومات تلقائيًا لما يقرب من 15 حملة ولأكثر من 000 موضع، وجمعت الكثير من التعليقات من المستخدمين حول تشغيل المنتج وتمكنت من تغيير العملية الرئيسية للمنتج عدة مرات، بناءً على هذه التعليقات.
بنية الحل 2.0
لقد مرت سنتان منذ بداية التطوير D1.رقمي. أدت الزيادة المستمرة في الحمل على النظام وظهور المزيد والمزيد من مصادر البيانات الجديدة إلى الكشف تدريجياً عن مشاكل في بنية الحلول الحالية.
المشكلة الأولى تتعلق بكمية البيانات التي يتم تنزيلها من المواقع. لقد واجهنا حقيقة أن جمع وتحديث جميع البيانات الضرورية من أكبر المواقع بدأ يستغرق الكثير من الوقت. على سبيل المثال، يستغرق جمع البيانات من نظام الإعلانات AdRiver، الذي نقوم من خلاله بتتبع الإحصائيات لمعظم المواضع، حوالي 12 ساعة.
لحل هذه المشكلة، بدأنا باستخدام جميع أنواع التقارير لتنزيل البيانات من المواقع، ونحاول تطوير واجهة برمجة التطبيقات (API) الخاصة بها مع المواقع بحيث تلبي سرعة عملها احتياجاتنا، وموازاة تنزيل البيانات قدر الإمكان.
هناك مشكلة أخرى تتعلق بمعالجة البيانات التي تم تنزيلها. الآن، عند وصول إحصائيات المواضع الجديدة، يتم إطلاق عملية متعددة المراحل لإعادة حساب المقاييس، والتي تتضمن تحميل البيانات الأولية، وحساب المقاييس المجمعة لكل موقع، ومقارنة البيانات من مصادر مختلفة مع بعضها البعض، وحساب مقاييس التلخيص للحملة. يؤدي هذا إلى تحميل كبير على تطبيق الويب الذي يقوم بجميع العمليات الحسابية. عدة مرات، أثناء عملية إعادة الحساب، استهلك التطبيق كل الذاكرة الموجودة على الخادم، حوالي 10-15 جيجابايت، مما كان له التأثير الأكثر ضررًا على عمل المستخدمين مع النظام.
أدت المشاكل التي تم تحديدها والخطط الطموحة لمواصلة تطوير المنتج إلى الحاجة إلى إعادة النظر في بنية التطبيق.
لقد بدأنا بالموصلات.
لقد لاحظنا أن جميع الموصلات تعمل وفقًا لنفس النموذج، لذلك قمنا ببناء إطار عمل لخط الأنابيب لإنشاء موصل، ما عليك سوى برمجة منطق الخطوات، والباقي كان عالميًا. إذا كان الموصل يحتاج إلى تحسين، فإننا ننقله على الفور إلى إطار عمل جديد في نفس الوقت الذي يتم فيه تحسين الموصل.
وفي الوقت نفسه، بدأنا في نشر الموصلات إلى Docker وKubernetes.
لقد خططنا للانتقال إلى Kubernetes لفترة طويلة، وقمنا بتجربة إعدادات CI/CD، لكننا بدأنا في التحرك فقط عندما بدأ موصل واحد، بسبب خطأ، في استهلاك أكثر من 20 جيجابايت من الذاكرة على الخادم، مما أدى عمليًا إلى قتل العمليات الأخرى . أثناء التحقيق، تم نقل الموصل إلى مجموعة Kubernetes، حيث بقي في النهاية، حتى بعد إصلاح الخطأ.
وسرعان ما أدركنا أن Kubernetes كان ملائمًا، وفي غضون ستة أشهر قمنا بنقل 7 موصلات ووكيل الموصلات، التي تستهلك معظم الموارد، إلى مجموعة الإنتاج.
بعد الروابط، قررنا تغيير بنية بقية التطبيق.
كانت المشكلة الرئيسية هي أن البيانات تأتي من الموصلات إلى الوكلاء على دفعات كبيرة، ثم تصل إلى DANBoID ويتم إرسالها إلى تطبيق الويب المركزي للمعالجة. نظرًا للعدد الكبير من عمليات إعادة حساب المقاييس، يوجد حمل كبير على التطبيق.
كما ثبت أيضًا أنه من الصعب جدًا مراقبة حالة مهام جمع البيانات الفردية والإبلاغ عن الأخطاء التي تحدث داخل الموصلات إلى تطبيق ويب مركزي حتى يتمكن المستخدمون من رؤية ما كان يحدث ولماذا لم يتم جمع البيانات.
لحل هذه المشاكل، قمنا بتطوير الهندسة المعمارية 2.0.
يتمثل الاختلاف الرئيسي بين الإصدار الجديد من البنية في أنه بدلاً من Web API، نستخدم RabbitMQ ومكتبة MassTransit لتبادل الرسائل بين الخدمات. للقيام بذلك، كان علينا إعادة كتابة Connectors Proxy بالكامل تقريبًا، مما جعله Connectors Hub. تم تغيير الاسم لأن الدور الرئيسي للخدمة لم يعد في إعادة توجيه الطلبات إلى الموصلات وإعادتها، ولكن في إدارة مجموعة المقاييس من الموصلات.
من تطبيق الويب المركزي، قمنا بفصل المعلومات المتعلقة بالمواضع والإحصائيات من المواقع إلى خدمات منفصلة، مما جعل من الممكن التخلص من عمليات إعادة الحساب غير الضرورية وتخزين الإحصائيات المحسوبة والمجمعة فقط على مستوى المواضع. لقد قمنا أيضًا بإعادة كتابة وتحسين منطق حساب الإحصائيات الأساسية بناءً على البيانات الأولية.
وفي الوقت نفسه، نقوم بترحيل جميع الخدمات والتطبيقات إلى Docker وKubernetes لجعل الحل أسهل في التوسع وأكثر ملاءمة للإدارة.
اين نحن الان
منتج إثبات المفهوم المعماري 2.0 D1.رقمي جاهز ويعمل في بيئة اختبار مع مجموعة محدودة من الموصلات. كل ما تبقى عليك فعله هو إعادة كتابة 20 رابطًا آخر إلى منصة جديدة، واختبار تحميل البيانات بشكل صحيح وحساب جميع المقاييس بشكل صحيح، وطرح التصميم بالكامل في مرحلة الإنتاج.
في الواقع، ستحدث هذه العملية تدريجيًا وسيتعين علينا ترك التوافق مع واجهات برمجة التطبيقات القديمة للحفاظ على عمل كل شيء.
تتضمن خططنا الفورية تطوير موصلات جديدة، والتكامل مع الأنظمة الجديدة وإضافة مقاييس إضافية إلى مجموعة البيانات التي تم تنزيلها من المواقع المتصلة وأنظمة الخدمة.
ونخطط أيضًا لنقل جميع التطبيقات، بما في ذلك تطبيق الويب المركزي، إلى Docker وKubernetes. سيؤدي ذلك، إلى جانب البنية الجديدة، إلى تبسيط عملية نشر الموارد المستهلكة ومراقبتها والتحكم فيها بشكل كبير.
فكرة أخرى هي تجربة اختيار قاعدة البيانات لتخزين الإحصائيات، والتي يتم تخزينها حاليًا في MongoDB. لقد قمنا بالفعل بنقل العديد من الروابط الجديدة إلى قواعد بيانات SQL، ولكن الفرق هناك غير ملحوظ تقريبًا، وبالنسبة للإحصائيات المجمعة يوميًا، والتي يمكن طلبها لفترة تعسفية، يمكن أن يكون الربح خطيرًا للغاية.
بشكل عام، الخطط عظيمة، فلنمضي قدمًا :)
مؤلفو المقال R&D Dentsu Aegis Network روسيا: جورجي أوستابينكو ()، ميخائيل كوتسيك ()
المصدر: www.habr.com