CN112035213A

CN112035213A - Multi-tenant network car booking system and dynamic isolation method

Info

Publication number: CN112035213A
Application number: CN202010885588.9A
Authority: CN
Inventors: 于志杰
Original assignee: Beijing Bailong Mayun Technology Co ltd
Current assignee: Beijing Bailong Mayun Technology Co ltd
Priority date: 2020-08-28
Filing date: 2020-08-28
Publication date: 2020-12-04
Anticipated expiration: 2040-08-28
Also published as: CN112035213B

Abstract

A multi-tenant network car booking system and a dynamic isolation method are disclosed. The system comprises: the public tenant computer room comprises a public data storage device which deploys business data of a plurality of first tenants in independent tables or mixed tables; the independent tenant computer room comprises independent data service storage equipment for deploying the business data of the second tenant by using independent equipment; the common tenant room and the independent tenant room provide a network car booking service for client devices of different tenants via external call routes of the system, and include: distributing global unique identification for the generated business data of different tenants; and storing the generated business data entries of the different tenants in a storage target corresponding to each tenant, wherein the entries comprise the globally unique identification items and tenant identification items. The invention realizes multi-tenant dynamic isolation by simultaneously introducing the global unique ID and the tenant ID in the service data and utilizing a data bidirectional synchronization technology and a building block type micro-service architecture.

Description

Multi-tenant network car booking system and dynamic isolation method

Technical Field

The present disclosure relates to cloud technologies, and in particular, to a multi-tenant network car booking system and a dynamic isolation method.

Background

The Online appointment vehicle is a novel internet service, is different from a common e-commerce or O2O (Online To Offline), and depends on Online scheduling and global information, particularly, the timeliness of the information is far higher than that of the e-commerce and O2O, and generation of a transaction often requires second-level response.

The network car booking service subjects are cars, drivers and passengers, and the network car booking service can be provided in public, mixed and private cloud environments. The data stored in the database may be accessed by services provided by the service provider. In large service systems, computerized information storage and retrieval systems are required to manage multiple databases, each of which may be owned by a different entity. Services may be subscribed to by multiple tenants simultaneously. In the network car booking service, a plurality of tenants can belong to different network car booking companies respectively, and the network car booking service needs to process data of different tenants simultaneously. Tenants may require different degrees of data isolation for reasons of traffic, cost, etc., and the degree of isolation can change seamlessly as external conditions change. Thus, service providers need to implement a multi-tenant architecture for services that allows data and configuration to be separated so that each tenant receives an appropriate level of data and traffic isolation.

There are currently three deployment options for managing multi-tenant data. Firstly, all tenant data are stored in the same physical storage and are distinguished through tenant identification, the same data source is accessed when the data are accessed by the service, and different tenants need to be distinguished in all service logics so as to prevent isolation failure. The method has the highest storage utilization rate, but the performance is easy to have a bottleneck along with the increase of services. And secondly, different tenant data are respectively stored in different physical storages, the business directly accesses different data sources according to the tenants, the logic is relatively simple, the performance is not reduced along with the increase of the tenants, and the cost is linearly increased along with the increase of the business and the increase of the tenants. Third, tenants are mixed and distributed in a plurality of physical storages, the number of tenants on different data sources can be different according to different strategies, and both expansibility and cost are considered, but the strategies are complex, and the problem that performance is uneven still exists after tenant service changes, and data needs to be planned again.

Traffic isolation is similar, and there are two different deployment models. Firstly, cluster centralized deployment is realized, and tenants share business services. When the tenant service is uneven, the tenant with large service volume often generates large pressure on the whole cluster, and the performance isolation is poor. And secondly, tenants are independently deployed, the isolation is good, the hardware cost is high, version iteration and upgrade maintenance need to be carried out respectively, and the maintenance cost is also high. The two isolation dimensions (i.e., data isolation and business isolation) are typically used in combination, such as tenant sharing business services, but data storage independent, and the like.

The existing isolation scheme has few problems under the condition that the tenant and the data volume are small, if the number of tenants is large and the difference of the service volume is large, the problems of data inclination, maintenance cost and the like are faced, and meanwhile, the rapid change of the service volume also needs to face the dynamic migration of service programs and data.

For this reason, an isolation scheme capable of flexibly coping with the requirements of multiple tenants is required.

Disclosure of Invention

The technical problem to be solved by the present disclosure is to provide an isolation scheme capable of flexibly coping with multi-tenant requirements, which realizes dynamic isolation of multi-tenant services by introducing a globally unique ID and a tenant ID in business data simultaneously and by using a data bidirectional synchronization technology and a building block type micro-service architecture.

According to a first aspect of the present disclosure, there is provided a multi-tenant network car appointment system, including: the public tenant computer room comprises a public data storage device which deploys business data of a plurality of first tenants in independent tables or mixed tables; the independent tenant computer room comprises independent data service storage equipment for deploying the business data of the second tenant by using independent equipment; the common tenant room and the independent tenant room provide a network car booking service for client devices of different tenants via external call routes of the system, and include: distributing global unique identification for the generated business data of different tenants; and storing the generated business data entries of the different tenants in a storage target corresponding to each tenant, wherein the entries comprise the globally unique identification items and tenant identification items.

Optionally, the common tenant computer room further includes: and the common basic data storage device is used for storing system metadata and management data.

