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

Pratik vaka analizi: Qunar ödeme sistemi mimarisinin gelişimi

Yazar Lu Bo

Düzenle Xiaozhi

Bu makale size Qunar'ın ödeme sistemi mimarisinin tüm evriminin ayrıntılı bir açıklamasını verecek, ortadaki tasarım fikri nedir, hangi çukurlara basıldı, referans için hangi iyileştirmeler yapıldı, bu gerçek savaşta çeşitli deneyim paylaşımları var. Durumda!

Qunar Ödeme Sistemi, 2011 yılında kurulduğundan bu yana kademeli olarak yüksek düzeyde bağlı tek bir sistemden, yüksek eşzamanlılık, yüksek kullanılabilirlik ve beş yıl içinde çoklu işlem ödeme hizmetleri için destek sağlayan dağıtılmış bir sisteme dönüşmüştür. İşletme, ilk aracı olmayan kişiden çeşitli tahsil etmeme ve tahsilat senaryolarından destek aldı. B2B işi sıfırdan büyüdü ve ödeme yöntemi tek bir çevrimiçi banka ödemesinden mevcut banka kartı, harcama, kuponlar, kırmızı zarflar ve kuruluşlara dönüştü. İndirimler, puanlar ve eğlenceli tur hazineleri ve sipariş kombinasyonları, tek ödemeden birden çok eşzamanlı ödemeye ve birden çok ödemeye kadar çeşitlilik gösterir. Aşağıdaki, genel evrim sürecine kısa bir giriş niteliğindedir.

Ödeme sistemi 1.0

Yeni iş sistemi ilk kurulduğunda, iş mantığı nispeten basitti ve iş hacmi görece küçüktü.Fonksiyonları hızlı bir şekilde uygulamak ve çevrimiçi olarak yayınlamak için çoğu ekip tüm mantığı tek bir sistemde birleştirecektir. Bu, ilk işin hızlı yinelenmesi için faydalıdır. İstisnasız ödeme işlem sistemi de bu yaklaşımı kullanır. Aşağıda gösterildiği gibi.

Bir ödeme sistemi, birkaç önemli bileşeni içeren bir istisna değildir: kasa, işlem, ödeme, ağ geçidi ve muhasebe.

Kasiyer: ödeme ayrıntılarını görüntülemek ve çeşitli ödeme seçenekleri sağlamak için kullanılır
İşlem: edinme kurallarının ve işlem kurallarının işlenmesi
Ödeme: Banka kartları, kullanıcı bakiyeleri, kredi ödemeleri, harcama, kırmızı zarflar, kuponlar, anında indirimler, puanlar vb. Gibi çeşitli ödeme yöntemi kombinasyonlarını işleyin.
Muhasebe: tüm işlemlerin ve fon işlemlerinin ayrıntılarını, finansal muhasebeyi kaydetmek için kullanılır
Ağ geçidi: banka kanallarını ve üçüncü taraf ödeme kanallarını (WeChat, Alipay) bağlamak için kullanılır

Küçük işletme hacmi söz konusu olduğunda, böyle bir sistem yapısı sorun değildir. Daha fazla hizmete erişim ve çeşitli karmaşık işlevsel mantıkların eklenmesiyle, sistemin işlenmesi biraz zordur, özellikle aşağıdaki yönlerden:

Sistem afet toleransı: tüm işlevler yoğunlaşır, bir işlev başarısız olduğunda, genel durumu doğrudan etkiler

Sistem genişletme: Dağıtılmış bir sistemde, sistem performansını belirleyen şey en kötü kısma bağlıdır ve genel genişleme etkisi zayıftır

Yüksek geliştirme maliyeti: ekip üyelerinin artışı, işlevlerin karmaşıklığı ve birden çok proje paralel olduğunda son derece düşük geliştirme verimliliği

Giderek daha karmaşık işletmeler: mantıksız yapı, iş geliştirme ihtiyaçlarını karşılayamayan

