CN113139726A - 多租户派单方法和网约车系统 - Google Patents

Abstract

公开了一种多租户派单方法以及多租户网约车系统。所述方法包括：接收包括乘客用车信息的用车需求；根据所述用车需求生成订单并将所述订单下发给多个租户；多个租户各自筛选符合所述乘客用车信息的司机信息；聚合来自多个租户的通过筛选的司机信息；以及从所述通过筛选的司机信息中选择司机进行派单。本发明通过多租户筛选司机并上报，在聚合平台中完成针对多租户上报司机的选择和绑单，由此为乘客提供更为及时的用车体验并且能够为体量小的租户提供相对均等的接单机会。

Description

多租户派单方法和网约车系统

技术领域

本公开涉及一种云技术，尤其涉及一种多租户派单方法，以及能够实现所述方法的多租户网约车系统。

背景技术

网约车作为新型的互联网服务，不同于普通的电商或者O2O(Online To Offline，即，线上到线下)，更加依赖线上的调度与全局性信息，尤其是对于信息时效性要远远高于电商与O2O，一笔交易的产生往往要求秒级响应。

现有的网约车厂商，在给司机派单时是在该公司自己的调度池内进行筛选，以便选择合适的司机进行绑单。该种绑单形式在网约车厂商运力不足时会导致绑单不及时或是等待时间过久，从而导致乘客体验较差。

为此，需要一种改进的派单方案。

发明内容

本公开要解决的一个技术问题是提供一种多租户派单方案，该方案通过多租户筛选司机并上报，在聚合平台中完成针对多租户上报司机的选择和绑单，由此为乘客提供更为及时的用车体验并且能够为体量小的租户提供相对均等的接单机会。

根据本公开的第一个方面，提供了一种多租户派单方法，包括：接收包括乘客用车信息的用车需求；根据所述用车需求生成订单并将所述订单下发给多个租户；多个租户各自筛选符合所述乘客用车信息的司机信息；聚合来自多个租户的通过筛选的司机信息；以及从所述通过筛选的司机信息中选择司机进行派单。本发明通过多租户筛选司机并上报，在聚合平台中完成针对多租户上报司机的选择和绑单，由此为乘客提供更为及时的用车体验并且能够为体量小的租户提供相对均等的接单机会。

根据本公开的第二个方面，提供了一种多租户网约车系统，包括：对接服务器，用于接收来自外部平台的用车需求；订单服务器，用于基于所述用车需求生成订单，并将所述订单下发给多个租户服务器；多租户调度服务器，用于从多个租户各自的司机调度池中筛选符合所述用车需求的司机信息；以及聚合服务器，用于聚合来自多个租户服务器的通过筛选的司机信息，并从所述通过筛选的司机信息中选择司机进行与所述乘客的司乘匹配。

由此，通过将主订单拆分为若干子订单以获取上报的司机并聚合选择，可以更好地给各租户进行派单，为各租户的成单量提供保障，也减少了因单租户运力不足导致乘客体验较差的情况。

附图说明

通过结合附图对本公开示例性实施方式进行更详细的描述，本公开的上述以及其它目的、特征和优势将变得更加明显，其中，在本公开示例性实施方式中，相同的参考标号通常代表相同部件。

图1示出了网约车云计算环境的示意图。

图2示出了一个多租户网约车系统的组成例。

图3示出了用于实施本发明一个实施例的云计算环境的示意图。

图4示出了根据本发明一个实施例的多租户派单方法的示意性流程图。

图5示出了本发明一个优选的多租户派单方法的例子。

具体实施方式

下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中显示了本公开的优选实施方式，然而应该理解，可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

网约车平台优选由SaaS平台实现。SaaS平台是运行SaaS软件的云平台。软件即服务(SaaS，Software-as-a-Service)向消费者(例如，作为租户的第三方厂商)提供技术服务接口或是直接的图形化操作界面，以使得消费者能够使用云基础设施上运行的各类应用。在不同的实现中，该应用可以通过诸如网络浏览器的客户端接口或是经由安装的专用APP的客户端进行访问。除了有限的特定于用户的应用配置设置的可能例外，消费者并不管理或控制包括网络、服务器、操作系统、存储、乃至个体应用能力的下层云基础设施。

“云”或者“云计算”可以看作一种服务交付模型，用于实现对可配置计算资源的共享且按需的访问。可配置计算资源能够以最小的管理成本或与服务提供者的最少交互而被快速供应和释放。

