一种电子商务运费计算的方法和系统.pdf

本发明提供一种电子商务平台运费服务的方法和系统，涉及国际物流计算领域，把运费计算以系统的形式独立存在，并给其它系统以API方式提供服务；服务内部的计算实现高度使用进程内缓存提供执行效率。本发明实现了运费计算的精准精确，以及计算的快捷，保证了工作效率。

权利要求书
1.  一种电子商务平台运费服务的方法，依次包括以下步骤，
结合平台业务，确定平台运费相关系统的边界，将平台运费服务分成两个系统：运费计算系统和运费模板系统；
根据运费计算相关结构模型建立所述运费计算系统的表结构；
运行所述运费计算系统；
将所述运费计算系统计算所得结果以api远程调用的方式给其它系统提供计算服务。

2.  如权利要求1所述的电子商务平台运费服务的方法，其特征在于，在所述步骤A中，所述运费计算系统用于实现各物流公司的标准运费的高效精准计算。

3.  如权利要求1所述的电子商务平台运费服务的方法，其特征在于，在所述步骤A中，所述运费模板系统用于实现把各物流公司组合起来成为所述运费模板，并在所述运费模板中设置用户相关的选项信息。

4.  如权利要求3所述的电子商务平台运费服务的方法，其特征在于，所述选项信息包括送达国家、运费折扣。

5.  如权利要求4所述的电子商务平台运费服务的方法，其特征在于，所述运费计算系统和所述运费模板系统是通过服务化接口的方式提供服务的。

6.  如权利要求1所述的电子商务平台运费服务的方法，其特征在于，在所述步骤C中，所述运费系统的运行依次包括以下步骤，
C1、输入商品体积、商品毛重、商品数量、国家；
C2、筛选可用的运费方式；
C3、判断是否支持快递，如果支持，转到C4，如果支持海运和空运，转到C5；
C4、按平台目前情况运行，进行运费折算后转到C7；
C5、查询支持的港口和承运商，并列出该国家的默认港口；
C6、查询承运商目的港口费用并计算出到港费；
C7、计算保险，组成运费报价明细列表。

7.  如权利要求1所述的电子商务平台运费服务的方法，其特征在于，所述电子商务平台运费服务的方法采用进程内缓存ehcache与nosql的key-value方式的redis缓存。

8.  一种电子商务平台运费服务的系统，其特征在于，该系统包括两个子系统，运费计算系统和运费模板系统。

9.  如权利要求8所述的电子商务平台运费服务的系统，其特征在于，所述系统的运行依次包括以下步骤,
结合平台业务，确定平台运费相关系统的边界，将平台运费服务分成两个系统：运费计算系统和运费模板系统；
根据运费计算相关结构模型建立所述运费计算系统的表结构；
运行所述运费计算系统；
将所述运费计算系统计算所得结果以api远程调用的方式给其它系统提供计算服务。

10.  如权利要求9所述的电子商务平台运费服务的系统，其特征在于，在所述步骤a中，所述运费计算系统用于实现各物流公司的标准运费的高效精准计算。