Sistemin sorumlulukları karıştı: örneğin, kasiyer sadece banka listesini tutuyor

Bu bağlamda 2.0 sistemi ortaya çıktı.

Ödeme sistemi 2.0

2.0 dönemi, ödeme işlem sistemlerinin hızlı gelişimi için önemli bir dönemdir. Bu süreçte, sadece hizmet odaklı sistem mimarisinden ayrılma değil, aynı zamanda daha karmaşık işletmeleri destekleme ihtiyacı.

Servis bölümü

Ağ geçidi bölmesi

Birincisi, nispeten bağımsız ağ geçidi bölünmüştür Ağ geçidi, tüm ödeme sistemindeki temel hizmete aittir ve nispeten önemli bir altyapıdır. Dışarıdan ne tür ödeme işlemi hizmetlerinin sağlanabileceği, ağ geçidinin kapasite geliştirmesine bağlıdır.

Ağ geçidinin bazı belirgin özellikleri vardır ve oldukça soyut bir hizmettir. Dış hizmetler, ödeme, geri ödeme ve sorgulama standartları olarak özetlenebilir. Bu nedenle, önce bu bölüm ayrılmalıdır, biri iyi bir temel oluşturmak, diğeri bağımsız olarak gelişebilir ve üçüncüsü, bu bölümün nispeten kolay uygulanmasıdır.

Ağ geçidinin bölünmüş yönlendirme sistemi hayati bir rol oynar ve çok kanallı ödemenin desteklenmesinde ve akıllıca seçilmesinde büyük bir rol oynar.

Muhasebe sistemini bölmek

İşlem ödemesi işinde önemli bir şey, net bir hesap tutmaktır. Defter tutma, işlem akışının çok basit bir kaydı olabilir, aynı zamanda daha profesyonel finansal muhasebe olabilir. Bölünmeden önce, sistem yalnızca işlem akışını kaydetti, bölünmeden sonra daha profesyonel ve karmaşık çift girişli defter tutma gerçekleştirildi.

Yeni muhasebe sisteminin basit bir akış şeması:

Üyelik sisteminin bağımsızlığı

Üyelik sistemi ve işlem sisteminin kendisi yalnızca bağımlı bir ilişkidir, işlem ödeme sistemi açısından sadece bir iş sistemidir. Örneğin, üyelik yenileme hizmeti bir ödeme işlemi olarak değerlendirilebilir. İlgili rollerini düzeltmek için üye kısmı orijinal sistemden ayrılır. Bu şekilde, her birinin konumu daha nettir ve her birinin bağımsız olarak gelişmesi de uygundur. Mevcut üyelik sistemi sadece bir bakiyeye sahip olmakla kalmaz, aynı zamanda gerçek isim hizmetleri, çeşitli varlık yönetimi, işlem yönetimi vb.

Temel hizmetlerin bölünmesi

Daha fazla sistem bölündükten ve bağımsız olduktan sonra, orijinal ortak işlevlerden bazıları birden çok kez kopyalanacaktır. Merkezi yönetim ve bakımı kolaylaştırmak için, her sistemin daha birleşik ortak mantığı aracılığıyla, talos sistemi için aşağıdaki şekilde gösterildiği gibi, güvenlik hizmetleri, ek doğrulama hizmetleri, bildirim hizmetleri, temel bilgi sorgusu vb. Gibi merkezi temel hizmetleri sağlayın.

Yukarıda belirtilen hizmetlerin bölünmesi daha çok iş veya teknoloji odaklı değerlendirmeler içindir. Tipik işlem ödeme sürecinin sıralı bir süreci vardır. Sipariş vermek gibi- > işlem- > Çıkış gişesi- > Ödemek- > Ağ geçidi > banka. Böyle bir dizi aynı zamanda daha iyi bir sistem bölme şemasıdır. Böyle bir sıraya göre, her aşamayı (ağ geçidi ve banka bölümleri hariç) aşağıdaki gibi ayırıyoruz:

1. İşlem çekirdeği (Apollo)

