CN114254606A

CN114254606A - Microservice framework model

Info

Publication number: CN114254606A
Application number: CN202111401120.9A
Authority: CN
Inventors: 王振广
Original assignee: Qingdao Haier Technology Co Ltd; Haier Smart Home Co Ltd
Current assignee: Qingdao Haier Technology Co Ltd; Haier Smart Home Co Ltd
Priority date: 2021-11-19
Filing date: 2021-11-19
Publication date: 2022-03-29

Abstract

The embodiment of the invention provides a micro-service framework model, which comprises the following components: the processing unit is used for receiving the micro-service frame generation instruction and determining a target micro-service frame template corresponding to the micro-service frame type from the micro-service frame library based on the micro-service frame type included in the micro-service frame generation instruction; and the micro-service frame library is used for storing micro-service frame templates corresponding to different micro-service frame types, wherein the micro-service frame templates comprise target micro-service frame templates. The method and the device solve the problem of difficult subsequent maintenance caused by non-uniformity of the micro-service framework in the related technology, achieve the effect of unifying the micro-service framework and simplify the maintenance process.

Description

Microservice framework model

Technical Field

The embodiment of the invention relates to the field of communication, in particular to a micro-service framework model.

Background

In the related technology, in the field-oriented micro service, the development frames of all projects are not uniform, the versions of the used technical frames are not uniform, the problems of backward technology and difficult technical upgrading exist, different development frames are required to be considered and compatible in each new technical upgrading, and the upgrading cost is extremely high. Project architectures are not uniform, an existing architecture is a process-oriented micro-service architecture, service logic and bottom-layer technical codes are mixed together, code readability is low, project maintenance cost is high, expandability is poor, and fast iteration which is not enough to meet service requirements is achieved. Code redundancy, low code reuse rate and difficult unit test.

Therefore, the problem that the follow-up maintenance is difficult due to the fact that micro-service frameworks are not uniform exists in the related art.

In view of the above problems in the related art, no effective solution has been proposed.

Disclosure of Invention

The embodiment of the invention provides a micro-service framework model, which at least solves the problem of difficult subsequent maintenance caused by non-uniformity of micro-service frameworks in the related technology.

According to an embodiment of the present invention, there is provided a microservice framework model including: the processing unit is used for receiving a micro-service frame generation instruction and determining a target micro-service frame template corresponding to the micro-service frame type from a micro-service frame library based on the micro-service frame type included in the micro-service frame generation instruction; the micro-service frame library is used for storing micro-service frame templates corresponding to different micro-service frame types, wherein the micro-service frame templates comprise the target micro-service frame templates.

According to the method and the device, the micro-service framework model comprises a processing unit and a micro-service framework library, wherein the processing unit is used for receiving a micro-service framework generation instruction and determining a target micro-service framework model corresponding to the micro-service framework type from the micro-service framework library according to the micro-service framework type included in the micro-service framework generation instruction. The micro-service frame library stores micro-service frame templates corresponding to different micro-service frame types. As the micro service framework can generate the instruction, the corresponding template can be selected from the micro service framework library, and the same template corresponding to the micro service framework generating instruction of the same kind is realized. Therefore, the problem that follow-up maintenance is difficult due to the fact that micro-service frames are not unified in the related technology can be solved, the effect of unifying the micro-service frames is achieved, and the maintenance process is simplified.

Drawings

FIG. 1 is a diagram of a related art DDD architecture;

FIG. 2 is a schematic structural diagram of a hexagonal architecture in the related art;

FIG. 3 is a diagram of a microservice framework model architecture according to an embodiment of the invention;

FIG. 4 is a schematic diagram of a web interface service, domain services hierarchical architecture, according to an illustrative embodiment of the present invention;

FIG. 5 is a domain services web project hierarchy diagram in accordance with an illustrative embodiment of the present invention;

FIG. 6 is a relational diagram of components at each level in accordance with an illustrative embodiment of the present invention;

FIG. 7 is an engineering module layered code architecture diagram in accordance with an exemplary embodiment of the present invention;

FIG. 8 is a diagram of an adaptation layer code structure according to an exemplary embodiment of the present invention;

FIG. 9 is a data transfer object class diagram in accordance with an exemplary embodiment of the present invention;

FIG. 10 is a schematic diagram of a client module code structure in accordance with an exemplary embodiment of the present invention;

FIG. 11 is a diagram of an application layer code structure in accordance with an illustrative embodiment of the present invention;

FIG. 12 is a domain layer code structure diagram in accordance with an illustrative embodiment of the present invention;

FIG. 13 is a base layer code structure diagram in accordance with an illustrative embodiment of the present invention;

FIG. 14 is a schematic diagram of an apparatus for generating a framework in accordance with an exemplary embodiment of the present invention;

FIG. 15 is a flowchart of a method of generating a framework according to an exemplary embodiment of the invention;

FIG. 16 is a flowchart of generating code according to an exemplary embodiment of the present invention.

Detailed Description

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings in conjunction with the embodiments.

It should be noted that the terms "first," "second," and the like in the description and claims of the present invention and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order.

The Maven ArchimeType is a Maven project template tool kit and supports the construction of a project template-mvn arch type: create-from-project in a command mode. However, the Maven arch type project template toolkit supports custom fixed templates, but does not support autonomous selection of dynamic add-drop features.

