Backend service processing method, apparatus, device, storage medium, and product

Abstract

The application relates to the computer technical field and discloses a backend service processing method and device, equipment, a storage medium and a product. The method comprises the following steps: in response to a project starting request of a target project, scanning a target class file corresponding to the target project, and loading a target class in the target class file into a corresponding manager; querying target data matched with a model class from a preset data source, binding the target data with a model in the model class to obtain a target model; calling a detector corresponding to the target model from a manager storing the detector class, and executing a project starting process based on the detector; and after completing the project starting process, calling a processor corresponding to the target service from a manager storing the processor class, and executing business logic corresponding to the target model through the processor. In the application, the data source can be centrally managed, the business processing is concentrated in the processor, and the newly-added function only needs to be expanded to the processor, so that the business development is more convenient.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a back-end business processing method, apparatus, device, storage medium, and product. Background Technology

[0002] Traditional backend systems primarily employ a three-tier architecture, dividing the application into a presentation layer (Controller), a business logic layer (Service), and a data access layer (DAO). In this layered architecture, the presentation layer does not directly interact with the data access layer; instead, it accesses it indirectly through the business logic layer. After receiving a user request, the presentation layer calls the interfaces provided by the business logic layer to perform business processing. The business logic layer then calls the interfaces of the data access layer for data access and persistence operations. This design allows each layer to focus on its specific responsibilities while also facilitating code testing and maintenance.

[0003] However, under this architecture, even simple CRUD operations require layered calls through a three-tier architecture, resulting in low flexibility. Furthermore, as business becomes more complex and new business services are continuously added, the business logic layer also grows larger. The excessive concentration of business logic in the business logic layer leads to a structure containing a large amount of irrelevant logic, making it difficult to maintain. Moreover, under this architecture, the data source can only be the database. With the data access layer directly coupled to the ORM (Object-Relational Mapping) framework, if the persistence technology needs to be changed, a large amount of data access layer code needs to be rewritten, which is difficult to meet the needs of efficient expansion and rapid iteration of backend business. Summary of the Invention

[0004] The main purpose of this application is to provide a backend business processing method, apparatus, device, storage medium and product, which aims to solve the technical problem that traditional three-tier architecture backend systems cannot meet the needs of efficient expansion and rapid iteration of backend business.

[0005] To achieve the above objectives, this application proposes a backend business processing method, which includes: In response to the project startup request of the target project, the target class files corresponding to the target project are scanned, and the target classes in the target class files are loaded into the corresponding manager. The target classes include model classes, detector classes and processor classes. The target data matching the model class is queried from the preset data source, and the target data is bound to the model in the model class to obtain the target model. The model is a basic model abstracted from the target business in the target project. From the manager storing the detector classes, the detector corresponding to the target model is invoked, and the project startup process is executed based on the detector; After completing the project startup process, the processor corresponding to the target business is called from the manager storing the processor classes, and the business logic corresponding to the target model is executed through the processor.

[0006] Optionally, the target class further includes an annotation class. The step of querying target data matching the model class from a preset data source, binding the target data to the model in the model class, and obtaining the target model includes: Extract the annotation classes and model classes from the manager; The data source type corresponding to the model class is determined based on the annotation class information, and a container model is created based on the data source type; Obtain the target data for the container model query from the preset data source; The target data is bound to the model in the model class to obtain the target model.

[0007] Optionally, the step of calling the detector corresponding to the target model from the manager storing the detector classes and executing the project startup process based on the detector includes: Invoke the container detector of the detector class manager in the manager; The appropriate target detector is invoked from the detector class manager using the target model and the container detector. The target model is initialized and configured according to the target detector, and the project startup process is executed.

[0008] Optionally, the target detector includes an incoming detector and an outgoing detector; The step of initializing the target model according to the target detector includes: An inbound endpoint listening connection is established through the inbound detector; The outgoing detector loads the application programming interface data and binds the interface data to the current container and endpoint.

[0009] Optionally, the step of executing the business logic corresponding to the target model through the processor includes: The processor invokes global context information, which includes the target data bound to the target model and preset business rules. Based on the preset business rules, the target data is processed to obtain the business processing result; The business processing result is stored in the global context information so that the downstream processor of the target model can call it.