说明书一种电子商务运费计算的方法和系统
技术领域
本发明涉及国际物流计算领域。
背景技术
国际物流的运输公司的多样性，不同物流公司有不同的定价规则，不同物流公司支持的配送国家不一致。电商平台需要一个高效精准的标准运费系统，该系统可以给其他系统提供运费计算服务。
在申请号为201110191695.2的专利一种网络物流数据处理方法及装置中，虽然提及了接收参数，进行处理的步骤，但是没有完全按照服务化界面的要求，做到完全独立存在。并且采用的算法技术等，不够高效精准。以及在计算的性能上，使用本地化缓存，因为使用了本地化缓存，所以多机器集群且基础数据变动时，不同机器缓存的配置信息可能不一致，导致价格计算结果不一致。
发明内容
国际物流的运输公司的多样性，不同公司有不同的定价规则，不同公司支持的配送国家不一致。根据这些不同点分析这些共性，抽象出一套通用的计算规则，提供对外的物流运费计算；在计算的性能上，高度的使用本地化缓存，提高执行效率，因为使用了本地化缓存，所以多机器集群且基础数据变动时，不同机器缓存的配置信息可能不一致，导致价格计算结果不一致。
针对现有技术这些不足之处，本发明提供一种电子商务平台运费服务的方法，其特征在于，该方法依次包括以下步骤，
A、结合平台业务，确定平台运费相关系统的边界，将平台运费服务分成两个系统：运费计算系统和运费模板系统；
B、根据运费计算相关结构模型建立所述运费计算系统的表结构；
C、运行所述运费计算系统；
D、将所述运费计算系统计算所得结果以api远程调用的方式给其他系统提供计算服务。
优选的是，在所述步骤A中，所述运费计算系统用于实现各物流公司的标准运费的高效精准计算。
上述任一方案中优选的是，在所述步骤A中，所述运费模板系统用于实现把各物流公司组合起来成为所述运费模板，并在所述运费模板中设置用户相关的选项信息。
上述任一方案中优选的是，所述选项信息包括送达国家、运费折扣。
上述任一方案中优选的是，所述运费计算系统和所述运费模板系统是通过服务化界面的方式提供服务的。
上述任一方案中优选的是，在所述步骤C中，所述运费系统的运行依次包括以下步骤，
C1、输入商品体积、商品毛重、商品数量、国家；
C2、筛选可用的运费方式；
C3、判断是否支持快递，如果支持，转到C4，如果支持海运和空运，转到C5；
C4、按平台目前情况运行，进行运费折算后转到C7；
C5、查询支持的港口和承运商，并列出该国家的默认港口；
C6、查询承运商目的港口费用并计算出到港费；
C7、计算保险，组成运费报价明细列表。
上述任一方案中优选的是，所述电子商务平台运费服务的方法采用进程内缓存ehcache与nosql的key-value方式的redis缓存。
本发明还提供一种电子商务平台运费服务的系统，该系统包括两个子系统，运费计算系统和运费模板系统。
上述任一方案中优选的是，所述系统的运行依次包括以下步骤,
a、结合平台业务，确定平台运费相关系统的边界，将平台运费服务分成两个系统：运费计算系统和运费模板系统；
b、根据运费计算相关结构模型建立所述运费计算系统的表结构；
c、运行所述运费计算系统；
d、将所述运费计算系统计算所得结果以api远程调用的方式给其他系统提供计算服务。
上述任一方案中优选的是，在所述步骤a中，所述运费计算系统用于实现各物流公司的标准运费的高效精准计算。
上述任一方案中优选的是，在所述步骤a中，所述运费模板系统用于实现把各物流公司组合起来成为所述运费模板，并在所述运费模板中设置用户相关的选项信息。
上述任一方案中优选的是，所述选项信息包括送达国家、运费折扣。
上述任一方案中优选的是，所述运费计算系统和所述运费模板系统是通过服务化界面的方式提供服务的。
上述任一方案中优选的是，在所述步骤c中，所述运费系统的运行依次包括以下步骤，
c1、输入商品体积、商品毛重、商品数量、国家；
c2、筛选可用的运费方式；
c3、判断是否支持快递，如果支持，转到c4，如果支持海运和空运，转到c5；
c4、按平台目前情况运行，进行运费折算后转到c7；
c5、查询支持的港口和承运商，并列出该国家的默认港口；
c6、查询承运商目的港口费用并计算出到港费；
c7、计算保险，组成运费报价明细列表。
上述任一方案中优选的是，所述电子商务平台运费服务的方法采用进程内缓存ehcache与nosql的key-value方式的redis缓存。
本发明针对国际物流的运输公司的多样性，不同公司有不同的定价规则，不同公司支持的配送国家不一致。根据这些不同点分析这些共性，抽象出一套通用的计算规则，提供对外的物流运费计算；在计算的性能上，高度的使用本地化缓存，提高执行效率，因为使用了本地化缓存，所以多机器集群且基础数据变动时，不同机器缓存的配置信息可能不一致，导致价格计算结果不一致，我们的解决办法是把缓存的key做到可统一配置修改，解决这一问题。
独立的应用专人维护优化，降低维护成本提供执行效率。
附图说明
图1是按照本发明一种电子商务平台运费服务的方法和系统的一实施例的确定运费计算系统边界的示意图；
图2是按照本发明一种电子商务平台运费服务的方法和系统的图1所示实施例的运费计算流程示意图。
具体实施方式
为了更好地理解本发明，下面结合附图具体的说明按照本发明一种电子商务平台运费服务的方法和系统的一个实施例。
本实施例提供一种电子商务平台运费服务的方法，其特征在于，该方法依次包括以下步骤，
E、结合平台业务，确定平台运费相关系统的边界，将平台运费服务分成两个系统：运费计算系统和运费模板系统；
F、根据运费计算相关结构模型建立所述运费计算系统的表结构；
G、运行所述运费计算系统；
H、将所述运费计算系统计算所得结果以api远程调用的方式给其他系统提供计算服务。在所述步骤A中，所述运费计算系统用于实现各物流公司的标准运费的高效精准计算。在所述步骤A中，所述运费模板系统用于实现把各物流公司组合起来成为所述运费模板，并在所述运费模板中设置用户相关的选项信息。所述选项信息包括送达国家、运费折扣。所述运费计算系统和所述运费模板系统是通过服务化界面的方式提供服务的。在所述步骤C中，所述运费系统的运行依次包括以下步骤，
C1、输入商品体积、商品毛重、商品数量、国家；
C2、筛选可用的运费方式；
C3、判断是否支持快递，如果支持，转到C4，如果支持海运和空运，转到C5；
C4、按平台目前情况运行，进行运费折算后转到C7；
C5、查询支持的港口和承运商，并列出该国家的默认港口；
C6、查询承运商目的港口费用并计算出到港费；
C7、计算保险，组成运费报价明细列表。所述电子商务平台运费服务的方法采用进程内缓存ehcache与nosql的key-value方式的redis缓存。
这里还提供一种电子商务平台运费服务的系统，该系统包括两个子系统，运费计算系统和运费模板系统。所述系统的运行依次包括以下步骤,
e、结合平台业务，确定平台运费相关系统的边界，将平台运费服务分成两个系统：运费计算系统和运费模板系统；
f、根据运费计算相关结构模型建立所述运费计算系统的表结构；
g、运行所述运费计算系统；
h、将所述运费计算系统计算所得结果以api远程调用的方式给其他系统提供计算服务。在所述步骤a中，所述运费计算系统用于实现各物流公司的标准运费的高效精准计算。在所述步骤a中，所述运费模板系统用于实现把各物流公司组合起来成为所述运费模板，并在所述运费模板中设置用户相关的选项信息。所述选项信息包括送达国家、运费折扣。所述运费计算系统和所述运费模板系统是通过服务化界面的方式提供服务的。在所述步骤c中，所述运费系统的运行依次包括以下步骤，
c1、输入商品体积、商品毛重、商品数量、国家；
c2、筛选可用的运费方式；
c3、判断是否支持快递，如果支持，转到c4，如果支持海运和空运，转到c5；
c4、按平台目前情况运行，进行运费折算后转到c7；
c5、查询支持的港口和承运商，并列出该国家的默认港口；
c6、查询承运商目的港口费用并计算出到港费；
c7、计算保险，组成运费报价明细列表。所述电子商务平台运费服务的方法采用进程内缓存ehcache与nosql的key-value方式的redis缓存。
本实施例针对国际物流的运输公司的多样性，不同公司有不同的定价规则，不同公司支持的配送国家不一致。根据这些不同点分析这些共性，抽象出一套通用的计算规则，提供对外的物流运费计算；在计算的性能上，高度的使用本地化缓存，提高执行效率，因为使用了本地化缓存，所以多机器集群且基础数据变动时，不同机器缓存的配置信息可能不一致，导致价格计算结果不一致，我们的解决办法是把缓存的key做到可统一配置修改，解决这一问题。
独立的应用专人维护优化，降低维护成本提供执行效率。
如图1—图2所示，图形下面部分以服务化界面的方式提供服务，运费计算的模型，我们增加了运费模板app/标准运费计算app的两个app,给商品系统提供商品的运费计算。
本实施例中提到的进程内缓存ehcache与nosql的key-value方式redis缓存，具体是指    a) Ehcache的缓存使用，把运费计算相关的报价价卡信息同步到ehcache中，并且把缓存的key用我们的统一配置中心进行配置管理（如果需要更正报价价卡时，可以通过统一配置中心把key修改）；价卡信息存在存储器的ehcache中，直接的效果就是计算价格时，不再读取数据库，全部在内存中计算完成，让我们的计算足够高效。
b) key-value的redis缓存，就是把我们平台产品需要的一下产品数据提前进行预计算，存在在reids中。全平台所有在线的产品的一些常用的数据，如：是否免运费、运费的物流周期等等系列数据一次初始化到缓存中；之后平台新上传、修改的产品，则系统以消息队列的方式维护产品的增量逐步同步到，最终把所有产品的这些数据维护到redis中。这些redis内的数据，是经常程序计算好的结果数据，这样调用方可以直接在redis里面直接读取，对批量性能要求高的搜索索引的应用中，效率提高会非常明显，不用redis缓存时，通过远程调用的方式，系统界面计算平均要20毫秒左右，并且批量并发调用并发量也只能是300以内的线程数，且界面的承受能力有限，很快就出现异常（拒绝连接等异常），如果计算的结果存储在redis，直接从redis取数据，可以上千的并发量，且只要9毫秒内就能数据返回，保证了系统的可用与稳定。
Java缓存框架 EhCache EhCache 是一个纯Java的进程内缓存框架，具有快速、精干等特点，是Hibernate中默认的CacheProvider。
主要的特性有：
1. 快速
2. 简单
3. 多种缓存策略
4. 缓存数据有两级：内存和磁盘，因此无需担心容量问题
5. 缓存数据会在虚拟机重启的过程中写入磁盘
6. 可以通过RMI、可插入API等方式进行分布式缓存
7. 具有缓存和缓存管理器的侦听接口
8. 支持多缓存管理器实例，以及一个实例的多个缓存区域
9. 提供Hibernate的缓存实现redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)和zset(有序集合)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。   2 性能怎么样  Redis是一个高性能的key-value内存数据库。官方性能测试结果： set操作每秒110000次，get操作每秒81000次。  3 可不可以存对象  和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)和zset(有序集合)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作。   4 Redis与memcache的最大区别  Replication（树形）  data types（String、Lists、Sorted Sets、Hashes） persistence (snapshot、aof)  很多开发者都认为Redis不可能比Memcached快，Memcached完全基于内存，而Redis具有持久化保存特性，即使是异步的，Redis也不可能比Memcached快。但是测试结果基本是Redis占绝对优势。一直在思考这个原因，目前想到的原因有这几方面。  Libevent。和Memcached不同，Redis并没有选择libevent。Libevent为了迎合通用性造成代码庞大(目前Redis代码还不到libevent的1/3)及牺牲了在特定平台的不少性能。Redis用libevent中两个文件修改实现了自己的epoll event loop(4)。业界不少开发者也建议Redis
使用另外一个libevent高性能替代libev，但是作者还是坚持Redis应该小巧并去依赖的思路。一个印象深刻的细节是编译Redis之前并不需要执行./configure。  CAS问题。CAS是Memcached中比较方便的一种防止竞争修改资源的方法。CAS实现需要为每个cache key设置一个隐藏的cas token，cas相当value版本号，每次set会token需要递增，因此带来CPU和内存的双重开销，虽然这些开销很小，但是到单机10G+ cache以及QPS上万之后这些开销就会给双方相对带来一些细微性能差别(5)。  5单台Redis的存放数据必须比物理内存小 
Redis的数据全部放在内存带来了高速的性能，但是也带来一些不合理之处。比如一个中型网站有100万注册用户，如果这些资料要用Redis来存储，内存的容量必须能够容纳这100万用户。但是业务实际情况是100万用户只有5万活跃用户，1周来访问过1次的也只有15万用户，因此全部100万用户的数据都放在内存有不合理之处，RAM需要为冷数据买单。 这跟操作系统非常相似，操作系统所有应用访问的数据都在内存，但是如果物理内存容纳不下新的数据，操作系统会智能将部分长期没有访问的数据交换到磁盘，为新的应用留出空间。现代操作系统给应用提供的并不是物理内存，而是虚拟内存(Virtual Memory)的概念。 基于相同的考虑，Redis 2.0也增加了VM特性。让Redis数据容量突破了物理内存的限制。并实现了数据冷热分离。
   6 Redis的VM实现是重复造轮子  Redis的VM依照之前的epoll实现思路依旧是自己实现。但是在前面操作系统的介绍提到OS也可以自动帮程序实现冷热数据分离，Redis只需要OS申请一块大内存，OS会自动将热数据放入物理内存，冷数据交换到硬盘，另外一个知名的“理解了现代操作系统”的Varnish就是这样实现，也取得了非常成功的效果。  作者antirez在解释为什么要自己实现VM中提到几个原因(6)。主要OS的VM换入换出是基于Page概念，比如OS VM1个Page是4K, 4K中只要还有一个元素即使只有1个字节被访问，这个页也不会被SWAP, 换入也同样道理，读到一个字节可能会换入4K无用的内存。而Redis自己实现则可以达到控制换入的粒度。另外访问操作系统SWAP内存区域时block进程，也是导致Redis要自己实现VM原因之一。