Yöntemleri ve işlem türlerini edinmeye odaklanın.

Satın alma sistemi halihazırda tek sipariş ödemesini ve toplu sipariş ödemesini desteklemektedir. İşlem türleri şu anda doğrudan işlemleri, teminatlı işlemleri, doğrudan bölünmüş defter işlemlerini, teminatlı bölünmüş defter işlemlerini ve önceden yetkilendirilmiş işlemleri desteklemektedir. Toplu sipariş ödemesi sırasında çeşitli işlem türleri karıştırılabilir. Ve bölünmüş hesap işlemleri aynı anda birden fazla hesabı destekler. Yukarıda belirtilen forward işlemlerine ek olarak, sistem ayrıca ön yetkilendirme onayı, ön yetkilendirme iptali, iade, garanti iptali ve ikincil bölünmüş işlemler gibi birçok sonraki işlem işlemini de destekler.

Çeşitli işlemler, her bir iş biriminin işinin karmaşıklığından kaynaklanmaktadır.Standartlaştırılmış ödeme sistemi ile karşılaştırıldığında, daha esnek ve kolay iş desteği sağlıyoruz.

2. Ödeme çekirdeği (minos)

Ödeme çözümlerinin kombinasyonuna ve uygulanmasına odaklanın.

Ödeme yöntemleri: banka kartı, Alipay, WeChat, TakeQihua, Funyoubao, bakiye, puanlar, kırmızı zarflar, kuponlar, üyelik kırmızı zarfları, anında indirimler ve diğer ödeme yöntemleri.

Ödeme kombinasyonu: Tek başına veya kombinasyon halinde kullanılabilir. Kombinasyon senaryoları fon türlerini ayırt eder: Örneğin, banka kartı, Alipay ve WeChat bir seferde yalnızca birini seçebilir ve diğer fon türleri aynı anda kullanılabilir.

Yukarıdaki vakfın desteğiyle, otel kredisi ödemesi, teslim alma ödemesi ve diğer iş senaryoları gibi iş senaryoları gibi aynı işlem emri partisi için birden fazla birleşik ödeme kesintileri de yapılabilir. Aşağıdaki şekil, ödeme çekirdeğinin (minos) sistemdeki konumunu gösterir:

3. Kasiyer

Kasiyer doğrudan kullanıcıya dönük olduğundan, ödeme deneyimi çok önemlidir. İstatistiklere göre, ödeme bağlantısında terk edilen siparişlerin oranı hala nispeten büyük. Bu nedenle, uygun, özlü ve kullanımı kolay bir kasa, sipariş dönüşümü için çok yararlıdır. Şu anda sistem tarafından desteklenen kasiyer sayaçları arasında temel olarak uygulama (yerel), uygulama ön kasiyer, dokunmatik, PC ön yetkili kasiyer, PC çoklu tek kasiyer, PC İngilizce kasiyer, PC standart kasiyer vb. Bulunmaktadır. Yazar kasanın sistemdeki konumu aşağıdaki şekilde gösterilmiştir.

Kablosuz kasiyer:

PC yazar kasa:

4. API erişim katmanı

Ticaret sisteminin daha fazla hizmeti, genel sistem işinin büyük bir bölümünü oluşturan arka plan arabirimi aracılığıyla tamamlanır. Ödemenin sonraki aşamasındaki fon akışı, ters işlemler için geri ödemeler vb. Ancak bazı işlem emirlerinin alaka düzeyini sorgulamak için kullanılan bazı bilgiler de vardır. Bu bağlamda, api erişim katmanı bir okuma-yazma ayırma yöntemini benimser. Aşağıdaki şekilde gösterildiği gibi, ares sistemi, çeşitli sorgu hizmetleri sağlamak için temeldeki dubbo hizmetlerini paketler. Odin sistemi okunabilir ve yazılabilirdir ve çözme, geri ödeme ve iptal gibi temel işlerle ilgili yazılara daha fazla dikkat eder.

