ESB与服务网格：

ESB通过将行内各个系统封装为渠道和服务方，而其中系统之间的数据交换和调用封装为服务，
ESB就是负责服务注册、交易发现、服务治理。
而在服务网格是将之前需要在ESB中需要开发的交易统一进行下沉，转变为基础设施架构，
通过在控制面的配置信息来控制各个系统的路由信息，进而管理各个系统之间的交易。

ESB 日志优化：

基于原有的旧版本和开发方式不变的情况下，在修改部分架构下将原有的日志由文本输出改为了将日志输出到队列中，
由单独的一个小程序依赖redis和业务逻辑(多步骤)对日志进行整合和优化，最后就变成现有的结构化日志方式。
队列使用的是activemq的topic模式，多生产者写入单一消费者消费。
业务逻辑主要在于在交易进入系统时会获得一个全局ID，这个全局ID跟随交易流转，在每次将日志输出到队列时，
传入提前预设的流程标志、日志内容和该ID。在日志处理模块中从队列中逐个获取生产者输出的日志，放入到redis 的set中。
最后通过redis 内部set 结构的模型，由ID 获取到全部的日志内容和流程标志进行结构优化然后统一输出到不同的日志文件中。

支付：

客户点击支付按钮发起订单支付，用户微信端携带支付信息到达后端服务器，后端根据携带的渠道支付信息进行字符渠道选择，
然后组装对应的订单信息去到三方支付平台同时添加一条30分钟后查询支付结果的定时任务。
三方支付平台返回一个url，后端将url返回到用户微信端，用户微信端调用该url，三方支付平台收到请求，发起对微信支付的请求，
微信支付收到请求调起微信的收银界面，用户输入密码，支付成功后，微信支付将支付结果返回到三方支付平台。
而三方支付平台在收到结果后调用后端上送的订单信息中的结果通知url，
后端服务器随后处理订单的支付结果信息并通知商户微信端该笔订单的支付情况。

对账:

1、下载支付平台昨日的对账文件。
2、处理支付平台的对账文件，并存入到临时支付平台对账表中。
3、筛选昨日关于该渠道的支付订单到渠道支付订单临时表中。
4、以渠道订单支付表为基础坐关联查询，判断对应的订单信息是否一致。
5、将对账信息一致的结果进行存储。
6、收集不一致信息，存入到待处理对账表中，待人工处理。

清分:

1、获取前一天的对账结果信息。生成一份原始清分数据。
2、根据商户的清分数据计算对应的各种费率。
3、根据计算费率进行分润。
4、根据配置的结算信息进行计算。

8583协议

8583协议，是一个国际标准的报文格式，最多由128个域组成，每个域都有统一的规定，分别有定长和变长之分。
上送的报文格式主要包含TPDU、报文头和报文域。其中TPDU长度十个字节，报文头长度十二个字节(主要包含终端状态、软件版本号等信息)，报文域主要包含信息类型域、位图域、报文数据域。另外报文最开始的地方还有一个包含所有报文的长度。