نحوه جمع‌آوری داده‌های کمپین‌های تبلیغاتی از سایت‌های آنلاین (مسیر خاردار به محصول)

به نظر می رسد حوزه تبلیغات آنلاین باید تا حد امکان از نظر تکنولوژی پیشرفته و خودکار باشد. البته، زیرا غول ها و متخصصان در زمینه خود مانند Yandex، Mail.Ru، Google و Facebook در آنجا کار می کنند. اما، همانطور که مشخص شد، هیچ محدودیتی برای کمال وجود ندارد و همیشه چیزی برای خودکار کردن وجود دارد.

منبع

گروه ارتباطات Dentsu Aegis Network روسیه بزرگترین بازیگر در بازار تبلیغات دیجیتال است و به طور فعال در فناوری سرمایه گذاری می کند و سعی در بهینه سازی و خودکارسازی فرآیندهای تجاری خود دارد. یکی از مشکلات حل نشده بازار تبلیغات آنلاین، جمع آوری آمار کمپین های تبلیغاتی از بسترهای مختلف اینترنتی است. راه حل این مشکل در نهایت منجر به ایجاد یک محصول شد D1. دیجیتال (بخوانید به عنوان DiVan)، که ما می خواهیم در مورد توسعه آن صحبت کنیم.

چرا؟

1. در زمان شروع پروژه، حتی یک محصول آماده در بازار وجود نداشت که مشکل خودکارسازی جمع آوری آمار کمپین های تبلیغاتی را حل کند. این بدان معناست که هیچ کس جز خودمان نیازهای ما را برآورده نخواهد کرد.

خدماتی مانند Improvado، Roistat، Supermetrics، SegmentStream یکپارچه‌سازی با پلتفرم‌ها، شبکه‌های اجتماعی و Google Anaalitycs را ارائه می‌دهند و همچنین امکان ساخت داشبوردهای تحلیلی را برای تجزیه و تحلیل راحت و کنترل کمپین‌های تبلیغاتی فراهم می‌کنند. قبل از شروع توسعه محصول خود، سعی کردیم از برخی از این سیستم ها برای جمع آوری داده ها از سایت ها استفاده کنیم، اما متاسفانه نتوانستند مشکلات ما را حل کنند.

مشکل اصلی این بود که محصولات آزمایش شده بر اساس منابع داده، نمایش آمار مکان‌یابی بر اساس سایت بودند و امکان جمع‌آوری آمار کمپین‌های تبلیغاتی را نداشتند. این رویکرد به ما اجازه نمی داد آمار سایت های مختلف را در یک مکان ببینیم و وضعیت کمپین را به طور کلی تجزیه و تحلیل کنیم.

عامل دیگر این بود که در مراحل اولیه این محصولات بازار غربی را هدف قرار می دادند و از ادغام با سایت های روسی پشتیبانی نمی کردند. و برای آن دسته از سایت‌هایی که ادغام با آن‌ها اجرا شد، تمام معیارهای لازم همیشه با جزئیات کافی دانلود نمی‌شد و ادغام همیشه راحت و شفاف نبود، به خصوص زمانی که لازم بود چیزی را دریافت کنید که در رابط سیستم وجود ندارد.
به طور کلی، ما تصمیم گرفتیم که با محصولات شخص ثالث سازگار نشویم، اما شروع به توسعه خودمان کردیم.

2. بازار تبلیغات آنلاین سال به سال در حال رشد است و در سال 2018 از نظر بودجه تبلیغاتی، به طور سنتی بزرگترین بازار تبلیغات تلویزیونی را پشت سر گذاشت. بنابراین یک مقیاس وجود دارد.

3. بر خلاف بازار تبلیغات تلویزیونی که فروش تبلیغات تجاری در انحصار است، تعداد زیادی از صاحبان موجودی تبلیغات در اندازه های مختلف با حساب های تبلیغاتی خود در اینترنت فعالیت می کنند. از آنجایی که یک کمپین تبلیغاتی، به طور معمول، در چندین سایت به طور همزمان اجرا می شود، برای درک وضعیت کمپین تبلیغاتی، لازم است گزارش هایی از همه سایت ها جمع آوری شده و آنها در یک گزارش بزرگ ترکیب شوند که تصویر کامل را نشان دهد. این بدان معنی است که پتانسیل برای بهینه سازی وجود دارد.

