1、 萬億級交易量下的支付平臺設(shè)計 本文主要是根據(jù)作者在2018QCon演講內(nèi)容整理而成：蘇寧金融交易量3年內(nèi)從1000億增長到萬億+，服務(wù)用戶3億+，服務(wù)場景從服務(wù)于蘇寧易購內(nèi)部生態(tài)，擴展到服務(wù)全渠道，全場景，多業(yè)態(tài)的線上線下智慧零售的開放生態(tài)圈，一方面要滿足公司業(yè)務(wù)發(fā)展要求，快速研發(fā)新產(chǎn)品，另一方面要滿足818大促，雙11等大促設(shè)計要求；本次主要介紹蘇寧支付系統(tǒng)如何實現(xiàn)500天性能提升2000倍，從100筆/秒提升到20萬筆/秒，給飛行中的飛機換引擎，將包括三大章節(jié)六個部分： 蘇寧支付平臺發(fā)展歷程，以及現(xiàn)在運行的總體架構(gòu)設(shè)計，以及配套的可視化作戰(zhàn)指揮系統(tǒng)，以及在業(yè)務(wù)急速變化，萬億級交易量的狀態(tài)

2、下，如何對全局架構(gòu)進行優(yōu)雅地重構(gòu)，以及重構(gòu)過程中的實戰(zhàn)案例，最后介紹一下我們目前規(guī)劃的、對未來的展望；具體技術(shù)包括高可用設(shè)計技巧，高伸縮性設(shè)計思路，彈性的流量和資源控制，異地多活，全鏈路壓測，消除數(shù)據(jù)瓶頸與單點，熱點追蹤與防護，故障自愈，賬務(wù)系統(tǒng)之大賬戶瓶頸解決方案，以及未來怎么實現(xiàn)機器人自動巡檢和自動修復(fù)等實戰(zhàn)經(jīng)驗分享。第一部分，我們介紹蘇寧支付平臺的演進路線， 架構(gòu)演進的驅(qū)動與目標；蘇寧支付平臺演進經(jīng)歷了四個階段：從傳統(tǒng)的架構(gòu)，到SOA架構(gòu)，到云計算架構(gòu)以及目前的智能支付引擎；服務(wù)場景也從單一的服務(wù)蘇寧易購，到服務(wù)蘇寧內(nèi)外部生態(tài)圈，再到提供行業(yè)解決方案。TPS從100到20w+的支付處理能

3、力；交付周期也從最初的按月交付到現(xiàn)在的準實時交付。那是什么驅(qū)動我們進行一次次的架構(gòu)演進呢？驅(qū)動力和目標是什么呢？支付平臺是整個金融的基礎(chǔ)設(shè)施，也是公共設(shè)施，服務(wù)于幾十個事業(yè)部的幾百條產(chǎn)品線，如果每一條產(chǎn)品線提一個需求，那就要同時響應(yīng)幾百個需求，同時還要面對業(yè)務(wù)的大促，因為蘇寧是O2O的模式，業(yè)務(wù)場景會更加復(fù)雜，線上線下都有：線下的五一、國慶；線上的418、618、818、雙11、雙12，基本上每兩個月就有一個S級大促；一方面要保證業(yè)務(wù)需求的快速響應(yīng)，另一方面也需要保證大促的安全穩(wěn)定，對來說業(yè)務(wù)需要快，對系統(tǒng)來講需要穩(wěn)，那就需要我們的系統(tǒng)，是一個高可用、可伸縮、低成本、快速交付的系統(tǒng)。第二部分介

4、紹現(xiàn)在正在運行的總體架構(gòu)設(shè)計，包括總體業(yè)務(wù)架構(gòu)設(shè)計，總體系統(tǒng)架構(gòu)設(shè)計，總體技術(shù)架構(gòu)設(shè)計，關(guān)鍵子域的架構(gòu)設(shè)計；首先是總體業(yè)務(wù)架構(gòu)設(shè)計，主要包括4個部分：第1部分是我們服務(wù)的渠道和場景，包括SDK,WAP,PC各端，線上線下門店；以及電商體系的應(yīng)用，金融APP的應(yīng)用等；第2是我們的合作方銀行：包括中農(nóng)工建交等以前的直連銀行，以后后來的網(wǎng)聯(lián)，銀聯(lián)等；第3是貫穿整個全流程的風(fēng)險控制體系與運營支撐體系，包括欺詐風(fēng)險，信用風(fēng)險，以及配置產(chǎn)品，運營的各種支撐系統(tǒng)；第4是云支付平臺本身。在云支付平臺中包含三大子架構(gòu)域：一是開放平臺，把我們內(nèi)部的服務(wù)統(tǒng)一開放出去給各個渠道、各個服務(wù)去使用；二是對這個平臺進行層層

