一、业务系统设计概述
1、什么是业务系统
互联网公司常常将产品方向分为两类，C端和B端，C端主要是面向客户和消费者的系统，B端的范围则相对模糊，给供应商或商家使用的系统，给内部业务人员使用的系统，都统称为B端系统。C端和B端系统建设的出发点和侧重点完全不同。C端系统偏重用户体验，强调感性，持续的数据分析优化，同一个按钮不同的摆放位置都要精心设计、论证，服务对象是个人；B端系统偏重流程、模块化，强调抽象和结构性，讲究整体的规划和体系设计，服务对象是组织和机构。
如果将B端系统进一步拆分，也可以分为两类，第一类是商家端，常见于双边模式的平台型互联网公司，例如淘宝的卖家管理系统，美团的商家管理后台；第二类是内部业务系统，支持企业经营、管理、业务运转。
- 常见的业务系统包括ERP（EnterpriseResource Planning），CRM（CustomerRelationship Management），SCM（Supply ChainManagement），WMS（WarehouseManagement System），TMS（TransportationManagement System），OA（Office Automation），HRM（Human ResourceManagement）等等。
- 从软件学的角度来看，所有软件系统分为两类，第一类是能够实时产生业务数据的系统，叫做OLTP（Online TransactionProcessing）系统，第二类是对数据进行加工、处理、探查、挖掘、展现的系统，叫做OLAP（Online AnalyticalProcessing）系统
总体来讲，业务系统对企业具有四点价值：提升管控能力、控制经营风险、降低运营成本、提升销售业绩。
2、设计业务系统重要性
针对不同企业强调的业务重点不一样，那么系统的业务的定制化特定化就是非常重要的。
3、如何设计一套业务系统
一般来讲，一套业务系统从0到1的构建，需要经历如下环节。
（1）业务方案设计
PM和业务负责人一起梳理、制定业务流程、制度、机制，理解业务的问题点，并确定软件系统解决方案。
（2）系统整体方案设计
PM结合业务诉求与目标，完成系统概要设计，包括界定业务、系统的边界，系统功能的抽象和演进蓝图，整体应用架构的设计，如何与公司已有系统拼接、交互。
（3）系统细节方案设计
PM完成细节方案的所有设计，包括建模、角色、界面、权限等。其中建模是最难的部分，建模好坏决定了系统未来的灵活性、可扩展性。建模要求对业务的全面理解，极强的抽象归纳能力。
（4）实施验收
PM对最终项目落地负责，系统上线后要展开持续的迭代优化，深度参与产品运营，数据分析等。
如果是从无到有设计系统，以上环节必须全面贯彻，尤其是架构设计和模型设计，是重中之重。
以上内容参考来源：
http://www.woshipm.com/pd/586436.html
https://36kr.com/p/5105245
四、数据对账系统
我们要设计的属于业务系统中的重点内容：数据对账，数据对账一般应用于支付系统，资金系统双方保持一致是非常重要的。而对于其他系统对于交互核心数据也是非常重要的，所以在这里我们需要从架构方面去设计一个高可用的数据对账系统。
什么是资金对账？
- 在会计上的概念：指为了保证账簿记录的正确性而进行的有关账项的核对工作，做到账证相符、账账相符、账实相符。
- 在支付机构的概念：资金对账，在对账中心进行，将系统保存的账务流水与银行返回的清算流水和清算文件进行对账，核对系统账务数据与银行清算数据的一致性，保证支付机构各备付金银行账户每日的预计发生额与实际发生额一致。即核对银行实际清算资金如充值、充退、提现等业务的银行处理结果是否一致。
对账中心的作用？
- 是主要处理对账的系统模块，主要业务是清算对账。对账中心部署于工作平台，分别接受会计系统和清算系统的数据输入进行对账处理。
- 对账中心最主要的职责是勾兑银行清算流水与支付系统入账流水，用以检查反映银存实际账户的余额变化与支付系统内部户余额变化是否平衡。对于已经核对无误的银行清算流水和支付系统入账流水，分别进入相应的历史银行流水库和历史入账流水库。
- 对于勾兑结果中银行清算流水多于系统入账流水的，而操作人员不明确资金的来源，需要根据所设定的分类规则将暂不明确的资金进行挂账处理。而后我们认为该部分资金已经系统入账，可以入历史流水库。
- 因为此时的银存实际账户的余额增加，与之对应的是支付系统内部户余额也增加了，比如： T 日的挂账可能会在 T+N 日后进行销账确认，而后续的销账行为是对明细流水的业务分流处理，我们不应将 T+N 日的销账所产生的账务流水作为入账流水，不再需要到对账中心体现。
现在从支付到引申类比其他数据对账系统(参考资料)
其他参考资料关于支付系统：资料1，资料2根据现有我们的系统进行系统之间的数据对账，以下为重点内容，由于有时候公司没有那么多财力和人力提供支持，所有的role都需要研发一个人来解决，所以这里我的角色是从业务方，PM,产品经理，架构师，研发，测试方面去一一解决。
（1）业务方案设计
业务背景（业务调研）：联合营销项目主要围绕大促活动跨店铺，跨自营/商家，打标，优惠券，单品促销，大促盘货等活动的创建和收品，以当前的打标活动收品量1个亿的数据，同步给下游促销系统或者促销收品量上亿的数据同步给下游系统，这个过程中数据量大，持续时间周期长，就不得不需要保证双方系统之间的数据幂等性。之前出现过因为网络抖动，以及没有兜底数据造成的数据丢失和未同步给下游系统情况。
业务方案:目前业务核心系统处理逻辑方案-》同步下游数据，同步成功实时更新本系统数据状态，并插入日志表一条同步数据，失败数据会同步至ES。由于分布式系统，事务比较复杂，目前依赖于异常和MQ重试机制，容易出现的结果，垃圾数据和数据不一致未能及时发现并做出有效方案解决。考虑目前的情况需要进行数据对账，独立扩展于辅助核心系统的数据稳定性，并实现脱离现有业务核心系统。
（2）系统整体方案设计
- 对账内容和数据来源
- 对账内容：主要是本系统和下游系统的sku商品数据是否一致。
- 数据来源：本系统数据库表调用下游系统发送数据，
本系统调用下游系统实时返回数据。
- 对账业务流程
- 对账中心主要功能
Tips:
- 1、入账接收：
联合营销核心业务系统收品SKU信息发送MQ(redo)–》数据对账系统监听消费–》存储jimdb- 2、数据存储：
- jimdb（redis）存储作为清算池，核对diff入账和出账数据，并校验。
- 弹性数据库JED（MySQL）,作为校验后的结果流水对账日志存储
- 3、出账接收：
联合营销核心业务系统实时调用促销系统返回结果信息发送MQ(done)–》数据对账系统监听消费–》存储jimdb- 4、数据清算：联合营销活动分三类触发清算事件
- 日常清算：日常大促收品并按照规则进行同步，时间充足。活动开始前24h进行清算事件触发。
- 限时清算：主要应对收品量小于千万，时间限制8h左右的情况。活动开始前5h进行清算事件触发。
- 紧急清算：主要应对收品量具大但是由于管理员忘记或者其他原因未能提前发布，品量大于千万级别。活动开始前12h进行清算事件触发。
- 5、异常预警：
数据对账系统进行清算入账数据和出账数据，对比结果不一致，异常预警邮件和短信通知研发，并进入审核节点。对比结果一致，接入数据存储，作为流水日志存储。- 6、审核流水：
研发收到报警，进入审核节点根据活动和异常sku信息定位数据不一致原因，根据预警和人工介入排查信息定位是否需要同步业务方和产品，或者从新跑数据调用同步促销系统。- 7、数据展示：
根据流水日志存储，进行数据展示界面，提供数据分析给产品和研发更好的保障系统数据的安全性。
- 对账流程图
- 对账中心功能模块分析
- Q1:
清算策略执行，异常预警，人工审核，重新跑数据时间周期多久？是否有足够的时间可控范围内
A1:
目前需要预估数据，根据jimdb运维反馈，单个key的数据比对不要超过5000，如果2亿数据，需要比对40w次，性能时间未能预估，需要压测执行参考性能。
- Q2:
数据对账系统的可用性
A2:
设计初衷，数据对账不止同步sku数据，其他所有系统交互都可以接入数据对账系统，数据对账系统只关心入账和出账比对结果，脱离核心业务系统逻辑，属于扩展系统。
- Q3:
数据对账系统的数据安全性
A3:
数据对账系统的数据安全性主要依赖于jimdb，通过rdb快照和aof日志恢复数据，但是不能保证100%数据恢复。
- 意外数据恢复逻辑
- 5.1. 意外数据恢复逻辑
参考上述数据对账系统的数据安全性。- 5.2. 对帐及异常恢复逻辑
通过人工审核，重新跑数据或者及时根据当时情况作出应急措施预案。
（3）系统细节方案设计
3.1）项目简化初步排期
3.2）建立资料共享文件夹GitHub或者SVN（持续交付和资料共享）：
（4）实施验收
