CN113835842A

CN113835842A - Service design method and system for simultaneously supporting monomer architecture and micro-service architecture

Info

Publication number: CN113835842A
Application number: CN202111147062.1A
Authority: CN
Inventors: 单德祥; 张洋
Original assignee: Industrial and Commercial Bank of China Ltd ICBC; ICBC Technology Co Ltd
Current assignee: Industrial and Commercial Bank of China Ltd ICBC; ICBC Technology Co Ltd
Priority date: 2021-09-28
Filing date: 2021-09-28
Publication date: 2021-12-24

Abstract

The disclosure provides a service design method for simultaneously supporting a monomer architecture and a micro-service architecture, which can be applied to the financial field. The method comprises the following steps: acquiring a service configuration file of a target service; determining a service module of the target service according to the service configuration file; determining an atomic service and a composite service corresponding to the business module according to the business module, wherein the atomic service is a bottom core service, and the composite service is a service formed by calling different atomic services according to business scene requirements; defining a service publishing protocol interface of the atomic service and the composite service; determining a service client calling interface and a calling mode according to the service publishing protocol interface; and responding to a deployment instruction of a user, and deploying the single application or the micro-service application for the target service. The present disclosure also provides a service design system, device, storage medium and program product that simultaneously support a monolithic architecture and a microservice architecture.

Description

Service design method and system for simultaneously supporting monomer architecture and micro-service architecture

Technical Field

The present disclosure relates to the field of software deployment and architecture, and more particularly, to a service design method, system, device, medium, and program product that simultaneously supports monolithic architecture and microservice architecture.

Background

With the development of internet technology, new requirements are put forward on the design of a business system, flexible and rapid adjustment can be performed according to market changes, and high concurrent access requirements under the internet environment are supported.

When a service system appears and needs to support both monomer application and micro-service application so as to meet different customer requirements, the basic solution is to maintain two sets of independent application systems, one set adopts a monomer architecture style, and meets the customer requirements of monomer application cluster deployment; the other set adopts the micro-service architecture style, and meets the customer requirements of micro-service application.

However, the two systems are consistent in core service implementation, and only different in implementation technical schemes. The two sets of core services are maintained to be the same, but the technical implementation modes are different, so that the difficulty of development, test, operation and maintenance is increased, and the stability of the core services is difficult to ensure.

Disclosure of Invention

In view of the foregoing, the present disclosure provides a service design method, system, device, medium, and program product that support both monolithic and microservice architectures.

According to a first aspect of the present disclosure, there is provided a service design method for simultaneously supporting a monolithic architecture and a micro-service architecture, including: acquiring a service configuration file of a target service;

determining a service module of the target service according to the service configuration file;

determining an atomic service and a composite service corresponding to the business module according to the business module, wherein the atomic service is a bottom core service, and the composite service is a service formed by calling different atomic services according to business scene requirements;

defining a service publishing protocol interface of the atomic service and the composite service;

determining a service client calling interface and a calling mode according to the service publishing protocol interface; and

and responding to a deployment instruction of a user, and deploying the single application or the micro-service application for the target service.

According to an embodiment of the present disclosure, the deploying, in response to a deployment instruction of a user, of a monolithic application or a microservice application to the target service includes:

determining a system architecture of a target service according to a deployment instruction of a user;

and deploying the target service according to the system architecture.

According to an embodiment of the present disclosure, the deploying the target service according to the system architecture includes:

if the system architecture is determined to be a single architecture, configuring modules required by single application through a configuration file, and constructing and generating a project component package through Maven;

and directly deploying the project component package to a Java virtual machine.

According to an embodiment of the present disclosure, the deploying the target service according to the system architecture further includes:

if the system architecture is determined to be a micro-service architecture, configuring modules required by micro-service application through a configuration file, and constructing and generating a plurality of project component packages through Maven;

each project building block package is deployed individually onto the JAVA virtual machine in the mode of a single application.

