某物流公司总部和营业务之间数据上传入库需求理解

摘录的要求：

 

1. 某物流公司，需要一套中间交易系统。有1000多个营业部，在一个月的某几天几种访问服务器，把单据数据录入；录入的数据要求实时保存到总部的数据库里。营业部不能直接访问总部的数据库；
2. 营业部的客户端和前置系统打交道，再由前置机和服务器交互，数据入库；前置机是一个物理的概念，逻辑上可以是一个中间层；
3. 前置机和中间层，中间层和服务器之间的交互可以考虑：web service，web， ICE， 其他二进制协议；
4.响应时间和并发能力：客户端操作的响应时间，几百个甚至上千个客户端一起访问，并发能力；
5. 前置机和数据库之间的事务采用事务中间件完成；

      我的理解和思路：先考虑基础架构，列举可能的选择，然后排除不适合的选择，再从中选择合适的。客户端的硬件是PC Server，前置机可能比PC Server略好，中间是广域网线路。客户端和前置机之间可能的选择是web service，直接web app，ICE或者其他二进制协议。客户端可能已经有应用，只是需要新的接口，所以wep app不是很合适，排除；ICE的线程模型是Leader/Follows，底层使用select，不适合大量连接的情形，其他二进制协议需要从头考虑服务器的编程。从简化实现的角度，采用web service是比较合适的选择。

      性能问题：广域网的数据传输本身是一个问题，这个问题和web service封装（soap xml解析的时间）处理相比，是不是可以忽略（需要测试验证，最好有数据支撑）；采用web service的情况下，性能的扩展可以采用web 服务器的扩展来实现。这样解决了客户端和前置机之间的交互，但是前置机和服务器之间的交互还有问题。每秒要达到1500个事务对数据库是要求很高的，在需求中又要求数据实时入库，如果没有这个要求，可以选择写文件，再入库的方式。内存数据库用于读的情形是很好，但是对于写，只是拉长的战线，没有根本解决问题。
      接口问题：可以向客户端提供web service的接口封装，这种封装在各种语言之下都有成熟的库。 前置机和服务器之间采用事务中间件，也没有什么好说的。
      结论：疑问还是在数据入库的时候，能否提供1500个左右的并发写。这个对数据库的设计提出了较高的要求。回忆从前接触过TonkLink的消息中间件，银行各个储蓄网点和计算中心之间的前置机采用TonkLink消息中间件，前置机和数据库服务器之间是TonEasy事务中间件。一个地市级的计算中心连大概几十个储蓄所。储蓄所的业务也没有太多的并发。所以现在看起来还不是很复杂的。