Şimdiye kadar, genel sistemin genel bir yapısı aşağıdaki şekilde gösterilmektedir:

Hizmet Bölüşümünün Getirdiği Zorluklar

Hizmet odaklı bölünmeden sonra, sistem yapısı daha nettir, ancak genel sistem geliştirme yönetimi ve günlük operasyon için daha büyük zorluklar getirir. Örneğin, aşağıdaki hususlar:

Geliştirme verimliliği nasıl artırılır

Sistem bölündükten sonra ağırlıklı olarak dubbo hizmeti ve harici http (https) hizmeti vermektedir.

1. Dubbo hizmeti için sözleşme

Arayüz tanımı: granüler kontrol, sınır kontrolü. Bir arayüz belirsiz olamaz, sadece bir

Parametre standartları: karmaşık arayüzler, nesneleri parametre olarak kullanır (haritadan kaçınma), ana sınıfı birleştirir, genişletilmiş özniteliklerin şeffaf aktarımını destekler, yasal parametreleri oluşturmak için oluşturma / oluşturucu sağlar ve parametre aralığını sınırlamak için numaralandırmaları kullanır. Çağıran tarafta yanlış parametre aktarımını etkili bir şekilde önleyin

Dönüş değeri: birleşik QResponse kapsülleme, hata kodu yönetimi (dijital olmayan biçimin açık anlamı vardır, yinelemeyi önlemek için işletme tarafından ayırt edilir, vb.)

İş şablonu: standart iş süreci prosedürlerini, standartlaştırılmış istisna işlemeyi tanımlayın

Arayüz dokümantasyonu: Arayüzü tanımladıktan sonra, açıklamalar aracılığıyla dinamik olarak arayüz dokümantasyonu oluşturun

2. http hizmeti için sözleşme

a) Arayüz parametreleri: komut, doğrulayıcı, parametre tipi yapılandırması.

Arayüz bilgileri, istek dönüş parametreleri, her bir parametrenin parametre tipi, parametre doğrulayıcı ve parametre tipi doğrulayıcı dahil olmak üzere komutta tanımlanır. Doğrulayıcı kombinasyon halinde kullanılabilir veya uzantı elde etmek için özelleştirilebilir. Aşağıdaki örnek:

Komut tanımı: < komutlar > < command name = "forex_queryExchangeRate" > < cnName > Döviz kuru sorgulama arayüzü < / cnName > < versiyon > 20150808 < / version > < azalan > Yerel para biriminin ve hedef para biriminin döviz kurunu sorgulayın < / desc > < istek > < param name = "localCurrType" gerekli = "true" > < doğrulayıcı kimliği = "CURID" / > < / param > < param name = "targetCurrType" gerekli = "true" > < doğrulayıcı kimliği = "CURID" / > < / param > < /istek > < ! - Parametre bölümüne geri dönün - > < tepki > < param adı = "localCurrType" > < cnName > para birimi < / cnName > < gereklidir > doğru < /gereklidir > < / param > < param name = "targetCurrType" > < cnName > Hedef para birimi < / cnName > < gereklidir > doğru < /gereklidir > < / param > < param adı = "satanFiyat" > < cnName > Satış fiyatı < / cnName > < gereklidir > doğru < /gereklidir > < / param > < param adı = "satın almaFiyatı" > < cnName > Alış fiyatı < / cnName > < gereklidir > doğru < /gereklidir > < / param > < param adı = "oranTime" > < cnName > Döviz kuru süresi < / cnName > < gereklidir > doğru < /gereklidir > < / param > < /tepki > < / komut > < / komutlar > Doğrulayıcı: < doğrulayıcılar > < doğrulayıcı kimliği = "CURID" type = "Normal ifade" > < Desen > ^ {3} $ < /Desen > < / doğrulayıcı > < / doğrulayıcılar > Parametre Türü: < paramTypes > < paramType name = "merchantCode" > < cnName > iş numarası < / cnName > < azalan > Farklı işletmeleri ayırt etmek için kullanılır < / desc > < tip > java.lang.String < / tür > < misal > testbgd < /misal > < doğrulayıcı türü = "Normal ifade" > < Desen > ^ {1,20} ABD doları < /Desen > < / doğrulayıcı > < / paramType > < / paramTypes >

