新金融分布式架構之SOFAStack解決方案

2021-10-24 03:03:52 字數 3254 閱讀 6912

金融行業正在流淌著一股去ioe,去集中化的it架構轉型洪流。我有幸參與到這股洪流中,見證這一重大變革。以下是我對這股洪流的一些思考和想法。

眾所周知,目前大部分金融機構的it架構還是以「ioe」的ibm大小型機,oracle資料庫,emc儲存為基礎的集中式架構。

這種架構有以下優點:

這些產品目前承載著世界上眾多金融行業的核心系統,而這些產品的廠家在這個領域有幾十年的積累,產品的成熟度,可靠性,可用性可見一斑。

不過這種架構也有三大缺點:

為了避免集中式架構的三大缺點,以網際網路銀行為代表的新金融it架構浮出水面。最開始的思路就**於網際網路+:將網際網路的架構加上金融架構。這種模式吸收了網際網路架構的優勢,同時保留了金融行業的高標準要求。

這種it架構基於開放式的平台,採用廉價的pc伺服器集群,形成分布式的架構,在有高效能,高擴充套件性,低成本的基礎上,同時滿足金融架構的高可用,低風險,強管控的要求。

在新金融的it架構框架下,大量廉價的pc伺服器集群(以開源的linux系統為主)替代了大小型機,很好的詮釋了團結就是力量。正所謂三個臭皮匠頂乙個諸葛亮,整合的策略對了,三個臭皮匠的能量就能聚合起來發揮出巨大的能量。同時,將集中式的服務拆分成微服務,部署在大量pc伺服器上能實現高效能,高擴充套件性,低成本,高可用的要求。

以mysql為代表的開源資料庫替代了封閉的oracle資料庫。我們不光能使用這些開源資料庫,檢視源**,而且我們還能貢獻我們的智慧型,讓它變得更好。雖然單個這類資料庫的效能可能沒有oracle的好,但是將他們整合起來形成分布式資料庫,然後使用分庫分表的手段可以達到高效能,高擴充套件性,低成本,高可用,低風險的要求。

分布式儲存技術在某些程度上可以替代emc的儲存。它最大的特點就是高可用性,高可擴充套件性和高資料可靠性。其典型的開源產品有google fs,hdfs,cephfs,glusterfs。

除了上文提到的成本問題,自主可控問題,高可擴充套件性問題外,我認為還有以下原因促使金融機構要考慮使用新的架構。

客戶連線的複雜化,除了櫃檯,**連線,還會有海量使用者隨時從各種地方,各種裝置的連線。這些連線對內部系統連線數,特別是session連線數和資料庫連線數來說是巨大的挑戰。金融機構需要新的架構來承載海量的連線,防止系統被打垮。

前面談了集中式架構的缺點,有人會問分布式架構就沒有缺點了嗎?似乎分布式系統只能同時滿足一致性,可用性,分割槽容錯性三者之二吧?確實沒錯。

對於金融場景來說,高可用,分割槽容錯性不可或缺,而且一致性也需要得到保證(畢竟誰也不想看到轉賬到朋友的錢沒有到賬,結果自己的餘額卻被扣掉了吧)。

但是,需要注意的是,這種三選二的說法其實是按照集中式架構的模式照搬到分布式架構而言的。試想一下,一台強大的資料庫被拆分成了n臺資料庫,這n臺資料庫之間的資料需要時間同步,當異常發生時,可能就產生了資料的不一致性。

那麼我們換乙個角度思考一下這個問題。我們將原來的資料庫拆分成了n臺資料庫之後,每台資料庫也只處理原來業務的1/n,同時其和其他處理(n-1)/n業務的資料庫之間不進行同步,這樣是否就可以解決這個一致性的問題了呢?答案是顯而易見的。

這時候有同學又要問了,那如何能保證每台資料庫只處理原來業務的1/n?同時資料庫的高可用怎麼辦?

對於第乙個問題,支付寶,網商銀行給出了答案:使用ldc(單元化)架構,乙個能完成所有業務操作的自包含集合,在這個集合中包含了所有業務所需的所有服務,以及分配給這個單元的資料。將業務按照一定維度進行拆分,拆分成n份,每份由乙個單元的服務和資料庫處理即可。