5、抽象，將c端業(yè)務(wù)平臺當中線上線下的公用邏輯抽取到c端業(yè)務(wù)平臺，b端業(yè)務(wù)平臺當中各個行業(yè)支付的公用邏輯，我們會抽取到b端公用平臺。第3作為支付核心，會統(tǒng)一整合內(nèi)外部支付工具以及賬戶核心操作指令統(tǒng)一提供給上層使用。業(yè)務(wù)架構(gòu)決定了系統(tǒng)架構(gòu)，從縱向來看，我們分為應(yīng)用層、數(shù)據(jù)層、技術(shù)服務(wù)層、基礎(chǔ)設(shè)施層，以及貫穿整個全流程的決策支持與運營支撐層。從橫向來看，分成面向用戶和商戶的服務(wù)交付層（通過開放平臺交付給我們的合作伙伴，通過這個平臺前置服務(wù)于蘇寧易購生態(tài)圈的各個應(yīng)用場景）；應(yīng)用服務(wù)層（包括業(yè)務(wù)處理類、管理類、數(shù)據(jù)類）；通用服務(wù)層（即平時常見的支付收銀臺、風(fēng)控、合同計費等）；核心服務(wù)層（包括會員、賬務(wù)核心

6、、清結(jié)算等）；網(wǎng)關(guān)服務(wù)層（因為我們需要集成外部的一些服務(wù)，包括金融服務(wù)，通過金融交換服務(wù)去做；溝通網(wǎng)關(guān)，面向運營商的；業(yè)務(wù)網(wǎng)關(guān)，面向和我們合作的商戶的）；整體架構(gòu)的設(shè)計，我們采用了插件式的架構(gòu)設(shè)計思想，比如服務(wù)交付層，我們基于標準的平臺業(yè)務(wù)進行服務(wù)交付，這樣可以使各應(yīng)用域獨立并行的研發(fā)；對網(wǎng)關(guān)服務(wù)層，我們基于標準的外部服務(wù)引入，使平臺具有快速可擴展性。業(yè)務(wù)架構(gòu)和系統(tǒng)架構(gòu)決定了我們的技術(shù)架構(gòu)，技術(shù)架構(gòu)包括三大部分：持續(xù)交付層，以及支撐我們持續(xù)交付的中間件層以及基礎(chǔ)設(shè)施部分：持續(xù)交付重點有兩個，第一是快：開發(fā)快，所以我們有開發(fā)的插件、模板生成工具；測試快，從自動化測試到持續(xù)集成，到一鍵建站的統(tǒng)一拉

7、起；發(fā)布快，有現(xiàn)成的發(fā)布流程支持；業(yè)務(wù)驗收快，這個是我們支付平臺獨有的一項，上線之后要做業(yè)務(wù)匹配分析和還原，這個有兩點好處：（1）對業(yè)務(wù)來說，可以快速地知道需求有沒有按照業(yè)務(wù)預(yù)期的開發(fā)；（2）對研發(fā)人員來說，可以快速地知道研發(fā)的需求是否獲得了業(yè)務(wù)收益。這樣，業(yè)務(wù)和研發(fā)人員有了統(tǒng)一的視圖。第二是穩(wěn)：開發(fā)的過程會做這一些非功能性的設(shè)計，如：伸縮型設(shè)計，監(jiān)控設(shè)計，資損防控設(shè)計；資損防控設(shè)計有三層：第1層是開發(fā)與測試，第2次是監(jiān)控與核對，第3層是止損與追款。平穩(wěn)，發(fā)布時支持灰度發(fā)布和預(yù)案回滾。比如做升級，收單要從單庫切到多庫，不能一刀切，需要按業(yè)務(wù)場景、用戶、訪問鏈路灰度，可以保證整個系統(tǒng)的平穩(wěn)；如果