Optionally, the independent tenant computer room further includes: and the independent basic data storage device is used for storing system metadata and management data required by providing services for the second tenant.

Optionally, the common tenant computer room may also include: and the public application server is used for splitting the network taxi appointment service into micro services for deployment and providing the services.

Optionally, the independent tenant computer room further includes: and the independent application server is used for deploying at least part of micro services of the network car-booking service required by the second tenant and providing the network car-booking service for the client equipment of the second tenant.

Optionally, the system further comprises: and the service call route is used for carrying out service call across the application servers according to the current flow and the call rule.

Optionally, the system further comprises: and the data call route is used for calling the required service data and/or basic data across the machine room according to the service call.

Optionally, the system further comprises: and the dynamic configuration module is used for dynamically selecting and arranging the microservices according to the requirements of the tenants.

Optionally, the same microservice runs on multiple application servers in the same or different rooms, and an election mechanism is used to determine the application server that provides the microservice for the current request.

Optionally, different tenants use the common application server according to respective traffic access rules.

Optionally, the system further comprises: and the global scheduler is used for limiting a specific application server to execute a certain timing task.

Optionally, a specific application server is dynamically allocated to perform the riding matching calculation of a certain tenant.

According to a second aspect of the present disclosure, there is provided a multi-tenant dynamic isolation method, including: distributing global unique identification for the generated business data of different tenants; and storing the generated business data entries of the different tenants in a storage target corresponding to each tenant, wherein the entries comprise the global unique identification items and the tenant identification items.

Optionally, the method further comprises: receiving a request for converting a certain tenant data deployment type; and directly storing the business data items stored in the current storage target of the tenant into the changed storage target based on the globally located tenant identification, wherein the data deployment type comprises independent device deployment, independent table deployment and table mixed deployment, and the respective corresponding storage target comprises independent devices, independent tables and mixed tables.

Optionally, the homogeneous business data entries of different tenants of different data deployment types have the same data structure.

Optionally, the method further comprises: receiving a service request from a client by an external call route; the service calling route calls an application server for providing corresponding micro service according to the micro service related to the service request; and the corresponding application server returns a result to the external call route based on the global unique identifier, wherein the client acquires the combination to generate a corresponding display page. Further, the corresponding application server acquires corresponding data via a data call route, and generates a result for return based on the data.

Optionally, assigning globally unique identifiers to the generated business data of different tenants includes: a globally unique order number is assigned for a taxi operation of a current user of a particular tenant, and the method further comprises: sending the taxi calling information to a public application server dynamically allocated to the specific tenant to execute riding and driving matching calculation; and allocating drivers to the users according to the result of the driver-and-passenger matching calculation.

Therefore, the multi-tenant network car booking platform and the dynamic isolation method thereof utilize the global unique ID to combine with the tenant ID for storage, and adopt the building block type micro-service architecture and the service call routing technology, so that the data cloud storage (independent of physical storage) and the dynamic data migration can be conveniently realized.

Drawings

The above and other objects, features and advantages of the present disclosure will become more apparent by describing in greater detail exemplary embodiments thereof with reference to the attached drawings, in which like reference numerals generally represent like parts throughout.

FIG. 1 shows a schematic diagram of a cloud computing environment for implementing one embodiment of the invention.

Fig. 2 is a schematic composition diagram of a multi-tenant network car booking service system according to one embodiment of the invention.

FIG. 3 illustrates an exemplary page of a net appointment APP.

Fig. 4 shows a schematic flowchart of a multi-tenant network appointment data processing method according to one embodiment of the present invention.

Detailed Description

Preferred embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While the preferred embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

The network appointment platform is preferably realized by a SaaS platform. The SaaS platform is a cloud platform running SaaS software. Software-as-a-Service (SaaS) provides a technical Service interface or a direct graphical operating interface to a consumer (e.g., a third party vendor that is a tenant) to enable the consumer to use various types of applications running on the cloud infrastructure. In different implementations, the application may be accessed through a client interface such as a web browser or via a client of an installed dedicated APP. With the possible exception of limited user-specific application configuration settings, consumers do not manage or control the underlying cloud infrastructure including networks, servers, operating systems, storage, or even individual application capabilities.

"cloud" or "cloud computing" can be viewed as a service delivery model for enabling shared and on-demand access to configurable computing resources. Configurable computing resources can be provisioned and released quickly with minimal administrative cost or minimal interaction with a service provider.

After the basic configuration is complete, the cloud's consumers are able to unilaterally and automatically acquire computing capabilities such as server time and network storage on demand without human interaction with the service provider. The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, and different physical and virtual resources are dynamically allocated and reallocated according to demand. The consumer typically has no control or knowledge of the exact location of the provided resources. In addition, the cloud infrastructure also has the capability to expand and contract to meet the customer's upgrade (e.g., service upgrade) needs. Further, the cloud system may automatically control and optimize resource usage with metering capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both the provider and consumer of the utilized service.

Cloud computing environments are service-oriented, focusing on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure comprising a network of interconnected nodes. Nodes in a cloud computing network are computing devices including, but not limited to, personal computer systems, server computer systems, mobile clients, and the like. Due to the real-time nature of the network car booking service, the SaaS platform implementing the network car booking service system also needs to have high timeliness, and can simultaneously process a large number of requests from the mobile client, for example, in the scene of placing an order and dispatching, the user request (user order) is allocated to the driver and passenger matching operation of the appropriate order-taking party (driver order taking), that is, each order sent by the passenger is matched with an appropriate driver.

