CN109088934A - 一种业务处理系统及业务处理方法 - Google Patents

Abstract

本申请实施例提供了一种业务处理系统及业务处理方法，用于提高对业务请求的并发处理量，同时实现业务处理系统结构的灵活扩展和重构。本申请中的业务处理系统包括：智能交互设备、用户终端、业务服务器及运维服务器，其中，所述业务服务器包括多个业务模块，每个业务模块对应部署一个微服务，所述业务服务器采用分布式微服务架构，或，分布式微服务和集群式部署的架构。

Description

一种业务处理系统及业务处理方法

技术领域

本申请涉及智能设备的汽车通信技术领域，尤其涉及一种业务处理系统及业务处理方法。

背景技术

随着网络技术和智能设备的发展，越来越多的智能设备都可以接入网络，以实现各智能设备之间的相互通信及对智能设备的远程管理。

根据中国物联网的定义，车联网是由车辆位置、速度和路线等信息构成的巨大交互网络，通过GPS、RFID、传感器、摄像头等图像处理装置，车辆的OBD诊断装置可以完成自身环境和状态信息的采集，并通过互联网技术，所有车辆可以将自身的各种信息传输汇聚到中央处理器，通过中央处理器将各种信息进行分析和处理。

而现有的车联网的处理器大多采用集群式部署的策略，而这种集群式部署策略在应对处理请求时，存在以下的缺点：

1、在面对数据请求量暴增带来的高并发、负载均衡问题时，如果集群节点中某个节点的服务器宕机则会给其他节点服务器带来不必要的负载压力，甚至导致访问堵车的问题，即使服务器不宕机也会因为并发问题导致服务器性能变差，用户体验不好；

2、现有整个服务器架构体系导致各业务模块功能之间的耦合度太高，很难做到对现有业务进行扩展、重构，相对于分布式微服务的系统架构显得臃肿、低效、维护成本较高。

申请内容

本申请实施例提供了一种业务处理系统及业务处理方法，通过对业务服务器采用分布式微服务架构，或分布式微服务和集群式部署架构，以实现对业务请求量的并发处理，及对服务器架构的灵活扩展和重构。

本申请实施例第一方面提供了一种业务处理系统，该业务处理系统包括智能交互设备、用户终端、业务服务器及运维服务器，其中，所述业务服务器包括多个业务模块，每个业务模块对应部署一个微服务，所述业务服务器采用分布式微服务架构，或，分布式微服务和集群式部署的架构。

优选的，所述业务处理系统还包括：用户信息服务器，所述用户信息服务器采用分布式微服务和/或集群式部署的架构。

优选的，所述业务处理系统还包括：校验服务器，所述校验服务器包括本地物理服务器或云服务器，所述智能交互设备内置加密芯片。

优选的，所述业务服务器包括主机和备用机，且所述主机上分布式部署多个微服务。

优选的，所述运维服务器对每个微服务的并发访问量进行统计，当所述运维服务器监测到任一个微服务的并发访问量大于预设的阈值时，则启用所述备用机，并在所述备用机上集群式部署对应的微服务，使得所述业务服务器由所述分布式微服务架构扩展为所述分布式微服务和集群式部署的架构。

本申请实施例第二方面提供了一种业务处理方法，应用于业务服务器，该业务服务器包括多个业务模块，每个业务模块对应部署一个微服务，该业务服务器采用分布式微服务架构，或，分布式微服务和集群式部署的架构，所述方法包括：

所述业务服务器分别建立与用户终端、运维服务器及智能交互设备的通信连接；

所述业务服务器的微服务接收所述用户终端发送的业务请求；

所述业务服务器的微服务将所述业务请求发送至所述智能交互设备；

所述业务服务器的微服务接收所述智能交互设备的业务响应，并将所述业务响应发送至所述用户终端；

所述业务服务器根据所述运维服务器监测到的微服务的并发访问量，在监测到所述并发访问量大于预设的阈值时，使得所述业务服务器由所述分布式微服务架构扩展为所述分布式微服务和集群式部署的架构。

优选的，在所述将所述业务响应发送至所述用户终端之前，所述方法还包括：

所述业务服务器的微服务根据所述业务请求，向所述用户信息服务器发送校验请求；

