基于微服务的物资服务管控方法、系统及存储介质与流程

1.本发明涉及信息网络技术领域，特别涉及基于微服务的物资服务管控方法、系统及存储介质。


背景技术：

2.物资是社会生活中维持各项活动的重要基础，物资迅速、安全、准确地配送和运输至目的地是物资保障的必要条件。目前，有各种用于解决商品购买与售出的b2b（btb,business-to-business，企业对企业之间的电子商务模式）、b2c（btc,business-to-customer，企业对消费者的电子商务模式）等线上平台，需求方通过这些线上平台能够轻松便捷地完成物资的采购。然而，市面上的线上平台存在如下问题：（1）架构多为整体式架构，需要多台应用服务器、数据库服务器和网络附属存储文件服务器进行管理，如果其中一个组件出现故障，可能导致整个应用程序无法运行，处理总体服务故障的难度大；（2）架构中设置有多个服务，这些服务需要部署在同一个虚拟机或系统亦或者应用服务器中，服务中的每个组件服务开发、部署、运营和扩展的难度大；（3）在面临大量物资采购时，由于平台系统的功能和所提供的服务较传统，鲜少设置有仓储应用、供应商服务等应用或服务，采购方并不能通过平台系统得知仓储情况，无法提供更多物资的相关信息，增加了物资采购的困难，降低了用户的体验感。
3.针对需求方对物资采购的要求以及目前线上平台所存在的问题，需要提供一种保证稳定运行、提供更多物资的相关信息、降低物资采购的难度的物资服务管控方案。


技术实现要素：