FIG. 1 shows a schematic diagram of a cloud computing environment for implementing one embodiment of the invention. As shown, the cloud computing environment 100 includes one or more cloud nodes 110, client devices 120 used by cloud consumers, such as an on-board computer 120_1, a laptop computer 120_2, a smartphone 120_3, and an in-vehicle computing system 120_ 4. A client device may utilize services provided by cloud platform 100, such as communicating with one or more cloud nodes 110 in platform 100, via, for example, a specialized App or using a web browser to access a specialized URL address. As shown, the computing nodes 110, which are infrastructure of the cloud environment 100, may communicate with each other and may have various physical forms, e.g., have the same attributes as server and client computers, and may be physically or virtually grouped into clusters (not shown) in one or more networks, thereby allowing the cloud environment 100 to provide services as a SaaS platform. It should be understood that the illustrated nodes 110 and their connections are merely schematic and are intended to represent the vast number of nodes and complex structures included in the cloud platform.

Consumers of cloud services do not need to maintain resources for them on local computing devices. It should also be understood that the type of computing device 120 shown in fig. 1 is intended to be illustrative only, and that the computing nodes 110 and cloud environment 100 may communicate with any type of computerized device over any type of network and/or network addressable connection (e.g., through the use of a web browser), as shown below in fig. 2, and that communication may be accomplished through an abstracted external routing function 130.

In the multi-tenant network appointment platform of the present invention, a third party vendor (i.e., tenant) may access a technical service interface provided by a cloud service provider (e.g., access a specific address via a web browser) through, for example, the desktop computer 120_1 and the laptop computer 120_2, etc., to implement operations such as customization, operation, and maintenance of a network appointment service for the tenant.

Users who utilize the above-described network appointment platform, such as passengers and drivers of waybills, may generally obtain services provided by the platform using, for example, a private network appointment APP or a navigation APP installed on the smart phone 120_ 3. In the prior art, passengers and drivers usually make and receive orders using APPs installed on smartphones, but it is understood that with the development of intelligentization and communication technologies of personal vehicles, vehicles for carrying passengers at present or in the future may be connected to the cloud platform 100 as shown in the in-vehicle computing system 120_4 of fig. 1 to directly perform ticketing operations as clients on the driver side.

The existing isolation scheme can generally guarantee normal operation under the condition that the number of tenants and data is small, but as the number of tenants is increased and the difference of the service volume of each tenant is increased, the existing cloud platform faces the problems of data inclination, maintenance cost and the like, and meanwhile, the problem of dynamic migration of service programs and data needs to be solved due to rapid change of the service volume.

Therefore, the invention provides a multi-tenant network car booking service system and a corresponding management and operation scheme, which are used for solving the problem of dynamic isolation of service programs and data in a network car booking and multi-tenant scene, reducing the hardware cost and the maintenance cost to the maximum extent and ensuring the uniformity of performance distribution.

As shown, the system includes a network appointment platform 100 and a client device 120. Here, the network appointment platform 100 may provide services to a plurality of tenants, such as tenants a-E, simultaneously. Here, the tenants a to E may be different network car booking operation entities that provide network car booking services for users and organize drivers to take orders. Each tenant may publish its own APP to facilitate installation by passengers and drivers (passengers and drivers of the same tenant may install different APPs corresponding to different identities, or select driver or passenger mode under the same APP). For this reason, tenants A-E may correspondingly publish their APP 1-5. In other cases, the navigation APP may also integrate the network appointment entry of a part of tenants. Here, the tenant client 120 shown in the figure, for example, the tenant client (tenant a) may refer to a driver or a passenger client in which the tenant (e.g., tenant a) publishes APP.

No matter through the own APP or the navigation APP, although the tenant a-E user body feels and uses different network appointment brands and entrances, actually, the service data of the tenant a-E may be supported by the same network appointment platform 100, and the service and data of the tenant a-E may be at least partially shared, processed and stored, but can be dynamically isolated by adopting the scheme of the present invention.

The platform 100 provides services to tenants using multiple data deployment and business service implementations simultaneously. This "shuffling" includes different deployments on data and different implementations on business services. As shown, the rooms 300 and 400 in which tenants a and B lease their own private, i.e., at least part of their storage of business data and processing of business data can be physically isolated from other tenants. Tenants C, D and E then choose to be arranged within common room 200, i.e., at least part of their storage of business data and processing of business data may share physical resources with other tenants. The respective clients 120 of tenants a-E may connect to the network appointment platform 100 via a network (e.g., using WiFi or a mobile network such as 4G, 5G), for example via respective network appointment APPs 1-5. Platform 100 may communicate with client devices 120 through unified external call routing 130. Here, the external call route 130 may be understood as a virtual function implemented by hardware and software on the cloud platform 100, such as a network interface device and scheduling software and rules, unlike the physically existing computer rooms 200, 300, and 400. The external invocation route 130 may be regarded as an access portal of the platform 100, so that the client device 120 can obtain the service provided by the platform 100 via a communication network (e.g., internet) without knowing a specific route inside the platform 100, for example, without knowing a specific route of a service request and response thereof in each node 110 shown in fig. 1, and without knowing a deployment situation of a corresponding tenant in the cloud platform 100.

