Ant Financial'ın farklı yerlerde çok aktif mikro hizmet sistemi "pasif olarak kazma optik kablolarından" "ağ kablolarını aktif olarak kesmeye" kadar
"Farklı yerlerde birden çok etkinlik", İnternet sisteminin yüksek oranda erişilebilir bir dağıtım mimarisidir ve "birimleştirme", farklı yerlerde birden çok etkinliği gerçekleştirmek için bir sorun çözme fikridir.
Bu konudan bahsetmişken, iki olaydan bahsetmek zorundayım: biri üç yıldan fazla geçmiş bir olay, diğeri bu yıl Hangzhou Yunqi Konferansı'nda gerçekleşti.
"Optik kablo kazma" dan "ağ kablosunu kesmeye"
27 Mayıs 2015'te belediye inşaatı nedeniyle, Hangzhou of Alipay'deki bir veri merkezinin optik kablosu kesildi ve bu da bazı kullanıcıların birkaç saat boyunca hizmet verememesine neden oldu. Aslında, Alipay'in modüler mimari felaket kurtarma işlemi çok erken başladı ve temelde 2015'te şekillendi. O sırada, ani olay nedeniyle birçok pratik sorunla karşılaşıldı ve geçişin tamamlanması ve kullanıcı verilerinin tamamen doğru olmasını sağlama öncülüğünde hizmeti geri yüklemek birkaç saat sürdü. Verilerde hata olmamasına rağmen, bu büyüklükteki bir şirket için, kamuoyunun hizmetlerin sağlanamaması üzerindeki etkisi de çok büyük.
527 sayısı, Ant Financial'ın tüm teknisyenlerinin gönlünü fethetti. Hatta teknik departmanın bulunduğu ofis binasında bir konferans odasını 527 olarak belirledik ve her yıl 27 Mayıs'ı Teknoloji Günü olarak belirledik, böylece teknolojiye olan hayranlığımızın her zaman farkına varabilir ve teknolojiyi parlatmaya devam edebiliriz.
Birkaç yıl süren sıkı çalışmanın ardından, Eylül 2018'in zamanı geldi. Yunqi Konferansı'nda Ant Financial, "Üç Konum ve Beş Merkez için Finans Düzeyinde Yüksek Kullanılabilirlik Planı" nı yayınladı. Sahada simüle edilmiş bir transfer sistemi uygulandı ve izleyiciler mini programlar aracılığıyla birbirlerine para aktarmaya devam etti. Sunucular üç şehirdeki beş veri merkezinde dağıtılır Daha sezgisel hissetmek için, Hangzhou'daki veri merkezi dolaplarından biri mekana kuruldu. Personel, Hangzhou'daki şehir düzeyindeki felaketi simüle etmek için Hangzhou'daki iki veri merkezinin ağ kablolarını yerinde kesti.
Ağ kablosu kesildikten sonra bazı kullanıcı hizmetleri kullanılamaz. 26 saniye sonra, olağanüstü durum kurtarma geçişi tamamlandı ve etkilenen tüm kullanıcılar normale döndü. Bu Demo elbette sadece gerçek üretim sisteminin basitleştirilmiş bir modelidir, ancak arkasındaki teknoloji aynıdır. Geçtiğimiz birkaç yılda, aslında, sistemin felaket toleransı yeteneklerini sürekli olarak iyileştirmek için üretim ortamında gerçek bir veri merkezi bağlantı kesme egzersizi gerçekleştirdik.
Büyük ekrandan, olağanüstü durumdan kurtarma anahtarlamasının "veritabanı değiştirme", "önbellek felaket kurtarma anahtarı", "çok etkin kural değiştirme", "ara yazılım değiştirme", "yük dengeleme değiştirme" ve "alan adı çözümleme değiştirme" gibi birden çok bağlantı içerdiği görülebilir. Uzak çoklu yaşam mimarisi, çok zengin teknik çağrışımlar içeren karmaşık bir sistem mühendisliğidir ve her şeyi tek bir alanda paylaşmak zordur. Bu, mikro hizmetler üzerine özel bir oturumdur.Ayrıca, farklı yerlerdeki çok aktif birim mimarisinin gerçek yüzüne bir göz atmak için uygulama katmanı mikro hizmet sistemini bir giriş noktası olarak alacağız.
Tek noktaya giden yol
Herhangi bir internet sistemi belirli bir ölçekte geliştiğinde, kaçınılmaz olarak tek bir darboğaz noktasına dokunacaktır. "Tek nokta", sistemin farklı geliştirme aşamalarında farklı tezahürlere sahiptir. Sistemin ölçeklenebilirliğini ve yüksek kullanılabilirliğini geliştirme süreci, çeşitli seviyelerde tek noktalarla sürekli bir mücadele sürecidir.
Sistem mimarisinde karşılaşılan sorunları basitten karmaşığa çıkarmak için hayatın en aşina olduğu bir sahneyi örnek olarak kullanabiliriz.
Yukarıdaki resim Alipay'i kahvaltı satın almak için kullanma senaryosunu gösteriyor, tabi ki karakter hayali.
En eski Alipay, tek uygulama çağında Taobao'dan çıkarılan küçük bir alet sistemiydi. Elbette, mobil ödeme şu anda henüz görünmedi. Örneğimiz yalnızca sorunu analiz etmeye yardımcı olmak için kullanılır. Lütfen bu boşluğu dikkate almayın.
Resimdeki sahnenin Pekin'de geçtiğini ve Alipay sisteminin Hangzhou'daki bir bilgisayar odasına yerleştirildiğini varsayalım. Xiao Wang "Öde" düğmesine bastığında ne olur?
Ödeme talebi istemciden sunucuya gönderilmelidir ve sunucu sonunda sonucu istemciye geri gönderecektir.Kırmızı çizgi ile gösterilen yaklaşık on milisaniye süren bir uzak ağ gidiş-dönüşü olması kaçınılmazdır. Uygulama sürecinde, ağ ek yükünü içermeyen ve zaman alıcı önemsiz olan, yeşil daire ile gösterilen birçok iş mantığı işlemi gerçekleşir. Uygulama veritabanına birden çok kez erişecek. Hepsi aynı bilgisayar odasında dağıtıldığı için, her seferinde bir milisaniyeden az sürüyor. Bir ödeme talebi, 10 veritabanı erişimi olarak sayılır (bir ödeme sistemi, bir işletme için çok fazla değil Çeşitli veri doğrulama ve veri değişikliklerini içerebilir). Zaman kaybı, çoğunlukla kullanıcı ile bilgisayar odası arasındaki kaçınılmaz fiziksel mesafeden kaynaklanmaktadır ve sistemin iç işleyişi çok az zaman harcar.
Servitizasyon çağında, iyi bir RPC çerçevesi, uzak servis çağrılarını yerel yöntemleri çağırmak kadar kolay hale getirmeyi amaçlamaktadır. Hizmetlerin bölünmesi ve işin gelişmesiyle birlikte, orijinal sürecin içindeki çağrılar ağ çağrılarına dönüştü. Uygulamaların tümü aynı bilgisayar odasında konuşlandırıldığından, genel iş ağı zaman tüketimi hala kabul edilebilir bir aralıktadır. Geliştiriciler genellikle bu soruna fazla dikkat etmezler, RPC hizmetleri neredeyse ek yük olmadan kullanılmakta ve uygulama sayısı giderek artmaktadır.
Servis, uygulama katmanındaki darboğazı çözer ve ardından veritabanı, sistem genişlemesini kısıtlayan darboğaz haline gelir. Bu sefer hizmet katmanına odaklanıyor olsak da, birimleştirme hakkında konuşmalıyız ve veri depolama hiçbir durumda kaçınılamayacak bir konu. Aşağıda, alt kitaplığa ve alt tablolara bir ön ışık olarak bir giriş yer almaktadır.
Veri erişim ara yazılımlarının devreye girmesiyle, uygulama şeffaf alt veri tabanı ve alt tablonun gerçekleştirilmesi mümkündür. Daha iyi bir uygulama şudur: mantıksal bölme önce gerçekleşir ve fiziksel bölme yavaş ilerler. Hesap tablosunu örnek olarak alırsak, kullanıcı kimliğinin son iki basamağını parçalama boyutu olarak kullanarak, veriler mantıksal olarak 100 parçaya bölünebilir ve bir seferde 100 parçaya bölünebilir. Bu 100 alt tablo, önce aynı fiziksel kitaplıkta yer alabilir ve sistem geliştikçe kademeli olarak 2, 5, 10 ve hatta 100 fiziksel kitaplığa bölünebilir. Veri erişim ara yazılımı, tablo ve kitaplık arasındaki eşleştirme ilişkisini koruyacaktır ve uygulama katmanının bunu algılaması gerekmez.
Tek nokta uygulama katmanı ve veritabanı katmanı çözüldükten sonra fiziksel bilgisayar odası, sistemin ölçeklenebilirliğini ve yüksek kullanılabilirliğini kısıtlayan en büyük tek nokta haline geldi.
Tek bir bilgisayar odasının kapasite sınırlamasını aşmak için en sezgisel çözüm yeni bir bilgisayar odası inşa etmektir Bilgisayar odaları aynı dahili ağa özel bir hat üzerinden bağlanır. Uygulama, düğümlerin bir kısmını ikinci bilgisayar odasına dağıtabilir ve veritabanı ayrıca ana ve yedek veritabanları arasında farklı bilgisayar odalarına çapraz olarak konuşlandırılabilir.
Bu aşamada sadece bilgisayar odasının yetersiz kapasitesi sorunu çözüldü ve iki bilgisayar odası mantıksal olarak hala bir bütündü. Günlük hayatta iki bölüm arası bilgisayar odası görüşmesi vardır:
Aynı şehirdeki bilgisayarlar arası oda tahsis edilmiş hattın erişim süresi, şekilde sarı çizgi ile gösterilen birkaç milisaniye mertebesindedir. Mikro hizmetlerin evrimi tüm hızıyla devam ettiği için, zaman tüketmenin bu kısmı da önemli.
Aynı şehirdeki geliştirilmiş çoklu bilgisayar odası mimarisi, uygulama katmanını mantıksal olarak izole etmek için farklı hizmet kayıt merkezlerine dayanır. Bir istek bir bilgisayar odasına girdiği sürece, uygulama katmanı bir bilgisayar odasında işlenecektir. Tabii ki, ana veri tabanı sadece bir tarafta olduğu için, bu mimari hala bilgisayar odalarındaki veri erişim probleminin yarısını çözmüyor.
Bu mimari altında, iki bilgisayar odasına giren istek oranı girişte ayarlandığı sürece, iki bilgisayar odasının yük oranı hassas bir şekilde kontrol edilebilmektedir. Bu kabiliyete bağlı olarak, sitenin tamamında mavi-yeşil sürümler elde edilebilir.
"İki konum ve üç merkez", finansal sistemlerde yaygın olarak kullanılan bir çapraz veri merkezi genişletme ve bölgeler arası felaket kurtarma dağıtım modelidir, ancak bazı sorunlar da vardır. Uzaktan olağanüstü durum kurtarma bilgisayar odası, veritabanı ana düğümünden çok uzak ve erişim süresi çok uzun Uzak yedekleme düğüm verileri güçlü bir şekilde tutarlı değil, bu nedenle çevrimiçi hizmetler doğrudan sağlanamıyor.
Genişletme yetenekleri açısından, bölgeler arası yedekleme merkezleri çekirdek hizmetleri taşımadıkları için, çekirdek hizmetlerin bölgeler arası genişlemesi sorununu çözemezler; maliyet açısından, felaket kurtarma sistemi yalnızca düşük kaynak kullanımı ve yüksek maliyetle felaket kurtarma için kullanılır; Felaket kurtarma yeteneği açısından, felaket kurtarma sisteminin soğuk beklemesi nedeniyle, felaket kurtarma sırasında kullanılabilirlik düşüktür ve anahtarlama riski nispeten yüksektir.
Bahsi geçen mimarilerin özelliklerini özetlemek. Bu noktaya kadar, mikro hizmet sisteminin kendisi çok fazla değişmedi.Birkaç setin nasıl dağıtılacağı ve bunların nasıl izole edileceği sorusundan başka bir şey değildir.Her bir mikro hizmet seti hala basit bir mimariye sahiptir.
Karınca Mali Birimleştirme Uygulaması
Ant Financial'ın modüler mimarisinin geliştirilmesinin arkasındaki orijinal itici güç iki cümleyle özetlenebilir:
İlki anlaşılması kolay, tam olarak daha önce tartışılan sorundur.Geleneksel iki konumlu üç merkezli mimari, bölgesel tek nokta sorunlarının çözümünde etkili değildir ve başka fikirlere ihtiyaç vardır. Ama sonuçta bu çok acil bir mesele değil, hayat ve ölüm için bütünleşmenin öneminden gerçekten bahseden ikincisidir.
2013 yılına gelindiğinde, Alipay'in çekirdek veritabanı, yeterli kapasiteden fazla kapasiteyle yatay olarak bölünmüştür, uygulama katmanı durumsuzdur ve isteğe göre yatay olarak genişletilebilir. Ancak o yıl Double Eleven'ın iş göstergelerine göre teknik planlama yaparken çetrefilli bir sorunla karşılaştık: Oracle veritabanı bağlantısı yeterli değildi.
Veritabanı, kullanıcı boyutuna göre yatay olarak bölünmüş olsa da, uygulama katmanı trafiği tamamen rastgeledir. Şekildeki basitleştirilmiş iş bağlantısını örnek olarak alırsak, herhangi bir çekirdek uygulama düğümü C herhangi bir veritabanı düğümüne D erişebilir ve bir veritabanı bağlantısını işgal etmesi gerekir. Bağlantı, veri tabanının çok değerli bir kaynağıdır ve bir üst sınırı vardır. O sırada Alipay, uygulama kümesini genişletememe sorunuyla karşı karşıya kaldı, çünkü her ek makinenin her veri alt veritabanına birkaç bağlantı eklemesi gerekiyordu ve bu sırada birkaç çekirdek veritabanına bağlantı sayısı üst sınıra ulaşmıştı. Uygulama genişletilemez, bu da Alipay sisteminin kapasitesinin dondurulduğu ve daha fazla iş büyümesi olamayacağı anlamına gelir. Büyük promosyondan bahsetmiyorum bile, bir süre günlük işleri bile destekleyemeyebilir.
Birleştirilmiş mimari, uygulama katmanının aynı zamanda veri katmanının aynı bölme boyutlarına göre bir sunucu grubundaki tüm istek bağlantısını birleştirebilmesi durumunda, uygulama katmanından veri katmanına kapalı bir birim oluşturulabileceği varsayımına dayanır. Veritabanının yalnızca bu birimin uygulama düğümünün talebini taşıması gerekir, bu da bağlantı sayısını büyük ölçüde azaltır. "Ünite" nispeten bağımsız bir bütün olarak hareket ettirilebilir ve hatta ünitenin bir kısmı uzak bir yere konuşlandırılabilir.
Birleştirme için birkaç önemli tasarım ilkesi vardır:
- Temel iş parçalanabilir olmalıdır
- Çekirdek işin parçalanmasının dengeli olması sağlanmalıdır. Örneğin, Alipay, parçalama boyutu olarak kullanıcı kimliğini kullanır
- Ana iş mümkün olduğunca bağımsız olmalı ve görüşme mümkün olduğu kadar kapalı olmalıdır.
- Sistemin tamamı, fiziksel dağıtımdan ziyade mantıksal bölümler için tasarlanmalıdır
Uygulamada, birkaç eşit birimi mantıksal olarak bölmenizi ve ardından birimleri gerçek fiziksel koşullara göre fiziksel veri merkezine dağıtmanızı öneririz. Eşit birimin faydası, bir birimin basınç testi sonuçlarına göre uygun bir şekilde tüm istasyonun kapasitesine dönüştürülebilen kapasite planlamasının yapılmasının daha kolay olmasıdır.
Birime Bölgesel Bölge diyoruz. Örneğin, veriler 100 parçaya bölünmüş ve mantıksal olarak her biri 20 parça veri taşıyan 5 Bölgesel Bölgeye bölünmüştür. İlk dağıtım, iki konum ve üç merkez olabilir (birden çok birimin aynı veri merkezinde konumlandırılmasına izin verir). Mimarinin gelişmesiyle birlikte tüm birim yeniden konumlandırılır ve üç lokasyona ve beş merkeze dönüşür ve uygulama katmanının fiziksel seviyedeki değişiklikleri algılaması gerekmez.
Önceki kahvaltı satın alma örneğine dönersek, Xiao Wangın kimliği 12345666 ve parça numarası 66dır ve Bölge 04e ait olmalıdır; Zhang Teyzenin kimliği 54321233 ve parça numarası Bölge 02ye ait olması gereken 33dür.
Uygulama katmanı, iş parametrelerindeki parçalanma konumunu otomatik olarak tanımlayacak ve talebi doğru birime gönderecektir. İş tasarımında, seri numarasının parçalama konumunun ödeme yapan kullanıcının parçalama konumuyla tutarlı olmasını sağlayacağız, böylece çoğu mikro hizmet çağrısı Bölgesel Bölge 04'te birleşecektir.
Ancak transfer işlemi kesinlikle farklı birimlerde yer alması muhtemel iki hesabı içerecektir. Zhang Teyze'nin hesabı, başka bir şehirde Bölge 02'de bulunuyor. Ödeme sistemi, Zhang Teyze'nin hesabına para eklemek için muhasebe sistemini çağırdığında, birimler arasında Bölgesel Bölge 02'nin muhasebe hizmetini aramalıdır. Şekildeki kırmızı çizgi, uzun süren (onlarca milisaniye) uzaktan erişimi gösterir.
Makro zaman alıcı diyagramdan, birimleştirme fikrini anlamak daha kolaydır: Bir birim içinde yüksek uyum, birimler arasında düşük bağlantı, birimler arası aramalardan kaçınılamaz, ancak genel zaman alıcıyı azaltmak için mümkün olduğunca birkaç hizmet katmanı çağrısıyla sınırlandırılmalıdır. Kabul edilebilir bir aralıkta kontrol (doğrudan kullanıcı deneyimi ve genel iş hacmi üzerindeki etki dahil).
Daha önce bahsettiğim şey, normal şartlar altında nasıl "daha fazla yaşanacağı" idi .. Bir bilgisayar odası arızası durumunda, afet toleransı ve birimler arasında karşılıklı yedekleme rolünü oynamak gerekir.
Bir şehrin genel olarak arızalanması durumunda, uygulama katmanı trafiği düzenli olarak değiştirilecek ve önceden planlanan diğer birimler tarafından üstlenilecektir.
Veri katmanı, felaket kurtarma birimine karşılık gelen bağımlı düğümleri otomatik olarak ana düğüm olarak seçen kendi geliştirdiği Paxos protokol tabanlı dağıtılmış veritabanı OceanBase'e dayanır, böylece uygulama parçalama ve veri parçalama aynı birimde birleşmeye devam eder. "İki yer, üç merkez" ve "üç yer ve beş merkez" fiziksel mimarisini planlamamızın nedeni, aslında Ocean Base'in kopya dağıtım stratejisiyle yakından ilgilidir. Veri katmanı farklı yerlerde daha canlıdır ki bu da ileride özel konularda paylaşılabilecek bir diğer önemli konu ki burada sadece kısaca bahsedilmektedir.
Bu şekilde, birleşik uzaktan çoklu aktif mimari yardımıyla, başlangıçta gösterilen şehir düzeyinde afet tolerans geçişini 26 saniyede tamamlama yeteneği gerçekleştirilebilir.
Temel teknik bileşenler
Birimleştirme, DNS katmanı, ters proxy katmanı, ağ geçidi / WEB katmanı, hizmet katmanı ve veri erişim katmanını içeren yukarıdan aşağıya birden çok bileşenin birlikte çalışmasını gerektiren karmaşık bir sistem mühendisliğidir.
Genel rehber ideoloji, "kaybolduğunda nasıl geri dönüleceğini bilen çok katmanlı savunma" dır. Her katman yeterli bilgiyi elde ettiği sürece talebi en kısa sürede doğru birime iletir, yeterli değilse bir sonraki katmana geçin.
- DNS katmanı mantıksal olarak herhangi bir iş katmanı bilgisini algılayamaz, ancak "çoklu alan adı teknolojisi" adı verilen bir optimizasyon yaptık. Örneğin, bilgisayar tarafındaki yazar kasanın alan adı cashier.alipay.com'dur.Sistem, bir kullanıcı verisinin hangi birime ait olduğunu bildiğinde, doğrudan ayrı bir alan adına erişebilir ve alt katmandan kaçınarak doğrudan ilgili veri merkezine çözümleyebilir. Bilgisayar odaları arasında ilerle. Örneğin, yukarıdaki şekilde cashiergtj.alipay.com, gtj, dahili bir veri merkezinin numarasıdır. Mobil terminal, müşteriye kurallar yayınlayarak da benzer etkilere ulaşabilir.
- Ters vekil katmanı, Nginx'in ikincil gelişimine dayanmaktadır.Arka uç sistemi, kullanıcının ait olduğu birimi parametreler aracılığıyla tanımladıktan sonra, Çerez'e belirli bir tanımlayıcı yazar. Bir sonraki talepte, ters vekil katmanı bunu tanıyabilir ve doğrudan ilgili birime iletebilir.
- Ağ geçidi / web katmanı, uygulamadaki ilk savunma hattıdır ve iş mantığının gerçekten var olabileceği yerdir. Oturumdaki kullanıcı kimliği alanını genel bir HTTP durdurucuda tanımlayın Bu birimin isteği değilse, doğru birime iletin. Tanımlayıcıyı Çerez'e yazın ve bir sonraki istek ters proxy katmanında doğru şekilde iletilebilir.
- Hizmet katmanı RPC çerçevesi ve kayıt defteri, birimleştirme yetenekleri için yerleşik desteğe sahiptir ve istek parametrelerine göre doğru birimin hizmet sağlayıcısını şeffaf bir şekilde bulabilir.
- Veri erişim katmanı son garantidir.Önceki tüm savunma hatları başarısız olsa ve bir talep yanlış birime girse bile, veritabanına erişirken kesinlikle doğru veritabanı tablosuna gidecek, bu da en çok uzun zaman alacak ancak kesinlikle olmayacak Yanlış verilere erişilecek.
Bu kadar çok bileşenin birlikte çalışması için, aynı kural yapılandırma bilgilerini paylaşmaları gerekir. Verimli bir konfigürasyon merkezi aracılığıyla dağıtılmış bir ortamdaki tüm düğümleri yönetmek ve dağıtmak için küresel bir birimleştirilmiş kural yönetimi ve kontrol merkezi bulunmalıdır.
Kuralların içeriği, şehrin topolojik yapısını, bilgisayar odasını ve mantıksal birimi tanımlayan nispeten zengindir ve daha da önemlisi, parça kimliği ile mantıksal birim arasındaki eşleştirme ilişkisini açıklar.
Hizmet kayıt defteri yerleşik birim alanlarına sahiptir ve tüm hizmet sağlayıcı düğümlerinin "mantıksal birim" öznitelikleri vardır. Farklı bilgisayar odalarının kayıt merkezleri, verileri birbirleriyle senkronize eder ve nihayetinde tüm hizmet tüketicileri, her mantıksal birimin hangi hizmet sağlayıcıya sahip olduğunu bilir. RPC çerçevesi, gerektiğinde çağıran hedefi seçebilir.
RPC çerçevesinin kendisi iş mantığını anlamıyor.Hangi hizmet biriminin ayarlanması gerektiğini bilmek istiyorsanız, bilgiler yalnızca iş parametrelerinden gelebilir. Sıfırdan tasarlanmış bir çerçeve ise, sabit bir parametrenin parça kimliğini temsil ettiği ve arayanın bu parametreyi geçmesi gerektiği doğrudan kabul edilebilir. Ancak birimleşme, işin uzun yıllardır devam ettiği mimari bir dönüşümdür, mevcut tüm hizmetlerin arayüzünü değiştirmek mümkün değildir. Arayan kişiden, uzak hizmeti aramadan önce parça kimliğini ThreadLocal'a koymasını ister misiniz? Bu aynı zamanda çok uygunsuzdur ve RPC çerçevesinin şeffaflık ilkesini ihlal eder.
Dolayısıyla çözümümüz, çerçevenin bir arabirimi tanımlaması ve hizmet sağlayıcının, parça kimliğinin iş parametrelerinden nasıl elde edileceğini açıklayan bir uygulama sınıfı vermesidir. Servis sağlayıcı arabirime açıklama ekler ve çerçeveye uygulama sınıfının yolunu söyler. Çerçeve, RPC çağrısını yürütürken ek açıklamanın uygulanmasına göre parametrelerden parça kimliğini yakalayabilir. Genel yönlendirme kuralındaki parça kimliği ve mantıksal birim arasındaki eşleme ilişkisiyle birleştirildiğinde, hangi birimin hizmet sağlayıcısının seçilmesi gerektiğini bilebilirsiniz.
Sonuna yaz
Bu makale, Ant Financial'ın uzak çoklu yaşam birimi mimarisi ilkesini ve bu mimari altında mikro hizmet sisteminin temel teknoloji gerçekleştirmesini vurgulayarak tanıtmaktadır. Birleştirmeyi mühendislik düzeyinde gerçek anlamda uygulamak için, ilgili teknik sorunlar bundan çok daha fazlasıdır. Örneğin: Veri katmanında felaket nasıl tolere edilir? Yatay olarak bölünemeyen işletmelerle nasıl başa çıkılır?
Transfer: https://www.infoq.cn/article/kihSqp_twV16tiiPa1LO
