Кыязы, онлайн-жарнама чөйрөсү мүмкүн болушунча технологиялык жактан өнүккөн жана автоматташтырылган болушу керек. Албетте, анткени ал жерде Яндекс, Mail.Ru, Google жана Facebook сыяктуу алптар жана өз тармагынын адистери иштешет. Бирок, белгилүү болгондой, кемчиликсиздиктин чеги жок жана ар дайым автоматташтырылган нерсе бар.
Байланыш тобу Dentsu Aegis Network Россия санариптик жарнак рыногундагы эң ири оюнчу болуп саналат жана технологияга жигердүү инвестиция салып, анын бизнес процесстерин оптималдаштырууга жана автоматташтырууга аракет кылууда. Интернет-жарнак рыногунун чечилбеген көйгөйлөрүнүн бири - ар кандай интернет платформаларынан жарнамалык кампаниялар боюнча статистикалык маалыматтарды чогултуу милдети. Бул маселенин чечилиши акыры буюмдун пайда болушуна алып келди D1.Digital (DiVan катары окулат), анын өнүгүшү жөнүндө сөз кылгыбыз келет.
Эмне үчүн?
1. Долбоор башталган учурда рынокто жарнамалык кампаниялар боюнча статистикалык маалыматтарды чогултууну автоматташтыруу маселесин чечкен бир дагы даяр продукция болгон эмес. Бул биздин муктаждыктарыбызды өзүбүздөн башка эч ким канааттандырбайт дегенди билдирет.
Improvado, Roistat, Supermetrics, SegmentStream сыяктуу кызматтар платформалар, социалдык тармактар жана Google Analytics менен интеграцияны сунуштайт, ошондой эле жарнамалык кампанияларды ыңгайлуу талдоо жана көзөмөлдөө үчүн аналитикалык такталарды түзүүгө мүмкүндүк берет. Продукциябызды иштеп чыгууну баштаганга чейин, биз сайттардан маалыматтарды чогултуу үчүн бул системалардын айрымдарын колдонууга аракет кылдык, бирок, тилекке каршы, алар биздин көйгөйлөрүбүздү чече алган жок.
Негизги көйгөй сыноодон өткөн өнүмдөр маалымат булактарына негизделип, сайттар боюнча жайгаштыруу статистикасын көрсөтүп, жарнамалык кампаниялар боюнча статистиканы бириктирүү мүмкүнчүлүгүн бербегендиги болду. Мындай ыкма ар кайсы сайттардын статистикасын бир жерден көрүүгө жана жалпы өнөктүктүн абалын анализдөөгө мүмкүндүк берген жок.
Дагы бир жагдай, баштапкы этапта продуктылар батыш рыногуна багытталган жана орус сайттары менен интеграцияны колдобогон. Ал эми интеграция ишке ашырылган сайттар үчүн бардык керектүү көрсөткүчтөр дайыма эле жетиштүү деталдар менен жүктөлгөн эмес жана интеграция дайыма эле ыңгайлуу жана ачык-айкын болгон эмес, айрыкча системанын интерфейсинде жок нерсени алуу зарыл болгондо.
Жалпысынан, биз үчүнчү тараптын өнүмдөрүнө көнүүнү чечпей, өзүбүздүн...
2. Интернет-жарнак рыногу жылдан жылга өсүп, 2018-жылы жарнамалык бюджеттин көлөмү боюнча салттуу эң чоң тележарнак рыногун басып өттү. Ошентип, бир тараза бар.
3. Коммерциялык жарнактарды сатуу монополизацияланган тележарнак рыногунан айырмаланып, интернетте өзүнүн жарнак эсептери менен иштеген ар кандай өлчөмдөгү жарнак инвентаризациясынын жеке ээлери көп. Жарнамалык кампания, эреже катары, бир эле учурда бир нече сайттарда жүргөндүктөн, жарнак кампаниясынын абалын түшүнүү үчүн, бардык сайттардан отчетторду чогултуу жана аларды бүтүндөй сүрөттү көрсөтө турган бир чоң отчетко бириктирүү керек. Бул оптималдаштыруу үчүн потенциал бар дегенди билдирет.
4. Бизге интернеттеги жарнак инвентаризациясынын ээлери статистиканы чогултуу жана аларды жарнамалык эсептерде көрсөтүү үчүн инфраструктурага ээ болуп көрүнгөн жана алар бул маалыматтар үчүн API бере алышат. Бул аны ишке ашырууга техникалык жактан мүмкүн экендигин билдирет. Бул анчалык жөнөкөй эмес болуп чыкты деп дароо айталы.
Дегеле долбоорду ишке ашыруунун бардык өбөлгөлөрү бизге ачык эле көрүнүп, долбоорду ишке ашыруу үчүн чуркадык...
Чоң план
Баштоо үчүн, биз идеалдуу системанын көрүнүшүн түздүк:
- 1С корпоративдик тутумунун жарнак кампаниялары автоматтык түрдө ага аталыштары, мөөнөттөрү, бюджеттери жана ар кандай платформаларда жайгаштырылышы менен жүктөлүшү керек.
- Жарнамалык кампаниянын алкагындагы ар бир жайгаштыруу үчүн бардык мүмкүн болгон статистикалар жайгаштыруу болуп жаткан сайттардан автоматтык түрдө жүктөлүп алынышы керек, мисалы, таасирлердин саны, чыкылдатуулар, көрүүлөр ж.б.
- Кээ бир жарнамалык кампаниялар Adriver, Weborama, DCM ж.б. Россияда өнөр жай интернет эсептегич да бар - Mediascope компаниясы. Биздин планга ылайык, көз карандысыз жана өнөр жай мониторингинин маалыматтары да автоматтык түрдө тиешелүү жарнамалык кампанияларга жүктөлүшү керек.
- Интернеттеги көпчүлүк жарнак кампаниялары белгилүү бир максаттуу аракеттерге (сатып алуу, чалуу, тесттик дискке жазылуу ж.б.) багытталган, алар Google Analytics аркылуу көзөмөлдөнөт жана алардын статистикасы кампаниянын статусун түшүнүү үчүн да маанилүү жана биздин куралга жүктөлүшү керек.
Жакшы ийгилик кийинки жолу
Программалык камсыздоону иштеп чыгуунун ийкемдүү принциптерине болгон берилгендигибизди эске алуу менен (апилдүүлүк, бардык нерсе) биз алгач MVP иштеп чыгууну чечтик, андан кийин итеративдик түрдө көздөгөн максатка карай жүрөбүз.
Биз продуктунун негизинде MVP түзүүнү чечтик DANBo (Dentsu Aegis Network Board), бул биздин кардарлардын жарнамалык кампаниялары жөнүндө жалпы маалымат камтылган веб-тиркеме.
MVP үчүн долбоор ишке ашыруу жагынан мүмкүн болушунча жөнөкөйлөштүрүлгөн. Биз интеграция үчүн платформалардын чектелген тизмесин тандап алдык. Бул Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB сыяктуу негизги платформалар жана Adriver жана Weborama негизги жарнамалоо системалары болгон.
API аркылуу сайттардагы статистикага кирүү үчүн, биз бир эсепти колдондук. Жарнамалык кампанияда статистиканы автоматтык түрдө чогултууну каалаган кардарлар тобунун менеджери адегенде сайттардагы керектүү жарнамалык кампанияларга кирүү мүмкүнчүлүгүн платформа эсебине өткөрүп бериши керек болчу.
Кийинки системанын колдонуучусу ДАНБо жайгаштыруу (жарнамалык кампания, платформа, формат, жайгаштыруу мезгили, пландаштырылган көрсөткүчтөр, бюджет ж. жарнамалоо системаларындагы сайттар жана эсептегичтер.
Чынын айтканда, коркунучтуу көрүндү:
Жүктөлгөн маалыматтар маалымат базасына сакталып, андан кийин өзүнчө кызматтар алардан сайттардагы кампаниянын идентификаторлорун чогултуп, алар боюнча статистиканы жүктөп алышкан.
Ар бир сайт үчүн өзүнчө Windows кызматы жазылган, ал күнүнө бир жолу сайттын API'синде бир кызмат эсебине кирип, көрсөтүлгөн өнөктүк идентификаторлору боюнча статистиканы жүктөп алган. Ошол эле нерсе жарнамалоо системалары менен болгон.
Жүктөлүп алынган маалыматтар интерфейсте чакан ыңгайлаштырылган башкаруу панели түрүндө көрсөтүлдү:
Биз үчүн күтүлбөгөн жерден MVP иштей баштады жана Интернеттеги жарнамалык кампаниялар боюнча учурдагы статистиканы жүктөй баштады. Биз тутумду бир нече кардарларга киргиздик, бирок масштабга аракет кылып жатканда олуттуу көйгөйлөргө туш болдук:
- Негизги көйгөй системага жүктөө үчүн маалыматтарды даярдоонун татаалдыгы болду. Ошондой эле, жүктөөдөн мурун жайгаштыруу маалыматтары катуу белгиленген форматка айландырылышы керек болчу. Жүктөө файлына ар кандай сайттардагы объекттин идентификаторлорун киргизүү керек болчу. Техникалык жактан даярдыгы жок колдонуучулар үчүн бул идентификаторлорду сайттан кайдан табаарын жана аларды файлдын кайсы жерине киргизүү керектигин түшүндүрүү абдан кыйын экендигине туш болдук. Сайттарда кампанияларды жүргүзүп жаткан бөлүмдөрдөгү кызматкерлердин санын жана жүгүртүүнү эске алганда, бул биздин тарапта чоң колдоону жаратты, бул биз таптакыр ыраазы болгон жок.
- Дагы бир көйгөй бардык жарнак платформаларында жарнамалык кампанияларга кирүү мүмкүнчүлүгүн башка аккаунттарга өткөрүп берүү механизмдери болгон эмес. Бирок өкүлчүлүк механизми жеткиликтүү болгон күндө да, бардык жарнакчылар үчүнчү тараптын аккаунттарына өз кампанияларына кирүү мүмкүнчүлүгүн берүүгө даяр эмес.
- Маанилүү фактор - бул колдонуучулардын нааразылыгын пайда кылган бардык пландаштырылган көрсөткүчтөрдү жана жайгаштыруу реквизиттерин биздин 1С эсептик тутумубузга киргизип, кайра киргизиши керек. ДАНБо.
Бул бизге жайгаштыруу тууралуу маалыматтын негизги булагы биздин 1С системабыз болушу керек деген ойду берди, ага бардык маалыматтар так жана өз убагында киргизилет (бул жерде кеп фактуралар 1С маалыматтарынын негизинде түзүлөт, андыктан маалыматтарды 1Сге туура киргизүү. ар бир KPI үчүн артыкчылыктуу болуп саналат). Ошентип системанын жаңы концепциясы пайда болду...
түшүнүк
Биринчиден, биз Интернеттеги жарнамалык кампаниялар боюнча статистиканы чогултуу тутумун өзүнчө продуктка бөлүүнү чечтик - D1.Digital.
Жаңы концепцияда биз жүктөөнү чечтик D1.Digital 1Сден жарнамалык кампаниялар жана алардын ичиндеги жайгаштыруулар жөнүндө маалымат, андан кийин сайттардан жана AdServing тутумдарынан бул жайгаштырууларга статистиканы чыгарыңыз. Бул колдонуучулардын жашоосун бир топ жөнөкөйлөштүрүү (жана, адаттагыдай эле, иштеп чыгуучуларга көбүрөөк жумуш кошуу) жана колдоонун көлөмүн азайтуу керек болчу.
Биз кабылган биринчи көйгөй уюштуруучулук мүнөзгө ээ болгон жана биз ар кандай системалардын объектилерин 1Стин кампаниялары жана жайгаштыруулары менен салыштыра турган ачкычты же белгини таба албаганыбызга байланыштуу болгон. Чындыгында, биздин компаниядагы процесс жарнак кампаниялары ар кандай адамдар (медиа пландоочулар, сатып алуу ж.
Бул көйгөйдү чечүү үчүн биз ар кандай системалардагы объекттерди бириктире турган жана жүктөлүп алынган маалымат топтомдорунда оңой жана уникалдуу түрдө аныктала турган уникалдуу хэштелген ачкычты, DANBoID ойлоп табышыбыз керек болчу. Бул идентификатор ар бир жеке жайгаштыруу үчүн ички 1С тутумунда түзүлөт жана бардык сайттардагы жана бардык AdServing системаларындагы кампанияларга, жайгаштырууларга жана эсептегичтерге өткөрүлүп берилет. DANBoIDди бардык жайгаштырууларга киргизүү практикасын ишке ашыруу бир аз убакытты талап кылды, бирок биз муну жасай алдык :)
Андан кийин биз бардык сайттарда статистиканы автоматтык түрдө чогултуу үчүн API жок экенин, жада калса API барлар да бардык керектүү маалыматтарды кайтарып бербестигин билдик.
Бул этапта биз интеграция үчүн аянтчалардын тизмесин бир топ кыскартууну чечтик жана жарнамалык кампаниялардын басымдуу көпчүлүгүнө катышкан негизги платформаларга көңүл бурууну чечтик. Бул тизмеге жарнама рыногундагы бардык ири оюнчулар (Google, Yandex, Mail.ru), социалдык тармактар (VK, Facebook, Twitter), негизги AdServing жана аналитика системалары (DCM, Adriver, Weborama, Google Analytics) жана башка платформалар кирет.
Биз тандаган сайттардын көбү бизге керектүү көрсөткүчтөрдү берген API болгон. API жок болгон же анда керектүү маалыматтарды камтыбаган учурларда, биз маалыматтарды жүктөө үчүн кеңсебиздин электрондук почтасына күн сайын жөнөтүлгөн отчетторду колдондук (айрым системаларда мындай отчетторду конфигурациялоого болот, башкаларында биз мындай отчетторду иштеп чыгуу боюнча макулдаштык. биз үчүн).
Ар кандай сайттардан алынган маалыматтарды талдоодо, биз субъекттердин иерархиясы ар кандай системаларда бирдей эмес экенин билдик. Мындан тышкары, маалымат ар кандай системалардан ар кандай майда-чүйдөсүнө чейин жүктөлүшү керек.
Бул көйгөйдү чечүү үчүн SubDANBoID концепциясы иштелип чыккан. SubDANBoID идеясы абдан жөнөкөй, биз сайтта кампаниянын негизги объектисин түзүлгөн DANBoID менен белгилейбиз жана биз уникалдуу сайт идентификаторлору менен бардык уяланган объекттерди жүктөйбүз жана DANBoID принцибине ылайык SubDANBoID түзөбүз + биринчи деңгээлдеги идентификатор уяланган объект + экинчи деңгээлдеги уяланган объекттин идентификатору +... Бул ыкма бизге ар кандай системалардагы жарнак кампанияларын туташтырууга жана алар боюнча деталдуу статистиканы жүктөп алууга мүмкүндүк берди.
Ошондой эле ар кандай платформалардагы кампанияларга кирүү маселесин чечүүгө туура келди. Биз жогоруда жазгандай, кампанияга кирүү мүмкүнчүлүгүн өзүнчө техникалык эсепке берүү механизми дайыма эле колдонула бербейт. Ошондуктан, биз токендерди жана бул токендерди жаңыртуу механизмдерин колдонуу менен OAuth аркылуу автоматтык авторизациялоо үчүн инфраструктураны иштеп чыгышыбыз керек болчу.
Кийинчерээк макалада биз чечүүнүн архитектурасын жана ишке ашыруунун техникалык деталдарын кеңири сүрөттөөгө аракет кылабыз.
Чечимдин архитектурасы 1.0
Жаңы продуктуну ишке ашырууну баштаганда, биз дароо жаңы сайттарды туташтыруу мүмкүнчүлүгүн караштырышыбыз керектигин түшүндүк, ошондуктан микросервис архитектурасынын жолун улантууну чечтик.
Архитектураны иштеп чыгууда биз бардык тышкы системалардын туташтыргычтарын - 1С, жарнак платформалары жана жарнамалык системаларды өзүнчө кызматтарга бөлдүк.
Негизги идея - сайттардын бардык туташтыргычтары бирдей APIге ээ жана сайт API'син биз үчүн ыңгайлуу интерфейске алып келүүчү адаптерлер.
Биздин продуктунун борборунда веб-тиркеме бар, ал монолит болуп саналат, ал сервистерге оңой ажыратыла тургандай иштелип чыккан. Бул колдонмо жүктөлүп алынган маалыматтарды иштеп чыгуу, ар кандай системалардын статистикасын чогултуу жана аларды системанын колдонуучуларына көрсөтүү үчүн жооптуу.
Туташтыргычтар менен веб тиркемесинин ортосунда байланышуу үчүн биз кошумча кызматты түзүшүбүз керек болчу, биз аны Connector Proxy деп атадык. Ал Кызматты табуу жана Тапшырма пландоочу функцияларын аткарат. Бул кызмат ар бир туташтыргыч үчүн ар бир түнү маалымат чогултуу тапшырмаларын аткарат. Тейлөө катмарын жазуу билдирүү брокерине туташтыруудан жеңилирээк болгон жана биз үчүн натыйжаны мүмкүн болушунча тезирээк алуу маанилүү болчу.
Жөнөкөйлүгү жана өнүгүү ылдамдыгы үчүн биз бардык кызматтар Web API болот деп чечтик. Бул тез эле концепциянын далилин чогултууга жана бүт долбоор иштеп жатканын текшерүүгө мүмкүндүк берди.
Өзүнчө, бир топ татаал милдет ар кандай эсептерден маалыматтарды чогултуу мүмкүнчүлүгүн түзүү болчу, биз чечкенибиздей, колдонуучулар веб-интерфейс аркылуу ишке ашырышы керек. Ал эки өзүнчө кадамдан турат: биринчиден, колдонуучу OAuth аркылуу эсепке кирүү үчүн белгини кошот, андан кийин белгилүү бир аккаунттан кардар үчүн маалыматтарды чогултууну конфигурациялайт. OAuth аркылуу токен алуу зарыл, анткени, биз буга чейин жазгандай, сайтта каалаган аккаунтка кирүү мүмкүнчүлүгүн берүү дайыма эле мүмкүн боло бербейт.
Сайттардан каттоо эсебин тандоонун универсалдуу механизмин түзүү үчүн, биз өзгөртүлгөн JSONEditor компоненти аркылуу формага келтирилген JSON схемасын кайтарып берүүчү API туташтыргычтарына методду кошууга туура келди. Бул жол менен, колдонуучулар маалыматтарды жүктөп алуу үчүн эсептерди тандап алган.
Сайттарда бар суроо-талап чектөөлөрүнө ылайык келүү үчүн, биз жөндөөлөр боюнча суроо-талаптарды бир токендин ичинде бириктиребиз, бирок биз ар кандай белгилерди параллелдүү иштете алабыз.
Биз MongoDBти веб-тиркеме үчүн да, туташтыргычтар үчүн да жүктөлгөн маалыматтарды сактоочу катары тандап алдык, бул тиркеменин объектинин модели күн сайын өзгөрүп турганда, иштеп чыгуунун баштапкы этаптарында берилиштердин структурасы жөнүндө көп кабатырланбоого мүмкүндүк берди.
Көп өтпөй биз MongoDBге бардык маалыматтар туура келбей турганын жана, мисалы, күнүмдүк статистиканы реляциялык маалымат базасында сактоо ыңгайлуу экенин билдик. Ошондуктан, маалыматтар түзүмү реляциялык маалымат базасына ылайыктуу туташтыргычтар үчүн биз сактагыч катары PostgreSQL же MS SQL Server колдоно баштадык.
Тандалган архитектура жана технологиялар бизге D1.Digital продуктуну салыштырмалуу тез курууга жана ишке киргизүүгө мүмкүндүк берди. Продукцияны иштеп чыгуунун эки жыл ичинде биз сайттарга 23 туташтыргычты иштеп чыктык, үчүнчү тараптын API'лери менен иштөөдө баа жеткис тажрыйбага ээ болдук, ар бири өз алдынча болгон ар кандай сайттардын тузактарынан качууну үйрөндүк, кеминде 3 сайт үчүн API'лерди иштеп чыгууга салым коштук. , дээрлик 15 000 кампания жана 80 000ден ашык жайгаштыруу боюнча маалыматты автоматтык түрдө жүктөп алып, продуктунун иштеши боюнча колдонуучулардан көптөгөн пикирлерди чогултуп, ушул пикирдин негизинде продуктунун негизги процессин бир нече жолу өзгөртүүгө жетишкен.
Чечимдин архитектурасы 2.0
Иштеп баштаганына эки жыл болду D1.Digital. Системага жүктөмдүн тынымсыз көбөйүшү жана көбүрөөк жаңы маалымат булактарынын пайда болушу бара-бара иштеп жаткан чечим архитектурасында көйгөйлөрдү ачып берди.
Биринчи көйгөй сайттардан жүктөлүп алынган маалыматтардын көлөмүнө байланыштуу. Биз ири сайттардан керектүү маалыматтарды чогултуу жана жаңыртуу өтө көп убакытты талап кыла баштаганына туш болдук. Мисалы, AdRiver жарнамалоо тутумунан маалыматтарды чогултуу, анын жардамы менен биз көпчүлүк жайгаштыруулардын статистикасын көзөмөлдөйбүз, болжол менен 12 саатты алат.
Бул көйгөйдү чечүү үчүн, биз сайттардан маалыматтарды жүктөп алуу үчүн ар кандай отчетторду колдоно баштадык, анын иштөө ылдамдыгы биздин муктаждыктарыбызды канааттандырышы үчүн сайттар менен бирге алардын API'син иштеп чыгууга аракет кылып жатабыз жана маалыматтарды жүктөөнү мүмкүн болушунча параллелдештиребиз. .
Дагы бир көйгөй жүктөлүп алынган маалыматтарды иштетүүгө байланыштуу. Эми, жаңы жайгаштыруу статистикасы келгенде, чийки маалыматтарды жүктөө, ар бир сайт үчүн топтолгон метрикаларды эсептөө, ар кандай булактардан алынган маалыматтарды бири-бири менен салыштыруу жана кампаниянын жыйынды көрсөткүчтөрүн эсептөө кирет. Бул бардык эсептөөлөрдү жасаган веб-тиркемеде көп жүктөмдү жаратат. Бир нече жолу, кайра эсептөө процессинде, тиркеме сервердеги бардык эстутумду, болжол менен 10-15 ГБ сарптады, бул колдонуучулардын система менен иштөөсүнө эң терс таасирин тийгизди.
Белгиленген көйгөйлөр жана продуктуну андан ары өнүктүрүү боюнча амбициялуу пландар бизди өтүнмөнүн архитектурасын кайра карап чыгуу зарылдыгына алып келди.
Биз туташтыргычтар менен баштадык.
Биз бардык туташтыргычтар бир моделге ылайык иштээрин байкадык, ошондуктан биз коннекторду түзүү үчүн кадамдардын логикасын программалоо керек болгон түтүк алкагын курдук, калгандары универсалдуу. Эгер кээ бир туташтыргыч жакшыртууну талап кылса, анда туташтыргыч өркүндөтүлүп жаткан учурда биз аны дароо жаңы алкактарга өткөрөбүз.
Ошол эле учурда, биз Docker жана Kubernetes үчүн туташтыргычтарды орното баштадык.
Биз Кубернетеске өтүүнү көп убакытка пландаштырганбыз, CI/CD жөндөөлөрү менен эксперимент жүргүзгөнбүз, бирок бир туташтыргыч катадан улам серверде 20 ГБдан ашык эстутумду жеп баштаганда гана кыймылдай баштадык жана башка процесстерди дээрлик жок кылып салдык. . Иликтөө учурунда туташтыргыч Kubernetes кластерине көчүрүлүп, ката оңдолгондон кийин да ошол жерде кала берген.
Биз бат эле Kubernetes ыңгайлуу экенин түшүндүк жана алты айдын ичинде биз эң көп ресурстарды талап кылган 7 туташтыргычты жана Коннекторлордун проксисин өндүрүш кластерине өткөрдүк.
Туташтыргычтардан кийин биз калган тиркеменин архитектурасын өзгөртүүнү чечтик.
Негизги көйгөй маалыматтар конекторлордон проксиге чоң партиялар менен келип, андан кийин DANBoIDге тийип, кайра иштетүү үчүн борбордук веб-тиркемеге жөнөтүлөт. Көп сандаган метрикалык кайра эсептөөлөрдөн улам, тиркемеде чоң жүк бар.
Ошондой эле жеке маалыматтарды чогултуу жумуштарынын абалына мониторинг жүргүзүү жана колдонуучулар эмне болуп жатканын жана эмне үчүн маалымат чогултулбай жатканын көрүү үчүн борбордук веб-тиркемеге туташтыргычтарда пайда болгон каталарды кабарлоо абдан кыйын болду.
Бул көйгөйлөрдү чечүү үчүн биз архитектура 2.0 иштеп чыктык.
Архитектуранын жаңы версиясынын негизги айырмачылыгы, кызматтардын ортосунда билдирүүлөрдү алмашуу үчүн Web API ордуна биз RabbitMQ жана MassTransit китепканасын колдонобуз. Бул үчүн, Коннекторлордун Проксисин дээрлик толугу менен кайра жазып, аны Connectors Hub кылып алышыбыз керек болчу. Аты өзгөртүлдү, анткени кызматтын негизги ролу суроо-талаптарды туташтыргычтарга жана артка жөнөтүүдө эмес, туташтыргычтардан метрикаларды чогултууну башкарууда.
Борбордук веб-тиркемеден биз сайттардан жайгаштыруу жана статистика жөнүндө маалыматты өзүнчө кызматтарга бөлдүк, бул керексиз кайра эсептөөлөрдөн арылууга жана жайгаштыруу деңгээлинде буга чейин эсептелген жана топтолгон статистиканы гана сактоого мүмкүндүк берди. Биз ошондой эле чийки маалыматтардын негизинде негизги статистиканы эсептөө логикасын кайра жаздык жана оптималдаштырдык.
Ошол эле учурда биз бардык кызматтарды жана тиркемелерди Docker жана Kubernetesке көчүрүп жатабыз, бул чечимди масштабдоону жеңилдетүү жана башкарууну ыңгайлуураак кылуу.
Биз азыр каяктабыз
Proof-of-concept архитектурасы 2.0 продукт D1.Digital даяр жана туташтыргычтардын чектелген топтому менен сыноо чөйрөсүндө иштөө. Болгону, жаңы платформага дагы 20 туташтыргычты кайра жазып, маалыматтардын туура жүктөлгөндүгүн жана бардык метрикалардын туура эсептелгендигин текшерүү жана бүт дизайнды өндүрүшкө чыгаруу керек.
Чынында, бул процесс акырындык менен ишке ашат жана биз бардыгын иштеши үчүн эски API менен артка шайкештикти калтырышыбыз керек болот.
Биздин жакынкы пландарыбызга жаңы туташтыргычтарды иштеп чыгуу, жаңы системалар менен интеграциялоо жана туташкан сайттардан жана жарнамалык системалардан жүктөлүп алынган маалыматтардын топтомуна кошумча метрикаларды кошуу кирет.
Биз ошондой эле бардык тиркемелерди, анын ичинде борбордук веб-тиркемени Docker жана Kubernetesке өткөрүүнү пландап жатабыз. Жаңы архитектура менен айкалышып, бул керектелүүчү ресурстарды жайгаштырууну, көзөмөлдөөнү жана контролдоону кыйла жөнөкөйлөтөт.
Дагы бир идея - азыркы учурда MongoDBде сакталган статистиканы сактоо үчүн маалымат базасын тандоо менен эксперимент жүргүзүү. Биз буга чейин SQL маалымат базасына бир нече жаңы туташтыргычтарды өткөрүп бердик, бирок бул жерде айырма дээрлик байкалбайт жана ыктыярдуу мезгилге суралышы мүмкүн болгон күндөлүк жалпы статистика үчүн киреше олуттуу болушу мүмкүн.
Жалпысынан алганда, пландар чоң, алдыга жылалы :)
Макаланын авторлору R&D Dentsu Aegis Network Russia: Георгий Остапенко (), Михаил Коцик ()
Source: www.habr.com