In the multi-tenant network car appointment service system, two (or three) deployment options for managing multi-tenant data can exist. The first deployment option stores tenant data in a separate database, which is the simplest approach to data isolation. As previously described, tenant a has its own independent machine room 300, tenant B also has its own independent machine room 400, and the machine rooms 300 and 400 may be physically separated from the common tenant machine room 200, for example, located in different data centers, different areas of the same data center (e.g., isolated using physical servers with lock cages, etc.). In the computer rooms 300 and 400, tenants a and B each own their dedicated databases, as shown in fig. 2, a device 320 (e.g., database 320, which may also be referred to as independent data storage device 320) that deploys tenant a business data independently, and a device 420 (e.g., database 420, which may also be referred to as independent data storage device 420) that deploys tenant B business data independently. Physical isolation can achieve greater security and efficiency when the number of users is large, but typically results in higher costs for service providers to maintain equipment and backup tenant data. The hardware cost is also higher than under the alternative deployment option.

In the common tenant room 200, there may be another deployment, i.e., a mix within the same database or device (or physical hard disk). Specifically, the mixing of the public machine room can be further divided into two deployments. One such deployment is that multiple tenants can be hosted in the same database, each tenant having its own set of tables and other database artifacts aggregated into a schema created specifically for that tenant. Although not as well as the fully isolated system of tenants a and B, this approach provides a moderate degree of logical data isolation for security-conscious tenants and is able to support a larger number of tenants on each database server. Further, the same database and the same set of tables may also be used to host data for multiple tenants. A given table may include records from multiple tenants stored in any order, and a tenant identification column associates each record with an appropriate tenant. Among these three options, the shared schema approach has the lowest hardware and backup costs because it allows each database server to serve the maximum number of tenants.

In the invention, the system supports tenants C, D and E to select a specific mix-distribution mode (for example, independent table arrangement or table mix-distribution related to different prices) in a common tenant machine room by themselves, or a platform provider can select a mix-distribution mode according to the needs of system operation. Whether in an independent table arrangement or a table mixed arrangement, the identity can be utilized to distinguish individual tenants. In fig. 2, the relevant business data of tenants C, D and E can be arranged with a device 220 (e.g., database 220, which can also be referred to as a common data store 220) that deploys the business data. For example, tenant C may currently select a common computer room deployment of the independent tables described above. Tenants D and E, as well as other small customers not shown in the figure, may then store the business data in the same data table and be distinguished by the tenant identity.

In the example of fig. 2, tenants a-E may have different service deployment manners (i.e., manners of providing network appointment services) besides different manners of isolating data. Tenants C, D and E disposed in common tenant room 200 preferably select cluster intensive deployments, i.e., utilize shared application servers to provide shared services. The shared application server may be provided by the device 210 providing tenant business services (e.g., the application server 210, which may also be referred to as a common application server 210) shown in fig. 2.

In other words, while users of tenants C, D and E may utilize different network appointment APPs (e.g., APP3, APP4, and APP5) or different portals on the navigation APPs, each installed, to perform taxi calling and ticketing operations, these operations from the different APPs may operate on the same server or server cluster. In addition, although not superior in terms of implementation cost and efficiency, tenants C, D and E may also use independently arranged application servers for the operations of related services, i.e., operations from different APPs may be run on different servers, or at least use specially allocated servers to complete core services, e.g., driver-and-crew matching. For tenants a and B that use independent machine rooms to store data, it may be preferable to utilize independently deployed servers, such as the illustrated device 310 for implementing tenant a business services and the illustrated device 410 for implementing tenant B business services to provide services for respective client devices 120 of tenants a and B (e.g., clients that have APP1 and APP2 installed, respectively), or to provide at least a portion of the services with independently deployed application servers 310 and 410 (also referred to as independent application servers 310 and 410).

In a broader embodiment, the

independent application servers

310 and 410 in the respective rooms are typically unable to perform all the functions requested by their corresponding client devices 120 completely independently, but instead need to interact with the common application server 210 located in the common tenant room 200, which may be implemented using the service call routing 140. Similar to the external call route 130, the service call route 140 is a virtual function for performing service call across machine rooms or across servers on the basis of software and hardware cooperation in the cloud environment 100. Although

application servers

310 and 410 are shown in figure 2 as being located in separate respective rooms, in other implementations, tenants a and B of the independent data arrangement may also operate with the business services of the cluster arrangement, e.g., with application server 210 in a common room. As will be described in detail below, in order to provide flexibility in service deployment, a micro-service approach may be adopted to split services, so that a single service application becomes sufficiently compact and centralized. Further, the service itself may not differentiate tenants, have the capability to handle all tenant requests, and be deployed in several physical clusters, so that it can handle requests from different tenants, for example, simultaneously, or serve as a redundant backup of the system.

In order to deal with various types of data required to be accessed by a service request, the cloud platform 100 of the present invention may further add a data call route 150 between the application server and the database. Similar to the routes 130 and 140, the data call route 150 can also be regarded as a virtual function for making data calls across machine rooms or across physical data storage devices based on the cooperative operation of software and hardware in the cloud environment 100.