The Mybatis Generator \ Mybatis-plus Generator code generation tool can quickly generate database access codes and support custom templates for generating codes. However, the code models generated by the Mybatis Generator and the Mybatis plus Generator are traditional MVC three-layer architectures, the development mode focuses on process thinking, and the design idea of DDD and the domain-oriented microservice code model are not fused.

Ddd (domain drive design), i.e. domain drive design, the core concept is divide-and-conquer, abstraction and knowledge. The application layer comprises a display layer, an application layer, a field layer and an infrastructure layer. Referring to fig. 1, a schematic diagram of a DDD architecture is shown, as shown in fig. 1, the DDD includes:

a presentation layer: responsible for presenting information to the user and interpreting user commands. In more detail, the following are: requesting an application layer to acquire data required to be displayed by a user; sending a command to the application layer asks it to execute a certain user command.

An application layer: a very thin layer that defines all the tasks that the software is to perform. And providing various application functions (including query or command) for the presentation layer, and completing various business logics for the internal calling domain layer (domain object or domain service), wherein the application layer does not contain the business logics.

Field layer: the system is responsible for expressing business concepts, business state information and business rules, and a domain model is positioned at the layer and is the core of business software.

Infrastructure layer: the layer provides general technical capability for other layers; providing inter-layer communication; implementing a persistence mechanism for the domain layer; in summary, the infrastructure layer may support the technical requirements of other layers through the architecture and framework.

The domain layer comprises aggregation and domain layer services, and the aggregation comprises entities and value objects.

An Entity (Entity) is a domain concept that requires unique identification in the domain, i.e., a domain object. The domain objects include: attributes, behaviors, states. Instead of defining too many attributes or behaviors to an entity, an association should be found, some other entity or value object discovered, and the attributes or behaviors transferred to other associated entities or value objects.

Value Object (Value Object): basic Object types, String, Integer, Double, Boolean, Object, Collection.

Domain Service (Domain Service): some concepts in the field are less suitable for modeling as objects, e.g. some operations, actions. These operations or actions often involve multiple domain objects and coordination of these domain objects is required to accomplish the operation or action together. If any one object is forced to assign the operation duties, the assigned object bears some duties which are not supposed to bear, so that the duties of the object are not clearly and confusingly affected. General domain objects are stateful and behavioral, while domain services are stateless and behavioral only. The domain service is stateless, and the meaning of the domain service is that the domain objects are coordinated to complete a certain operation.

The functions are as follows: and the domain logic is prevented from being leaked to an application layer. Like the Faade mode (facade mode) provides a straightforward but well-defined interface by invoking domain services.

Polymeric and polymeric roots (Aggregate Root): aggregation is a domain schema used to define domain object ownership and boundaries, helping to simplify the relationships between model objects.

Only one application layered architecture design guiding idea is defined in the DDD architecture idea, differential design aiming at application engineering of different functions is lacked, and other design modes and architecture ideas are lacked.

The hexagonal architecture is also called "port and adapter mode", and is an architecture style with symmetry characteristics proposed by Alistair Cockburn. In the architecture, the system interacts with the outside by means of an adapter, and the application service and the domain service are packaged in the system. The hexagonal structure is also a layered structure, fig. 2 is a schematic structural diagram of the hexagonal structure in the related art, and as shown in fig. 2, the hexagonal structure is divided into three layers: port adapter, application layer and domain layer. And the port can be divided into an input port and an output port.

Input port: the method is used for exposing an API interface when the system provides service, receiving the input of an external client system, and converting the input of the client system into the input understood in the program. The access layer to which the system is external as a service provider can be regarded as an input port.

Output port: support is provided for the system to obtain external services, such as obtaining persistent state, persisting results, or issuing change notifications (e.g., domain events) for domain state. The interface (database, cache, message queue, RPC call) of the system, which is used as the service for the consumer to obtain the service, can be regarded as the input port.

An application layer: the work that the system can do is defined, a very thin layer. It does not process business logic and completes business logic by coordinating domain objects or domain services and outputs results through input ports. Transaction management can also be done at this level.

Field layer: the charge represents the concept, rule and state of the service, and belongs to the core of the service.

The invariance of the application layer and the domain layer can ensure that the core domain is not interfered by the outside, and the replaceability of the port can be conveniently butted with an unused external system.

However, when a framework is developed, the technology selection of the development framework is inconsistent, the technology is old, and the technology is difficult to upgrade.

In view of the above problems, some embodiments are proposed:

in this embodiment, a micro service framework model is provided, and fig. 3 is a structural diagram of the micro service framework model according to an embodiment of the present invention, as shown in fig. 3, the process includes the following steps:

the processing unit 32 is configured to receive a micro service frame generation instruction, and determine a target micro service frame template corresponding to a micro service frame type from a micro service frame library based on the micro service frame type included in the micro service frame generation instruction;

the micro-service framework library 34 is configured to store micro-service framework templates corresponding to different types of micro-service frameworks, where the micro-service framework templates include the target micro-service framework template.

In this embodiment, the processing unit may be a processor or the like, and the processing unit may directly or indirectly receive the microservice framework generation instruction. And determining the type of the micro service frame required by the micro service frame generation instruction. And determining a target micro-service frame template in the micro-service frame library according to the type of the micro-service frame. Each frame template stored in the micro-service frame library corresponds to one frame type. After the micro-service frame type included in the micro-service frame generation instruction is determined, the target micro-service frame template can be determined from the micro-service frame library. The microservice framework type may be the type corresponding to the application to be developed.