8、一個系統(tǒng)上線后，如果出問題能馬上實現(xiàn)回滾，對用戶沒有影響；接下來講關(guān)鍵子域架構(gòu)設(shè)計，從收銀臺到交易，從支付服務(wù)到支付引擎，我們?nèi)绾螌崿F(xiàn)標準化和插件化。首先收銀臺分為三層：第1層是業(yè)務(wù)產(chǎn)品層；第2層是業(yè)務(wù)接入層，會做一些異常的適配，如不同的errorCode可以展示不同的異常界面，對用戶體驗比較好。第3是核心層，用戶偏好與習(xí)慣、額度控制等。收銀臺是從一個簡單的收銀門面，千人一面，逐漸發(fā)展到千人千面，再到一人千面；就是不同的用戶在不同場景下看到的收銀臺是不一樣的，到同一個用戶在不同場景下也可以進行個性化的適配；這個是收單系統(tǒng)和交易系統(tǒng)的介紹：分成兩部分，一個是公用的部分，就是我通用的上下層的依賴，

9、比如支付引擎、會員、收銀臺、收費計費等，中間的收單服務(wù)層可以通過設(shè)計模式去封裝，根據(jù)不同的業(yè)務(wù)請求，然后統(tǒng)一做收單路由到不同的插件去處理。這樣即使有幾十條產(chǎn)品線同時請求，我們也能同時響應(yīng)，因為只需要改動一個插件即可；基于這種插件式架構(gòu)的設(shè)計思想，接下來的支付服務(wù)也是這樣設(shè)計的。支付引擎會整合銀行相關(guān)的外部支付工具，以及零錢寶、任性付、信用支付、現(xiàn)金貸等內(nèi)部支付工具，同時進行賬戶操作指令的封裝（主賬務(wù)核心和各個業(yè)務(wù)的微賬務(wù)核心）。對我們來說，賬務(wù)核心、支付工具群和支付外轉(zhuǎn)接中心都是一個個插件，開發(fā)速度快；在具體的一個支付工具內(nèi)部，也是插件式的；這樣就完全可以實現(xiàn)大規(guī)模的并行研發(fā)；最后是網(wǎng)關(guān)層，面

10、向接入銀行渠道和接入合作大商戶：第1層是報文組裝解析層，第2層是適配器層，第3層是路由引擎；由圖可見，每家銀行的公用邏輯相同，可以通過設(shè)計模式封裝。不同的是輸入?yún)?shù)的獲取策略以及輸出參數(shù)的不同闡釋策略。具體實踐時代碼結(jié)構(gòu)上可以用設(shè)計模式來封裝；實現(xiàn)代碼上每個銀行的輸入報文的不同，可以用velocity模板來做。在返回報文時，每個銀行的錯誤碼和異常處理機制也不一樣，可以通過groovy腳本來解析，這樣對于接入新銀行和商戶不用做系統(tǒng)發(fā)布，直接配置即可，實現(xiàn)插件化可配置；2015年前公司一個月接一家銀行，2016年后可以實現(xiàn)一個月接幾十家?；谇懊娴恼w架構(gòu)，我們思考，如果每個系統(tǒng)中的模塊、調(diào)用鏈都

11、能可視化，不管新的優(yōu)化、重構(gòu)、還是做業(yè)務(wù)需求都能快速實現(xiàn)?；谶@個理念，我們做了一個可視化作戰(zhàn)指揮系統(tǒng)。包括三大部分： 研發(fā)的可視化： 聚焦統(tǒng)一目標下的交付全鏈路、全資源可視化；統(tǒng)一目標是指公司的戰(zhàn)略目標，從上圖可見，戰(zhàn)略目標KPI一定極簡指標，要定北極星指標，一般我們會定三項，戰(zhàn)略目標分解到事業(yè)部，事業(yè)部分解到研發(fā)中心對應(yīng)具體需求，而需求的整個研發(fā)周期已經(jīng)可視化了，可以清楚知道每一個需求、每天做的事情是不是幫助整個集團在完成戰(zhàn)略目標。運行的可視化：系統(tǒng)上線之后可以看到從機房，到整個調(diào)用鏈，到每個架構(gòu)域，再到每個具體的系統(tǒng)；以至系統(tǒng)里面的每個模塊，都能清楚他們的狀態(tài)。管控的可視化： 組件自治，