在基本配置完成之后，云的消费者无需与服务提供者进行人为交互就能够单方面自动地按需获取诸如服务器时间和网络存储等之类的计算能力。提供者的计算资源被池化，以使用多租户模型服务于多个消费者，并且根据需求动态地分配和再分配不同的物理和虚拟资源。消费者通常不能控制或不知晓所提供的资源的确切位置。另外，云基础设施还要具有扩展和缩减的能力，以满足消费者的升级(例如，服务升级)需求。进一步地，云系统可以利用适于服务类型(例如存储、处理、带宽和用户账户)的某个抽象层面上的计量能力，自动地控制和优化资源使用。可以监测、控制和报告资源使用，从而为被利用的服务的提供者和消费者双方提供透明度。

云计算环境是面向服务的，聚焦于无状态性、低耦合性、模块性和语意互操作性。云计算的核心是包含互连节点的网络的基础设施。云计算网络中的节点是计算装置，包括但不限于个人计算机系统、服务器计算机系统、移动客户端等。由于网约车服务的实时性，实现网约车服务系统的SaaS平台还需要具有高时效性，能够同时处理大量来自移动客户端的请求，例如，在下单派单场景中，将用户请求(用户订单)分配给恰当接单方(司机接单)的司乘匹配操作，即，为乘客发送的每个订单匹配一个合适的司机。

图1示出了用于实施本发明一个实施例的云计算环境的示意图。如图所示，云计算环境100包括一个或多个云节点110，由云消费者使用的客户端装置120，例如台式计算机120_1、可移动智能设备(智能电话)120_2、可移动智能设备(智能电话)120_3和车载计算系统120_4。客户端装置可以经由例如专门的应用、APP或是使用网络浏览器访问专门的URL地址来利用云平台100所提供的服务，例如与平台100中的一个或多个云节点110通信。如图所示，作为云平台100基础设施的计算节点110之间可以彼此通信，并且可以具有各种物理形态，例如具有与服务器和客户端计算机相同的属性，并且可以在一个或多个网络中被物理或虚拟地组成群(未示出)，由此允许云环境100作为SaaS平台提供服务。应该理解的是，图示的节点110及其连接方式仅仅是示意性的，用来表示云平台中包括的庞大节点和复杂结构。

云服务的消费者不需要在本地计算装置上为其保持资源。同样应当理解，在图1中示出的计算装置120的类型旨在仅是说明性的，并且计算节点110和云环境100可以通过任何类型的网络和/或可网络寻址的连接(例如，通过使用网络浏览器)与任何类型的计算机化的装置通信，如下图2所示，可以通过抽象的外部路由功能130实现通信。

在为多个租户提供网约车服务的网约车平台中，第三方厂商(即，租户)可以通过例如台式计算机120_1(或是诸如膝上型计算机等的其他相比于移动智能设备具有更强处理能力的终端)访问云服务提供方提供的技术服务接口(例如，经由网络浏览器访问特定地址)，以实现针对该租户的网约车服务的定制、运营和维护等操作。

利用上述网约车平台的用户，例如，下单的乘客和跑单的司机，则通常可以利用例如智能电话120_2和120_3上安装的专用网约车APP来获取平台提供的服务。为了方便说明，智能终端120_2可以指代网约车APP的乘客端，智能终端120_3则可以指代网约车APP的司机端。但应该了解的是，有些网约车APP可以在乘客模式和司机模式中切换，因此可以按照其当前所处模式来确定其属于乘客端120_2或是司机端120_3。

在现有技术中，乘客和司机通常使用智能电话上安装的APP进行下单和接单，但可以理解的是，随着个人交通工具的智能化和通信技术的发展，用于载客的车辆在现在或是将来，可以如图1的车载计算系统120_4所示，连入云平台100，以直接作为司机侧的客户端来进行跑单操作。

应该理解的是，虽然在图中仅示意性的示出了一个典型形态，但在实际使用场景中，会有多个第三方厂商通过多个终端120_1连入云平台，更会有海量的乘客端和司机端连入云平台。

在此，SaaS平台的“租户”指的是利用平台的存储和计算能力，自行运营出行品牌并维护客户的厂商。例如，云平台100可以同时为多个租户，例如图2所示的租户A-E(例如，AA出行、BB专车、CC约车、DD打车、EE用车)等租户提供出行服务，例如司乘匹配、司机和乘客数据存储等。在此，不同的租户可以开发不同的司机端和乘客端。例如，AA出行司机端、AA出行乘客端；BB专车司机端、BB专车乘客端；CC约车司机端、CC约车乘客端；DD打车司机端、DD打车乘客端；EE用车司机端、EE用车乘客端。用户可以根据需要，安装对应的APP。

尽管这些APP具有不同的名称，并且通常具有不同的页面布局与功能，但由于都使用了云平台100的服务，因此可以具有实质上相同或至少部分相同的服务，虽然这些服务可能具有不同的层级关系和外观。

为了实现SaaS的功能，需要庞大而复杂的物理系统实现。图2示出了一个多租户网约车系统的组成例。