b) Eşzamanlılık kontrolü

Bazı işletim senaryolarında, eşzamanlı yazma işlemlerinde, önbellek kilitlemeye dayanarak kontrol edilebilen bazı sorunlar olacaktır. Örneğin, arayüze ek açıklamalar ekleyerek etkinleştirin. Arayüz parametrelerini kilidin lockKey'i olarak belirtebilir, kilit sona erme süresini ve yeniden deneme sayısını belirtebilir ve bir istisna meydana geldiğinde işleme şemasını belirtebilirsiniz (lockGotExIgnore).

@RequestLock (lockKeyPrefix = "combdaikoupay:", lockKey = "$ {parentMerchantCode} _ $ {parentTradeNo}", lockKeyParamMustExists = true, lockKeyExpireSecs = 5, lockUsedRetryTimes = 0, lockUsedRetryLockIntervalMills = 500

c) Akış kontrolü

Şu anda iki tür akış denetimi vardır: qps ve paralel sayı.

Qps, düğümlere, kümelere, arabirim düğümlerine ve arabirim kümelerine bölünmüştür. Saniyedeki istek sayısını kontrol ederek, önceden belirlenmiş bir eşikten büyükse (dinamik olarak ayarlanabilir), erişim reddedilir ve sayı azaltılır, aksi takdirde sayım azalmadan sayılır.

Satır sayısı esas olarak isteğin birden çok saniyeye yayıldığı durumu çözmek içindir. Şu anda qps koşulları karşılıyor, ancak genel erişim hacmi artıyor ve bu da sistemin verimini etkiliyor. Önceden ayarlanmış eşikten büyükse (dinamik olarak ayarlanabilir), erişim reddedilir. Her talebin sonunda sayı azaltılır.

d) Emniyet doğrulaması

Arayüz yetkisi: arayüz erişim yetkisinin birleşik yönetimi ve doğrulanması, ziyaretçiye ayrıntılı kontrol, erişilen sistem, arayüz, sürüm numarası

Arayüz imzası: transfer işlemi sırasında arayüz parametrelerinin değiştirilmesini önlemek için

e) Birleşik izleme

Arayüz sayısı, yanıt süresi ve hata kodu istatistikleri dahil olmak üzere üç boyut

f) Arayüz belgeleri

Analiz ve oluşturma için önceki komuta, doğrulayıcıya ve parametre türü yapılandırmasına güvenin

Birden fazla sistem nasıl yönetilir?

Arayüz izleme şablonu: http, Dubbo çoklu sistem birleşik şablon, merkezi ekran yönetimi.

Bileşenler izlenebilir: Redis / Memcache, Mybatis, Lock, QMQ, EventBus, DataSource, JobScheduler

Otomatik izleme panelleri oluşturma: Python otomatik olarak komut dosyaları oluşturur.Yeni oluşturulan sistemlerin, standart izleme panelleri oluşturmak için yalnızca sistem adını ve panel yapılandırma düğümlerini sağlaması gerekir.

Sistem donanım kaynaklarının, tomcat ve iş temel göstergelerinin görsel olarak izlenmesi

Günlük verimli bir şekilde nasıl çalıştırılır?

Her sahnenin temel işlemleri için günlük çıktısını biçimlendirin ve merkezi bir şekilde toplayıp işleyin. OrderLog, userLog, cardLog, binlog, busilog, tracelog, pagelog gibi ...

Servis bölme sırasında DB işleme

Alt tablo