12、資源彈性調(diào)度；每逢大促尤其是洪峰時候，需要執(zhí)行應(yīng)急預(yù)案，我們就需要知道，執(zhí)行應(yīng)急預(yù)案之后影響的用戶場景，以及各個硬件執(zhí)行過程當中的操作的步驟?？梢暬鲬?zhàn)系統(tǒng)架構(gòu)設(shè)計，這里面除了平時的一些常用的技術(shù)設(shè)計之外，還有三點核心的設(shè)計思想：第1點，對研發(fā)來說，體現(xiàn)在可視化整個研發(fā)生命周期，但是起點與平常不同，平常的起點可能就是一個需求，但這個的起點是戰(zhàn)略。第2點，運行時關(guān)注不穩(wěn)定性的因素，去主動分析、依賴分析和變更感知。分析變更感知的前提，是需要對每個系統(tǒng)做SLA；第3點，為了進行平滑的管控，需要做幾個工作：制定應(yīng)急預(yù)案后進行線下，線上的演練，除了線下測試環(huán)境的演練外，生產(chǎn)環(huán)境也需要實際的演練，比如劃撥

13、一定量的生產(chǎn)用戶，調(diào)度一定量的業(yè)務(wù)場景，也會自動注入一些故障，盡量讓演練流量的結(jié)構(gòu)構(gòu)成接近真實流量，以保證演練的真實性。如果故障沒有經(jīng)過演練，真實發(fā)生是不可控的；故障能否快速恢復(fù)，能否自愈，對用戶來說是不是感到平滑。蘇寧金融集團年交易量已過萬億，日均資金流水幾十億，需要保證每一筆交易資金的安全；對這樣業(yè)務(wù)需求極速變化的高并發(fā)金融資金系統(tǒng)進行重構(gòu)，就猶如對發(fā)射出去的導(dǎo)彈進行二次加速，任何一個小失誤，都可能導(dǎo)致上億的資損，影響上億的用戶體驗；那么在重構(gòu)過程中，如何保證優(yōu)雅就非常重要？首先需要確定我們的目標是什么？基于這個目標我們的困難是什么？解決方案是什么？怎么去實施？怎么去演進？怎么去驗證？基于

14、這個愿景，就要滿足兩點：快和穩(wěn)； 第一個是快：我們需要對業(yè)務(wù)敏捷、快速響應(yīng)業(yè)務(wù)的變化；這個也是研發(fā)中心的核心使命，能對集團業(yè)務(wù)能夠很好的支撐，甚至是驅(qū)動業(yè)務(wù)的發(fā)展；第2個是穩(wěn)，性能要高（20萬TPS、高可用），平時會考核MTTR，出現(xiàn)故障后多久能恢復(fù)，10秒、20秒還是一分鐘？通過這個指標去牽動其它所有的工作的優(yōu)化，避免指標太多，工作沒有重點，不能聚焦；比如定10個指標，每個指標權(quán)重10%，看似面面俱到，其實沒有重點；但是系統(tǒng)指標有很多，有成功率，耗時，異常率，各個硬件的使用率等等，作為負責(zé)人要找到北極星指標；我們的北極星指標就是MTTR；以及這么多系統(tǒng)能否實現(xiàn)彈性治理。基于目標，然后識別關(guān)鍵

15、問題，那我們的關(guān)鍵問題有四類：1、交付速度：基于標準的復(fù)用，并行、分布研發(fā)；2、高可用：需要分析故障點，建設(shè)DB單點/熱點防護、自動化運維、服務(wù)自愈、應(yīng)用級災(zāi)備能力3、可伸縮：從應(yīng)用到IDC、服務(wù)器、網(wǎng)絡(luò)，做到全網(wǎng)伸縮；4、低成本：不僅要節(jié)流，還要開源，重點是公司盈利和控制資損，通過技術(shù)對業(yè)務(wù)驅(qū)動力產(chǎn)生的正向價值，產(chǎn)品運營效果評估，這個也是對團隊負責(zé)人的一個要求：要善于做技術(shù)產(chǎn)品化和技術(shù)品牌的運營；高可用的重點是故障識別與應(yīng)對，即對故障源的實時感知和可視化的治理。故障源來源：按照我們的服務(wù)模型分三方面：提供的服務(wù)、服務(wù)本身、依賴服務(wù)。提供的服務(wù)：故障來源在于請求，比較經(jīng)常出故障的是：重復(fù)請求、

