A service version control method, device and equipment

Abstract

The application provides a service version control method, device and equipment, the method comprises the following steps: obtaining user context information of at least one user; creating a service class postprocessor in a container initialization stage of an application target development framework; generating a target automatic assembly parser according to the service class postprocessor; generating a target proxy object for the target automatic assembly parser; obtaining a target service version instance according to the user context information; and providing a target service to a target user through the target proxy object according to the target service version instance. The scheme integrates service version control in the framework level of the application target development framework, can centrally manage different versions, and realizes the decoupling of service version control and other business logic.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer information processing, in particular to a service version control method, device and equipment. BACKGROUND

[0002] With the wide application of cloud computing and Software as a Service (SaaS) mode, more and more enterprises use software services through subscription. SaaS systems usually adopt a multi-tenant architecture, that is, a unified application instance provides services for multiple tenants, and data isolation and function differentiation among tenants are realized through configuration or permission control. In a typical SaaS system, the platform divides functions into different business modules, such as customer management module, order processing module, report analysis module, etc., and each tenant can purchase specific modules according to its own needs and open their functions by paying; in addition, the same module can provide different versions of service levels, such as basic version, professional version, enterprise version, etc., to meet the needs of different user groups. In order to support such flexible function combination and hierarchical service strategy, the SaaS platform needs to have the following capabilities: 1, modular design: divide system functions into independent modules according to business fields for management and deployment; 2, tenant individualization configuration: allow tenants to enable or disable certain function modules according to their subscription plan; 3, interface multi-implementation version support: there are multiple implementation versions of the same interface, corresponding to different function levels or feature sets; 4, runtime dynamic switching logic: without restarting the application, automatically select the corresponding version of the service implementation according to the current tenant identity and subscription information.

[0003] However, in the traditional Spring Boot framework, the loading and dependency injection mechanism of instance objects (Beans) are static and fixed, once the container is started, the types and implementations of all Beans are determined, and cannot be dynamically adjusted according to the tenant context. Therefore, if you want to implement the above functions in a SaaS system, developers often need to manually write a large amount of routing judgment logic, conditional branch code, or even introduce external configuration centers or custom annotations to realize version switching, which not only increases the complexity of the system, but also reduces the maintainability and extensibility of the code. Although some existing solutions can achieve service version control to some extent, they generally have the following problems: 1, the implementation method is highly invasive and needs to modify the original business logic; 2, the version routing logic is scattered and difficult to manage centrally; 3, there is a lack of good compatibility with the original Inversion of Control (IOC) mechanism in the SpringBoot framework; 4, poor scalability, difficult to adapt to subsequent new version strategies (such as gray release, A / B testing, etc.). SUMMARY

[0004] The application provides a service version control method, device and equipment, and solves the problems of high coupling between service version control and business logic, poor centralized management of version routing, poor compatibility with original IOC mechanism and poor expansibility.

[0005] To solve the above technical problems, the technical solutions of the application are as follows:

[0006] The application provides a service version control method, device and equipment, and solves the problems of high coupling between service version control and business logic, poor centralized management of version routing, poor compatibility with original IOC mechanism and poor expansibility.

[0007] Obtaining user context information of at least one user;

[0008] Creating a service class post-processor in a container initialization stage of an application target development framework;

[0009] Generating a target automatic assembly parser according to the service class post-processor;

[0010] Generating a target proxy object for the target automatic assembly parser;

[0011] Obtaining a target service version instance according to the user context information;

[0012] Providing a target service to a target user through the target proxy object according to the target service version instance.

[0013] Optionally, the service class post-processor is created in the container initialization stage of the application target development framework, and the method comprises the following steps:

[0014] Determining an interface name of an interface that needs to be inherited by the service class post-processor;

[0015] Creating the service class post-processor that inherits the interface according to the interface name.

[0016] Optionally, the target automatic assembly parser is generated according to the service class post-processor, and the method comprises the following steps:

[0017] Determining a class name of a class that needs to be inherited by the target automatic assembly parser;

[0018] Creating the automatic assembly parser that inherits the class in the service class post-processor according to the class name, and generating the target automatic assembly parser.

[0019] Optionally, the target proxy object is generated for the target automatic assembly parser, and the method comprises the following steps:

[0020] Scanning and processing all classes that implement a target interface under a specific package path to obtain a target to be proxied;

[0021] The target agent object factory is generated for the target to be agent.

[0022] Optionally, all classes implementing the target interface under a specific package path are scanned and processed to obtain the target to be agent, including:

[0023] All classes implementing the target interface under a specific package path are scanned by a scanning tool to obtain a class object set;

[0024] The class object set is filtered to retain the class object directly implementing the target interface;

[0025] The class object is stored in a set to obtain the target to be agent.

[0026] Optionally, the target service version instance is obtained according to the user context information, including:

[0027] The user unique sequence is obtained according to the user context information;

[0028] The target service version instance is obtained according to the user unique sequence.

[0029] Optionally, the target service is provided to the target user through the target agent object according to the target service version instance, including:

[0030] The corresponding target service is obtained according to the target service version instance;

[0031] The target service is provided to the target user through the target agent object.

[0032] The embodiment of the application further provides a service version control device, including:

[0033] An acquisition module is configured to acquire user context information of at least one user;

[0034] A processing module is configured to create a service class post-processor in a container initialization stage of an application target development framework, generate a target automatic assembly parser according to the service class post-processor, generate a target agent object for the target automatic assembly parser, obtain a target service version instance according to the user context information, and provide a target service to a target user through the target agent object according to the target service version instance.

[0035] The embodiment of the application further provides a computing device, including a processor and a memory storing a computer program, wherein the computer program is run by the processor to execute the above method.

[0036] The embodiment of the present application further provides a computer readable storage medium, which stores instructions, and when the instructions are run on a computer, the computer executes the method.

[0037] The technical scheme of the present application at least has the following effects:

[0038] The above scheme of the present application obtains user context information of at least one user, creates a service class post-processor in a container initialization stage of an application target development framework, generates a target automatic assembly parser according to the service class post-processor, generates a target proxy object for the target automatic assembly parser, obtains a target service version instance according to the user context information, and provides a target service for a target user through the target proxy object according to the target service version instance. The scheme can realize decoupling of service version control and business logic, can centrally manage version routing, can realize automatic service version identification and dynamic injection based on tenant context without changing original business code structure, and can dynamically select a service implementation according to user identity and subscription state. BRIEF DESCRIPTION OF DRAWINGS

[0039] Figure 1 is a flowchart of a service version control method provided by the embodiment of the present application;

[0040] Figure 2 is a structural diagram of a service version control device provided by the embodiment of the present application;

[0041] Figure 3 is a structural schematic diagram of a computing device provided by the embodiment of the present application. DETAILED DESCRIPTION

[0042] Exemplary embodiments of the present application will be described in greater detail below with reference to the accompanying drawings. Although exemplary embodiments of the present application are shown in the drawings, it is understood that the present application can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided so that the present application can be more thoroughly understood and so that the scope of the present application can be completely conveyed to those skilled in the art.

[0043] As shown in Figure 1 the embodiment of the present application proposes a service version control method, which comprises:

[0044] Step 11, obtaining user context information of at least one user;

[0045] Step 12, creating a service class post-processor in a container initialization stage of an application target development framework;

[0046] Step 13, generating a target automatic assembly parser according to the service class post-processor;

[0047] Step 14, generating a target agent object for the target automatic assembly resolver;

[0048] Step 15, obtaining a target service version instance according to the user context information;

[0049] Step 16, providing a target service to a target user through the target agent object according to the target service version instance.

[0050] In this embodiment, in step 11, user (or tenant) accessing the service platform generates access data, i.e. user context information, which mainly includes user unique sequence (ID) and service interface version configuration and the like.