若校验通过，则触发将所述业务响应发送至用户终端的步骤。

优选的，若所述业务请求为密令业务请求，在所述将所述业务响应发送至所述用户终端之前，所述方法还包括：

所述业务服务器的微服务将所述密令业务请求发送至校验服务器进行解密校验；

若校验通过，则触发将所述业务响应发送至用户终端的步骤。

本申请第三方面提供了一种业务服务器，该业务服务器包括：

处理器；

及存储器，用于存储处理器的可执行指令；

其中，该处理器执行存储器上的可执行指令时，用于实现本申请实施例第二方面提供的业务处理方法。

本申请实施例第四方面提供了一种业务处理方法，应用于本申请实施例第一方面提供的业务处理系统，所述业务处理系统包括智能交互设备、用户终端、业务服务器及运维服务器，其中，所述业务服务器包括多个业务模块，每个业务模块对应部署一个微服务，所述业务服务器采用分布式微服务架构，或，分布式微服务和集群式部署的架构，该方法包括：

用户终端建立与所述智能交互设备及所述业务服务器之间通信连接；

用户终端将业务服务器的路由参数发送至所述智能交互设备，使得所述智能交互设备建立与所述业务服务器之间的通信连接；

用户终端向所述业务服务器的微服务发送业务请求；

业务服务器的微服务将所述业务请求发送至所述智能交互设备；

业务服务器的微服务接收所述智能交互设备的业务响应，并将所述业务响应发送至所述用户终端；

运维服务器在监测到所述业务服务器的每个微服务访问并发量大于预设的阈值时，使得所述业务服务器由分布式微服务架构扩展为分布式微服务和集群式部署的架构。

从以上技术方案可以看出，本申请实施例具有以下优点：

本申请实施例中，业务处理系统中的业务服务器可以采用分布式微服务，或分布式微服务和集群式部署的架构，不仅提升了业务服务器对业务请求的并发处理度，也可以在微服务的访问并发量较大时，灵活实现业务服务器的扩展和重构。

附图说明

图1为业务处理系统中各装置及各装置连接关系的一个实施例示意图；

图2为业务处理方法的一个实施例示意图；

图3为业务处理系统中各装置及各装置连接关系的另一个实施例示意图；

图4为业务处理方法的另一个实施例示意图；

图5为业务处理方法的另一个实施例示意图；

图6为业务处理方法的另一个实施例示意图。

具体实施方式

本申请实施例提供了一种业务处理系统及业务处理方法，包括智能交互设备、用户终端、业务服务器和运维服务器，其中，通过对业务服务器采用分布式微服务架构，或分布式微服务和集群式部署架构，实现了对业务请求的并发处理，及对业务服务器架构的灵活扩展和重构。

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

现有的车联网中，对车辆请求数据进行处理的业务服务器大多采用集群化部署的方式，即在一个业务服务器上，或同一个节点上部署所有的业务模块，这样很容易导致该节点宕机时，所有的业务请求都无法处理，而引起业务瘫痪的问题；同时，若在同一个节点上部署所有的业务模块，容易导致各业务模块之间的耦合度过高，限制业务请求的处理速度，且在扩展服务器架构时，需要在新的节点上同样部署所有的业务模块，难以避免因各业务模块之间耦合度高，从而限制处理速度的问题。

基于现有车联网中存在的各种问题，本申请实施例提出了一种业务处理系统，用于对业务服务器采用分布式微服务架构，或分布式微服务和集群式部署的架构，以减少业务服务器中各个微服务之间的耦合度，提升数据请求的并发处理度，同时在业务请求量过大时，将业务服务器的分布式微服务架构扩展为分布式微服务和集群式部署的架构，实现对业务服务器架构的灵活扩展。

为便于理解，下面对本申请实施例中的业务处理系统进行描述，请参阅图1，本申请实施例中业务处理系统的一个实施例，包括:

本申请实施例中业务处理系统，包括：智能交互设备，用户终端、业务服务器和运维服务器，其中，所述业务服务器包括多个业务模块，每个业务模块对应部署一个微服务，业务服务器采用分布式微服务架构，或分布式微服务和集群式部署的架构，以实现对业务请求的并发处理，及对业务服务器架构的灵活扩展和重构。

