Multi-tenant-based mileage fee rationality verification

Abstract

The invention discloses mileage fee rationality verification based on multiple tenants, and relates to the field of fees of a multi-tenant aggregation taxi-taking platform, and the mileage fee rationality verification specifically comprises the following steps: 1, creating an online registration form to complete a tenant registration process, generating a tenant ID to ensure that tenant data is physically and logically isolated on a database level, the service function of the aggregation taxi-taking platform is split into a plurality of micro services, and through an API Gateway routing mechanism, it is ensured that a tenant request is correctly forwarded to a corresponding service instance. The tenant ID is generated to ensure that the tenant data is physically and logically isolated on the database level, the stability is improved through data isolation between the tenants, meanwhile, the personalized customization requirement is met, the current effective charging rule of the tenant is dynamically loaded according to the tenant ID, a localized pricing strategy is achieved, and the charging efficiency of the tenant is improved through a real-time verification mechanism and abnormity monitoring. The reasonability of mileage fee calculation is ensured, the user experience and the transparency of mileage fees are improved, and the fairness of competition between different tenants is improved.

Description

Technical Field

[0001] The present invention relates to the field of fees for a multi-tenant aggregated taxi-hailing platform, and in particular to a multi-tenant-based mileage fee rationality check. Background Art

[0002] In recent years, ride-hailing platforms have developed rapidly around the world, driving the innovation of urban travel. Consumers' demand for convenient, economical and efficient travel has increased significantly. This trend has not only spawned new market opportunities, but also brought new challenges. With the intensification of market competition, in order to meet the changing needs of users, ride-hailing platforms have gradually introduced multiple tenants to provide a wider range of service options and higher coverage. The introduction of a multi-tenant model enables the platform to integrate more resources and services, improving user selectivity. As the number of tenants increases, the platform faces more complex management tasks, especially in cost calculation and management. In a multi-tenant environment, although diversified pricing strategies can meet the needs of different users, they also increase the complexity of cost management.

[0003] In the current taxi-hailing platform, the cost management of multiple tenants is particularly complex. Each tenant may have different operating models and billing rules. This requires the taxi-hailing platform to ensure the operational independence and data isolation of each tenant to prevent data cross-talk and interference. By providing flexible billing rule customization functions to adapt to the personalized needs of each tenant, and through an effective anomaly detection mechanism, false data and fraud can be prevented.

[0004] The existing technology has the following deficiencies: the data isolation mechanism of the existing multi-tenant taxi-hailing platform is not strict enough, and there may be risks of data leakage and confusion. When the data of different tenants are stored in the same database list, data leakage may occur due to defects or configuration errors at the application level, causing the data of different tenants to be improperly accessed or tampered with, thereby affecting the integrity and reliability of the data. Traditional billing rules are static. When the billing rules change, the modification process is cumbersome and prone to errors, which can easily cause instability and data inconsistency in the taxi-hailing platform. In terms of high-concurrency data processing, the delay in the real-time calculation of fees on the existing taxi-hailing platform will cause the fees seen by users to be inconsistent with the actual situation, thereby affecting the user's trust and satisfaction with the platform. Traditional report generation methods often rely on manual intervention, and the accuracy and timeliness of the reports are difficult to guarantee.

[0005] The above information disclosed in this Background section is only for enhancement of understanding of the background of the present disclosure and therefore it may contain information that does not constitute the prior art that is already known to one of ordinary skill in the art. Summary of the invention

[0006] The purpose of the present invention is to provide a multi-tenant-based mileage fee rationality check to solve the problems in the above-mentioned background technology.

[0007] In order to achieve the above object, the present invention provides the following technical solutions:

[0008] Step 1: Create an online registration form to complete the tenant registration process, generate a tenant ID to ensure physical and logical isolation of tenant data at the database level, split the business functions of the aggregated taxi-hailing platform into multiple microservices, and use the APIGateway routing mechanism to ensure that tenant requests are correctly forwarded to the corresponding service instances;

[0009] Step 2: Define the billing rule table structure, allow billing rules to be applied to the same order at the same time, create an independent billing rule table to store the current tenant's billing rule data, synchronize it to each tenant's microservice instance in real time, and add a version number field to the billing rule table;

[0010] Step 3: Use the map service API to obtain the actual driving path of the tenant's vehicle based on the location information of the tenant's vehicle, bind the tenant rules, dynamically load the tenant's currently valid billing rules based on the tenant ID, and perform a comparison to verify the rationality of the rate;