16、并發(fā)請求、超量請求。針對每一個請求我們用不同的策略進行處理。外部服務(wù)：首先檢測通信是否正常，通信正常后服務(wù)是否可用，服務(wù)可用后響應(yīng)是否超時，這些都沒問題后功能契約SLA是否滿足，這樣就形成了一個體系化的處理方法，就不會遺漏，也便于團隊的知識傳承（不論是代碼結(jié)構(gòu)設(shè)計，還是團隊設(shè)計思想的統(tǒng)一，都是比較好的）從PAAS平臺進入到IAAS實現(xiàn)全網(wǎng)可伸縮。對外提供的服務(wù)是吞吐量、單資源存儲量的上限、響應(yīng)時間；內(nèi)部服務(wù)：關(guān)注DB、數(shù)據(jù)庫總連接數(shù)、單數(shù)據(jù)庫每秒事務(wù)數(shù)、慢SQL；依賴服務(wù)：銀行實時清算能力、關(guān)鍵服務(wù)訪問量等；這個是個可伸縮的框架，接下來我們詳講一些關(guān)鍵系統(tǒng)的可伸縮設(shè)計，具體是怎么做到的，交易系

17、統(tǒng)、支付引擎系統(tǒng)和賬務(wù)核心，如何實現(xiàn)可伸縮的。首先是交易系統(tǒng)的設(shè)計，大維度上，將B、C端拆封開，然后進行讀寫分離，再對寫進行分庫分表。這里要特別講一下分庫分表中間件有兩個特別的功能：灰度支持和影子庫表支持?；叶戎С旨从脕韺Σ煌脩?，對不同場景，不同功能進行灰度，影子庫表主要便于生產(chǎn)壓測使用，后面在生產(chǎn)壓測部分會詳講；支付引擎即支付服務(wù)的分庫分表策略，按照用戶維度進行拆分。這里面有個核心設(shè)計，我們設(shè)計了一個邏輯數(shù)據(jù)源，而不是物理數(shù)據(jù)源，便于遷庫，減少DBA的運營成本。賬務(wù)系統(tǒng)可伸縮，難點在于熱點賬戶；熱點賬戶即資金處理頻繁、時間點密集、基于等待的數(shù)據(jù)庫排它鎖的大賬戶；正常情況下，我們開發(fā)人員首先

18、是切入系統(tǒng)進行優(yōu)化，但實際以業(yè)務(wù)為切入點會更好。首先對業(yè)務(wù)場景進行優(yōu)化，實現(xiàn)進出資金隔日，業(yè)務(wù)錯峰，拆分收支賬戶，收款方到賬準時實化，收款方到賬準時實化；接下來才是系統(tǒng)上的優(yōu)化，系統(tǒng)上做到分布式鎖、資金資源池機制、緩沖記賬、并發(fā)控制、異步化；最后是賬戶層面的優(yōu)化，不同賬戶制定不同的策略。比如中間賬戶：只登記賬戶明細流水，不更新余額，日終進行匯總軋差，一次性更新；待清算賬戶：采用單邊記賬方式，待清算賬戶不做余額更新并且不登記賬戶明細流水，待日終進行單邊匯總；特定業(yè)務(wù)收費賬戶：異步分段補賬等，這樣的優(yōu)化才是最有效的，而且擴展性好，后期的維護成本也低；在解決了核心瓶頸點之后，設(shè)計架構(gòu)的演進路線也很重

19、要；因為我們做系統(tǒng)重構(gòu)是不能停業(yè)務(wù)的，就好比飛機在飛行的過程中，進行換引擎的操作；基于以上目標，我們進行架構(gòu)重構(gòu)，就需要注意這三點：1、要與業(yè)務(wù)發(fā)展路線合拍，順勢而為：切忌沉浸在自己的技術(shù)世界里面，因為公司首先是盈利組織，研發(fā)首先要服務(wù)好業(yè)務(wù)，才能驅(qū)動業(yè)務(wù)，才能長遠發(fā)展，阻礙業(yè)務(wù)發(fā)展的研發(fā)團隊和研發(fā)技術(shù)方案是不長久的，特別是對于一個競爭對手激烈的高度發(fā)展的公司；2、專注主線、邊界優(yōu)先，步步為營：就像裝修房子一樣，可以先把墻裝好，但內(nèi)部的每一個房間不一定馬上裝修，因為我們內(nèi)部是可控的，內(nèi)部系統(tǒng)重構(gòu)可以放后，但是要先做提供給邊界系統(tǒng)的接口，這樣既可以很好的控制風(fēng)險，也便于多團隊之間的協(xié)同作戰(zhàn)；3、