[0010] Optionally, after the step of calling the detector corresponding to the target model from the manager storing the detector classes and executing the project startup process based on the detector, the method further includes: Based on the preset data source, query the registration center data corresponding to the backend device; Register the target project to the registry center based on the registry center data.

[0011] Furthermore, to achieve the above objectives, this application also proposes a back-end service processing apparatus, which includes: The class loading module is used to respond to the project startup request of the target project, scan the target class files corresponding to the target project, and load the target classes in the target class files into the corresponding manager. The target classes include model classes, detector classes and processor classes. The data binding module is used to query target data that matches the model class from a preset data source, bind the target data to the model in the model class, and obtain the target model. The model is a basic model abstracted from the target business in the target project. The project startup module is used to call the detector corresponding to the target model from the manager storing the detector classes, and execute the project startup process based on the detector; The business execution module is used to call the processor corresponding to the target business from the manager storing the processor classes after the project startup process is completed, and execute the business logic corresponding to the target model through the processor.

[0012] In addition, to achieve the above objectives, this application also proposes a back-end service processing device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the back-end service processing method as described above.

[0013] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the back-end business processing method described above.

[0014] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the backend business processing method described above.

[0015] This application abstracts corresponding models based on business needs and dynamically binds these models to data sources. Unlike the three-tier architecture where data sources can only be databases, the data sources in this model are more flexible and easily expandable. Adding different data sources later only requires defining different data source types in the data source model, enabling centralized management of data sources. Simultaneously, business processing is centralized in the processor; new business processing functions only require extending the processor without modifying the architecture, facilitating later maintenance and making business development more convenient and adaptable to multiple business scenarios. Furthermore, when the project starts, class files can be pre-loaded and cached in the manager. Subsequent business processes (such as data binding, startup configuration, and business execution) do not require repeated scanning of class files; the required classes can be directly and accurately called from the corresponding manager, reducing resource consumption. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating the first embodiment of the backend business processing method of this application; Figure 2 This is a schematic diagram of the system architecture for the backend business processing method in this application; Figure 3 This is a flowchart illustrating the second embodiment of the backend business processing method of this application; Figure 4 A flowchart illustrating the project startup process for the backend business processing method in this application; Figure 5 This is a flowchart illustrating the third embodiment of the backend business processing method of this application; Figure 6 This is a schematic diagram of the module structure of the backend business processing device in an embodiment of this application; Figure 7 This is a schematic diagram of the device structure of the hardware operating environment involved in the backend business processing method in the embodiments of this application.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] Traditional backend systems primarily employ a three-tier architecture. This approach hinders future scalability, making it difficult to split modules into separate projects. This application abstracts different business logic into corresponding models, and business attributes into model data. The corresponding models are loaded upon project startup and stored in a model manager. Models are created first, then their behaviors are specified, with the behavior determined by the data item (dataId). This approach differs significantly from traditional three-tier architectures, prioritizing the model and ultimately managing it within a container. It features a clear hierarchical structure and decoupling from business logic.

[0023] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, data retrieval, and program execution functions, such as a computer, or an electronic device capable of performing the above functions. The following description uses a backend device as an example to illustrate this embodiment and the subsequent embodiments.

[0024] Based on this, the embodiments of this application provide a backend business processing method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the backend business processing method of this application.

[0025] In this embodiment, the backend business processing method includes: Step S10: In response to the project startup request of the target project, scan the target class file corresponding to the target project, and load the target class in the target class file into the corresponding manager. The target class includes model class, detector class and processor class.

[0026] It should be noted that the target project can be a collection of applications or modules in the backend device that are to be started and process specific business operations; the command signal that triggers the target project to start can be initiated by user operation, scheduled task, or other business modules. The target class file is a code file containing the business logic and component definitions of the target project. The target class is the core unit with independent functions in the file, including model classes, detector classes, and processor classes, etc. The manager is a container used to classify, store, and manage target classes of corresponding types. For example, the model manager ModelManager manages and stores model classes to achieve orderly scheduling of class resources. Furthermore, in order to achieve automation and low coupling of data-driven models by annotating core classes, defining association rules, and supporting manager control, the target class can also include annotation (@Cubelet) classes. When the project starts, classes with @Cubelet are scanned and loaded into the annotation class manager CubeleteManager.