[0051] In step 12, a custom service class postprocessor is created, which determines the interface to be implemented and realizes the functional expansion of the implementation class according to the determined interface. The version control related logic defined in the custom service class postprocessor can be executed in the container initialization phase of the Spring Boot framework.

[0052] In step 13, the class that the target automatic assembly resolver needs to inherit is determined, a first method is defined in the service class postprocessor, and an automatic assembly resolver is created in the first method. The automatic assembly resolver inherits the above determined class to generate a target automatic assembly resolver.

[0053] In step 14, a class scanning tool is used to scan all classes that implement the version control custom (Version Support) interface under a specific package path. According to the scanning result, all service interfaces that need to be version controlled can be obtained. The class scanning tool can be a scanning tool class (Class Scanner). The implementation includes direct implementation or indirect implementation. The Version Support interface is a version control custom interface, and there are many implementation classes under the interface. The service interface is not an "interface" in the programming technical sense, but is essentially a "class". A general proxy object factory (Proxy Service Object Factory) is registered for each service interface as a resolvable dependency, and a target agent object is generated after processing by the general proxy object factory.

[0054] In step 15, the user ID is obtained through the user context information, and the target service version instance is obtained according to the user ID. The target user version instance is the function version corresponding to the user's authority.

[0055] In step 16, the specific service function is acquired according to the target service version instance, and the specific service function is provided to the user with corresponding authority for use through the target proxy object.

[0056] The technical scheme integrates the SaaS service version control function at the Spring Boot framework level, realizes the separation of version control and business logic, and meanwhile, when a new version strategy is added subsequently, the automatic service version identification and dynamic injection based on the tenant context can be realized without changing the original business code structure, so that the flexibility, maintainability and scalability of the SaaS system are improved.

[0057] In an optional embodiment of the present application, in step 11, the user context information of at least one user is acquired, which can include:

[0058] In step 111, the user accesses the user access interface of the service platform to acquire the user context information of at least one user.

[0059] In this embodiment, in step 111, the user is a tenant of the service platform, and when the user accesses the service platform through various terminal devices (such as computers, mobile phones and tablets, etc.), a series of platform and user interaction related information will be generated, which together constitute the user context information. The user context information mainly includes user basic information such as user name, user ID and other personal information, access behavior information such as click operation and page browsing information of the user on the service platform, device environment information such as terminal device information and network environment information, and access time information such as the time period of user access, etc.

[0060] The user context information needs to be packaged first, and different types of information are arranged according to certain format and standard, necessary identification and metadata are added, then a suitable network transmission protocol is selected to send the data, so that the service platform can receive the user context information in time.

[0061] In an optional embodiment of the present application, in step 12, the service class postprocessor is created in the container initialization stage of the application program target development framework, which can include:

[0062] In step 121, the interface that the service class postprocessor needs to inherit is determined, and the interface name is obtained.

[0063] In step 122, the service class postprocessor that inherits the interface is created according to the interface name.

[0064] In this embodiment, since the service version control process needs to be integrated into the Spring Boot framework, the version control needs to intervene in the instance object creation process during the Spring container initialization phase, so the interface that the service class postprocessor needs to implement is determined as an instance object postprocessor interface and an instance object factory postprocessor interface, so that the logic in the service class postprocessor can be executed when the framework container is initialized.

[0065] After the service class postprocessor is created, the first default method (post Process Bean Factory) in the instance object factory postprocessor interface is rewritten, and then the system compatibility is judged: if the current object factory is the default object factory, it means that the object factory in the framework has not been modified, that is, the current service version control is compatible with the system architecture, and the custom automatic assembly parser can be normally created; if the current object factory is not the default object factory, it means that the object factory in the framework has been modified, that is, conflicts may occur between different framework integration logics, in which case, the system framework modification needs to be checked to eliminate the logical conflict hidden danger at the architecture level. Under normal working conditions, the system compatibility should be compatible.

