可能部分來賓已經在外面看到過我的一些文章，但是正式開始之前還是想做一個小小的調查，在座的各位有沒有對網商銀行有過初步了解的？今天我的分享主要從這樣幾個方面進行：網商銀行的發展現狀、服務架構分層和實踐、全鏈路壓測、跨地域多機房切換等等。

網商銀行基于阿里巴巴螞蟻金服的自營體系，但是在PaaS層面有些不一樣的地方，已經完成整個產品化的過程。現在整個基于2018/26949.html">微服務的單一化架構，核心思想就是基于數據來把拆分思路提升到接入層，就是每一個數據中心都有很多業務單元，更多的是承載核心業務邏輯，每個單元都會處理部分用戶數據。共享單元也有一個最大的特點，客戶的數據也會放在共享單元給業務單元反饋，全域單元就是產品應用，比如滿足批量處理的用戶數據。

我們可以分成技術層、渠道層、開放層和運營層，有些原則也是和大家差不多的，常規的應用類型分為存款、信貸和理財，我們會把底層核心的云客戶、云產品服務進行分離，也會考慮是不是滿足批量交易或者后臺小號交易，按照領域類型來看我們會進行清算、核算和資產類型劃分，也會關注關鍵應用是否成就，需要滿足單一化架構的約束，進行服務更加細致的劃分。

全鏈路壓測也是非常重要的條塊，怎樣探測我們的生產環境真實情況，挑戰也是比較大的，早期就是所有核心業務都要滿足全鏈路壓測的要求，每個服務都會要求同時進到生產表和壓測表，流量方面通過我們自己的壓測平臺進行數據準備，比較依賴于單元進行流量識別，生產流量和壓測流量不會被判定為非法的安全工具。

我們真正實踐過程當中發生多次，這些遺漏怎樣進行兜底，我們很依賴于中心對流量的判斷。2018/26949.html">微服務架構也有很多異構化的過程，進行壓測的時候需要考慮過程當中會不會發生丟失，就是整個系統設計當中需要重點考慮。除了流量評估之外，我們每年的重大活動都是通過壓測，早期的雙核到多核，包括一些云產品的切換，整個過程都是依賴于怎樣保證業務的穩定性，也是進行系統的預熱，每個月都會有固定的窗口，香港免備案主機，可以看到我們業務的成功率是怎樣的，通過自己的共享平臺注入到只會影響到壓測當中。

右上角這張圖當中可以看到一個比較陡的曲線，比如100個分庫，服務器擴容的時候會有一個更大的效應，就是導致整個數據庫的后端崩潰，所以從這個角度來說，擴容其實是有一個比較明顯的瓶頸。因為2018/26949.html">微服務架構提升是沒有一個有序的管控，其實數據層面也會出現這種交叉的情況，由于控制線的問題就會導致所有的服務器崩潰，平時如果不進行流量日常化的運轉，看起來資源利用率是非常低的。

我們可以看到某個具體數據單元進行二次邏輯劃分，有的單元承載30%的流量，根據機房自身的服務器規模以及基礎設施情況決定流量的配置，跨地域的部署就是解決機房的路由實驗，內部也是用了一些改造，可能用戶數據已經不在機房里面，所以需要進行二次轉化，就是轉化到正確的機房，需要判斷這個數據是不是屬于本單元，那么還會進行一次轉化，核心就是用戶定位和整個單元面對的關系，數據聚焦到單元也是依賴于這種協同服務。

我們在這個過程當中做的事情還是很多，最大的挑戰在于怎樣把所有的機房做成一個整體，就是針對allocation進行跟進，然后歸到請求的鏈路就可以完成整個過程，但是基礎設施的配套過程還是比較漫長，花了一年多的時間，也有提升我們產品化的能力。

這是我們建設鏈路獲得的很明顯的紅利，就是日常會有很多收益，也是基于整個一鍵切換的平臺，就是需要把這個單元調成0%就可以，在這種情況下整個業務就會得到恢復，實踐過程當中我們并不需要去找，只是集中在某個固定單元切換就可以了。整個機房所有單元都出現故障的話，我們只需要調到另外一個對應的單元，然后再把路由進行調整，就是要把所有UI切換過來，云服務器租用，不僅是數據層面的，也包括上層應用的，都是流量控制中心當中進行調度。

每次重大架構升級做起來都會比較漫長，因為每個應用都要進行改造和回歸，每個團隊的資源情況也不一致，所以推動架構的過程非常漫長。未來我們希望把不是和業務強相關的邏輯下沉，這個過程當中只是把我們的安全架構和管控往下流轉，整個APP規模也會明顯下降，屬于給我們未來體系打下基礎。按照結構來看，我們的APP也是部署在一個Port上面，這種部署結構會帶來比較好的特點，就是未來隨著整個架構升級，不會有更多對業務的打擾，基礎云和安全云都會得到發展，而且可以更好地控制自己版本發布，所以就會得到效益層面極大的提升。隨著整個Service Mesh的落地，很多服務都可以提升出來。