如图所示，系统包括网约车平台100和客户端设备120。在此，网约车平台100可以对多个租户，例如租户A-E提供服务。这里的租户A-E可以是为用户提供网约车服务，并组织司机进行接单的不同的网约车运营实体。每个租户都可以发布自己的APP以方便乘客和司机的安装(同一租户的乘客和司机可以安装对应于不同身份的不同APP，或是在同一APP下选择司机或是乘客模式)。为此，租户A-E可以对应发布自己的APP 1-5。在此，图中示出的租户客户端120，例如租户客户端(租户A)可以指代安装了该租户(例如，租户A)发布APP的司机或是乘客客户端。

虽然租户A-E用户体感使用不同的网约车品牌和入口，但实际上租户A-E的业务数据可以是由同一个网约车平台100所支持的，并且租户A-E的业务和数据可能至少部分被共享处理和存储，但能够采用本发明的方案被动态隔离。

平台100同时利用多种数据部署和业务服务实现方式为租户提供服务。这种“混布”包括数据上的不同部署方式以及业务服务上的不同实现方式。如图所示，其中租户A和租户B租用了自己专用的机房300和400，即，其业务数据的存储以及业务数据的处理中的至少部分可以与其他租户物理隔离。租户C、D和E则选择在公共机房200内进行布置，即，其业务数据的存储以及业务数据的处理中的至少部分可以与其他租户共享物理资源。租户A-E各自的客户端120可以通过网络(例如，利用WiFi或是诸如4G、5G的移动网络)连接至网约车平台100，例如经由各自的网约车APP 1-5。平台100可以通过统一的外部调用路由130与客户端设备120进行通信。在此，不同于物理存在的机房200、300和400，外部调用路由130可以理解为由云平台100上的硬件和软件，例如网络接口装置和调度软件与规则等实现的虚拟功能。该外部调用路由130可以看作是平台100的访问入口，使得客户端设备120能够经由通信网络(例如，因特网)获取平台100所提供的服务，而无需知晓平台100内部的具体路由，例如，无需知晓其服务请求和应答在图1所示各个节点110中的具体路由，也不会知晓其对应租户在云平台100内的部署情况。

可以存在用于管理多租户数据的两种(也可细化为三种)部署选项。第一部署选项将租户数据存储在分离的数据库中，这是数据隔离的最简单方案。如前所述，租户A拥有自己独立的机房300，租户B也拥有自己独立的机房400，上述机房300和400可以与公共租户机房200物理上分开布置，例如，位于不同的数据中心、同一数据中心的不同区域内(例如，利用带锁隔笼等的物理服务器隔离)。在机房300和400内，租户A和B各自拥有其专用的数据库，如图2所示，独立部署租户A业务数据的设备320(例如，数据库320，也可称为独立数据存储设备320)，以及独立部署租户B业务数据的设备420(例如，数据库420，也可称为独立数据存储设备420)。物理上的隔离可以实现更高的安全性以及在用户数量庞大时更高的效率，但通常会导致服务提供者维护设备和备份租户数据的更高成本。硬件成本也比在备选部署选项下更高。

在公共租户机房200内，则可存在另一种部署，即在同一个数据库或设备(或物理硬盘)内混布。具体地，公共机房的混布还可以进一步地划分为两种部署。其中的一种部署是可以在同一个数据库中容纳多个租户，每个租户具有其自己的表格集以及集合到专门为该租户创建的模式中的其他数据库产物。尽管不如租户A和B的完全隔离系统，这种方案为有安全意识的租户提供中等程度的逻辑数据隔离，并且能够支持每个数据库服务器上的更大数量的租户。进一步地，还可以使用相同的数据库和相同的表格集来托管多个租户的数据。给定表格可以包括以任何次序存储的来自多个租户的记录，并且租户标识列将每个记录与适当的租户相关联。在这三个选项之中，共享模式方案具有最低的硬件和备份成本，这是因为其允许每个数据库服务器服务于最大数量的租户。

租户C、D和E可以自行选择在公共租户机房内的具体混布方式(例如，涉及不同价格的独立表格布置或是表格混布)，也可以平台提供方根据系统运营的需要来自行选择混布方式。无论是独立表格布置还是表格混合布置，都可以利用标识来区分各个租户。在图2中，可以利用部署了业务数据的设备220(例如，数据库220，也可称为公共数据存储设备220)来布置租户C、D和E的相关业务数据。例如，租户C当前可以选择上述独立表格的公共机房部署。租户D和E以及图中未示出的其他小型客户则可在相同的数据表中存储业务数据，并利用租户标识加以区分。

在图2的例示中，除了数据的隔离方式不同之外，租户A-E之间可以具有不同的业务部署方式(即，网约车服务的提供方式)。布置在公共租户机房200的租户C、D和E优选选择集群集中部署，即，利用共享的应用服务器来提供共享的服务。上述共享的应用服务器可由图2所示的提供租户业务服务的设备210(例如，应用服务器210，也可称为公共应用服务器210)来提供。

