<mark id="oztn4"></mark>
0
| 本文作者： 周蕾 | 2021-02-24 16:19 | 專題：銀行系統(tǒng)云化升級 實戰(zhàn)體驗營 |
傳統(tǒng)銀行有必要擁抱云原生嗎？這個問題，或許還沒有太多答案。
但這些問題，在傳統(tǒng)銀行大步向前、業(yè)務飛速發(fā)展的過程中，一定會遇到：
怎樣才能在整個底盤升級過程中，盡量避免對已上線業(yè)務造成打擾？
想做到架構(gòu)平穩(wěn)切換，壓測方案如何設計定奪？
銀行怎樣改造數(shù)據(jù)中心，才能保證不同業(yè)務間的流量調(diào)度、隔離一切正常？
而網(wǎng)商銀行就用自身的云原生實踐給出了解答。從云平臺+分布式架構(gòu)，演化到云原生、混合云彈性架構(gòu)，這家被稱為“國內(nèi)首家跑在云技術(shù)之上”的商業(yè)銀行，他們五年來的云化升級歷程，所遇到的典型挑戰(zhàn)、解決思路都頗具借鑒意義。
在雷鋒網(wǎng)《AI金融評論》與阿里云聯(lián)合主辦“銀行系統(tǒng)云化升級”實戰(zhàn)體驗營，網(wǎng)商銀行基礎技術(shù)架構(gòu)部負責人蔣易民就深入講解了他們的云原生演進之路。
欲獲得所有講者視頻以及PPT回顧內(nèi)容，可關(guān)注公眾號“AI金融評論”（ID: aijinrongpinglun），進群獲取回放鏈接。
以下為經(jīng)雷鋒網(wǎng)AI金融評論編輯的蔣易民演講內(nèi)容：
今天很榮幸和大家分享網(wǎng)商銀行的實踐情況。
從這張圖來看，網(wǎng)商銀行主要經(jīng)歷了三代架構(gòu)的演進。
一，2015-2016年，主要是基于云平臺+分布式架構(gòu)建立起來的。整個的部署模式是同城雙活模式。
二，2017-2018年，在同城雙活的基礎上需要建設一個異地數(shù)據(jù)中心，希望這個異地的數(shù)據(jù)中心在日常過程中能承載業(yè)務流量，能與杭州數(shù)據(jù)中心同時對外提供服務。
在滿足異地災備要求的同時考慮提升整個IT基礎設施的資產(chǎn)利用率，所以打造了單元化多活架構(gòu)，它是一個三地五中心的部署結(jié)構(gòu)。
三，2019年，網(wǎng)商銀行開始關(guān)注云原生架構(gòu)，包括開始引進一些產(chǎn)品，設計建設相關(guān)能力。在這個過程中，我們也建設了混合云彈性架構(gòu)，具備了在兩朵云之間調(diào)度資源的能力。
在上圖右側(cè)的曲線可以看出，從網(wǎng)商銀行開業(yè)，全行的容量水位大概是50 TPS，經(jīng)過多年的發(fā)展，到現(xiàn)在已經(jīng)到了5萬TPS。
但在整個過程中，也發(fā)現(xiàn)了存在的一些問題：
在底層基礎架構(gòu)頻繁演進過程中，需要大量上層業(yè)務研發(fā)去配合。這個時候升級改造，控制進度、周期是非常難的。
一代架構(gòu)的演進大概需要兩年左右的時間，基本上把全行所有的系統(tǒng)都切過了。過程中，研發(fā)人員的體驗感也不是特別好。
怎樣才能在整個底盤升級過程中，盡量避免對已上線業(yè)務造成打擾？這也是我們引入云原生最初的一個原動力。
放眼多年的發(fā)展，我們的路徑是一種雙模路徑——為什么叫雙模？就是在多個架構(gòu)運行過程中，除了對新技術(shù)的探索，最重要的是要做好技術(shù)風險的防控，保證業(yè)務的連續(xù)性。
怎樣保證在新舊架構(gòu)演進的過程中，最大化地減少對業(yè)務的影響？
我們在進行新技術(shù)探索時，也需要做好風險防控。
新一代架構(gòu)誕生以后，并不是立馬全面投產(chǎn)，新老架構(gòu)會經(jīng)歷較長時間并軌運行，這種情況下是基于增量式的交付，逐漸把老的架構(gòu)往新的架構(gòu)演進，并且具備快速回退的能力。
回顧網(wǎng)商銀行多年的發(fā)展，全行的技術(shù)架構(gòu)特征，有以下幾個方面：
因為網(wǎng)商銀行是一家沒有線下網(wǎng)點的互聯(lián)網(wǎng)銀行，IT系統(tǒng)需要支撐上億的客戶，每天處理上億的交易量，雙11這種活動也會帶來流量的一個突增。同時還要確保安全、穩(wěn)定和可控。
從我行的架構(gòu)特征來看，要滿足這些高性能、高可靠，還有高彈性、高標準，低成本、低風險等要求，架構(gòu)演進主要也是圍繞著解決穩(wěn)定、效能、安全、容量、成本等多個方面進行。從安全角度來看，有兩個維度：
一，信息安全，主要是確保抵御惡意攻擊的能力，保證用戶數(shù)據(jù)和隱私安全。
二，資金安全，需要避免在交易過程中數(shù)據(jù)不一致，特別是一些缺陷導致公司和客戶的資金出現(xiàn)問題。
多年的架構(gòu)演進，“壓艙石”是什么，那非全鏈路追蹤和壓測能力莫屬。如何做到架構(gòu)平穩(wěn)切換，壓測方案的設計是其中重要一環(huán)。
從開業(yè)至今五年多，三代架構(gòu)的演進整體上是平滑的，我們認為很關(guān)鍵的一點是從第一代架構(gòu)誕生就已具備了全鏈路壓測的本領。我們的方案跟一些業(yè)內(nèi)方案可能存在一些差異，我們是直接拿生產(chǎn)環(huán)境去壓測的，沒有去做模擬的環(huán)境，盡最大可能避免環(huán)境配置和服務器的水位不同帶來的一些差異。
從上圖可以看出，我們計算上是共享的，但是存儲層面是同庫不同表。從這個角度來看，在壓測過程中是能最大化還原真實的生產(chǎn)流量對生產(chǎn)系統(tǒng)的壓力。
云原生架構(gòu)是基于云原生技術(shù)的一組架構(gòu)原則和設計模式的集合，最關(guān)鍵的點就是把一些業(yè)務處理邏輯中非功能性的代碼剝離出來，從而讓云設施接管應用中原有的大量非功能特性（如彈性、韌性、安全、可觀測性、灰度等）。
圖左可以看到，傳統(tǒng)架構(gòu)的一段代碼邏輯包含三部分，非功能性代碼、業(yè)務代碼、三方依賴。
而云原生，希望非功能性的代碼在理想情況下最大化的減少，相對的業(yè)務代碼只要聚焦自己的業(yè)務即可。
大量非功能的特性，包括彈性、容量、安全可觀測性、灰度等都會逐漸下沉到底層的基礎設施，特別像高可用能力、容災能力、容量保障、安全特性，還有一些可運維的特性，逐漸讓基礎設施去接管。
這種情況下可以看出，在我們在部署上會發(fā)生的一些變化。從圖的右下角看到，容器會進行進一步的拆分，拆成應用一個進程，邊車（sidecar）一個進程。
網(wǎng)商銀行云原生的關(guān)鍵實踐，主要包含4個部分：微服務，容器化，不可變基礎設施，服務網(wǎng)格。
受益于第一代跟第二代架構(gòu)打下的基礎，前兩個層面已經(jīng)有了較好的積累，我們在進行云原生實踐過程中沒有投入太多的精力，后兩個部分投入很大。
涉及到不可變基礎設施最重要的一點，就是要完成它的鏡像化改造。對此，我們的要求應用是無狀態(tài)化。
早期的微服務有部分系統(tǒng)并不具備無狀態(tài)化，此時要求逐漸變成無狀態(tài)化。對于服務網(wǎng)格，我們引進SOFA Mesh來實現(xiàn)Mesh的落地。（注：SOFA是螞蟻金服自主研發(fā)的分布式中間件，Scalable Open Financial Architecture；SOFAMesh即其第三輪開源產(chǎn)品）
現(xiàn)在網(wǎng)商銀行部署的一個基線，主要是三地五中心的模式。
從應用層看，現(xiàn)有容量運用三個數(shù)據(jù)中心已經(jīng)足夠，但在存儲層面選擇了5個中心。這種情況下，我們做的是多活的模式。
那么這套架構(gòu)是怎么建起來的？依賴于商業(yè)化的一些成熟產(chǎn)品，包括金融級中間件SOFASTACK、分布式數(shù)據(jù)庫OceanBase。
這套架構(gòu)最核心的一個特征，就是可以做到同城和異地容災切換時，RPO=0。
如圖所示，IDC1跟IDC2如果同時出現(xiàn)問題，我們可以做到分鐘級內(nèi)把流量切到IDC3。這個過程基于異地多活架構(gòu)提供的能力是非常快的。從近期生產(chǎn)演練的數(shù)據(jù)來看，同城大概是2分鐘，異地大概是3分鐘。
如圖所示，網(wǎng)商銀行早期也是非單元化。
非單元化有一個很典型的特點：在計算跟存儲上，會存在交叉訪問的情況。雖然網(wǎng)商早期設計中，做好了分庫分表的設計，但從上層計算層面看，它也會出現(xiàn)跨層。
早期運用同城雙活的模式，兩邊的數(shù)據(jù)跟計算存在交叉，這是沒什么問題的。但要建設異地數(shù)據(jù)中心時，兩地之間的延遲可能會導致一次服務的耗時大幅上漲，可能會導致最終客戶的一筆交易會出現(xiàn)超時，這種情況下計算跟存儲之間的跨城通訊是不可以接受的。
如何解決？采用的是單元化的架構(gòu)模式，最典型特征是，它的流量是受控的，能形成一個小的閉環(huán)，讓計算跟存儲基本封閉在一個邏輯數(shù)據(jù)中心，但不排除有部分的跨城或者跨數(shù)據(jù)中心的訪問。
當跨城、跨數(shù)據(jù)中心的訪問是基于服務級別，不是數(shù)據(jù)級別的情況下，它的延遲是可以得到很好的控制。
當我們進入了單元化架構(gòu)，在服務上會有多種路由模式，除了在同一個數(shù)據(jù)中心內(nèi)部，單元之間、同城的數(shù)據(jù)中心之間也都會存在通訊的情況。最重要的是我們解決了跨城數(shù)據(jù)服務通訊。從實踐來看，延遲是可以接受的。
重點看右下角的路由表，分片標記用戶，用戶屬于某一個數(shù)據(jù)中心下面的一個單元，通過該路由表，用戶的請求進入后會找到對應的數(shù)據(jù)中心下面的單元。也可能會出現(xiàn)一部分用戶進入后，并沒有到正確的數(shù)據(jù)中心，這種情況下我們會在接入層把用戶的請求轉(zhuǎn)到它對應的一個數(shù)據(jù)中心。
路由的核心是在SDK層面解決的。在業(yè)務系統(tǒng)代碼里引入一些關(guān)鍵的API去做一些路由的定制，這種情況其實是非常重的。
從全行的單元化升級來看，花的時間也較長，這個跨度至少是一年以上，才會把一些關(guān)鍵的系統(tǒng)全部切到單元化架構(gòu)上面。
網(wǎng)商銀行早期也經(jīng)歷過富容器，這種較重，包含了所有的應用發(fā)布部署需要的依賴，不限于一些關(guān)鍵的RPC、消息、數(shù)據(jù)庫等SDK。
最小的部署單元也是一個容器，在云原生里做進一步劃分。
容器會區(qū)分為APP的容器，跟Sidecar 的容器。根據(jù)現(xiàn)在的實踐來看，主要是包含Service Mesh里面MOSN的容器，還有DBMesh的容器。這兩個容器解決的是 RPC、消息，還有數(shù)據(jù)庫跟緩存層面的轉(zhuǎn)發(fā)。
這種模式有一個最大的好處，就是MOSN跟DBMesh可以獨立演進，即可以不需要在上層業(yè)務容器配合的情況下，自己完成一些升級跟發(fā)布。
當我們做一次全行的架構(gòu)升級，富容器模式會帶著全行所有的應用，可能會進行一到多次迭代的發(fā)布。
升級一個SDK最大的問題是什么呢？因為各個系統(tǒng)有自己的進度安排，各自資源可能不一致。要做到全行統(tǒng)一升級，周期往往會拉得非常長。
最不可控的是什么？升級過程中，不同的系統(tǒng)質(zhì)量保障各有差異。有些可能做得非常好，但有些如果稍有瑕疵，就會引發(fā)生產(chǎn)問題，這種情況下很難通過統(tǒng)一的手段去保障。
全行架構(gòu)升級過程中，關(guān)注質(zhì)量的品質(zhì)，一致性和普遍性。
相對而言，輕容器較好做，因為所有的能力下沉到MOSN跟DBMesh之后，只要在這兩個層面做好質(zhì)量保障，聚焦后能保障升級品質(zhì)的一致性和普遍性。上層云的應用很少會關(guān)注下層的一些變化。
舉個例子，有一次全行升級，大概是一個人花了不到一個月的時間，把全行上萬的容器全部進行升級，基本不會對上層的業(yè)務造成打擾。所以輕容器相比富容器模式有了極大的提升。
早期發(fā)布時，這是分階段的，一般要先創(chuàng)建服務器，再下載依賴，過程中可能還要安裝一些插件。全程存在很多變量，包括環(huán)境標記，依賴于不同人的配置能力。
早期配置的過程，會把一部分代碼的參數(shù)放在配置平臺。相當于引入一個可變的變量。
當配置平臺發(fā)生一些變化，整個部署的效果就可能會出現(xiàn)差異，最明顯的就是線下環(huán)境部署沒問題，但在生產(chǎn)過程可能會發(fā)現(xiàn)問題。
怎么解決？在云原生架構(gòu)理念上，我們考慮把所有的信息都放在鏡像化包中，最大的好處是所有東西都包含在一個鏡像里面，就可以從鏡像環(huán)境到生產(chǎn)環(huán)境都使用同一個鏡像。
這個過程需要應用保證它的無狀態(tài)化。如果做不到無狀態(tài)化，它就不能做到自動的擴收容和自動恢復。
從圖中可以看出，我們的鏡像是分層的，這有利于不同的團隊可以聚焦在自己的那一部分，然后整合起來形成一個大的鏡像。在發(fā)布過程中，能保證質(zhì)量品質(zhì)的一致性，不會受限類似于一些環(huán)境或者人的操作水平。
在實際的生產(chǎn)過程中，全行幾百個系統(tǒng)最典型的問題是單物理機故障對業(yè)務產(chǎn)生的影響較大。
物理機的規(guī)模較小，很容易導致部分核心系統(tǒng)的容器分布集中。普通的PC物理機會有宕機問題，造成影響面的半徑較大。
比方說一個核心系統(tǒng)，可能有百分之四十容器集中在這臺物理機上。當它出現(xiàn)問題，對業(yè)務穩(wěn)定有極大的挑戰(zhàn)，即使只是小部分出問題也會引起較大的抖動。
怎么解決？有了云原生架構(gòu)后，我們根據(jù)業(yè)務特點，包括應用等級，去制定策略，確保所有的調(diào)度不會集中在個別的物理機上，也可以說是把它“打散”。
另一方面，之前配置中心不能自動發(fā)現(xiàn)物理機上的容器問題并自動剔除，通過監(jiān)控 MOSN的監(jiān)控狀態(tài)，探測它的服務健康狀態(tài)。下發(fā)自愈策略后，當它發(fā)現(xiàn)監(jiān)控報警有問題，讓它自動剔除。
因為在分布式架構(gòu)下，很多業(yè)務最終會匯集到同一個服務上。怎樣保證這些服務占用的資源不會互相影響？這也是我們目前面臨的一個較大的挑戰(zhàn)。
其實除了物理機故障場景，在實際生產(chǎn)過程中還經(jīng)常遇到這種問題：因為業(yè)務場景增多，有一些日常過程中流量非常少的業(yè)務場景，突然間提速后，會導致周邊跟業(yè)務相關(guān)的所有系統(tǒng)發(fā)生變化。
這種情況下，很可能出現(xiàn)部分服務器請求積壓，導致其他業(yè)務請求發(fā)到這臺服務器時處理時會失敗。這種情況下可能會影響很多業(yè)務，嚴重情況時會出現(xiàn)“雪崩”效應。
很多時候聯(lián)機交易跟批量交易并沒有拆分系統(tǒng)，所以他們占用的資源是同一批。
這種情況下，在新的云原生架構(gòu)下，借助資源調(diào)度和流量的標記能力對資源進行隔離使用，這樣聯(lián)機交易和批量任務所依賴的資源就可以區(qū)分開來，同時，我們希望把這些批量任務托管起來，做到資源的彈性調(diào)度。
當批量任務開始跑批時，能動態(tài)給它更多的資源；但沒有跑批時，把資源給釋放出來，可以減少對聯(lián)機交易的一些影響。
從上圖可以看出，當一個流量進到生產(chǎn)系統(tǒng)時，它經(jīng)過了多個系統(tǒng)，最終它會反映到的底層是容器，當沒有進行有效區(qū)分時，不同的流量在容器內(nèi)部是互相干擾的。
基于新的云原生能力，在流量轉(zhuǎn)發(fā)的過程，它會有具備染色能力，可以在流量通過mosn時進行標記，讓它路由到指定的一些容器上，就可以做到不同業(yè)務請求下，它會路由到不同的容器集群里，業(yè)務之間的相互影響就得到進一步降低。
最典型的是生產(chǎn)遇到的熱點賬戶問題，很容易導致全行的交易抖動。如果我們可以識別不同的業(yè)務所導致的熱點，可以做到有效的隔離，發(fā)生熱點時不會影響到非產(chǎn)生熱點的其他業(yè)務場景。
而近幾年銀行在改造數(shù)據(jù)中心，新中心的流量調(diào)度能力以往是比較弱的。
數(shù)據(jù)中心間的流量調(diào)撥的一般做法會在流量入口層做處理。如果投產(chǎn)過程中出現(xiàn)問題，對業(yè)務打擾較大。雖然也能做到快速回切，但從銀行每天上億的交易筆數(shù)來看，哪怕是幾十秒，受影響的用戶數(shù)可能也非常大。
在新的云原生架構(gòu)之下，基于mosn可以打造更細粒度流量調(diào)撥，從數(shù)據(jù)中心層面進一步下沉到單個應用級別。可以找一些不敏感的應用服務先切流，避免影響到關(guān)鍵業(yè)務內(nèi)容。
云原生架構(gòu)的核心價值是可以實現(xiàn)流量的精細化隔離。
在單元化異地多活架構(gòu)下，可以做到數(shù)據(jù)中心里某一個邏輯區(qū)域的隔離。到云原生架構(gòu)下，可以把流量的隔離能力做得更細。
原來的模式下，兩個業(yè)務同時進來，還是會互相影響。而云原生模式，可以按業(yè)務等級進行管理。
我們會給不同敏感度的業(yè)務打上標記，以此區(qū)分業(yè)務應該到什么樣的容器下去做完成交易。
標記能力因為有MOSN，所以實現(xiàn)起來較容易。相比早期第二代架構(gòu)做單元化用UID做標記，是通過研發(fā)人員編寫代碼實現(xiàn)的。因此借助MOSN，可以用很低的代價實現(xiàn)這個邏輯。
運用MOSN之后新的數(shù)據(jù)中心啟用方式會有什么不一樣？
我們早期做新數(shù)據(jù)中心壓測，一般來說有兩種方式。
1、 通過找一些系統(tǒng)進行流量轉(zhuǎn)發(fā)。做流量轉(zhuǎn)發(fā)往往需要系統(tǒng)自我改造，這樣不具備規(guī)模化、快速化的復制能力。
2、 直接把流量入口遷入新的數(shù)據(jù)中心。
早期做數(shù)據(jù)中心壓測時，很難做到較細粒度，這和網(wǎng)商銀行是異地多活模式有很大關(guān)系。它有一個全局的路由表，如果做不到新舊數(shù)據(jù)中心隔離，就會有問題。
舉個例子：在沒有升級能力的情況下，如果做壓測，可能就需要讓全局路由表在新的數(shù)據(jù)中心生效。新的數(shù)據(jù)中心在沒有經(jīng)過充分驗證的情況下，一旦路由表生效，生產(chǎn)流量進入就很有可能導致故障。我們通過Mesh進行了路由表的隔離。
新舊數(shù)據(jù)中心的路由表是有差異的，這個差異體現(xiàn)在哪里？
兩個老數(shù)據(jù)中心生產(chǎn)流量配比可以做到50%：50%，新數(shù)據(jù)中心沒有生產(chǎn)流量，而壓測流量在兩個老數(shù)據(jù)中心和新數(shù)據(jù)中心中配比可以做到40%、40%、20%，壓測流量有一部分在新的機房進行處理，根據(jù)新的路由表轉(zhuǎn)到了新的數(shù)據(jù)中心。
Mesh在我們新的實踐過程中，可以支撐不同的技術(shù)棧。從網(wǎng)商銀行建站以來，我們是有一部分外購的系統(tǒng)，雖然它是Java技術(shù)棧，但是它可能和我們的體系，比方說基于SOFA，還是有差異的。
實踐層面上看，讓外購的廠商改成SOFA框架是很難的。傳統(tǒng)模式下是希望廠商適當改一部分，框架不用修改，他可能修改服務調(diào)用方式，而我行內(nèi)部的這些自研系統(tǒng)，他會提供某種輕量級的HTTP服務，暴露給外購系統(tǒng)進行互聯(lián)互通。
整個過程來看，代價是較高的，它對相關(guān)的每個系統(tǒng)都有改造要求。
現(xiàn)在隨著我們整個業(yè)務的發(fā)展，特別是智能化和新技術(shù)引進，逐漸出現(xiàn)了JAVA之外的其他語言系統(tǒng)，最典型的就是Python、GO語言，這些系統(tǒng)怎樣跟Java系統(tǒng)互聯(lián)互通？這種情況下其實也會帶來新的問題。
在云原生模式下，這個問題就變得簡單。因為sidecar解決了，像服務發(fā)現(xiàn)路由、加密。鑒權(quán)，限流等通用性問題，它集成了一些不同的語言，這種情況下，它只要提供一個SDK，輕量化就能對接上系統(tǒng)。
這樣服務提供方和服務消費者都不用做大的改動，只要單邊系統(tǒng)修改就可以，不需要所有相關(guān)方做改造，對我們整個研發(fā)效能提升和業(yè)務拓展帶來非常大的幫助。
總結(jié)下來，前面提到的云原生實踐更多的是在穩(wěn)定性、效能方面去提升。現(xiàn)在需要關(guān)注的問題，在云原生架構(gòu)模式下，我們做安全會有哪些不一樣的地方？
解決應用層的安全。
從整個基礎設施層面做到安全可信。其中包含多個環(huán)節(jié)，包括硬件準入，從主機的供應鏈層面可能要防止物理機入侵。
從鏡像準入層面做一些控制，防止鏡像被非法篡改后在生產(chǎn)上運行。
在有了MOSN以后，最大的好處就是可以做到全局的服務和數(shù)據(jù)鑒權(quán)。
原來那種架構(gòu)模式，如果要做數(shù)據(jù)鑒權(quán)跟服務鑒權(quán)，也需要很多系統(tǒng)去改，去做 SDK的升級。
在寫入鏡像中心時，要做安全可信。
1、首先，控制在研發(fā)環(huán)境的鏡像編譯、準入。
2、在整個鏡像被使用的過程中，去驗證鏡像是否安全。
3、從底層的物理機層面，在供應鏈采購時可能會做準入控制。
4、在上層應用層的容器啟動時，我們也會探測它是不是可信的。
有了MOSN，我們在進行服務的鑒權(quán)，還有數(shù)據(jù)的加密都可以下沉到相關(guān)的sidecar，這種時候做安全方面的控制都集中在底層的基礎設施，可以明顯看到云原生帶來的紅利。
上層的業(yè)務可以不用關(guān)心相關(guān)的要求，基本上安全工程師通過配置一些規(guī)則，然后把這些規(guī)則下發(fā)到全行相關(guān)的一些sidecar產(chǎn)品上即可，包括 MOSN、DBMESH。
問：壓測采用的是生產(chǎn)流量還是模擬的流量？
蔣易民：我們用的是模擬的流量，它跟生產(chǎn)流量是不一樣的。這是另外一套賬號體系，它不是真實的。
生產(chǎn)流量是真實的用戶，壓測流量來源于壓測平臺，且流量并不是同一套流量，用戶體系也是不一樣的。在存儲結(jié)構(gòu)上是同庫上兩套不同的表（表結(jié)構(gòu)完全一致但表名不同），落的數(shù)據(jù)處于不同的區(qū)域。
問：關(guān)于客戶統(tǒng)一視圖查詢的問題。
蔣易民：如果要在多個服務中獲得最新的客戶信息匯總，就需要把數(shù)據(jù)集中化處理了。但是從實際的過程看，至少在交易層面，是很少用到客戶信息的匯總，更多的是在批處理層面。在批處理層面，我們會把它放到類似于odps大數(shù)據(jù)平臺去解決。
所有數(shù)據(jù)回流到大數(shù)據(jù)平臺，多庫多表，最終會集中到一張表里，這個數(shù)據(jù)是全量的。
采用 sidecar以后，我們運行這套架構(gòu)也有較長時間了，對日常其實沒什么影響。基本上層業(yè)務對它沒有什么感知。整個sidecar引進以后，對資源的占用是非常少的，不會影響到整個系統(tǒng)的容量水平。
本次實戰(zhàn)體驗營由雷鋒網(wǎng)《AI金融評論》與阿里云聯(lián)合主辦。欲獲得所有講者視頻以及PPT回顧內(nèi)容，可關(guān)注公眾號“AI金融評論”（ID: aijinrongpinglun），進群獲取回放鏈接。
雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
專題