[0066] In an optional embodiment of the application, in step 13, generating the target automatic assembly parser according to the service class postprocessor can include:

[0067] In step 131, the class that the target automatic assembly parser needs to implement is determined to obtain the class name.

[0068] In step 132, an automatic assembly parser inheriting the class is created in the service class postprocessor according to the class name to generate the target automatic assembly parser.

[0069] In this embodiment, the automatic assembly parser is the native parser in the Spring Boot framework, but in order to obtain different service versions according to user information, the original automatic assembly parser needs to be extended to meet the actual needs. First, the parser executed by Sping Boot in the native state is determined to obtain the native parser (ContextAnnotation Autowire Candidate Resolver), which mainly includes a dependency candidate judgment method, an annotation processing method, an instance object definition metadata access method, and some tool methods. The native parser is the class that the target automatic assembly parser needs to implement. Then, a custom automatic assembly parser is created, which inherits the native parser to realize the function expansion of the native parser, that is, to generate the target automatic assembly parser.

[0070] After the target autowire resolver is generated, the second default method (is AutowireCandidate) in the class is rewritten, in which the type information of dependency injection is first obtained, and whether the given instance object is a legal candidate of the current dependency is determined by checking the type matching, that is, the second determination result of whether the current object instance definition information is a Version Support (version control custom) subclass; when it is a subclass of Version Support, it is not directly used as a candidate, but is processed by the proxy factory, at this time the second determination result is false; when it is not a subclass of Version Support, at this time the second determination result is true, and the specific judgment logic is as follows:

[0071] If the current instance object definition information is indeed a subclass of the Version Support interface, the second determination result is false; if the current instance object definition information is not a subclass of the Version Support interface, the second determination result is the determination result of the same named method of the original resolver of the parent class, after all logical checks in the same named method of the parent class, the final result of true given by the default of the same named method of the parent class is obtained, that is, if the current class is not a subclass of the Version Support interface, the second determination result is true. The false and true are the configuration switches of the subsequent proxy object factory, and the false represents that the subsequent proxy object factory will start the logic of processing related instance objects; the true represents that the subsequent proxy object factory will close the logic of processing related instance objects, and the instance object will be directly used as an autowire candidate for dependency injection.

[0072] In an optional embodiment of the application, for the target autowire resolver, the target proxy object in step 14 can include:

[0073] Step 141, scanning and processing all classes that implement the target interface under a specific package path to obtain a target to be proxied;

[0074] Step 142, registering a proxy object factory for the target to be proxied to generate a target proxy object.

[0075] In this embodiment, in step 141, all classes implementing the VersionSupport interface under a specific package path are scanned by a scanning tool to obtain a class object set; all classes implementing the VersionSupport interface under a specific package path are scanned by a scanning tool to obtain a class object set; the scanning tool can use ClassScanner (a scanning tool class); the specific package can be specified by itself, and is generally set as the topmost package established by the current system project to achieve full-range scanning; the classes implementing the VersionSupport interface include directly implemented classes and indirectly implemented classes; the class object set obtained here is a non-redundant class object set, which ensures that the class objects in the set are not repeated.

[0076] The class object set is filtered to retain class objects directly implementing the VersionSupport interface; the class objects are stored in a set to obtain service interfaces that need to be version controlled; the class object set is filtered to retain only classes directly implementing the VersionSupport interface, i.e., to remove indirectly implemented classes.

[0077] The class objects are stored in a set to obtain the target agents that need to be version controlled. The classes directly implementing the VersionSupport interface are stored in an ordered and repeatable set to obtain all target agents that need to be version controlled; each target agent can be obtained directly according to the order of storage in the set.

[0078] In step 142, the target agent registers a proxy object factory to generate a target agent object. The proxy object factory is a general object factory for managing multiple versions of service version instances and their corresponding specific version target services, and a target agent object is generated after a general object factory processes a regular object.

