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