According to an embodiment of the present disclosure, the determining a service client invocation interface and invocation mode according to the service publishing protocol interface includes:

determining a service release protocol according to the service release protocol interface;

and determining a service client calling mode according to the service publishing protocol.

According to an embodiment of the present disclosure, the service publishing protocol includes a local service, Restful style service, Dubbo RPC, and SOFA RPC.

According to the embodiment of the disclosure, the calling mode comprises a local call, an OpenFeign, a Dubbo RPC client and a SOFA RPC client.

A second aspect of the present disclosure provides a service design system supporting both a monolithic architecture and a micro-service architecture, comprising: the acquisition module is used for acquiring a service configuration file of a target service;

the first determining module is used for determining a service module of the target service according to the service configuration file;

the second determining module is used for determining an atomic service and a composite service corresponding to the business module according to the business module, wherein the atomic service is a bottom core service, and the composite service is a service formed by calling different atomic services according to business scene requirements;

the interface module is used for defining a service release protocol interface of the atomic service and the composite service;

the third determining module is used for determining a service client calling interface and a calling mode according to the service publishing protocol interface; and

and the deployment module is used for responding to a deployment instruction of a user and deploying the single application or the micro-service application for the target service.

A third aspect of the present disclosure provides an electronic device, comprising: one or more processors; a memory for storing one or more programs, wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to perform the above-described service design method that supports both monolithic and microservice architectures.

A fourth aspect of the present disclosure also provides a computer-readable storage medium having stored thereon executable instructions that, when executed by a processor, cause the processor to perform the above-described service design method that supports both monolithic and microservice architectures.

A fifth aspect of the present disclosure also provides a computer program product comprising a computer program which, when executed by a processor, implements the above-mentioned service design method that supports both the monolithic architecture and the microservice architecture.

Drawings

The foregoing and other objects, features and advantages of the disclosure will be apparent from the following description of embodiments of the disclosure, which proceeds with reference to the accompanying drawings, in which:

fig. 1 schematically illustrates an application scenario diagram of a service design method supporting both a monolithic architecture and a micro-service architecture according to an embodiment of the present disclosure;

FIG. 2 schematically illustrates a flow diagram of a service design method that supports both monolithic and microservice architectures in accordance with an embodiment of the present disclosure;

FIG. 3 schematically shows a schematic diagram of a target business deployment approach according to an embodiment of the disclosure; and

FIG. 4 schematically illustrates a block diagram of a service design system that supports both monolithic and microservice architectures according to an embodiment of the present disclosure; and

fig. 5 schematically illustrates a block diagram of an electronic device adapted to implement a service design method that supports both monolithic and microservice architectures in accordance with an embodiment of the present disclosure.

Detailed Description

Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. It should be understood that the description is illustrative only and is not intended to limit the scope of the present disclosure. In the following detailed description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the disclosure. It may be evident, however, that one or more embodiments may be practiced without these specific details. Moreover, in the following description, descriptions of well-known structures and techniques are omitted so as to not unnecessarily obscure the concepts of the present disclosure.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The terms "comprises," "comprising," and the like, as used herein, specify the presence of stated features, steps, operations, and/or components, but do not preclude the presence or addition of one or more other features, steps, operations, or components.

All terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art unless otherwise defined. It is noted that the terms used herein should be interpreted as having a meaning that is consistent with the context of this specification and should not be interpreted in an idealized or overly formal sense.

Where a convention analogous to "at least one of A, B and C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B and C" would include but not be limited to systems that have a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B, C together, etc.).

The terms appearing in the present embodiment are explained first:

monomer architecture: all functions are deployed together by one application, namely, a representation layer, a service layer and a data access layer of all service scenes are placed in one project, and finally, the representation layer, the service layer and the data access layer are compiled, packaged and deployed on one server, so that deployment nodes and cost are reduced.

