从前一篇文章说起，讲了什么是支付，什么是支付系统，以及支付系统与外界沟通的公共平台。本篇文章将继续说明支付系统，将更多的细节部分说明清楚，以及支付系统的一些必须处理的常规问题，以及一些常见的困难。
针对支付系统，始终存在这样的一些东西，他与外界选择与那个平台进行沟通没有关系，只与行内的业务存在关系，同时这些东西是只关心账务的，而不关心依靠外部系统的所必须满足的逻辑。所以将支付系统，分为两部分，一部分作为与外界进行沟通所必须进行的逻辑，第二部分作为一家银行所必须完成的内部逻辑。
首先说说外部的逻辑，一家银行，要完成线上的或者线下的，与其他机构或者机构进行资金上的往来，或者说是支付，那么必须就要经过一个公有的一个平台系统，比如央行的大小额，网银互联平台，通过这个平台，银行将要进行来往的资金数据发往其他银行的机构，中间平台起着监管和控制的作用，而所有的银行和机构都必须接入央行的清算系统（规定），所以所有的关于如何进行支付交易的通信，都是由央行做出规定和说明，这里也可以看出，外部系统要做的，就是对接人行的借口，对定义好的借口和相关规则进行实现，这里面的细节主要包括，xml报文的接收和解析，数据入库，业务逻辑，进行账务处理或者其他信息处理，返回人行信息，行内业务处理。主要技术难点在于，支付系统属于大流量的系统，同时安全级别比较高，数据要保证绝对的正确，所以，要处理流量问题，数据库操作极限，以及交易处理极限。举个例子，为了迎接双十一期间，网上支付的流量高峰，在双十一之前，就针对支付系统进行压力测试，对相关的交易流程进行了极大的优化，同时也优化了我们的afe报文拼接和报文解析系统，这次的主要问题，也主要是因为我们的交易很快就处理完成了，但却是在接受人行信息和返回人行信息的处理中，占用了大量的时间，我们刚开始的做法是提升线程数，强制提升cpu的使用率，在cpu提到百分之30左右后，再对验签系统进行了优化，通过乐观预测验签成功，不等人行返回便开始组装报文，等接收到人行返回成功，便立即返回数据，同时关闭了部分的日志功能。这些大概就是支付系统可能会遇到的高并发的问题。
然后就是数据安全和正确性的问题，数据安全，主要由数据仓库负责。
数据正确性往往涉及的是，业务逻辑的问题，由于支付系统的业务都比较复杂，是整个银行资金流动的接口，所以支付系统涉及多个系统的业务逻辑，包括贷记卡（信用卡之类的贷款形式的卡），以及手机银行，柜面系统，企业网银，电子银行，其他特色系统，不同的系统进行的现金交易，如果要发往其他行，就必须走支付系统，所以支付系统同时需要对接其他系统的接口，同时要根据人行的接口规范和逻辑将其他系统接收到的业务发送到人行。而这之间的各个系统的信息的检查，以及业务逻辑的实现，都不能有漏洞，也不能出错，一旦出错或者有漏洞，就可能导致客户的账户金额的错误，所以支付系统的对业务熟悉度要求是非常高的，必须熟悉人行的接口，同时要熟悉一些账务处理的各种规定，不能把不该记的账记了，漏的帐给漏了。
内部系统的主要职责，内部系统主要是进行信息维护和保证数据正确的，内部系统主要包括账务的处理，在交易进行中，支付业务必然会往核心做账务处理，其中包括，记账，挂帐，抹帐，对账。每个操作的都是直接会改变客户在其账户上所能看到的金额数，所以账务操作是绝对要保证正确的，各种账务状态的相互转换，账务操作的处理时间，以及日终对账，日间对账都是为了再一次确认账务的正确性，而且这些操作的数据量一般都比较大，对数据库的io要求也比较高，对账操作一般是在业务量比较小的日终状态进行。其他账务操作则要求事务，如果数据库或者流程失败，则要返回失败信息，同时做事务处理。
行内支付系统，或则说是不对外的系统，还包括一些信息维护，比如银行内部的机构状态的维护，机构的维护，以及节假日维护等。
太复杂了，得花些心思来慢慢理解和背背。。。