20、定期可視化投入產(chǎn)出比：因為金融系統(tǒng)不可能把業(yè)務(wù)停下來，他一定是在業(yè)務(wù)發(fā)展的過程當中，需要實時評估，重構(gòu)和業(yè)務(wù)發(fā)展是否合拍，這樣便于獲得集團的大力支持，減少各方的不理解，減少很多不必要的阻礙，消除部門壁壘，消除決策層的顧慮；實施的過程當中，如何管控項目？項目前：需要消除風(fēng)險，獲得支持，確定項目價值與范圍，明確業(yè)務(wù)影響 ，獲得相關(guān)干系人支持，用架構(gòu)概念驗證原型；項目中：做到短、平、快，嚴格控制項目范圍擴張，Rebase不可避免的業(yè)務(wù)需求；項目發(fā)布時：做到穩(wěn)定，用戶體驗連續(xù)，基于場景的立體化監(jiān)控與報警，比如有時監(jiān)控時我們常發(fā)現(xiàn)單個系統(tǒng)的耗時、成功率等指標都正常，但實際影響了整個調(diào)用鏈，影響了某個場景

21、，所以一定需要基于場景做立體化監(jiān)控。其次，每個核心鏈路上的系統(tǒng)一定要經(jīng)過應(yīng)急預(yù)案的演練。然后，要保持悲觀主義的心態(tài)和終結(jié)者的思維，潛意識里面要假設(shè)重構(gòu)時一定會有問題， 所以一定要守好上線的最后底線，要做到快速回滾和降級。最后是階段性復(fù)盤，聚焦目標，防止做的需求偏離業(yè)務(wù)目標，這一點對于研發(fā)管理者特別重要，通過這些回顧逐漸拿到和業(yè)務(wù)方的平等話語權(quán)；慢慢就會建立起和業(yè)務(wù)的一個很好的溝通渠道；架構(gòu)重構(gòu)后需要驗證合理性，怎么知道我們設(shè)計的架構(gòu)就是滿足我們的預(yù)期呢？主要包括3個方面：1、新老場景的推演：新老場景是否都能支持；2、核心服務(wù)的推演：上下游系統(tǒng)需要演練是否穩(wěn)定 ，3、非功能性的推演：系統(tǒng)是否可隔

22、離、可配置、可監(jiān)控、可回滾、無單點、無狀態(tài)等；主要推演架構(gòu)的高可用、可伸縮、研發(fā)成本，運維成本和遷移成本5個指標，通過這5個指標在上述3個方面的推演，基本上就可以驗證架構(gòu)合理性了，其實做架構(gòu)決策也可以參考這個依據(jù)，比如多個研發(fā)中心，讓你做架構(gòu)決策，這個系統(tǒng)誰做合適？特別是架構(gòu)師怎么讓自己的架構(gòu)決策做到大家都認可，這種思維方式都可以參考；接下來介紹重構(gòu)過程中的一些經(jīng)典案例，便于大家可以在自己的公司里面快速的復(fù)制和集成；第一個：兩周建成立體化監(jiān)控體系：為什么需要監(jiān)控？因為重構(gòu)過程中，隨時有可能出問題，所以需要一個監(jiān)控系統(tǒng)能隨時看到重構(gòu)的鏈路情況。為什么是兩周？因為重構(gòu)對時間其實是有要求的，需要快速

23、完成。如何在兩周之內(nèi)建成一個立體化監(jiān)控體系呢？有幾點：1、指標要極簡2、可視化3、管控全網(wǎng)化（規(guī)則報警、一鍵定位、洪峰控制、業(yè)務(wù)降級），4、統(tǒng)一日志模型，針對重構(gòu)系統(tǒng)的變化，要保證監(jiān)控是準確的，所以需要對服務(wù)模型抽象出三層（服務(wù)的使用者、服務(wù)的提供者、服務(wù)的集成者）打日志，每個服務(wù)的接口都會打digest摘要日志。實現(xiàn)過程中，會請架構(gòu)師或資深的技術(shù)經(jīng)理搭好插件化框架，完成日志模型搭建、異常體系的建設(shè)，領(lǐng)域模型，對輸出結(jié)果的闡釋策略。后面程序開發(fā)時，開發(fā)人員只需要開發(fā)對應(yīng)的插件即可，這樣就將程序的設(shè)計和重構(gòu)變成了工廠的批量化生產(chǎn)，所以這個維度上其實就能減少很多風(fēng)險。做到以上幾點，才能保證重構(gòu)過程