Micro-service: a stand-alone, deployable service that focuses on doing one thing and does well, and this can typically be business capability, or the smallest unit service that provides business value.

Micro-service architecture: the complex system is divided into dozens of even hundreds of small services, and each service is responsible for realizing an independent business logic. The various services in the system are typically deployed independently and loosely coupled to each other.

With the rapid development of internet technology, services need to be flexibly and rapidly adjusted according to market changes, and also have the capability of rapid innovation. Meanwhile, high concurrent access requirements in the internet environment are supported, and at the moment, the micro-service architecture is developed, so that a solution is provided for solving the problems. The advent of the microservice architecture, while addressing the above problems, also introduces technical complexity, including various stages of development, testing, operation, and operation, which results in some enterprises being afraid of introducing the microservice architecture, but rather selecting a relatively simple monolithic architecture and performing cluster deployment to provide high availability of the system and to cope with high concurrency issues.

At present, for a project, the alternative selection between the single application and the micro-service application is basically performed in the project feasibility analysis stage according to specific business requirements and by combining factors such as the technical level of a project team, the technical accumulation of companies and the like.

When a service system appears and needs to support both monomer application and micro-service application so as to meet different customer requirements, the basic solution is to maintain two sets of independent application systems, one set adopts a monomer architecture style, and meets the customer requirements of monomer application cluster deployment; the other set adopts the micro-service architecture style, and meets the customer requirements of micro-service application. However, the two systems are consistent in core service implementation, and only different in implementation technical schemes. The two sets of core services are maintained to be the same, but the technical implementation modes are different, so that the difficulty of development, test, operation and maintenance is increased, and the stability of the core services is difficult to ensure.

Based on the above technical problem, an embodiment of the present disclosure provides a service design method for simultaneously supporting a monolithic architecture and a micro-service architecture, where the method includes: acquiring a service configuration file of a target service; determining a service module of the target service according to the service configuration file; determining an atomic service and a composite service corresponding to the business module according to the business module, wherein the atomic service is a bottom core service, and the composite service is a service formed by calling different atomic services according to business scene requirements; defining a service publishing protocol interface of the atomic service and the composite service; determining a service client calling interface and a calling mode according to the service publishing protocol interface; and responding to a deployment instruction of a user, and deploying the single application or the micro-service application for the target service.

Fig. 1 schematically illustrates an application scenario diagram of a service design method supporting both a monolithic architecture and a micro-service architecture according to an embodiment of the present disclosure.

As shown in fig. 1, network 104 is the medium used to provide communication links between

terminal devices

101, 102, 103 and server 105. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.

The user may use the

terminal devices

101, 102, 103 to interact with the server 105 via the network 104 to receive or send messages or the like. The

terminal devices

101, 102, 103 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.

The server 105 may be a server providing various services, such as a background management server (for example only) providing support for websites browsed by users using the

terminal devices

101, 102, 103. The background management server may analyze and perform other processing on the received data such as the user request, and feed back a processing result to the terminal device (for example, package the service module according to the user deployment instruction and deploy the service module to generate the application).

It should be noted that the service design method supporting both the monolithic architecture and the micro-service architecture provided by the embodiment of the present disclosure may be generally executed by the server 105. Accordingly, the service design system supporting both the monolithic architecture and the micro-service architecture provided by the embodiments of the present disclosure may be generally disposed in the server 105. The service design method supporting both the monolithic architecture and the micro-service architecture provided by the embodiment of the present disclosure may also be performed by a server or a server cluster that is different from the server 105 and is capable of communicating with the

terminal devices

101, 102, 103 and/or the server 105. Accordingly, the service design system supporting both the monolithic architecture and the micro-service architecture provided by the embodiment of the present disclosure may also be disposed in a server or a server cluster different from the server 105 and capable of communicating with the

terminal devices

101, 102, 103 and/or the server 105. The method provided by the embodiment of the disclosure can be used in related aspects in the financial field, and can also be used in any field except the financial field.

