大家晚上好，今天我们分享的主题主要有四个部分
- 整个重构过程的总结
- 系统面临的痛点
- 架构演进之路
- 重构的收益
第一部分：系统面临的痛点
我们系统重构之前面临的痛点主要分为两类
- 系统的问题
- 研发的问题
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