下面以交互的方式对本申请实施例中业务处理系统中各装置的作用进行描述，请参阅图2，本申请实施例中的业务处理方法的一个实施例，包括：

201、用户终端与智能交互设备和业务服务器建立通信连接；

现有的各智能设备之间一般都可以通过网络模块之间实现通信连接，如可以在智能交互设备中内置蓝牙、WiFi模块、NFC模块，实现与用户终端之间的通信连接，而本实施例中的用户终端可以是电脑、平板、智能手机或可穿戴式设备中的任一种，也可以是电脑、平板、智能手机或可穿戴式设备中所安装的APP或小程序。

实际使用中，为了避免投入更多的生产成本，即避免给智能交互设备设置处理器，可以通过开发应用程序，即开发APP或小程序，实现智能交互设备与用户终端之间的通信连接，并通过用户终端的处理器实现与业务服务器之间的数据通信及数据处理。

202、用户终端将业务服务器的路由参数发送至智能交互设备，使得智能交互设备建立与业务服务器的通信连接；

具体的，智能交互设备可以内置WiFi模块和蓝牙模块，当用户终端分别与业务服务器和智能交互设备建立通信连接时，用户终端可以将业务服务器的路由参数通过蓝牙模块发送至智能交互设备，使得智能交互设备通过内置的WiFi模块与业务服务器建立通信连接，方便业务服务器对智能交互设备状态的实时监测与查询。

203、用户终端向业务服务器发送业务请求；

当用户终端分别与智能交互设备及业务服务器建立通信连接后，用户终端(如用户终端中安装的智能交互设备的APP)可以根据具体的需求向业务服务器发送业务请求，而业务服务器则在接收到该业务请求后，向用户终端发送业务响应。

具体的，本实施例中的智能交互设备包括但不限于智能诊断设备，如汽车的OBD诊断系统，当用户终端想要获取被诊断车辆的当前运行状态时，可以向业务服务器发送车辆运行状态获取请求，而业务服务器将该获取请求发送至汽车的OBD诊断系统，使得汽车的OBD诊断系统根据该获取请求，将被诊断车辆的当前运行状态信息，如胎压、发动机的当前温度、油量等，发送至业务服务器，而业务服务器在接收到被诊断车辆的当前运行状态信息后，将该车辆的当前运行状态信息发送至用户终端。

需要说明的是，本实施例中的业务服务器采用分布式微服务架构，即本实施例中的业务服务器可以包括一个主机和备用机，也可以包括多个主机和备用机，且主机上分布式部署多个微服务。同时业务服务器包括多个业务模块，且每个业务模块都以微服务的形式在主机上进行部署，且各微服务之间可以通过API接口进行调用，从而减少了各微服务之间的耦合度，提高了业务微服务器对业务请求处理能力的并发度。

进一步，当智能诊断设备用在车辆诊断技术领域时，可以是车辆内置的诊断系统，如车载OBD系统，也可以是外置的独立诊断装置，此处对智能诊断设备的表现形式不做具体限制。

204、业务服务器接收业务请求，并将该业务请求发送至智能交互设备，使得智能交互设备根据该业务请求，向业务服务器发送业务响应。

业务服务器接收到用户终端发送的业务请求后，将该业务请求发送至智能交互设备，使得智能交互设备根据该业务请求，向业务服务器发送业务响应。

如：用户终端向业务服务器发送获取当前车辆运行状态的业务请求后，业务服务器接收到该业务请求，并将该业务请求发送至智能交互设备(车辆诊断设备)，使得智能交互设备(车辆诊断设备)根据该业务请求，获取被诊断车辆的当前运行状态信息，并在获取到被诊断车辆的当前运行状态信息后，将被诊断车辆的当前运行状态信息发送至业务服务器。

205、业务服务器接收业务响应，并将业务响应发送至用户终端。

当业务服务器接收到智能交互设备发送的业务响应后，进一步将该业务响应发送至用户终端，使得用户终端进行查看。

具体的，如当业务服务器接收到智能交互设备(车辆诊断设备)发送的被诊断车辆的运行状态信息后，进一步将被诊断车辆的运行状态信息发送至用户终端，使得用户进行查看。

206、运维服务器对每个微服务的并发访问量进行统计，当运维服务器监测到任一个微服务的并发访问量大于预设的阈值时，启用备用机，并在备用机上集群式部署对应的微服务，使得业务服务器由分布式微服务架构扩展为分布式微服务和集群式部署架构。

区别于现有技术的是，本实施例中的运维服务器对业务服务器中每个微服务器的并发访问量进行统计，当运维服务器监测到任一个微服务的并发访问量大于预设的阈值时，启用备用机，并在备用机上集群式部署对应的微服务，使得业务服务器采用分布式微服务和集群式部署的架构。

实际应用场景中，每个微服务可以对应相同或不同的并发访问阈值，此处不做具体限制，如当车辆运行状态获取服务的并发访问量大于预设的阈值时，运维服务器则启用业务服务器中的备用机，并在备用机上集群式部署车辆运行状态获取服务，使得本实施例中的业务服务器采用分布式微服务和集权式部署的架构，不仅提升了业务数据处理能力的并发度，也提升了业务服务器架构的可扩展性和灵活性。

本申请实施例中，业务处理系统中的业务服务器可以采用分布式微服务，或分布式微服务和集群式部署的架构，不仅提升了业务服务器对业务请求的并发处理度，也可以在微服务的访问并发量较大时，灵活实现业务服务器的扩展和重构。

基于图1所述的实施例，业务处理系统还可以包括用户信息服务器、校验服务器，用户信息服务器采用分布式微服务和/或集群式部署的架构，校验服务器包括本地物理服务器或云服务器，且当智能交互设备为智能诊断设备时，还可以在智能诊断设备内置加密芯片，以用于对重要的业务请求进行加密，其中图3给出了业务处理系统中各装置及各装置间另一连接关系示意图。

当智能交互设备为车辆诊断装置时，下面结合具体的应用场景，从交互的角度对本申请实施例中各装置的作用进行描述，请参阅图4，本申请中业务处理方法的另一个实施例，包括：

401、用户终端与车辆诊断装置及业务服务器建立通信连接；

现有的各智能设备之间一般都可以通过网络模块之间实现通信连接，如可以在车辆诊断装置中内置蓝牙、WiFi模块、NFC模块，实现与用户终端之间的通信连接，而本实施例中的用户终端可以是电脑、平板、智能手机或可穿戴式设备中的任一种，也可以是电脑、平板、智能手机或可穿戴式设备中所安装的APP或小程序。

而用户终端可以通过内置的网络连接模块实现与业务服务器之间的通信连接。

402、用户终端将业务服务器的路由参数发送至车辆诊断装置，使得车辆诊断装置建立与业务服务器的通信连接；

本实施例中的车辆诊断装置(如车辆OBD系统)可以内置蓝牙和WiFi模块，并通过蓝牙模块建立与用户终端之间的通信连接，并在与用户终端建立通信连接后，用户终端将业务服务器的路由参数发送至车辆诊断设备，使得车辆诊断设备通过内置的WIFI模块建立与业务服务器之间的通信连接，使得业务服务器可以对车辆诊断装置的状态进行监测与查询。

403、用户终端向用户信息服务器发送注册请求；

实际通讯过程中，为了避免恶意终端对服务器进行访问，造成服务器数据的毁坏，而为了数据安全，一般要求用户终端在对业务服务器进行访问前，先对用户终端的身份信息进行注册，而本实施例中可以在车辆诊断装置通讯系统中加设用户信息服务器，以用于接收用户终端的注册请求，而这种将用户信息服务器和业务服务器区分设置的策略，也进一步缓解了业务服务器的数据负载，提高了业务请求的处理速度。

具体的，可以将用户信息服务器和业务服务器部署在云服务器上，而用户信息服务器也可以采用分布式微服务和/或集群式部署的架构，以实现对用户终端注册请求和业务请求的高速处理。

404、用户信息服务器接收注册请求，并根据注册请求，对车辆诊断装置和用户终端的基本信息进行关联存储；

用户信息服务器接收到注册请求后，可以根据该注册请求，对车辆诊断装置和用户终端的信息进行关联存储，以用于后续对车辆诊断装置及用户终端的身份信息进行识别与校验。

