CN112035213B - Multi-tenant network car booking system and dynamic isolation method - Google Patents

Multi-tenant network car booking system and dynamic isolation method Download PDF

Info

Publication number
CN112035213B
CN112035213B CN202010885588.9A CN202010885588A CN112035213B CN 112035213 B CN112035213 B CN 112035213B CN 202010885588 A CN202010885588 A CN 202010885588A CN 112035213 B CN112035213 B CN 112035213B
Authority
CN
China
Prior art keywords
tenant
data
service
independent
application server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202010885588.9A
Other languages
Chinese (zh)
Other versions
CN112035213A (en
Inventor
于志杰
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Bailong Mayun Technology Co ltd
Original Assignee
Beijing Bailong Mayun Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Bailong Mayun Technology Co ltd filed Critical Beijing Bailong Mayun Technology Co ltd
Priority to CN202010885588.9A priority Critical patent/CN112035213B/en
Publication of CN112035213A publication Critical patent/CN112035213A/en
Application granted granted Critical
Publication of CN112035213B publication Critical patent/CN112035213B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06Q50/40
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45587Isolation or security of virtual machine instances

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 machine room and the independent tenant machine room provide a network appointment 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 taxi appointment as a novel internet service is different from a common e-commerce or O2O (Online To Offline), and depends on Online scheduling and global information, especially, the timeliness of the information is far higher than that of the e-commerce and the O2O, and the generation of one 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. Services provided by service providers may access data stored in the database. 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 taxi appointment service, a plurality of tenants can belong to different network taxi appointment companies respectively, and the network taxi appointment 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 may 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 storage utilization rate of the method is highest, but the performance is easy to have a bottleneck along with the increase of the service. 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. Thirdly, the tenants are mixed and distributed in a plurality of physical storages, the number of the tenants on different data sources can be different according to different strategies, the expansibility and the cost are considered, the strategies are complex, the problem of uneven performance still exists after the tenant service changes, and the 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 tenants sharing business services, but data being stored independently, etc.
The existing isolation scheme has few problems under the condition that the tenant and the data volume are small, if the tenant number 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 dynamic migration of service programs and data needs to be faced when the service volume changes rapidly.
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 public 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 public 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 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 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, allocating globally unique identifiers for 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 foregoing and other objects, features and advantages of the disclosure will be apparent from the following more particular descriptions of exemplary embodiments of the disclosure as illustrated in the accompanying drawings wherein like reference numbers generally represent like parts throughout the exemplary embodiments of the disclosure.
FIG. 1 shows a schematic diagram of a cloud computing environment for implementing one embodiment of the present 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 by 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 ability to expand and contract to meet customer upgrade (e.g., service upgrade) requirements. 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 desktop computer 120_1, laptop computer 120_2, smartphone 120_3, and on-board computing system 120_4. The client devices 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 dedicated App or using a web browser to access a dedicated URL address. As shown, computing nodes 110, which are infrastructure of cloud platform 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 in one or more networks (not shown), thereby allowing 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 (e.g., access a specific address via a web browser) provided by a cloud service provider 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 ticketing, may then typically 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 generally 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 may be connected to the cloud platform 100 at present or in the future 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.
Fig. 2 is a schematic composition diagram of a multi-tenant network car booking service system according to one embodiment of the invention.
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 multiple 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 APPs 1-5. In other cases, the navigation APP may also integrate the car appointment entries of partial 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 deployments 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 machine 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 through 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 machine rooms 200, 300, and 400 that exist physically. 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-booking service system of the invention, 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 may enable 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 schemas 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 largest number of tenants.
In the invention, the system supports tenants C, D and E to select specific mixed distribution modes (for example, independent table arrangement or table mixed distribution related to different prices) in a public tenant computer room by themselves, and can also be a mode in which a platform provider selects the mixed distribution modes by self 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, relevant business data of tenants C, D, and E can be arranged with a device 220 (e.g., a 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 the network appointment service) besides different manners of isolating data. Tenants C, D, and E disposed in the 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 portals on the respective installed different web appointment APPs (e.g., APP3, APP4, and APP 5) or navigation APPs for taxi calling and ticketing operations, these operations from different APPs may operate on the same server or server cluster. In addition, while not dominant in terms of implementation cost and efficiency, tenants C, D and E may also use independently arranged application servers for the operation of related services, i.e. operations from different APPs may be operated on different servers, or at least use specially allocated servers to complete core services, e.g. department matching. For tenants a and B that use independent machine rooms to store data, it may be preferable to provide services for respective client devices 120 of tenants a and B (e.g., clients with APP1 and APP2 installed, respectively) using independently deployed servers, such as the illustrated device 310 for implementing tenant a business service and the illustrated device 410 for implementing tenant B business service, or to provide at least a portion of services using 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 of service deployment, a micro-service manner may be adopted to split a service, so that a single service application becomes sufficiently simplified 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, and is used for providing a global centralized service, 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 needs a large amount of manual participation, so that the labor cost is high and the efficiency is low. Specifically, 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 necessitate data migration (e.g., from a mix of data and services to independent deployment of data and/or services); while some tenants also have a need to reduce cost, data is migrated (e.g., from independent deployment to mixed deployment, to table independent 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 cost of manual intervention is high, and in view of the property that network appointment needs to provide service all the day long (namely, vehicle using needs also exist in early morning hours), the service needs to be prevented from being completely stopped;
3. different tenants have different business models, all functions are 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 the online risk is 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 taxi appointment 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; 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 the 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 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 storage 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 illustrative 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 persistence 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 in 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 microservice manner, that is, a building block structure is adopted, so that each function in the system is split into a single microservice 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 views a "my trip" page and clicks into a specific trip on a client after a network appointment APK issued by a tenant a to the user is installed on his smartphone, and 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 a floating display on the map and the disinfection query module may no longer display 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, ensure 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 microservices 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. Further, the route calling mode may also automatically select an Http mode (across physical machine rooms) and a TCPRPC mode (same machine room) according to the cluster deployment mode.
When providing services for tasks (e.g., user requests) that are 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, 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 the corresponding data and return it for 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 service periods (e.g., early-late peak), tenants may be uniformly routed. The unified routing configuration may be a segment of configuration file, marking 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. A timed task class program may refer to a program that periodically executes a certain piece of code program according to a set frequency and 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 and 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 takes 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-multiplier matching operation of each tenant can be dynamically configured, so that at a certain moment, a certain computing resource is specially used for one tenant to perform driver-multiplier matching.
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, by simultaneously storing the globally 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 the 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 taxi appointment system, the users paying to the cloud can be various online taxi appointment manufacturers, namely tenants 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, the 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 combined with the tenant ID for storage, 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 (10)

1. A multi-tenant network car booking system for realizing data cloud storage 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; 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 public tenant machine room and the independent tenant machine room provide network car booking service for client devices of different tenants through external call routes of the system, wherein:
distributing global unique identification for the generated business data of different tenants;
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 identifier and tenant identifier items; and is provided with
When a request for converting a certain tenant data deployment type is received, business data entries stored in a current storage target of the tenant are directly stored into a changed storage target based on the global unique identifier and the tenant identifier item, the data deployment types comprise independent device deployment, independent table deployment and mixed table deployment, and respective corresponding storage targets comprise independent devices, independent tables and mixed tables,
and wherein the common tenant room further comprises:
a common underlying data storage device for storing system metadata and management data to provide a global centralized service; and
the public application server is used for splitting the network taxi appointment service into micro-services for deployment and providing services for the client equipment of the first tenant and the client equipment of the second tenant,
and wherein the independent tenant room further comprises:
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;
the system further comprises:
the service call route is used for carrying out micro-service call between the public application server and the independent application server across the application servers according to the current flow and the call rule so as to call the application server providing the corresponding micro-service; and
and the data call route is used for calling the required service data and/or basic data across the machine room according to the micro service call of the cross-application server.
2. The system of claim 1, further comprising:
and the dynamic configuration module is used for dynamically selecting and arranging the microservices according to the requirements of the tenants.
3. The system of claim 1, 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.
4. The system of claim 1, wherein different tenants use the common application server according to respective traffic access rules.
5. The system of claim 1, further comprising:
and the global scheduler is used for limiting a specific application server to execute a certain timing task.
6. The system of claim 1, wherein the application server is dynamically allocated to perform a driver-and-crew matching calculation for a tenant.
7. 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.
8. A multi-tenant dynamic isolation method for realizing data cloud storage comprises the following steps:
deploying business data of a plurality of first tenants in independent tables or mixed tables on public data storage equipment of a public tenant computer room;
deploying service data of a second tenant by using independent equipment in independent data service storage equipment of an independent tenant machine room;
storing system metadata and management data in a public basic data storage device of the public tenant computer room to provide global centralized service;
splitting a network taxi appointment service into micro services for deployment at a public application server of the public tenant computer room, and providing services for client equipment of the first tenant and client equipment of the second tenant;
deploying at least part of micro services of the network car booking service required by the second tenant at an independent application server of the independent tenant machine room, and providing the network car booking service for client equipment of the second tenant;
distributing global unique identification for the generated business data of different tenants;
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 identifier and tenant identifier items;
in response to receiving a request for converting a certain tenant data deployment type, directly storing business data entries stored in a current storage target of the tenant into changed storage targets based on the global unique identifier and the tenant identifier item, wherein the data deployment types comprise independent device deployment, independent table deployment and mixed table deployment, and respective corresponding storage targets comprise independent devices, independent tables and mixed tables;
receiving a service request from a client of a first tenant and/or a client of a second tenant by an external call route;
the service call route carries out micro-service call between the public application server and the independent application server across the application servers according to the micro-service related to the service request so as to call the application server providing the corresponding micro-service;
the corresponding application server calls the required service data and/or basic data by crossing the machine room through a data call route, and generates a result for returning based on the data; and
and the corresponding application server returns a result to the external call route based on the global unique identifier, wherein the client side acquires the result to generate a corresponding display page.
9. The method of claim 8, wherein homogeneous business data entries of different tenants of different data deployment types have the same data structure.
10. The method of claim 8, 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 certain tenant,
and the method further comprises:
sending the taxi calling information to a public application server dynamically allocated to the tenant to execute driver and passenger matching calculation; and
and allocating drivers for the users according to the result of the driver-and-passenger matching calculation.
CN202010885588.9A 2020-08-28 2020-08-28 Multi-tenant network car booking system and dynamic isolation method Active CN112035213B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010885588.9A CN112035213B (en) 2020-08-28 2020-08-28 Multi-tenant network car booking system and dynamic isolation method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010885588.9A CN112035213B (en) 2020-08-28 2020-08-28 Multi-tenant network car booking system and dynamic isolation method

Publications (2)

Publication Number Publication Date
CN112035213A CN112035213A (en) 2020-12-04
CN112035213B true CN112035213B (en) 2023-02-10

Family

ID=73586912

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010885588.9A Active CN112035213B (en) 2020-08-28 2020-08-28 Multi-tenant network car booking system and dynamic isolation method

Country Status (1)

Country Link
CN (1) CN112035213B (en)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112631804A (en) * 2020-12-25 2021-04-09 杭州涂鸦信息技术有限公司 Service call request processing method based on isolation environment and computer equipment
CN112631527A (en) * 2021-01-07 2021-04-09 上海明略人工智能(集团)有限公司 Juypter notewood code remote storage method and device based on k8s multi-tenant
CN112818062A (en) * 2021-02-04 2021-05-18 北京易车互联信息技术有限公司 Basic data support assembly system
CN113139726A (en) * 2021-04-23 2021-07-20 北京白龙马云行科技有限公司 Multi-tenant order dispatching method and network car booking system
CN114726878B (en) * 2022-03-28 2024-02-23 广州广电运通金融电子股份有限公司 Cloud storage system, equipment and method
CN116029557A (en) * 2023-03-27 2023-04-28 北京白龙马云行科技有限公司 Network about car wind control method, system, computer equipment and storage medium
CN116455951B (en) * 2023-06-19 2023-08-18 云筑信息科技(成都)有限公司 Calling method for realizing RPC isolation of multi-tenant service based on dynamic rules
CN116743876B (en) * 2023-08-14 2023-12-08 云筑信息科技(成都)有限公司 Method for realizing multi-tenant scheduling based on xxl-job

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104160381A (en) * 2012-03-08 2014-11-19 国际商业机器公司 Managing tenant-specific data sets in a multi-tenant environment
US9342353B2 (en) * 2012-10-06 2016-05-17 International Business Machines Corporation Techniques for implementing information services with tenant specific service level agreements
CN106559488A (en) * 2016-11-24 2017-04-05 天津市普迅电力信息技术有限公司 A kind of method of the electrical network geographical information space service for setting up tenant's driving
CN109565511A (en) * 2016-09-16 2019-04-02 甲骨文国际公司 Tenant and service management for multi-tenant identity and data safety management cloud service
CN109951530A (en) * 2019-02-27 2019-06-28 上海浪潮云计算服务有限公司 A kind of Implementation Technology of multi-tenant mode
CN111478961A (en) * 2020-04-03 2020-07-31 中国建设银行股份有限公司 Multi-tenant service calling method and device

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104160381A (en) * 2012-03-08 2014-11-19 国际商业机器公司 Managing tenant-specific data sets in a multi-tenant environment
US9342353B2 (en) * 2012-10-06 2016-05-17 International Business Machines Corporation Techniques for implementing information services with tenant specific service level agreements
CN109565511A (en) * 2016-09-16 2019-04-02 甲骨文国际公司 Tenant and service management for multi-tenant identity and data safety management cloud service
CN106559488A (en) * 2016-11-24 2017-04-05 天津市普迅电力信息技术有限公司 A kind of method of the electrical network geographical information space service for setting up tenant's driving
CN109951530A (en) * 2019-02-27 2019-06-28 上海浪潮云计算服务有限公司 A kind of Implementation Technology of multi-tenant mode
CN111478961A (en) * 2020-04-03 2020-07-31 中国建设银行股份有限公司 Multi-tenant service calling method and device

Also Published As

Publication number Publication date
CN112035213A (en) 2020-12-04

Similar Documents

Publication Publication Date Title
CN112035213B (en) Multi-tenant network car booking system and dynamic isolation method
US10298666B2 (en) Resource management for multiple desktop configurations for supporting virtual desktops of different user classes
US9973571B2 (en) Migrating legacy applications to a multi-tenant computing environment
US10212050B2 (en) Providing recursively-generated instantiated computing resource in a multi-tenant environment
CN112035214B (en) Multi-tenant isolated driver and passenger matching method and system
US8930536B2 (en) Virtual private cluster
JP2020536312A (en) Utilization of microservices containers to provide tenant isolation in multi-tenant API gateways
US8676984B2 (en) Live directory of cloud tenants to enable inter-tenant interaction via cloud
CN109191008A (en) A kind of micro services frame system for fish quality supervisory systems
CN111290854A (en) Task management method, device and system, computer storage medium and electronic equipment
CN112104723B (en) Multi-cluster data processing system and method
US20160217403A1 (en) Providing resources to customers via node-relationship models
CN105074702A (en) Database system providing single-tenant and multi-tenant environments
CN104813614A (en) Asynchronous Framework For Management Of IAAS
US10728169B1 (en) Instance upgrade migration
CN113139726A (en) Multi-tenant order dispatching method and network car booking system
US11050837B2 (en) Providing cloud services associated with unused hardware resources of private cloud providers
CN103034526B (en) A kind of implementation method of virtualization services and device
Huang et al. A geospatial hybrid cloud platform based on multi-sourced computing and model resources for geosciences
CN113992680A (en) Scheduling method, device, equipment and medium applied to distributed multi-activity system
US11586470B2 (en) Scalable workflow engine with a stateless orchestrator
US20230196182A1 (en) Database resource management using predictive models
WO2022078060A1 (en) Tag-driven scheduling of computing resources for function execution
CN106022615B (en) Enterprise resource management method based on cloud computing
CN113114560B (en) Driver end instant messaging method, driver end and driver and passenger system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant