苏宁金融集团年交易量已过万亿，日均资金流水几十亿，需要保证每一笔交易资金的安全；对这样业务需求极速变化的高并发金融资金系统进行重构，就犹如对发射出去的导弹进行二次加速，任何一个小失误，都可能导致上亿的资损，影响上亿的用户体验；那么在重构过程中，如何保证优雅就非常重要？首先需要确定我们的目标是什么？基于这个目标我们的困难是什么？解决方案是什么？怎么去实施？怎么去演进？怎么去验证？
基于这个愿景，就要满足两点：快和稳； 第一个是快：我们需要对业务敏捷、快速响应业务的变化；这个也是研发中心的核心使命，能对集团业务能够很好的支撑，甚至是驱动业务的发展；第2个是稳，性能要高（20万TPS、高可用），平时会考核MTTR，出现故障后多久能恢复，10秒、20秒还是一分钟？通过这个指标去牵动其它所有的工作的优化，避免指标太多，工作没有重点，不能聚焦；比如定10个指标，每个指标权重10%，看似面面俱到，其实没有重点；但是系统指标有很多，有成功率，耗时，异常率，各个硬件的使用率等等，作为负责人要找到北极星指标；我们的北极星指标就是MTTR；以及这么多系统能否实现弹性治理。
基于目标，然后识别关键问题，那我们的关键问题有四类：
1、交付速度：基于标准的复用，并行、分布研发；2、高可用：需要分析故障点，建设DB单点/热点防护、自动化运维、服务自愈、应用级灾备能力3、可伸缩：从应用到IDC、服务器、网络，做到全网伸缩；4、低成本：不仅要节流，还要开源，重点是公司盈利和控制资损，通过技术对业务驱动力产生的正向价值，产品运营效果评估，这个也是对团队负责人的一个要求：要善于做技术产品化和技术品牌的运营；
高可用的重点是故障识别与应对，即对故障源的实时感知和可视化的治理。故障源来源：按照我们的服务模型分三方面：提供的服务、服务本身、依赖服务。提供的服务：故障来源在于请求，比较经常出故障的是：重复请求、并发请求、超量请求。针对每一个请求我们用不同的策略进行处理。外部服务：首先检测通信是否正常，通信正常后服务是否可用，服务可用后响应是否超时，这些都没问题后功能契约SLA是否满足，这样就形成了一个体系化的处理方法，就不会遗漏，也便于团队的知识传承（不论是代码结构设计，还是团队设计思想的统一，都是比较好的）
对外提供的服务是吞吐量、单资源存储量的上限、响应时间；内部服务：关注DB、数据库总连接数、单数据库每秒事务数、慢SQL；依赖服务：银行实时清算能力、关键服务访问量等；这个是个可伸缩的框架，接下来我们详讲一些关键系统的可伸缩设计，具体是怎么做到的，交易系统、支付引擎系统和账务核心，如何实现可伸缩的。
首先是交易系统的设计，大维度上，将B、C端拆封开，然后进行读写分离，再对写进行分库分表。这里要特别讲一下分库分表中间件有两个特别的功能：灰度支持和影子库表支持。灰度支持即用来对不同用户，对不同场景，不同功能进行灰度，影子库表主要便于生产压测使用，后面在生产压测部分会详讲；
支付引擎即支付服务的分库分表策略，按照用户维度进行拆分。这里面有个核心设计，我们设计了一个逻辑数据源，而不是物理数据源，便于迁库，减少DBA的运营成本。