405、用户终端向业务服务器发送业务请求；

当用户终端在用户信息服务器上完成信息注册后，可以进一步向业务服务器发送业务请求，具体的，当车辆诊断设备与用户终端建立通信连接，并通过用户终端在用户信息服务器上完成注册信息后，用户终端向业务服务器发送业务请求，如用户终端想要获取车辆的当前运行状态信息，可以向业务服务器发送业务请求，而业务服务器接收到该业务请求后，将该业务请求发送至车辆诊断装置，使得车辆诊断装置根据该业务请求，获取被诊断车辆的当前运行状态信息，并进一步将被诊断车辆的运行状态信息发送至业务服务器。

区别于现有技术的是，本申请中的业务服务器可以包括一个主机和备用机，也可以包括多个主机和备用机，且业务服务器包括多个业务模块，每个业务模块都以微服务器的形式分布式部署在主机上，且各个微服务之间可以通过API接口进行调用，从而提高了业务服务器对业务请求的并发处理度。

具体的，本实施例中的车辆诊断装置可以是车辆内置的诊断系统，如车载OBD系统，也可以是外置的独立诊断装置，此处对车辆诊断装置的表现形式不做具体限制。

进一步，本实施例中的车辆诊断装置还可以内置加密芯片，这样可以在用户终端向业务服务器发送重要级别的业务请求时，用户终端将该业务请求发送至车辆诊断装置，使得车辆诊断装置采用内置加密芯片对该业务请求进行加密，以生成密令业务请求，以提高业务请求的私密性。具体的，车辆诊断装置内置加密芯片可以通过公钥和时间戳的方式，对该业务请求进行加密，以生成密令业务请求。

这样，对于车辆诊断装置(车载OBD诊断系统)而言，即使在用户终端丢失或用户终端APP被破解的情况下，也无法篡改业务请求数据，保证了业务请求数据的安全性。

406、业务服务器接收业务请求，根据该业务请求，向用户信息服务器发送校验请求，以使用户信息服务器对用户终端和车辆诊断装置的基本信息进行校验，若校验成功，则执行步骤407，若校验失败，则执行步骤408；

当业务服务器接收到业务请求后，根据该业务请求，向用户信息服务器发送校验请求，以对用户终端和车辆诊断装置的基本信息进行校验。若该用户终端和车辆诊断装置在用户信息服务器上已经完成基本信息注册，则用户信息服务器接收到该校验请求后，即根据该校验请求，对用户终端和车辆诊断装置的身份信息进行验证，若校验成功，则执行步骤407，若校验失败，则执行步骤408。

407、业务服务器判断业务请求是否为密令业务请求，若是，则执行步骤409，若否，则执行步骤410；

当业务服务器对该车辆诊断装置的身份校验通过，则业务服务器进一步判断该业务请求是否为密令业务请求，若该业务请求为密令业务请求，则执行步骤409，否则，执行步骤410。

408、业务服务器拒绝该业务请求；

若用户信息服务器对该车辆诊断装置的身份校验失败，则拒绝用户终端对业务服务器的访问，即拒绝该业务请求。

具体的，若用户信息服务器对车辆诊断装置的身份校验失败，可能是用户终端未在用户信息服务器上进行基本信息注册，则用户信息服务器可以将未注册的提示信息发送至业务服务器，使得业务服务器将未注册的提示信息发送至用户终端；也可能是用户终端的连续恶意访问，若业务服务器连续多次拒绝该用户终端的业务请求后，还接收到该用户终端的业务请求，可以将该用户终端拉入黑名单，以防止该用户终端对业务服务器造成严重的数据毁坏。

409、业务服务器将该密令业务请求发送至校验服务器，以用于对密令业务指令进行解密校验，若解密成功，执行步骤410，若解密失败，则执行步骤412。

若业务服务器判定业务请求为密令业务请求后，可以进一步将该密令业务请求发送至校验服务器，使得校验服务器对该密令业务指令进行解密，优选的，本实施例中的校验服务器采用本地物理服务器或云服务器，若解密成功，则执行步骤410，若解密失败，则执行步骤412。