[0027] It should be understood that upon receiving a startup request from the target project, the backend device automatically triggers a class file scanning mechanism. This mechanism traverses all class files contained in the target project, and based on preset classification rules (such as class annotation identifiers and functional descriptions), it selects model classes, annotation classes, detector classes, and processor classes from the class files. These target classes are then loaded into their respective managers. These four types of class files are stored in an orderly manner by type within their respective managers (such as ModelManager and CubeletManager), avoiding the confusion caused by mixing different functional classes. Furthermore, the classes are pre-loaded and cached in the managers during project startup, eliminating the need for repeated scanning of class files in subsequent business processes (such as data binding, startup configuration, and business execution). The required classes can be directly and accurately called from the corresponding managers, reducing resource consumption.

[0028] It should be understood that in this embodiment, the manager isolates the storage and business logic between class files. As an intermediary hub, the manager enables rapid association and invocation between classes and can obtain detectors adapted to the target model from the DetectorManager, ensuring the continuity of the business chain. At the same time, when adding a new business, only the corresponding class needs to be added and loaded into the manager at subsequent startups, without modifying the existing architecture (such as only extending the processor class when adding a new business), which solves the problems of tight coupling and difficult expansion in the traditional three-tier architecture.

[0029] Understandably, the models in the model class are the basic models abstracted from the business logic of the project. All models are scanned and loaded into the ModelManager when the project starts for subsequent use. The annotation class file is used to describe the metadata information of the class or property, such as configuration rules and relationships. When the project starts, classes with @Cubelet need to be scanned and loaded into the CubeletManager.

[0030] Understandably, detectors are bound to models. After the project starts and loads the model and model data, different detectors are used for different models to handle the logic of that model during startup. Subsequent project startups scan the detector classes, load them into the DetectorManager, call and find the corresponding detectors, and execute the startup process. For example, in this project, the DsicContainerDetector (container detector) mainly includes the DsicOutboundDetector (outbound detector) and the DsicInboundDetector (inbound detector). The outbound and inbound detectors are mainly used to listen to their own ports and load their own API data.

[0031] It should be understood that processors are primarily used to handle the business logic and functionalities corresponding to each model. When the project starts, the processor classes are scanned and loaded into the ProcessorManager for subsequent calls and lookups. Furthermore, most of the business logic in this project is implemented within their respective processors, allowing for flexible business development. New business logic can be added simply by adding a corresponding new processor, making it easy and convenient.

[0032] Step S20: Query target data that matches the model class from the preset data source, bind the target data to the model in the model class to obtain the target model, which is a basic model abstracted from the target business in the target project.

[0033] It's important to note that preset data sources refer to various data carriers pre-configured in the backend devices for storing business data. These carriers provide corresponding data for the model. Since the model is abstracted from business logic and can be of many types, the data source can include local files, databases, registry centers, service governance systems, configuration centers, etc. When the project starts and loads the model, it can query the corresponding data source to obtain the model's data. Target data is the specific data retrieved from the preset data source that matches the model's class attributes and business requirements.

[0034] It should be understood that the target model is an instantiated model formed by binding target data with the model, which can be directly used for business processing, integrating abstract model structure and specific business data. When the system starts or a business is triggered, based on a predefined model class (such as an abstract class describing the structure of business entities), and coordinated by components such as CubeletManager, it extracts and matches real data from multiple sources such as databases (such as business data table records), configuration files (such as parameter configuration items), and registry centers (such as service node information) according to the data source association rules defined in the @Cubelet annotated class. Finally, it dynamically binds the structural definition information of the model class with the actual business data from multiple data sources to form a complete instance. The target model retains the abstract description of business entities (such as attributes and relationships) from the model class, and integrates real-time or static data, which can be directly used as the operation object for business logic (such as data validation, process execution, and result return).

[0035] Understandably, when loading data from a data source into a model, the corresponding model manager is first called to obtain the model class, data is queried from the data source, and the data is then bound to the corresponding model. The main data sources include local files, databases, service governance, configuration centers, and registry centers, encompassing containers, endpoints, APIs, keymsg, forwarding rules, and routing rules, all of which are read from local files. Application and API data originate from two sources, primarily local files and service governance.

[0036] Understandably, during the project startup initialization phase, after data binding is completed, the target model will be instantiated and persisted to a cache, such as memory or a distributed cache, depending on the system configuration. When business logic is called subsequently, the processor will directly retrieve the target model instance from the cache to execute the project startup process, avoiding repeated binding and initialization and improving call efficiency.

