记得一年前的今天，做过一个接口项目，这几天正好有些事情，修改了一下，顺便谈一谈这个项目吧。
这个项目是一个webservice的接口，原本说好的由接口的提供方来规定传输协议，结果还是用了发送方的xml协议。
第一、链接
由实施人员配好数据库，接口服务的orm并不在启动时链接数据库，而是在收到数据或者查询数据时，建立连接，两个接口同一个服务，但是数据库启用却要分开。
第二、数据模板
由于要对多个数据库相同的数据结构进行保存，由于数据表结构虽然相同，但是相同指标前期业务人员配比随意，导致并不能 直接存入，所以要进行二次转换，要求前台可配置指标，及转换方法。
第三、接口协议
对方接口并非单一接口，而是包括认证接口，数据接口，认证关闭接口，三个接口。
当前实现
第一条-->将接口内容加入数据库信息，讲数据库编号插入表内，在数据发送过来后将带有数据库信息，根据信息生成数据库连接，待数据传输完毕后关闭连接。
第二条-->将发送接口和接受接口分开，发送是使用发送模板转换，接受时使用接受模板接受，对数据进行处理后保证字段一直，再存入数据库中。
第三条-->对于请求认证，拿到认证信息，传输每一条数据，待数据传输完毕后关闭认证即可。规划实现当前实现并不严谨，有很多问题，由于当时技术栈并不成熟，也有很多弯路，所以如果再次实现
第一条-->接口内加入数据库信息，数据传入时，生成数据库链接，然后动态读出数据库字段，生成临时的数据库映射，讲映射的文件放入缓存，待数据传输完毕后，关闭连接，但是缓存文件，避免性能损耗。
第二条-->模板弃用数据库表作为对照，使用json 格式，直观且维护性比较好，将模板文件存入数据库，随时生成或者更换，耦合性讲更低。
第三条-->
1、认证是个典型的上下文管理，使用python的with 关键字进行管理，不过也可以传入 装饰器来进行上下文的切换，使代码更简洁，保持可读性。
2、维护几个队列的发送，将符合条件的数据直接插入队列，保证单条发送无重复，无遗漏，也可记录当前状态。
总结：
虽然上线半年多了，但仍旧有很多问题没有解决，当前定时任务是每次都会查询数据，而不是放到未发送的数据表中，对方服务器超时问题，三个接口都有可能超时，还好做了详细的发送，接收记录，其实并不喜欢这种数据库直接注入，前几天系统就出现消息队列阻塞，不过是那个cs端出现问题，接口程序并没有受到影响，但是停止接口服务后，cs端就正常工作，应该是接口程序释放了链接cs导致。
由于工作流程比较复杂，导致发送效率比较低，一分钟大概10条左右。不过这也能阻塞对方服务器，也是服了，可能对方服务器有其他并发吧。
====================================2016-12-09日修改========================================
最近对于记录数据库做了统一入库，做了发送数据池，避免了读写数据库的冲突导致数据库死锁，发送数据池，避免数据重复发送。
同样配置了logging 模块，继续收集更多日志。