[0011] Step 4: Use CRON to automatically generate statistical reports regularly and support multi-dimensional data grouping and aggregation by tenant, time period and order type. Use the RESTful API interface to connect the data of the aggregated taxi platform to the traffic supervision department and define the billing-related data fields to be reported;

[0012] Step 5: Define different user roles and assign corresponding permissions based on the aggregated taxi-hailing platform, use the role-based access control model to build a mapping relationship between roles and permissions, and encrypt sensitive data and transmission data of different user roles.

[0013] Preferably, an online registration form for the aggregated taxi-hailing platform is created, the upload field allows tenants to upload qualification certification documents, the input box allows tenants to enter charging standards, the text box allows tenants to describe their service areas and specific business scope, help documents are used to help tenants understand the registration process and required information, and a summary page of the information filled in by the tenant is displayed.

[0014] Preferably, a 128-bit unique identifier is generated as a tenant ID based on a timestamp using a UUID.randomUUID() command, a tenant ID field is set as a primary key through an online registration form, an independent database instance is created for each tenant, and a tenant ID is assigned to the newly created tenant. In the same database instance, a tenant ID field is added for each tenant, and data of different tenants is distinguished by the field, and the tenant ID is used as a query condition through a SELECT * FROM data_table WHERE tenant_id=? command.

[0015] Preferably, the business functions of the aggregated taxi-hailing platform are split into multiple microservices, each microservice is responsible for specific business logic, and an independent microservice instance is created and connected to the database instance according to each tenant ID, and a separate tenant ID, data, and logic are managed. The API Gateway is deployed to act as the entry point for all external requests and is responsible for routing requests to the correct microservice instance, and the routing rules of the API Gateway are configured. The tenant ID is used as the routing basis to correctly forward requests from different tenants to the corresponding microservice instance. The dynamic routing logic of the request is implemented and forwarded to the microservice instance through the API Gateway plug-in according to tenant requirements, and the access control policy is defined so that tenants can only access their own data and microservices, and the Prometheus tool is used to track the traffic of the API Gateway and the status of the microservice instance in real time.

[0016] Preferably, define the structure of the billing rule table, set the basic rate for each tenant service, store the basic rate in digital type and adjust it dynamically, set the mileage rate ladder and save it to the database through the configuration array, divide the time period into peak period and off-peak period, set different time period rates according to different time periods, map the tenant ID of the geographical area to the corresponding regional rate, allow billing rules to apply the same order at the same time, set the basic rate as the first priority rate, and the mileage rate, time period rate and regional rate as the second priority rate, create an independent billing rule table to store the current tenant's billing rule data, use cloud control to dynamically modify the rules, and synchronize them to each tenant's microservice instance in real time, and add a version number field to the billing rule table.

[0017] Preferably, the location information of the tenant's vehicle is obtained in real time using a GPS device, and a map service API is integrated to combine the location information of the tenant's vehicle with map information to obtain the driving route, road conditions and traffic information; the actual driving route of the tenant's vehicle is obtained using the map service API based on the location information of the tenant's vehicle, and tenant rules are bound to aggregate the order information of mobile phone passengers placed on the taxi platform, including the passenger's location, destination and time; the currently valid billing rules of the tenant are dynamically loaded based on the tenant ID, the database is queried to obtain the latest billing rules corresponding to the tenant ID and applied to the current order, and the corresponding charges are compared with the estimated charges on the passenger side to verify the rationality of the rates.

[0018] Preferably, the rate rationality range is set to 10% by the aggregated taxi-hailing platform, and the lower limit of the rate rationality check range is set. The specific formula is:

[0019] C min =E*(1-10%)

[0020] Among them, C min It represents the lower limit of the range of rate rationality check, E represents the estimated fare on the passenger side, and sets the upper limit of the range of rate rationality check. The specific formula is:

[0021] C max =E*(1+10%)

[0022] Among them, C max It represents the upper limit of the range of rate rationality check, and E represents the estimated fare on the passenger side.

[0023] Preferably, CRON is used to automatically generate statistical reports regularly and support multi-dimensional data grouping and aggregation based on tenants, time periods, and order types, showing the mileage rates, rate fluctuation trends, and anomalies of different tenants. Data visualization is performed through BI tools, and passenger accounts in the database with "too low fees" and "too high fees" are marked. Reports are generated and provided to the operation team of the aggregated taxi platform for intervention, allowing tenants to customize report content and time, and using the RESTful API interface to connect the data of the aggregated taxi platform to the traffic regulatory department, define the billing-related data fields to be reported, set automated scheduled tasks for data integrity checks, and report data regularly at the time intervals required by the traffic regulatory department.