[0037] It should be understood that by binding data and models through querying data from the data source, a data-driven model is achieved. Furthermore, the data source is flexible, with multiple different types of data sources available. Unlike traditional three-tier architectures where the data source is limited to a database, adding a different data source requires additional development and leads to messy data source management, the model's data source is more flexible and extensible. Adding different data sources later only requires defining different data source types and key attributes in the data source model, which can then be used in the project. Centralized management of different data sources facilitates later maintenance.

[0038] Furthermore, to enable centralized management, easy expansion, and flexible configuration of data sources, and to implement data-driven models for various data sources of different types, the target class also includes annotation classes. Step S20 may include: Extract annotation classes and model classes from the manager; determine the data source type corresponding to the model class based on the annotation class information, and create a container model based on the data source type; obtain the target data queried by the container model from the preset data source; bind the target data to the model in the model class to obtain the target model.

[0039] It should be noted that data source type is a category of data sources classified according to the data storage format and access method, such as relational databases, cache databases, configuration files, etc.; the container model is a data query carrier created based on the data source type, used to adapt to specific data source access rules, and encapsulates data source connection parameters, query statement templates, etc.

[0040] Understandably, the metadata information defined in the annotation class determines the data source type corresponding to the model class. Then, an adapted container model is created based on this type. The container model queries the target data from the preset data source, and finally, the target data is bound to the model in the model class to generate the target model. By using annotation classes to dynamically associate the model class with the data source, and leveraging the container model to adapt to the access logic of different data sources, this avoids the problem of hard-coded coupling between the data source and the business model in traditional architectures. It automates data querying and model binding, improving the flexibility of business adaptation to different data sources.

[0041] It should be understood that annotation classes support multiple data source identifier configurations (such as @MultiDataSource), and the container model dynamically selects the data source based on the business scenario. Common query logic such as data pagination and filtering can be integrated into the container model, reducing redundant development. Furthermore, when an annotation class specifies multiple data sources, the container model queries them sequentially according to a preset priority, prioritizing the acquisition of target data from available data sources.

[0042] Step S30: From the manager storing the detector classes, call the detector corresponding to the target model, and execute the project startup process based on the detector.

[0043] It should be noted that the manager storing the detector classes can be a DetectorManager. Once the model is populated with data, the corresponding detector for the target model can be called from the DetectorManager. This involves calling the corresponding implementation of the detector for that model. For example, the DsicEndpointDetector in the DetectorManager can be called to handle endpoint loading and binding to the current container. API data is queried from the local data source and service governance data source, and then bound to the current container and endpoint. The address and endpoint are bound, a socket connection is created, and the corresponding endpoint is listened to.

[0044] Understandably, the manager retrieves the associated detector based on the target model's identification information, calls the detector to initialize the target model (such as parsing network parameters, loading interface data, establishing communication connections, etc.), and finally brings the target project to a ready state where executable business logic can be achieved.

[0045] It should be understood that if a step fails during project startup (such as a network connection timeout), the detector records the breakpoint state, and execution resumes directly from the breakpoint upon restart, reducing repetitive operations.

[0046] Step S40: After completing the project startup process, the processor corresponding to the target business is called from the manager storing the processor classes, and the business logic corresponding to the target model is executed through the processor.

[0047] It should be noted that the processor is mainly used to handle the business logic and functional implementation corresponding to each model. Obtaining the processor corresponding to the target business from the manager can be done by obtaining the processor corresponding to the target business from the ProcessorManager.

[0048] Specifically, the manager matches the corresponding processor based on the identifier of the target business (such as business code, function type). The processor completes the processing by calling the attribute data of the target model and following the built-in business rules (such as data calculation, process jump, result verification, etc.) and generates business results.