In the above embodiment, the development framework template built in the micro service framework library may be a domain-oriented micro service framework code model based on DDD, and may be implemented by combining design ideas such as a DDD framework, a Clean framework, a hexagon framework, a Command and Query Responsibility Separation (CQRS) framework, a service-oriented framework, an event-driven framework, a framework in which a service customization package is separated from a platform, and the like. The design of horizontal function layering and vertical field sub-packaging can be adopted, a strict layering architecture is adopted, and a certain layer can only be coupled with a layer directly below the certain layer.

In one exemplary embodiment, the micro service framework library comprises: the system comprises a basic service framework template of a first type, a field service framework template of a second type, a field service framework template of a third type and an interface service framework template of a fourth type. In this embodiment, the micro service framework library may include a basic service item template, a domain service Web item template, and an interface service Web item template. Applications can be classified into Dubbo basic service, Dubbo domain service, web interface service according to functions. Accordingly, templates of a type corresponding to the application may be included in the micro service framework library. The first type of basic service frame template may be a Dubbo basic service frame template; the second type of domain service framework template may be a Dubbo domain service framework template, and the third type of domain service framework template may be a web domain service framework template; the fourth type of interface service frame template may be a web interface service frame template. In the whole development system, communication among micro services in the system can be transmitted by using a Dubbo protocol, and the system provides an HTTP (hyper text transport protocol) protocol interface for the outside. The transmission efficiency of the internal micro-service network is improved, the response delay caused by network resource limitation is reduced, and the response time of the whole request link is prolonged. The micro-service can provide the HTTP and the Dubbo protocol simultaneously, and meets the requirements of high efficiency, low delay and simple, standard and quick access of an internal access scene and an external access scene.

In the above embodiment, different micro service framework templates may be selected to match for different functional applications. By adopting an object thinking mode, the whole team uses a group of general terms and definitions by using business to be oriented, and the business tracking is easier. The software design perfection is improved, codes are easy to read, the repetition is reduced, and the maintenance is easy. The model can be repeatedly used, so that repeated models are avoided, and the problems that codes are difficult to modify, test and read are solved. The maintainability and expansibility of the system are improved, the service complexity and the technical complexity are effectively isolated, and the domain model is used as a stable and cohesive core of the whole system, and is separated and unchanged.

In one exemplary embodiment, the first type of basic service framework template includes at least one of: a client layer, an application layer, a domain layer and an infrastructure layer; the second type of domain service framework template comprises at least one of: a client layer, an application layer, a domain layer and an infrastructure layer; the third type of domain service framework template comprises at least one of: an adaptation layer, a client layer, an application layer, a domain layer and an infrastructure layer; the fourth type of interface service framework template comprises at least one of: and (4) an adaptation layer. In this embodiment, when the basic service framework template of the first type is a Dubbo basic service framework template and the domain service framework template of the second type is a Dubbo domain service framework template, the Dubbo basic service and the Dubbo domain service adopt four-layer architecture: the system comprises a client layer, an application service layer, a field layer and an infrastructure layer. When the third type of domain service framework template is a Web domain service framework template, the Web domain service framework template may be divided into an adaptation layer, a client layer, an application service layer, a domain layer, and an infrastructure layer. When the interface service framework template of the fourth type is a Web interface service framework template, the Web interface service framework template may be divided into adaptation layers.

In the above embodiment, the adaptation layer of the Web interface service has an association relationship with the client layer of the Dubbo domain service, data transmission is performed through a network based on the Dubbo service protocol, the Web interface service performs protocol conversion and service encapsulation on the Dubbo domain service through the adaptation layer, and multi-terminal function adaptation of the Web terminal, the mobile terminal, the IoT terminal, and the like is realized. The application layer of the Dubbo field service realizes a client layer, an application layer is related to a field layer, an infrastructure layer realizes the field layer, and the application layer depends on the infrastructure layer.

In the above embodiment, when the domain service framework template of the third type is a Web domain service framework template, comparing with the DDD four-layer architecture, the presentation layer function is split into an adaptation layer and a client layer, the adaptation layer processes HTTP protocol requests sent by users, and data is assembled, and the client layer is responsible for defining a data transmission format and an application layer Facade ("Facade") interface. The adaptation layer can be independently positioned in a web interface service project, remotely calls other Dubbo field service projects through network communication, can also be integrated in the web field service project, and converts a Dubbo service protocol into an HTTP protocol to provide web interface services. The effect is as follows: by converting and packaging the network protocol and the data protocol, various terminal devices are flexibly adapted, and a multi-service scene is adapted. The client layer can package the Dubbo service API and request parameters and return results, so that the development cost of other services when calling the services is reduced, the development code amount is reduced, and the service calling specification is defined.

In the above embodiment, a schematic diagram of a web interface service and domain service hierarchical architecture can be seen in fig. 4, a schematic diagram of a domain service web project hierarchical architecture can be seen in fig. 5, a relationship diagram of each layer of components can be seen in fig. 6, and a structural diagram of an engineering module hierarchical code can be seen in fig. 7.