[0024] Preferably, different user roles are defined and corresponding permissions are assigned according to the aggregated taxi-hailing platform, a role-based access control model is used to build a mapping relationship between roles and permissions, permission groups are created to define common permissions, database role verification logic is added, user role access behaviors are recorded, a real-time monitoring mechanism is implemented to detect abnormal access behaviors, the AES-256 algorithm is selected to encrypt sensitive data of different user roles, AWS KMS is used to generate, store and manage encryption keys, the transmitted data is encrypted through the TLS protocol, and the RESTful API interface is encrypted using the HTTPS protocol.

[0025] In the above technical solution, the technical effects and advantages provided by the present invention are:

[0026] By allocating independent database instances to each tenant and using tenant IDs for data isolation, we ensure the security and privacy of tenant data. The dynamic routing function of Gateway can flexibly manage and expand the business logic of the platform, improve the flexibility and maintainability of the system, use UUID to generate a unique tenant ID, and ensure the accuracy and consistency of tenant data through primary key settings and query conditions. Using Prometheus for traffic and status monitoring helps to timely discover and solve problems and optimize system performance. Through detailed registration forms and help documents, the registration process of tenants is simplified, and the accuracy of information is ensured through the summary page. By managing the basic rate, mileage rate, time period rate and regional rate separately and setting priorities, the billing rules can be dynamically adjusted and adapted to different business needs. By configuring arrays to save mileage rate ladders, different mileage segment charges can be flexibly handled. By dividing time periods and setting different rates, dynamic pricing can be performed for different needs and time periods. The tenant ID of the geographical area corresponds to the regional rate to implement a localized pricing strategy. The cloud control is used to dynamically modify the rules and synchronize them to the microservice instances of each tenant in real time, reducing the delay caused by rule changes and improving the flexibility and response speed of the system. By adding a new version number field, it is ensured that each rule update has a clear version number. Identification is easy to trace and audit, ensuring that the historical change records of billing rules are traceable. The current effective billing rules of the tenant are dynamically loaded according to the tenant ID to ensure the real-time update and applicability of the billing rules, improve the flexibility and accuracy of billing, and effectively monitor the rationality of billing by setting the scope of rate rationality verification, and automatically audit according to the set rationality range. Statistical reports are automatically generated through CRON tasks to reduce manual intervention and improve efficiency. It supports data grouping and aggregation by tenant, time period and order type, helping the operation team to more accurately analyze cost fluctuations and abnormal situations. BI tools are used to display mileage rates and rate fluctuation trends, making trends and anomalies clear at a glance and assisting decision-making. Different user roles are defined and corresponding permissions are assigned to improve the security and management efficiency of the taxi platform. Permission groups are created and general permissions are defined. Database role verification logic is added to record the access behavior of user roles, and a real-time monitoring mechanism is implemented to detect abnormal access behavior. Potential security threats or abnormal activities can be discovered and responded to in a timely manner. Sensitive data and transmission data are encrypted to ensure the security of data during storage, and the security of data during network transmission is protected to prevent data from being stolen or tampered with. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0028] Figure 1 The present invention is a flowchart of the mileage fee rationality verification based on multiple tenants. DETAILED DESCRIPTION

[0029] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in a variety of forms and should not be construed as limited to the examples set forth herein; rather, these example embodiments are provided so that the description of the present disclosure will be more comprehensive and complete, and the concept of the example embodiments will be fully conveyed to those skilled in the art.

[0030] The present invention provides Figure 1 The mileage fee rationality check based on multi-tenancy shown specifically includes the following steps:

[0031] Step 1: Create an online registration form to complete the tenant registration process, generate a tenant ID to ensure physical and logical isolation of tenant data at the database level, split the business functions of the aggregated taxi-hailing platform into multiple microservices, and use the APIGateway routing mechanism to ensure that tenant requests are correctly forwarded to the corresponding service instances;

[0032] Create an online registration form for the aggregated ride-hailing platform and ensure that the form has necessary instructions to help tenants of the aggregated ride-hailing platform complete the form. Provide tenants with the ability to upload qualification certification documents through the upload field. Use the input box to allow tenants to enter charging standards, including basic fees, mileage fees, and time fees. Use the text box to allow tenants to describe their service areas and specific business scope. Use help documents to help tenants understand the registration process and required information. Display a summary page of the information filled in by tenants for tenants to verify the accuracy of the registration information.

[0033] Use the UUID.randomUUID() command and generate a 128-bit unique identifier as the tenant ID based on the timestamp to ensure that each tenant ID is unique in the database. Set the tenant ID field as the primary key through the online registration form to ensure uniqueness. Create a separate database instance for each tenant and assign the tenant ID to the newly created tenant. In the same database instance, add a tenant ID field for each tenant to distinguish the data of different tenants through this field. Use the tenant ID as the query condition through the SELECT * FROM data_table WHERE tenant_id = ? command.

[0034] The business functions of the aggregated taxi-hailing platform are split into multiple microservices. Each microservice is responsible for specific business logic, including mileage verification service, tenant management service, and billing service. An independent microservice instance is created according to each tenant ID and connected to the database instance, and separate tenant IDs, data, and logic are managed. API Gateway is deployed to serve as the entry point for all external requests and is responsible for routing requests to the correct microservice instance. The routing rules of API Gateway are configured, and the tenant ID is used as the routing basis to correctly forward requests from different tenants to the corresponding microservice instance. According to tenant requirements, the dynamic routing logic of the request is implemented through the API Gateway plug-in and forwarded to the microservice instance. The access control policy is defined so that tenants can only access their own data and microservices to prevent data leakage between tenants. The Prometheus tool is used to track the traffic of API Gateway and the status of microservice instances in real time, which is helpful for troubleshooting and performance optimization.

[0035] Step 2: Define the billing rule table structure, allow billing rules to be applied to the same order at the same time, create an independent billing rule table to store the current tenant's billing rule data, synchronize it to each tenant's microservice instance in real time, and add a version number field to the billing rule table;

[0036] Define the structure of the billing rule table, set the basic rate for each tenant service, store the basic rate as a digital type and adjust it dynamically, set the mileage rate ladder and save it to the database through the configuration array, charge a fixed fee for the first 10 kilometers of tenant service, and then increase by 1.5 yuan per kilometer, divide the time period into peak period and off-peak period, set different time period rates according to different time periods, map the corresponding regional rates by the tenant ID of the geographical area, and set different regional rates for different regions, allow billing rules to apply the same order at the same time, and set the basic rate as the first priority rate, and the mileage rate, time period rate and regional rate are listed as the second priority rate, create an independent billing rule table to store the current tenant's billing rule data, the billing rule table includes rule ID, rule content, creation time and update time, use cloud control to dynamically modify the rules, and synchronize them to the microservice instances of each tenant in real time to reduce delays caused by rule changes, and add a version number field to the billing rule table. Each time the rule is updated, the version number is incremented to ensure that it can be traced back to the specific version.

[0037] Step 3: Use the map service API to obtain the actual driving path of the tenant's vehicle based on the location information of the tenant's vehicle, bind the tenant rules, dynamically load the tenant's currently valid billing rules based on the tenant ID, and perform a comparison to verify the rationality of the rate;

[0038] Use GPS devices to obtain the location information of tenant vehicles in real time, integrate map service API to combine the location information of tenant vehicles with map information to obtain driving routes, road conditions and traffic information, use map service API to obtain the actual driving route of tenant vehicles based on the location information of tenant vehicles, bind tenant rules, aggregate order information placed by mobile passengers on the taxi platform, including passenger location, destination and time, dynamically load the tenant's currently valid billing rules based on the tenant ID, query the database to obtain the latest billing rules corresponding to the tenant ID and apply them to the current order, compare the corresponding charges with the passenger-side estimated charges to verify the rationality of the rate.

[0039] The reasonableness range of the fare is set to 10% through the aggregated taxi-hailing platform, and the lower limit of the reasonableness range of the fare is set. The specific formula is:

[0040] C min =E*(1-10%)

[0041] Among them, C min It represents the lower limit of the range of rate rationality check, E represents the estimated fare on the passenger side, and sets the upper limit of the range of rate rationality check. The specific formula is:

[0042] C max =E*(1+10%)