[0049] In one example, reference Figure 2 , Figure 2This is a schematic diagram of the system architecture for the backend business processing method in this application. The logical results of the system include models, data sources, detectors, and processors. The model is a basic model abstracted from the business logic in the project, including entities such as disk containers (DiscContainer), applications (App), check entities (CheckEntity), endpoints (Endpoint), transfers, disk service routing rules (DiscServiceRouterRule), interfaces (Api), disk HTTP protocols (DiscHttpProtocol), key messages (KeyMsg), and flow control (FlowControlModel), used to abstract and define various business scenarios and data structures. The data source provides various data storage and management carriers such as local files, databases, configuration centers, registry centers, and service governance, supporting the storage and retrieval of business data. The detectors include container detectors (DiscContainer Detector), endpoint detectors (DiscEndpoint Detector), outbound detectors (DiscOutbound Detector), and inbound detectors (DiscInbound Detector), responsible for detection and initialization work during project startup and other processes. The processor module includes local container processor DiscContainerLocalProcessor, key message processor KeyMessage, HTTP protocol processor DiscHttpProtocol Processor, flow control processor flowcontrol, IoT router Iorouter, etc., which are used to execute specific business logic processing tasks.

[0050] In this embodiment, a corresponding model is abstracted based on business needs, and the model is dynamically bound to the data source. Unlike the three-tier architecture where the data source can only be a database, the data source of the model is more flexible and easily expandable. If different data sources are added later, different data source types only need to be defined in the data source model, so that the data source can be centrally managed. At the same time, business processing is concentrated in the processor. New business processing functions only need to expand the processor without modifying the architecture, which facilitates later maintenance, makes business development more convenient, and adapts to multiple business scenarios.

[0051] Reference Figure 3 , Figure 3 This is a flowchart illustrating the second embodiment of the backend business processing method of this application. Based on the first embodiment described above, a second embodiment of the backend business processing method of this application is proposed. In the second embodiment, step S30 includes: Step S301: Invoke the container detector of the detector class manager in the manager.

[0052] It should be noted that the container detector is a core scheduling component built into the detector class manager. It has the functions of parsing target model features, retrieving detector resource pools and matching and adapting detectors, and connecting target models with specific detectors.

[0053] Understandably, business attributes of the target model can be extracted, such as model identifier, function type, and interface requirements. Then, based on preset mapping rules (such as the binding relationship between business type and detector, and interface compatibility verification standards), detectors that meet the requirements are selected from the resource pool of the detector class manager, providing accurate components for the subsequent initial configuration of the target model.

[0054] Step S302: Using the target model and the container detector, call the adapted target detector from the detector class manager.

[0055] It should be understood that once the target model is populated with the corresponding data, the container detector can, based on the feature information of the target model and according to preset matching rules (such as business type correspondence, interface compatibility verification, functional requirement matching degree, etc.), search in the detector resource pool of the detector class manager, and finally determine and call the target detector that is fully adapted to the target model. For example, DsicInboundDetector calls DsicEndpointDetector to handle endpoint loading and binding with the current container. It queries API data from the local data source and service governance data source, binds it to the current container and endpoint, and creates a socket connection to listen to the corresponding endpoint.

[0056] Step S303: Initialize the target model according to the target detector and execute the project startup process.

[0057] Understandably, initial configuration involves setting parameters and preparing resources to enable the target model to have business processing capabilities, such as network port binding and rule loading.

[0058] Specifically, the target detector, based on the configuration annotations of the target model and business requirements, completes the setting of network parameters (such as ports and protocols), business rules (such as verification logic and data flow paths), and loading of dependent resources (such as database connections and cache instances). Subsequently, based on the configuration results, it executes the project startup process, including establishing communication connections with other modules, completing component registration, and triggering status checks, ultimately bringing the target project to a ready state for executable business logic. This process, through the collaboration of the detector and the model, decouples the startup configuration from the business logic, solving the problems of poor scalability and high maintenance costs caused by hard-coded startup processes in traditional architectures.

[0059] Furthermore, to enhance the stability and smoothness of the interaction between the target model and the external environment, the target detector includes an incoming detector and an outgoing detector. Step S303 may include: The incoming endpoint is established by the incoming detector; the application programming interface data is loaded by the outgoing detector, and the interface data is bound to the current container and the endpoint.

[0060] It should be noted that the inbound detector is responsible for managing the inbound endpoints of the target model that receive external data, and has the functions of establishing network listening and receiving data requests; the inbound endpoint can be the network interface of the target model that receives external data, including information such as address, port, and protocol; the outbound detector is responsible for processing the interface configuration of the target model that outputs data, and has the functions of loading interface definitions and binding interaction relationships; the application programming interface data can describe the interface specification information of the target model that provides services to the outside world, such as interface name, parameter format, return value type, etc.; the current container is the environment carrier for running the target model, used to manage the lifecycle and resources of the model; endpoints include inbound endpoints and outbound endpoints, which can be network nodes for the target model to interact with the outside world.