换句话说，虽然租户C、D和E的用户可以利用各自安装的不同的网约车APP(例如，APP 3、APP 4和APP 5)或是导航APP上的不同入口来进行叫车和跑单操作，但是这些来自不同APP的操作可以在相同的服务器上运营。另外，虽然在实现成本和效率上不占优势，但是租户C、D和E也可以使用独立布置的应用服务器来进行相关业务的操作，即来自不同APP的操作可以在不同的服务器上运营。对于使用独立机房存储数据的租户A和B而言，可以优选利用独立部署的服务器，例如图示的用于实施租户A业务服务的设备310以及用于实施租户B业务服务的设备410分别来为租户A和租户B各自的客户端设备120(例如，分别安装了APP1和APP 2的客户端)提供服务，或是至少利用独立布置的应用服务器310和410(也可称为独立应用服务器310和410)来提供部分服务。

在更为广泛的实施例中，在各自机房的独立应用服务器310和410通常无法完全独立地完成其对应客户端设备120所请求的全部功能，而是需要与位于公共租户机房200内的公共应用服务器210进行交互，上述交互可以利用业务调用路由140实现。与外部调用路由130类似，业务调用路由140是在云环境100中的软硬件协同操作的基础上，跨机房或是跨服务器进行业务调用的虚拟功能。虽然图2中示出了位于各自独立机房内的应用服务器310和410，但在其他实现中，独立数据布置的租户A和租户B也可以利用集群布置的业务服务，例如，利用公共机房内的应用服务器210进行操作。如下将详述的，为了提供业务部署的灵活性，可以采用微服务方式对业务进行拆分，使得单一业务应用变得足够精简和集中。进一步地，业务本身可以不对租户加以区分，具有处理全部租户请求的能力，并且部署于若干物理集群，从而可以同时应对例如来自不同租户的请求，或是用作系统的冗余备份。

为了应对业务请求所需访问各类数据，本发明的云平台100还可以在应用服务器与数据库之间添加数据调用路由150。与路由130和140类似，数据调用路由150同样可以看作是在云环境100中的软硬件协同操作的基础上，跨机房或是跨物理数据存储设备进行数据调用的虚拟功能。

如图所示，除了存储业务数据之外，系统数据还可以包括基础数据。这些SaaS基础数据可以集中存储于单独的物理存储中，例如位于公共机房200的基础SaaS数据存储设备(即，元数据数据库，也可称为公共基础数据存储设备230)。基础数据主要包括SaaS级别的管理数据与元数据，用于提供全局中心化服务，例如，可以在元数据数据库内存储租户标识信息、系统策略和任何其他相关信息。

在图2所示的例子中，当租户A和B利用云平台为其客户提供服务时，仍然需要访问公共租户机房200内的元数据数据库230。在其他实施例中，独立租户的机房也可以包括独立基础数据存储设备，用于存储为各自对应的独立租户提供服务所需的系统元数据和管理数据。换句话说，SaaS基础数据及服务同样可以不共享，并采用冗余存储。这样整体部署更为简单，但一致性处理成本会有所提高。

虽然租户C、D、E存在一定程度的数据混布，但是与独立布置的租户A和B类似，各个租户的司乘匹配操作是彼此隔离并独立进行的。在此，“司乘匹配”是指在网约车场景中，将乘客订单分配给恰当司机的匹配操作。在实际的匹配过程中，优选采取全局最优策略。全局最优策略通常同时涉及n个订单，并找到m个备选司机(例如，属于同一区域的n个订单和m个备选司机)。随后可以通过综合计算，选出q对(q取n和m中较小者)订单司机组合。这些组合从单个组合来看，可能并不是全局最优的。但从整体看，这些组合达到的匹配效果最好。

在一些优选实施例中，系统会为每个租户分配独立的服务器来进行各自的司乘匹配计算。例如，系统将30台服务器划分作为司乘匹配服务器，其中第1-10台服务器划分给租户A，第11-20台划分给租户B，第21-25台划分给租户C，第26-28台划分给租户D，第29-30台划分给租户E。更为优选地，系统可以根据实时流量，为各个租户动态分配司乘匹配服务器。

在其他实施例中，可能会存在在同一服务器上为不同租户进行司乘分配操作的情形。但应该理解的是，哪怕在此种场景中，不同租户间的计算仍然是彼此隔离的，因此仍然可以认为各个租户是在各自的调度池里进行独立的调配。换句话说，当用户使用CC约车的乘客端APP(对应于APP3)发出用车请求时，该订单只会在CC约车的调度池中被计算(例如，加入司乘匹配运算)，而不可能出现在其他租户的调度池中。在CC约车在当前区域运力不足时，这样会导致绑单不及时并降低用户体验。

