Tencent Oyun Pazarlama Teknolojisinde OpenResty Uygulaması ve Uygulaması
Herkese günaydın, ben Tencent'ten Shawn Gu Xiaoping. Tencent oyun pazarlama teknolojisi ve OpenResty'nin bazı uygulama örneklerini paylaşmak için bugün NetEase Building'e gelme fırsatına sahip olduğum için çok mutluyum.
Önce basit bir kendini tanıtın. Tencent'e katılmadan önce, Huawei ve UTStarcom dahil olmak üzere iletişim endüstrisinde iletişim yazılımı araştırma ve geliştirme çalışmalarında bulundum.
Tencent'e Ekim 2012'de katıldım ve şimdi Tencent Interactive Entertainment Group'taki pazarlama teknolojisi ile ilgili işlerin bir kısmından sorumluyum. Pek çok teknik işle temasa geçtim, ama aynı zamanda daha karmaşık, bu yüzden tam yığın bir mühendis değil, tam yığın bir mühendis olduğumu iddia ediyorum. Düşük seviyeli tek çipli mikro bilgisayardan gömülü ve protokol yığını geliştirmeye, üst seviye uygulama geliştirmeye kadar, oyunun arka planı üzerinde de çalıştım ve şimdi pazarlama ile ilgili bazı teknolojiler yapıyorum, bu nedenle her türlü teknolojiye mutlaka derinlemesine değil, dokunuldu, ancak hepsi açığa çıktı Biraz geç.
Bugün paylaşmak istediğim içerik ağırlıklı olarak iki ana parçadan oluşuyor:
- İlk parça, Tencent oyun pazarlama API ağ geçidinde OpenResty uygulamasıdır
- İkinci parça, Tencent'in oyun reklam sistemindeki OpenResty uygulamasıdır.
Paylaşımım OpenResty uygulamasına odaklanacak ve OpenResty'nin çok fazla spesifik teknik detayını içermeyecektir.Ana amaç, bazı uygulama durumları aracılığıyla bazı optimizasyon fikirlerini başkalarını çekmek için sizinle paylaşmaktır.
Tencent Game Marketing API Gateway'de bir OpenResty uygulaması
Tencent Game Marketing API Gateway'de bir OpenResty uygulaması olan ilk paylaşılan duruma girerken, aşağıda herkese garip gelebilecek bir şapka var. "One Piece" i okuduysanız, aşina olabilirsiniz. Bu " Luffy'nin "One Piece" içindeki şapkası aynı zamanda dahili API ağ geçidimizin logosudur. Ekibimiz "One Piece" tarafından yapılan tüm genel bileşenleri ve platform öğelerini adlandırır ve elbette çok daha fazlası vardır.
Daha sonra, neden API ağ geçitleri yapmak zorunda olduğumuza ve bir iş geliştirme ekibiyiz çünkü API ağ geçitleri yapmanın iş geçmişine bir göz atalım. Yeni bir oyun piyasaya sürülmeden önce, aşağıdakiler de dahil olmak üzere birçok pazarlama ve tanıtım faaliyeti yapması gerekir: Çeşitli oturum açma, operasyon, piyango ve diğer etkinlikler. Formlar da küçük oyunlar, promosyon türü gibi küçük programlar, H5l kılavuz türü ve benzeri gibi farklıdır.
Buna ek olarak, her oyunun, her oyunun APP'sinin girişinden erişilebilen ve bazı bilgiler, strateji, kişisel verilerin yanı sıra bazı puanlar, sıralamalar vb. Sağlayan kendi mikro topluluğu vardır. , Ayrıca canlı etkinliğin bazı içeriğini içerir.
Her oyunda çok sayıda aktivite var ve bu oyunun sayısı hala çok fazla. O zaman ziyaret ettiği arka planın trafiği de çok büyüktür ve bu, burada bahsedilen sayıyı çok aşacaktır.
Böylesine karmaşık bir işle karşı karşıya, başlangıçta bunu nasıl yaptık? İşlevsel düzeyde, onu birçok benzer işlevsel modüle böldük.Yaklaşık yirmi ya da otuz kadar işlevsel modül var Modülerleştirmeden sonra sorun yok mu? Ancak sorun, esas olarak iki yönü içeren hala var:
- İlk husus: Geliştirme aşamasında, kimlik doğrulama, oturum açma doğrulama, akış kontrolü, frekans kontrolü, güvenlik vb. Gibi çok sayıda tekrarlayan, işlevsel olmayan modül geliştirme vardır.
- İkinci özellik: Çevrimiçi çalışırken çok sayıda kaydırmayı önleme ve anormal kullanıcı davranışı da vardır; bu davranış kontrolü ve analizi, piyango etkinlikleri için anti-swipe, seckill ve akış kontrolü gibi bazı müdahaleler dahil.
Bu tür soruların tümü, bize işlevsel geliştirme ve işlevsel olmayan garantinin bağımsızlığını nasıl elde edeceğimizi ve birleşik akış kontrolüne nasıl ulaşacağımızı düşündürür. Aslında API ağ geçidinin yapması gereken şey budur, bu yüzden Daha sonra, kabaca iki kategoriye ayrılan endüstrinin API ağ geçidi çözümleri hakkında birçok araştırma ve analiz yaptık:
İlk kategori, açık kaynak çözümlerdir, aşina olduğumuz açık kaynak çözümleri arasında, OpenResty tabanlı Orange ve KONG ile kendi API ağ geçitleri olan Go ve Java gibi diğer diller.
İkincisi, bulut çözümüdür.Her ana akım bulut satıcısının kendi API ağ geçidi çözümü vardır. Bu çözümlerin kendi avantajları ve dezavantajları vardır, ancak hepsinin ortak bir sorunu vardır, yani işimizin bireysel ihtiyaçlarını karşılayamazlar. , Birçok özelleştirilmiş gereksinim dahil. Başka bir sorun daha var, özellikle büyük şirketlerde mevcut bileşenlerimiz ve platformlarımızla entegre olamıyor Açık kaynak olmadığı için bunu yapmak zor.
Bu nedenle, buna dayanarak, tam bir özelleştirme yapmak için turuncu çözüm olan açık kaynak çözümünün en basit ve en basitleştirilmiş sürümünü seçiyoruz.
Özelleştirmeden önce, turuncu çözümün ihtiyaçlarını karşılayamayan sorunlara veya yönlere bir göz atalım.Ona beş yönden bakıyoruz.Bu beş yön, herhangi bir teknik çözüm seçimi veya değerlendirmesi yaptığımızda da ortaya çıkıyor. Analiz noktaları:
Portakalın bu beş yönüyle ilgili eksikliklerine bir göz atalım.
Daha sonra, beş açıdan nasıl optimize ettiğimiz ve düşündüğümüz hakkında konuşacağız:
Kullanım kolaylığı için optimize edilmiştir
İlki kullanım kolaylığı açısından optimizasyon. İki resim var Soldaki resim turuncu yönetim terminalinin ekran görüntüsü. URL yönlendirme dahil çok sayıda teknik eklenti olduğunu görebiliyoruz, Yeniden yazma, çeşitli sertifikalar, hız sınırları, güvenlik vb. Peki bununla ilgili sorun nedir? Basit bir örnek vermek gerekirse, yeni bir API eklemek istiyoruz, daha sonra bu API'nin URL'sini tüm eklentilerde yapılandırmam gerekiyor, eklentilerin altında seçiciler var ve kuralların tekrar çalıştırılması gerekiyor ki bu çok tekrarlı ve zahmetli.
İkinci sorun, iş geliştiriciler için, onların düşünme ve çalışma alışkanlıklarının, uygulamalarımdan birine, belirli bir uygulama altındaki belirli bir hizmete ve altındaki belirli bir hizmete daha fazla dikkat etmek gibi işe daha fazla önem vermesidir. Her API'nin kullanımı (kimlik doğrulama, doğrulama, güvenlik, akış kontrolü, istatistiklerin vb. Çalışması veya yürütülmesi).
Dolayısıyla burada kullanım kolaylığı için tasarım yaparken teknoloji odaklı olmaktan çok iş odaklı düşünmemiz gerektiğini söyleyen bir söz var sanırım KONG'nin konfigürasyon arayüzünde de hizmet kavramı var gibi görünüyor, bu düşünceniz ne kadar fazla olursa.
Kullanılabilirlik optimizasyonu
İkincisi, kullanılabilirliğin optimizasyonudur.Kullanılabilirlik konusu, büyük şirketlerde nispeten daha kolaydır, çünkü büyük şirketler, temeldeki düğümlerin ve düğümlerin kullanılabilirliğini sağlamak için daha güvenilir ekipmanlarına veya bileşenlerine sahiptir. Ve Tencent, TWG / STGW adı verilen böyle bir erişim katmanı ağ geçidi bileşenine sahiptir. Bunlar, başlangıçta farklı operatörlerin trafiğini Tencentin kendi bilgisayar odasında toplamak ve ayrıca yük dengeleme, hata toleransı ve diğer kullanılabilirliği yapmak için tasarlandı. Koruma. Bu nedenle, ağ geçidinin kendisinin kullanılabilirliği çok basittir. API ağ geçidi düğümünü doğrudan TGW / STGW'ye asmanız yeterlidir.Son üç ağ geçidi makinesi bilgisayar odasına yerleştirilir ve felaket kurtarma seviyesinde daha fazla kullanılabilirlik garanti edilir. .
İkinci yön, yapılandırma düğümünün kullanılabilirliğinin optimizasyonudur. Yapılandırma düğümü, yapılandırma bilgilerini depolar. Yapılandırma bilgileri çok küçük olmasına rağmen, bazı basit optimizasyonlar yapılabilir. En basit olan, MySQL veya Redis'i bağımsız olarak dağıtmak ve yapılandırma bilgilerini bunlara koymaktır. Bir yere gidin ve ardından mysql / redis'in kullanılabilirliğini kendiniz sağlayın.
Üçüncüsü, konfigürasyon bilgisini saklamak için MySQL veya daha hafif bir sqlite kullanabilir ve yönetim tarafı kullanılabilirliğini sağlayacaktır.Yönetim tarafı her yeni API eklediğinde, bu üçüne aynı anda yazacaktır. Düğümü yapılandırın ve ardından aynı anda API ağ geçidinin paylaşılan belleğine yazın. Bu şekilde, giriş kabadır, ancak basit ve kolaydır ve yine de hızla çevrimiçi olduğumuz şeyler için kullanılabilir.
Son yöntem, konfigürasyon bilgilerini ETCD'de saklamak için ETCD'yi kullanmak ve kullanılabilirliğini ve tutarlılığını sağlamak için merkezi olmayan ETCD protokolünü kullanmaktır. Bu çözüm nispeten mükemmel, ancak ETCD gibi işlemleri izlemek için API ağ geçidine yeni kod yazmamız gereken bir sorun var ve yavaş yavaş bu çözüme geçiyoruz.
Verim iyileştirmesi
Üçüncüsü performans optimizasyonu ... Başlangıçta ekibimiz Orange'ın performansı üzerine bir ön test yaptı ve kural sayısı arttıkça QPS'nin önemli ölçüde düştüğünü gördü ve ardından alev grafiğini analiz etmeye gittik. Daha sonra, işlemlerin% 60'ının json işlemlerinde ve düzenli ifade eşleştirme işlemlerinde tüketileceği ve json işlemlerinin çoğunlukta olduğu keşfedildi.
Bizim için ilk tepki, json işleminin çok zaman alması oldu. Turuncu renkteki Cjson'u daha yüksek performanslı bir json işleme kitaplığı ile değiştirebilir miyiz? Tencent öğrencileri için tanıdık geliyor RapidJSON, çünkü bu Tencent'in ilk açık kaynak projesi. Hızlı bir şekilde RapidJSON'u turuncu renkte cJSON ile değiştirdim ve etkinin hala çok açık olduğunu ve performansın bir seferde% 10 + arttığını gördüm.
Sıradaki sorun olur mu? Bunu neden yapmak istediğimizi sormaya devam edelim ve basitçe kodu okuyalım. Nedeni hala çok basit, yani turuncunun kendisi bir http isteği aldığında, her işçi, isteği aldığında yapılandırmayı çekmek için paylaşılan belleğe gidecek. Bilgi ve ardından her bir çalışanın veri yapısı haline gelen bir json serisini kaldırma işlemi yapın.Konfigürasyon bilgilerinin güncellenip güncellenmediğine bakılmaksızın, bunu yapın.Yazar kendi değerlendirmesini yapabilir. Yapılandırma güncellemesi olduğunda, Böylece gerçek zamanlı olarak öğrenebilirsiniz.
Şimdi kendimize ikinci soruyu soralım, bunu yapıp yapamayacağımızdır. Bizim için, gerçek zaman pahasına, en son yapılandırma bilgilerini almak için yarım dakika veya birkaç saniyede bir yapılandırma güncellemesi yapabiliriz. Kabul edilmiş. Bu nedenle, doğrudan bir Zamanlayıcıyı başlatmak ve bu paylaşılan bellekte yapılandırma bilgisinin güncelleme bayrağı olup olmadığını kontrol etmek için belirli bir süre kontrol etmek olan yukarıdaki sık serileştirme işlemlerinden kolayca kurtulabiliriz Bu bölümü doğrudan optimize etmek çok basittir. JSON işlemi doğrudan kaldırılır.
İşte en büyük optimizasyonun esneklik yapmamak ya da dengelemek olmadığı bir deneyim Bu esnek denge, performans için diğer bazı kaynaklardan ödün vermek, performans için hafızadan fedakarlık etmek veya performans için bazı gerçek zamanlı performanstan ödün vermek gibi birçok yönü içerebilir. Performans elde etmek için bazı ürünlerin deneyiminden ödün vermeyi de içerir.Bunlar esnek dengelerdir ve düşünmek için daha fazla zaman harcamamızı gerektirebilir.
Daha sonra, daha fazla optimizasyon yapacağız. Bu nedenle, tam bir performans testi yapacağız. Tam bir performans testi esas olarak bu yedi bağlantıyı içerecektir.İlk üç bağlantı, stres testinin dördüncü halkası için hazırlanmıştır. , Ortam hazırlığı, yapılandırma ayarı, statik inceleme vb. Dahil
Elbette bu bağlantıda dikkat edilmesi gerekenler de var.Çevre hazırlığı çok basit olsa da göz önünde bulundurulması gereken bazı hususlar var, yani test makinesinin performansı ve basınç test aletinin performansı sıklıkla problemler yaşıyor. Göz önünde bulundurulması gereken test makinesi ve test edilen makine vb. Gecikmeler de vardır, aksi takdirde testimizin gerçekliğini etkileyecektir.
Aksi takdirde, yapılandırma ayarı ve statik kontrol, bazı genel deneyimler referans alınarak yapılabilir.
Stres testine başlayalım.Geçerli ağın gerçek ortamını ve canlı ağın işlem akışını simüle etmek için stres testi mümkün olduğunca yapılmalıdır.Eğer sadece bir yankı testi yaparsak, performans verileri çok yüksek olmasına rağmen, değildir. Çok gerçek olmalı ve referans değerine sahip olmalıdır. Bu yüzden, Tencent içindeki bir C1 modelinde gerçek ağ trafiğini ve yapılandırmasını simüle ettik ve ölçülen veri muhtemelen 18000 QPS idi. Bu veriler kesinlikle daha önce PHP'nin eşzamanlı engellemesini kullanan geleneksel CGI yönteminden daha büyük bir sıradadır, ancak optimizasyona mutlaka yer yoktur.
Bundan sonra darboğaz analizi ve performans analizi yapmaya devam ediyoruz. Performans analizi, performans analizi yapıtımızı kullanır: alev grafiği OpenResty topluluğundaki öğrenciler alev grafiklerine çok aşinadır.
CPU tüketiminin ilk 10 işlemini özetledik. Birkaç işlem türü vardır. Bunlardan ilki% 9,18'i oluşturan JSON işlemleridir. İkincisi, L5 işlemlerinin% 4,74'ünü oluşturması (L5, Tencent'in dahili yük dengeleme hizmetinin bir bileşenidir) ve diğeri, normal ifade eşleştirmesinin% 10,36'lık bir paya sahip olmasıdır. Diğeri nginx ve sistem çağrılarının çalışmasıdır.
Daha sonra, optimizasyon için yer olup olmadığını görmek için bu üç husus üzerinde çalışacağız. Her şeyden önce, L5'in bu işleminin optimizasyonu için yer olup olmadığını görelim. L5'in Tencent içinde bir yük dengeleme bileşeni olduğunu söylemiştim. Onu API ağ geçidine de entegre edeceğiz. Çalışma prensipleri yerel L5agent ile aynı olacaktır. İletişim, bu nedenle stres testi yaparken, bu kadar büyük bir stres testi akışı durumunda, L5agent'in CPU tüketip tüketmediğini veya herhangi bir hata olup olmadığını kontrol etmemiz gerekir, ardından günlüğüne ve hata koşullarına bakın. Normal mi Daha sonra performans artışı olup olmadığını görmek için önceki Lua C / API yöntemimizi FFI ile değiştirin. L5'in çalışmasını analiz etmek için daha ileri gittik ve UDP çağrılarını engelleme kullandığını gördük, bu yüzden burada bir risk var, diğer coroutine'lerin yürütülmesini etkileyecek, bu yüzden zaman aşımı süresini ayarlamaya çalışmalıyız Biraz daha kısaltın ve L5 API'yi uygulamak için cosocket kullanıp kullanamayacağımızı görmeye çalışın, ancak protokolün açık kaynaklı olmadığını gördük. Bu denemelerden sonra, optimizasyonun bu kısmını nihayet bıraktık.
Sırada JSON işlemlerinin optimizasyonu var.Önceki deneyimi yaşadıktan sonra, performans optimizasyonu yaparken kendimize iki soru soracağız. İlk soru neden bunu yapmamız gerektiğidir.Analiz, arka uç hizmetimizin tüm yanıt verilerinin bir JSON kodlamasını yapması ve ardından API ağ geçidinin JSON kodunu çözmesi ve ardından içeriye bir dönüş kodu çıkarması nedeniyle olduğunu buldu. Arka uç tarafından döndürülen dönüş kodu farklıdır, ister 200 OK olsun, ister ön uca döndürülen başka bir HTTP yanıt kodu tam da böyle bir şeydir. Sonra ikinci soruyu yapıp yapamayacağınızı sormaya devam edin.Açıktır ki, bu mümkündür, yani, arka uç geri dönüş kodu alanını ayırmak için doğrudan veriye izin verebiliriz ve API ağ geçidi, bir karar vermek için doğrudan dönüş kodunu alabilir. Ardından veri alanını doğrudan ön uca iletin ve sorun yok. Çok basit bir optimizasyon, JSON işleminin bu bölümünü doğrudan kaydedebilir.
Buna ek olarak, JSON işlemleri CPU performansımızın çoğunu tüketir. Sınıf arkadaşlarımızdan bazıları genellikle hata ayıklama sırasında yazdırır ve bu hata ayıklama günlüğündeki birçok veri yapısının içeriğini yazdırmak (yazdırmak için json.encode kullanın) ve ardından nesile koymak ister. Ortam, bu hata ayıklama işlemi gerçekleştirilmeyecek olsa da, bu işlev, JSON kodlama işlemi yürütülecek, bu, üretim ortamında büyük bir performans kaybına neden olacak, vb. Hala birçok benzer durum var, bu yüzden biz Gerçek süreçte, bu tür kötü kodlama alışkanlıklarına hala dikkat etmemiz gerekiyor.
Normal ifade eşlemesinin optimizasyonu
Üçüncüsü, düzenli ifade eşlemesinin optimizasyonudur. Düzenli ifade eşleştirmesinin düzenli ifade motorları tarafından yapıldığını herkes bilir.Genel olarak kullanılan düzenli ifade motoru PCRE'dir, bu nedenle daha yüksek performanslı bir düzenli ifade eşleştirme motoru olup olmadığını dikkate alacağız. Ayrıca biraz araştırma yaptık.Kural ifadelerin en çok kullanıldığı alan aslında güvenlik alanıdır.Güvenlik alanında bu tür IPS, IDS ve düzenli ifadeler kullanan bazı güvenlik algılama ve savunma ürünleri var. Eşleştirme işlemi için, daha önce düzenli ifade eşlemesi yapmak için PCRE kullanıldı. Daha sonra, son iki yılda hepsi Intel'in açık kaynak kodlu Hyperscan gibi bir normal ifade motoruna geçti.
Neden böyle bir değişiklik yapsın? Hyperscan düzenli ifade motorunun bu PCRE'ye göre avantajları nelerdir? Analizden sonra, birkaç farklılığı veya avantajı olduğu bulundu.
- Birincisi, sadece blok modunu değil, aynı zamanda akış modunu da desteklemesidir. Sözde akış modu, güvenlik ürünleri için çok yararlı olan farklı ağ paketleri arasında bir eşleşme yapmaktır.
- İkincisi, aynı anda birden fazla kuralı derleyebilmesidir .. Herkes bilir ki, düzenli ifadeler eninde sonunda eşleştirme işlemlerini dahili olarak gerçekleştirmek için bir durum makinesinde derlenecektir.
- Üçüncüsü, bir girdi birden çok kuralın yalnızca bir kez eşleşmesidir, birden çok kuralla paralel olarak eşleşebilir, bu çok güçlüdür. Performansı çok yüksek olabilir, bu yüzden bundan sonra böyle bir doğrulama yapacağız, bu da bir metne 300.000 http alma isteği (URL dahil) yazmaktır. Daha sonra her parametre normal bir ifadeyle eşleştirilir ve dosyayı okumak, tek tek okumak ve ardından her kuralı eşleştirmek için PCRE kodu ve Hyperscan kodu kullanılır. Hyperscan'in normal ifadelerle eşleştiği bulundu, bu nedenle geçen süre, PCRE'nin aldığı zamandan gerçekten çok daha düşük, bu da PCRE'nin yaklaşık% 30'u. Daha sonra onu API ağ geçidimize çok kararlı bir şekilde tanıttık ve alev grafiği ile doğrulamaya devam ettik.İşlemci tüketimi önceki% 10'dan% 7'ye düşürüldü.
Peki optimizasyon için hala yer var mı? Elbette, paralel eşleştirme kurallarını açma işlemi vardır.Bu Hyperscan ayrıca geri çağırmalar da sağlar.O zaman sadece her kural için bir bayrak ayarlamamız ve eşleştirme tamamlandıktan sonra bayrağı kontrol etmemiz gerekir ve bu tamam olacaktır. Bunu yapabilirsin.
Diğer şey nedir? Düzenli anlatım kuralları yazmanın zorluğudur.İş geliştirme öğrencilerinden her seferinde düzenli ifadeler yazmalarını isteyemeyiz, bu onlar için mutlaka doğru değildir ve bazı öğrenme maliyetleri vardır. Öyleyse, nispeten benzer parametrelerin çoğuna bir göz atalım, bu nedenle bu parametrelerin normal ifadelerini özetleyeceğiz ve ardından bir şablon oluşturmak için bazı metinsel açıklamalar kullanacağız ve işletme personeli bunları doğrudan seçebilir Şablon tamam ve bu sorun çok iyi çözüldü.
Güvenlik optimizasyonu
Optimizasyonun dördüncü yönü, güvenliğin optimizasyonudur. Güvenliği optimize etmek için yapılması gereken bir şey, API ağ geçidimizin güvenlik stratejisini şirketin mevcut güvenlik ürünlerinden bazılarıyla entegre etmesi gerektiğidir. Tencent'in Menshen adlı kendi güvenlik ürünü vardır, bu nedenle http talebinin okuma sonrası aşamasında güvenlik ürünüyle etkileşime girecek ve trafiği filtrelemesine izin vereceğiz. Filtrelediği trafik sorun değil, güvenlik politikamıza girer. Elbette bu güvenlik politikası, bir API beyaz listesi de dahil olmak üzere nispeten basittir ve API'ye yapılandırılmış trafik buna girebilir. Ardından, kullanıcı filtrelemesine, giriş doğrulamasına dayalı kara ve beyaz listeler ve Tencent'in mobil QQ, WeChat, vb. Destekleyen çoklu doğrulama yöntemleri de entegre edilmiştir.
Ek olarak, parametre doğrulaması yapmak için, parametre doğrulaması, zorunlu parametrelerin çok katı bir şekilde doğrulanması için yukarıda bahsedilen normal ifadeyi kullanır. Ek olarak, çok katı düzenli ifade eşleştirmesi yapılırsa, SQL enjeksiyonu önleme gibi sorunlar olmayacaktır. Bu, güvenliğin optimizasyonudur.
Sürdürülebilirlikte optimizasyon
Sonuncusu, sürdürülebilirliğin optimizasyonu. Ayrıca iki noktaya değindik:
- Birincisi, bazı günlük ve istatistik işlevleri eklemektir. Örneğin, 4xx / 5xx gibi bazı hata günlüklerini ayırın ve belirli bir kullanıcı kimliği ve ikinci istek kimliğine göre bir boya günlüğü izleme baskısı ekleyin.
- Optimizasyonun ikinci yönü, bugün tartışılan içeriğe ait olmak zorunda değildir, yani bir çağrı zinciri izleme sistemi de yaptık. API ağ geçidi, bu çağrı zinciri izleme sisteminde başlangıç noktası olarak hizmet eder.İzleme kimliğini oluşturur, çağrı zincirinin içeriğini oluşturur ve çağrı zincirini sonlandırır.Ayrıca, çağrı zinciri izleme koleksiyonunun sıklığını da kontrol edebilir.
Öyleyse burada, kullanım kolaylığı, kullanılabilirlik, performans, güvenlik ve sürdürülebilirlik açısından, bazı düşünme ve optimizasyon sürecimiz açısından, ilk uygulama durumuna hızlı ve basit bir giriş var.
Tencent oyun ve reklam sisteminde OpenResty uygulama örneği
Ardından, Tencent oyun ve reklam sisteminde OpenResty'nin uygulama durumu olan ikinci bölüme girin. Yine önceki içerikle aynı şekilde, özellikle vakayı sizinle paylaşmak için pek çok spesifik OpenResty teknik detayı ve bu durumda bazı optimizasyon fikirlerini dahil etmeyeceğim.
Bu durum nispeten cesur olacak, çünkü muhtemelen Tencent Games'in bu sistem aracılığıyla yatırım yapacak yüz milyonlarca pazarlama harcaması var. Reklam alanları, zaman aralıkları, trafik, normal teklif verme ve gerçek zamanlı teklif verme dahil olmak üzere birçok reklam biçimi vardır. Bugün sizinle paylaşmak istediğim şey, gerçek zamanlı teklif verme reklam yerleştirme formu ile OpenResty'mizin birleşimi ve OpenResty optimizasyonu.
Gerçek zamanlı teklif verme reklamcılığı nedir? Ve gerçek zamanlı teklif verme reklamcılığının süreci nedir? İçinde bir resim var. En sağdan sola bakarız ve en sağ, kullanıcılarımızın başlıklardaki içeriği görüntülemek veya haberleri taramak gibi içerikleri görüntülemek için telefonlarını açtıkları zamandır. İşlem sırasında reklam spotlarının olduğunu göreceksiniz.Reklam içeren sayfa görüntülendiğinde, APP bu anda ADX (Reklam Değişim Platformu) sunucusuna bir reklam isteği gönderecektir. Ad Exchange sunucusu reklam isteğini aldıktan sonra, reklam isteğini aşağıdaki reklamverenin DSP sunucusuna dağıtacaktır.Elbette birçok DSP sunucusu olabilir.Genel olarak konuşursak, sadece büyük reklamverenlerin kendilerine ait olacaktır. DSP sunucusu.
Nispeten büyük bir reklamveren olarak, Tencent Games'in kendi DSP sunucusu da var. Bir reklam isteği aldıktan sonra ne yapacak? Bu reklam isteğindeki trafiği bir karar vermek için DMP (Veri Yönetim Platformu) veritabanına aktaracak. Nasıl yargılamalı? İhtiyacım olan bu kullanıcı mı? İhtiyacım olan buysa, ona hangi fiyatın, yani bu kullanıcının reklam gösterme fırsatını elde etmek için ne kadar ödemeye hazır olduğum konusunda bir değerlendirme yapmalıyım.
Bu, teklifi değerlendirmek için bazı makine öğrenme algoritmalarını içerecektir Teklif nihayet belirlendikten sonra, teklifi ADX sunucusuna geri döndürecektir. ADX sunucusu bu teklifi aldıktan sonra, diğer reklamverenlerin TTP sunucularının tekliflerini bekleyecek, sonunda en yüksek teklife sahip reklamverenin reklamını seçmek için bunları birbiriyle karşılaştıracak ve ardından reklamverene bu reklamı gösterme fırsatı verecektir. Reklamverenin reklam öğesi, bu nispeten basitleştirilmiş gerçek zamanlı bir teklif verme sürecidir.
Yapılması gereken bir şey, ADX ve DSP sunucusu arasındaki etkileşimin OpenRTB protokolü aracılığıyla yapılmasıdır. Çözülmesi gereken iki sorun vardır:
- Birincisi, trafik çok büyük. ADX'in tüm reklam istekleri DSP sunucusuna gönderilecek.Bazı büyük medyalar on binlerce QPS'ye sahip olabilir ve birkaç tane varsa, kolayca 100.000 QPS'yi aşacaktır.
- Diğer bir sorun da, ADX'in tüm TTP'lerin teklif yanıtlarını 100 milisaniye içinde döndürmesini gerektirmesidir. Bu 100 milisaniye, ağdaki zamanı içerir. 100 milisaniye içinde yanıtınızı almazsam, sizi tekliften vazgeçmeyi düşüneceğim.
Tabii ki, gerçek zamanlı teklif verme reklam teknolojisinde birçok zorluk vardır ve esas olarak bu tür zorluklar vardır.
- İlki, etiket madenciliği, kitle yayılımı, profil analizi ve hedef popülasyonların seçilmesine yardımcı olacak bazı gerçek zamanlı analizler ve perspektif analizleri dahil olmak üzere veriler açısından.Bu, veri açısından teknik bir zorluktur.
- İkincisi, algoritmadır, algoritma iki çekirdek algoritma daha içerecektir. Birincisi pCTR ve ikincisi pCVR'dir. PCTR, tıklama oranı tahmin algoritmasıdır ve pCVR, dönüşüm oranı tahmin algoritmasıdır. Bu dönüşüm, birden çok dönüşümü içerebilir. İndirmeler, kayıtlar, ödemeler ve etkinleştirmelerin tümü dönüşümlerdir. Bu iki algoritma, içlerindeki daha sıcak makine öğrenme algoritmalarından bazılarını kullanacak.
- Üçüncü zorluk, sistem seviyesindeki zorluktur. Daha önce de belirtildiği gibi, ADX ve DSP sunucuları aralarında nispeten yüksek QPS'ye sahip olacaklar Diğeri ise, 100 milisaniye'lik bir gecikme gereksinimi olmasıdır. Bugün paylaştığım içerik esas olarak üçüncü bölüme odaklanıyor, bu da OpenResty ile sistem düzeyinde nasıl entegre edilir.
Bu, sistem tarafındaki gerçek zamanlı teklif verme reklam sisteminin şematik bir diyagramıdır. Üst katman trafik katmanıdır Her ADX'in reklam talebinin trafiği aşağıdaki erişim katmanına gönderilecektir. Erişim katmanı, biri statik bir CDN, diğeri dinamik bir RTB ağ geçidi olmak üzere iki bölümden oluşur. CDN, reklam materyallerini depolar. RTB ağ geçidi, OpenRTB protokolünü kodlamak ve kodunu çözmek için bir şey yapar. Ek olarak, bir miktar güvenlik sağlar ve Akış kontrolü gibi işlemler.
Mantık katmanı, teklif verme motorunu içerir ve alt kısım, DMP veri yönetimi platformunu içeren veri katmanıdır. Bu iki bölümün yaptığı şey, bu reklam isteğinin ihtiyacımız olan kullanıcı olup olmadığını belirlemek için birlikte söylediğimiz şeydir, eğer ihtiyacımız olan kullanıcıysa, bunun için bir fiyatı nasıl tahmin ederiz.
Turuncu-sarı yazı tipleri, erişim katmanının RTB ağ geçidi, mantık katmanı teklif motoru ve DMP veri yönetimi platformunun bir parçası dahil olmak üzere yeniden düzenlediğimiz veya optimize ettiğimiz OpenResty ile işaretlenmiştir.
Nasıl yeniden düzenleme ve optimize ettiğimize bir bakalım
- Öncelikle, erişim katmanında, RTB ağ geçidini özelleştirmek için doğrudan OpenResty kullanıyoruz.GTB ağ geçidini özelleştirmek için neden OpenResty kullanmalı? Az önce bahsettiğim gibi, trafiği çok büyük Bu, OpenResty'nin nginx + lua coroutine'in yüksek performanslı özelliklerine tam anlamıyla etki edebilir.
- Diğer bir sorun, farklı ortamların farklı OpenRTB protokollerine sahip olmasıdır.Standart düzenlemeler olmasına rağmen, yine de bazı farklılıkları vardır.Bağlanmak hala çok zahmetlidir, bu nedenle her ortam eklenti yöntemleriyle farklılaştırılır. Ortak hata ayıklamanın etkinliğini artırmak için.
- Sırada güvenlik açısından bir optimizasyon var Buradaki güvenlik politikası daha önce bahsedilen güvenlik politikasından farklı olabilir. Bu, temel olarak OpenRTB protokolünün güvenlik politikasına dayanmaktadır, buna Talep kimliğinin çeşitli doğrulama aşamaları ve ayrıca sızma önleme, sızan kullanıcı bilgileri vb. İçin parametrelerin asimetrik şifrelenmesi, bazı hile önleme işlemlerine ek olarak, bu güvenlik yönlerini ele alıyoruz. Optimizasyon bu RTB ağ geçidinde yapılır.
- Ek olarak, RTB ağ geçidi, hedef trafik filtrelemesini doğrudan RTB ağ geçidine yerleştirmek için büyük bir optimizasyon yaptı. Geleneksel yöntemler bunu daha önce nasıl yapıyordu? Trafiğin DMP veri platformuna girmesine izin vermek ve ardından kullanıcının ihtiyacımız olup olmadığını belirlemek için teklif verme motoru, reklam alma ve etiket sorgulama hizmetleri aracılığıyla DMP veri yönetimi platformuna gelmektir. DMP veri yönetimi platformu, tüm kullanıcıların şifrelenmiş kimlik bilgilerini ve bazı etiket özniteliklerini, tercihlerini vb. Sakladığından, daha önce bu şekilde değerlendirildi.
Aslında biraz basitleştirip şifrelenmiş verilerin bu kısmını doğrudan RTB ağ geçidine koyabiliriz. Elbette kullanıcının şifrelenmiş kimlik bilgilerinin çok büyük olması, bir milyardan fazla parçanın olması ve diğer cihaz kimliğinin en az olması gibi bir sorunla karşılaşacağız. Bu 32 dizedir.Hepsi hafızada saklanırsa, bir düzineden fazla Gs olacaktır.Elbette, bu, indeks arama ek yükünü içermez.
Ardından, sabit uzunlukta bir dizeyi doğrudan bir tam sayıya dönüştürebilen bir karma algoritma bulmaya gidiyoruz ve sonra bu tamsayıyı Bitmap aracılığıyla 512 megabayt bellek içindeki bir bit ile doğrudan eşleştiriyoruz. Böylelikle 512 megabayt bellek üzerinden 4 milyar şifreli cihaz numarası direkt olarak depolanabilir.Elbette aynı bite eşlenen farklı şifreli cihaz numaraları olacak ama bu önemli değil, yine de orijinal yolu takip etmeye devam ediyoruz. Son DMP'de başka bir yargıya varmasına izin verin.
Böylesine basit bir optimizasyondan sonra, ilk seferde trafiğin% 80'inden fazlasını filtreleyebiliriz, böylece tüm sistemin performansı da büyük ölçüde iyileştirilir.
Bir sonraki adım, mantık katmanını optimize etmektir. Mantık katmanı esas olarak teklif verme motorudur. Teklif verme motoru, etiket sorgulama, reklam alma, tıklama oranı tahmin sorgusu, frekans kontrol sorgusu ve faturalama kontrolü gibi çok sayıda dahili hizmete erişimi içerecektir. Bu tür dahili hizmet erişimini bekleyin ve aynı zamanda DB'yi ayarlama, önbelleği ayarlama, yeniden düzenleme vb. Gibi çok sayıda işlemi içerecektir. İşlerimizin çoğu aslında böyle, çok sayıda G / Ç işlemi, çok tipik GÇ yoğun hizmetler , Bu yüzden OpenResty'yi çok kararlı bir şekilde tamamen yeniden düzenlemek için kullandık.Önceden, daha geleneksel ve çok eski C ++ çok iş parçacıklı senkronizasyon çerçevesini kullandık. Elbette, içinde birçok C ++ coroutine çözümü de var ve biz yine de onu doğrudan yeniden düzenlemek için OpenResty'yi kullanmayı seçiyoruz.
Diğer bir yön ise, gecikmeyi azaltmak için bazı önceki serileştirilmiş işlemleri paralel hale getirmek için bazı yeni coroutinler oluşturmak için OpenResty kullanmaktır.Belki bir veya iki paralel işlem, teklif verme gecikmesini yaklaşık% 10 azaltabilir. Aynı zamanda çok etkileyici bir kazançtır.
Son olarak, veri katmanında, OpenResty'nin kullanımı olup olmadığını görelim.
Veri katmanı DMP'nin üç işlevi vardır: Birincisi veri toplama, ikincisi veri hesaplama ve üçüncüsü veri uygulamasıdır. En ilkel veri toplama alanında, pazarlama sistemimize hizmet etmek için daha sonra DMP'yi büyüteceğimiz için, reklam gösterimi, topluluk davranışı ve resmi hesap davranışı dahil olmak üzere birçok veri toplama işi içerir. , Çeşitli pazarlama faaliyetleri, vb., Daha önce olduğu gibi, şifrelemeden sonra toplanır.
Veri uygulama alanında, etiket sorgulama, hesap dönüştürme, dahili veri işbirliği, gerçek zamanlı sorgulama gibi çok sayıda işlemimiz var. Bu işlemler aslında çok ve bu OpenResty'yi doğrudan da kullanabilirsiniz, bu yüzden çok kullanıyoruz Çok az sunucu milyarlarca veri toplama ve sorgulama işlemlerini kolayca işleyebilir.
Bu noktada, 2 başvuru durumumu paylaştım ve sonunda söylediklerimi ve ifade etmek istediğim optimizasyon fikirlerini özetlemek için dört sayı kullandım, 3527 (9527 değil):
- "3" ne anlama geliyor? Sistem mimarimizde az önce bahsettiğimiz üç katmandır, erişim katmanı, mantık katmanı ve veri katmanı. Üç katmanı optimize etmek için OpenResty'yi kullanmayı düşünebilirsiniz.Herkes OpenResty'yi esas olarak erişim katmanı CDN ve En çok API kullanılır. Aslında, mantık katmanında, özellikle I / O yoğun mantık katmanında bazı işler yapmayı denemek için OpenResty kullanmayı da düşünebilirsiniz. Ve OpenResty'miz, TCP / UDP sunucusunu destekleyen akış modülünü yükseltti. Daha kararlı olabilirse, bu modülü doğrudan mantık katmanımıza hizmet etmek için de kullanmaya çalışacağız. Son olarak, gidip bunun veri katmanında olup olmadığını da görebiliriz. Çok basit veri toplama ve sorgulama işlemleri, eğer varsa, miktar görece büyükse, kolayca uygulamak için OpenResty kullanmayı da düşünebilirsiniz.
- "5" ne anlama geliyor? Az önce herhangi bir plan seçimi, teftiş, değerlendirme ve derinlemesine yaparken bunu bu beş yönden yapabileceğimizi söyledik. Birincisi kullanım kolaylığı, ikincisi kullanılabilirlik, üçüncüsü performans, dördüncüsü güvenlik ve beşincisi sürdürülebilirlik. Teknik öğrencilerimiz genellikle performans, kullanılabilirlik ve güvenlik hakkında düşünür, ancak aslında, birinci ve beşinci noktalar, kullanım kolaylığı ve bakım kolaylığı açısından daha fazla zaman harcamamızı gerektirir. Özellikle iş geliştirme sınıf arkadaşlarımız için, zamanın% 80'inden fazlası bu iki yönden olabilir.Kullanım kolaylığı ve bakım kolaylığı konusunda başarılı olursak, bize çok zaman kazandıracaktır.
- Üçüncü sayı "2", "2" ise performans optimizasyonu yaparken kendimize iki soru sormamız gerektiği anlamına gelir. İlk soru bunun neden yapıldığıdır. İkinci soru, atlanıp atlanamayacağı ve performansı artırmak için bellek kaynakları gibi bazı diğer kaynakları feda edip edemeyeceğidir. Performansı iyileştirmek için bazı gerçek zamanlı performanstan ödün verebilir miyiz veya performansı iyileştirmek için ürün deneyiminden ödün verebilir miyiz? Performansı optimize etmemiz gerektiğinde, bu tür düşünceleri ve değiş tokuşları yapmak için üst seviyeye gidebiliriz.
- "7", performans optimizasyonunu test ederken 7 bağlantımız olduğu anlamına gelir. İçindeki her bağlantının kendi dikkatine ihtiyacı vardır ve bazı indüksiyon ve özetleme yapabilir.