[0061] Understandably, the inbound detector parses the inbound configuration of the target model (such as listening port and transport protocol), establishes a continuous network listening connection at the corresponding inbound endpoint, and ensures that external data requests can be captured in a timely manner and transmitted to the target model. The outbound detector, on the other hand, loads predefined application programming interface data, parses the interaction rules of the interface, and binds this interface data to the container of the currently running target model and the outbound endpoint, so that the data processed by the target model can be output to the outside world through the bound endpoint according to the interface specification.

[0062] Furthermore, to enable the target project to be identified and managed by the registry center, facilitating its discovery and invocation by other business modules, the process after step S30 also includes: Based on the preset data source, query the registration center data corresponding to the backend device; register the target project to the registration center according to the registration center data.

[0063] It should be noted that the registry center data is used to describe the basic information of the registry center (such as address, port, and communication protocol) and the project registration rules (such as registration format and heartbeat mechanism). The registry center is used to manage the registration, discovery, and status monitoring of each project / service in the backend devices, and to realize dynamic communication and collaboration between projects. When a target project registers, the target project's identification information (such as project ID, service address, and function description) is entered into the registry center according to the registry center rules, so that other projects can discover and call the target project.

[0064] Understandably, after calling the model's detector to start the process, the corresponding registry data can be queried through the registry data source in the preset data source, and the application can be registered to the registry for use by subsequent services.

[0065] In one example, reference Figure 4 , Figure 4 This is a flowchart illustrating the project startup process for the backend business processing method of this application. Upon project startup, the scanner first scans JAR files and class files, loading the relevant classes into the corresponding managers for subsequent use. Specifically, this includes scanning classes with `@Cubelet` and loading them into `CubeleteManager`; scanning model class files and loading the models into `ModelManager`; scanning detector classes and loading them into `DetectorManager` for later use in the project startup process; scanning processor classes and loading them into `ProcessorManager` for later use in the startup process; and finally loading the `DataSourceType` data source class into the `DataSourceTypeManager` data source class manager.

[0066] Next, based on the information provided by the local file data source in the data source, the forwarding rules, key information identification rules and routing rules are loaded, the container model is created and the data of the container model is queried. Then the detector (runDetector) is run, and the service is registered through the registry data source in the data source.

[0067] When the project starts running the detector, the container detector DsicContainerDetector is obtained from the detector class manager of DetectorManager. Then, the outbound detector DiscOutboundDetector and the inbound detector DiscInboundDetector are called through the container detector. At the same time, the endpoint detector DiscEndpointDetector can also be called through the outbound detector.

[0068] An endpoint model is created using endpoint detectors and inbound detectors. Then, endpoint data is obtained from the local file data source in the data source, and API data is obtained from the local file data source and service governance data source in the data source. Next, the endpoint data and API data are bound together, and the protocol bound to the current detector is obtained based on the binding result. The socket connection is created by binding the address and port through the protocol and listening to the corresponding endpoint.

[0069] In this embodiment, the container detector of the detector class manager in the manager is invoked; the adapted target detector is invoked from the detector class manager using the target model and the container detector; the target model is initialized and configured according to the target detector, and the project startup process is executed. By invoking the container detector to obtain the adapted target detector from the manager, accurate matching between the detector and the target model is achieved, avoiding blind selection of the detector; at the same time, initializing and configuring the target model based on the target detector and starting the project ensures the standardization and reliability of the project startup process.

[0070] Reference Figure 5 , Figure 5 This is a flowchart illustrating the third embodiment of the backend business processing method of this application. Based on the above embodiments, a third embodiment of the backend business processing method of this application is proposed. In the second embodiment, step S40 includes: Step S401: The processor calls global context information, which includes the target data bound to the target model and preset business rules.

[0071] It should be noted that global context information can be stored in a shared data container in the system, which centrally carries the target data (specific business data) bound to the target model and preset business rules (such as data processing rules, routing rules, etc.) for cross-module access by various components.

[0072] Understandably, the processor, based on its association with the target model, accurately extracts the required business data and corresponding processing rules from the global context, eliminating the need for separate queries from data sources or configuration files, thus achieving one-stop access to data and rules. Centralized management of the global context improves the processor's resource access efficiency and ensures data and rule consistency during business logic execution.