4. به نظر ما این بود که صاحبان موجودی تبلیغات در اینترنت از قبل زیرساخت جمع آوری آمار و نمایش آن در حساب های تبلیغاتی را دارند و می توانند برای این داده ها یک API تهیه کنند. این بدان معناست که اجرای آن از نظر فنی امکان پذیر است. بیایید فوراً بگوییم که معلوم شد چندان ساده نیست.

در مجموع همه پیش نیازهای اجرای پروژه برای ما مشخص بود و دویدیم تا پروژه را زنده کنیم...

طرح بزرگ

برای شروع، ما چشم اندازی از یک سیستم ایده آل شکل دادیم:

• کمپین های تبلیغاتی از سیستم شرکتی 1C باید به طور خودکار با نام، دوره، بودجه و مکان های خود در سیستم عامل های مختلف در آن بارگذاری شوند.
• برای هر قرار دادن در یک کمپین تبلیغاتی، تمام آمارهای ممکن باید به طور خودکار از سایت هایی که قرارگیری در آن انجام می شود بارگیری شود، مانند تعداد نمایش ها، کلیک ها، بازدیدها و غیره.
• برخی از کمپین های تبلیغاتی با استفاده از نظارت شخص ثالث توسط سیستم های به اصطلاح تبلیغاتی مانند Adriver، Weborama، DCM و غیره ردیابی می شوند. همچنین یک اینترنت متر صنعتی در روسیه وجود دارد - شرکت Mediascope. طبق برنامه ما، داده های نظارت مستقل و صنعتی نیز باید به طور خودکار در کمپین های تبلیغاتی مربوطه بارگذاری شود.
• بیشتر کمپین های تبلیغاتی در اینترنت با هدف انجام اقدامات هدف خاصی (خرید، تماس، ثبت نام برای تست درایو و غیره) انجام می شوند، که با استفاده از گوگل آنالیتیکس ردیابی می شوند، و آماری که برای درک وضعیت کمپین و همچنین وضعیت کمپین مهم است. باید در ابزار ما بارگذاری شود.

اولین پانکک یکپارچه است

با توجه به تعهد ما به اصول انعطاف پذیر توسعه نرم افزار (چابک، همه چیز)، تصمیم گرفتیم ابتدا یک MVP توسعه دهیم و سپس به سمت هدف مورد نظر به طور مکرر حرکت کنیم.
ما تصمیم گرفتیم که MVP را بر اساس محصول خود بسازیم DANBo (هیئت شبکه Dentsu Aegis)، که یک برنامه وب با اطلاعات کلی در مورد کمپین های تبلیغاتی مشتریان ما است.

برای MVP، پروژه تا حد امکان از نظر اجرا ساده شد. ما لیست محدودی از پلتفرم ها را برای ادغام انتخاب کرده ایم. اینها پلتفرم‌های اصلی، مانند Yandex.Direct، Yandex.Display، RB.Mail، MyTarget، Adwords، DBM، VK، FB و سیستم‌های تبلیغاتی اصلی Adriver و Weborama بودند.

برای دسترسی به آمار سایت ها از طریق API، از یک حساب کاربری استفاده کردیم. مدیر گروه مشتری که می‌خواست از جمع‌آوری خودکار آمار در یک کمپین تبلیغاتی استفاده کند، ابتدا باید دسترسی به کمپین‌های تبلیغاتی لازم در سایت‌ها را به حساب پلتفرم واگذار می‌کرد.

بعدی کاربر سیستم است DANBo باید فایلی با فرمت خاصی در سیستم اکسل آپلود می کرد که حاوی تمام اطلاعات مربوط به مکان (کمپین تبلیغاتی، پلت فرم، قالب، دوره قرارگیری، شاخص های برنامه ریزی شده، بودجه و غیره) و شناسه های کمپین های تبلیغاتی مربوطه در سایت ها و شمارنده ها در سیستم های تبلیغاتی

صراحتاً وحشتناک به نظر می رسید:

داده‌های دانلود شده در یک پایگاه داده ذخیره می‌شوند و سپس سرویس‌های جداگانه شناسه‌های کمپین را در سایت‌ها از آن‌ها جمع‌آوری کرده و آمار مربوط به آن‌ها را دانلود می‌کنند.

برای هر سایت، یک سرویس ویندوز جداگانه نوشته شده بود که یک بار در روز به یک حساب سرویس در API سایت می رفت و آمار مربوط به شناسه های کمپین مشخص را دانلود می کرد. در مورد سیستم های تبلیغاتی نیز همین اتفاق افتاد.

داده های دانلود شده در رابط به شکل یک داشبورد سفارشی کوچک نمایش داده می شود:

به طور غیرمنتظره ای برای ما، MVP شروع به کار کرد و شروع به دانلود آمار فعلی کمپین های تبلیغاتی در اینترنت کرد. ما سیستم را روی چندین مشتری پیاده‌سازی کردیم، اما هنگام تلاش برای مقیاس‌بندی، با مشکلات جدی مواجه شدیم:

• مشکل اصلی پیچیدگی آماده سازی داده ها برای بارگذاری در سیستم بود. همچنین، قبل از بارگذاری، داده‌های قرارگیری باید به یک فرمت کاملاً ثابت تبدیل می‌شد. لازم بود در فایل دانلودی شناسه های موجودیت از سایت های مختلف درج شود. ما با این واقعیت روبرو هستیم که برای کاربرانی که از نظر فنی آموزش ندیده اند توضیح دادن این شناسه ها در کجای سایت و کجای فایل باید وارد شوند بسیار دشوار است. با توجه به تعداد کارمندان دپارتمان‌هایی که کمپین‌هایی را در سایت‌ها اجرا می‌کنند و گردش مالی، این امر منجر به حمایت عظیمی از طرف ما شد که ما مطلقاً از آن راضی نبودیم.
• مشکل دیگر این بود که همه پلتفرم های تبلیغاتی مکانیسم هایی برای واگذاری دسترسی به کمپین های تبلیغاتی به حساب های دیگر نداشتند. اما حتی اگر مکانیزم تفویض اختیار در دسترس بود، همه تبلیغ‌کنندگان حاضر به دسترسی به کمپین‌های خود به حساب‌های شخص ثالث نبودند.
• یک عامل مهم خشم کاربران از این واقعیت بود که تمام شاخص های برنامه ریزی شده و جزئیات قرارگیری که قبلاً وارد سیستم حسابداری 1C ما شده اند، باید دوباره وارد شوند. DANBo.

این به ما این ایده را داد که منبع اصلی اطلاعات در مورد مکان‌یابی باید سیستم 1C ما باشد، که تمام داده‌ها به طور دقیق و به موقع وارد می‌شوند (نکته در اینجا این است که فاکتورها بر اساس داده‌های 1C تولید می‌شوند، بنابراین ورود صحیح داده‌ها به 1C یک اولویت برای همه KPI است). اینگونه بود که مفهوم جدیدی از سیستم پدید آمد...

مفهوم

اولین کاری که تصمیم گرفتیم انجام دهیم این بود که سیستم جمع آوری آمار کمپین های تبلیغاتی در اینترنت را به یک محصول جداگانه جدا کنیم - D1. دیجیتال.

در مفهوم جدید، ما تصمیم گرفتیم تا بارگذاری کنیم D1. دیجیتال اطلاعات مربوط به کمپین‌های تبلیغاتی و قرارگیری‌های درون آن‌ها را از 1C، و سپس آمار را از سایت‌ها و سیستم‌های AdServing به این مکان‌ها ارائه کنید. قرار بود این کار به طور قابل توجهی زندگی کاربران را ساده کند (و طبق معمول کار بیشتری را به توسعه دهندگان اضافه کند) و میزان پشتیبانی را کاهش دهد.

اولین مشکلی که با آن مواجه شدیم ماهیت سازمانی داشت و مربوط به این واقعیت بود که نتوانستیم کلید یا علامتی پیدا کنیم که به وسیله آن بتوانیم موجودیت های سیستم های مختلف را با کمپین ها و مکان های 1C مقایسه کنیم. واقعیت این است که فرآیند در شرکت ما به گونه ای طراحی شده است که کمپین های تبلیغاتی توسط افراد مختلف (مدیا برنامه ریزان، خرید و ...) وارد سیستم های مختلف می شود.

برای حل این مشکل، ما مجبور شدیم یک کلید هش منحصربه‌فرد به نام DANBoID اختراع کنیم که موجودیت‌های موجود در سیستم‌های مختلف را به هم مرتبط می‌کند و می‌تواند به راحتی و به‌طور منحصربه‌فرد در مجموعه‌های داده دانلود شده شناسایی شود. این شناسه در سیستم داخلی 1C برای هر مکان جداگانه تولید می شود و به کمپین ها، مکان ها و شمارنده ها در همه سایت ها و در همه سیستم های AdServing منتقل می شود. اجرای تمرین قرار دادن DANBoID در همه مکان ها مدتی طول کشید، اما ما موفق به انجام آن شدیم :)

سپس متوجه شدیم که همه سایت‌ها دارای API برای جمع‌آوری خودکار آمار نیستند و حتی آن‌هایی که دارای API هستند، تمام داده‌های لازم را بر نمی‌گردانند.

در این مرحله، تصمیم گرفتیم لیست پلتفرم‌های یکپارچه‌سازی را به میزان قابل توجهی کاهش دهیم و روی پلتفرم‌های اصلی که در اکثریت قریب به اتفاق کمپین‌های تبلیغاتی درگیر هستند، تمرکز کنیم. این لیست شامل تمام بزرگترین بازیگران بازار تبلیغات (Google، Yandex، Mail.ru)، شبکه های اجتماعی (VK، Facebook، Twitter)، سیستم های اصلی AdServing و تجزیه و تحلیل (DCM، Adriver، Weborama، Google Analytics) و سایر سیستم عامل ها است.

اکثر سایت هایی که انتخاب کردیم دارای یک API بودند که معیارهای مورد نیاز ما را ارائه می کرد. در مواردی که API وجود نداشت یا حاوی داده‌های لازم نبود، از گزارش‌هایی که روزانه به ایمیل دفتر خود ارسال می‌شد برای بارگیری داده‌ها استفاده می‌کردیم (در برخی از سیستم‌ها امکان پیکربندی چنین گزارش‌هایی وجود دارد، در برخی دیگر ما بر روی توسعه چنین گزارش‌هایی توافق کردیم. برای ما).

هنگام تجزیه و تحلیل داده ها از سایت های مختلف، متوجه شدیم که سلسله مراتب موجودیت ها در سیستم های مختلف یکسان نیست. علاوه بر این، اطلاعات باید با جزئیات متفاوت از سیستم های مختلف دانلود شوند.

برای حل این مشکل، مفهوم SubDANBoID توسعه داده شد. ایده SubDANBoID بسیار ساده است، ما موجودیت اصلی کمپین را در سایت با DANBoID تولید شده علامت گذاری می کنیم و همه موجودیت های تو در تو را با شناسه های سایت منحصر به فرد آپلود می کنیم و SubDANBoID را طبق اصل DANBoID + شناسه سطح اول تشکیل می دهیم. موجودیت تودرتو + شناسه موجودیت تودرتو سطح دوم +... این رویکرد به ما امکان می دهد تا کمپین های تبلیغاتی را در سیستم های مختلف به هم متصل کرده و آمار دقیق آنها را دانلود کنیم.

همچنین باید مشکل دسترسی به کمپین ها در پلتفرم های مختلف را حل می کردیم. همانطور که در بالا نوشتیم، مکانیسم واگذاری دسترسی به یک کمپین به یک حساب فنی جداگانه همیشه قابل اجرا نیست. بنابراین، ما مجبور شدیم زیرساختی برای مجوز خودکار از طریق OAuth با استفاده از توکن ها و مکانیسم هایی برای به روز رسانی این توکن ها ایجاد کنیم.

در ادامه مقاله سعی خواهیم کرد تا معماری راه حل و جزئیات فنی پیاده سازی را با جزئیات بیشتری شرح دهیم.

معماری راه حل 1.0

