银行的架构演进在第九阶段：属于分层和分割服务于需求的阶段!大部分要做的维护需求与改造老旧的系统!其底层使用的是python，前端使用的是awt的java系统!
银行系统遵循了基本的架构演进，但是其代码的目的是为了维护系统的稳定与账务的安全，并不在于追求技术，因此其开发多用到的技术的原理实现与适应市场的账务解决方案，而非先进的技术方案!
银行系统：
系统结构：柜面(前端)+中间业务(逻辑处理)+核心(数据库管理金钱)
通讯：总行与分行/其他行内系统/核心之间的沟通通过网关(报文转译)，总行与外部商务子公司的沟通通过 web外联前置！
对于银行来说柜面，中间业务，核心，网关都是组成每个系统的一部分，同时也是各自独立的系统!柜面系统维护了柜员的身份系统，权限，现金箱，key盾等;中间业务系统维护了每个系统从柜面发起请求后的逻辑处理和判断，通过中间业务系统的处理将数据或者请求目标化与核心进行沟通；而核心系统做的是关于银行账务(凡涉及到钱的)的数据处理；网关系统负责中间业务与其他各系统之家的沟通，相当于翻译机；
由于银行业务众多，每种类型的业务可以针对其客户需要开发成一个子系统，当每增加一个项目系统，柜面系统，中间业务，核心同时也需要维护相关的子系统模块!
因此银行的架构也可以看成是一个箭靶，每个部分都是一个靶环。核心是作为整个系统的靶心，中件业务毗邻核心作为内环，内环之外则是柜面系统，而柜面系统之外则是外联商务圈，外联商务圈之外则是许许多多的商务公司!柜面到中间业务到核心之间的环通过网关进行连接，与外联圈等商务公司的则通过外联前置连接!每个环都是由许许多多的系统组成!
环与环之间可能存在着管理数据信息负责信息整理的ECIF系统，或者负责负责数据抽取的数据仓库系统！
==========================================================================================
涉及到技术开发的要求:
1-------数据库必须携带账务设置，因此大多系统使用的db2，携带with ur的事务控制
2-------异常即终止，因为对于账务的高度严谨，要求一但出现问题，系统要即刻马上报错
3-------在对外接触的时候，必须是入口有校验，出门有核查!
4-------大量使用if-else的逻辑判断语句，以保证分支的处理
5-------每一个操作都必须涉及到成功失败异常的处理!
6-------关于记录的维护，必须做重复的判断
7-------时间的校验，必须精确
8-------金额存入数据库是以元转化分的形式处理的
==========================================================================================
批量代收付系统：
批量代收付是银行的一个非常重要的业务，其系统也非常庞大，主要业务分为本行卡，借记卡，信用卡，他行卡!业务分成代收业务和代付业务!
其流程是:客户在规模进行签约协议并选择业务类型。确认完业务类型后，客户提供文件给柜员，柜员拿到文件后，上传系统并解密，解密完成后完成后，完成一系列的校验以及合法性检查，然后生成文件，上送给核心，核心根据业务类型处理完成后，同样以文件的形式返回给文件服务器,项目监控的文件服务器有自己的文件，那么对文件进行解析，并将核心处理的结果更新到数据库，前台展示给柜员看！
客户信息表：记录客户与银行签约的信息，该表只维护了客户的相关信息，如币种或者是否是否对公对私等信息!并不维护业务类型
业务信息表:客户与银行签订合约后，需要订立银行提供给客户的业务类型，比如代收代付，银联代付等!
客户信息与业务类型信息历史表*2:两张表分别记录对客户信息和业务类型的操作!
注意：为了保护系统的稳定，客户信息的纯净，每份客户信息都有一个合约日期，到期会自动解约！合约的删除也是采用虚拟删除的操作!并且当合约没有业务类型的时候会自动解约。因此需要些一个Schedule的shell调度脚本!用于定时调度
在客户提供的批量文件需要利用加解密工具进行加密后给到柜员，柜员上传到系统，这个时候系统会进行文件解密并根据客户选择的合约类型的格式和字段信息，进行判断！如果成功则在系统中维护一条交易记录，并将文件的明细给维护到系统中!
秘钥表 : select * from batch.batch_kdcinfo where sysid='001099' and UNITNO='99992200'
批次表 ：select * from batch.batch_appbatchinfo where appbatchno='2017091500023252' with ur
明细表 ： select * from batch.batch_transdtl where appbatchno='2017091500023252' with ur
到了这一步，客户的信息也维护到数据库中，批次表与批次明细通过批次号进行维护，并没有设置内外键，基本的业务逻辑都是在逻辑代码上实现!
系统对于每个合法性的检查，如账号是否有效，账号和用户名是否准确都是有一个个单独的模块组成的!当有需要在选择调用!因此，对于不同的业务类型都有不同的校验方式，我们系统也维护了一套校验的规则，通过读取合法性校验的流程和步骤一步步地进行实现!
select * from batch.batch_flowcfg as a1 left join batch.BATCH_STEPINFO as a2 on a1.stepid=a2.stepid left join batch.BATCH_STEPMODECFG as a3 on a1.stepid=a3.stepid left join batch.BATCH_FUNCTION as a4 on a3.funcid=a4.funcid where flowMode ='1111000004'
批次文件上传后处理的步骤:
--->批量文件预检查--->批次初始化--->批量文件入库--->批次重整--->批次账户信息校验 --->批量文件合法性检查--->批次网点提交---->批次网点复核---->分行提交批次过账处理
==========================================================================================
注意:使用模块组装的方式，既使得模块的方法可以被其他系统使用，也大大提高了系统的灵活性，甚至实现断点续跑功能!
当合法性校验通过了之后则通过提交通过网关发送给核心，这个过程中，我们同样会在本地系统中维护一张表，将合法的记录给生成文件提交到核心，这张表则维护了文件的路径和系统标志，核心返回的结果和批次号以及核心处理的批次号!