In an exemplary embodiment, the adaptation layer is configured to receive a target protocol request sent by a target application, parse a configuration file included in the target protocol request, and send data corresponding to the configuration file to the application layer through the client layer. In this embodiment, the adaptation layer is associated with the client layer, the application layer implements the client layer, the application layer is associated with the domain layer, the infrastructure layer implements the domain layer, and the application layer depends on the infrastructure layer. The Web domain service can simultaneously provide the Dubbo protocol service and the HTTP protocol interface service to the outside.

In one exemplary embodiment, the adaptation layer includes: the Web service is used for exposing the target interface under the condition of receiving the control instruction of the page request; the mobile terminal service is used for adapting functions for the wireless terminal; and the Iot Internet of things service is used for adapting functions to the Iot terminal. In this embodiment, the adaptation layer may provide service adaptation for the front end and resource adaptation for the resource layer. This layer aggregates interface adaptation related functions. Responsible for routing and adaptation of the front-end exposure (web, mobile, IoT), for legacy B/S systems, the adapter behaves as a controller in MVC. For the HTTP request, the layer is mainly used for processing a Restful request sent by a user and analyzing a configuration file input by the user; and the related client layer transmits the data to the Application layer in an internal engineering calling mode or transmits the data to the Application layers of other Dubbo services in a remote process calling mode. The Web service can be used for a Controller for processing page requests, and exposes an Http interface, and most interface functions should be under a Web package. The mobile terminal service may be a mobile terminal service for handling wireless terminal specific function adaptation. The Iot service may be used to handle the specific functional adaptation of the Iot terminal. The structure diagram of the adaptation layer code can be seen in fig. 8.

In an exemplary embodiment, the client layer is configured to encapsulate a data transmission object corresponding to the configuration file determined by the adaptation layer and a target service interface, where the target service interface is an interface for providing a service to the outside. In this embodiment, the client layer is used for storing the codes related to the interaction and data presentation of the client layer and the outside. The external application obtains the required data from the application service through the interface of the layer. The data assembly, data transmission format, and codes such as the Facade interface are all placed in this layer of directory. Wherein the target service interface may be a Dubbo service interface.

In the above embodiment, for RPC protocol requests, the client layer is used to provide a client call SDK, which includes a Dubbo service interface API and a data transfer object DTO. Wherein, the application service interface API: the service interface API provided by the service is mainly the API of the Dubbo RPC service and the RESTful request API. Data transfer object DTO: the DTO object provided by the service outside inherits the DTO parent class. The method is divided into two types of client request object request and data object response, and the client request object code packet path request and the data object code packet path response.

In the above embodiment, the data object response refers to an object for transmitting a service return result. The Response class inherits the parent DTO class, and is further subdivided into a SingleResponse (data format is generic T), a Multiresponse (data format is generic Collection < T >), and a Pageresponse (data format is generic Collection < T >), and simultaneously contains pageSize, pageIndex, and totalCount paging query parameters) according to different data structures of returned results. The client request object request refers to a client object for receiving request parameters, and can be divided into Command and Query types according to a Command Query Responsibility Separation (CQRS) architecture mode. The Command class inherits a parent DTO class, the Query class inherits a parent Command class, and the PageQuery class inherits a Query class. When the code is developed, the Query class request parameter inherits a Query parent class, the paging Query class request parameter inherits a PageQuery parent class, and the non-Query class request parameter inherits a Command parent class. The data transmission object class diagram can be referred to in fig. 9, and the client module code structure diagram can be referred to in fig. 10.

In one exemplary embodiment, the application layer includes: the application service is used for providing service related service and task scheduling service; a command executor for processing an operation of a target type; a subscription event processor for subscribing the message events in the message queue and calling the lower module to process the service; the timing task processor is used for processing the timing task; an object converter for converting a target object; and the parameter checker is used for checking the legality of the parameters included in the request instruction. In this embodiment, the application layer is responsible for obtaining input, assembling context, checking parameters, requesting authentication, processing Request, controlling transaction, and the like. Service combination and arrangement are realized, and the requirement of rapid change of the business process is met. The application layer aggregates application services and event related functionality. And the application layer calls the domain layer to perform service processing. Different layers in the engineering are isolated, and an application layer only allows access to a domain layer and not allows access to a basic implementation layer. The schematic diagram of the application layer code structure can be seen in fig. 11.

In the above embodiment, the application service: and the concrete implementation of the application service realizes a service api interface. And providing business related services and task scheduling services. The specific service logic implementation adopts a command mode and is realized by a corresponding executor. The service class only makes simple command calls.

Command executor: the request type is divided into a common command and a query according to the request type, and a responsibility separation architecture (CQRS) is adopted to be classified into a CmdExe class and a QryExe class and respectively process common command operation and query class operation.

Subscription event handler subscribe: and the message event subscription processing module subscribes the message events in the message queue and calls the lower-layer module to perform service processing.

The timed task processor jobi: and processing the timing tasks, and uniformly scheduling by a distributed task scheduling center.

The object converter converts the DTO and the Model object into each other.

The parameter checker validator checks whether the DTO request parameter and the request parameter are not empty or other validity checks.

In one exemplary embodiment, the domain layer includes: the domain service is used for providing domain actions, operations and behavior capabilities; and the domain rule is used for verifying the business rule and the multi-business scene rule. In this embodiment, the domain layer may include a domain model, a domain capability, and a domain repository, and the domain capability may include a domain service, a domain object, and a domain rule. The schematic diagram of the domain layer code structure can be seen in fig. 12.

In the above embodiment, the Domain Layer (Domain Layer) may implement core business logic of the Domain, and the Domain Layer aggregates Domain objects such as aggregation, aggregation root, entity, value object, Domain Service, and event of the Domain Model, and business capabilities formed by combining them, and provides business entity and business logic computation for the App Layer by a method of Domain Service and Domain object (Domain Model). The field is the core of the application and does not depend on any other layer in the project; and the second square base Client does not depend on any other project.

Domain Model (Domain Model): the domain model object (entity and value object) comprises data and basic behavior capability, and the internal attribute definition in the domain provides basic getter, setter, attribute judgment and simple business state judgment. The domain model objects are stateful objects, are objects with instance variables (data members), can store data, are non-thread-safe, and require manual creation of objects (instantiation).

Domain ability (ability): may include Domain objects (Domain models), Domain rules (Domain rules), and Domain services (Domain services). Domain capabilities are stateless objects, objects without instance variables. Data cannot be saved, the class is unchanged, and the thread is safe. The object life cycle is managed by a Spring container.

Domain object (Domain Model): and basic getter, setter, constractor and attribute judgment capability are provided. If the action of a domain capability is a verb and belongs to an entity or value object, the capability is provided by the corresponding domain Model.

Domain Service (Domain Service) all business logic within the Domain is implemented in the Domain Service. And the service logic of the field is realized through the sub-field aggregation, and various complex field actions, operations and behavior capabilities are provided.

Domain Rule (Domain Rule): the method is used for business rule checking and multi-business scene rule checking.

Domain Repository (Domain Repository): decoupling sharers, decoupling business logic and technical implementation details, infrastructure layer capability abstraction definitions in the field, such as RPC capability abstraction of persistent layer databases, search engines, file systems, distributed services.

In one exemplary embodiment, the infrastructure layer includes: domain repository implementations, databases, caches, search engines, API gateways, event message buses, third party tools, basic services, other basic components. In this embodiment, the infrastructure layer may be responsible for the handling of technical detail issues, such as CRUD of databases, search engines, file systems, RPC of distributed services, etc. In addition, the field of preservation also falls here, and external dependence requires a transposition process by a repositor to be used by the above App layer and Domain layer. The basic layer code structure diagram can be seen in fig. 13.

In the above embodiments, the field warehouse implements RepositoryImpl as an anticorrosive layer. The system is used for integrating database, Dubbo RPC, Cache, search engine search, API gateway httpparent, event message bus, third-party tool util, basic service, other basic components and the like.

Database: the database persistence layer operation comprises the following steps: the entity database table mockup and the mapper database map.

Caching: and (4) realizing the cache operation.

Configuring config: and configuring information.

Search engine search: a search engine implementation.

API gateway client: and calling the remote Http interface to realize calling and calling other basic services.

Message issuing event: and the message processing class is used for specifically realizing the message publishing function.

In the embodiment, by classifying different functions, the reusability of the codes can be improved, the coupling degree is reduced, the maintainability is improved, the readability is improved, the testability is improved, the code idleness rate is reduced, the development efficiency is improved along with the improvement of the service complexity, the multi-person collaborative development can be realized, the development speed is improved, the service is followed, and the rapid iteration of a software system is facilitated.

In one exemplary embodiment, one or more of the first type of base service framework template, the second type of domain service framework template, the third type of domain service framework template, and the fourth type of interface service framework template further comprises: the system comprises a starting layer, a configuration layer and a unit test layer, wherein the starting layer comprises a starting class code, a configuration file and a unit test code and is used for realizing separation of an application code, a configuration code and a test code. In this embodiment, one or more of the basic service framework template of the first type, the domain service framework template of the second type, the domain service framework template of the third type, and the interface service framework template of the fourth type may include a start layer. The starting layer comprises an application starting class, a configuration file and a unit test code, and realizes the separation of the application code, the configuration code and the test code. The code function is clear, the code reading difficulty is reduced, the test and the service code are separated, the coupling degree of the service code and the test code is reduced, the software testability is improved, and the code complexity is reduced.

In the foregoing embodiment, after the frame templates in the micro service frame library are constructed, the corresponding frame template may be selected according to the frame generation instruction. Wherein the frame generation instruction may be an instruction input through the target interface. The target interface may be an interface in the production framework apparatus. The schematic diagram of the apparatus for generating the framework can refer to fig. 14, and as shown in fig. 14, the apparatus includes a web front-end module, a back-end interface module, a project building module, a code downloading module, and a code uploading module.

The Web front-end module is a Web user interaction page and is responsible for interacting with users, and the development framework is conveniently generated through visual operation of the users.

The back-end interface module is used for receiving the request of the web front-end module, processing the user request, calling other modules to complete specific functions and returning a processing result.

And the project construction module is used for automatically matching corresponding project frame templates according to the selected frame types and generating new project codes according to information such as project names and the like. And generating respective functional component configuration commands according to the configuration information of the selectable functional components, and deleting functions of the newly generated project framework so as to meet the requirements of users.

The code downloading module is used for providing a code packaging and downloading function, packaging the generated project codes into a compression package and downloading the compression package to the local part of a user.

The code uploading module is used for automatically uploading the generated project codes to a code warehouse path appointed by a user according to the provided internal code warehouse account and password information, and the steps of manually uploading the project codes to the code warehouse by the user are reduced.