24、比較平穩(wěn)和風(fēng)險可視化。第2個案例，全鏈路壓測：我們的壓測系統(tǒng)經(jīng)歷這么幾個階段：首先是線下壓測階段，這會面臨3個問題：測試環(huán)境和生產(chǎn)環(huán)境配置不一致（比如生產(chǎn)環(huán)境配了10個數(shù)據(jù)庫，而測試環(huán)境只有5個）；測試環(huán)境和生產(chǎn)環(huán)境數(shù)據(jù)結(jié)構(gòu)不一致，（生產(chǎn)環(huán)境有些用戶可能有50個訂單行，而測試環(huán)境基本上為了測試方便，可能只構(gòu)建了1個訂單行）；用戶訪問路徑不一致（比如生產(chǎn)環(huán)境用戶從4級頁到收銀臺有4步，而測試環(huán)境直接從金融App進來1步完成。漏斗不同決定了大促的流量比例不同，比如前面有1萬TPS，經(jīng)過3層漏斗只剩1000TPS如果只有2層漏斗，可能剩下5000TPS，對資源的消耗是不一樣的）第二個階段，我們開始做

25、生產(chǎn)憋單壓測（比如代扣的訂單憋在一起，從收單到支付服務(wù)到銀行，都可以進行壓測，但是對用戶進入收銀臺前面的路徑獲取不到，基于這個缺點），這樣可以實現(xiàn)部分鏈路的生產(chǎn)環(huán)境的真實流量壓測；第三節(jié)階段就是，我們目前正在使用的全鏈路生產(chǎn)壓測，就是把全鏈路串起來；當時我們做的時候，需要解決3個問題：（1）服務(wù)的用戶商戶怎么辦？（2）銀行不配合壓測（3）如何保證支付鏈路系統(tǒng)的配置準確。解決方案是：在易購建立測試商戶和賬戶，配置虛擬銀行，配置影子庫影子表，改造中間件，增加影子庫單號判斷，做到與生產(chǎn)用戶數(shù)據(jù)隔離。在多活這個方面，我們也經(jīng)歷了幾個階段的發(fā)展，初期因為業(yè)務(wù)量小，我們做了一個稻草系統(tǒng)，它是一個最小可用支

26、付系統(tǒng)，只關(guān)注80%主要的銀行和支付工具，即便出問題時，能保證核心鏈路仍可用。這個系統(tǒng)在交易量大肯定是有問題的，下一階段就開始做支付核心鏈路failover，但是仍不能解決機房出問題（如停電問題，網(wǎng)絡(luò)設(shè)備問題等）。所以后來做了多活，要做多活就要解決幾個核心問題：跨機房耗時問題、依賴服務(wù)部署與治理、研發(fā)體系配套改造、故障切換的工具支持。我們的解決方案主要是：1、支付鏈路單元化;2、消息同步服務(wù)化;3、依賴服務(wù)做多活部署;4、研發(fā)體系的配套支持，支持發(fā)布到金絲雀環(huán)境等；5、機房選址，跨機房調(diào)用其實存在很大延遲；6、容災(zāi)能力，支持機房級容災(zāi)，按系統(tǒng)、按鏈路容災(zāi)；從單機房到多機房，在架構(gòu)演進過程中，也

27、要支持容災(zāi)，因為演進過程中要做系統(tǒng)發(fā)布，逐步切流量。比如整體流量先切換白名單用戶，再切換1/256,1/8,1/4，到1/2等，也可以針對單個系統(tǒng)的切換，單個模塊的切換等（包括數(shù)據(jù)源的動態(tài)切換，以及切換過程中，安全等問題），便于在建設(shè)過程中控制風(fēng)險；熱點防護包括3部分：1、發(fā)現(xiàn)熱點，感知熱點源，通過埋點，關(guān)注請求，關(guān)注整個鏈路依賴的資源；2、熱點診斷，主要通過實時分析，離線分析，上下游分析;3、熱點治理，最粗暴的直接限流，這個是有損服務(wù)，是一刀切?？梢陨晕⒃賰?yōu)雅一點，進行故障隔離，比如由于場景1導(dǎo)致的問題，可以直接把場景1切調(diào)，對其它場景沒有影響，這樣可以做到稍微精細化一點；業(yè)務(wù)場景優(yōu)化，比如