在现有场景中，乘客除了使用专门的网约车APP(例如，CC约车的乘客端APP)进行叫车服务之外，更多地会从其他渠道进行叫车服务。例如，用户可以利用地图APP进行线路查询，并使用地图APP所包含的叫车服务来实现约车出行。而地图服务平台通常不包括提供司乘服务的能力，为此，地图平台可以对接网约车平台，并将用户的乘车请求提供给网约车平台，以实现司乘匹配和后续的派单。

图3示出了用于实施本发明一个实施例的云计算环境的示意图。如图所示，提供网约车服务的云平台100除了连接租户以及租户的客户端(120_1～120_4)之外，还可以对接其他的云平台，例如图中示出的云平台2000和3000。

在一个实施例中，云平台2000可以是地图服务平台，例如GG地图平台。用户可以通过在智能终端(例如，手机)中安装GG地图APP(例如，图示的客户端2010)来与云平台200交互，从而获取导航、地址查询等服务。应该理解的是，虽然为了简明仅示出一个客户端2010，但在实际场景中，会有成千上万甚至更多的客户端2010与地图平台2000相连接，以获取请求的地图服务。由于用户在进行路线查询之后，往往存在叫车出行的需要，因此GG地图APP中内嵌了叫车功能。例如，用户可以在叫车页面下进行路线查询，并获取网约车厂商(往往不止一家，例如可以对应于平台的多个租户)的预估报价。用户可以点选其中的一家或多家进行叫车，并在叫车成功后，直接在GG地图APP中与匹配的司机端进行交互，例如，进行即时通信、呼叫司机(需要跳转至外部通话应用)和支付车费等操作。

由于云平台2000(例如，地图服务平台)无法提供司乘服务，因此在接收到来自客户端2010的叫车请求后，需要与网约车云平台100交互。具体地，云平台2000可以将用户的叫车请求发送给平台100，由平台100根据用户选择的网约车厂商(例如，用户选择了AA出行和BB专车)进行司乘匹配，并且在有车辆符合要求时，生成订单，并将订单信息发送给司机端(例如，BB专车的某个司机的司机端)，并经由平台200转发给客户端210。

类似地，云平台3000也可以是与平台100对接以获取其网约车服务的平台，例如可以是同城服务平台或是旅游服务平台。云平台的客户端3010也可以在其使用平台300的服务时，顺势发起叫车请求。例如，旅游平台300可以为用户提供接送机服务，用户预定了例如从XX机场到XX宾馆的接机服务。由于平台3000本身无法提供司乘服务，因此需要将用户的用车请求发送给平台100，由平台100根据用户选择和/或平台3000选择的网约车厂商(例如，所有在目的地城市能够提供服务的租户)进行司乘匹配，并且在有车辆符合要求时，进行绑单，并将相关信息发送给司机端(例如，AA出行的某个司机的司机端)，并经由平台3000转发给客户端3010。

由上可知，来自外部平台的用车请求往往会默认或是主动勾选多个网约车厂商。换句话说，使用GG地图客户端2010叫车的用户可能并不在乎是乘坐租户A-E中哪一个的网约车出行，只要能够及时出行即可。针对此种情况，本发明提出了一种基于多租户的派单方案，该方案能够在多个租户的司机中进行全局性地司机选择，从而为乘客提供更优的司机匹配，并且避免各个网约车厂商在自己的调度池内分散进行司机选择，

图4示出了根据本发明一个实施例的多租户派单方法的示意性流程图。该方法可由网约车平台100执行。

在步骤S410，接收包括乘客用车信息的用车需求。如图3所示，平台100可以为外部聚合平台2000和3000提供接口，以方便外部平台的用户向各自所属的平台提出用车请求。

例如，用户可以用GG地图APP查询路线，并且通过点击“打车”频道来获取经查询路线的打车信息。由于GG地图所在的出行平台2000跟网约车平台100存在合作关系，并且知晓各个租户的计费规则，因此平台2000根据计费规则预估可以提供出车服务的多个租户(有时也可以包括平台100支持的租户以外的出行厂商，例如出租车等)的各种级别的车型(例如，普通车型、舒适车型、7座车型、豪华车型等)的报价，并在GG地图APP的“打车”页面显示给用户，用户可以默认选择部分车型(或是主动勾选部分车型，或是取消部分车型的勾选)，并点击“呼叫”按钮。由此平台2000获取包括用户的用车需求，该用车需求中包括用车起止点、时间(当前或是预约)、所选租户(甚至具体租户的具体车型)等的乘客用车信息，并且可以将该用车需求提供给平台100。在此种情况下，乘客用车信息中已经规定了(即，由外部平台用户选择了)能够提供用车服务的租户(及其特定车型)。