4.本技术的实施例提供了基于微服务的物资服务管控方法、系统及存储介质，通过物资服务请求调用多个针对物资采购需求的应用和微服务，降低物资采购的难度。
5.本发明解决其技术问题的解决方案是：第一方面，本技术实施例提供基于微服务的物资服务管控方法，包括以下步骤：通过前端向网关层发起对应的物资服务请求，所述物资服务请求用于调用服务层的业务微服务；根据所述物资服务请求，所述网关层向应用层中与所述物资服务请求对应的应用发送第一调用请求；根据所述第一调用请求，所述应用层向所述服务层中与所述第一调用请求对应的业务微服务发起第二调用请求；根据所述第二调用请求，所述服务层向所述前端提供与所述第二调用请求对应的业务微服务，所述业务微服务包括商品服务、交易服务、供应商服务、支付服务或物流服务中的至少一种；在所述服务层向所述前端提供与所述第二调用请求对应的业务微服务时，通过存
储层调用与所述业务微服务对应的数据采集模型和数据分析模型，通过所述数据采集模型向所述服务层的业务微服务提供数据存储和数据调出的服务，并通过所述数据分析模型向所述服务层的业务微服务提供数据分析的服务；其中，所述商品服务用于搜索物资信息，对物资信息进行分类并展示；所述交易服务用于提交与所述物资信息对应的购买订单信息并查看、修改和维护所述购买订单信息；所述供应商服务用于获取储备数量不足的物资信息，采集并展示与储备数量不足的物资信息对应的供应商信息；所述支付服务用于提供与所述购买订单信息相对应的支付方式，并展示所述购买订单信息及其流水；所述物流服务用于展示与所述购买订单信息相对应的物流信息。
6.第二方面，本技术实施例提供基于微服务的物资服务管控系统，包括：前端，与网关层相关联，用于向网关层发起对应的物资服务请求，所述物资服务请求用于向服务层调用对应的业务微服务；网关层，与所述前端和应用层相关联，用于接收来自所述前端的物资服务请求，并向应用层中与所述物资服务请求对应的应用发送第一调用请求；应用层，通过中间层与服务层相关联并与所述网关层相关联，包括多个应用，每一个应用均向服务层中与所述第一调用请求对应的服务发起第二调用请求；服务层，通过中间层与所述应用层相关联并与存储层相关联，包括多个微服务，用于根据所述第二调用请求，提供与所述第二调用请求相对应的业务微服务；其中，所述业务微服务包括商品服务、交易服务、供应商服务、支付服务或物流服务中的至少一种；存储层，与所述服务层相关联，包括数据采集模型和数据分析模型，用于调用与所述业务微服务对应的数据采集模型和数据分析模型，通过所述数据采集模型向所述服务层的业务微服务提供数据存储和数据调出的服务，并通过所述数据分析模型向所述服务层的业务微服务数据分析的服务；其中，所述商品服务用于搜索物资信息，对物资信息进行分类并展示；所述交易服务用于提交与所述物资信息对应的购买订单信息并查看、修改和维护所述购买订单信息；所述供应商服务用于获取储备数量不足的物资信息，采集并展示与储备数量不足的物资信息对应的供应商信息；所述支付服务用于提供与所述购买订单信息相对应的支付方式，并展示所述购买订单信息及其流水；所述物流服务用于展示与所述购买订单信息相对应的物流信息。
7.第三方面，本技术实施例提供存储介质，其中存储有处理器可执行的指令，所述处理器可执行的指令在由处理器执行时用于执行所述的物资服务管控方法。
8.本技术实施例至少包括以下有益效果：提供基于微服务的物资服务管控方法、系统及存储介质，方法包括：通过前端向网关层发起对应的物资服务请求，物资服务请求用于调用服务层的业务微服务；根据物资服务请求，网关层向应用层中与物资服务请求对应的
应用发送第一调用请求；根据第一调用请求，应用层向服务层中与第一调用请求对应的业务微服务发起第二调用请求；根据第二调用请求，服务层向前端提供与第二调用请求对应的业务微服务，业务微服务包括商品服务、交易服务、供应商服务、支付服务或物流服务中的至少一种；通过存储层调用与业务微服务对应的数据采集模型和数据分析模型，通过数据采集模型向服务层的业务微服务提供数据存储和数据调出的服务，并通过数据分析模型向服务层的业务微服务提供数据分析的服务。本发明通过前端发送物资服务请求至网关层以调用对应的业务微服务，通过网关层发送第一调用请求至应用层以调用对应的应用，并通过应用层向服务层发送第二调用请求，实现对应的业务微服务的调用，进而实现物资采购需求的满足。本技术提供的方法能够使得服务层的多个微服务和应用层的应用完整、有序地运行，降低在调用微服务和应用时的数据运算量；并且，本技术通过调用针对需求方物资采购需求的应用和服务，在面对大量物资采购的情况时，通过供应商服务调取短缺物资对应的供应商信息，以保证物资商品能够满足需求方的需求，降低了物资采购的难度，提高了需求方的采购体验。
9.本技术的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本技术而了解。本技术的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。
附图说明
10.附图用来提供对本技术技术方案的进一步理解，并且构成说明书的一部分，与本技术的实施例一起用于解释本技术的技术方案，并不构成对本技术技术方案的限制。
11.图1为本技术实施例提供的物资服务管控方法的流程示意图；图2为本技术实施例提供的物资服务管控系统的结构示意图；图3为本技术实施例提供的物资服务管控系统的中间层的结构示意图；图4为本技术实施例提供的数据采集模型的结构示意图；图5为本技术实施例提供的数据分析模型的结构示意图。
具体实施方式
12.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本技术，并不用于限定本技术。
13.下面结合说明书附图和具体的实施例对本技术进行进一步的说明。所描述的实施例不应视为对本技术的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
14.在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。
15.除非另有定义，本文所使用的所有的技术和科学术语与属于本技术的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本技术实施例的目的，不是旨在限制本技术。
16.物资，即物资资源，通常包括可以直接满足社会各方所需求的生活资料，又包括间接满足社会各方所需要的生产资料。目前，当物资出现短缺的情况时需求方通常通过用于解决商品购买与出售的线上平台，如b2b（btb，企业对企业之间的电子商务模式）、b2c（btc,企业对消费者的电子商务模式）等，完成短缺物资的采购。由于构建线上平台的架构多为整体式架构，当其中一个组件出现故障时，将会导致整个应用程序无法运行，进而影响需求方对物资的采购的进行。并且，由于平台系统所提供的服务功能有限且较为传统，在面临大量物资采购时，线上平台并未设置有对应的仓储应用、供应商服务等应用或服务，进而有可能会出现物资商品的库存量不足，导致无法满足需求方的物资需求，增加了物资采购的难度。
17.分布式系统由一组为了完成共同任务而协调工作的计算机节点组成，它们通过网络进行通信。分布式系统能满足互联网对大数据存储、高并发和快响应的要求，从实际成本来说，分布式系统通过廉价的普通机器进行独立运算，通过多个机器相互协助来完成网站业务，以完成单个计算机节点无法完成的计算和存储任务。分布式系统具有以下至少之一的优点：第一，高性能。当存在有大量的请求时，分布式系统可以将请求合理地分摊至每个节点，减少每一台服务器的运算负担，并且多个请求通过多台机器同时处理，能够有效地提高请求处理的效率；第二，高可用性。在单机系统中，当机器出现故障时将会造成网站不可使用的情况。在分布式系统中，当某个机器（即节点）出现故障时，分布式系统将会迅速地发现该节点存在故障，进而不再向该节点转发请求，分布式系统的其他节点仍旧可以使用。
18.第三，可伸缩性。当现有的机器的性能不能满足业务的发展时，则需要拓展微服务。在分布式系统中，只需要对路由算法进行改造，使路由算法找寻到新的可使用的机器，从而将更多的可使用的机器纳入至分布式系统中，以满足大数据、并发性和快速响应的要求。从另一个方面来说，若现有的机器已经超出实际需求，则可以通过路由算法减少机器，进而节省成本。
19.微服务是一种架构，这种架构是将单个的整体应用程序分割成更小的项目关联的独立的服务。一个服务通常实现一组独立的特性或功能，包含自己的业务逻辑和适配器。各个微服务之间的关联通过暴露api来实现。这些独立的微服务不需要部署在同一个虚拟机，同一个系统和同一个应用服务器中。
20.针对上述情况，本技术采用ddd（domain-driven design，领域驱动设计），ddd是一种综合软件系统分析和设计的面向对象建模的方法，结合微服务架构、分布式系统以及docker容器技术，提出一种物资服务管控方法、系统及存储介质，其扩展性高，能够实现多个微服务的自动部署与管理，适用于物资服务管控系统的管理方、需求方、商家以及供应商等多个角色。本技术提供的方法协调管理和运行多个应用服务器、数据库服务器和存储文件服务器，使得多个服务层的微服务和应用层的应用的完整、有序地运行，降低在调用微服务和应用时的数据运算量。同时，本技术通过调用多个针对需求方物资采购需求的应用和服务，在面对大量物资采购的情况时，通过仓储应用和供应商服务调取短缺物资对应的供应商信息，以保证物资商品能够满足需求方的需求，降低了物资采购的难度，提高了需求方的采购体验。
21.参照图1所示，图1为本技术实施例提供的物资服务管控方法的流程示意图。本申
请提供的物资服务管控方法，包括以下步骤：通过前端向网关层发起对应的物资服务请求,物资服务请求用于调用服务层的业务微服务；根据物资服务请求，网关层向应用层中与物资服务请求对应的应用发送第一调用请求；根据第一调用请求，应用层向服务层中与第一调用请求对应的业务微服务发起第二调用请求；根据第二调用请求，服务层向前端提供与第二调用请求对应的业务微服务；在服务层向前端提供与第二调用请求对应的业务微服务时，通过存储层调用与业务微服务对应的数据采集模型和数据分析模型，通过数据采集模型向服务层的业务微服务提供数据存储和数据调出的服务，并通过数据分析模型向服务层的业务微服务提供数据分析的服务。
22.需要说明的是，业务微服务包括商品服务、交易服务、供应商服务、支付服务或物流服务中的至少一种。
23.具体地，商品服务用于提供与物资商品相关的服务。与物资商品相关的服务可以包括但不限于搜索或查询物资信息，根据预设的规则对物资信息进行分类并展示，新增、修改和删除物资信息。
24.可选地，根据预设规则对商品信息进行分类包括：根据商品信息的sku（stock keeping unit，库存量单位）编码或spu（standard product unit，标准化产品单元)编码对商品信息进行分类。
25.在一实施例中，当需求方需要搜索或查询商品时，可通过前端调取商品服务进行物资商品的查询，服务层将物资信息进行分类并将分类后的物资信息通过前端展示。在另一实施例中，当管控系统的管理员因需求需要修改物资信息时，可通过前端调取商品服务实现对物资信息的新增、修改和删除的操作。
26.具体地，交易服务用于提供与物资商品交易相关的服务。交易相关的服务可以包括但不限于提交购买订单信息，对所提交的购买订单信息执行查看、修改和维护等操作。在一实施例中，当物资需求方需要购买某一物资商品时，可通过前端调取商品服务获取所需要的物资商品，并通过交易服务提交与所需要的物资商品对应的购买订单信息，并可通过交易服务查看和修改所提交的购买订单信息。在另一实施例中，当管控系统的管理员需要维护购买订单信息的相关数据时，可通过前端调取交易服务以实现对购买订单信息的维护操作。
27.具体地，供应商服务用于提供与供应商相关的服务。与供应商相关的服务可以包括但不限于获取储备数量不足的物资信息，采集与储备数量不足的物资信息对应的供应商信息并展示；获取供应商信息，新增、删除和修改供应商信息；维护供应商信息及其相关属性。
28.需要说明的是，供应商信息的相关属性包括：供应商的名称信息、类别信息、生产周期信息、评价信息和相关订单信息。
29.在一实施例中，当需求方需要购买某一物资商品，但该物资商品的储备数量显示不足时，可通过前端调取供应商服务获取与该物资商品对应的供应商信息，通过供应商信
息挑选对应的供应商，通过供应商调取储备数量不足的物资商品或直接从供应商处购买该物资商品，保证了需求方的物资需求。之后，需求方可通过交易服务提交相关购买订单信息。
30.在另一实施例中，当需求方有大量物资商品的采购需求时，而多个物资商品在采购平台上的储备数量不足以满足需求方的物资需求时，需求方通过前端调取供应商服务以获得多个供应商信息，进而实现储备数量不足的多个物资商品的购买。本技术提供的供应商服务能够应对大量物资商品的采购需求，避免出现物资商品的储备不足而无法满足需求方的物资需求的现象。
31.在又一实施例中，当管控系统的管理员需要修改或维护供应商信息的相关数据时，可通过前端调取供应商服务以实现对供应商信息的新增、删除和修改以及维护其相关属性的操作。
32.具体地，支付服务用于提供多渠道的支付方式，支付方式用于支付购买订单信息。另外，支付服务还可以用于生成购买订单信息的支付结果，调取历史的购买订单信息并展示。
33.可选地，支付方式包括b2b网银支付方式、b2c网银支付方式、如微信支付或支付宝支付的快捷支付方式或其他第三方支付方式。
34.在一实施例中，需求方在通过交易服务提交购买订单信息之后，通过支付服务对其所提交的购买订单信息进行支付。在另一实施例中，当需求方需要查看其历史提交的购买订单信息时，可通过前端调取支付服务以实现历史购买订单信息的查询。
35.具体地，物流服务用于提供物流相关的服务，物流为与购买订单信息相关联的物流信息。
36.在一实施例中，需求方在通过支付服务对其所提交的购买订单信息进行支付之后，可通过前端调取物流服务，查看与购买订单信息相关联的物流信息，以便于得知其所需要的物资商品的运输情况，实现对物资商品的运输情况的实时监控。
37.参照图2所示，图2为本技术实施例提供的物资服务管控系统的结构示意图。该系统包括前端、网关层、应用层、服务层、存储层和中间层。前端与网关层相关联，网关层还与应用层相关联；应用层通过中间层与服务层相关联，服务层还与存储层相关联；而中间层分别与服务层和应用层相关联。
38.前端用于向网关层发起对应的物资服务请求，物资服务请求用于向服务层调用对应的业务微服务。
39.可选地，前端由pc端、移动端、提供至第三方及其他应用的暴露服务接口组成。其中，pc端为电脑访问端；移动端为如手机、平板等移动设备；暴露服务接口不限定使用设备，通常为提供给第三方的访问端。
40.网关层用于接收来自前端的服务请求，并向应用层中与物资服务请求对应的应用发送第一调用请求。
41.本实施例中，通过防火墙、负载均衡以及网络地址转换结合实现网关层的功能，同时网关层也是分布式应用的入口分发调度层。
42.其中，负载均衡是指在在多个提供相同服务的服务器的情况下，负载均衡设备存在虚拟服务地址，当大量客户端从外部访问虚拟服务ip地址时，负载均衡设备将这些报文
请求根据负载均衡算法，将流量均衡的分配给后台服务器以平衡各个服务器的负载压力，避免在还有服务器压力较小情况下其他服务达到性能临界点出现运行缓慢甚至宕机情况，从而提高服务效率和质量。
43.网络地址转换（nat，network address translation），用于实现私有网络和公有网络之间的互访。网络地址转换用来将内网地址和端口号转换成合法的公网地址和端口号，建立一个会话，与公网主机进行通信。网络地址转换外部的主机无法主动跟位于网络地址转换的内部的主机通信，网络地址转换的内部主机想要通信，必须主动和公网的一个ip通信,路由器负责建立一个映射关系，从而实现数据的转发。
44.可选地，防火墙为waf（web application firewall，web应用防火墙），waf是通过执行一系列针对http/https的安全策略来专门为web提供保护的一种防火墙。
45.可选地，网关层与前端通过第一网络协议进行通信连接。其中，第一网络协议包括http（hypertext transfer protocol，超文本传输协议）、套接字（socket）和基于tcp的全双工通信协议（websocket）中的至少一种。
46.需要说明的是，http是目前应用最广泛的一个网络传输协议，是用于从www服务器传输超文本到本地浏览器的传送协议，保证了计算机正确快速地传输超文本文档，使得浏览器更加高效并减少网络传输的数据量。
47.需要说明的是，网络上的两个程序通过一个双向的通信连接实现数据的交换，这个连接的端称为socket，应用程序通过socket向网络发出请求或应答网络请求。在互联网上的主机一般运行了多个服务软件，并同时提供若干种服务。每种服务都会打开一个socket，并绑定到一个端口上，不同的端口对应于不同的服务。客户端通过调用不同的端口以获得不同的服务。
48.需要说明的是，websocket协议是基于tcp的一种新的网络协议，实现了浏览器与服务器全双工通信以及允许服务器主动发送信息给客户端。在实现websocket连线过程中，需要通过浏览器发出websocket连线请求，服务器作出回应，这个过程通常称为握手。在websocket中，浏览器和服务器只需要做一个握手的动作，浏览器和服务器即可形成一条快速的通信通道。在此websocket协议中，两者互相沟通的头部数据很小，通常只有2bytes的数据量，并且服务器不再被动地接收到浏览器的请求之后才返回数据，而是在有新数据的时候，服务器就会将数据主动推送至浏览器。
49.应用层包括多个应用，每一个应用均向服务层中与所述第一调用请求对应的服务发起第二调用请求。
50.需要说明的是，应用层至少包括买家应用、店铺应用、商城应用、平台应用、仓储应用、物流应用、支付应用和开放应用程序编程接口应用。
51.本实施例中，应用层为用户实际业务需求所搭建的代码业务逻辑层。应用层主要针对实际业务应用场景与业务逻辑进行编码实现，形成满足用户需求的操作层。
52.可选地，网关层与应用层亦通过第一网络协议进行通信连接。其中，第一网络协议包括http（hypertext transfer protocol，超文本传输协议）、套接字（socket）和基于tcp的全双工通信协议（websocket）中的至少一种。
53.服务层包括多个业务微服务，用于根据第二调用请求，提供与第二调用请求相对应的业务微服务。
54.需要说明的是，业务微服务至少包括商城服务、商品服务、用户服务、店铺服务、交易服务、活动服务、平台服务、会员服务、供应商服务、结算服务、支付服务、物流服务和车辆服务。
55.需要说明的是，服务层还包括多个组件微服务，组件微服务至少包括工作者服务、文件服务、数据服务、数据分析服务和数据采集服务。
56.存储层包括数据采集模型和数据分析模型，用于调用与业务微服务对应的数据采集模型和数据分析模型，通过数据采集模型向服务层的业务微服务提供数据存储和数据调出的服务，并通过数据分析模型向服务层的业务微服务数据分析的服务。
57.需要说明的是，数据采集模型至少包括订单采集模型、商品采集模型、物流采集模型和供应商采集模型。数据分析模型至少包括订单分析模型、商品分析模型、物流分析模型、供应商分析模型和供应链分析模型。
58.参照图3所示，图3为本技术实施例提供的中间层的结构示意图。下面将对中间层的结构进行说明和阐述。中间层包括注册中心、配置中心和中间件，用于构建分布式微服务框架，管理服务层和应用层的配置信息，并提供分布式微服务框架运行所需要的中间件。
59.需要说明的是，注册中心用于向服务层提供注册业务微服务和管理业务微服务的服务，获取业务微服务并输出至应用层。配置中心用于向服务层和应用层提供配置信息，并管理配置信息。中间件包括缓存中间件、消息中间件、分布式任务调度中间件和搜索中间件。
60.进一步地，缓存中间件用于根据服务层的业务微服务和应用层的应用的需要，进行数据存入和输出。
61.可选地，使用redis（remote dictionary server，远程字典服务）和memcached作为缓存中间件。 redis是一种支持key-value等多种数据结构的高速缓存数据库，适用于存储信息量较小的数据。redis具有内存操作速度快、所支持的数据类型多样的优点，可以用作分布式锁和消息队列，还可用于持久化数据。其中，redis所支持的数据类型包括字符串、链表、集合、有序集合和哈希。而memcached是一个基于内存的key-value存储系统，适用于存储信息量较大的数据。通常在使用mysql数据库时通过在其中增加memcached，mysql内部检测该sql是否在memcached中存在，若不存在则访问数据库，否则访问memcached即可。将缓存中间件memcached放在数据库层面，不仅可以减少查询数据库的数据运算量，还能够有效地确保数据的一致性。较redis而言，memcached只支持简单数据类型。
62.本技术采用redis和memcached作为缓存中间件，同时存储信息量较大和信息量较小的数据，进而实现多种不同数据结构的数据的缓存。并且，当因应用层的应用或服务层的业务微服务的需要而需要调用相关的数据信息时，只需调用memcached即可实现数据库的访问，提高了物资服务的调用速率，同时也降低了系统的运算量和运算负担。
63.进一步地，消息中间件用于采集和存储服务层的微服务和应用层的应用的日志信息，构建任务队列，并根据第一调用请求新增服务层的服务任务至任务队列，根据第二调用请求新增应用层的应用任务至任务队列。
64.可选地，使用kafla和rocketmq作为消息中间件。kafla是指一种高吞吐量、可划分、冗余备份的分布式发布订阅消息系统，主要用于处理在网站中的所有动作流数据。kafla可以采集网页浏览产生的数据或搜索某个关键词时产生的数据，并能够采集日志消
息和监控数据，是分布式架构中较为常用的消息中间件之一。而rocketmq是一个队列模型的消息中间件，具有高性能、高可靠、高实时和分布式的特点。rocketmq基于高可用分布式集群技术，提供消息订阅和发布、消息轨迹查询以及定时消息等一系列消息服务，为分布式应用系统提供异步解耦、削峰填谷的能力。
65.本技术采用kafla和rocketmq作为系统的消息中间件，对物资商品采购平台的动作流数据进行采集与监控，通过构建任务队列实现应用层与服务层之间的通信。当应用层接收到第一调用请求时，产生第二调用请求并发送至中间层，第二调用请求对应于应用层的应用任务。中间层的配置中心获取应用任务的配置信息；根据配置信息，消息中间件kafla将对应的应用任务置于任务队列中，通过应用任务向服务层调用对应的业务微服务。当服务层接收到第二调用请求并调用对应的业务微服务时，业务微服务对应于服务层的服务任务，中间层的配置中心获取服务任务的配置信息；根据配置信息，消息中间件将对应的服务任务置于任务队列中，向前端提供对应的业务微服务。
66.进一步地，分布式任务调度中间件用于执行服务任务和应用任务。
67.可选地，使用elastic-job作为分布式任务调度中间件。elastic-job是一个去中心化的分布式调度中间件，其作业调度的过程为：当多个节点运行时，先选择一个节点作为主节点；当到达执行时间后，每个实例开始执行任务，主节点负责分片的划分，其他节点等待划分的完成；每个节点获取主节点划分好的分片项，并将分片项作为参数执行任务。
68.进一步地，搜索中间件用于查询中间层中可使用的中间件。
69.需要说明的是，可使用的中间件包括缓存中间件、消息中间件和分布式任务调度中间件中的至少一种。
70.可选地，使用elasticsearch作为搜索中间件。elasticsearch是一个分布式搜索中间件，能够横向拓展至数以百计的服务器存储以及处理pb级的数据，可以在极短的时间内存储、搜索和分析大量的数据。本技术通过elasticsearch实现高效地调用中间层的多个中间件，获取服务层和应用层的相应配置信息，并实现服务层的业务微服务的调用。
71.参照图2所示，本技术的一个实施例，下面将对服务层的业务微服务进行进一步说明和阐述。服务层中所包含的业务微服务还包括活动服务、结算服务、车辆服务、商城服务、用户服务、店铺服务、平台服务或会员服务中的至少一种。根据第二调用请求，服务层向前端提供与第二调用请求对应的业务微服务，还包括以下至少之一：当与第二调用请求对应的业务微服务为商城服务时，通过商城服务向前端提供装修商城、更改商城状态和修改商城首页所展示的活动信息的服务。
72.可以理解的是，商城为物资商品的采购平台。
73.需要说明的是，商城服务用于提供与商城相关的服务。与商城相关的服务可以包括但不限于修改物资商品采购平台的状态，修改物资商品采购平台的首页所展示的活动信息。活动信息至少包括店铺信息以及平台信息。
74.在一实施例中，当管控系统的管理员需要修改商城的状态或活动信息，亦或者需要装修商城时，管控系统的管理员可通过前端向服务层调用商城服务，以完成商城状态和活动信息的修改或装修商城的操作。
75.当与第二调用请求对应的业务微服务为用户服务时，通过用户服务向前端提供查询、分类和维护买家用户信息的服务。
76.需要说明的是，用户服务用于提供与需求方即购买方相关的服务。与需求方相关的服务可以包括但不限于查询买家用户信息，根据买家用户信息对用户进行分类和维护。
77.在一实施例中，当需求方即买家想要查询自己的买家用户信息时，可通过前端获取用户服务，以获取自己的买家用户信息。在另一实施例中，当商家或管控系统的管理者需要管理或维护与其有关联的买家用户信息，可通过前端获取用户服务以对买家用户信息进行分类并维护买家用户信息。
78.当与第二调用请求对应的业务微服务为店铺服务时，通过店铺服务向前端提供查询、修改和维护店铺信息的服务。
79.需要说明的是，店铺服务用于提供与店铺相关的服务，店铺服务通常面对商家而开放。与店铺相关的服务可以包括但不限于查询和管理店铺信息，维护店铺信息及其相关属性。需要说明的是，店铺信息的相关属性包括：店铺的名称信息、类别信息、评价信息和相关订单信息。在一实施例中，商家可通过前端获取店铺服务，以根据自身需求查询和管理店铺信息，以及对店铺进行维护。
80.当与第二调用请求对应的业务微服务为活动服务时，通过活动服务向前端提供新建、修改和维护店铺的活动信息和平台活动信息，以及构建店铺的活动信息对应的活动规则和平台活动信息对应的活动规则的服务。
81.需要说明的是，活动服务用于新建和修改活动信息并对其进行维护，以及建立活动信息对应的活动规则。活动信息至少包括店铺活动信息以及平台活动信息，活动规则至少包括与店铺的活动信息对应的活动规则，以及与平台活动信息对应的活动规则。活动服务通常面对商家以及管控系统的管理员开放。
82.在一实施例中，商家或管控系统的管理员可以就某一物资商品设置相应的折扣，根据折扣新建或修改活动信息，构建活动规则，并通过前端向多个需求方展示。需求方通过商城的首页可以清晰地得知物资商品的活动信息，以便于进行对物资商品的采购。
83.当与第二调用请求对应的业务微服务为平台服务时，通过平台服务向前端提供设置和维护平台信息的服务。
84.需要说明的是，平台为物资商品的采购平台。平台服务用于提供与平台相关的服务。与平台相关的服务可以包括但不限于设置平台信息和维护平台信息。平台服务通常面对管控系统的管理者开放。
85.当与第二调用请求对应的业务微服务为结算服务时，通过结算服务向前端提供与购买订单信息相对应的结算方式。
86.需要说明的是，结算服务用于提供购买订单信息的结算方式，通过结算方式结算购买订单信息。而通过结算方式结算购买订单为通过买家用户所选定的结算方式对买家用户选中的商品信息进行统计和结算。
87.需要说明的是，结算服务与支付服务不同。例如，需求方同时购买了商品一、商品二和商品三三种商品，统计这三种商品的单价以及总价格，这一行为通过结算服务实现。当计算得到这三种商品的总价格，通过交易服务生成购买订单信息，根据购买订单信息中的总价格进行支付，这一行为通过支付服务实现。
88.当与第二调用请求对应的业务微服务为会员服务时，通过会员服务向前端提供查询、修改和维护会员信息的服务。
89.需要说明的是，会员服务用于提供与会员相关的服务。会员信息的数量小于或等于买家用户信息的数量，而会员信息对应的用户调用微服务时的优先级大于非会员信息对应的用户调用微服务时的优先级。
90.在一实施例中，当具有会员信息的需求方需要查询自身的会员信息时，可通过前端调用会员服务实现。在另一实施例中，管控系统的管理者或者商家亦可通过前端调用会员服务查询或维护与其相关联的会员信息。
91.当与第二调用请求对应的业务微服务为车辆服务时，通过车辆服务向前端提供采集、存储、展示和维护与物流信息对应的物流车辆信息的服务。
92.需要说明的是，车辆服务用于采集物流车辆信息及其与物流信息的映射关系，存储、展示并维护物流车辆信息及其与物流信息的映射关系。车辆服务通常面对需求方和商家开放。
93.在一实施例中，当需求方需要查询某一购买订单信息对应的物流信息时，通过前端调用物流服务以及物流车辆服务，通过物流车辆服务采集物流车辆信息及其与物流信息的映射关系，生成相关的物流信息，输出至前端并展示。需求方通过前端所展示的物流信息即可得知当前物资商品的运输情况。在另一实施例中，商家通过前端调用物流车辆服务，实现对物资商品的运输情况的监控，以保证物资商品及时送达至需求方处。
94.参照图2所示，本技术的一个实施例，下面将对服务层的组件微服务进行进一步说明和阐述。服务层除了包括有业务微服务，还包括有组件微服务。组件微服务用于为业务微服务的调用和执行提供数据和架构的支持。对此，物资服务管控方法还包括：在服务层向前端提供与第二调用请求对应的业务微服务时，根据第二调用请求对应的业务微服务，提供组件微服务。
95.需要说明的是，组件微服务包括工作者服务、文件服务、数据服务、数据分析服务和数据采集服务。
96.进一步地，根据第二调用请求对应的业务微服务，提供组件微服务，包括以下至少之一：通过工作者服务以异步、定时和任务触发的方式对服务层的服务任务和应用层的应用任务进行调度。
97.需要说明的是，异步是指在获取到任务之后，先将该任务挂起；待该任务可以被执行时，再加入至任务队列中等待执行。定时是指在获取到任务之后，该任务携带有其可以执行的时间戳、时间值或者时间周期，当到达该时间戳、时间值或者时间周期时，将该任务加入至任务队列中等待执行。任务触发是指预先设置任务执行的条件，当达到该条件时将任务加入至任务队列中等待执行。任务触发的实现方式可以是定时触发，也可以是前端页面手动触发。
98.本步骤中，前端请求调用服务层的业务微服务的过程中，不仅调用业务微服务，还调用了应用层中的部分应用，将会产生服务层对应的服务任务和应用层对应的应用任务。对此，通过调用工作者服务对多个服务任务和多个应用任务进行调度，保证服务任务和应用任务有序地执行。
99.通过文件服务以预设的存储方式存储应用层和服务层的数据。
100.需要说明的是，存储方式包括对象存储、文件存储或信息存储中的至少一种。对象
存储的体现形式通常为uuid（universally unique identifier，通用唯一识别码），将数据和元数据打包一起作为一个整体对象存储。对于对象访问，只需要通过uuid即可访问对应的数据和元数据。文件存储通过以目录和文件的形式体现，数据以文件的方式存储和访问，并按照目录的结构进行组织与分类。文件存储可以对数据进行一定的高级管理，比如在文件层面进行访问权限控制等。而信息存储可以理解为块存储，其体现形式通常为卷或硬盘，数据以字节为单位进行访问。对于块存储，其只负责数据的读取和写入，适用于对响应时间要求较高的系统或模块。
101.本步骤中，采用对象存储、文件存储和信息存储的存储方式实现应用层和服务层的数据的存储。通过对象存储提供足够的存储空间，对应用层和服务层在调用过程中所产生的大量的数据和元数据进行存储；通过文件存储能够实现对应用层和服务层的数据进行分类；而通过信息存储能够做到快速地响应应用层和服务层的部分数据的读取和写入，达到快速响应前端的物资服务请求的效果。
102.通过数据服务从存储层中调用与第二调用请求对应的数据分析模型和数据采集模型，并维护数据分析模型和数据采集模型。
103.本步骤中，数据服务用于协同根据需求者的物资服务请求，加载相应的数据分析模型或数据分析模型进行数据的相关操作如采集、分析等，并对数据分析模型和数据采集模型进行维护，以保证数据分析模型和数据采集模型正常运行，为服务层的业务微服务和应用层的应用的运作提供强大的数据支撑。
104.通过数据采集服务执行根据第二调用请求对应的数据采集模型，并对与第二调用请求对应的业务微服务进行数据存储和数据调出；通过数据分析服务根据第二调用请求对应的数据分析模型，并对与第二调用请求对应的业务微服务进行数据分析。
105.参照图4所示，图4为本技术实施例提供的数据采集模型的结构示意图。本技术的一个实施例，下面将对通过数据采集模型向服务层的业务微服务提供数据存储和数据调出的服务进行说明和阐述。通过数据采集模型向服务层的业务微服务提供数据存储和数据调出的服务包括以下至少之一：调用订单采集模型采集购买订单信息，向结算服务、支付服务以及交易服务提供购买订单信息。
106.需要说明的是，订单采集模型用于采集和存储购买订单信息，并向结算服务、支付服务和交易服务提供存储购买订单信息和调出购买订单信息的功能。
107.需要说明的是，购买订单信息可以包括但不限于购买订单的名称信息、总状态信息、支付状态信息、总价格信息、实际支付价格信息、确认时间值信息、支付时间值信息、完成时间值信息、持续时长信息以及买家用户信息。
108.其中，总状态信息包括已完成状态信息或未完成状态信息中的任一种；支付状态信息包括已支付状态信息或未支付状态信息中的任一种；总价格信息大于或等于实际支付价格信息。可以理解的是，因店铺的活动信息或平台的活动信息而产生商品折扣百分比，使得实际商品价格变为原本商品价格与商品折扣百分比相乘后的数值，该实际商品价格则为实际支付价格。
109.本步骤中，当应用层向服务层所发送的第二调用请求对应的业务微服务为结算服
务、支付服务或交易服务中的任一种时，服务层通过存储层调用订单采集模型，进而采集购买订单信息，为结算服务、支付服务或交易服务中的任一种提供数据支持。
110.可选地，订单采集模型连接有订单商品采集模型。调用订单采集模型采集购买订单信息，向结算服务、支付服务以及交易服务提供购买订单信息，包括：调用订单商品采集模型采集与购买订单信息相对应的商品信息并提供至订单采集模型需要说明的是，与购买订单信息相对应的商品信息包括：商品的名称信息、图片信息、购买价格信息、购买数量信息和折扣信息。其中，折扣信息为因店铺的活动信息或平台的活动信息而产生的商品折扣百分比。
111.本步骤中，订单商品采集模型用于采集和存储与购买订单信息相对应的商品信息，并将与购买订单信息相对应的商品信息输出至订单采集模型，以供订单采集模型完善购买订单信息并向结算服务、支付服务和交易服务提供存储购买订单信息和调出购买订单信息的功能。
112.本技术中，由于订单采集模型存储有购买订单信息，而与购买订单信息相对应的商品信息的数据量较大，若订单采集模型在接收到第二调用请求时同时采集并存储购买订单信息以及与购买订单信息相对应的商品信息，将会降低数据采集的效率和速率。为了降低订单采集模型的数据采集量和提高数据采集的效率，本技术设置订单商品采集模型，订单商品采集模型与订单采集模型连接，由订单商品采集模型对商品信息进行采集，由订单采集模型对购买订单信息进行采集，能够提高数据采集的效率。
113.调用商品采集模型采集物资信息，向商品服务和活动服务提供物资信息。
114.需要说明的是，商品采集模型用于采集和存储物资信息，并向商品服务和活动服务提供存储物资信息和调出物资信息的功能。物资信息包括：物资商品的spu（standard product unit，标准化产品单元)编号信息、sku（stock keeping unit，库存量单位）编号信息、名称信息、详情信息、价格信息、折扣信息、图片信息、库存数量信息以及历史销量信息。
115.本步骤中，当应用层发送至服务层的第二调用请求对应的业务微服务为商品服务或活动服务时，服务层通过存储层调用商品采集模型采集对应的物资信息，为商品服务和活动服务提供数据支持。
116.调用供应商采集模型采集所述供应商信息，向所述供应商服务提供所述供应商信息。
117.需要说明的是，供应商采集模型用于采集和存储供应商信息，并向供应商服务提供存储供应商信息和调出供应商信息的功能。供应商信息包括：供应商的名称信息、联系信息、地址信息以及其所生产的商品信息。
118.本步骤中，供应商采集模型主要采集物资商品的供应商的相关数据，以应对当出现大量物资采购的情况时，调用供应商采集模型能够快速地、准确地采集得到供应商信息。
119.在一实施例中，当需求方所需要采购的某一物资商品的库存量不足，或者当需求方有大量物资采购的需求而出现多个物资商品的库存量不足，需求方通过前端调用供应商服务，供应商服务通过存储层的供应商采集模型采集所得到的供应商信息，进而通过供应商服务向需求方提供储备有库存量不足的物资商品的供应商。之后，需求方可通过供应商调取储备数量不足的物资商品或直接从供应商处购买该物资商品，使得需求方顺利完成物
资的采购，以满足需求方的物资商品的采购需求。
120.调用物流采集模型采集与购买订单信息对应的物流信息，向车辆服务和物流服务提供物流信息。
121.需要说明的是，车辆采集模型用于采集和存储与购买订单信息相对应的物流信息，并向车辆服务和物流服务提供存储物流信息和调出物流信息的功能。
122.需要说明的是，与购买订单相对应的物流信息包括运输商品车辆的当前位置信息、当前状态信息、最大承重信息、联系信息、在线时长信息和更新时间信息。其中，当前位置信息可以通过定位技术实现；当前状态信息包括正在运载状态信息和未运载状态信息中的一种。
123.本步骤中，车辆采集模型主要采集与购买订单信息对应的的物流信息，即购买订单信息的物资商品的运输情况或状态。当应用层向服务层所发送的第二调用请求对应的业务微服务包括车辆服务或物流服务中的任一种时，服务层通过存储层调用车辆采集模型，进而采集相关的物流信息，为车辆服务或物流服务中的任一种提供数据支撑。
124.可选地，运输商品车辆周期性将其当前位置信息和当前状态信息上传至车辆采集模型，车辆采集模型存储运输商品车辆的当前位置信息、当前状态信息、最大承重信息和联系信息。运输商品车辆上传其当前位置信息和当前状态信息的时间值为更新时间信息，多个更新时间信息之和则为在线时长信息。本技术通过物流信息能够对多台运输商品车辆进行管理与监控，实现对商品的运输情况的实时追踪，以便于及时应对出现异常的物流运输情况。
125.参照图5所示，图5为本技术实施例提供的数据分析模型的结构示意图。本技术的一个实施例，下面将对通过数据分析模型向服务层的业务微服务提供数据分析的服务进行说明和阐述。通过数据分析模型向服务层的业务微服务提供数据分析的服务，包括以下至少之一：从订单采集模型调取购买订单信息，通过订单分析模型分析购买订单信息，生成订单分析结果并输出至结算服务、支付服务和交易服务。
126.需要说明的是，订单分析模型用于从订单采集模型中调取并分析购买订单信息，并向结算服务、支付服务和交易服务提供购买订单信息的分析结果。
127.可选地，根据与购买订单信息的相关数据，如确认时间值信息、支付时间值信息、完成时间值信息和持续时长信息等，订单分析模型分析与购买订单信息的相关数据，如分析购买订单信息是否完成，或购买订单信息是否出现异常情况。之后，得到的分析结果并将其输出至服务层中与第二调用请求对应的业务微服务，业务微服务包括结算服务、支付服务或交易服务的任一种。
128.从商品采集模型调取物资信息，通过商品分析模型分析物资信息，生成商品分析结果并输出至商品服务和活动服务。
129.需要说明的是，商品分析模型用于从商品采集模型中调取并分析商品信息，并向商品服务和活动服务提供商品信息的分析结果。
130.可选地，根据商品信息，如物资商品的sku编号信息、spu编号信息等，分析物资商品的商品信息，生成商品分析结果并输出至服务层中的商品服务或活动服务。其中，商品分析结果可以包括但不限于物资商品对应的第一级分类、第二级分类和第三级分类、物资商
品的品牌名称信息、生产日期信息，以及与该物资商品相似的其他物资商品。第二级分类由第一级分类进行细分得到，第三级分类由第二级分类进行细分得到。
131.从供应商采集模型调取供应商信息，通过供应商分析模型分析供应商信息，生成供应商分析结果并输出至供应商服务。
132.需要说明的是，供应商分析模型用于从供应商分析模型中调取并分析供应商信息，并向供应商服务提供供应商信息的分析结果。
133.本步骤中，通过存储层从供应商采集模型中调取供应商信息，供应商信息为单个物资商品所对应的供应商信息。之后，通过供应商分析模型分析单个物资商品所对应的供应商信息，如分析供应商所储备的物资商品的储备量能否满足需求方的物资需求数量。之后，供应商分析模型生成供应商信息对应的分析结果，并输出至服务层中与第二调用请求对应的业务微服务，业务微服务包括供应商服务。
134.从物流采集模型调取物流信息，通过物流分析模型分析物流信息，生成物流分析结果并输出至车辆服务和物流服务。
135.需要说明的是，物流分析模型用于从车辆采集模型中调取并分析物流信息，并向车辆服务和物流服务提供物流信息的分析结果。
136.可选地，根据运输商品车辆的当前位置信息、当前状态信息和在线时长信息，通过物流分析模型对物资商品的当前运输状态进行分析，得到对应的分析结果并输出至服务层中与第二调用请求对应的业务微服务，业务微服务包括车辆服务或物流服务中的任一种。
137.从供应商采集模型调取若干供应商信息，通过供应链分析模型分析若干供应商信息，生成供应链分析结果并输出至供应商服务。
138.需要说明的是，供应链分析模型用于从供应商采集模型中调取多个供应商信息并进行分析，并向供应商服务提供供应商信息的分析结果。
139.本步骤中，通过存储层从供应商采集模型中调取供应商信息，该供应商信息为多个物资商品所对应的所有供应商信息，即多个物资商品的供应链信息，供应链上包含多个供应商。之后，通过供应链分析模型分析多个供应商信息，如针对某个物资商品，分析供应链的储备数量能否满足需求方的物资需求数量。之后，供应链分析模型生成对应的分析结果，并输出至服务层中与第二调用请求对应的业务微服务，业务微服务包括供应商服务。
140.可选地，针对某一物资商品，通过供应商服务获取该物资商品对应的供应商信息。根据物资商品对应的供应商信息，确定多个供应商的物资商品的储备量不足，通过存储层调取供应链分析模型，通过供应链分析模型分析该物资商品对应的供应链的储备数量能否满足物资需求的数量，并生成分析结果输出至供应商服务。此时，若供应链的储备数量能够满足物资需求的数量，需求方可以通过调度供应链的物资商品或直接购买供应链的物资商品，以确保满足其物资需求。
141.在一实施例中，存储层除了设置有多个数据采集模型和多个数据分析模型，还设置有分布式文件存储模块、分布式数据库和分布式对象存储模块。分布式文件存储模块用于采用分布式架构存储以文件存储方式存储的数据。分布式数据库为采用分布式架构的数据库，可选地，使用mysql作为分布式数据库。分布式对象存储模块用于采用分布式架构存储以对象存储的方式存储的数据。
142.本技术的一个实施例，下面将对根据第一调用请求，应用层向服务层中与第一调
用请求对应的业务微服务发起第二调用请求进行说明和阐述。根据第一调用请求，应用层向服务层中与第一调用请求对应的业务微服务发起第二调用请求，包括以下至少之一：当与服务请求对应的应用为买家应用时，应用层通过买家应用向服务层的会员服务、用户服务和交易服务发起第二调用请求，以获取买家用户信息和购买订单信息，提供修改买家用户信息和购买订单信息，并处理购买订单信息。
143.需要说明的是，买家应用用于获取买家用户信息和购买订单信息，提供修改买家用户信息和购买订单信息以及处理购买订单信息的功能。买家应用主要面对需求方即买家而开放。
144.本步骤中，当需求方有如修改其买家用户信息或购买订单信息等需求时，可通过前端向应用层调用买家应用，进而调用服务层的会员服务、交易服务或用户服务中的任一种。
145.当与服务请求对应的应用为商城应用时，应用层通过商城应用向服务层的商城服务、商品服务和活动服务以及交易服务发起第二调用请求，以搜索物资信息和展示与物资信息对应的店铺活动和平台活动，并提交购买订单信息。
146.需要说明的是，商城应用用于为买家用户提供购买商品的相关功能。其中，购买商品的相关功能可以包括但不限于搜索商品信息、对商品信息对应的店铺活动和平台活动进行展示，以及提交购买订单信息。商城应用主要面对需求方即买家而开放。
147.本步骤中，当需求方有如查询商品信息、活动信息或提交购买订单信息等需求时，可通过前端向应用层调用商城应用，进而调用服务层的商城服务、商品服务、活动服务或交易服务中的任一种。
148.当与服务请求对应的应用为支付应用时，应用层通过支付应用向服务层的支付服务和结算服务发起第二调用请求，以获取购买订单信息的支付方式和结算方式。
149.需要说明的是，支付应用用于提供支付和结算购买订单的相关功能。支付应用主要面对需求方即买家而开放。支付购买订单的相关功能可以包括但不限于提供支付购买订单信息的支付方式和结算方式。可选地，支付方式包括b2b网银支付方式、b2c网银支付方式、如微信支付或支付宝支付的快捷支付方式或者其他第三方支付方式。
150.本步骤中，当需求方有如支付购买订单信息等需求时，可通过前端向应用层调用支付应用，进而调用服务层的支付服务或结算服务。
151.当与服务请求对应的应用为店铺应用时，应用层通过店铺应用向服务层的店铺服务、商品服务、活动服务、交易服务和物流服务发起第二调用请求，以设置店铺信息以及管理店铺的所有物资信息及其库存信息、与店铺活动和平台活动对应的物资信息、与购买订单信息对应的物流信息和买家用户信息。
152.需要说明的是，店铺应用用于提供售卖商品的相关功能。售卖商品的相关功能可以包括但不限于设置店铺信息以及管理店铺的所有商品信息及其库存信息、与店铺活动和平台活动相应的商品信息、与购买订单信息相应的物流信息和买家用户信息。店铺应用主要面对商家而开放。
153.本步骤中，当商家有如修改商品信息和店铺信息或查询与购买订单信息相应的物流信息、买家用户信息等需求时，可通过前端向应用层调用店铺应用，进而调用服务层的店铺服务、商品服务、活动服务、交易服务或物流服务中的任一种。
154.当与服务请求对应的应用为物流应用时，应用层通过物流应用向服务层的车辆服务、物流服务和交易服务发起第二调用请求，以获取、管理和展示与购买订单信息相对应的物流信息。
155.需要说明的是，物流应用用于提供管理物流的相关功能。管理物流的相关功能可以包括但不限于获取、展示和管理与购买订单信息对应的物流信息。物流应用主要面对商家和需求方而开放。
156.本步骤中，当商家或需求方有如查询与购买订单信息对应的物流信息的需求时，可通过前端向应用层调用物流应用，进而调用服务层的物流服务、交易服务或车辆服务中的任一种。
157.当与服务请求对应的应用为仓储应用时，应用层通过仓储应用向服务层的商品服务、平台服务、店铺服务和供应商服务发起第二调用请求，以管理供应商仓库、店铺仓库和平台仓库的储备信息。
158.需要说明的是，仓储应用用于提供管理多方仓库的相关功能。管理多方仓库的相关功能可以包括但不限于管理供应商仓库、店铺仓库和平台仓库的商品储备信息，平台仓库可以理解为物资商品的采购平台的仓库。仓储应用主要面对管控系统的管理员而开放。
159.本步骤中，当管控系统的管理员有如查询某一物资商品的储备信息时，可以通过前端调用仓储应用，进而调用服务层的商品服务、平台服务、店铺服务或供应商服务中的任一种。
160.当与服务请求对应的应用为平台应用时，应用层通过平台应用向服务层的平台服务发起第二调用请求，以审核和管理店铺信息、供应商信息和购买订单信息。
161.需要说明的是，平台应用用于提供设置物资商品的采购平台的相关功能。设置智能平台的相关功能可以包括但不限于审核和管理店铺信息、供应商信息和购买订单信息。平台应用主要面对管控系统的管理员而开放。
162.本步骤中，当管控系统的管理员有如管理采购平台的相关数据的需求时，前端调用应用层的平台应用，进而调用服务层的平台服务。
163.在一实施例中，根据第一调用请求，应用层向服务层中与第一调用请求对应的业务微服务发起第二调用请求，包括以下至少之一：通过开放应用程序编程接口应用，提供第三方可调用的应用程序编程接口。
164.需要说明的是，开放应用程序编程接口应用为开放api应用。各个组件微服务之间的任何通信均是通过明确定义的应用程序编程接口进行的，通过微服务架构对每个组件微服务进行开发、部署、运营和扩展，并不会影响其他业务微服务的功能。
165.基于上述实施例，本技术提供的物资服务管控方法和系统能够应对需求方的大量物资采购的需求，主要通过仓储应用、供应商服务以及存储层的数据采集模型和数据分析模型实现。下面以一个例子对仓储应用、供应商服务、供应商采集模型、供应商分析模型以及供应链分析模型的作用进一步地说明。当需求方对多个物资商品的需求数量远大于物资采购平台上的物资商品的库存数量或者储备数量时，需求方通过前端发送调用供应商服务的物资服务请求。物资服务请求通过网关层传输至应用层，并调用应用层的仓储应用。仓储应用生成第二调用请求并通过中间层发送至服务层，以调用供应商服务。
166.服务层获得与供应商服务对应的第二调用请求之后，通过存储层调用供应商采集
模型，采集与多个物资商品相关联的供应商的信息，并通过存储层调用供应商分析模型。供应商分析模型对物资商品对应的单个供应商信息依次进行分析，如分析某一供应商的某一物资商品的库存数量能否满足需求方对该物资商品的需求数量。
167.待供应商分析模型对所有供应商信息分析完毕后，若有某一供应商的物资商品的库存数量无法满足需求方对物资商品的需求数量，则通过存储层调取供应链分析模型。供应链分析模型对物资商品对应的全部供应商信息进行分析，如分析该供应链上所有供应商的物资商品的库存数量总和能否满足需求方的需求数量，并将对供应链的分析结果数据输出至供应商服务，以供需求方通过前端获取供应商和供应链的相关数据。需求方根据供应商和供应链的相关数据，可得知储备有物资商品的供应商的信息，进而完成对大量物资商品的采购。
168.本技术通过前端发送物资服务请求至网关层以调用对应的业务微服务，通过网关层发送第一调用请求至应用层以调用对应的应用，并通过应用层向服务层发送第二调用请求，实现对应的业务微服务的调用，进而实现物资采购需求的满足。本技术使得多个应用和业务微服务具备独立性，提高了调用微服务和应用时的灵活性、可扩展性和维护性。当业务规模增加或流量增大时，由于本技术的方法通过调用请求实现业务微服务和应用的调用，只需要需要修改的应用或业务微服务抽离出来进行扩展和修改，以降低系统在业务规模增加或流量增大时的数据运算量，从而降低系统的整体负担，提高系统的运行效率，做到快速响应前端生成的物资服务请求。
169.参照图1和图2所示，本技术的一个实施例，本技术实施例提供的物资服务管控方法还包括：通过中间层构建分布式微服务框架，管理服务层和应用层的配置信息，并提供分布式微服务框架运行所需要的中间件；其中，中间层包括注册中心、配置中心和若干个中间件；进一步地，管理服务层和应用层的配置信息，包括：通过注册中心向服务层提供注册业务微服务和管理业务微服务的服务，根据第二调用请求获取业务微服务并输出至应用层；通过配置中心向服务层和应用层提供配置信息并管理配置信息。
170.进一步地，提供分布式微服务框架运行所需要的中间件，包括：根据服务层的业务微服务和所述应用层的应用的需要，通过缓存中间件进行数据的存入和输出。
171.可选地，缓存中间件至少包括redis和memcached。
172.通过消息中间件执行采集和存储服务层的微服务和应用层的应用的日志信息，构建任务队列，根据第一调用请求和第二调用请求新增服务层的服务任务和应用层的应用任务至任务队列。
173.可选地，消息中间件至少包括kafla和rocketmq。
174.通过分布式任务调度中间件执行服务任务和应用任务。
175.可选地，分布式任务调度中间件包括elastic-job。
176.通过搜索中间件执行查询中间层中可使用的中间件，可使用的中间件包括缓存中间件、消息中间件和分布式任务调度中间件中的至少一种。
可以表示：只存在a，只存在b以及同时存在a和b三种情况，其中a，b可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。
188.在本技术所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其他的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，可以是电性、机械或其它的形式。
189.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
190.另外，在本技术各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
191.所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机装置(可以是个人计算机、服务器或者网络装置等)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：只读存储器(read-only memory，简称rom)、随机存取存储器(random access memory，简称ram)、磁碟或者光盘等各种可以存储程序代码的介质。
192.对于上述方法实施例中的步骤编号，其仅为了便于阐述说明而设置，对步骤之间的顺序不做任何限定，实施例中的各步骤的执行顺序均可根据本领域技术人员的理解来进行适应性调整。