هنگام شروع اجرای یک محصول جدید، متوجه شدیم که بلافاصله باید امکان اتصال سایت های جدید را فراهم کنیم، بنابراین تصمیم گرفتیم مسیر معماری میکروسرویس را دنبال کنیم.

هنگام طراحی معماری، ما کانکتورها را به تمام سیستم های خارجی - 1C، پلتفرم های تبلیغاتی و سیستم های تبلیغاتی - به سرویس های جداگانه جدا کردیم.
ایده اصلی این است که همه کانکتورهای سایت ها API یکسانی دارند و آداپتورهایی هستند که API سایت را به یک رابط مناسب برای ما می آورند.

در مرکز محصول ما یک برنامه وب قرار دارد که یکپارچه است که به گونه ای طراحی شده است که می توان آن را به راحتی در خدمات جدا کرد. این اپلیکیشن وظیفه پردازش داده های دانلود شده، جمع آوری آمار از سیستم های مختلف و ارائه آنها به کاربران سیستم را بر عهده دارد.

برای برقراری ارتباط بین کانکتورها و برنامه وب، باید یک سرویس اضافی ایجاد می‌کردیم که به آن Connector Proxy می‌گفتیم. این توابع سرویس Discovery و Task Scheduler را انجام می دهد. این سرویس هر شب وظایف جمع آوری داده را برای هر کانکتور اجرا می کند. نوشتن یک لایه سرویس آسان تر از اتصال یک کارگزار پیام بود و برای ما مهم بود که در سریع ترین زمان ممکن به نتیجه برسیم.

برای سادگی و سرعت توسعه، ما همچنین تصمیم گرفتیم که تمام سرویس ها Web API باشند. این امر امکان گردآوری سریع یک اثبات مفهومی را فراهم کرد و تأیید کرد که کل طرح کار می کند.

یک کار جداگانه و نسبتاً پیچیده تنظیم دسترسی برای جمع‌آوری داده‌ها از حساب‌های مختلف بود که همانطور که تصمیم گرفتیم باید توسط کاربران از طریق رابط وب انجام شود. این شامل دو مرحله جداگانه است: ابتدا کاربر یک رمز برای دسترسی به حساب از طریق OAuth اضافه می کند و سپس مجموعه ای از داده ها را برای مشتری از یک حساب خاص پیکربندی می کند. دریافت توکن از طریق OAuth ضروری است، زیرا همانطور که قبلاً نوشتیم، همیشه امکان واگذاری دسترسی به حساب مورد نظر در سایت وجود ندارد.

برای ایجاد یک مکانیسم جهانی برای انتخاب یک حساب از سایت‌ها، باید روشی را به API رابط‌ها اضافه می‌کردیم که طرحواره JSON را برمی‌گرداند، که با استفاده از یک مؤلفه اصلاح‌شده JSONEditor به شکلی رندر می‌شود. به این ترتیب، کاربران می‌توانستند حساب‌هایی را انتخاب کنند که از آن‌ها داده‌ها را دانلود کنند.

برای رعایت محدودیت‌های درخواستی که در سایت‌ها وجود دارد، درخواست‌های تنظیمات را در یک توکن ترکیب می‌کنیم، اما می‌توانیم توکن‌های مختلف را به صورت موازی پردازش کنیم.

ما MongoDB را به‌عنوان ذخیره‌سازی برای داده‌های بارگذاری شده هم برای برنامه وب و هم برای رابط‌ها انتخاب کردیم، که به ما اجازه داد در مراحل اولیه توسعه، زمانی که مدل شی برنامه یک روز در میان تغییر می‌کند، زیاد نگران ساختار داده نباشیم.

به زودی متوجه شدیم که همه داده ها به خوبی در MongoDB جا نمی شوند و به عنوان مثال، ذخیره آمار روزانه در یک پایگاه داده رابطه ای راحت تر است. بنابراین، برای اتصال دهنده هایی که ساختار داده آنها برای پایگاه داده رابطه ای مناسب تر است، ما شروع به استفاده از PostgreSQL یا MS SQL Server به عنوان ذخیره کردیم.