It should be understood that the number of terminal devices, networks, and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

A service design method for supporting both the monolithic architecture and the micro-service architecture according to the disclosed embodiment will be described in detail with reference to fig. 2 to 3 based on the scenario described in fig. 1.

Fig. 2 schematically illustrates a flow chart of a service design method supporting both monolithic and microservice architectures according to an embodiment of the present disclosure.

As shown in fig. 2, the service design method supporting both the monolithic architecture and the micro service architecture of this embodiment includes operations S210 to S260.

In operation S210, a service profile of a target service is acquired.

In operation S220, a service module of the target service is determined according to the service profile.

In one example, firstly, the service requirements of the target service are analyzed, the boundaries of the target service fields are divided, and each service field corresponds to one service module. A service module of the target service may be determined according to the service profile in operation S210.

In operation S230, an atomic service and a composite service corresponding to the business module are determined according to the business module, where the atomic service is a bottom core service, and the composite service is a service formed by invoking different atomic services according to business scenario requirements.

In one example, for each service module, the atomic service of the service domain corresponding to the service module is extracted according to the DDD design concept, so as to implement maximum service multiplexing, and the core service remains basically unchanged, thereby ensuring the stability of the core service, improving the reusability of the core service, and reducing repeated development. And designing the composite service of the service domain designed by the target service according to the actual service scene so as to meet the actual service requirement and functional requirement of the user.

And designing an atomic service interface for each independent and complete service function, and providing specific atomic service realization for each atomic service interface. Similarly, the composite service implementation class implements a composite service interface. The service interface and the service implementation adopt an interface design mode, the interface definition and the interface implementation are decoupled, and the dynamic and flexible increase of the interface implementation is supported according to the actual service requirement.

In operation S240, a service publishing protocol interface of the atomic service and the composite service is defined.

In one example, according to the specific implementation of a service interface, a service release protocol interface is designed and defined, including an atomic service and a composite service release protocol interface, and different release protocols are respectively implemented according to the service release protocol interface and in combination with actual service requirements, and if a target service requires a single architecture, a local service is selected; when the target service needs the micro service architecture, the Dubbo service, the Rest service, etc. are selected.

In operation S250, a service client invocation interface and an invocation manner are determined according to the service publishing protocol interface.

According to the embodiment of the disclosure, different service publishing protocols are realized according to the service publishing protocol interface, wherein the service publishing protocols comprise local services, Restful style services, Dubbo RPC and SOFA RPC. And determining a service client calling mode according to the service issuing protocol, wherein the calling mode comprises a local call, an OpenFeign, a Dubbo RPC client and a SOFA RPC client.

In one example, the service client invocation interface is designed according to the service publishing protocol interface in operation S240; and respectively realizing corresponding service client calling realization, such as a local service client, a Dubbo service client, a Rest service client and the like, aiming at the release protocol realized by the service client according to the service client calling interface.

For each service, a set of service interfaces is respectively defined at a service end and a client end. At the service end, different service issuing modes are realized aiming at different network protocols, such as local service, Dubbo service, Rest service and the like. At the client, aiming at different protocols for providing services externally by different service terminals, corresponding client calling interfaces are provided for realizing, such as a local service client, a Dubbo service client, a Rest service client and the like.

The service protocol interface and service protocol implementation, the client interface and the client implementation adopt an interface design mode, the interface definition and the interface implementation are decoupled, and the dynamic and flexible interface implementation increase is supported according to the actual service requirements.

In operation S260, in response to the deployment instruction of the user, the target service is deployed as a single application or a micro service application.

In one example, a target service is deployed according to a deployment requirement of a user, and the design method provided by the embodiment of the disclosure can enable the target service to simultaneously support a single architecture or a micro-service architecture. The target service deployment will be described in detail below with reference to fig. 3. Fig. 3 schematically shows a schematic diagram of a target service deployment according to an embodiment of the present disclosure. As shown in fig. 3, operations S310 to S330 are included.