As shown, the system data may include basic data in addition to storing business data. These SaaS base data may be centrally stored in a separate physical store, such as a base SaaS data storage (i.e., a metadata database, which may also be referred to as a common base data storage 230) located in a common computer room 200. The basic data mainly includes management data and metadata at the SaaS level, which are used to provide global centralized services, for example, tenant identification information, system policies, and any other relevant information may be stored in a metadata database.

In the example shown in fig. 2, when tenants a and B utilize the cloud platform to service their customers, there is still a need to access the metadata database 230 within the common tenant room 200. In other embodiments, the machine room of the independent tenant may also include an independent basic data storage device for storing system metadata and management data required for providing services for the respective corresponding independent tenant. In other words, the SaaS base data and services may also be unshared and employ redundant storage. This makes overall deployment simpler, but the consistency processing cost can be increased.

The existing tenant static isolation scheme requires a large amount of manual participation, so that the labor cost is high and the efficiency is low. In particular, as the volume of partial tenant traffic increases (e.g., increase in the number of service cities, users, and orders), existing solutions face performance and data volume bottlenecks that require data migration (e.g., from a mix of data and services to independent deployment of data and/or services); meanwhile, part of tenants have the requirement of reducing cost, so data is migrated (for example, from independent deployment to mixed deployment, to table independent deployment to mixed table deployment). In addition, each tenant also has a demand for customizing services, updating system structures, and the like.

In summary, existing platforms face the following difficulties in dealing with the above-mentioned needs of tenants:

1. when the data is stored in different physical storages, the primary key id may face repetition and the data cannot be migrated in or out directly;

2. in a conventional data migration mode, service needs to be stopped, even if a real-time synchronization scheme is used, writing is also stopped, the manual intervention cost is high, and in view of the property that a network appointment needs to provide service all the day long (namely, the vehicle using requirement also exists in early morning hours), the service needs to be prevented from being completely stopped;

3. different tenants have different business models, all functions are always required to be provided on business programs, different logic judgment is carried out according to the tenants, so that coupling is serious, the difficulty of function iteration test is high, and online risks are increased;

4. the individual requirements of different tenants are different greatly, and adaptation is needed on a service program, so that the logic judgment and coupling are serious, and the problems of slow function iteration test and low development efficiency exist.

For this reason, the multi-tenant network car booking platform scheme of the present invention can solve the problem that data generation depends on a physical database (for example, an autonomous key) by using an organic combination of external call routing, service call routing and data call routing functions under the system architecture as shown in fig. 2, so that data can be stored in any physical storage without conflict. Meanwhile, the platform solution of the invention can provide a dynamic migration capability to solve the problem that the service needs to be stopped in the data migration process, and can also solve the problems of service program logic coupling, low service requirement personalized development efficiency and the like through micro-service splitting.

The public tenant machine room and the independent tenant machine room provide network car booking service for client devices of different tenants through external call routing of the system. Specifically, although one database for data storage and one application server for business services (e.g., the metadata database 230, the common database 220, and the common application server 210 in the common machine room) are illustrated as respective machine rooms, in practical applications, depending on the number of service tenants and the volume of each tenant, the common tenant machine room 200 may be a small data center including tens of servers or may be a large data center including hundreds or even thousands of servers. Similarly, individual rooms may have different equipment sizes depending on the amount of traffic supported by the customer. In other words, although shown as a single device for convenience of illustration, each illustrated device unit (e.g., 210, 220, 230, 310, 320, 410, 420) will typically include multiple physical devices, especially corresponding to a common computer room, and multiple physical servers are typically required to implement the processing capability of the common application server 210 for simultaneously handling mass user requests from multiple tenants, and multiple databases are required to store mass business data.

In the case of a mixed deployment of data and services, in order to distinguish traffic data from different tenants, the generated traffic data is to include at least a tenant identification (tenant ID), e.g., a number corresponding to each tenant within a corresponding tenant identification field. Besides, in the invention, the business data can also comprise a globally unique identifier (globally unique ID) in addition to the tenant identifier, thereby ensuring the uniqueness of the data and providing a prerequisite for data clouding.

Specifically, clients of different tenants, for example, clients of tenants a to E shown in fig. 2, may uniformly access corresponding nodes in the system 100 via the APP installed therein, for example, access the above-mentioned common tenant machine room and independent tenant machine room via the external call route 130 of the system 100, so that devices in the machine room provide network appointment services for client devices of different tenants, and may allocate globally unique identifiers for generated service data of different tenants; and storing the generated business data entries of the different tenants in a storage target corresponding to each tenant, wherein the entries comprise the globally unique identification items and tenant identification items.

Specifically, the cloud platform 100 may receive taxi-calling requests from passenger clients of different tenants at the same time, and assign globally unique order numbers to the requests (that is, the order numbers of the respective tenants do not overlap with each other), and the resultant taxi-calling service data may include a tenant identification item for placing a tenant ID and a globally unique identification item for placing a generated globally unique ID. The piece of data may be stored in the data storage device of the independent deployment room (e.g., the data of tenant a is stored in the data store 320) or the storage device 220 of the common tenant room (e.g., the data of tenants C-E) according to the data storage type corresponding to the tenant. The data entries stored in the common tenant room can also be a separate table store (e.g., data for tenant C) or a mixed store within a table (e.g., data for tenants D and E).

After the external request route 130 as an access stratum acquires the user request uniformly, the generated service data may be stored as needed, and also needs to be routed between the respective service services via the service invocation route 140.