[0043] Among them, C max It represents the upper limit of the range of rate rationality check, E represents the estimated fee on the passenger side, and sets the upper limit of the range of rate rationality check. When the chargeable fee is less than the lower limit of the range of rate rationality check, it is recorded as "too low fee" through the database and an alarm is triggered, notifying the operator of the aggregated taxi platform for review. When the chargeable fee is greater than the upper limit of the range of rate rationality check, it is recorded as "too high fee" through the database and an alarm is triggered, notifying the operator of the aggregated taxi platform for review. When the chargeable fee is between the upper and lower limits of the range of rate rationality check, it is recorded as "reasonable fee" through the database and the order is continued to be processed. When "too low fee" or "too high fee" occurs, the billing rules of the current order are contacted to the passenger via SMS through the database and used as the basis for calculating the fee of the current order.

[0044] Step 4: Use CRON to automatically generate statistical reports regularly and support multi-dimensional data grouping and aggregation by tenant, time period and order type. Use the RESTful API interface to connect the data of the aggregated taxi platform to the traffic supervision department and define the billing-related data fields to be reported;

[0045] CRON is used to automatically generate statistical reports regularly and support multi-dimensional data grouping and aggregation by tenant, time period and order type, showing the mileage rates, rate fluctuation trends and anomalies of different tenants. Data visualization is performed through BI tools to help the operation team of the aggregated taxi platform quickly identify trends and anomalies, mark passenger accounts with "too low fees" or "too high fees" in the database, generate reports and provide them to the operation team of the aggregated taxi platform for intervention, allow tenants to customize report content and time to meet different monitoring needs, use RESTful API interface to connect the data of the aggregated taxi platform to the traffic supervision department, define the reported billing-related data fields, including actual mileage, receivables, used billing rules, driver tenant information and passenger information, to ensure the structure and accessibility of data, set up automated scheduled tasks for data integrity checks, and report data regularly at the time intervals required by the traffic supervision department to avoid compliance risks caused by data errors.

[0046] Step 5: Define different user roles and assign corresponding permissions based on the aggregated taxi-hailing platform, use the role-based access control model to build a mapping relationship between roles and permissions, and encrypt sensitive data and transmission data of different user roles;

[0047] According to the aggregated taxi-hailing platform, different user roles are defined and corresponding permissions are assigned, including administrators, tenants, passengers, and operation teams. The role-based access control model is used to build a mapping relationship between roles and permissions, and permission groups are created to define common permissions. Database role verification logic is added to improve the security of user role login, record user role access behavior, and implement a real-time monitoring mechanism to detect abnormal access behavior. The AES-256 algorithm is selected to encrypt sensitive data of different user roles. AWS KMS is used to generate, store, and manage encryption keys. The transmitted data is encrypted through the TLS protocol to ensure the security of data during network transmission. The RESTful API interface is encrypted using the HTTPS protocol.

[0048] The above description is only by way of illustration of certain exemplary embodiments of the present invention. It is undoubted that those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the above drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.

Claims

1. Mileage fee rationality check based on multiple tenants, characterized by: The following steps are involved: Step 1: Create an online registration form to complete the tenant registration process, generate a tenant ID to ensure physical and logical isolation of tenant data at the database level, split the business functions of the aggregated taxi-hailing platform into multiple microservices, and use the API Gateway routing mechanism to ensure that tenant requests are correctly forwarded to the corresponding service instances; Step 2: Define the billing rule table structure, allow billing rules to be applied to the same order at the same time, create an independent billing rule table to store the current tenant's billing rule data, synchronize it to each tenant's microservice instance in real time, and add a version number field to the billing rule table; Step 3: Use the map service API to obtain the actual driving path of the tenant's vehicle based on the location information of the tenant's vehicle, bind the tenant's rules, dynamically load the tenant's currently valid billing rules based on the tenant ID, and perform a comparison to verify the rationality of the rate; Step 4: Use CRON to automatically generate statistical reports regularly and support multi-dimensional data grouping and aggregation by tenant, time period and order type. Use the RESTful API interface to connect the data of the aggregated taxi platform to the traffic supervision department and define the billing-related data fields to be reported; Step 5: Define different user roles and assign corresponding permissions based on the aggregated taxi-hailing platform, use the role-based access control model to build a mapping relationship between roles and permissions, and encrypt sensitive data and transmission data of different user roles.

2. The multi-tenant based mileage fee rationality check according to claim 1 is characterized by: In the step one, an online registration form for the aggregated taxi-hailing platform is created, an upload field is used to allow tenants to upload qualification certification documents, an input box is used to allow tenants to enter charging standards, a text box is used to allow tenants to describe their service areas and specific business scopes, a help document is used to help tenants understand the registration process and required information, and a summary page of the information filled in by the tenant is displayed.