再例如，用户可以使用XX旅游APP，利用平台3000提供的服务来预订机票，并且点选了XX旅游APP在机票预订成功页面上显示的“接送机”按钮，并进入相应的预订平台。类似地，云平台3000也可以是与平台100对接以获取其网约车服务的平台，例如可以是同城服务平台或是旅游服务平台。云平台的客户端3010也可以在其使用平台300的服务时，顺势发起叫车请求。例如，旅游平台300可以为用户提供接送机服务，用户预定了例如X月X日XXXX次航班的从XX机场到XX宾馆的接机服务。由于平台3000本身无法提供司乘服务，因此需要将用户的用车请求发送给平台100。此时的用车需求同样可以包括用车起止点和时间(当前或是预约)，但是可以不包括租户信息。用户例如可以只在订车的时候选择车型(例如，轿车或是7座车)并且接收相应区间范围的报价。在此种情况下，乘客用车信息中并未规定了具体租户，但平台100可以根据用户设置的条件信息(例如，乘客用车信息中包括的价格条件和车型条件)来自行确定租户。

当平台100接收到如上所述的用车需求(通常来自外部平台)之后，则可在步骤S420，根据用车需求(特别是其内包含的乘客用车信息)生成订单，并将所述订单下发给多个租户。

虽然生成的订单可以是在外部聚合用车需求门类下的非全局订单(例如，仅在外部聚合用车需求门类下具有唯一订单号)，但在优选实施例中，为该外部用车需求生成的订单可以具有全局唯一订单号，由此方便系统的迁移和维护。例如，可以首先生成具有全局唯一订单号的主订单，再将所述订单拆分成多个子订单，以分别下发给所述多个租户中的一个。子订单可以具有与主订单相同的全局唯一订单号，但同时带有子订单标记，例如在主订单订单号后加上一位附加位，用来标记子订单以及租户身份。进一步地，当前租户的子订单与其它租户互不影响，子订单内的信息可以与主订单一致(除了表明子订单身份的标记之外)。

在此，获得子订单的多个租户可以是所述乘客用车信息中包含的租户，例如由外部平台的客户端210的用户主动或默认选择的租户；也是网约车平台选择的租户，例如，基于网约车平台100与旅游平台3000的合作协议，由网约车平台100挑选租户及司机并向平台3000的客户端310发送。在后一种情况下，客户端310在下单约车时可以同时包括一些约束条件，比如车型和预估费用范围，平台100则可根据这些约束条件进行租户(和车型挑选)。

在租户收到订单之后(例如，所述多个租户被各自分配了子订单之后)，在步骤S430，多个租户各自筛选符合所述乘客用车信息的司机信息。具体地，每个租户可以根据乘客用车信息中的指定信息(例如，指定AA出行的经济型和舒适型车型，而没有选择豪华或是七座车型)来对在其名下注册且当前在线接单的司机进行筛选，例如，AA出行的筛选服务器可以选择用户上车点一定范围内的经济型和舒适型的司机。每个租户也可以根据乘客用车信息的预估价格选择对应车型，或是根据乘客用车信息中的附加条件进行筛选，例如，只选择五星司机等等。

除了基于所述乘客用车信息进行筛选之外，多个租户(中的任意租户)还根据各自的调度策略筛选属于该租户的司机信息。例如，某些租户在高峰时期优先满足本租户APP乘客的用车需求，因此在高峰时期或是热门地段，选择不向或是少向外部用户(例如，客户端210和310)提供用车服务。再例如，CC约车以B城市为其品牌服务关键城市并且具有大量司机配置。这些司机可以分为核心车队司机和普通司机。CC约车可以在自身订单繁忙时段不上报核心车队司机信息(以使其服务CC约车APP用户)，也可以在空闲时段优先上报核心车队司机信息(以使核心司机能够接到更多的订单)。

多个租户筛选出司机信息之后，可以上报这些司机信息。平台100可以包括用于外部聚合订单场景的专用聚合平台，并由该聚合平台在步骤S440聚合来自多个租户的通过筛选的司机信息，并且在步骤S450从所述通过筛选的司机信息中选择司机进行派单。在某一地区同一时段同时存在大量外部用车需求的情况下，可以进行n个司机和m个乘客的全局最优司乘匹配。但在优选实施例中，可以不进行如上的司乘匹配计算，而直接为所述乘客从通过筛选的n个司机中选择最为匹配的一个司机，例如，距上车点最近的司机或是距上车点行驶时间最短的司机。

由此，通过聚合来自多个租户的司机信息并进行绑单，能够为乘客的用车需求提供最佳的解决方案。另外，相比于多个租户各自进行订单匹配运算，本发明的聚合匹配运算具有更高的效率，不影响各租户内部正常的司乘匹配，并且可以对来自各个租户的司机提供相同的被选机会(即，租户接单机会均等)，避免小体量租户无单可接的情形。