28、賬務(wù)核心收支賬戶分離；熱點結(jié)構(gòu)優(yōu)化，比如說我們在收銀臺上有一個活動，只取前1000名滿100減50，其他人沒有資格，其實是通過優(yōu)化緩存結(jié)構(gòu)實現(xiàn)的；熱點拆分，對數(shù)據(jù)庫進行分庫，對數(shù)據(jù)表進行分表， 對記錄進行緩存機制處理?；A(chǔ)服務(wù)包括統(tǒng)一日志，服務(wù)的SLA，決策支持；應(yīng)用工具包括系統(tǒng)級的紫金大盤、產(chǎn)品級的地動儀，這兩個其實是可視化工具，用來觀測治理之后的效果。接下來講從100tps到20萬tps的實踐過程。橫向看，從總體架構(gòu)優(yōu)化到應(yīng)用程序優(yōu)化到數(shù)據(jù)程序優(yōu)化到技術(shù)組件的優(yōu)化；縱向看，深入到每一個架構(gòu)，從收銀臺到收單到支付服務(wù)到渠道到賬務(wù)核心到清結(jié)算進行優(yōu)化。應(yīng)用層看鏈路能否縮短，再看內(nèi)部服務(wù)能否治理

29、，再到線程池調(diào)優(yōu)，去事務(wù)。數(shù)據(jù)層優(yōu)化，需要考慮收益，比如SQL優(yōu)化排第一位，因為比分庫分表的收益來的快。原則是能用單庫盡量用單庫，不能用單庫時，才考慮分庫分表。DB配置參數(shù)優(yōu)化，可以優(yōu)化引擎參數(shù)。因為優(yōu)化過程會產(chǎn)生資源消耗，所以仍然要考慮業(yè)務(wù)目標?；A(chǔ)技術(shù)平臺優(yōu)化，要遵循體系，服務(wù)的本身，依賴方，服務(wù)方。中間是RSF分布式服務(wù)框架（內(nèi)部通過這種服務(wù)來進行路由和調(diào)度。數(shù)據(jù)方面，分庫分表組件和緩存；通信方面，調(diào)度組件）的優(yōu)化。接下來是存儲，如SSD，以前是普通硬盤，那么IOPS會比較低，如果本次優(yōu)化目標是提升2倍，那么只要更換SSD，速度快，成本低，對用戶也沒有損傷。閉環(huán)驗證中心，這個是我們做性能

30、優(yōu)化的一個亮點：特別是重構(gòu)、性能優(yōu)化的時候，需要快速知道結(jié)果是不是我們想要的，下面的服務(wù)日志、調(diào)用日志都是比較通用的。監(jiān)控決策中心：提供灰度方案，移動端應(yīng)急管控。雖然日常有規(guī)則管控，做SLA、流控，但是關(guān)鍵的核心系統(tǒng)出問題（如支付服務(wù)），仍需人工介入確認是否執(zhí)行降級和流控，因為一旦流控，會對用戶產(chǎn)生影響。我們最近也在建設(shè)大促機器人，實現(xiàn)自動巡檢，和智能的治理，這個后面會講到；然后需要驗證大屏，可以直接看到對門店或交易是否有影響。 其實在做系統(tǒng)性能優(yōu)化的時候，也會伴隨研發(fā)組織與研發(fā)過程的“性能優(yōu)化”；這個我有一篇文章業(yè)務(wù)需求極速變化的高并發(fā)金融系統(tǒng)性能優(yōu)化實踐，里面有詳細的分享，主要介紹蘇寧金融對業(yè)務(wù)需求極速變化的高并發(fā)金融系統(tǒng)進行性能優(yōu)化的實踐經(jīng)驗，主要包括：智能監(jiān)控系統(tǒng)，瓶頸點驅(qū)動的性能優(yōu)化，全局規(guī)劃驅(qū)動的性能優(yōu)化以及研發(fā)組織與研發(fā)過程的“性能優(yōu)化”；核心技術(shù)點包括瓶頸點的可視化診斷，瓶頸點治理，熱插拔架構(gòu)設(shè)計，鏈路failover設(shè)計，應(yīng)用N+X設(shè)計，異步化，數(shù)據(jù)庫單點與熱點賬戶防護；也包括從網(wǎng)絡(luò)，中間件，應(yīng)用層，數(shù)據(jù)層，DB的橫向優(yōu)化方案；以及從架構(gòu)，代碼，會話，緩存，線程與隊列，事務(wù)，堆內(nèi)存與GC的縱向優(yōu)化方案，橫縱向結(jié)合的體系化