具体的，若车辆诊断装置对该业务请求采用公钥和时间戳的方式进行加密，则校验服务器采用私钥的方式对该密令业务指令进行解密，并在解密成功后，执行步骤410，解密失败后执行步骤412。

410、业务服务器接收业务请求，并将该业务请求发送至车辆诊断装置，使得车辆诊断装置根据该业务请求，向业务服务器发送业务响应；

若业务服务器判断该业务请求为非加密业务请求，则业务服务器接收到该业务请求后，可以进一步将该业务请求发送至车辆诊断装置，使得智能交互设备根据该业务请求，向业务服务器发送业务响应。

或，业务服务器将密令业务请求发送至校验服务器，校验服务器对该密令业务请求解密成功后，则业务服务器接收到该业务请求后，可以进一步将该业务请求发送至智能交互设备，使得智能交互设备根据该业务请求，向业务服务器发送业务响应。

需要说明的是，当业务服务器接收到业务请求后，若该业务请求不需要经过车辆诊断装置，则业务服务器可以直接对该业务请求进行响应，而省略将业务请求发送至智能交互设备的步骤。

411、业务服务器将该业务响应发送至用户终端；

当业务服务器接收到车辆诊断装置发送的业务响应后，则进一步将该业务响应发送至用户终端。

412、业务服务器拒绝该密令业务请求；

若业务服务器将密令业务请求发送至校验服务器，而校验服务器对该密令业务请求解密失败后，则业务服务器拒绝该密令业务请求。

413、运维服务器对每个微服务的并发访问量进行统计，当运维服务器监测到任一个微服务的并发访问量大于预设的阈值时，启用备用机，并在备用机上集群式部署对应的微服务，使得业务服务器采用分布式微服务和集群式部署的架构。

而运维服务器可以实时或定时(如每隔15分钟)对业务服务器上每个微服务的并发访问量进行统计和监测，并在监测到任一个微服务的并发访问量大于预设的阈值时，自动或手动启用备用机，并在备用机上集群式部署对应的微服务，以缓解每个微服务的数据负载。

414、当运维服务器监测到任一个微服务的并发访问量在预设时间段小于预设的阈值时，则关闭备用机，使得业务服务器采用分布式微服务架构，以节省数据开销。

进一步，运维服务器还可以监测任一个微服务在预设的时间段内的并发访问量是否小于预设的阈值，若小于预设的阈值，则关闭备用机，以节省数据开销。

具体的，如运维服务器在22:00-07:00之间，监测到某个微服务的并发访问量小于预设的阈值，则自动或手动关闭备用机，以节省数据开销。

本申请实施例中，业务处理系统中的业务服务器可以采用分布式微服务，或分布式微服务和集群式部署的架构，即在运维服务器监测到微服务的并发访问量小于预设阈值时，对业务服务器采用分布式微服务架构，而在运维服务器监测到任一个微服务的并发访问量大于预设的阈值时，则启动备用机，并在备用机上集群式部署对应的微服务，使得业务服务器采用分布式微服务和集群式部署的架构，不仅提升了业务服务器对业务请求的并发处理度，也可以在微服务的访问并发量较大时，灵活实现业务服务器的扩展和重构。

其次，本申请实施例中，加入了用户信息服务器和校验服务器，以用于对车辆诊断装置的身份信息和密令业务请求进行校验，提高了数据的安全性；且本实施例中的车辆诊断装置中内置加密芯片，可以通过加密芯片对重要的业务请求进行加密，避免了在用户终端丢失或用户终端被破解后，业务请求被篡改的问题。

下面从单侧(业务服务器)的角度，对本申请中的业务处理方法进行描述，请参阅图5，本申请中业务处理方法的另一个实施例，包括：

501、业务服务器分别建立与用户终端、运维服务器及智能交互设备的通信连接；

本申请实施例中的业务处理系统包括用户终端、业务服务器、智能交互设备及运维服务器，如图2所述，业务服务器要实现与用户终端、智能交互设备及运维服务器的数据通信，首先得与用户终端、智能交互设备及运维服务器建立通信连接，具体的，业务服务器与用户终端、智能交互设备及运维服务器之间的通信连接可以是通过WiFi模块、蓝牙模块、NFC模块、红外模块等任一种而建立，此处不做具体限制。