The specific description of fig. 2 is for illustration purposes only. It is to be understood that the invention is not limited to the specifically described embodiments, and that any combination of implementing and practicing the invention is contemplated. Although fig. 2 shows a single server (e.g., 210, 310, and 410) in each of the rooms, embodiments of the invention may be used with any number of servers that provide the services and functions described herein. Furthermore, the services and persistent functions provided by the application server may be housed in separate physical servers or in separate virtual servers within the same server. In some embodiments, each microservice may be deployed in multiple instances in a computing cluster. As known to those of ordinary skill in the art, the individual microservices may be hosted by the same server, different servers, or any combination thereof. The items in the storage (e.g., 220, 320, 420, and 230) may also be stored in the same server, different servers, or any combination thereof, and may also reside as application modules on the same or different servers.

As mentioned above, the business service of the present invention can be split in a micro-service manner, that is, a building block structure is adopted, so that each function in the system is split into a single micro-service with a single enough function. FIG. 3 illustrates an exemplary page of a net appointment APP. Fig. 3 may be a page displayed when a user checks a "my trip" page on a client and clicks into a specific trip, for example, after a network appointment APK issued by a tenant a to the user is installed on his smartphone, and after a user calls a car and receives travel services using the network appointment APP. The page is not a static order page, but a page aggregated by multiple microservice APIs. As shown, the page includes a map module 1, a driver information module 2, a fee module 3, an evaluation module 4, and a customer service module 5, the upper part of which displays a travel path. Each of the modules described above may be supported by one or more corresponding microservices. In other words, when the user clicks to enter a specific travel page, the cloud platform 100 does not directly provide the display of the entire page of fig. 3 via a corresponding "travel query" server, but obtains corresponding data from the corresponding path query server, driver information server, fee and invoice server, evaluation server and customer service server, respectively, and performs aggregate display according to the content contained in the request information (e.g., the order number corresponding to the travel) and the page frame of the page.

Because each function of the page is split into a single micro-service, rather than a corresponding "journey query" large service, each corresponding micro-server can concurrently obtain respective corresponding content. Further, the platform can also include a dynamic configuration module for dynamically selecting and arranging microservices according to tenant requirements. The invention realizes the capability of achieving the personalized business requirements of automatic collocation, assembly according to requirements and aggregation between the micro-services by combining the dynamic configuration module of the background. Also as shown in figure 3, in addition to the modules 1-5 described above, the service personnel of tenant a may add a notification module 6 and a disinfection query module 7 as needed. Wherein the notification may be displayed floating on the map and the disinfection query module may not be displayed in subsequent queries on the same page. Further, in this page, the evaluation module 4 may first display the mask evaluation, and the user needs to enter the star rating page by clicking "go star rating". And when the driver does not have the hard requirement of wearing the mask in the future, the service personnel of the tenant A can also conveniently modify the evaluation module 4 into a star evaluation page displayed directly.

In addition, one or more micro services in the order query page shown in fig. 3 may also be reused in other pages according to the structure setting of the APP, for example, a fee and/or invoice micro service is reused in a customer service page.

Therefore, the network appointment platform 100 of the present invention can support tenants to freely and simply go online in the background through selection and aggregation of microservices (a "building block" manner) by adopting a building block microservice splitting and dynamic configuration tenant architecture. Preferably, the system can adopt a release, deployment, flexible and high-performance RPC (Remote Procedure Call) framework to ensure the performance between microservices and avoid runtime (runtime) checkpoints.

In addition, the same microservice runs on multiple application servers in the same or different rooms, and the application server providing the microservice for the current request is determined by using an election mechanism. Specifically, the RAFT algorithm can be adopted to solve the problem of cache data consistency of the microservice application, the consistency of microservice caches in a multi-place and double-activity scene of the system is ensured, and the cross-building microservice can be mutually called. The RPC framework and RAFT algorithm described above can be viewed as the basis for implementing the service call routing 140 function. Furthermore, the route calling mode can also automatically select an Http mode (crossing a physical machine room) and a TCPRPC mode (the same machine room) according to the cluster deployment mode

When providing services for tasks (e.g., user requests) decomposed into a plurality of microservices, each application server can access required data through a data call route 150 of the system, and can be specifically used for calling required business data and/or basic data across a computer room according to service calls. For example, in order to display the travel information page shown in fig. 3 after the user clicks, the corresponding path query server, driver information server, fee and invoice server, evaluation server and customer service server may query the corresponding database to obtain corresponding data and return to the page display.

The routing of the data layer may be routed according to two levels of factors: tenant dimensions (which may also include user dimensions) and logical configurations. Different tenants use the common application server according to the corresponding traffic access rules. For example, in order to ensure that services are not unduly skewed towards a tenant during peak periods of service (e.g., peak morning and night), tenants may be uniformly routed. The unified routing configuration may be a segment of configuration file, which labels each tenant traffic access rule. The configuration file can be stored in a configuration center, and the service can pull the corresponding rule through the configuration name. Therefore, each tenant can access the corresponding service instance by reading the uniform routing configuration, so as to achieve dynamic allocation of the flow. Further, user rules may also be set. The user dimension is mainly used for grayscale verification. In addition, different service logics are also transmitted in a logic configuration mode, and logic routing is carried out at a micro-service level.