[0073] It should be understood that, in actual implementation, the global context can adopt a thread-safe storage structure, supporting concurrent access by multiple processors and avoiding data conflicts. Simultaneously, a data expiration mechanism should be set for the global context to automatically clean up temporary business data, reducing memory consumption. Furthermore, sensitive target data (such as user privacy information) in the global context can be encrypted and stored, requiring decryption through permission verification when called by the processor. This application does not impose any limitations on this.

[0074] Step S402: Perform business processing on the target data based on the preset business rules to obtain the business processing result.

[0075] It is understandable that preset business rules can be predefined logical specifications and operational guidelines used to guide the processing of target data, including data parsing rules, routing and forwarding rules, key information identification rules, business calculation formulas, etc.

[0076] It should be understood that after the project starts, all business logic is implemented in the processor. For example, forwarding rules (Transfer), routing (ServiceRouter), and key information identification (KeyMessage) will each implement their own corresponding processor. Each processor class implements its own business methods. Each processor class has a `process` method, whose parameter is an `Exchange`. The `Exchange` class is a global context, with corresponding containers such as `in`, `out`, `context`, and `parameter`. When the `process` method executes, it retrieves data from upstream from `in`, processes the business logic, and places the results in `out` for downstream use. `context` is a global container that can pass models, etc., for global use. `parameter` is a global map container (Map) used to store parameters during processing, which can be used globally by the system.

[0077] Step S403: Store the business processing result in the global context information so that the downstream processor of the target model can call it.

[0078] Understandably, business processing results are the output data generated by the processor after processing the target data according to preset business rules. This includes intermediate calculation results, status indicators, or final business output. Downstream processors are processors that follow the current processor in the business process and need to rely on the upstream processing results to continue executing logic. They have a business link relationship with the target model.

[0079] Understandably, after completing the current business processing, the processor writes the result to a designated storage area in the global context according to a preset format (such as associating it with the target model identifier in the form of a key-value pair). Downstream processors can then accurately retrieve the result from the global context by identifying the target model identifier or business link information, without needing to repeatedly query the data source or transmit it across modules. This process achieves efficient sharing of business processing results, improving the continuity and efficiency of business processes.

[0080] In this embodiment, data is processed based on preset rules and the results are stored in the global context for easy access by downstream processors, thereby achieving continuity of business processing and data sharing, and improving overall business processing efficiency.

[0081] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the backend business processing methods of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0082] This application also provides a backend business processing device, please refer to... Figure 6 The backend service processing device includes: The class loading module 10 is used to respond to the project startup request of the target project, scan the target class file corresponding to the target project, and load the target class in the target class file into the corresponding manager. The target class includes model class, detector class and processor class. The data binding module 20 is used to query target data that matches the model class from a preset data source, bind the target data to the model in the model class, and obtain the target model. The model is a basic model abstracted from the target business in the target project. The project startup module 30 is used to call the detector corresponding to the target model from the manager storing the detector classes, and execute the project startup process based on the detector; The business execution module 40 is used to call the processor corresponding to the target business from the manager storing the processor classes after the project startup process is completed, and execute the business logic corresponding to the target model through the processor.

[0083] The backend business processing apparatus provided in this application, employing the backend business processing method in the above embodiments, can solve the technical problem that traditional three-tier architecture backend systems struggle to meet the needs of efficient expansion and rapid iteration of backend business. Compared with the prior art, the beneficial effects of the backend business processing apparatus provided in this application are the same as those of the backend business processing method provided in the above embodiments, and other technical features in the backend business processing apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0084] This application provides a back-end service processing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the back-end service processing method in the above embodiment 1.

[0085] The following is for reference. Figure 7This document illustrates a structural diagram of a backend service processing device suitable for implementing embodiments of this application. The backend service processing device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 7 The backend business processing equipment shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0086] like Figure 7 As shown, the back-end processing equipment may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the back-end processing equipment. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows back-end service processing equipment to communicate wirelessly or wiredly with other equipment to exchange data. Although the figures show back-end service processing equipment with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0087] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0088] The backend business processing device provided in this application, employing the backend business processing method in the above embodiments, can solve the technical problem that traditional three-tier architecture backend systems cannot meet the needs of efficient expansion and rapid iteration of backend businesses. Compared with the prior art, the beneficial effects of the backend business processing device provided in this application are the same as those of the backend business processing method provided in the above embodiments, and other technical features in this backend business processing device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0089] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0090] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0091] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the back-end business processing method in the above embodiments.