對於第二個問題,我們可以給主資料庫配上兩個從資料庫,同時實現他們之間的強一致性同步。雖說效能上稍微有些下降,但是卻能使整個分布式系統滿足金融場景的特殊需求。

此外,從上圖也可以看出ldc架構另乙個好處就是天然自帶灰度屬性。新發布的功能可以在某些特殊的業務單元中進行灰度驗證,降低因為新版本引發的故障的影響範圍。

綜上所述,分布式架構理論上可以滿足金融場景的特殊需求。

阿里旗下的支付寶,網商銀行的這套ldc單元化架構依託於sofastack™(scalable open financial architecture stack)。它包含了構建金融級雲原生架構所需的各個元件,也是在金融場景裡錘煉出來的最佳實踐。提供微服務應用開發、部署發布、專案管理、監控運維、容災高可用等全棧式解決方案,並相容 dubbo、spring cloud 等微服務執行環境,助力客戶各類應用輕鬆轉型分布式架構。

在巨集觀架構層面,sofastack提供單機房向同城雙活、兩地三中心、異地多活架構演進路線,使系統容量能在多個資料中心內任意擴充套件和排程,充分利用伺服器資源,提供機房級容災能力,保證業務連續性。

異地多活單元化架構是「三地五中心」部署模式的技術創新。在該架構解決方案下,可以避免跨機房、跨城市訪問的延遲,真正實現異地多活部署,不但消除了傳統「兩地三中心」架構中的單獨冷備中心,並提公升了災備高可用能力,無論在成本還是在伸縮性、高可用方面,都帶來了巨大的優勢。

在微服務層面,sofastack包括了乙個面向未來架構的微服務平台,支援異構應用融合遷移。

微服務平台通過 sofa 微服務和 service mesh 微服務,提供了既支援 sofa 框架又支援 service mesh 架構的微服務管理和治理能力,解決使用者在技術轉型期間與未改造的遺留系統相互之間打通和過渡問題,幫助金融機構平穩的從傳統的集中式、微服務架構演進到雲原生架構。

在分布式應用元件層面,sofastack還提供了分布式中介軟體套件以滿足傳統金融架構的平滑遷移、融合適配,以穩妥應對業務公升級變更,並積極應對金融交易系統所面臨的服務和資料擴充套件性、事務一致性、秒級容災、彈性供給與排程等關鍵技術挑戰。

所謂天下大勢,合久必分,分久必合。在我看來,架構也是如此。現在,我們正處在合久必分的洪流中。但是未來,可能是較長之後的未來,未必不會出現分久必合,合久必分的反覆。

比如說,未來,我們掌握了自我可控的價效比高的強大核心計算技術;

比如說,量子計算,生物計算,光子計算,超導計算等有了巨大突破;

那麼,那時候未必不會出現分久必合的局面。

再遠一些的未來,由於資料範圍擴大,我們可能不光要計算乙個省的資料,更可能需要計算乙個國,甚至整個地球的資料;

再遠一些的未來,由於資料維度擴大,資料量也會**;

那麼,那時候未必不會再次出現合久必分的局面。

讓我們拭目以待吧!

python分布式架構 分布式架構

1.分布式架構 採用centos mongodb windows2012 python redis進行分布式架構搭建,mongodb的框架最核心的設計就是 mongodb和mapreduce。mongodb為海量的資料提供了儲存,則mapreduce為海量的資料提供了計算,windows2012作為...

分布式架構之美

我們都知道,當今無論在bat這樣的大公司,還是各種各樣的小公司,甚至是傳統行業剛轉網際網路的企業都開始使用分布式架構,那麼什麼叫分布式架構呢?分布式架構有什麼好處呢?分布式架構經過了怎樣的發展呢?是哪家企業開啟了分布式架構的時代呢?讀完本文,你就會得到這些答案,下面讓我們一起來開啟分布式概述的奇妙之...

分布式架構

cap原理 c 一致性 多節點資料的一致 a 可用性 保證服務持續可用 多節點 多型伺服器 p 分割槽容忍性 是否可將資料存到多個地方 設計不可能同時滿足cap ac 放棄分割槽容忍,物理資料庫 ap 可以短暫的容忍資料不一致 nosql資料庫 cp 放棄可用性 springcloud有一下功能 e...