在选出最合适的司机之后，可以将匹配信息发送给匹配司机所属的租户和订单来源方，例如，将订单信息(此时不仅包括乘客用车信息，还包括匹配的司机相关信息，例如，车牌号、当前位置、司机星级等)发送给下单的平台2000的客户端210，以及该司机所属例如BB专车的服务器(即，租户B的服务器)，并由租户B的服务器转发给该司机的司机端APP。同时，可以通知匹配司机所属租户之外的其他租户关闭下发的子订单。

在匹配司机取消接单时，还可以重新从所述通过筛选的司机信息中选择司机进行与所述乘客的司乘匹配。例如，从在前上报的n个司机中，再选出一个合适的司机进行匹配。换句话说，可以进行全局改派，并同时相应的乘客和司机。由于存在司机取消订单并全局改派的可能性，因此其他租户可以推迟关闭各自子订单的时间，例如，在乘客开始乘车之后，其他租户再关闭各自子订单。

而在乘客取消时，则直接关闭订单，例如关闭主订单和所有子订单。

由此，本发明提供了一种基于多租户的网约车的订单分配、司机筛选、向上交付和全局改派的方法。订单分配包括：乘客通过聚合平台发单到订单服务，订单服务将主订单拆给各租户。司机筛选包括：从各个租户的运力池中根据调度策略筛选司机的基本信息、司机状态、车辆的基本信息、车辆状态等。向上交付包括：调度服务将符合条件的司机筛选出来后，向上交付到聚合平台进行最终绑单，如果此时司机取消则进行全局改派，乘客取消则订单关闭。

由此，本发明能够解决单个租户因运力不足导致绑单不及时，致使乘客体验较差的问题，并且由于租户接单机会均等，由此能够避免小体量租户无单的情况。

图5示出了本发明一个优选地多租户派单方法的例子。

首先，外部平台乘客下单，由此发送至平台100的订单服务。

随后，订单服务生成主订单并进行拆单。

于是，子订单被发送到基于多租户的调度服务。

随后，调度服务根据各种调度策略，从每个租户各自的调度池中筛选合适的司机。

随后，调度服务向上交付司机信息给聚合平台，司机信息可以包括手机号码、司机星级、司机ID、司机头像、司机姓名等。

随后，聚合平台从上报的司机中选择唯一的司机进行绑单，并绑定订单成功后，通知订单服务，订单关闭其他订单。

如果乘客取消订单，通知到订单服务，订单服务通知司机订单关闭。

如果司机取消订单，订单服务可以进行全局改派，并通知聚合平台，由此通知外部平台的乘客。

进一步地，本发明还可以实现为一种多租户网约车系统，该系统可以看作是图1-3所示系统100的一个能够实现本发明的具体服务器配置例。

该系统可以包括：对接服务器，用于接收来自外部平台的用车需求；订单服务器，用于基于所述用车需求生成订单，并将所述订单下发给多个租户服务器；多租户调度服务器，用于从多个租户各自的司机调度池中筛选符合所述用车需求的司机信息；以及聚合服务器，用于聚合来自多个租户服务器的通过筛选的司机信息，并从所述通过筛选的司机信息中选择司机进行与所述乘客的司乘匹配。

在一个实施例中，所述订单服务器用于：为用车需求生成具有全局唯一订单号的主订单，并将所述订单拆分成N个子订单，以分别下发给N个租户中的一个。

所述订单服务器也为租户内部提供订单服务，并且可以为多个租户各自的租户内部订单也生成具有全局唯一订单号的订单。由此提升平台100整体的鲁棒性和数据可迁移性。

多租户调度服务器可以是多个调度服务器，不同的服务器分别为不同的租户提供彼此独立的调度服务，也可以是(或是至少部分是)同一个调度服务器，用于彼此隔离地为多个租户提供调度服务。所述多租户调度服务器还可以用于：根据多个租户各自的调度策略筛选属于该租户的且符合所述乘客用车信息的司机信息。

该系统还包括：司乘匹配服务器，用于对租户内部的司乘需求进行匹配，其中，所述司乘匹配服务器与所述聚合服务器进行通信以避免对同一司机进行匹配。例如，当某一司机在租户内或是聚合平台上与某一个乘客订单进行绑单，则立即通知另一平台停止对该司机的匹配操作。

在一个实施例中，所述聚合服务器用于：将匹配信息发送给匹配司机所属的租户服务器和订单来源方；以及通知匹配司机所属租户之外的其他租户服务器关闭下发的子订单。