معماری و فناوری های انتخاب شده به ما امکان ساخت و راه اندازی محصول D1.Digital را نسبتاً سریع داد. در طی دو سال توسعه محصول، ما 23 اتصال دهنده به سایت ها توسعه دادیم، تجربه ارزشمندی در کار با API های شخص ثالث به دست آوردیم، یاد گرفتیم که از دام های سایت های مختلف که هرکدام مختص به خود بودند اجتناب کنیم، به توسعه API حداقل 3 کمک کردیم. سایت‌ها، اطلاعات تقریباً 15 کمپین و بیش از 000 مکان را به طور خودکار دانلود کردند، بازخوردهای زیادی از کاربران در مورد عملکرد محصول جمع‌آوری کردند و بر اساس این بازخورد موفق شدند چندین بار روند اصلی محصول را تغییر دهند.

معماری راه حل 2.0

دو سال از شروع توسعه می گذرد D1. دیجیتال. افزایش مداوم بار بر روی سیستم و ظهور هر چه بیشتر منابع داده جدید به تدریج مشکلاتی را در معماری راه حل موجود آشکار کرد.

اولین مشکل مربوط به حجم داده های دانلود شده از سایت هاست. ما با این واقعیت روبرو بودیم که جمع آوری و به روز رسانی تمام داده های لازم از بزرگترین سایت ها زمان زیادی را می برد. برای مثال، جمع‌آوری داده‌ها از سیستم تبلیغات AdRiver، که با آن آمار اکثر مکان‌ها را دنبال می‌کنیم، حدود 12 ساعت طول می‌کشد.

برای حل این مشکل، ما شروع به استفاده از انواع گزارش ها برای دانلود داده ها از سایت ها کردیم، سعی می کنیم API آنها را همراه با سایت ها توسعه دهیم تا سرعت عملکرد آن نیازهای ما را برآورده کند و دانلود داده ها را تا حد امکان موازی سازی کنیم.

مشکل دیگر مربوط به پردازش داده های دانلود شده است. در حال حاضر، زمانی که آمار قرارگیری جدید وارد می‌شود، یک فرآیند چند مرحله‌ای برای محاسبه مجدد معیارها راه‌اندازی می‌شود که شامل بارگذاری داده‌های خام، محاسبه معیارهای جمع‌آوری شده برای هر سایت، مقایسه داده‌های منابع مختلف با یکدیگر، و محاسبه معیارهای خلاصه برای کمپین است. این باعث می شود که برنامه تحت وب که تمام محاسبات را انجام می دهد، بار زیادی داشته باشد. چندین بار در طول فرآیند محاسبه مجدد، برنامه تمام حافظه سرور را در حدود 10 تا 15 گیگابایت مصرف کرد که بیشترین تأثیر را بر کار کاربران با سیستم داشت.

مشکلات شناسایی شده و برنامه های بلندپروازانه برای توسعه بیشتر محصول ما را به نیاز به بازنگری در معماری برنامه سوق داد.

ما با کانکتورها شروع کردیم.
ما متوجه شدیم که همه کانکتورها طبق یک مدل کار می کنند، بنابراین یک چارچوب خط لوله ایجاد کردیم که در آن برای ایجاد یک کانکتور فقط باید منطق مراحل را برنامه ریزی کنید، بقیه موارد جهانی بود. اگر برخی از کانکتورها نیاز به بهبود دارند، بلافاصله همزمان با بهبود کانکتور، آن را به یک چارچوب جدید منتقل می کنیم.

در همان زمان، ما شروع به استقرار کانکتورها برای Docker و Kubernetes کردیم.
ما برای مدت طولانی انتقال به Kubernetes را برنامه ریزی کردیم، تنظیمات CI/CD را آزمایش کردیم، اما تنها زمانی شروع به حرکت کردیم که یکی از کانکتورها، به دلیل یک خطا، شروع به خوردن بیش از 20 گیگابایت حافظه روی سرور کرد و عملاً سایر فرآیندها را از بین برد. . در طول بررسی، کانکتور به یک خوشه Kubernetes منتقل شد، جایی که در نهایت حتی پس از رفع خطا باقی ماند.

خیلی سریع متوجه شدیم که Kubernetes راحت است و در عرض شش ماه 7 کانکتور و Connectors Proxy را که بیشترین منابع را مصرف می کنند به خوشه تولید منتقل کردیم.