İş hacminin artmasıyla birlikte tek tablodaki veri miktarı çok fazla ve operasyon baskısı da yükseliyor. Bu nedenle, alt tablo zorunludur. Aylık tablo, çeyrek tablo, belirli bir anahtara göre karma tablo veya ikisinin bir kombinasyonu gibi zamana göre tablo bölme gibi yaygın olarak kullanılan tablo bölme stratejileri. Alt ölçümün avantajı, geçmiş verilerin taşınmasını kolaylaştırması, çevrimiçi veri miktarını azaltması ve tek bir metrenin basıncını dağıtabilmesidir.

Alt veritabanı, birden çok örnek

Çoklu veritabanı tek örnek, çoklu hizmet tek veritabanı. Bazı iş sorunları genel durumu etkileyecek ve bu da tüm kümeyi çökertecektir. Bu nedenle, iş sistemi bölündükten sonra, db'nin bölünmesi de önemli bir bağlantıdır. Ödeme kitaplığını bölmeye ilişkin bir örnek alın. Ödeme işlem tablolarının hepsi aynı kitaplıkta, disk kapasitesi sorunları ve işin bölünmesi nedeniyle kitaplığın bölünmesine karar verildi. Güvenlik amacıyla, muhafazakar bir yaklaşım benimsiyoruz. Önce mevcut örnek için bir bağımlı kitaplık oluşturun ve ardından bölünmesi gereken kitaplık için yeni bir kullanıcı U oluşturun. Geçiş yaparken önce U'nun yazma iznini geri çekin ve ardından ana-bağımlı senkronizasyonunun tamamlanmasını bekleyin. İlgili tablo yazılmadıktan sonra, U yeni örneğe geçin. Ardından ilgili kitaplıklardaki ilgisiz tabloları silin.

Ayrımı okuyun ve yazın, yük dengelemeyi okuyun

Birçok işletme daha fazla okur ve daha az yazar MMM yapısını kullanarak, temelde yalnızca bir tanesi çalışıyor, bu sadece kaynakları boşa çıkarmakla kalmıyor, aynı zamanda genel kümenin istikrarına da yardımcı olmuyor. Okuma-yazma ayrımı ve okuma sorumluluğu dengeleme stratejilerini tanıtın. Donanım kaynaklarını etkili bir şekilde kullanın ve her bir sunucu üzerindeki baskıyı azaltın.

a) Yük dengelemeyi okuyun ve yazın

b) Çoklu dinamik kaynaklar

c) Çoklu veritabanı dinamik kaynak okuma yük dengeleme

Eşzamansız kullanım

Servlet3 asenkron: sistemin genel verimini iyileştirmek ve farklı hizmetlerin çalışan iş parçacığını izole etmek için http iş parçacığını serbest bırakın

qmq: en yaygın kullanılan ve daha esnek eşzamansız

dubbo: Servis sağlayıcının yavaş yanıt vermesi için

Eşzamansız servlet ve qmq kombinasyonu senaryosu aşağıdaki şekilde gösterilmektedir. İşlem, http hizmetinin birleşik kesinti talebini alması ve ardından arka uç işlem sistemine bir sipariş vermesi ve kesintiyi başlatmasıdır. Bu sırada http hizmeti yoklama beklemesine girer ve yoklama aralığına göre önbelleğe yerleştirilen kesinti sonuçlarının sorgulanmasını periyodik olarak başlatır. İşlem sistemi, tüm işlemler tamamlanana kadar (başarı, başarısızlık, kısmi ödeme) kesinti kurallarına göre qmq cinsinden kesintiyi yürütür. Her kesintinin sonunda sonuç, http hizmet sorgusu için önbelleğe alınacaktır.

Yukarıdaki şekilde yoklama senaryosu kullanılmıştır, anahtar yoklama aralığını belirlemektir

İzleme alarmı

Java izleme modülü

Uygulamaya gömülü olan gösterge verileri esnek bir şekilde yapılandırılabilir ve birden çok yere gönderilebilir. Ayrıca verileri doğrudan çekmek için api arayüzünü destekler

Çevrimdışı izleme çerçevesi

Python izleme betiği çerçevesi, db, java modülü api, redis vb.'den veri alın, göstergeleri hesaplayın ve gönderin