[0079] In an optional embodiment of the application, in step 15, the target service version instance is obtained according to the user context information, which can include:

[0080] In step 151, the user unique sequence is obtained according to the user context information.

[0081] In step 152, the target service version instance is obtained according to the user unique sequence.

[0082] In this embodiment, in step 151, the user carries user ID information for distinguishing other users, i.e., a user unique sequence, every time the user accesses the service platform.

[0083] In step 152, according to the user unique sequence, the current permission information of the corresponding user can be obtained, and according to the permission information, the target service version instance of the current user can be obtained.

[0084] In an optional embodiment of the present application, in step 16, according to the target service version instance, the target service can be provided to the target user through the target agent object.

[0085] In step 161, according to the target service version instance, the corresponding target service can be obtained.

[0086] In step 162, the target service can be provided to the target user through the target agent object.

[0087] In this embodiment, according to the preset static tool class, the specific target service corresponding to the target service version instance can be queried, that is, it is clear that what specific service should be provided to the user with this permission, and the target service can be provided to the target user through the target agent object, which can prevent other users from improperly stealing the service, thereby realizing version isolation control between specific services of different permission users.

[0088] In an optional embodiment of the present application, in step 161, according to the target service version instance, the corresponding target service can be obtained.

[0089] In step 1611, according to the tenant access data, the target service version instance of the target to be agented can be obtained, and a third judgment result of whether the target service version instance exists can be obtained.

[0090] In step 1612, when the third judgment result is no, an execution result that the current tenant does not have the corresponding target service is obtained; when the third judgment result is yes, an object instance corresponding to the target service version instance is obtained, and a fourth judgment result of whether the object instance exists is obtained.

[0091] In step 1613, when the fourth judgment result is no, an execution result that the current tenant does not have the corresponding target service is obtained; when the fourth judgment result is yes, a target service suitable for the current tenant is obtained.

[0092] In this embodiment, in step 1611, according to the tenant access data, the target service version instance of the target to be agented can be obtained, that is, through the method in the tenant access data, the implementation class name of the target to be agented is obtained, and then whether the implementation class version exists is judged to obtain the third judgment result.

[0093] In step 1612, if the third judgment result is no, it means that the current tenant does not have the execution result of the target service at this time, the system throws an exception and gives a prompt "the service version is not configured, please contact the administrator"; if the third judgment result is yes, the corresponding object instance is obtained through the target service version instance, and then whether the object instance exists is judged to obtain the fourth judgment result;

[0094] In step 1613, if the current object instance does not exist, that is, the fourth judgment result is no, the current tenant does not have the execution result of the target service, the system throws an exception and gives a prompt "the service version is not configured, please contact the administrator"; if the current object instance exists, that is, the fourth judgment result is yes, the object instance is returned to the user, that is, the target service suitable for the current tenant is obtained.

[0095] One specific embodiment of the service version control method provided by the embodiment of the application is:

[0096] The custom service class postprocessor intervenes in the creation process of the object instance in the container initialization stage: the service class postprocessor implements the object instance postprocessor and the object instance factory postprocessor interface, so that it can intervene in the creation process of the object instance in the container initialization stage, and the main responsibilities include replacing the default autowire-candidate resolver and registering the proxy object factory for a specific service interface to support the injection of the multi-version service instance. It is checked whether the current object instance factory is of a default type, and if so, the default autowire-candidate resolver of the object instance factory is replaced with a custom target autowire-candidate resolver, so that the object instance that implements the Version Support interface cannot become a candidate directly, but is processed by the proxy factory in the subsequent step.

[0097] The default autowire-candidate resolver is replaced so that it can determine the version of the Bean to be injected according to the tenant information: the native resolver of the Spring Boot framework is extended to create a custom target autowire-candidate resolver, which functions to determine whether a certain Bean is a candidate for injection according to the service version information subscribed by the current tenant during dependency injection; the is Autowire Candidate method of this resolver is rewritten, and for the object instance that implements the Version Support interface, "false" is returned to prevent these object instances from becoming candidates for autowire directly, and instead, the parent class is allowed to handle the selection logic of these Beans to dynamically provide the correct service version according to the tenant context.