需要说明的是，本实施例中的业务服务器包括多个业务模块，每个业务模块上分布式部署一个微服务，各个微服务之间可以通过API接口实现相互调用，且该业务服务器采用分布式微服务的架构，或，分布式微服务和集群式部署的架构。

502、业务服务器的微服务接收所述用户终端发送的业务请求；

503、业务服务器的微服务将所述业务请求发送至所述智能交互设备；

504、业务服务器的微服务接收所述智能交互设备的业务响应，并将所述业务响应发送至所述用户终端；

需要说明的是，本实施例中的步骤502至504与图2所述实施例中的步骤203至205类似，此处不再赘述。

505、业务服务器根据所述运维服务器监测到的每个微服务的并发访问量，在监测到所述并发访问量大于预设的阈值时，使得所述业务服务器由所述分布式微服务架构扩展为所述分布式微服务和集群式部署的架构。

本申请实施例中，业务服务器在与运维服务器建立通信连接后，运维服务器可以实时或定时对业务服务器中每个微服务的并发访问量进行监测，而业务服务器可以根据运维服务器监测到的每个微服务的并发访问量，将业务服务器由分布式微服务架构，扩展为分布式和集群式部署的架构。

具体的，可以是在运维服务器监测到业务服务器中每个微服务的并发访问量大于预设阈值时，向业务服务器发送通知指令，而业务服务器可以包括多个主机和备用机，当业务服务器接收到通知指令时，由业务服务器在备用机上集群式部署对应的微服务，使得业务服务器由分布式微服务架构扩展为分布式微服务和集群式部署的架构。

或者，还可以是在运维服务器监测到业务服务器中每个微服务的并发访问量大于预设阈值时，由运维服务器直接在业务服务器的备用机上集群式部署对应的微服务，使得业务服务器由分布式微服务扩展为分布式微服务和集群式部署的架构，从而实现业务服务器架构的灵活扩展，提高业务服务器的并发访问量。

基于图5所述的实施例，本申请实施例中的业务处理系统还可以包括：用户信息服务器和校验服务器，且当智能交互设备为车辆诊断装置时，下面结合具体的应用场景，从单侧的角度对本申请实施例中业务服务器的作用进行描述，请参阅图6，本申请实施例中业务处理方法的另一个实施例，包括：

601、业务服务器分别建立与用户终端、运维服务器及智能交互设备的通信连接；

602、业务服务器的微服务接收所述用户终端发送的业务请求；

603、业务服务器的微服务根据所述业务请求，向用户信息服务器发送校验请求，若校验通过，则执行步骤604，否则，执行步骤605；

604、判断所述业务请求是否为密令业务请求，若是，则执行步骤606，若否，则执行步骤607；

605、则拒绝用户终端的业务请求；

606、业务服务器将密令业务请求发送至校验服务器进行解密校验，若解密成功，则执行步骤607，若解密失败，则执行步骤609；

607、业务服务器接收业务请求，并将该业务请求发送至车辆诊断装置，使得车辆诊断装置根据该业务请求，向业务服务器发送业务响应；

608、业务服务器将该业务响应发送至用户终端；

609、业务服务器拒绝用户终端的密令业务请求；

610、业务服务器根据所述运维服务器监测到的每个微服务的并发访问量，并在监测到所述并发访问量大于预设的阈值时，使得所述业务服务器由所述分布式微服务架构扩展为所述分布式微服务和集群式部署的架构。

需要说明的是，本实施例中业务服务器的作用与图4所述实施例中的业务服务器的作用类似，此处不再赘述。

本申请实施例中，业务处理系统中的业务服务器可以采用分布式微服务，或分布式微服务和集群式部署的架构，即在运维服务器监测到微服务的并发访问量小于预设阈值时，对业务服务器采用分布式微服务架构，而在运维服务器监测到任一个微服务的并发访问量大于预设的阈值时，则启动备用机，并在备用机上集群式部署对应的微服务，使得业务服务器采用分布式微服务和集群式部署的架构，不仅提升了业务服务器对业务请求的并发处理度，也可以在微服务的访问并发量较大时，灵活实现业务服务器的扩展和重构。