In the foregoing embodiments, the necessary functions and optional functions supported by the frame may be viewed by determining at least one frame component selected by the user at the interactive interface, adding or subtracting optional functions by autonomous selection, selecting a type of item, selecting a group of items, entering a requisite item: project name, business module name, input option: and the project version number automatically checks whether the project name is repeated in a code warehouse according to the information input by the user, and automatically generates a package name package and project coordinate information (groupId and artifactId) of the new project according to a unified development naming standard after the project name check is passed. Clicking an 'immediate construction' button, manually triggering a project construction action, acquiring configuration information required by project construction by a system, generating a corresponding frame component configuration instruction according to each configuration information, and respectively adding related codes of each frame component which is pre-generated into an established development frame template according to the frame component configuration instruction so as to obtain a development frame required by a user.

After a user inputs a user name, a password and project group name information of a code warehouse GitLab on an interactive interface, an 'immediate construction' button is clicked, project construction actions are triggered manually, and after a system generates a frame, a newly-built project under an appointed group of the code warehouse can be automatically established through a code uploading component, and the address of the code warehouse where the project is located is returned. Of course, when the user clicks the "download" button, the project codes that the system can generate are packaged into a compressed package and automatically downloaded to the user's local computer.

The application of different functions corresponds to different project framework templates, a domain-oriented micro-service architecture can be adopted, and a framework template code model can be realized on the basis of the design idea of DDD domain drive by combining the design ideas of a DDD architecture, a Clean architecture, a hexagon architecture, a Command and Query Responsibility Separation (CQRS) architecture, a service-oriented architecture, an event-driven architecture, a service customization package and platform separation architecture and the like. The method comprises a basic service Dubbo project template, a field service Web project template and an interface service Web project template.

In the foregoing embodiment, when the target frame is generated, the visualization degree is high, the operation is easy, the understanding is easy, and a new project frame, that is, the target frame, can be generated simply and conveniently. And technical statistics is developed, and upgrading and maintenance are facilitated. And multiple choices can be provided for different functional items, and the most suitable frame template is automatically recommended. The method has the advantages of optional functions, guarantee of consistent development framework versions and complete basic functions. The selectable functions are selected independently, different development scenes are adapted, unnecessary function dependence is reduced, and burden is reduced for the project.

Fig. 15 is a flowchart of a method for generating a frame, and as shown in fig. 15, the method includes:

in step S1502, the user selects a project building function on the web interaction page (corresponding to the target interface).

In step S1504, the user inputs the required information.

Step S1506, select a project frame, a project group, and a project type, and input a project name, a module name, and a service scene name.

In step S1508, it is checked in the code repository whether the entered item name is occupied.

In step S1510, it is determined whether or not the item name is already present, and if the determination result is yes, step S1512 is executed, and if the determination result is no, step S1514 is executed.

In step S1512, it is prompted that the item name is repeated and please re-input.

Step S1514, acquires user input information, generates a project package name, project coordinate information.

Step S1516 is a step of determining whether or not padding information is input, and if yes, step S1518 is executed, and if no, step S1522 is executed.

In step S1518, the user inputs the opt-in information.

And step S1520, item version number, Gitlab code warehouse account number, password and code group name.

In step S1522, the user selects an optional function component.

In step S1524, the user clicks the immediate build button.

In step S1526, the back-end interface module obtains a user building request (corresponding to the above-mentioned framework generation instruction).

Step S1528, the project building module obtains information such as the selected frame type, the target name, the package name, and the project coordinate.

In step S1530, a specified frame module is downloaded from the Maven private server repository, and a new item code is generated and stored in the local temporary directory of the server.

Step S1532 acquires configuration information of each optional functional component, and generates a build instruction corresponding to each configuration information.

Step S1534, executing each framework component configuration command, and deleting unneeded functional component codes from the new project framework.

Step S1536 determines whether the Gitlab account information is null, and if the determination result is yes, step S1538 is executed, and if the determination result is no, step S1548 is executed.

Step S1538 returns the project construction success information.

In step S1540, the user clicks a download button.

Step S1542, the back-end interface module obtains the user download request.

Step S1544, the code downloading module packs the generated project codes into a compressed packet, returns the file download stream, and deletes the project code file of the server.

Step S1546, download the project file to the local.

Step S1548, the code uploading module uploads the generated code to a designated warehouse according to the code warehouse account number, the password and the group name.

In step S1550, the project code file stored in the server is cleared.

And step S1552, returning to finish uploading.

In the related technology, because the project architecture is not uniform, the project architecture is a process-oriented micro-service architecture, the service logic and the bottom technical code are mixed together, the code readability is low, the project maintenance cost is high, the expandability is poor, and the quick iteration of the service requirement cannot be adapted sufficiently. Code redundancy, low code reuse rate and difficult unit test. When a new project is constructed, the traditional manual construction mostly adopts copying of an existing project code and then manual deletion of a service code, or the construction is started step by step from scratch, which is time-consuming and labor-consuming and has high frame bug rate.

Therefore, after the target frame (corresponding to the target micro-service frame template) is determined, the codes corresponding to the target frame can be arranged according to the code template, so that the readability of the codes is improved, and the maintenance cost and the error rate of the frame codes are reduced.

