大家晚上好，今天我們分享的主題主要有四個部分
整個重構過程的總結
系統面臨的痛點
架構演進之路
重構的收益
第一部分：系統面臨的痛點
我們系統重構之前面臨的痛點主要分為兩類
系統的問題
研發的問題
1.1 系統問題：
（1）沒有通用封包的抽象
沒有形成統一的封包收發模式
沒有基于封包收發建構通用的路由引擎
（2）缺乏基本網關平台
缺乏平台化建設
不能形成統一的配置和監控管理模式
新管道成本高、速度慢
運維維護及支援的投入和成本高昂
（3）非功能性需求考慮不足
監控的有效性和報警的及時性不足；
降級能力和災備能力建設不足；
1.2 研發問題
需要精通數十種基礎技術産品的運用
潛在地，需要與多個系統打交道
對開發人員技能要求高
大量的溝通與協作
并行研發能力受到限制
第二部分：架構演進之路
此過程主要分為三部走。
明确系統定位
确定目标架構
明确建設思路，制訂建設步驟
2.1 系統定位
（1）統一的封包與通信中心
基于封包抽象，實作通用的封包收發
快速的統一的管道端口接入
網關層的通用基礎平台，提高重用性和可靠性
（2）統一的配置管理和監控
根據交易類型，可靈活配置封包收發路由
提供統一的集中的接入管道管理和監控
（3）網關的可配置化接入
通過增加封包類型和配置路由規則，實作網關的快速接入
降低網關接入的改造量
2.2 目标架構
老架構：由管道網關進行統一封裝内外部支付工具；
新架構：
總體思路：強核心，标準化，易管控；
支付核心是易付寶各支付工具（含銀行卡）資金處理能力的抽象，提供依托于支付工具資料模型的統一的支付類資金處理服務；
将内外部支付工具分離；
由支付核心統一協調處理；
基于插件式的設計思想，重新進行了架構設計；
基于開-閉原則(ocp)設計元件；
每一個元件（業務元件,資料元件，基礎計算資源）具備最大可能的自我完備性，做到可監控、可配置與禁用，具備确定的sla，并與其它元件之間以松散耦合的方式進行協作。當依賴的元件不存在或者無法正常提供服務時，能夠以良好的方式降級，且在故障解除後自動恢複。
基于目标架構和新系統定位，要解決的主要問題包括以下四類：
管道規劃，支付引擎建設，支付分流，清分路由；
2.3.1 建設思路
在目标架構和建設思路都明确後，我們基于此制定了具體的建設步驟。
首先是面向服務的業務模組化步驟
我們系統總體架構是soa架構，我們采用“面向服務的模組化方式”，對于核心領域，采用領域模組化實作；
① 得到所設計業務系統的業務服務邊界(一組業務服務集)，以及這組業務服務與其他業務角色(客戶與合作夥伴)之間的關系
②得到資金流、以及業務流與資金流的關系
上圖中
虛資金流：資金在支付平台虛拟賬戶體系中的流轉，展現為賬戶中的餘額變動。
實資金流：資金在現實世界中的流轉，展現為客戶與銀行賬戶中餘額變動，或者現金的轉移。
虛實資金流之間存在關聯關系。
③ 将所設計的業務系統分解為一組業務功能域，并描述各個業務功能域的業務職責
金融交換網關：配置化接入，無釋出上線，靈活應對銀行變更
④描述各個業務功能域之間如何通過動态協作實作前面講的主業務服務。
⑤描述每個業務功能域的業務服務邊界與業務資料邊界
領域模型是領域知識的系統描述；
對領域進行簡化，抓住主題，忽略細節與無關内容；
最終形成一個場景：我是誰，我依賴于誰，我服務于誰，解決了哪些核心問題域；以及相關的限制；
⑥在業務層面進行變更分析。逐一分析對本業務涉及到的相關業務流程與公共業務關注點的影響，給出這些現有業務的配合改造點。
⑦給出業務層面的異常，并針對各種異常異常情況下的業務處理方式(如業務差錯處理，反向業務流程等)。凡無法通過技術手段完全避免的異常，均應在業務層面設計與之對應的業務處理方式。
在業務模型建立完畢後，将進行系統設計
具體包括四個環節：
應用設計
資料設計
技術設計
非功能性設計
應用設計遵循以下步驟
其中主機闆内容為
① 代碼分層結構(dal,service,integration要獨立)，日志，異常，攔截器監控；
② 代碼骨架(抽象類中提供模版方法，通過流程來組織鈎子方法)；
③ 前置校驗模版搭建；
④ 後置處理示例搭建；
而外部服務設計包括
① 統一的權限管理：通過authenticationfilter，在filter層進行控制；
② 建立标準化業務服務模型：每個業務都按照業務主題單據和詳情單據進行設計;每個服務處理都由校驗前置，業務服務，後置校驗構成；
③ 标準化業務服務目錄，通過抽象，聚合成标準的服務接口(簽約、支付、查詢、退款、擷取網銀連結)與擴充接口
④ 标準化接入控制：将安全控制，合法性預檢，格式轉換，接入日志記錄；統一提取為公共util
内部服務設計
① 統一業務服務路由，多管道業務服務統一推送(通過ssf接收支付服務通知，由路由元件進行統一排程，根據業務類型分發到簽約、支付等應用子產品)
② 内部服務實作通過spring的application.xml配置檔案進行統一管控；
③ 擴充卡子產品主要由業務模型和管道路由構成，兩者由路由規則關聯，組裝業務模型，然後根據路由規則調用相應的路由管道進行處理；
④ 内部服務的可配置化接入：通過增加服務類型和配置路由規則，實作服務子產品(支付、退款)快速接入；
接口設計：
資料設計有以下過程
多級流控政策：
1.系統垂直多級：從入口->内部各個服務->每個外圍合作銀行；
2.每層的多級流控值：從壓測極限安全水位值->上年雙11峰值流控->平時峰值->…………
通過彈性管控平台自動實作，不用人工幹預；
其中日志模型和服務模型對應；
要考慮到分析型解決方案和曆史型解決方案
第三部分：重構的收益
總結
今天的分享到此為止，感謝大家的支援，如果有不足之處，請指出。同時，也很期待和大家交流經驗。
分享者簡介：
黃駿宇，支付線技術專家，穩定性小組核心成員，深耕金融支付領域多年，全程參與蘇甯易付寶從1.0到2.0的架構更新，對系統性能優化和大促保障有多年的實戰經驗。現專注于金融支付網關的重構優化。
本文轉載自微信公衆号 中生代技術 freshmantechnology