[0092] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0093] The aforementioned computer-readable storage medium may be included in the back-end business processing equipment; or it may exist independently and not be assembled into the back-end business processing equipment.

[0094] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by a backend business processing device, cause the backend business processing device to perform the backend business processing method described above.

[0095] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0096] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0097] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0098] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the aforementioned backend business processing methods. This solves the technical problem that traditional three-tier architecture backend systems struggle to meet the demands for efficient expansion and rapid iteration of backend services. Compared to existing technologies, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the backend business processing methods provided in the above embodiments, and will not be elaborated upon here.

[0099] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the backend business processing method described above.

[0100] The computer program product provided in this application can solve the technical problem that traditional three-tier architecture backend systems cannot meet the needs of efficient expansion and rapid iteration of backend services. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the backend service processing method provided in the above embodiments, and will not be repeated here.

[0101] The above description is only a part of the embodiments of this application and does not limit the scope of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included within the protection scope of this application.

Claims

1. A backend business processing method, characterized in that, Applied to backend devices, the backend business processing includes: In response to the project startup request of the target project, the target class files corresponding to the target project are scanned, and the target classes in the target class files are loaded into the corresponding manager. The target classes include model classes, detector classes and processor classes. The target data matching the model class is queried from the preset data source, and the target data is bound to the model in the model class to obtain the target model. The model is a basic model abstracted from the target business in the target project. From the manager storing the detector classes, the detector corresponding to the target model is invoked, and the project startup process is executed based on the detector; After completing the project startup process, the processor corresponding to the target business is called from the manager storing the processor classes, and the business logic corresponding to the target model is executed through the processor.

2. The backend business processing method as described in claim 1, characterized in that, The target class also includes annotation classes; the step of querying target data matching the model class from a preset data source, binding the target data with the model in the model class, and obtaining the target model includes: Extract the annotation classes and model classes from the manager; The data source type corresponding to the model class is determined based on the annotation class information, and a container model is created based on the data source type; Obtain the target data for the container model query from the preset data source; The target data is bound to the model in the model class to obtain the target model.

3. The backend business processing method as described in claim 1, characterized in that, The step of calling the detector corresponding to the target model from the manager storing the detector classes and executing the project startup process based on the detector includes: Invoke the container detector of the detector class manager in the manager; The appropriate target detector is invoked from the detector class manager using the target model and the container detector. The target model is initialized and configured according to the target detector, and the project startup process is executed.

4. The backend business processing method as described in claim 3, characterized in that, The target detector includes an incoming detector and an outgoing detector; The step of initializing the target model according to the target detector includes: An inbound endpoint listening connection is established through the inbound detector; The outgoing detector loads the application programming interface data and binds the interface data to the current container and endpoint.

5. The backend business processing method as described in claim 1, characterized in that, The step of executing the business logic corresponding to the target model through the processor includes: The processor invokes global context information, which includes the target data bound to the target model and preset business rules. Based on the preset business rules, the target data is processed to obtain the business processing result; The business processing result is stored in the global context information so that the downstream processor of the target model can call it.

6. The backend business processing method as described in any one of claims 1 to 5, characterized in that, After the step of calling the detector corresponding to the target model from the manager storing the detector classes and executing the project startup process based on the detector, the method further includes: Based on the preset data source, query the registration center data corresponding to the backend device; Register the target project to the registry center based on the registry center data.

7. A back-end business processing device, characterized in that, The device includes: The class loading module is used to respond to the project startup request of the target project, scan the target class files corresponding to the target project, and load the target classes in the target class files into the corresponding manager. The target classes include model classes, detector classes and processor classes. The data binding module is used to query target data that matches the model class from a preset data source, bind the target data to the model in the model class, and obtain the target model. The model is a basic model abstracted from the target business in the target project. The project startup module is used to call the detector corresponding to the target model from the manager storing the detector classes, and execute the project startup process based on the detector; The business execution module is used to, after completing the project startup process, call the processor corresponding to the target business from the manager storing the processor classes, and execute the business logic corresponding to the target model through the processor.

8. A back-end business processing device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the back-end service processing method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the back-end business processing method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the backend business processing method as described in any one of claims 1 to 6.

Images