The DDD code model-based code generator component can be matched in the target framework and integrated into the framework in the form of an external dependency package, and a user configures necessary configuration information in a property file, such as: database connection information, database user names, database passwords, database table names, sub-field names, class file name prefixes, authors and sub-field function descriptions, and optionally configured configuration information is selected and configured autonomously, for example: and whether a database operation function code is generated or not and whether a control class Controller function code is generated or not are judged, then a Main function Main method of a code generation class is operated, and the required code is automatically generated. The generated code comprises functions of basic addition, deletion, modification, searching and the like, and comprises codes of a user interface layer, a client layer, an application layer, a field layer, an infrastructure layer and the like. The code model types supporting autonomous selection generation are divided into a DDD (distributed data description) hierarchical architecture code model and an MVC (model view controller) architecture code model.

The code Generator component can use a Freemarker template engine to predefine a code template based on a Mybatis-plus Generator tool, automatically read properties attribute parameters configured by a user during running, select a code model template to be generated according to frame type parameters configured by the user, select a code file to be generated according to enabled function parameters configured by the user, and then replace a placeholder in the code template in a variable mode to generate a basic function code which meets the requirements of the user and meets the frame naming specification.

And if the database access function is started, analyzing the database table structure by using a Mybatis-Plus Generator according to the information such as the field name, the table name, the database connection and the like configured by the user, and generating a database function code conforming to the Mybatis frame model.

If the controller function is enabled, a web interface function code is generated.

Referring to fig. 16, a flowchart for generating a code may be shown, as shown in fig. 16, where the flowchart includes:

in step S1602, a DOMAGenerator type Main method is run.

Step S1604, reads generator, properties file configuration information under ckasspath directory, and loads the configuration information into software memory.

Step S1606, the git account information parsing module generates a git account information parsing command.

Step S1608, determining the type of the operating system, executing step S1610 if the operating system is a windows system, and executing step S1612 if the operating system is a unix system.

In step S1610, a cmd program is called to execute the git account information parsing command.

In step S1612, the bash program is invoked to execute the git account information parsing command.

Step S1614, get git login account, set as file author.

Step S1616, setting database connection information: connection url, user name, password.

In step S1618, the default code generation function of the Mybatis-Plus Generator component is set to be disabled.

Step S1620, custom variable information is set.

In step S1622, the type of the generated code module is determined, and in the case where the determination result is the MVC architecture, step S1624 is executed, and in the case where the determination result is the DDD architecture, step S16216 is executed.

Step S1624, sets the code generation file path and the package name, and conforms to the MVC architecture style.

Step S1626, setting a generated file path and a package name, and conforming to the DDD layered architecture style.

Step S1628, setting a custom code template path, and generating a code file output path configuration list.

In step S1630, it is determined whether or not a database function code is generated, and if the determination result is yes, step S1632 is executed, and if the determination result is no, step S1634 is executed.

Step S1632, adding a database function template path, and generating code file output path information to the configuration list.

In step S1634, it is determined whether or not the web interface function code is generated, and if the determination result is yes, step S1636 is executed, and if the determination result is no, step S1638 is executed.

Step S1636, adding a web interface function template path, and generating code file output path information to the configuration list.

Step S1638, adding code template paths of functions of the client layer, the application layer, the domain layer and the infrastructure layer, and generating code file output path information to the configuration list.

In step S1640, the template engine is set to Freemarker.

Step S1642, call the Mybatis-Plus Generator component to execute the method, and generate the code to the local disk.

In the above embodiment, each project frame includes a code generator module, and may generate a complete set of function codes of basic functions such as query, addition, modification, deletion, and the like based on a table structure of a database, support flexible configuration of a code generation function in a property attribute file manner, autonomously select whether to enable a database connection function or a control class Controller function, and generate a code that follows a DDD hierarchical architecture and a domain-oriented code model, thereby achieving low code development and improving development efficiency. In addition, different development frames are matched with the code generator, basic addition, deletion, modification and check function codes can be quickly generated, the development code amount is reduced, the development mode is standardized, and the learning threshold of developers for practicing DDD is lowered.

In the foregoing embodiment, the visualization operation quickly constructs the back-end micro-service project development framework through the project construction wizard system. A user can independently select any project frame on a visual operation page, the frame comprises a necessary functional component and a selectable functional component, the necessary functional component can not be selected by self definition, and the selectable functional component supports independent increase and decrease. The method comprises the steps of checking required selectable functional components on a page, selecting a project type and a project group, inputting information such as a project name, a service module name, a service scene name and a version number, and automatically generating project coordinate information such as a package path, a Maven group id and a Maven artifactId according to a unified project naming specification. Clicking the immediate construction button, automatically generating project codes and downloading the project codes to the local in a compressed package form. Meanwhile, the method supports the input of a GitLab account number, a password and a group name, and the generated project can be automatically uploaded to a GitLab code warehouse.

The application of different functions corresponds to different project framework templates, a domain-oriented micro-service architecture is adopted, a framework template code model is based on DDD domain drive design ideas, and the design ideas such as a DDD architecture, a Clean architecture, a hexagon architecture, a Command and Query Responsibility Separation (CQRS) architecture, a service-oriented architecture, an event drive architecture, a service customization package and platform separation architecture are combined to realize the application. The method comprises a basic service Dubbo project template, a field service Web project template and an interface service Web project template.