[0098] Scan the Version Support interface implementation classes under a specific package path to collect all service interfaces that require version control: Use the Class Scanner tool to scan all classes that implement the Version Support interface under the specified package path; then, process these classes one by one to obtain their corresponding object instance collections, and register a proxy object factory as a resolvable dependency for each service interface. Therefore, when other components need to inject such service interfaces, they will actually get a proxy object, which can dynamically return the correct service version instance based on the tenant context.

[0099] By combining tenant context information, the system can dynamically select the corresponding target service at runtime, thereby achieving service version isolation and control in a multi-tenant environment. Through static utility classes, the system manages tenant context information (such as tenant ID) in a multi-tenant environment and stores tenant information related to the current thread to ensure that each request can correctly obtain the corresponding tenant-specific service version.

[0100] The service version control method proposed in this invention, by deeply integrating service version control with the Spring Boot framework, can reduce the intrusiveness of service version control on the code, separate business logic from version control, achieve centralized management of service versions, and realize good compatibility and scalability with the native Spring Boot framework.

[0101] like Figure 2 As shown, this embodiment of the invention also provides a service version control device 20, including:

[0102] Module 21 is used to obtain user context information of at least one user;

[0103] Processing module 22 is used to create a service class post-processor during the container initialization phase of the application target development framework; generate a target auto-assembly parser based on the service class post-processor; generate a target proxy object for the target auto-assembly parser; obtain a target service version instance based on the user context information; and provide the target service to the target user through the target proxy object based on the target service version instance.

[0104] Optionally, processing module 22 is specifically used for:

[0105] Determine the interfaces that the service class postprocessor needs to inherit, and obtain the interface names;

[0106] Create a service class postprocessor that inherits from the interface name.

[0107] Optionally, based on the service class post-processor, a target auto-assembly parser is generated, including:

[0108] determining a class name of a class that the target auto-assembly resolver needs to inherit;

[0109] creating an auto-assembly resolver that inherits the class in the service class post-processor according to the class name, to generate the target auto-assembly resolver.

[0110] Optionally, a target proxy object is generated for the target auto-assembly resolver, including:

[0111] scanning and processing all classes that implement the target interface under a specific package path to obtain a target to be proxied;

[0112] registering a proxy object factory for the target to be proxied to generate a target proxy object.

[0113] Optionally, scanning and processing all classes that implement the target interface under a specific package path to obtain a target to be proxied, including:

[0114] scanning all classes that implement the target interface under a specific package path through a scanning tool to obtain a class object set;

[0115] filtering the class object set to retain class objects that directly implement the target interface;

[0116] storing the class objects into a set to obtain a target to be proxied.

[0117] Optionally, obtaining a target service version instance according to the user context information, including:

[0118] obtaining a user unique sequence according to the user context information;

[0119] obtaining a target service version instance according to the user unique sequence.

[0120] Optionally, providing a target service to a target user through the target proxy object according to the target service version instance, including:

[0121] obtaining a corresponding target service according to the target service version instance;

[0122] providing the target service to the target user through the target proxy object.

[0123] It should be noted that the device corresponds to the above method, and all implementation manners in the above method embodiments are applicable to this embodiment and can achieve the same technical effects.

[0124] As Figure 3As shown, the embodiment of the present application further provides a computing device 30, which comprises a processor 31, a memory 32, a program or instruction stored in the memory 32 and executable on the processor 31, the program or instruction is executed by the processor 31 to realize the processes of the above-mentioned service version control method embodiment and achieve the same technical effects. For the sake of brevity, the details are not repeated here. It should be noted that the computing device in the embodiment of the present application includes the above-mentioned mobile electronic device and non-mobile electronic device.