In operation S310, a system architecture of a target service is determined according to a deployment instruction of a user.

And determining the deployment requirement of the user according to the deployment instruction of the user, and determining a corresponding configuration file. In operation S320, the target service is deployed according to the system architecture.

Operation S320 specifically includes operations S330 through S340.

In operation S330, if it is determined that the system architecture is a single architecture, configuring modules required by the single application through a configuration file, and constructing and generating a project component package through Maven; in operation S331, the project building package is directly deployed onto the Java virtual machine.

In one example, in a single architecture style, the composite service and the atomic service of each business module are implemented locally, the local service and the local service client are directly used, all the business modules are packaged into a component package, that is, Jar can run by spring boot, and then the component package is directly deployed on a Java virtual machine. The monolithic application supports a cluster deployment mode.

In operation S340, if it is determined that the system architecture is a microservice architecture, configuring modules required by microservice applications through configuration files, and creating a plurality of project component packages through Maven construction; in operation S341, each project building block is separately deployed onto the JAVA virtual machine in a mode of a single application.

In one example, under the micro-service architecture style, a remote service (Dubbo service, Rest service, etc.) and a remote service client (Dubbo service client, Rest service client) are adopted to make calls through RPC or HTTP protocols. And each service module is packed into a component package, namely the SpringBoot can run Jar, and then each service module is independently deployed to the Java virtual machine in a mode of single application. Different business modules are separately deployed, and all the business modules form a micro-service architecture style to provide services for the outside. Each business module supports a cluster deployment mode.

According to the service design method for simultaneously supporting the single body architecture and the micro-service architecture, the design ideas of multiple modules, service platforms and facing interfaces are adopted in service design, and the quick conversion of the single body application and the micro-service application is realized.

In design, firstly, for each business module, the atomic service of the business domain corresponding to the business module is extracted according to the design idea of DDD, so as to realize maximum service multiplexing. And then designing composite service of the business domain related to the project according to the actual business scene so as to meet the actual business requirement and functional requirement of the user. And finally, interface design modes are adopted for realizing the service interface and the service, realizing the service protocol interface and the service protocol, realizing the client interface and the client, decoupling interface definition and interface realization, and supporting dynamic and flexible increase of interface realization according to actual business requirements.

In the aspect of implementation, multi-module development based on Maven is adopted, each module is packaged independently, different product components are constructed based on different architecture styles, and differences of local calling and remote calling of services are shielded.

Based on the service design method for simultaneously supporting the monomer architecture and the micro-service architecture, the disclosure also provides a service design system for simultaneously supporting the monomer architecture and the micro-service architecture. The apparatus will be described in detail below with reference to fig. 4.

Fig. 4 schematically illustrates a block diagram of a service design system supporting both monolithic architecture and microservice architecture according to an embodiment of the present disclosure.

As shown in fig. 4, the service design system 400 supporting both the monolithic architecture and the microservice architecture of this embodiment includes a first obtaining module 410, a first determining module 420, a second determining module 430, an interface module 440, a third determining module 450, and a deploying module 460.

The first obtaining module 410 is configured to obtain a service profile of a target service. In an embodiment, the first obtaining module 410 may be configured to perform the operation S210 described above, which is not described herein again.

The first determining module 420 is configured to determine a service module of the target service according to the service profile. In an embodiment, the first determining module 420 may be configured to perform the operation S220 described above, which is not described herein again.

The second determining module 430 is configured to determine an atomic service and a composite service corresponding to the service module according to the service module, where the atomic service is a bottom core service, and the composite service is a service formed by invoking different atomic services according to requirements of a service scenario. In an embodiment, the second determining module 430 may be configured to perform the operation S230 described above, which is not described herein again.

The interface module 440 is used to define the service publishing protocol interfaces of the atomic service and the composite service. In an embodiment, the interface module 440 may be configured to perform the operation S240 described above, which is not described herein again.

