mongodb在跨境电子商务物流供应链系统中的应用

本文介绍了从单一应用向面向服务的分布式系统架构过渡过程中所面临的挑战和实现方法。它包括基于mongodb的建模和数据持久化的具体实践。

我们公司的重资产是人。我们了解跨境电子商务物流，包括跨境电子商务通关环节、**物流法律以及出境产品的相关信息，这些都是我们公司宝贵的资源。

我们公司有大量长期合作的供应商，这是我们的优势。我们的困难是这些供应商无法控制，因为我们在使用其他供应商的服务。

所以除了订单系统，还有一个非常重要的资产，那就是我们自己的海外仓储，这也是我们的核心价值。

以上是我们的全球物流网络。这些仓库又大又小。英国仓库是我们的核心仓库。截至2017年，我们在中国有8个仓储中心，主要集中在深圳、广州和上海。

我们的平台推荐亚马逊、eBay、wish、阿里**、shopee、aliexpress和lazada作为我们的物流服务提供商。

我们以前的系统是上图左边的架构。它针对的是企业的第三方ERP和一些企业自己开发的一套系统。还有一些平台可以与我们的系统直接交互。其中一些是通过一组由export easy提供的UI访问的，并且有大量的在线发货。我们将使用API来访问它们。我们有管理背景在后台和一个单独的WMS系统。

我们认为这个系统有点太大了，想做些调整。大多数新的体系结构仍然没有改变，只有后端的管理系统希望朝着面向服务的体系结构的方向发展。基于业务场景的划分分为两部分：一部分是基于用户认证和授权等通用服务，另一部分是日志。

有一些支付网关，并与贝宝，支付宝，付款人和银行的接口。

以下是我们业务的主要模块，包括产品报价、客户关系管理系统、订单、物流网络和运输，包括WMS、付款、物流跟踪、供应商管理系统、结算报告等。

单一应用：前端和后端系统共享一组webapp解决方案。

单数据库：采用MSSqlServer数据库，核心业务功能共享一个数据库。

业务功能完整性：it系统随着业务的发展而扩展新的功能。满足跨境电子商务物流业务基本的功能需求。

易于测试和部署：使用单一解决方案，系统依赖性更低。一旦部署，所有功能都可以测试。

不灵活：对应用程序的任何细微更改都需要重新构建和重新部署整个应用程序。

妨碍持续交付：系统规模大，建设部署时间较长，不利于频繁部署，阻碍持续交付。

受技术栈的限制：包括开发语言、开发工具、数据库一旦选定，就不能根据实际需要做出其他选择。

技术责任：系统逻辑极其复杂。随着时间的推移，人员变动和技术责任不断累积。

面向服务：根据业务模块划分不同的系统模块，系统模块采用面向服务的架构。服务和服务通过清晰的接口定义进行通信。

领域驱动设计：每个业务模块团队负责与领域或业务功能相关的所有开发。核心域是根据DDD中明确定义的规则实现的。

独立部署、升级、扩展和替换：每个服务可以单独部署和透级，而不影响整个系统。

异构/多语言：每个服务开发团队可以选择熟悉开发语言、数据库、开发工具和开发架构。

身份验证：每个服务都需要统一的登录验证。

身份验证：不同用户使用同一服务模块需要身份验证。

单点登录页面包括基于OAuth2API的访问。DDD是一种逻辑体系结构，包括应用层和领域层。域层包括域模型、实体子对象、域服务、域事件和查询规范。

基于仓库，要存储订单，必须连接实体和子对象以存储并将其刷新到数据库。

当我们做应用程序时，我们更喜欢完成业务，所以我们选择了mangodb。我们有一套自己的建筑。在封装过程中，我们将mangodb做一层封装。

上图中的面向方面架构包括练习、加载和缓存等方面。

上图是TMS系统中调拨订单汇总根的示意图，包括物流轨迹的采集、预计到达时间等信息，以及这些调拨订单的节点信息。

一、非交易紧张。误差数据容忍度相对较高。

二、团队成员有mongodb开发经验。对基于mongodb的建模中要考虑的必要冗余有一些了解。

三、基于mongodb的高读写性能，门户模块解决了高并行发送系统的卡死问题。

四、TMS系统模型之间的关系是复杂的。如果使用传统的关系数据库，将添加一堆表。使用mongodb，复杂的模型可以通过doucment存储在一起。

不能在集合之间联接。特别注意造型。建议增加必要的冗余，减少二次查询。

仅支持单文档级事务处理。当出现数据一致性错误时，应考虑必要的数据监控和数据修复功能。

聚合查询需要通过mongodb聚合管道进行查询。mongoodbc?驱动程序提供了很好的支持，但与LINQ查询相比仍然比较繁琐。

1、 仓库

仓储于整个聚合根的操作，提供聚合根的持久性和重构或查询。

2、 存储库上下文

负责交易处理。每个聚合根的仓库都与同一个仓库上下文相关联。但是mongodb不支持事务。我们提供了一个虚拟实现。仓库上下文应用工作单元模式。

1、 采用Poco（POJO）作为领域模型

简单CLR对象（简单Java对象）不会继承持久性框架中的任何基类，也不会实现持久性框架中的任何接口。域层没有引用mongodb类库。mongodb仓库层使用lambdaexpression实现类的映射。

2、 ID生成器

有多种ID生成器可供选择。guidgeGenerator、OjbectIdGenerator、StringOjbectIdGenerator等。我们总是使用字符串类型作为ID。所以直接使用mongodb的stringobjectidgenerator。

3、 多态类图

如果将多态类（继承）映射到mongodb，则需要指定已知类型。

4、 一些需要理解的约定

Namedidmemberconvention可以指定类的哪些属性可以用作id。

Ignoreextraelementsconvention可以忽略文档中类中不存在的字段，否则将引发异常。

Enumrepresentationconvention可以指定枚举序列化方法。我们都指定了bsontype.string。

1、 聚合框架

此框架首先过滤文档，即过滤出符合条件的文档；其次转换文档，即更改文档的输出形式。其他包括按指定字段分组和排序。

它实际上是MapReduce的替代品，但比MapReduce简单。

该框架使用声明性管道符号来支持类似于SQL中groupby操作的函数。您不需要编写自己的自定义JavaScript。

2、 管道操作员

$project：数据投影，主要用于重命名、添加、删除字段。

$match：过滤操作，过滤符合条件的文档作为下一阶段的输入。

限制：限制通过管道的文档数。

$skip：从要操作的集合的开头跳过的文档数。

$unwind：将数组元素拆分为独立的字段。

$group:组数据。

$sort：根据指定字段对文档进行排序。

$geonear:将返回一些坐标值，这些值按从近到远到指定点的距离排序。这在地理信息系统中常用。

对于大多数聚合操作，聚合管道提供了良好的性能和一致的接口。

它很容易使用。与MapReduce一样，它也可以在分片集上工作。

输出结果只能保存在一个文档中，但受b文档大小限制（当前为16m）的限制。

对于一些简单的固定数据，管道对数据类型和结果大小有一些限制。

管道可用于聚合操作，但MapReduce仍用于一些复杂的大型数据集聚合任务。