In addition to service requests made to users, the timed task programs also need to be uniformly scheduled in the tenant validation cluster dimension. The timed task class program may refer to a program that executes a certain code program periodically according to a set frequency time to yield a corresponding result, for example, a timed self-check, etc. In the case where a plurality of timing tasks exist at the same time, a certain machine may be designated to execute a certain task. To this end, a global scheduler may be set to define a particular application server to perform a certain timed task. Specifically, the global scheduler may record the current task execution state, and the task may inquire whether the scheduler is executable before executing the task, and if there is a task currently executing, the subsequent execution request for the same task may not be allowed.

In addition, the network appointment platform needs to execute the riding matching operation in real time. In an application scenario of a user ordering system order, a matching operation is involved that assigns a user order to an appropriate acquirer. For example, in a network car appointment scenario, the matching operation is a key process that the system needs to implement efficiently, namely a driver and passenger matching process, which matches an appropriate driver for each order sent by a passenger. In a specific matching process, a global optimal strategy is preferably adopted. The global optimal strategy typically involves n orders simultaneously and finds m alternative drivers. Then, q pairs (q being the smaller of n and m) of driver combinations of orders can be selected by comprehensive calculation. These combinations may not be globally optimal from a single combination point of view. But the best matching results are achieved by these combinations in view of the whole. In a scene related to the peak on duty and off duty, the driver and crew matching needs to calculate a large matrix in real time. For this reason, in a network appointment platform involving multiple tenants, a specific application server can be dynamically allocated to perform the riding matching calculation of a certain tenant. For example, several servers (e.g., M servers) in the application server 210 are exclusively allocated to the tenant C for driver-and-crew matching at a certain time, several other servers (e.g., N servers) are allocated to the tenant D, and several servers (e.g., O servers) are allocated to the tenant E. The specific servers and the number thereof participating in the driver-and-multiplier matching operation of each tenant can be dynamically configured, so that a certain computing resource is specially used for a tenant to perform driver-and-multiplier matching at a certain moment.

The network appointment platform capable of realizing dynamic tenant isolation and the corresponding processing scheme thereof are described above with reference to the accompanying drawings, and the dynamic isolation capability enables the platform to adjust physical deployment and effectively utilize resources according to the cost and business requirements of tenants.

Fig. 4 shows a schematic flowchart of a multi-tenant network appointment data processing method according to one embodiment of the present invention. The method may be implemented by a platform 100 as shown in fig. 2.

In step S410, a globally unique identifier is assigned to the generated business data of different tenants. In step S420, the generated business data entries of the different tenants are stored in the storage target corresponding to each tenant, where the entries include the globally unique identification item and the tenant identification item. Therefore, through the simultaneous storage of the global unique ID and the tenant ID, tenant isolation based on the tenant ID can be conveniently carried out, and service requests can be conveniently distributed to a plurality of related micro services and corresponding results can be conveniently returned.

When tenant type conversion is involved, the method may further include: step S430, receiving a request for converting a certain tenant data deployment type, and step S440, based on a globally located tenant identity, directly storing a service data entry stored in a current storage target of the tenant into a changed storage target.

The data deployment type comprises independent device deployment, independent table deployment and table mixed deployment, and the corresponding storage targets respectively comprise independent devices, independent tables and mixed tables. Specifically, the independent tenant a or B may be converted into a mixed tenant, or the mixed tenant C, D or E may be converted into an independent tenant, or the mixed tenant may perform conversion of an independent table or a mixed table. In any conversion, the generated business data entry comprises the global unique identification item and the tenant identification item, so that the conversion and various operations based on the global unique identification can be conveniently carried out.

Further, the homogeneous business data entries of different tenants of different data deployment types may have the same data structure. Thereby further promoting the conversion convenience of the deployment types.

The invention can support the smooth migration of data through the data bidirectional synchronization technology. In particular, data synchronization can support tenant-level isolation of data; the method can accurately control the service call routing and prevent the data conflict; the timing task program also supports global accurate scheduling; and functional atomization micro-service splitting, and breaking down to a data route according to a tenant route and a service route.

The method can also include processing the regular service data, including: receiving a service request from a client by an external call route; the service calling route calls an application server providing corresponding micro service according to the micro service included in the service request; and the corresponding application server returns a result to the external call route based on the global unique identifier, wherein the client acquires the combination to generate a corresponding display page. Further, the corresponding application server may obtain the corresponding data via a data call route and generate a result for return based on the data.

When the car calling service is involved, step S410 may include assigning a globally unique order number to the car calling operation of the current user of a certain tenant. The method may then further comprise: sending the taxi calling information to a public application server dynamically allocated to the specific tenant to execute riding and driving matching calculation; and allocating drivers to the users according to the result of the driver-and-passenger matching calculation.

Embodiments of the present invention may be provided to end users through a cloud computing infrastructure. Cloud computing generally refers to scalable computing resources provided as a service over a network. More formally, cloud computing may be defined as providing abstracted computing power between computing resources and their underlying technical architecture (e.g., servers, storage, networks), enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be quickly provisioned and released with minimal administrative cost or minimal interaction with a service provider. Thus, cloud computing allows users to access virtual computing resources (e.g., storage, data, applications, or even fully virtual computing systems) in the "cloud" regardless of the underlying physical systems (or locations of these systems) used to provide the computing resources.

