How a team of just two engineers tackled real-time persisted events for hundreds of millions of players Sadece iki mühendisle Supercell, temel hesap sistemlerini yüzlerce milyon oyuncuya bağlayan bir sosyal platform haline getirme zorlu görevini üstlendi. Hesap yönetimi, arkadaş istekleri, çapraz oyun promosyonları, sohbet, oyuncu varlığı izleme ve takım oluşturma - bunların hepsi beş ana oyunda çalışmak zorunda kaldı. Supercell'in sunucu mühendisi Edvard Fagerholm, son zamanlarda iki kişilik güçlü ekibinin bu görevi nasıl ele aldığını paylaştı. Not: Eğer bu gibi mühendislik başarıları duymaktan hoşlanıyorsanız, Monster Scale Summit'de bize katılın (ücretsiz + sanal). Disney+ / Hulu, Slack, Canva, Uber, Salesforce, Atlassian ve daha fazlası mühendisleri stratejileri ve vaka çalışmaları paylaşacak. s ile notu : Bu tür mühendislik başarıları duymaktan hoşlanıyorsanız, bize katılın Monster Scale Toplantısı Disney+/Hulu, Slack, Canva, Uber, Salesforce, Atlassian ve daha fazlasının mühendisleri stratejileri ve vaka çalışmaları paylaşacak. notu Monster Scale Toplantısı Sonraki Sonraki yazı: Supercell Kim? Supercell, Hay Day, Clash of Clans, Boom Beach, Clash Royale ve Brawl Stars oyunlarının arkasındaki Finlandiya merkezli şirkettir. Yakın zamana kadar, yüzlerce milyon aylık aktif kullanıcıya hizmet veren oyunlar için tüm hesap yönetimi işlevselliği sadece iki mühendis tarafından oluşturuldu ve yönetildi. Supercell ID Hakkında Bilgiler Supercell ID temel bir hesap sistemi olarak doğdu – kullanıcıların hesapları kurtarmalarına ve yeni cihazlara taşımalarına yardımcı olmak için bir şey. Edvard şöyle açıklıyor: “Müşteri, hesap API’sine HTTP sorgular yapabiliyordu, bu da çoğunlukla müşterinin kimliğini kanıtlamak için oyun sunucusuna sunabileceği imzalı tokenleri iade edebiliyordu. Bazı işlemler, arkadaş istekleri yapmak gibi, hesap API’sinin başka bir oyuncuya bir bildirim göndermesini gerektiriyordu. Örneğin, ‘Bu arkadaş isteğini onaylıyor musunuz?’ bu amaçla, bildirim için bir olay sırası vardı. Olayı orada yayınlayacağız ve oyun arka kısmı bildirimi oyun soketi kullanarak müşteriye iletecekti.” İki Yönlü İletişim Edvard, 2020'in sonunda Supercell ID projesine katıldıktan sonra, bildirim arka planı üzerinde çalışmaya başladı - öncelikle beş oyunlarında çapraz promosyon için. Müşteriler bir proxy sunucusuna bağlandı, daha sonra bir yönlendirme mekanizması olayları doğrudan müşterilere (oyunu geçirmeden) yönlendirdi. Bu, karşılıklı promosyon ve arkadaş istekleri ile ilgili hemen hemen bir hedef için yeterliydi. Ancak bu, onları daha büyük düşünmelerine neden oldu. Supercell ID sisteminin kapsamını önemli ölçüde arttırmak için iki yönlü iletişim kullanabileceklerini fark ettiler. Edvard, “Özellikle, daha önce oyun sunucusunun bir parçasıydı olan özellikleri uygulamamıza izin verdi. Amacımız, geliştirilecek yeni oyunların ihtiyacı olabilecek özellikleri almak ve bunları sistemimize paketlemek ve böylece gelişimlerini hızlandırmaktı.” Bu sayede Supercell ID, arkadaş grafikleri, takım oluşturma, sohbet ve arkadaş durum izleme gibi özellikleri destekleyen bir cross-game sosyal ağ haline dönüşmeye başladı. Supercell ID’nin Cross-Game Sosyal Ağına Gelişimi Bu noktada, arka planın Sosyal Ağ tarafı hala tek kişilik bir projeydi, bu yüzden bunu basitlikle tasarladılar. Doğru abstraksiyonu bulmak “Sadece tüm kullanımlarımızı destekleyecek ve tek bir mühendis tarafından tasarlanabilir ve uygulanabilir bir basit abstraksiyona sahip olmak istiyorduk,” dedi Edvard. “Başka bir deyişle, bir sohbet sistemi, bir varlık sistemi vb. inşa etmekten kaçınmak istiyorduk. Doğru soyutlama bulma anahtarıydı. ve Change Data Capture ile hierarşik bir anahtar değer deposu faturaya mükemmel bir şekilde uydu. Anahtar değer mağazasının üst düzey anahtarları, abone edilebilecek konulardır. Her bir üst düzey anahtarın altındaki iki katmanlı bir harita vardır – haritalar(string, map(string, string)). Bir üst düzey anahtarın altındaki verilerdeki herhangi bir değişiklik bu anahtarın tüm abonelerine yayınlanır. En iç haritadaki değerler aynı zamanda zaman etiketli. Her veri kaynağı kendi zaman etiketlerini kontrol eder ve doğru düzeni tanımlar. Haritalar (haritalar, haritalar, haritalar) Verilerin tipik bir değişikliği, “yüksek seviye 10’a eşit” değişikliğine “yüksek seviye 11’e eşit” gibi bir şeydir. oyuncular oynarken, bu gibi her türlü güncelleştirmeyi tetiklerler, bu da tüm olayların devam etmesinde birçok küçük yazıyı içerir. Doğru veri tabanını bulmak Minimalizm ekibini göz önünde bulundurarak teknik gereksinimlerini destekleyecek ve yönetilebilir bir veritabanına ihtiyaç duydular. Düşük latanslı çok sayıda küçük yazılım kullanır Hierarşik bir veri modeli desteklemek Bir hizmet olarak yedekleme ve kümelenme işlemlerini yönetir ScyllaDB Cloud mükemmel bir uyum sağladı. (ScyllaDB Cloud, ölçüde öngörülebilir düşük gecikme sağlayan bilinen bir veritabanı olan ScyllaDB'nin tamamen yönetilen sürümüdür). Her şey nasıl oynanır Bu Supercell oyunlarında nasıl oynanacağına dair bir fikir edinmek için, iki örneğe bakalım. İlk olarak, sohbet mesajlarını düşünün. basit bir sohbet mesajı veritabanında şu şekilde temsil edilebilir: Edvard şöyle açıklıyor: “Öncelikli anahtar, sohbet odası ID’dir. Sonraki düzey anahtarı bir zaman etiketli UID’dir, bu nedenle her mesajın bir sıralaması vardır ve sohbet geçmişini sorgulayabiliriz. Sonraki olarak, Supercell'in yeni (ve çok beklenen) oyununda kullanılan "varlık"a bir göz atalım. mo.co. Varlık hedefi, Edvard'a göre: "Savaş için bir araya geldiğinizde, avatarınızı ve arkadaşlarınızın mevcut yapılarını gerçek zamanlı olarak görmek istiyorsunuz - temelde arkadaşlarınızın silahları ve ekipmanları, yanı sıra ne yapıyorlar. Players’ state data is encoded into Supercell’s hierarchical map as follows: Note that: Üst seviye oyuncu kimliği, ikinci seviye türü ve iç haritası verileri içerir. Supercell ID’nin verileri anlamasına gerek yok; sadece oyun müşterilerine iletir. Oyun istemcileri arkadaş grafikini bilmek zorunda değildir çünkü yönlendirme Supercell ID tarafından ele alınır. Sistem mimarisi hakkında daha fazla bilgi Edvard tarafından sağlanan bir sistem mimarisi turuyla sona erelim. “Backend API’lere, proxy’lere ve olay yönlendirme / depolama sunucularına ayrılır. Konular olay yönlendirme sunucularında yaşar ve bunların arasında bölünür. Bir müşteri, müşteri konunun aboneliğini yöneten bir proxy’ye bağlanır. Proxy bu abonelikleri uygun olay yönlendirme sunucularına yönlendirir. Son noktalar (örneğin, sohbet ve varlık için) verilerini olay yönlendirme sunucularına gönderir ve tüm olaylar ScyllaDB Cloud’da devam eder. Her temanın birincil ve yedek parçası vardır. Birincil parçası düşerse, birincil parçası kayıp mesajları tespit etmek için her mesaj için hafıza sıralama numaralarını korur. İkinci parçası, sıralama numaraları olmadan mesajları iletir. Birincil parçası düşerse, birincil yükselir, istemci üzerinde bir durum yenilemeyi tetikler, aynı zamanda sıralama numaralarını geri yükler. Yönlendirme katmanları için API, bir konu, tür, anahtar, değer tuples serisini içeren basit bir olay sonrası RPC'dir. Her API'nin görevi sadece verilerini yukarıdaki tuple temsiline yeniden yazmaktır. Her olay abonelere yayınlanmadan önce ScyllaDB'de yazılır. API'lerimiz, bir API çağrısı başarılı bir yanıt verirse, mesaj ScyllaDB'de devam eder. Aynı olayı birden çok kez göndermek, güncelleştirmeyi istemciye uygulamak, aynı mesajı birden fazla sekans numarasının haricinde, idempotent bir işlemdir. Bağlantı yapıldığında, proxy tüm arkadaşlarınızı bulur ve konulara abone olur, aynı zamanda sizin ait olduğunuz sohbet grupları için de geçerlidir. Biz de bağlanan istemci için konulara abone oluruz. Bunlar, arkadaş istekleri ve çapraz promosyonlar gibi, istemciye bildirim göndermek için kullanılır. Router'ın yeniden başlatılması, proxy'den konulara yeniden abonelik yapar. Tüm yük dengeleme, aynı HTTP/2 bağlantısı üzerinden yapılan taleplerin proxy üzerinde aynı TCP soketi tarafından işlenmesini garanti etmek için TCP düzeyinde. Bu, başlangıç dinleme sırasında bellekte belirli bilgileri saklamamıza izin verir, bu nedenle diğer talepler üzerinde yeniden düzeltme yapmamız gerekmez. Herhangi bir HTTP/2 isteği ayrı olarak yük dengelemeye gerek kalmayacak kadar eşzamanlı müşterilerimiz var, çünkü trafiği her durumda eşit olarak dağıtıyoruz ve talepler farklı kullanıcılar arasında işlemek için eşit oranda pahalıdır. Proxy ve yönlendirici arasında kalıcı soketler kullanıyoruz. Bu şekilde, sorunsuz olarak saniyede on binlerce aboneliği tek bir yönlendiriciye gönderebiliriz. ” Oyunun sonu değil Tam teknik konuşmayı izlemek istiyorsanız, aşağıdaki oyuna basın: Ve oyun dünyasında ScyllaDB'nin rolü hakkında daha fazlasını okumak istiyorsanız, aynı zamanda okumak isteyebilirsiniz: Epic Games, Unreal Cloud DDC tarafından kullanılan büyük oyun varlıklarının küresel dağılımını hızlandırmak için NVMe ve S3'ün önünde ScyllaDB'yi ikili bir bellek olarak nasıl kullanıyor? Tencent Oyunları: Tencent Oyunları, Pulsar ve ScyllaDB ile CQRS ve olay kaynaklama modelleri temelinde hizmet mimarisini nasıl oluşturdu. Discord: Discord'ın ScyllaDB'yi nasıl kullandığını, büyük bir oyun platformundan dünyanın en büyük iletişim platformlarından birine geçerek büyük bir büyüme için kullanıyor. Epic Oyunları: Tencent Oyunları: Çatışma :
