Ant Financial'ın 100 milyon düzeyinde eşzamanlılık altında mobil uçtan uca ağ erişim mimarisinin analizi
Önsöz
Alipay'in mobil terminal mimarisi, üç aşamalı yinelemeyi ve araç uygulamalarının, platform uygulamalarının ve süper uygulamaların kademeli olarak iyileştirilmesini tamamladı.
Bu paylaşım, Alipay'in mobil ağ erişim mimarisindeki özel gelişiminin yanı sıra yeni yıl kırmızı zarflarına ve milyar düzeyindeki eşzamanlı senaryodaki diğer projelere verilen özel tepkiye odaklanacak. Ek olarak, Ant Financial'ın mobil ağ teknolojisinin ticarileştirme için nasıl uygulanabileceği ve ihraç edilebileceği konusundaki tartışmayı genişleteceğiz.
1. Ant Financial Mobil Ağ Erişim Mimarisi Evrimi
Alipay mobil ağ birinci nesil mimarisi
Alipay kablosuz ekibi 2008 yılında kuruldu. O zaman, Alipay uygulamasının genel mimarisi basitçe tek bir uygulama mimarisi olarak adlandırılabilir. Tek bir uygulama, https üzerinden iletişim kuran istemci APP ve sunucu olmak üzere iki bölümden oluşur.
Kablosuz hizmetlerin aşamalı olarak gelişmesi nedeniyle, birçok hizmetin PC'lerden kablosuza taşınması gerekiyor ve daha fazla geliştirmenin kablosuza yatırım yapılması gerekiyor, ancak mevcut mimari birden çok hizmetin ve birden çok ekibin paralel Ar-Ge'sini destekleyemiyor. Her işletme fonksiyonunun bir şube çekmesi gerekir ve N işletme aynı anda N şubeyi çekmelidir.Kodu birleştirmek de çok zahmetlidir ve tüm mimari büyük bir darboğaz haline gelir.
Alipay mobil ağ ikinci nesil mimarisi
2013 yılında, Uygulama mimarisini yükselttik ve API ağ geçidi mimarisini kullanıma sunduk: arka uç hizmeti, çeşitli hizmetlere ayrıştırılabilen harici hizmetler sağlamak için bir arayüze dönüştürülmüştür.Her sistemin geliştirilmesi ve yayınlanması diğer sistemlerden farklıdır. Ağızdan ağıza APP ve Alipay ana APP gibi çoklu terminal uygulama erişimini destekler.
En önemlisi, mobil bir RPC araştırma ve geliştirme modeli sunduk. Çok terminalli kod üretebilen bir ara DSL tanımı var. RPC çerçevesi ortadaki tüm iletişim ayrıntılarından sorumludur ve müşterinin yalnızca işi önemsemesi gerekir.
API ağ geçidi mimarisi, API geliştirmeden yayınlamaya ve çevrimiçi, yapılandırmadan, çevrimiçi hizmete, hizmet operasyonuna, vb. Ve son çevrimdışı duruma kadar süreç olarak tanımlanabilen eksiksiz bir API hizmet yaşam döngüsü sağlar. Ar-Ge desteği döneminde kod oluşturma ve API test araçları gibi birçok araç yaptık. Hizmetin çevrimiçi hale geldikten sonra çalışması için, API yanıt süresi, veri aktarım boyutu, yanıt süresi vb. Gibi her API'yi puanlama dahil olmak üzere eksiksiz bir izleme sistemimiz var, örneğin, hata oranı yasal bir değeri aştığında, bir e-posta gönderilecektir. Erken uyarı. Ayrıca birçok istemci ve sunucu tanılama işlevi gerçekleştirdik ve tam platform uygulama desteği sağladık.
Ek olarak, kablosuz RPC mekanizmasını tanıttık.
Araştırma ve geliştirme sırasında, sunucu sınıf arkadaşları arayüzü açar, hizmeti otomatik olarak çeker ve ağ geçidi arka ucuna bağlanır; iş sınıfı arkadaşları her istemcinin RPC kodunu oluşturabilir ve entegrasyon için istemci sınıf arkadaşlarına gönderebilir; istemci sınıf arkadaşları, ağ geçidine ve ağ geçidine göndermek için RPC kodunu kullanır. İşletme sunucusuna iletin. Tüm süreç çok basittir ve genel Ar-Ge verimliliği büyük ölçüde iyileştirilmiştir.
Alipay mobil ağ üçüncü nesil mimarisi
Alipay, 2015 yılından itibaren sosyal ağlar yapmaya başladı. Sonuç olarak, platform tabanlı mimarinin tasarımı ve optimizasyonu çok yakın ve yeni iş senaryoları da Uygulama kararlılığı için daha büyük zorluklar ve gereksinimler ortaya koyuyor, bu nedenle üçüncü nesil mobil erişim mimarisi ortaya çıktı.
İlk olarak, ağ protokolünü optimize ettik, istemci ile sunucu arasındaki iletişim mekanizmasını uzun bir bağlantıya dönüştürdük ve uzun bağlantı protokolü MMTP'yi özelleştirdik, ikincisi, SYNC mekanizmasını tanıttık, sunucu senkronize edilmiş verileri istemciye aktif olarak gönderebilir; Üçüncüsü, bilgisayar odası felaket kurtarma, beyaz liste planlama vb. Gibi çeşitli kişiselleştirilmiş programlamaya sahip mobil planlamanın tanıtımı.
Daha sonra ağ protokolünün optimizasyonuna detaylı olarak bakalım.
Ağ aktarım protokolümüzün alt katmanı SSL / TLS'dir. Ant, TLS1.3'e ve kendi geliştirdiği MTLS'ye dayanır. Üst katman, oturum katmanıdır. Başlangıçta HTTP'ye dayalıdır. Artık kendi geliştirdiği iletişim protokolü MMTP'yi temel alır, üst katman RPC, SYNC'dir, PUSH uygulama katmanı protokolü.
RPC, "istek-yanıt" iletişim modunu çözer; SYNC, "veriyi istemciye doğrudan ileten sunucunun" iletişim modundan sorumludur; PUSH, "geleneksel PUSH bildirimlerini iletmekten" sorumludur.
Ek olarak, HTTP2'yi yeniden tanımladık, H2 + özel çerçeve protokolünü tanıttık ve özel iki yönlü iletişimi destekledik. HTTP2 artık temelde yeni nesil iletişim protokolü olarak belirlendi ve ana akım tarayıcılar bunu zaten destekledi. Aynı zamanda, multipleksleme ve hpack yüksek oranda sıkıştırılabilir algoritmalar gibi birçok mobil ağ dostu özelliğe sahip olduğu için mobil terminale de tanıttık.
Daha sonra SYNC mekanizması hakkında konuşacağız.
Esasen SYNC, SyncKey'e dayalı bir senkronizasyon protokolüdür. SYNC'in ne olduğunu açıklamak için doğrudan bir "fatura sayfası görüntüleme" örneğini ele alalım: geleneksel anlamda, müşteri bu kişinin tüm faturalarını çekmek ister ve sunucuya bir RPC isteği gönderir.Sunucu, tüm verileri bir kerede geri çeker, bu çok masraflıdır. akış. SYNC mekanizmamız, trafikten tasarruf etmenin etkisini sağlayan diferansiyel verileri senkronize etmektir.Veri miktarı az olduğunda, iletişim verimliliği daha verimli olur ve müşteri sunucu verilerini elde etmede daha yüksek bir başarı oranına sahiptir.
Ek olarak, SYNC mekanizması için, istemcinin gerçek zamanlı olarak çevrimiçi olmasına gerek yoktur.Çevrimiçi olmayan kullanıcı için, SYNC Sunucusu fark verilerini veritabanına kaydedecektir. İstemci sunucuya bir sonraki sefer bağlandığında, fark verileri kullanıcıyla senkronize edilir. Alipay içinde, sohbet, konfigürasyon senkronizasyonu ve veri itme gibi senaryolarda SYNC mekanizmasını uyguladık.
Mobil planlama tasarımı ile ilgili olarak, mobil planlamanın alt katmanı aslında geleneksel LocalDNS yerine bir HTTPDNS'dir.
Geleneksel DNS ilk olarak DNS ele geçirme sorununa sahip olduğundan ve operatörlerin kendi DNS'sinin kalitesi dengesiz olduğundan, istek yanıtlarının kalitesini etkileyecektir.Ayrıca, LDC çok merkezli zamanlama gibi karmaşık özel zamanlama gereksinimlerini desteklemez. Bu nedenle, felaket kurtarma, strateji, kanal optimizasyonu ve LDC beyaz liste planlamasını destekleyen AMDC mobil planlamayı kendimiz yaptık.
Alipay mobil ağ dördüncü nesil mimarisi
Dördüncü nesil Alipay mobil mimarisinin evrimiyle ilgili olarak, esas olarak iki şey yaptık: birincisi, ağ kitaplığını birleştirmek; ikincisi, ağ geçidini merkezden uzaklaştırmak.
Bir yandan, istemci platformunun IOT RTOS gibi platformlara ek olarak iOS ve Android'i kapsaması gerekiyor ve gelecekte daha fazla terminalin desteklenmesi gerekiyor. Bununla birlikte, desteklediğimiz her platform için, bir dizi ağ kitaplığını yeniden geliştirmemiz gerekir; diğer yandan, istemci tarafı ağ kitaplığımızın nispeten zengin ve karmaşık stratejileri vardır. Genellikle her platformdaki strateji uygulamasının farklı olacağını görürüz. , Bu farklılıklar birçok beklenmedik soruna neden olacaktır.
Yukarıdaki iki noktaya dayanarak, C dilini farklı platformlarda çalışabilen birleşik bir ağ kitaplığı olarak kullanmayı düşünüyoruz ve tüm istemci ağ stratejileri ve zamanlaması birleşiktir. Bu, Ar-Ge maliyetlerini büyük ölçüde azaltır ve her ihtiyaç yalnızca bir Ar-Ge öğrencisinin yatırım yapmasını gerektirir ve farklı platformlar birleşik ağ kitaplığını yükseltebilir.
Sunucu tarafında, ağ geçidinin merkezi olmayan mimarisini yükselttik.Merkezileştirilmiş ağ geçidinin iki sorunu var: birincisi, kapasite planlama sorunu Şimdi tüm Alipay ağ geçidi platformunun her olaydan önce değerlendirilmesi gereken yaklaşık 10.000 arayüz var. Arabirimin istek hacmi, ancak en yüksek istek hacmini değerlendirmek zordur, her kaba kapasite alındığında; ayrıca, ağ geçidi sunucusunun maliyeti giderek yükselir, her bir etkinliğin iş hacmi büyüktür ve her seferinde büyük miktarda genişletme gerekir; İkincisi, kararlılık sorunları. API ağ geçidi işletmeye daha yakındır ve değişiklikler daha sık yayınlanır.Bazen, belirli bir iş nedeniyle yapılan değişikliklerle ilgili sorunlar olabilir, bu da tüm ağ geçidi kümesinin askıda kalmasına, tüm işletmeleri etkilemesine ve bunu yapmamasına neden olur. İşletme düzeyinde izolasyon. Bu yüzden ağ geçidi ademi merkeziyetini yaptık, "resmi" ağ geçidini ortadan kaldırdık, API yönlendirme yeteneğini ağ geçidine en üst erişim ağ geçidine yerleştirdik ve ağ geçidinin temel işlevlerini (imza doğrulama, oturum ve mevcut sınırlama gibi) entegre ettik. Vb.) Bir Kavanoz çizilir ve iş sistemine entegre edilir.
Bunun iki avantajı vardır:
Birincisi performans geliştirmedir Ağ geçidi çağrı servisinin uzaktan çağrısı yerel bir JVM çağrısı haline gelmiştir;
İkincisi, kararlılığın iyileştirilmesidir.Her hizmet, ağ geçidi Jar'ın kararlı bir sürümünü bütünleştirir.Belirli bir hizmet sistemi, ağ geçidi Jar ile yükseltildiğinde, diğer hizmet sistemleri rahatsız edilmez.
Bununla birlikte, ağ geçidi ademi merkeziyetçiliğinin dezavantajları da açıktır.Örneğin, sürüm bölünmesi sorunu. Sistem her entegre edildiğinde ağ geçidi Jar'ın sürümü farklıdır.Örneğin, ağ geçidi Jar'ın yükseltilmesi ve çözülmesi gereken bir güvenlik açığına sahip olduğu bulundu. Zorlu süreçte, iş sistemi Jar'ın yeni sürümünü entegre etme, regresyonu test etme ve çevrimiçi yayınlama gibi karmaşık süreçlerden geçmelidir.
Ek olarak, Jar çatışmalarına dayanan sorunlar vardır ve heterojen sistemlerin entegrasyonu kolay değildir. Service Mesh'in ortaya çıkışı bize yeni fikirler getiriyor.Ağ geçidi mantığını ServiceMesh'teki ağ proxy'sine uyguluyoruz ve bunu, kayıpsız ve sorunsuz yükseltmeleri mükemmel bir şekilde destekleyen ve aynı zamanda heterojen sistemleri destekleyen ayrı bir süreç olarak iş sistemine bir yardımcı olarak dağıtıyoruz. , Alipay'deki Nodejs ve C dil sisteminin merkezi olmayan entegrasyon problemini çözen.
2. Çin Yeni Yılı kırmızı zarflarının 100 milyon düzeyindeki eşzamanlılık sorunuyla nasıl başa çıkılır?
Alipay, 2015 Bahar Şenliği'nden başlayarak Bahar Şenliği kırmızı zarf etkinliklerini gerçekleştirecek. 2016'da Alipay, Bahar Şenliği Galası ile işbirliği yaptı ve kırmızı zarfların en yüksek değeri dakikada 17,7 milyara ulaştı, saniyede yaklaşık 300 milyon istek - bu tür eşzamanlı zorluklarla nasıl başa çıkacağız?
Başa Çıkma
Alipay'in büyük ölçekli etkinliğinin süreci şudur: İlk olarak, ürün yöneticisi birkaç ay önce iş oyununu belirler ve teknik öğrenciler iş oyununu aldıktan sonra teknolojiyi değerlendirmeye başlar ve etkinliğin zirvesindeki çevrimiçi kullanıcı sayısı ve temel iş taleplerinin sayısı gibi temel göstergeleri değerlendirmeye başlar. Çıktıktan sonra teknik plan değerlendirilecektir.
Teknik çözüm, temel bağlantıyı analiz etmemize ve ardından tüm sistemlerin kapasitesini değerlendirmemize bağlıdır.Kapasite değerlendirmesinden sonra, akım sınırlayıcı bir çözüm hazırlayacağız ve son olarak, tüm bağlantıdaki belirli sistemleri veya düğümleri optimize edip edemeyeceğimize bakacağız.
Son nokta, temel olmayan iş ve temel olmayan işlevlere olan bağımlılığın düşürülüp düşürülmeyeceğidir. Teknik plan çıktıktan sonra stres testi yapılacak, stres testi standarda ulaştıktan sonra aktivite egzersizi yapılacak, tatbikat sırasında bazı sorunlar keşfedilecek ve zamanında onarılacaktır. Takip, fiili çatışmaya hazırlanmaktır, eğer bir sorun varsa, acil bir durumda çözülecektir. Etkinlik bittikten sonra, daha önce yapılmış olan düşürme stratejisini, bilgisayar odası açılır penceresini ve diğer işlemleri geri alacağız.
Ağ erişim katmanımız büyük promosyon etkinliklerini nasıl garanti eder? Aşağıdakiler temel olarak, paylaşılacak erişim katmanındaki mevcut sınırlama ve performans optimizasyonuna odaklanmaktadır.
Katman geçerli sınırına erişim
Karşılaştığımız talep miktarı yüz milyonlarca ve arka uç işi kesinlikle bunu sürdüremiyor. Giriş katmanı, mevcut sınırlama yoluyla arka uç sistemini korumalıdır.
Temel fikir, çekirdek işin, kabul edilebilir deneyim aralığı içinde çekirdek olmayan işlevlere ve işlere indirgenmesini sağlamak için kayıplı bir hizmet sağlamaktır. İlk olarak, performans katmanının tüketimini azaltmak için sıkıştırma eşiğini düşürüyoruz; ek olarak, tüm çekirdek olmayan ve önemsiz arayüzleri düşüreceğiz çünkü bu arayüzler kısıtlanmıştır ve müşteri deneyimini etkilemeyecektir.
LVS akım sınırlaması, erişim katmanı akım sınırlaması, API ağ geçidi akım sınırlaması ve iş katmanı akım sınırlaması olarak ikiye ayrılan çok seviyeli bir akım sınırlama mekanizması uyguladık:
LVS açısından: Tek bir VIP ve bir LVS kümesi genellikle 4 makineden oluşur.Bir LVS kümesi kesinlikle bunu idare edemez. Bu nedenle, her bir IDC'ye birden fazla VIP atarız ve birden fazla LVS kümesi trafiği paylaşır ve DDOS saldırılarına direnme yeteneğini geliştirir.
Erişim katmanı: TCP akım sınırlama ve çekirdek RPC akım sınırlama yetenekleri sağlar. Ek olarak, API ağ geçidi katmanında hiyerarşik bir akım sınırlama algoritması uyguladık ve farklı istek hacimlerine sahip arayüzler için stratejiler uyguladık. Yüksek QPS akım sınırlaması, basit bir temel algoritma kullanır. Bu değer aşılırsa, doğrudan reddedeceğiz; orta QPS için bir jeton paketi algoritması uyguladık, kabul et Belirli trafik patlamaları; akım sınırlamasının doğruluğunu sağlamak için düşük QPS için dağıtılmış akım sınırlaması.
TLS performans optimizasyonu
Ağ geçidi erişim seviyesindeki bu tür büyük talepler için, performans aşırı derecede optimize edilmelidir.Performans tüketimini azaltmak için birçok performans optimizasyonu yaptık.
Öncelikle, TLS'nin performansta büyük bir fark olup olmadığını (http ile https arasındaki fark), TLS optimizasyonunu paylaşın. Şifreleme algoritmasını anlayan öğrenciler, TLS'deki en büyük performans ek yükünün, TLS el sıkışma aşamasında RSA şifreleme ve şifre çözme olduğunu bilirler. Sunucuda RSA şifreleme ve şifre çözme performans tüketimini optimize etmek için, birkaç yıl önce optimizasyon stratejimiz donanım hızlandırma idi ve RSA şifreleme ve şifre çözme işlemleri ayrı bir donanım hızlandırma kartına devredildi. TLS'nin sürekli gelişmesiyle birlikte, TLS'deki RSA temelde terk edilmiş ve en son ECDSA, RSA'nın yerine geçmiştir.ECDSA'nın en düşük seviye algoritmasının performans tüketimi ve maliyeti RSA'nınkinden 5-6 kat daha düşüktür. Buna ek olarak, TLS el sıkışmasını 2RTT'den 1RTT'ye düşürürken performansı büyük ölçüde iyileştirmek için Oturum Bileti mekanizmasını kullanıyoruz.
Sıkıştırma algoritması optimizasyonu
En yaygın kullanılan sıkıştırma algoritması gzip'tir ve sıkıştırmanın iki temel göstergesi şunlardır: sıkıştırma oranı ve sıkıştırma / açma hızı. Gzip, lz4, brotli, zstd gibi birçok algoritmayı kaynak olarak açmaya çalıştık ve sonunda Facebook'un sıkıştırma algoritması zstd'nin bu iki göstergede bir avantajı olduğunu gördük. Bununla birlikte, zstd'nin sözlükler için nispeten yüksek gereksinimleri vardır Hat üzerindeki veri hacmini temizleyerek, bizim için uygun olan ve sıkıştırma oranını ve sıkıştırma performansını büyük ölçüde artıran bir sözlük elde ederiz.
3. Ant Financial'ın mobil ağ teknolojisinin ticari uygulaması ve çıktısı
Tek noktadan mobil geliştirme platformu mPaaS
Ant'ın mobil ağ teknolojisinin ticarileştirilmesi, Ant Financial'ın mobil geliştirme platformu olan mPaaS'ye dayanıyor.
mPaaS, Alipay Uygulamasındaki son 10 yıllık mobil teknoloji düşüncesi ve uygulamasından türetilmiştir.Mobil geliştirme, test etme, çalıştırma ve çalıştırma ve bakım için teknik eşikleri etkili bir şekilde azaltabilen, Ar-Ge maliyetlerini azaltabilen ve geliştirme verimliliğini artırabilen buluttan uca tek noktadan bir platform çözümü sunar. Hızlı bir şekilde istikrarlı ve yüksek kaliteli mobil uygulamalar oluşturmaları için ekolojik ortaklara yardımcı olun Mobil ağ hizmetleri, MGS ağ geçidi hizmeti, MSS veri senkronizasyon hizmeti, MPS push hizmeti ve MDC gönderme hizmeti gibi mPaaS'de zengin ağ çözümleri sağlar.
Ant Financial'ın teknik yeteneklerini tam olarak entegre edin
Sunucu tarafındaki MGS (Ağ Geçidi Hizmeti), MPS (Push Hizmeti) ve MSS (Senkronizasyon Hizmeti) temel hizmetlerimizdir. Temel olarak, çoğu işletmeyi tatmin edebilen üç istek yanıtı, itme ve artımlı güncelleme modunu kapsar. Uygulama senaryoları. Ağ geçidi hizmetinin açık sürümü, HTTP, Dubbo, ZDAS, SOFA-RPC gibi birden çok protokolü destekler ve ayrıca eklentiler aracılığıyla ağ geçidi işlevini geliştiren eklenti işlevlerini destekler. MSS servis mekanizması artımlı bir güncelleme modudur ve sırayla itilebilir.Örneğin, sohbet için sohbet mesajlarının sıralı değil, tek tek ulaşması gerekir ve saniyeler içinde ulaşılabilir. Çin'deki MPS hizmetleri için kendi PUSH kanalımızı kuracağız.Ayrıca, kendi kanalımız olmadığında, yüksek kullanılabilirlik ve yüksek itme oranı sağlamak için Xiaomi ve Huawei gibi üreticilerin PUSH kanalından geçmeye çalışacağız.