在一个实施例中，所述聚合服务器用于：在匹配司机取消订单时，重新从所述通过筛选的司机信息中选择司机进行与所乘客的司乘匹配；和/或为所述乘客从通过筛选的n个司机中选择最为匹配的一个司机。

上文中已经参考附图详细描述了根据本发明的基于多租户的派单、司机筛选、向上交付和全局绑单(以及全局改派)的方案。由此，本发明通过将主订单拆分为若干子订单以获取上报的司机并聚合选择，可以更好地给各租户进行派单，为各租户的成单量提供保障，也减少了因单租户运力不足导致乘客体验较差的情况。

此外，根据本发明的方法还可以实现为一种计算机程序或计算机程序产品，该计算机程序或计算机程序产品包括用于执行本发明的上述方法中限定的上述各步骤的计算机程序代码指令。

或者，本发明还可以实施为一种非暂时性机器可读存储介质(或计算机可读存储介质、或机器可读存储介质)，其上存储有可执行代码(或计算机程序、或计算机指令代码)，当所述可执行代码(或计算机程序、或计算机指令代码)被电子设备(或计算设备、服务器等)的处理器执行时，使所述处理器执行根据本发明的上述方法的各个步骤。

本领域技术人员还将明白的是，结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。

附图中的流程图和框图显示了根据本发明的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上已经描述了本发明的各实施例，上述说明是示例性的，并非穷尽性的，并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (15)

1.一种多租户派单方法，包括：

接收包括乘客用车信息的用车需求；

根据所述用车需求生成订单并将所述订单下发给多个租户；

多个租户各自筛选符合所述乘客用车信息的司机信息；

聚合来自多个租户的通过筛选的司机信息；以及

从所述通过筛选的司机信息中选择司机进行派单。

2.如权利要求1所述的方法，其中，生成的订单是包括全局唯一订单号的主订单，并且

将所述订单下发给多个租户包括：

将所述订单拆分成多个子订单，以分别下发给所述多个租户中的一个。

3.如权利要求2所述的方法，其中，获得子订单的多个租户是所述乘客用车信息中包含的租户；和/或

获得子订单的多个租户是网约车平台选择的租户。

4.如权利要求2所述的方法，还包括：

将匹配信息发送给匹配司机所属的租户和订单来源方；以及

通知匹配司机所属租户之外的其他租户关闭下发的子订单。

5.如权利要求1所述的方法，其中，多个租户各自筛选符合所述乘客用车信息的司机信息包括：

多个租户还根据各自的调度策略筛选属于该租户的且符合所述乘客用车信息的司机信息。

6.如权利要求1所述的方法，还包括：

在匹配司机取消接单时，重新从所述通过筛选的司机信息中选择司机进行与所述乘客的司乘匹配。

7.如权利要求1所述的方法，其中，接收包括乘客用车信息的用车需求：

从外部平台接收外部平台用户的用车请求。

8.如权利要求1所述的方法，其中，从所述通过筛选的司机信息中选择司机进行与所述乘客的司乘匹配包括：

为所述乘客从通过筛选的多个司机中选择最为匹配的一个司机。

9.一种多租户网约车系统，包括：

对接服务器，用于接收来自外部平台的用车需求；

订单服务器，用于基于所述用车需求生成订单，并将所述订单下发给多个租户服务器；

多租户调度服务器，用于从多个租户各自的司机调度池中筛选符合所述用车需求的司机信息；以及

聚合服务器，用于聚合来自多个租户服务器的通过筛选的司机信息，并从所述通过筛选的司机信息中选择司机进行与所述乘客的司乘匹配。

10.如权利要求9所述的系统，其中，所述订单服务器用于：为用车需求生成具有全局唯一订单号的主订单，并将所述订单拆分成多个子订单，以分别下发给多个租户中的一个。

11.如权利要求10所述的系统，其中，所述订单服务器用于：

为多个租户各自的租户内部订单也生成具有全局唯一订单号的订单。

12.如权利要求9所述的系统，还包括：

司乘匹配服务器，用于对租户内部的司乘需求进行匹配，

其中，所述司乘匹配服务器与所述聚合服务器进行通信以避免对同一司机进行匹配。

13.如权利要求9所述的系统，其中，所述聚合服务器用于：

将匹配信息发送给匹配司机所属的租户服务器和订单来源方；以及

通知匹配司机所属租户之外的其他租户服务器关闭下发的子订单。

14.如权利要求9所述的系统，其中，所述多租户调度服务器用于：

根据多个租户各自的调度策略筛选属于该租户的且符合所述乘客用车信息的司机信息。

15.如权利要求9所述的系统，其中，所述聚合服务器用于：

在匹配司机取消订单时，重新从所述通过筛选的司机信息中选择司机进行与所述乘客的司乘匹配；和/或

为所述乘客从通过筛选的多个司机中选择最为匹配的一个司机。

Images