其次，本申请实施例中，加入了用户信息服务器和校验服务器，以用于对车辆诊断装置的身份信息和密令业务请求进行校验，提高了数据的安全性；且本实施例中的车辆诊断装置中内置加密芯片，可以通过加密芯片对重要的业务请求进行加密，避免了在用户终端丢失或用户终端被破解后，业务请求被篡改的问题。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccess Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (10)

1.一种业务处理系统，其特征在于，所述业务处理系统包括智能交互设备、用户终端、业务服务器及运维服务器，其中，所述业务服务器包括多个业务模块，每个业务模块对应部署一个微服务，所述业务服务器采用分布式微服务架构，或，分布式微服务和集群式部署的架构。

2.根据权利要求1所述的业务处理系统，其特征在于，所述业务处理系统还包括：用户信息服务器，所述用户信息服务器采用分布式微服务和/或集群式部署的架构。

3.根据权利要求2所述的业务处理系统，其特征在于，所述业务处理系统还包括：校验服务器，所述校验服务器包括本地物理服务器或云服务器，所述智能交互设备内置加密芯片。

4.根据权利要求1至3中任一项所述的业务处理系统，其特征在于，所述业务服务器包括主机和备用机，且所述主机上分布式部署多个微服务。

5.根据权利要求4所述的业务处理系统，其特征在于，所述运维服务器对每个微服务的并发访问量进行统计，当所述运维服务器监测到任一个微服务的并发访问量大于预设的阈值时，则启用所述备用机，并在所述备用机上集群式部署对应的微服务，使得所述业务服务器由所述分布式微服务架构扩展为所述分布式微服务和集群式部署的架构。

6.一种业务处理方法，其特征在于，应用于业务服务器，所述业务服务器包括多个业务模块，每个业务模块对应部署一个微服务，所述业务服务器采用分布式微服务架构，或，分布式微服务和集群式部署的架构，所述方法包括：

所述业务服务器分别建立与用户终端、运维服务器及智能交互设备的通信连接；

所述业务服务器的微服务接收所述用户终端发送的业务请求；

所述业务服务器的微服务将所述业务请求发送至所述智能交互设备；

所述业务服务器的微服务接收所述智能交互设备的业务响应，并将所述业务响应发送至所述用户终端；

所述业务服务器根据所述运维服务器监测到的微服务的并发访问量，在监测到所述并发访问量大于预设的阈值时，使得所述业务服务器由所述分布式微服务架构扩展为所述分布式微服务和集群式部署的架构。

7.根据权利要求6所述的方法，其特征在于，在所述将所述业务响应发送至所述用户终端之前，所述方法还包括：

所述业务服务器的微服务根据所述业务请求，向所述用户信息服务器发送校验请求；

若校验通过，则触发将所述业务响应发送至用户终端的步骤。

8.根据权利要求7所述的方法，其特征在于，若所述业务请求为密令业务请求，在所述将所述业务响应发送至所述用户终端之前，所述方法还包括：

所述业务服务器的微服务将所述密令业务请求发送至校验服务器进行解密校验；

若校验通过，则触发将所述业务响应发送至用户终端的步骤。

9.一种业务处理系统，其特征在于，应用于业务服务器，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求6至8任一项所述的业务处理方法。

10.一种业务处理方法，其特征在于，应用于权利要求1至5中任一项所述的业务处理系统，所述业务处理系统包括智能交互设备、用户终端、业务服务器及运维服务器，其中，所述业务服务器包括多个业务模块，每个业务模块对应部署一个微服务，所述业务服务器采用分布式微服务架构，或，分布式微服务和集群式部署的架构，所述方法包括：

所述用户终端建立与所述智能交互设备及所述业务服务器之间通信连接；

所述用户终端将业务服务器的路由参数发送至所述智能交互设备，使得所述智能交互设备建立与所述业务服务器之间的通信连接；

所述用户终端向所述业务服务器的微服务发送业务请求；

所述业务服务器的微服务将所述业务请求发送至所述智能交互设备；

所述业务服务器的微服务接收所述智能交互设备的业务响应，并将所述业务响应发送至所述用户终端；

所述运维服务器在监测到所述业务服务器的每个微服务访问并发量大于预设的阈值时，使得所述业务服务器由分布式微服务架构扩展为分布式微服务和集群式部署的架构。