上一期我们讲到支付系统架构中最为关键的对账的问题，这个问题是较为关键的，和钱打交道，在任何公司，都跑不掉财务部门。 那财务部门会关注哪些内容？ 当然，最重要的是账务信息。 所有的交易都要记账，按要求公司都需要定期做审计，每一笔帐都不能出错。这当然不能等到审计的时候再去核对，而是每天都需要对账，确保所有的交易支出相抵，也就是所说的把账给平了。 这就有三种情况：电商系统和商家对账；电商系统和支付系统对账；支付系统和支付收单机构对账。作为支付系统，我们仅关注后两者的情况。
从软件开发角度， 还有一些非功能性需求需要实现：
性能： 特别是秒杀的时候，如何满足高频率的支付需求？
可靠性：不用说，系统能达到几个9，是衡量软件设计功力的重要指标。 99%是基础， 99.999%是目标，更多的9哪就是神了。
易用性：支付中多一个步骤，就会流失至少2%的用户。 产品经理都在削尖脑袋想想怎么让用户赶紧掏钱。
可扩展性： 近年来支付业务创新产品多，一元购、红包、打赏等，还有各种的支付场景。 怎么能够快速满足产品经理的需求，尽快上线来抢占市场，可扩展性对支付系统设计也是一个挑战。
可伸缩性：为了支持公司业务，搞一些促销活动是必须的。 那促销带来的爆发流量，最佳应对方法就是加机器了。 平时流量低，用不了那么多机器，该释放的就释放掉了， 给公司省点钱。
整体上来说， 从分层的角度，支付系统和普通的业务系统并没有本质的区别，也是应用、服务、接口、引擎、存储等分层。 在应用层，支付系统一般会提供如下子系统：
1、支付应用和产品.(应用层)： 这是针对各端（PC Web端、android、IOS)的应用和产品。 为各个业务系统提供收银台支持，同时支付作为一个独立的模块，可以提供诸如银行卡管理、理财、零钱、虚拟币管理、交易记录查阅、卡券等功能；
2、支付运营系统(应用层)： 支付系统从安全的角度来说，有一个重要的要求是，懂代码的不碰线上，管运营的不碰代码。这对运营系统的要求就很高，要求基本上所有线上的问题，都可以通过运营系统来解决。
3、支付BI系统(应用层): 支付中产生大量的数据，对这些数据进行分析， 有助于公司老板们了解运营状况，进行决策支持。
4、风控系统(应用层)：这是合规要求的风险控制、反洗钱合规等。
5、信用信息管理系统(应用层)：用来支持对信用算法做配置，对用户的信用信息做管理。
其他各层功能：
1、支付服务层：为上述各端系统提供API。这些API也可以提供给业务系统直接使用。
2、接口层：和各相关系统对接的接口，其中最重要的是和支付渠道对接的支付网关。
3、引擎层： 包括统计分析、风控、反洗钱、信用评估等在后台运行的各个系统。
4、存储层： 各种持久化的数据库支持。
这其实也是普通互联网应用系统架构，没有什么特别之处。比如微服务如何体现，如何满足性能需求等，在这个视图中无法体现出来。这只是个软件角度的高层视图，后续还需要对各个主要模块进行分解，从分解视图中可以知道如何满足非功能性需求。