The third determining module 450 is configured to determine a service client invoking interface and an invoking manner according to the service publishing protocol interface. In an embodiment, the third determining module 450 may be configured to perform the operation S250 described above, and is not described herein again.

The deployment module 460 is configured to perform deployment of a single application or a micro-service application on the target service in response to a deployment instruction of the user. In an embodiment, the deployment module 460 may be configured to perform the operation S260 described above, which is not described herein again.

According to the embodiment of the present disclosure, any plurality of the first obtaining module 410, the first determining module 420, the second determining module 430, the interface module 440, the third determining module 450, and the deploying module 460 may be combined into one module to be implemented, or any one of them may be split into a plurality of modules. Alternatively, at least part of the functionality of one or more of these modules may be combined with at least part of the functionality of the other modules and implemented in one module. According to an embodiment of the present disclosure, at least one of the first obtaining module 410, the first determining module 420, the second determining module 430, the interface module 440, the third determining module 450, and the deploying module 460 may be implemented at least in part as a hardware circuit, such as a Field Programmable Gate Array (FPGA), a Programmable Logic Array (PLA), a system on a chip, a system on a substrate, a system on a package, an Application Specific Integrated Circuit (ASIC), or may be implemented in hardware or firmware in any other reasonable manner of integrating or packaging a circuit, or in any one of three implementations of software, hardware, and firmware, or in any suitable combination of any of them. Alternatively, at least one of the first obtaining module 410, the first determining module 420, the second determining module 430, the interface module 440, the third determining module 450, and the deploying module 460 may be at least partially implemented as a computer program module, which when executed, may perform a corresponding function.

As shown in fig. 5, an electronic device 500 according to an embodiment of the present disclosure includes a processor 501 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)502 or a program loaded from a storage section 508 into a Random Access Memory (RAM) 503. The processor 501 may comprise, for example, a general purpose microprocessor (e.g., a CPU), an instruction set processor and/or associated chipset, and/or a special purpose microprocessor (e.g., an Application Specific Integrated Circuit (ASIC)), among others. The processor 501 may also include onboard memory for caching purposes. Processor 501 may include a single processing unit or multiple processing units for performing different actions of a method flow according to embodiments of the disclosure.

In the RAM 503, various programs and data necessary for the operation of the electronic apparatus 500 are stored. The processor 501, the ROM 502, and the RAM 503 are connected to each other by a bus 504. The processor 501 performs various operations of the method flows according to the embodiments of the present disclosure by executing programs in the ROM 502 and/or the RAM 503. Note that the program may also be stored in one or more memories other than the ROM 502 and the RAM 503. The processor 501 may also perform various operations of method flows according to embodiments of the present disclosure by executing programs stored in one or more memories.

According to an embodiment of the present disclosure, electronic device 500 may also include an input/output (I/O) interface 505, input/output (I/O) interface 505 also being connected to bus 504. The electronic device 500 may also include one or more of the following components connected to the I/O interface 505: an input portion 506 including a keyboard, a mouse, and the like; an output portion 507 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage portion 508 including a hard disk and the like; and a communication section 509 including a network interface card such as a LAN card, a modem, or the like. The communication section 509 performs communication processing via a network such as the internet. The driver 510 is also connected to the I/O interface 505 as necessary. A removable medium 511 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 510 as necessary, so that a computer program read out therefrom is mounted into the storage section 508 as necessary.

The present disclosure also provides a computer-readable storage medium, which may be contained in the apparatus/device/system described in the above embodiments; or may exist separately and not be assembled into the device/apparatus/system. The computer-readable storage medium carries one or more programs which, when executed, implement the method according to an embodiment of the disclosure.

According to embodiments of the present disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, which may include, for example but is not limited to: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. For example, according to embodiments of the present disclosure, a computer-readable storage medium may include ROM 502 and/or RAM 503 and/or one or more memories other than ROM 502 and RAM 503 described above.