Typically, cloud computing resources are provided to users on a pay-per-use basis, where the users are charged only for the computing resources actually used (e.g., the amount of storage space consumed by the user or the number of virtualized systems instantiated by the user). In the online car booking system, the user paying to the cloud can be each online car booking manufacturer, namely a tenant of the platform. The users of each vendor are charged by pricing (for passengers) and drawing (for drivers) rules within the vendor.

A user can access any resource that resides in the cloud at any time and from anywhere across the internet. In the context of the present invention, a user may access applications or related data available in the cloud. For example, the deployment conversion and business update operations of the present invention may be performed on a computing system in the cloud, thereby converting a database from one multi-tenant deployment to another, or updating a micro-service combination of a tenant. In a deployment translation operation, a database deployment may be translated and the physical data store and associated tenant metadata stored at a storage location in the cloud, thereby allowing a user to access this information from any computing system attached to a network (e.g., the internet) connected to the cloud.

The multi-tenant network appointment platform and the dynamic isolation method thereof according to the present invention have been described above in detail with reference to the accompanying drawings. According to the scheme, the global unique ID is used for storing in combination with the tenant ID, and a building block type micro-service architecture and a service call routing technology are adopted, so that dynamic data migration and data cloud storage (independent of physical storage) can be conveniently realized.

Furthermore, the method according to the invention may also be implemented as a computer program or computer program product comprising computer program code instructions for carrying out the above-mentioned steps defined in the above-mentioned method of the invention.

Alternatively, the invention may also be embodied as a non-transitory machine-readable storage medium (or computer-readable storage medium, or machine-readable storage medium) having stored thereon executable code (or a computer program, or computer instruction code) which, when executed by a processor of an electronic device (or computing device, server, etc.), causes the processor to perform the steps of the above-described method according to the invention.

Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems and methods according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Having described embodiments of the present invention, the foregoing description is intended to be exemplary, not exhaustive, and not limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen in order to best explain the principles of the embodiments, the practical application, or improvements made to the technology in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A multi-tenant network car booking system comprising:

the public tenant computer room comprises a public data storage device which deploys business data of a plurality of first tenants in independent tables or mixed tables; and

the independent tenant computer room comprises independent data service storage equipment for deploying the business data of a second tenant by using independent equipment;

the common tenant room and the independent tenant room provide a network car booking service for client devices of different tenants via external call routes of the system, and include:

distributing global unique identification for the generated business data of different tenants;

and storing the generated business data entries of the different tenants in a storage target corresponding to each tenant, wherein the entries comprise the globally unique identification items and tenant identification items.

2. The system of claim 1, wherein the common tenant room further comprises:

and the common basic data storage device is used for storing system metadata and management data.

3. The system of claim 1, wherein the independent tenant room further comprises:

and the independent basic data storage device is used for storing system metadata and management data required by providing services for the second tenant.

4. The system of claim 1, wherein the common tenant room further comprises:

and the public application server is used for splitting the network taxi appointment service into micro services for deployment and providing the services.

5. The system of claim 4, wherein the independent tenant room further comprises:

and the independent application server is used for deploying at least part of micro services of the network car-booking service required by the second tenant and providing the network car-booking service for the client equipment of the second tenant.

6. The system of claim 4, further comprising:

and the service call route is used for carrying out service call across the application servers according to the current flow and the call rule.

7. The system of claim 6, further comprising:

and the data call route is used for calling the required service data and/or basic data across the machine room according to the service call.

8. The system of claim 4, further comprising:

and the dynamic configuration module is used for dynamically selecting and arranging the microservices according to the requirements of the tenants.

9. The system of claim 4, wherein the same microservice runs on multiple application servers in the same or different rooms, and an election mechanism is utilized to determine the application server that provides the microservice for the current request.

10. The system of claim 4, wherein different tenants use the common application server according to respective traffic access rules.

11. The system of claim 4, further comprising:

and the global scheduler is used for limiting a specific application server to execute a certain timing task.

12. The system of claim 4, wherein a particular application server is dynamically allocated to perform a span matching calculation for a tenant.

13. A multi-tenant dynamic isolation method comprises the following steps:

distributing global unique identification for the generated business data of different tenants; and

14. The method of claim 13, further comprising:

receiving a request for converting a certain tenant data deployment type; and

directly storing the business data items stored in the current storage target of the tenant into the changed storage target based on the globally located tenant identification,

the data deployment type comprises independent device deployment, independent table deployment and table mixed deployment, and the corresponding storage targets respectively comprise independent devices, independent tables and mixed tables.

15. The method of claim 13, wherein homogeneous business data entries of different tenants of different data deployment types have the same data structure.

16. The method of claim 13, further comprising:

receiving a service request from a client by an external call route;

the service calling route calls an application server for providing corresponding micro service according to the micro service related to the service request; and

the corresponding application server returns a result to the external invocation route based on the globally unique identifier, wherein the client obtains the combination to generate a corresponding display page.

17. The method of claim 16, further comprising:

the corresponding application server acquires corresponding data through a data call route, and generates a result for returning based on the data.

18. The method of claim 13, wherein assigning globally unique identifications for the generated business data of different tenants comprises:

a globally unique order number is allocated for the taxi calling operation of the current user of a specific tenant,

and the method further comprises:

sending the taxi calling information to a public application server dynamically allocated to the specific tenant to execute riding and driving matching calculation; and

and allocating drivers for the users according to the result of the driver-and-passenger matching calculation.