【资损】系统迭代过程中的兼容性设计
作者简介：小明java问道之路，专注于研究 Java/ Liunx内核/ C++及汇编/计算机底层原理/源码，就职于大型金融公司后端高级工程师，擅长交易领域的高安全/可用/并发/性能的架构设计与演进、系统优化与稳定性建设。
热衷分享，喜欢原创~ 关注我会给你带来一些不一样的认知和成长。
InfoQ签约作者、CSDN专家博主/后端领域优质创作者/内容合伙人、阿里云专家/签约博主、51CTO专家
如果此文还不错的话，还请关注、点赞、收藏三连支持一下博主~
本文目录
本文导读
一、 资损防控系统设计资损防控规范
二、兼容性设计随业务的不断变更和发展
1、数据库、接口服务新增的向前兼容性原则
2、数据库、接口服务变更的向后兼容性原则
2.1 删除字段
2.2 新增字段
2.3 变更字段约束
2.4 变更字段名称
2.5 变更字段类型
2.6 数据库索引变更的时候要考虑对产线执行计划的影响
三、数据库、接口服务删除原则
四、注意文件字段、缓存对象，消息对象
五、生产系统发布过程中兼容性考量
1、系统和数据之间的兼容性
2、系统和业务处理之间的兼容性
3、新老系统间的兼容性
4、兼容性分析
4.1 组合考量业务的处理
4.2 组合考量新旧系统兼容性的处理
4.3 组合考量新旧系统与新旧数据的兼容性处理
六、生产系统发布过程中，要考虑消息调度的兼容性
七、业务迁移过程的兼容处理
八、数据和数据存储的迁移
九、采用开关的方式规避风险
总结
本文导读
系统兼容性设计随业务的不断变更和发展、系统和架构也在不断的调整和优化这其中既有新业务、新系统的上线，也有老业务、老系统、老数据的迁移。在这些新老的变化过程中，我们既不能导致业务的间断影响可用率，更不能产生资损造成公司损失。
为了防范这些新旧间处理的风险，我们需要从数据、系统、发布、业务等各个环节做好兼容性设计。
一、 资损防控系统设计资损防控规范
从系统架构层面整体来看，支付公司的系统可以抽象为如下结构:
一、对外部商户提供收单服务类的系统
二、连通支付公司与各金融渠道的网关类系统
三、支付公司的内部业务处理系统
四、消息、调度等中间件系统
五、数据库、缓存等存储平台
从系统架构与业务架构上来讲，各个结构连接的地方最容易出现资损。因此我们将从接口服务层面与系统设计层面对资损进行分析并总结相关规范。
二、兼容性设计随业务的不断变更和发展
系统兼容性设计随业务的不断变更和发展、系统和架构也在不断的调整和优化这其中既有新业务、新系统的上线，也有老业务、老系统、老数据的迁移。在这些新老的变化过程中，我们既不能导致业务的间断影响可用率，更不能产生资损造成公司损失。
为了防范这些新旧间处理的风险，我们需要从数据、系统、发布、业务等各个环节做好兼容性设计。
1、数据库、接口服务新增的向前兼容性原则
数据库、接口服务新增的向前兼容性原则，向前兼容设计更多的体现在数据库、接口的初始化设计阶段（新增数据库结构、新增接口）。
数据库结构与服务接口在设计过程中，在数据库、接口复杂度与字段（个数、长度等）允许的范围内，尽可能的考虑到未来可以预见的情况，支持未来的业务拓展。
新增设计时，需要考虑到：
1、数据库字段、接口字段的合理冗余。比如在设计交易接口的时候，除了考虑交易金额字段，考虑未来有收费的场景，可以增加手续费金额字段。此时，也要注意避免过度设计。
2、数据库字段，接口字段长度的适度放大与类型的泛化。比如在允许的范围内，可以将交易金额字段设计的范围长度大一些某些类型字段定义为字符串类型而非整数类型；时间参数精度设计到毫秒等。
3、数据库字段、接口字段或接口处理逻辑的约束。考虑到未来有可能扩展或放松现有约束（如非空判断等），在接口中考虚默认、异常等多种处理情况。
2、数据库、接口服务变更的向后兼容性原则
数据库、接口服务变更的向后兼容性原则，向后兼容设计是最常见的应用场景，更多的提现在数据库，接口的变更阶段（变更数据库结构、接口）。
服务提供方在做接口非破坏性的变更时，需要确保服务以向后兼容的模式演变：
在无需变更现有消费者的实现或配置的条件下被更多的消费者重用。由于我们发布过程是DB先发布，所以新老系统是会同时使用一个数据库结构的。因此必须保证数据库结构发生变化的时候，新旧系统可以同时使用变更后的数据库结构。
一般数据库、接口变更，分为如下场景：
2.1 删除字段
1、禁止直接删除正在使用的字段。
2、对于接口字段，如果确认该字段所有的请求方和服务方都不再使用。分多个版本，按照请求方先去掉该字段，确认所有请求方完成后，服务方方可以进行字段的删除。
3、对于数据库字段，老系统要先解除和数据库结构间的字段依赖（包括语法依赖和业务依赖）再进行删除。对于已经产生的数据，要考虑保存机制。
2.2 新增字段
1、服务提供方需要考虑各服务请求方的兼容性。服务提供方对该字段的约束允许为空，接口处理可以以提供默认值等方法保证逻辑处理兼容性。
2、数据库结构新增字段的时候，需要保证系统与数据库结构的语法与业务兼容。数据库字段可空。
3、服务请求方在升级新增字段的时候，根据服务提供方该新增字段是否已经上线、制定兼容性方案。
2.3 变更字段约束
1、禁止直接进行字段约束从严的变更。接口进行从严变更（如长度收缩）的时候，需要各服务请求方先检视请求方约束是否符合条件；
不符合条件的。先完成请求方的变更后续进行服务方的升级。数据库进行从严变更的时候，要保证老数据符合规范系统先完成约束控制后进行变更。
2、字段约束放松的变更。接口按照服务提供方先进行约束放松，后续版本各请求方进行变更；请求方不能早于服务方进行变更。
2.4 变更字段名称
1、禁止直接变更正在使用的字段名称。尤其是对于为多个服务请求方提供服务的接口的字段。
2、当需要变更接口字段名称的时候，按照新增字段、删除字段的流程来处理变更。
2.5 变更字段类型
1、禁止直接变更正在使用的字段类型。
2、如果需要变更类型的时候，建议新增字段来解决。
2.6 数据库索引变更的时候要考虑对产线执行计划的影响
数据库索引变更的时候要考虑对产线执行计划的影响
三、数据库、接口服务删除原则
1、禁止直接删除正在被使用的数据库结构和接口服务
2、如果需要进行删除。接口按照服务请求方先变更，在确认已无服务请求方请求接口的前提下服务提供方才可以进行接口删除。数据库结构需要保证系统不会再放我的情况下，并做好数据的保存。
四、注意文件字段、缓存对象，消息对象
对于文件字段、缓存对象，消息对象的使用和设计，也需要遵从数据库与接口服务相关的兼容性设计原则，保证向前向后的兼容设计。
五、生产系统发布过程中兼容性考量
生产系统发布过程中兼容性考量，发布过程中，要从系统、数据、业务组合考虑兼容性
1、系统和数据之间的兼容性
需要考虑系统和数据之间的兼容性，设计过程中要保证新老系统产生的过程数据可以相互处理，即老系统产生的中间数据，系统发布后，新系统可以出来；
新系统产生的数据，系统一旦出问题回滚后，老系统也可以处理。如果不能处理的时候，不能选用直接的war包回滚方案。可以通过中间兼容版本保证回滚的兼容性、也可以通过数据订正，保证新系统产生的数据部会被老系统处理（数据订正方案是紧急情况下的处理方案，不建议采用）；
另外也可以通过引流等方式解决这部分数据问题，以保证其兼容性。
2、系统和业务处理之间的兼容性
需要考虑系统和业务处理之间的兼容性生产系统发布过程中，在老系统受理的业务，新系统可以继续处理（如老系统落单、新系统继续支付、老系统正交易逻辑、新系统反交易逻辑），并且要保证业务规则业务流程的兼容处理。
3、新老系统间的兼容性
新老系统间的兼容性，避免幂等击穿、并发失效等问题对于新系统的功能变更、幕等机制、并发控制机制等只可以增加，不可以减少，避免老系统未能控制的幂等、并发，新系统也可以控制住。
如果是相关机制变更的话要重，控制只可以从严不可以从松、控制字段、控制场景、控制业务要考虑新旧系统兼容的情况。
4、兼容性分析
兼容性分析过程中，不可以孤立看新旧业务、新旧系统、新旧数据的处理，需要组合考量。
4.1 组合考量业务的处理
业务处理的各个场景和过程中都会有被新war包老war包处理的两种情况。要通过分析业务各个场景和过程中在新旧war包中的处理步骤和流程，判新他们之间在业务上是否有依赖关系，并分析在组合的业务场景下是否可以被正确处理。
比如，订单交易平台修改了支付的冲销逻辑、业务兼容性需要做如下分析：
对于一笔支付业务，有支付和冲销两种场景、支付场景、冲销场景被老系统如何处理、被新系统如何处理？支付和冲销有没有依存关系？老系统的支付是不是必须被老系统冲销？老系统支付新系统冲销可以不可以被支持？新系统支付老系统冲销可不可以被支持？
如果冲销服务有查询状态冲销发起两个过程，还需要考虑着两个过程和各个业务场景组合的情况。
4.2 组合考量新旧系统兼容性的处理
系统的多种处理和控制机制是分多个阶段的，每个阶段也都会有被新war包老war包处理的两种情况。通过分析者每个阶段在新war包和老war包中不同处理以及控制的目的、逻辑、方式直至字段代码，判断其相互之间有无依赖，每个阶段在什么场号下可以成为下个阶段的前置，并分析其在组合场景下可否互相处理完成功能。
比如，某个系统对幕等控制进行优化。需要分析该系统处理的任务有任务抓取、处理等阶段，老war包怎么进行任务抓取？怎么进行任务处理，幂等控制的？新war包是怎么处理的？抓取的任务是做完幂等控制才能被处理？还是抓取后流入到处理进行幂等控制？新war包抓取的任务老war包能不能处理？
如果除了处理阶段流程变化，还有处理逻辑变化，还需要进一步考虑并发、幕等控制的字段及实现代码在各个组合场景下的兼容性。
4.3 组合考量新旧系统与新旧数据的兼容性处理
发布过程中存在新系统写数据、老系统写数据、新系统读老系统写的数据、新系统读新系统写的数据、老系统读老系统写的数据，老系统读新系统写的数据供六种场景。
要分析以上各个场景的读写是否正确，读写之后的业务处理方式是否正确，是否会对小一步业务处理产生不兼容的影响？
比如一个业务改造走挂内部帐逻辑的改造。要考虑新系统的时候写数据会记录挂账单编号，老系统写数据没有挂账单编号，新系统读老系统没有挂账单编号的业务数据怎么处理？
六、生产系统发布过程中，要考虑消息调度的兼容性
生产系统发布过程中，要考虑消息调度的兼容性，按照前述的处理原则，发布的时候还需要避免消息处理、调度的不兼容处理。
其他处理方案（不建议）：当有消息不兼容的时候，需要告知部署同学按分组下线消息源头生产者，当有调度不兼容的时候，部署的时候可以暂信调度。
七、业务迁移过程的兼容处理
业务迁移过程中、涉及到新旧业务流程、新旧业务规则、新旧业务数据等的兼容处理，需要从分析、设计、上线、验证等各个环节把控。
1、对于业务移，必须详细分析所迁移业务的新旧规则、流程、参数并和上下游系统确认。
2、新老业务与新老系统之间必须能够业务处理流程和规则上保证平滑处理、无缝切换。
3、尽可能保证新老业务、系统、数据直接的交叉处理。不能保证的时候，要通过相关表示避免交叉。
4、业务移的风险较大，需要通过开关、引流等进行产线验证。
5、迁移过程中，要有完整的报警、核对等跟踪机制，保证及时发现问题；有完整的开关等流控机制，保证有问题的时候可以及时断流。
八、数据和数据存储的迁移
数据和数据存储的迁移。涉及到系统的底层环节（数据），要分析不同数据结构、不同数据存储之间的差异，保证这些差异口以被系统正常接受处理。
1、数据迁移（如CCDC数据迁移、会员数据迁移）前后，要保证业务系统能正常识别和处理。不能保证的话，要考虑停机迁移。
2、数据存储迁移，尤其是不同存储之间的迁移，要考虑其之间的差异（如oracle和pg的差异、redis和hippo的差异，尤美是者seauence相关的差异更应该注意，这些都和资损率切相关。
3、迁移过程中，要有完整的报警、核对等跟踪机制，保证及时发现问题。
4、数据是系统的底层环节，迁移的时候一定要有完备的回退机制。
九、采用开关的方式规避风险
风险较大的系统发布与业务迁移，采用开关的方式规避风险，保证业务的兼容运行。
总结
我们的系统和数据一定是不断迭代和更新的，变更往往存在诸多风险，bug/资损也往往在系统迭代过程中产生，做好兼容性控制至关重要！