Embodiments of the present disclosure also include a computer program product comprising a computer program containing program code for performing the method illustrated in the flow chart. When the computer program product runs in a computer system, the program code is used for enabling the computer system to realize the service design method which supports the monomer architecture and the micro-service architecture simultaneously and is provided by the embodiment of the disclosure.

The computer program performs the above-described functions defined in the system/apparatus of the embodiments of the present disclosure when executed by the processor 501. The systems, apparatuses, modules, units, etc. described above may be implemented by computer program modules according to embodiments of the present disclosure.

In one embodiment, the computer program may be hosted on a tangible storage medium such as an optical storage device, a magnetic storage device, or the like. In another embodiment, the computer program may also be transmitted, distributed in the form of a signal on a network medium, downloaded and installed through the communication section 509, and/or installed from the removable medium 511. The computer program containing program code may be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 509, and/or installed from the removable medium 511. The computer program, when executed by the processor 501, performs the above-described functions defined in the system of the embodiments of the present disclosure. The systems, devices, apparatuses, modules, units, etc. described above may be implemented by computer program modules according to embodiments of the present disclosure.

In accordance with embodiments of the present disclosure, program code for executing computer programs provided by embodiments of the present disclosure may be written in any combination of one or more programming languages, and in particular, these computer programs may be implemented using high level procedural and/or object oriented programming languages, and/or assembly/machine languages. The programming language includes, but is not limited to, programming languages such as Java, C + +, python, the "C" language, or the like. The program code may execute entirely on the user computing device, partly on the user device, partly on a remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., through the internet using an internet service provider).

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Those skilled in the art will appreciate that various combinations and/or combinations of features recited in the various embodiments and/or claims of the present disclosure can be made, even if such combinations or combinations are not expressly recited in the present disclosure. In particular, various combinations and/or combinations of the features recited in the various embodiments and/or claims of the present disclosure may be made without departing from the spirit or teaching of the present disclosure. All such combinations and/or associations are within the scope of the present disclosure.

The embodiments of the present disclosure have been described above. However, these examples are for illustrative purposes only and are not intended to limit the scope of the present disclosure. Although the embodiments are described separately above, this does not mean that the measures in the embodiments cannot be used in advantageous combination. The scope of the disclosure is defined by the appended claims and equivalents thereof. Various alternatives and modifications can be devised by those skilled in the art without departing from the scope of the present disclosure, and such alternatives and modifications are intended to be within the scope of the present disclosure.

Claims

1. A method for service design that supports both monolithic and microservice architectures, the method comprising:

acquiring a service configuration file of a target service;

2. The method of claim 1, wherein the deploying the monolithic application or the microservice application to the target service in response to the deployment instruction of the user comprises:

and deploying the target service according to the system architecture.

3. The method of claim 2, wherein deploying the target service according to the system architecture comprises:

and directly deploying the project component package to a Java virtual machine.

4. The method of claim 2, wherein deploying the target service according to the system architecture further comprises:

5. The method of claim 1, wherein determining a service client invocation interface and invocation manner according to the service publishing protocol interface comprises:

6. The method of claim 5, wherein the service publishing protocols include native services, Restful style services, Dubbo RPC, and SOFA RPC.

7. The method of claim 5, wherein the calling means comprises a local call, an OpenFeign, a Dubbo RPC client, and a SOFA RPC client.

8. A service design system supporting both monolithic architecture and microservice architecture, comprising:

the acquisition module is used for acquiring a service configuration file of a target service;

9. An electronic device, comprising:

one or more processors;

a storage device for storing one or more programs,

wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to perform the method of any of claims 1-7.

10. A computer readable storage medium having stored thereon executable instructions which, when executed by a processor, cause the processor to perform the method of any one of claims 1 to 7.

11. A computer program product comprising a computer program which, when executed by a processor, implements a method according to any one of claims 1 to 7.