A domain-oriented micro-service architecture code generator component. Each project frame comprises a code generator module, a complete set of function codes of basic functions of inquiring, adding, modifying, deleting and the like can be generated based on a table structure of a database, the function of generating the codes through local flexible configuration of properties attribute files is supported, whether a database connection function is started or not and whether a control type Controller function is started or not are selected independently, the generated codes follow a DDD (distributed data description) hierarchical architecture and a domain-oriented code model, low-code development is realized, and development efficiency is improved.

In the embodiment, a new project is generated through the project construction system, a unified development framework is formed, the development framework template is updated irregularly, the technical advancement is kept, the technical standard is unified, the system technology is convenient to upgrade, and the cost of upgrading the basic functions of the system is reduced. A user flexibly selects different types of development frames on an interactive page, a new project framework is generated by one key, downloading to the local and synchronous uploading to a code warehouse are supported, time and labor are saved, and new project construction is realized in one minute. The system built-in development framework is verified through multiple tests, the basic function is complete, the bug rate of the framework is low, and the framework is matched with development document guidance to ensure that developers can use the framework when opening the box. The traditional development thinking mode is changed, and the process thinking is converted into the object thinking. The domain-oriented micro-service architecture is adopted, the DDD design idea is popularized, and a code generator component which accords with a DDD code model is matched, so that development thinking mode conversion of developers is facilitated, and the learning threshold is lowered. A code generator component is arranged in the frame, based on a DDD code model, through simple database connection configuration and field name configuration, functional codes are added, deleted, changed and checked on the basis of one-key generation, simple and repeated coding work is reduced, and development efficiency is greatly improved. A user selects a project type on an interactive page, inputs a project name, a project group name, a service module name and a service scene name, the system automatically checks whether the project name is repeated in a code warehouse, and automatically generates a project package name and project coordinate information according to a unified naming rule, so that project issuing conflict caused by the fact that the project name is not standard is avoided.

It will be apparent to those skilled in the art that the various modules or steps of the invention described above may be implemented using a general purpose computing device, they may be centralized on a single computing device or distributed across a network of computing devices, and they may be implemented using program code executable by the computing devices, such that they may be stored in a memory device and executed by the computing device, and in some cases, the steps shown or described may be performed in an order different than that described herein, or they may be separately fabricated into various integrated circuit modules, or multiple ones of them may be fabricated into a single integrated circuit module. Thus, the present invention is not limited to any specific combination of hardware and software.

The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, or improvement made within the principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A microservice framework model, comprising:

the processing unit is used for receiving a micro-service frame generation instruction and determining a target micro-service frame template corresponding to the micro-service frame type from a micro-service frame library based on the micro-service frame type included in the micro-service frame generation instruction;

the micro-service frame library is used for storing micro-service frame templates corresponding to different micro-service frame types, wherein the micro-service frame templates comprise the target micro-service frame templates.

2. The micro-service framework model of claim 1, wherein the micro-service framework library comprises: the system comprises a basic service framework template of a first type, a field service framework template of a second type, a field service framework template of a third type and an interface service framework template of a fourth type.

3. The micro-service framework model of claim 2,

the first type of basic service framework template comprises at least one of: a client layer, an application layer, a domain layer and an infrastructure layer;

the second type of domain service framework template comprises at least one of: a client layer, an application layer, a domain layer and an infrastructure layer;

the third type of domain service framework template comprises at least one of: an adaptation layer, a client layer, an application layer, a domain layer and an infrastructure layer;

the fourth type of interface service framework template comprises at least one of: and (4) an adaptation layer.

4. The microservice framework model of claim 3, wherein the adaptation layer is configured to receive a target protocol request sent by a target application, parse a configuration file included in the target protocol request, and send data corresponding to the configuration file to the application layer through the client layer.

5. The microservice framework model of claim 4, wherein the adaptation layer comprises:

the Web service is used for exposing the target interface under the condition of receiving the control instruction of the page request;

the mobile terminal service is used for adapting functions for the wireless terminal;

and the Iot Internet of things service is used for adapting functions to the Iot terminal.

6. The microservice framework model according to claim 3, wherein the client layer is configured to encapsulate the data transmission object corresponding to the configuration file determined by the adaptation layer and a target service interface, wherein the target service interface is an interface for providing a service to the outside.

7. The microservice framework model of claim 3, wherein the application layer comprises:

the application service is used for providing service related service and task scheduling service;

a command executor for processing an operation of a target type;

a subscription event processor for subscribing the message events in the message queue and calling the lower module to process the service;

the timing task processor is used for processing the timing task;

an object converter for converting a target object;

and the parameter checker is used for checking the legality of the parameters included in the request instruction.

8. The microservice framework model of claim 3, wherein the domain layer comprises:

the domain service is used for providing domain actions, operations and behavior capabilities;

and the domain rule is used for verifying the business rule and the multi-business scene rule.

9. The microservice framework model of claim 3, wherein the infrastructure layer comprises: domain repository implementations, databases, caches, search engines, API gateways, event message buses, third party tools, basic services, other basic components.

10. The micro-service framework model of claim 3, wherein one or more of the first type of base service framework template, the second type of domain service framework template, the third type of domain service framework template, and the fourth type of interface service framework template further comprises:

the system comprises a starting layer, a configuration layer and a unit test layer, wherein the starting layer comprises a starting class code, a configuration file and a unit test code and is used for realizing separation of an application code, a configuration code and a test code.