[0125] Those skilled in the art can understand that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized in electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0126] Those skilled in the art can clearly understand that, for the convenience and brevity of the description, the specific working processes of the above-mentioned system, device and unit can refer to the corresponding processes in the foregoing method embodiments, which will not be repeated here.

[0127] In the embodiments provided by the present application, it should be understood that the disclosed device and method can be implemented by other ways. For example, the device embodiments described above are only schematic, and the division of units is only a logical function division, and there can be another division way in actual implementation, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections between different parts can be indirect couplings or communication connections through some interfaces, devices or units, and can be electrical, mechanical or other forms.

[0128] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, i.e. they can be located in one place, or distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment of the present application.

[0129] In addition, each functional unit in each embodiment of the present application can be integrated into a processing unit, or each unit can exist physically independently, or two or more units can be integrated into one unit.

[0130] If the functions are realized in the form of software function units and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application or the parts of the present application that essentially contribute to the prior art or the parts of the technical solutions can be embodied in the form of software products. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the embodiments of the present application. The aforementioned storage medium includes a U disk, a mobile hard disk, a ROM, a RAM, a magnetic disk or an optical disk, and various storage media that can store program codes.

[0131] In addition, it should be noted that in the device and method of the present application, it is obvious that the components or steps can be decomposed and / or recombined. These decompositions and / or recombination should be considered as equivalent solutions of the present application. Moreover, the steps of performing the above series of processes can naturally be executed in time sequence according to the order of description, but do not necessarily have to be executed in time sequence, and some steps can be executed in parallel or independently of each other. It can be understood by those skilled in the art that all or any steps or components of the method and device of the present application can be realized in hardware, firmware, software or their combination in any computing device (including processors, storage media, etc.) or network of computing devices, which can be realized by those skilled in the art using their basic programming skills after reading the description of the present application.

[0132] Therefore, the object of the present application can also be realized by running a program or a set of programs on any computing device. The computing device can be a commonly known general-purpose device. Therefore, the object of the present application can also be realized only by providing a program product containing program code for realizing the method or device. That is, such a program product also constitutes the present application, and the storage medium storing such a program product also constitutes the present application. Obviously, the storage medium can be any commonly known storage medium or any storage medium developed in the future.

[0133] The above is the preferred embodiment of the present application. It should be noted that for those skilled in the art, without departing from the principles of the present application, a number of improvements and refinements can be made, which should also be considered as the protection scope of the present application.

Claims

1. A method of controlling a service version, characterized by, The application comprises the following steps: obtaining user context information of at least one user; creating a service class postprocessor in the container initialization stage of the application target development framework, wherein the version control related logic defined in the service class postprocessor is executed in the container initialization stage of the Spring Boot framework; generating a target auto-assembly resolver according to the service class postprocessor; generating a target proxy object for the target auto-assembly resolver; obtaining a user unique sequence according to the user context information, and obtaining a target service version instance according to the user unique sequence; providing a target service to a target user through the target proxy object according to the target service version instance; wherein the service class postprocessor is created in the container initialization stage of the application target development framework, comprising the following steps: determining the interface that the service class postprocessor needs to inherit to obtain an interface name; creating a service class postprocessor that inherits the interface according to the interface name; the interface that the service class postprocessor needs to implement is an instance object postprocessor interface and an instance object factory postprocessor interface; after the service class postprocessor is created, the first default method in the instance object factory postprocessor interface is rewritten; wherein the target auto-assembly resolver is generated according to the service class postprocessor, comprising the following steps: determining the class that the target auto-assembly resolver needs to inherit to obtain a class name; creating an auto-assembly resolver that inherits the class in the service class postprocessor according to the class name to generate a target auto-assembly resolver; after the target auto-assembly resolver is generated, the second default method in the class is rewritten, the type information of the dependency injection is obtained in the second default method, and whether the given instance object is a legal candidate of the current dependency is judged by checking the type matching, specifically including: if the definition information of the current instance object is a subclass of the Version Support interface, the second judgment result is false; if the definition information of the current instance object is not a subclass of the Version Support interface, the second judgment result is true, false represents that the subsequent proxy object factory processing related instance object logic will be started; true represents that the subsequent proxy object factory processing related instance object logic will be closed, and it will be directly used as an auto-assembly candidate for dependency injection; wherein the target proxy object is generated for the target auto-assembly resolver, comprising the following steps: scanning and processing all classes that implement the version control custom Version Support interface under a specific package path to obtain a target to be proxied, specifically, scanning all classes that implement the Version Support interface under a specific package path through a scanning tool to obtain a class object set; filtering the class object set to retain the class objects that directly implement the Version Support interface; storing the class objects in a set to obtain a target to be proxied; registering a proxy object factory for the target to be proxied to generate a target proxy object.