3. The multi-tenant based mileage fee rationality check according to claim 1 is characterized by: In the step 1, a 128-bit unique identifier is generated based on the timestamp using the UUID.randomUU ID() command as the tenant ID, the tenant ID field is set as the primary key through the online registration form, an independent database instance is created for each tenant and the tenant ID is assigned to the newly created tenant, the business functions of the aggregated taxi-hailing platform are split into multiple microservices, each microservice is responsible for specific business logic, an independent microservice instance is created and connected to the database instance according to each tenant ID, and separate tenant IDs, data, and logic are managed, an API Gateway is deployed to act as the entry point for all external requests and is responsible for routing requests to the correct microservice instance, the tenant ID is used as the routing basis to correctly forward requests from different tenants to the corresponding microservice instance, the dynamic routing logic of the request is implemented through the API Gateway plug-in according to tenant requirements and forwarded to the microservice instance, and the Prometheus tool is used to track the traffic of the API Gateway and the status of the microservice instance in real time.

4. The multi-tenant based mileage fee rationality check according to claim 1 is characterized by: In the step 2, the structure of the billing rule table is defined, the basic rate for each tenant service is set, the basic rate is stored in a digital type and dynamically adjusted, the mileage rate ladder is set and saved to the database through the configuration array, the time period is divided into peak period and off-peak period, different time period rates are set according to different time periods, the tenant ID of the geographical area is mapped to the corresponding regional rate, the billing rules are allowed to apply to the same order at the same time, and the basic rate is set as the first priority rate, the mileage rate, time period rate and regional rate are listed as the second priority rate, and an independent billing rule table is created to store the billing rule data of the current tenant, and the rules are dynamically modified by cloud control, and synchronized to the microservice instances of each tenant in real time, and a version number field is added to the billing rule table.

5. The multi-tenant based mileage fee rationality check according to claim 1 is characterized by: In the step three, the GPS device is used to obtain the location information of the tenant's vehicle in real time, and the map service API is integrated to combine the location information of the tenant's vehicle with the map information to obtain the driving path, road conditions and traffic information. The map service API is used to obtain the actual driving path of the tenant's vehicle based on the location information of the tenant's vehicle, bind the tenant rules, aggregate the order information of the mobile phone passengers on the taxi platform, including the passenger's location, destination and time, dynamically load the tenant's currently valid billing rules based on the tenant ID, query the database to obtain the latest billing rules corresponding to the tenant ID and apply them to the current order, and compare the corresponding charges with the passenger's estimated charges to verify the rationality of the rate.

6. The multi-tenant based mileage fee rationality check according to claim 5 is characterized by: The reasonableness range of the fare is set to 10% through the aggregated taxi-hailing platform, and the lower limit of the reasonableness range of the fare is set. The specific formula is: C min =E*(1-10%) Among them, C min It represents the lower limit of the range of rate rationality check, E represents the estimated fare on the passenger side, and sets the upper limit of the range of rate rationality check. The specific formula is: C max =E*(1+10%) Among them, C max It represents the upper limit of the range of rate rationality check, and E represents the estimated fare on the passenger side.

7. The multi-tenant based mileage fee rationality check according to claim 1 is characterized by: In the step 4, CRON is used to automatically generate statistical reports regularly and support multi-dimensional data grouping and aggregation by tenant, time period and order type, showing the mileage rates, rate fluctuation trends and abnormal situations of different tenants, and using BI tools to visualize data, generate reports and provide them to the operation team of the aggregated taxi-hailing platform for intervention, allowing tenants to customize the report content and time, and use the RESTful API interface to connect the data of the aggregated taxi-hailing platform to the traffic supervision department, define the billing-related data fields to be reported, and set automated scheduled tasks to perform data integrity checks.

8. The multi-tenant based mileage fee rationality check according to claim 1 is characterized by: In the step five, different user roles are defined and corresponding permissions are assigned according to the aggregated taxi-hailing platform, a role-based access control model is used to build a mapping relationship between roles and permissions, a permission group is created to define common permissions, database role verification logic is added, the access behavior of user roles is recorded, a real-time monitoring mechanism is implemented to detect abnormal access behavior, the AES-256 algorithm is selected to encrypt sensitive data of different user roles, AWS KMS is used to generate, store and manage encryption keys, the transmitted data is encrypted through the TLS protocol, and the RESTful API interface is encrypted using the HTTPS protocol.

Images