g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

Tencent içerik platformu sisteminin mimari uygulaması

Yazar | Sun Zixun (yetkili)

editör | kül

Bulutun mikro hizmet mimarisiyle birleştirilmesiyle, üretim verimliliği etkin bir şekilde iyileştirildi; derin öğrenme, üretkenliğin gelişimini desteklemek için çeşitli içerik işleme alanlarına girmeye devam ediyor. Mesaj sistemleri, veri ambarları, bilgi işlem çerçeveleri ve depolama sistemleri gibi altyapı katmanlarının kademeli olarak iyileştirilmesi temelinde, büyük İnternet şirketleri iş altyapısına olan talebi daha da ileri götürdü. Altyapı ve üst katman iş arasında taşımak için acilen bir orta ofis sistemine ihtiyaç vardır. Orta ofis sistemi, aynı iş katmanının algoritma yeteneklerini, hizmet yeteneklerini ve iş yeteneklerini yüksek oranda bütünleştirir, etkin bir şekilde organize eder ve dinamik olarak planlar. Üst düzey işlere daha iyi yardım edin.

Mühendislik

selef

2015 yılında, içerik platformu (mobil QQ ve diğer içerik hizmetleri dahil olmak üzere Tencent'i taşıyan içerik platformu) orijinal olarak QQ resmi hesap sisteminden geliyordu (resmi hesap sistemi, QQ hizmet hesabı, abonelik hesabı, kırmızı zarflar ve diğer büyük ölçekli Event push, abonelik hesabı mesaj teslimi, materyal içerik yönetimi vb.). O zaman, resmi hesap sisteminin birkaç alt sistemi vardı: veri alt sistemi, mesaj alt sistemi, ilişki zinciri alt sistemi ve malzeme alt sistemi. Bir numara sahibinin kendi içeriğini hayranlara vermesi gerekiyorsa bu 4 alt sistemden geçmesi gerekir.

(mavi kısım)

(Alt sistem, bağımsız depolama mantığı veri akışı arayüzüne sahip bir sistemdir. Konsept, Sistem Analizi ve Tasarımının DFD alt sisteminden gelir)

En basit hayran gönderme senaryosunda, önce grup gönderme görevinin içeriğini yönetmek için malzeme sistemini kullanın, ardından hayran verilerini çekmek için ilişki zinciri alt sistemini kullanın ve mesaj göndermek için mesaj alt sistemi aracılığıyla bir grup gönderme görevi oluşturun. süreç, parametreyi elde etmek için malzeme alt sistemi ile etkileşime girmeniz gerekir.

2015 yılının ikinci yarısında içerik stratejisi yükseltilmiştir.Hesap sahibi tarafından platformdan gönderilen içeriklere ek olarak, çok sayıda başka dış işbirliği platformlarımız da bulunmaktadır. Şirketin diğer platformları üzerinden geldiler, o zaman mesaj göndermeye dayalı bu senaryoyu tekrar kullandık ve karşı tarafın bir grup gönderme görevi oluşturmasına izin verdik ve içerik işlenmek üzere malzeme kitaplığına girdi ve sonra ulaşabildik. hayranlar.

Ancak daha sonra tüm iş formu abonelikten Feeds akışına dönüştü ve orijinal hayran ilişkisi tavsiye haline geldi.Giderek daha fazla içerik işleme hizmeti ve artan içerik hacmi ile eski sistem artık bunu taşıyamadı. Bu yüzden eski sistemi güçlendirmemiz gerekiyor.

Bir dizi birleşik çok kaynaklı içerik kitaplığına sahip olmayı umuyoruz.İyi genişletilebilirlik çerçevesinde, çeşitli hizmet türleri, önceden tanımlanmış arayüzleri uygulayarak içeriğin işlenmesini tamamlayabilir, insan-makineyi birleştirebilir ve abonelere çıktı verebilir.

İçerik işleme hizmetleri, içerik güvenliği ve kalitesini (kalite değerlendirmesi, şiddet içeren pornografi, kabalık, unvan partisi, yazım hataları vb.), içerik modelleme özelliklerini (kategoriler, konular, etiketler vb.), içerik anlama ve oluşturmayı (kapak resimleri, özetler, yapılandırma, klipler, vb.).

(İçerik platformunun üst düzey görünümü)

Metin, çalışmanın ana mimari bölümünü tanıtır.

depolamak

fiziksel depolama

Ana hesap sahibi tarafından içerik göndermek için orijinal malzeme sistemi, içerik platformunun en eski prototipi haline geldi.Malzeme, kullanıcı tarafından gönderilen içeriği depolamak için hala MySql aracılığıyla saklanıyor.Metin ve html tarafından oluşturulan tüm sayfa stilleri de saklanır. bir tabloda ve tek tablo bunalmış durumda.Denenmiş bölüm Sql yürütme optimizasyonu vb, ancak boşuna. İçerik çağında, onu desteklemek için daha yüksek performanslı bir depolama sistemine ihtiyacımız var. O zamanki teknik seçenekler, malzeme sisteminin geçmişteki acı noktalarına ve gelecekte desteklenecek skalaya göre değerlendirildi.

İsteğe bağlı alan uzantılarını, Schema Free'yi desteklemek için depolama sistemimize ihtiyacımız var. Sütun konumlandırma verimliliğine göre ölçeklendirilmesi kolay O(1) olmalıdır

Depolama sistemi kalıcı depolamayı desteklemeli ve aynı zamanda Redis gibi onbinlerce /s gerektirmese de en azından binler düzeyinde olması gerekir.

Çok makineli yatay genişlemeyi desteklemesi gerekiyor.

Şirketin işletme ve bakım için olgun bir ekibi var.

Mongodb ve Hbase, Cassandra ve diğer KV mağazaları o zamanlar düşünülmüştü.

Mongodb'un faydaları çoktur. Ancak yüksek verimli erişimi, büyük bir bellek kaynağı yükü getiriyor. Sıcak ve soğuk, kontrol edilemeyen eşzamanlı yazma ve replika depolamanın eşit olmayan dağılımı, önümüzdeki birkaç yıl içinde daha büyük bir gelişmeyi gerçekleştirememesine neden oluyor.

Diğeri ise Hbase.Hbase'i KV online hizmeti olarak kullanmamız gerekirse bu dayanılmaz olurdu ama bu sorunu çözmek için üzerine bir KV cache ekleyebiliriz, gerisi bize kalırdı. Hbase ve bellek KV veri senkronizasyonunu desteklemek için bir orta katman oluşturmak.

Hbase'in satır anahtarı + sütun ailesi + sütun niteleyicisi + zaman damgası + değeri, HFile'daki veri düzenlemesinin temelidir. Buna göre HFile veriyi satır düzeyinde değil veri bloğu düzeyinde indeksler.

Ek olarak, başlangıçta, KV belleği ve kalıcı depolamayı bir araya getirebilen, ancak birincil sürümü yapmış olsak bile, o zamanki ortamda LevelDB tabanlı yeni bir içerik ara katman yazılımı çözümü olan bir çözüm düşünüldü. daha önce hızlı yapamadık Geliştirildi ama Hbase'in avantajı bir süre KV erişimini destekleyebilmesidir.İleride optimizasyonu destekleyemeyecek ve Önbelleği artıramayacak.Aslında, bunu daha sonra yaptık.

Buradaki depolama işiyle ilgili olarak, depolama ara katman yazılımı RCS'ye nasıl evrimleştiğimizden daha sonra bahsedeceğiz. Depolama ile bir sonraki adım, depolama katmanının veri modelinin nasıl tasarlanacağıdır.

veri modelleme

2016'da depolama modeli tasarlanırken birkaç şey doğrulandı:

İçerik işlemede, içeriği paralel olarak işlemesi gereken çok sayıda modül mutlaka olacaktır;

Bu modüller, ortak mülk edinimlerinin yanı sıra özel mülk edinim gereksinimlerine sahiptir.

Modüllerin kendileri, diğer modüller tarafından kullanılmak üzere birbirlerine çıktılar üretir.

Hedefimiz:

Mimari açısından, tüm modüllerin depolamayı okuması ve yazması gereken senaryoları barındırmak için birleşik bir depolama oluşturulur, böylece her modüldeki öğrenciler birleşik bir şekilde depolayabilir. İşletme sınıf arkadaşlarının iş mantığı alanı olup olmadığı. Veya algoritma sınıf arkadaşlarının model iş çıktısı veya model özellik çıktısı. Geliştiricilerin stratejinin kendisine daha fazla dikkat etmesi gerekiyor ve depolamadaki her şey API'ler sağlamak için birleştirilmelidir.

Tablo yapısında:

İlk noktaya ulaşılırsa, gelecekte bu geniş tabloya dayalı doğal tek tablo alımı ve tek tablo temel içerik özellik madenciliği yapabiliriz. Algoritma deney alanları bile geniş bir tabloda birleştirilebilir.

Bu yüzden birkaç önemli tasarım yaptık:

1. Yeni benzersiz kimlik sistemini tanıtın, resmi hesabın kendi kendine artan makale kimliğini kaldırın ve kimlik aşağıdaki özellikleri destekleyebilir:

Kimlik sistemi = ayrılmış alan + zaman + otomatik artış kimliği + içerik türü + iş kaynağı

Yani rowkey ile herhangi bir rowkey elde edersek, en azından ilk bakışta kaynağın yaklaşık zamanını ve türünü bilebiliriz, bu da yönlendirme için uygundur.

2. Sütun adlarını standartlaştırın.Tüm sütun adları [durum sınıfı] ve [içerik özellik sınıfı] olarak ayrılır.İlki, durumu işaretlemek ve durumu ele almak için kullanılır. İkincisi, içeriğin temel meta bilgilerini, modül işleme sırasında üretilen sonuç bilgilerini ve ara bilgileri kaydetmek için kullanılır. O zamanki sütun yapısı kuralının formatı şuydu:

Sütun adı = sütun özelliği (eyalet sınıfı veya işletme sınıfı veya model sınıfı) + alan sahibi + alan açıklaması

eyalet sınıfı

Model sınıfı

O zamanlar tahmin edilemeyen şeyler, şimdi düşünülmesi gereken birkaç şey var:

İş alanları farklı iş senaryolarına göre "polimorfizm" üretebilir.Dilde çok iyi çözülen bu sorun, depolama katmanına düştüğünde birçok soruna neden olacaktır. İş senaryoları arasında, birden fazla işletmenin aynı içeriğin başlık ve kapak resmi için kendi alt sınıfları olabilir ve senaryo kavramının eklenmesi gerekir.

Orijinal varsayım, yürütmenin bir ağaç veya grafik gibi derin bir geçiş DAG olduğu ve döngü dönüşü olmayacağıydı.Aslında, bu senaryo gerçekten gerçekleşir.

Alanların üstel genişlemesi ile birlikte sütun adlarının çökme ve dağıtım için iyi planlanmaması, geliştiricinin organizasyon yapısını karmaşık organizasyon yapısından sonra kontrol edilemez hale getirmekte ve makul bir daraltma ve dağıtım yöntemine ihtiyaç duyulmaktadır.

Buradaki veri modelimiz geniş bir tablo formatı kullanıyor Karmaşık EVA depolama ile karşılaştırıldığında, geniş tabloların veri özeti istatistiklerine daha elverişli olduğunu düşünüyoruz. Sonraki RCS bölümünde tekrar tanıtılacaktır.

Geniş tablolar daha işlemseldir. HBase, işlem atomiği ile bir satıra (Put) yazar.Bir satırdaki tüm sütunlar ya başarılı bir şekilde yazılır ya da hiç yazılmaz. Ancak birden çok satırın güncellemeleri arasında işlem garantisi yoktur.

Çevrimiçi mevcut gerçek durum, tek bir makale tablosunda 500'den fazla seyrek sütun bulunması ve iş senaryolarının artmasıyla sayının artmasıdır. Test verileri doğrulaması, sütun arttıkça arama ek yükünü etkilemez.

İlgili karşılaştırmalar için şunu okuyun:

https://stackoverflow.com/questions/16447903/table-design-wide-table-vs-columns-as-properties

süreç modelleme

Esas olarak hizmetlerin tasarım ayrımını tanıtır.Buradaki hizmetler, kod dönüştürme, iş mantığı işleme gibi iş yeteneği hizmetlerini ve model algoritmalarıyla ilgili hizmetleri içerir. Veri akışına mimari bir yaklaşım da vardır.

Hizmet Katmanı Mimarisi

Herhangi bir hizmeti L0-L2 olmak üzere üç katmana ayırırız.Katman 0 atomiktir, bu iş senaryolarının durumsuz temel yetenekleri için uygun değildir.NLP uygulamalarında kullanılıyorsa, aşağıdaki şekle benzer:

Çekirdeğin IO_DIRECT desteğine benzer şekilde, VFS, işletim bloğu cihaz katmanına doğrudan erişim sağlar. Model hizmetimiz ayrıca, doğrudan iş mantığının ötesinde, temeldeki temel yeteneklere erişimi de destekleyebilir.

(Linux io ile ilgili özel referans

Herhangi bir hizmeti geliştirirken öncelikle hiyerarşik ilişkiyi çözeriz. [Harici protokoller ve arabirimler] Paralelleştirilmiş bulut tabanlı olağanüstü durum kurtarma aşırı yük koruması ve kaynaştırma dahil olmak üzere saf mühendisler tarafından sağlanan kod çerçevesi burada birleştirilebilir.

İş testinin algoritma ekibi, L1-L2 katmanının iş geliştirmesini gerçekleştirmek için diğer halk kütüphanelerinin L0 veya L1 katmanının yeteneklerini kullanır ve mühendisler ayrıca L2 katmanını birlikte geliştirebilir.

(Servis modülündeki katmanların şematik diyagramı)

Bir hizmeti aşağıdaki boyutlara göre ayırt edebiliyoruz ve aşağıda belirtilen sevk merkezi bu boyutlara göre farklı işleme stratejileri gerçekleştiriyor.

Küresel bilginin gerekli olup olmadığı:

Geçmişte işlenmiş tüm içeriğin çıktısının gerekli olup olmadığı, bir içeriğin işlenmesini ifade eder. Örneğin, veri tekilleştirme veya homojenleştirilmiş içerik denetimi, geçmişte biriken içerik işleme durumuyla mantıklı olmalıdır. Artımlı + tam senkronizasyon.

İster güçlü iş mantığı

Sözde güçlü iş mantığı, hizmetin iş mantığıyla güçlü bir şekilde ilişkili olup olmadığı ve iş senaryosundan bağımsız olabileceği anlamına gelir. Kapak resminden alıntıdır.

Farklılıklar şu şekildedir: iş stratejileri ile güçlü bir şekilde ilişkili olan homojen içerik kontrolü.Farklı iş senaryoları, stratejilerin özelleştirilmesi olasılığına sahiptir.Dosya sistemlerinin uygulanmasına benzer şekilde, ext4 xfs vardır. Aynı etiket çıkarma hizmeti, farklı dikey kategoriler için farklı iş stratejilerine de sahip olacaktır.

servis edilebilir mi

Genel olarak konuşursak, hizmetin kendisinin iş mantığı ne kadar zayıfsa ve diğer işletmelerin küresel bilgilerine bağlı değilse, görüntü etiketi çıkarma, unvan partisi gibi üçüncü taraflara birleşik hizmetler sağlayabilir.

Bu tür bir hizmet, hizmetin kendisinin bilgilerini tam olarak çıkarabilir ve kullanım için üst düzey iş tarafına sağlayabilir.

Eşzamansız olarak işlemek mümkün mü

Asenkron olup olmaması hizmet işlemenin zaman verimliliğine bağlıdır.İşlem süresi gerçek zamanlı geri dönüşü garanti edebiliyorsa, asenkron için fazla talep yoktur.Bazı hizmetler kesinlikle kapak resimleri gibi belirli iş senaryolarına bağlıdır, devam edebilmeleri için işlenmesi gerekir. . Homojenizasyon kontrolü gibi önce açığa çıkarılabilen ve ardından kaldırılabilen bazı hizmetler, içerik çevrimiçi olduktan sonra yürütülebilir ve güncellenebilir.

Herhangi bir ön bağımlılık var mı?

Önceden bağımlı hizmetler varsa, bu hizmet, önceki birkaç hizmetin işlenmesi tamamlandıktan sonra yürütülmelidir.

Örneğin, video ağırsa, önceki video karesine dayanması gerekir ve devam etmeden önce ses parmak izi hizmeti tamamlanabilir. Görev grafiğindeki bağımlı hizmet öncesi hizmetlerin üst düğümleri tamamlandıktan sonra hizmetin başlatılması gerekir.

Bir hizmeti geliştirmeden önce anlaşılması gereken birkaç boyut olduğuna inanıyoruz. Örneğin şimdi xLab'ın etiketleme yeteneklerini tanıtmamız gerekiyor, bu boyutlara kapsamlı bir şekilde bakalım.

Geçmişte, hizmetin iş senaryosuna derinlemesine girmesi gerekip gerekmediği konusunda birkaç fikrimiz vardı.Buradaki sorun, güçlü model yeteneği ile ilgili iş mantığının hizmetin kendisinde uygulanması gerekiyorsa, çünkü bu daha fazla olabilir. iş mantığı ve algoritma çıktısına elverişli Bir bütün oluşturmak için birbirleriyle işbirliği yapın.Geliştiriciler için işin ihtiyaçlarını anlamak, işletme departmanının algoritma personelinin etiketleme, tekilleştirme, algoritma özelliklerinin kullanımı gibi dikkat etmesi gereken şeydir. modül içinde ve yüksek derecede iş mantığı uyumu.

süreç işleme

Brendan (aynı zamanda Kubernetes'in yazarı, şimdi Microsoft'ta, eski Google Cloud'da) 2018'de Designing Distribution System adlı yeni kitabında 2015'ten beri denediğimiz birkaç yoldan bahsetti ve neredeyse benzer kalıplar ve şeyler yaptı ve duyguyla ilgili deneyimleri özetledi. tek şey bu kitabın sadece 18 yılda basılmış olmasıdır. (Yol Güveni, Teori Güveni, Kültürel Güven )

Brendan, bu çok aşamalı, çok modüllü işbirlikçi işleme yöntemini Toplu Hesaplamalı Modeller olarak adlandırır.

(Olay Odaklı Toplu İşleme iş akışının şematik diyagramı)

(İçerik merkezinin basitleştirilmiş sürümünün video işleme iş akışının şematik diyagramı)

İşleme çerçevemiz birkaç aşamadan geçer.

Toplu mod (2016):

Başlangıçta tam ademi merkeziyetçilik fikri. O zamanlar arka plan sıkıydı ve inşa edilecek birçok modül vardı. 2016 yılında, ondan az kişiden oluşan bir ekiple, kütüphaneye erişim, görüntülerin ve metinlerin tekilleştirilmesi, kapak görüntüleri, harici yetenek yerleştirme, bazı erken kaliteli modeller ve dahil olmak üzere tam bir hevesle yaklaşık yüze yakın modül geliştirdik. videolar.Eski kamu hesabı sisteminin gelişimini dikkate alarak kod dönüştürme, tarama vb.

Dahili: Şu anda, her şeyin hızlı bir şekilde ilerlemesi gerekiyor. Modüller, depolanmış durum değişiklikleri aracılığıyla birbirleriyle etkileşime girer. Geliştiriciler, yüksek düzeyde özerktir ve model yeteneklerinden ve iş senaryolarından sorumludur. Her hizmet işlevsel birimi, yüksek uyum ve düşük bağlantıya sahiptir. Durumu izlemek ve değişiklikler üretmek için tarama deposunun durum alanına güvenmek.

Dış: 2016'nın ortasında, alt işlerin artması nedeniyle, birbirleriyle etkileşimin gevşek bir şekilde bağlanması gerekiyor, tek bir modül tarafından tahsis edilebilecek işlem süresi sürekli olarak sıkıştırılıyor ve temel bir çoklu üretim var. ve çoklu tüketim modeli. Birden fazla alt iş tarafı CMS, öneri vb. ile bağlantı kurmak için bir mesaj kuyruğu mekanizması sunuyoruz. İçeriğin giriş/çıkışlarını ve durum değişikliğini bildirin.

Olay Odaklı Toplu Mod (2017):

O zaman 2016'da görev çizelgeleme vardı ve tüm modüller tartışıldıktan sonra, yönetim arayüzü acil durumlarda çizelgelemeyi kabul etmek için ayrıldı. Ayrıca mesaj kuyruğunu artırmanın yolunu doğrudan değiştirdiği de düşünülmüştür. 2017'nin başında, sıcak içerik, içerik işleme için yüksek bir zamanlılık ortaya koydu.O zaman, birkaç öğrenci, tetikleme ve tersine çevirme için merkezi bir zamanlama hizmetinin gerekli olup olmadığını tekrar tekrar tartıştı. Aşağıdaki senaryolar ortaya çıktı:

Seçenek 1.1'in avantajları şunlardır:

Küresel merkezsiz modül. Herhangi bir modül, bir arıza durumunda kendisini halledebilir.

Gevşek bağlı modüller, mesaj kuyrukları aracılığıyla birbirleriyle iletişim kurar.

(1.1 Modeli)

O zamanlar 1.1 ve 2.0 setler üzerine çok tartışmıştık.

Amaç olaya dayalı desteği desteklemektir, ancak sahipsiz mesaj kuyruğu yöntemine devam etmek (topoloji yapılandırması yapılandırma merkezi aracılığıyla yönetilebilir) veya hizmetin tetikleyici mantığını kontrol için sevk merkezine toplamak aslında teknoloji odaklıdır. ve iş odaklı sorun. Sonunda işletmeyi seçtik.

Sevkiyat merkezinin konumu:

Sevk Merkezi = Olay Sürücüsü (Topoloji Yönetimi) + Akış Kontrolü + Olağanüstü Durum Kurtarma + İzleme (Performans, Çağrı Zinciri İzleme)

Seçenek 2.0'ın avantajları şunlardır:

İş modülleri arasında işleme zamanlaması bağımlılığı yoktur.

Sevkiyat merkezi, birleşik kapasite modeline göre modüllerin eşzamanlı işleme isteklerinin sayısını dinamik olarak ayarlayabilir.

Sevkiyat merkezi, kaynağa göre birden çok topolojiyi koruyabilir ve yapılandırma sunucusu rolünü oynayabilir.

(2.0 sevk merkezi sağ alt köşesi)

Depolama katmanı ve hizmet öz kayıtları ile birleştirilebilen iyi bir zamanlama çerçevesi olarak 2.0'ı seçtik.

Genel çerçeve

Sevkiyat hizmetinin bu işlemleri gerçekleştirebilmesi ve bunları temeldeki RCS deposuyla birleştirebilmesi için bir dizi işleç soyutlayabilir ve tanımlayabiliriz. Üst arayüz, çeşitli servisleri doğrudan sürükleyip bırakabilir, operatörü belirleyebilir ve inşaat iş akışını görselleştirebilir.

Filtre:

Geçirilen içeriğin zorla filtrelenmesi, genellikle temel güvenlik filtrelemesi ve depolamada saldırıya uğrama riskini azaltmak için yüksek içerik doğruluğu altında tekilleştirme için kullanılır.

Fotokopi:

Mevcut alanları devralarak bir içeriğin birden çok sahne içeriğine çatallanmasını destekler. Bu şekilde, bir içeriğin işlenmesi, sonraki işlemeye devam etmek için birden çok eşe bölünebilir. Depolama katmanında, aynı yabancı anahtarın ana kaydı işaret ettiği birden fazla kayıt vardır.

Bölücü:

Çok kanallı bölme, depolama katmanı tarafından oluşturulan ortak alanlara göre, iş işleme mantığını dallanma ve şöntleme. Örneğin, ana hesaba birkaç kalite puanının altında bir mesaj gönderirken. Farklı işlemler için yüksek kaliteli ve düşük kaliteli olarak ayrılmıştır (gri tonlamalı, gözden geçirilip geçirilmeyeceği vb.).

Zamanlama, hizmet arabirimini çalıştırmak için her hizmet tarafından uygulanan şablon modunu kullanır ve harici hizmetler, arabirimin birleşik olduğundan emin olmak için bağdaştırıcı modunu birleştirebilir. Bu tür işlemleri soyutlayarak, yerel depolama ve zamanlama ve hizmet çerçeveleri birbiriyle birleştirilebilir.

(İş akışı ve hizmet oluşturmanın şematik diyagramı)

genişletmek

İş akışı tasarımında Orkestrasyon ve Koreografi olmak üzere 2 ana kamp vardır.

bakınız:

https://wso2.com/blogs/thesource/2016/03/orchestration-and-choreography-while-to-use-an-esb-vs-a-workflow-engine/

İlki, tüm iş mantığının birleşik kontrolünü kolaylaştıran ve izlemeyi ve zamanında müdahaleyi kolaylaştıran merkezi planlama hizmetlerine odaklanır. Dezavantajı, bağlantının çok yüksek olması ve şişmesi ve her hizmetin kendi değerini kaybetmesi kolay olan saf bir yetenek modeline dönüşmesidir.

İkinci saf olay, olayı izleyen ve değiştiren, aktif olarak olay işlemeyi elde edecek ve talep üzerine kendi mesajlarını yayınlayabilecek her hizmeti yönlendirir. Avantajları, düşük bağlantı ve yüksek uyumdur ve teknisyenler tamamen özerktir. Dezavantajı, iş süreçlerinin aboneliklerle temsil edilmesi ve izleme için ek çağrı zinciri izleme çerçevelerinin eklenmesi gerekmesidir ve ek müdahale gerektiren hizmet kesintileri olabilir.

2.0 modelimiz her ikisinin de avantajlarını özümser. Gönderi merkezi, belirtilen işlem ilkelleri senaryosunda süreç mantığını düzenleyerek bir olay oluşturucu rolü oynar.Aynı zamanda, karmaşıklığı önlemek için her hizmet L2 katmanının iş mantığını korur koordinatlar iş. değişiklik.

zamanlama hakkında

Sınıf arkadaşlarımız şirketin teknik incelemesinden her geçtiğinde bir sorunla karşılaşacaklar, neden fırtına kullanmıyorsun. Aslında burada durum bu. Storm'un kendisi aslında gerçek zamanlı veri akışı için bir zamanlama çerçevesidir ve Torque gibi iş planlama gibi iş mantığını içermez. Kullanıcıların Topology'de kendi zamanlama mantığını yazmaları gerekir. Çıkış ucu ve cıvata birimleri, kullanıcıların sabit bir çerçeve altında veri akışıyla etkileşime girmesini gerektirir.

Bu temelde özerk alanımızı sınırlar:

Blot ekleme ve değiştirme, topolojinin yeniden başlatılmasını gerektirir ve sıcak olarak güncellenemez.

Çok boyutlu iş nesnelerinin algoritmik mantık işlemesi için değil, gerçek zamanlı veri istatistikleri için uygundur ve özel işlem temellerinin kullanıldığı senaryolar için uygun değildir.

Kendi geliştirdiği çerçeve ile karşılaştırıldığında, sistem işletimi ve bakımı daha dolambaçlı olacaktır, ikincisi sadece algoritma modelinin öğrencileri için protokolü standartlaştırmaya ihtiyaç duyar ve fırtına dili esas olarak Java'yı destekler.

Yukarıda belirtilen eşzamansız olarak dönen hizmetler için yerel destek yoktur.

içerik akışı

Workflow'dan bahsettikten sonra Dataflow'a bir göz atalım. Cambridge Martin Kleppmann'da (dağıtılmış sistemler uzmanı ve başka bir Akış İşleme kitabının yazarı) başyapıtı: Veri Yoğun Uygulama Tasarımı, Martin, bir veri akışı sisteminin verileri (bu durumda içerik verilerini kastediyoruz) bir hizmetten çeşitli şekillerde dönüştürdüğünden bahseder. başka bir servise gönderilebilir:

(Orijinal kitabın ekran görüntüsü) Yazılım mühendisliğinde tüm veri akışları bir veri akış şeması ile tasarlanmalıdır (Veri Akış Şeması)

içerik aboneliği

Dahili hizmetlerimiz arasındaki erken veri akışı ve paylaşımı, Model_1'in Veritabanlarına dayalı olmasıdır.Verilerin tutarlılığını sağlamak için katı zamanlama ile alanların sütunlarını ayırıyoruz.

Daha sonra Workflow 2.0 dönüşümü ile geniş tabloların model alanlarına ve iş alanlarına ayrı ayrı erişiyoruz. Sevkiyat merkezi ve servis arasında, geniş tablonun iş alanları Model_2 arabirimi aracılığıyla eşit olarak iletilir.

Sistem ve sistem arasında (aşağıdaki şekilde noktalı kutu), Model_3'ün mesaj kuyruğu veri yolundan geçiyoruz. Harici birleşik senkronizasyon, mesaj kuyruğu veriyolu aracılığıyla gerçekleştirilir.Veriler artımlı ve tam verileri içerir ve çok durumlu sürüm kontrolü benimsenir.Farklı işlem durumları farklı sürüm numaralarını kullanır. Aynı zamanda, iş tutarlılığı ve diğer senaryoların gereklilikleri ile, harici de tarafımızca sağlanan veri ara katman hizmeti RCS aracılığıyla Model_3 yani iş verilerini okuyabilir ve yazabilir.

(İçerik platformu Dataflow'un şematik diyagramı)

İçerik ara yazılımı

2017'nin ikinci yarısında, veri senkronizasyonu gerektiren iş senaryolarının sayısı arttıkça, birden çok iş senaryosu arasındaki içerik verilerinin tutarsız olduğunu gördük. Aynı zamanda, birden çok işletmenin temel alınan veritabanına doğrudan erişmesi gerekecektir. Bu nedenle, birden fazla iş senaryosunun bir kopyası olan bir depolama seti, birden fazla iş senaryosuna birleştirilmiş bir şekilde erişimi destekleyen bir depolama kümesine dönüştürülmüştür.Aynı zamanda, daha önce harici olarak senkronize edilen Model_2 mesaj teslim yöntemi ile birleştirilmiştir. yukarıdaki şekilde RCS olan bir bileşen.

Depolanan veri ara yazılımı da üç katmana ayrılır: L0, L1 ve L2.

L0: Cproxy, temeldeki depolamaya erişmek için veri katmanının uzaktan olağanüstü durum kurtarmasına odaklanır.

L1: Sproxy, medya erişim yollarını depolamak için kullanılır ve OR-Mapping, harici sahne alanlarını birleştirir.Örneğin, bir kapak, farklı stratejilere göre farklı model deney gruplarının kapak sütununa eşlenebilir ve harici olarak ekranlanabilir.

L2'nin en üst katmanı olan Eproxy, tüm iş katmanının mantıksal kontrolü için kullanılır.

(RCS bileşeni, üç katmanlı proxy L0, L1, L2'ye karşılık gelir) (HBase'in kendi replikasyonu ana veritabanının yazma hızını yavaşlatacaktır ve veriler bizim temel varlığımızdır. 2017'de uzak soğuk yedeklemeye proxy yazmayı eklemeye başladık. . ve çerçeve seviyesi ile düzenli olarak anahtarlama tatbikatları gerçekleştirin)

RCS'nin detaylarına ilerleyen zamanlarda değineceğiz.Belirtilmesi gereken birkaç nokta var.Buna depolama katman yazılımı denilebilir.

Depolama katmanındaki tüm işlemleri daraltın.

Herhangi bir alana doğrudan erişim desteklenir ve izin kontrolü eklenir.

Yerleşik MQ aracılığıyla harici gerçek zamanlı veri istatistikleri hizmetlerine bağlanmayı, boru hatlarını bilgilendirmeyi ve veri işlemlerini güncellemeyi destekler.

Hbase'in çoğaltmasından daha iyi çoğaltma mekanizması.

Benzer çalışma: Xiaomi, açık kaynak bileşeni Pegasus 1.11.0'ı Eylül 2018'de yayınladı.

içerik alma

RCS verilerinin gerçek zamanlı olarak ES ile senkronize edilebilmesi ve ELK üzerinden çok boyutlu alma ve trend incelemesinin yapılabilmesi için bir iş yaptık. Tam içerik madenciliği vb. için Hive ile senkronize edin. Geniş tablo ile aşağıdaki komutu kolayca uygulayabiliriz:

Kıtlık deneyi B tarafından kazılan belirli bir süre içinde kapak görüntüsünün puanı > 8 noktalı ve 3'ten az etiketli toplam video sayısı.

(ELK tabanlı izleme görünümü)

sonunda yaz

Mühendislik geliştirme öğrencileri sayesinde, alexcxu carrickliu ericxjiang guangyupeng jianxunzou jamescxchen mamoyang maplechang marcopeng taoyang tedqian xiaoccwang yuliangshen ve yetenek modeli öğrenciler chenchwang lshzhang haodeye yaprakxin louislwang yu u dondong ve vindong qyutianyu yutyan mühendisi kim çalıştı vindong qyutianyu yui dondong ve vindong q yutianu yuliang yuliang yuliangu geçmişte.

yazar hakkında

Sun Zixun, (Tencent/SNG İçerik Platformu Departmanı/Platform Ürün Merkezi/Algoritma Platformu ve Sahne Arkası Ekip Lideri), 11 yıldır Baidu'da yüksek performanslı algoritmalar üzerinde çalışıyor. 2012'de Tencent'e katıldı ve 2015'te QQ resmi hesap platformundan ve içerik merkezinin arka ucundan sorumluydu ve ekiple birlikte QQ içerik platformunu sıfırdan kurdu. 2016 yılında algoritma araştırması ve içerik işleme yeteneklerinin uygulanması ile uğraştı.

Bugün, geçen hafta geri dönen süper kahraman dramından bahsedelim - "The Punisher" ın ikinci sezonu

Gerçek koku makinesi: Kutudan çıkan iPhone XR konuşma