2. The method of claim 1, wherein providing a target service to a target user through the target proxy object according to the target service version instance, comprising: According to the target service version instance, a corresponding target service is obtained; The target service is provided to a target user through the target agent object.

3. An apparatus for controlling a service version, characterized by comprising: The control device of the service version comprises: An acquisition module is configured to acquire user context information of at least one user; An acquisition module is configured to acquire user context information of at least one user; The processing module is used for creating a service class postprocessor in a container initialization stage of an application target development framework, version control related logic defined in the service class postprocessor is executed in a container initialization stage of a Spring Boot framework, a target auto-assembly parser is generated according to the service class postprocessor, a target proxy object is generated for the target auto-assembly parser, a user unique sequence is obtained according to the user context information, a target service version instance is obtained according to the user unique sequence, and the target service is provided to a target user through the target proxy object according to the target service version instance, wherein the service class postprocessor is created in the container initialization stage of the application target development framework, which comprises determining an interface that the service class postprocessor needs to inherit to obtain an interface name, and creating the service class postprocessor that inherits the interface according to the interface name, the interface that the service class postprocessor needs to implement is an instance object postprocessor interface and an instance object factory postprocessor interface, and the first default method in the instance object factory postprocessor interface is rewritten after the service class postprocessor is created, wherein the target auto-assembly parser is generated according to the service class postprocessor, which comprises determining a class that the target auto-assembly parser needs to inherit to obtain a class name, creating the auto-assembly parser that inherits the class in the service class postprocessor according to the class name to generate the target auto-assembly parser, and rewriting the second default method in the class after the target auto-assembly parser is generated, the type information of dependency injection is obtained in the second default method, whether a given instance object is a legal candidate of a current dependency is judged by checking type matching, and the judgment specifically comprises: if the definition information of the current instance object is a subclass of the Version Support interface, the second judgment result is false; if the definition information of the current instance object is not a subclass of the Version Support interface, the second judgment result is true, false represents that the logic of subsequent proxy object factory processing related instance objects is started, and true represents that the logic of subsequent proxy object factory processing related instance objects is closed, and the instance object is directly used as a candidate of auto-assembly for dependency injection, wherein the target proxy object is generated for the target auto-assembly parser, which comprises scanning and processing all classes that implement the version control custom Version Support interface in a specific package path to obtain a target to be proxied, specifically, all classes that implement the Version Support interface in the specific package path are scanned by a scanning tool to obtain a class object set, the class object set is filtered to retain the class objects that directly implement the Version Support interface, the class objects are stored in a set to obtain the target to be proxied, and the target proxy object is generated by registering a proxy object factory for the target to be proxied.

4. A computing device, comprising: Comprise: A processor, a memory having stored a computer program, which, when executed by the processor, performs the method of any one of claims 1 to 2.

5. A computer readable storage medium, characterized in that, A memory having stored instructions, which, when executed on a computer, cause the computer to perform the method of any one of claims 1 to 2.

Images