به دنبال کانکتورها، تصمیم گرفتیم معماری بقیه برنامه ها را تغییر دهیم.
مشکل اصلی این بود که داده ها از اتصال دهنده ها به پراکسی ها در دسته های بزرگ می آیند و سپس به DANBoID ضربه می زنند و برای پردازش به برنامه وب مرکزی ارسال می شوند. به دلیل تعداد زیاد محاسبات مجدد معیارها، بار زیادی روی برنامه وجود دارد.

همچنین نظارت بر وضعیت مشاغل جمع آوری داده های فردی و گزارش خطاهای رخ داده در رابط های یک برنامه وب مرکزی بسیار دشوار بود تا کاربران بتوانند ببینند چه اتفاقی می افتد و چرا داده ها جمع آوری نمی شوند.

برای حل این مشکلات، معماری 2.0 را توسعه دادیم.

تفاوت اصلی بین نسخه جدید معماری این است که به جای Web API از RabbitMQ و کتابخانه MassTransit برای تبادل پیام بین سرویس ها استفاده می کنیم. برای انجام این کار، مجبور شدیم Proxy Connectors را تقریباً به طور کامل بازنویسی کنیم و آن را به Connectors Hub تبدیل کنیم. این نام تغییر کرد زیرا نقش اصلی سرویس دیگر در ارسال درخواست‌ها به رابط‌ها و برگشت نیست، بلکه در مدیریت مجموعه معیارها از رابط‌ها است.

از برنامه وب مرکزی، ما اطلاعات مربوط به مکان‌ها و آمارها را از سایت‌ها به سرویس‌های جداگانه جدا کردیم، که این امکان را فراهم می‌کند که از محاسبات مجدد غیر ضروری خلاص شویم و فقط آمارهای محاسبه‌شده و جمع‌آوری‌شده از قبل را در سطح مکان‌یابی ذخیره کنیم. ما همچنین منطق محاسبه آمار پایه بر اساس داده های خام را بازنویسی و بهینه کردیم.

در عین حال، ما در حال انتقال همه سرویس‌ها و برنامه‌های کاربردی به Docker و Kubernetes هستیم تا مقیاس را آسان‌تر و مدیریت را راحت‌تر کنیم.

الان کجا هستیم

محصول معماری اثبات مفهوم 2.0 D1. دیجیتال آماده و کار در یک محیط آزمایشی با مجموعه محدودی از کانکتورها. تنها کاری که باید انجام دهید این است که 20 کانکتور دیگر را به یک پلتفرم جدید بازنویسی کنید، آزمایش کنید که داده ها به درستی بارگیری شده اند و تمام معیارها به درستی محاسبه شده اند و کل طرح را در مرحله تولید قرار دهید.

در واقع، این فرآیند به تدریج اتفاق می‌افتد و ما باید سازگاری با APIهای قدیمی را ترک کنیم تا همه چیز کار کند.

برنامه های فوری ما شامل توسعه اتصال دهنده های جدید، ادغام با سیستم های جدید و افزودن معیارهای اضافی به مجموعه داده های دانلود شده از سایت های متصل و سیستم های تبلیغاتی است.

همچنین قصد داریم تمامی اپلیکیشن ها از جمله وب اپلیکیشن مرکزی را به Docker و Kubernetes منتقل کنیم. در ترکیب با معماری جدید، این امر به طور قابل توجهی استقرار، نظارت و کنترل منابع مصرف شده را ساده می کند.

ایده دیگر آزمایش با انتخاب پایگاه داده برای ذخیره آمار است که در حال حاضر در MongoDB ذخیره می شود. ما قبلاً چندین کانکتور جدید را به پایگاه‌های داده SQL منتقل کرده‌ایم، اما در آنجا تفاوت تقریباً قابل توجه نیست و برای آمارهای انبوه در روز که می‌توان برای یک دوره دلخواه درخواست کرد، سود می‌تواند کاملاً جدی باشد.

به طور کلی، برنامه ها بزرگ هستند، بیایید ادامه دهیم :)

نویسندگان مقاله R&D Dentsu Aegis Network روسیه: گئورگی اوستاپنکو (shmiigaa)، میخائیل کوتسیک (hitexx)

منبع: www.habr.com