Genel mimari eklenti olabilir, ortak standart işlevlere sahip olabilir ve ayrıca geliştirme özelleştirilebilir

Bir izleme sayfası eklemek için göstergeler doğrudan izleyici (kontrol paneli) sistemine gönderilebilir

Alarm yöntemleri arasında mail, sms, qtalk bulunur

Python izleme betiği çerçevesi temel olarak dört önemli bileşeni içerir:

metric_manager: metrik yöneticisi

graphite_sender: gösterge itme

Dbpool: veritabanı bağlantı havuzu yönetimi

Zamanlayıcı: Zamanlayıcı, dizin verisi toplamayı düzenli olarak yürütün

Veri akış sistemi

İş günlüklerini ve binlog'u gerçek zamanlı olarak toplamak ve işlemek için xflume, kafka, storm, hdfs, hbase, redis, hive kullanın. İş günlüğü, sipariş yaşam döngüsü günlüğü, çeşitli biçimlendirilmiş günlüklerin sorgulanması, hesaplama depolaması ve bazı izleme göstergelerinin alarmını sağlayın. Genel süreç aşağıdaki şekilde gösterilmektedir:

Polisi aramak

Alarm, iş ve sistem yapısı karmaşık olduğunda özellikle önemlidir. Hangi göstergelerin alarma geçirilmesi gerektiğini belirlemek ve alarm eşiğini belirlemek çok karmaşık bir konudur. Genel olarak iki durum vardır: Birincisi açıkça gerçekleşmediğinin varsayılması, diğeri ise polisi arayıp aramayacağına karar vermek için belirli hesaplamalar yapılması gerektiğidir. Elbette, bazı temel katman hizmetlerinde zincirleme tepkilere neden olabilecek sorunlar vardır, bu nedenle polise bildirmek için en doğrudan sorunların nasıl tanımlanacağı ve yargıyı etkileyen yanlış bildirimlerin nasıl önleneceği daha zordur. Şu anda, sistem tüm bu durumu rapor edecek ve ardından temel manuel kararlar verecektir.Örneğin, arayüz alarma yavaş yanıt veriyorsa ve bu sırada DB yavaş sorgu alarmı görünüyorsa, temelde bunun bir DB sorunu olduğu doğrulanabilir.

A. Arıza alarmını temizle

Günlük NPE, iş HATASI, sistem HATASI, Erişim (4xx \ 5xx), arabirim istisnası, dubbo zaman aşımı, fullgc, DB yavaş sorgu vb.

B. Hesaplama alarmı

Çağrı hacmi çok küçük, dalgalanma ayrıntıları, süreklilik yok ve kontrast yok

Beklenen değer: Aşağıdaki şekilde gösterildiği gibi, mevcut değer ile beklenen değer arasındaki sapma artar

Sonuna yaz

Şimdiye kadar, işlem ödeme sistemi, kasa, işlem, ödeme, ağ geçidi, muhasebe, temel hizmetler, izleme ve diğer modüllerden bağımsız olarak bölünmüş ve gelişmiştir.Yüksek karmaşık hizmetler ve yüksek eşzamanlı erişim desteği, eskisinden çok daha güçlüdür. Ancak hala iyileştirilmesi ve mükemmelleştirilmesi gereken birçok eksiklik var.

İşlem Ödemesi 3.0'ı dört gözle beklemeye devam edin ...

Bu makale Qunar Teknoloji Salonunun InfoQ resmi hesabı tarafından iletilmesine ve yayılmasına izin verilen orijinal makalesidir.

yazar hakkında

Qunar.com'un finans bölümünde Ar-Ge mühendisi olan Lu Bo, Jilin Üniversitesi'nden mezun oldu ve 2012'de Qunar.com'a katıldı. Ödeme platformu araştırma ve geliştirme ve ödeme bağlantısı temel hizmet inşaatı taahhüdü.

Bugünün Tavsiyesi

Okumak için aşağıdaki resme tıklayın