CN112685052B - Micro-service implementation method supporting different deployment modes based on NET Core - Google Patents

Micro-service implementation method supporting different deployment modes based on NET Core Download PDF

Info

Publication number
CN112685052B
CN112685052B CN202011631150.4A CN202011631150A CN112685052B CN 112685052 B CN112685052 B CN 112685052B CN 202011631150 A CN202011631150 A CN 202011631150A CN 112685052 B CN112685052 B CN 112685052B
Authority
CN
China
Prior art keywords
micro
service unit
micro service
service
program
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202011631150.4A
Other languages
Chinese (zh)
Other versions
CN112685052A (en
Inventor
王延东
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Inspur General Software Co Ltd
Original Assignee
Inspur General Software Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Inspur General Software Co Ltd filed Critical Inspur General Software Co Ltd
Priority to CN202011631150.4A priority Critical patent/CN112685052B/en
Publication of CN112685052A publication Critical patent/CN112685052A/en
Application granted granted Critical
Publication of CN112685052B publication Critical patent/CN112685052B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Stored Programmes (AREA)

Abstract

The application discloses a method for realizing micro-services supporting different deployment modes based on a NET Core, which comprises the following steps: generating a description file of the micro service unit according to the corresponding micro service unit defined by the split micro service; dividing the micro service unit types corresponding to the micro service units according to different functions of the micro service units; starting an application program, firstly identifying all the micro service unit description files in the current system to form a micro service unit list; loading a program set according to the micro service unit type and the sequence according to the micro service unit list identified by the system; when the micro service units are required to be called in the process, the Remote Procedure Call (RPC) framework is used for calling among the micro service units.

Description

Micro-service implementation method supporting different deployment modes based on NET Core
Technical Field
The application relates to the field of application software, in particular to a method for realizing micro-services supporting different deployment modes based on a NET Core.
Background
With the rapid development of the internet industry, the continuous expansion of company or organization business, the rapid change of demand and the continuous increase of user quantity, the traditional single software architecture can not adapt to the requirements of the internet era on software.
In this context, micro-service architecture modes are becoming popular, enabling collaboration and communication between micro-services through hypertext transfer protocol HTTP or lightweight application programming interface APIs. These micro-services can be developed using different languages, different storage technologies, independently deployed for release through automation tools, and kept to a minimum for centralized management.
However, the micro-service architecture is based on a distributed system, and the construction of the distributed system entails additional overhead, and the operation and maintenance costs rise exponentially, so that not every scenario is suitable for using the micro-service architecture, nor every enterprise has the ability or effort to face these challenges.
Disclosure of Invention
The invention provides a method for realizing micro-services supporting different deployment modes based on a NET Core, which solves the problems.
A method for realizing micro-service supporting different deployment modes based on NET Core comprises the following steps:
generating a description file of the micro service unit according to the corresponding micro service unit defined by the split micro service;
dividing the micro service unit types corresponding to the micro service units according to different functions of the micro service units;
starting an application program, firstly identifying all the micro service unit description files in the current system to form a micro service unit list;
loading a program set according to the micro service unit type and the sequence according to the micro service unit list identified by the system;
when the micro service units are required to be called in the process, the Remote Procedure Call (RPC) framework is used for calling among the micro service units.
In one embodiment of the present application, defining a corresponding micro service unit according to the split micro service specifically includes:
firstly, decomposing a complex application program into a group of micro-services supporting independent deployment through analysis and modeling of a specific service field, then carrying out corresponding definition of micro-service units according to service micro-service division, and taking the micro-service units as minimum recognition objects for merging and/or splitting deployment of the application program;
the micro-service unit represents a unit for packing and deploying the micro-service program, is a minimum function set perceived by a user and represents a minimum unit for splitting the micro-service.
In one embodiment of the present application, the micro service unit type specifically includes:
a public micro service unit;
the public micro service unit does not contain an external service interface and implementation, but exists as a common program set and configuration file, provides a common program interface on which programs run and cannot be deployed independently.
In one embodiment of the present application, the micro service unit type specifically includes:
a business micro service unit;
the business micro-service unit comprises external services and pages, and information such as a program set, a configuration file and the like related to the module on which the business micro-service unit is realized, is a complete deployment catalog, has no special requirement on the naming of a folder, and is generally the same as the name of the service unit.
In an embodiment of the present application, dividing the micro service unit types corresponding to the micro service units specifically includes:
in actually splitting the micro service, a core domain must be included in the business micro service unit, and a general domain and a support domain may be split into the common micro service unit in order to avoid repeated deployment among a plurality of the micro service units, because they are common among different critical applications, even different micro service units of the same critical application.
In one embodiment of the present application, an application is started, and all the micro service unit description files in the current system are first identified to form a micro service unit list, which specifically includes:
when an application program is started, firstly, circularly searching all subdirectories in a system, and identifying all micro service unit description files in the current system to form a micro service unit list and corresponding paths and program set information of each micro service unit.
In one embodiment of the present application, according to the list of micro service units identified by the system, the program sets are loaded according to the micro service unit types according to different sequences, and specifically includes:
and sequentially loading the program set files under each micro service unit path through a program integration extension service loop.
In one embodiment of the application, the application server is started by collecting the Controller information of all Web application programming interfaces WebAPI service managers through an extended application model, adding a custom Filter and a route.
In one embodiment of the present application, isolation between the micro-service units is achieved through a remote procedure call RPC framework, and remote procedure call RPC calls are implemented using a DotNetty or a fluen.
In one embodiment of the present application, the micro service unit specifically includes:
executable program sets, pages, documents that support materials and release notes for end users.
The invention provides a method for realizing micro-service supporting different deployment modes based on a NET Core, which is based on a micro-service architecture, realizes the flexible switching between different deployment modes supported by the same system and different deployment modes through abstract definition of a micro-service unit and expansion of an NET Core application loading mechanism, simplifies development workload, increases system deployment flexibility, improves delivery efficiency and is very suitable for being used in a distributed system.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute an undue limitation to the application. In the drawings:
fig. 1 is a flow chart of steps of a method for implementing micro services supporting different deployment modes based on NET Core according to an embodiment of the present application;
fig. 2 is a schematic diagram of a micro service unit of different deployment modes in an application program according to the present embodiment.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be clearly and completely described in connection with specific embodiments of the present application. It will be apparent that the described embodiments are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.
With the rapid development of the internet industry, the continuous expansion of company or organization business, the rapid change of demand and the continuous increase of user quantity, the traditional single software architecture makes large projects difficult to develop, expand and maintain, and the system performance expansion can only be realized by expanding cluster nodes, so that the cost is high, the bottleneck is caused, the technical stack is limited, and the requirements of the internet era on software cannot be met.
In this context, the micro-service architecture model is increasingly popular, which emphasizes the development of single business functions into the form of micro-services, each running in one process. Collaboration and communication between micro services is achieved through hypertext transfer protocol HTTP or lightweight application programming interface APIs. These micro-services can be developed using different languages, different storage technologies, independently deployed for release through automation tools, and kept to a minimum for centralized management.
However, the micro-service architecture is based on a distributed system, and the construction of the distributed system entails additional overhead, and the operation and maintenance costs rise exponentially, so that not every scenario is suitable for using the micro-service architecture, nor every enterprise has the ability or effort to face these challenges. Therefore, if the application system can support the micro-service architecture, it is important to consider the single deployment mode.
The solution of the present application can solve the above problems, and will be specifically described below.
Fig. 1 is a process schematic diagram of a micro-service implementation method supporting different deployment modes based on NET Core according to an embodiment of the present application, which may include the following steps:
generating a micro-service unit description file according to the split micro-service definition corresponding to the micro-service unit;
dividing micro service unit types corresponding to the micro service units according to different functions of the micro service units;
starting an application program, firstly identifying all micro service unit description files in a current system, and forming a micro service unit list;
according to the micro service unit list identified by the system, loading the program set according to the micro service unit type in sequence;
when the micro service units are required to be called in the process, the Remote Procedure Call (RPC) framework is used for calling among the micro service units.
The invention is based on a micro-service architecture, and realizes the same system to support different deployment modes and flexible switching among different deployment modes through the abstract definition of a micro-service unit and the expansion of a NET Core application loading mechanism. May be used to build software applications for Windows, linux and MacOS. Unlike other software frameworks, NET Core is the most versatile framework that can be used to build a variety of software including Web applications, mobile applications, desktop applications, cloud services, micro-services, APIs, games, and internet of things applications. Unlike other frameworks, the NET Core is not limited to a single programming language, and supports multiple languages such as c#, vb NET, f#, XAML, and TypeScript. NET Core provides the most advanced, mature and broad class libraries, public APIs, multi-language support and tools. Based on the development platform with the NET Core being so strong, the method of the invention not only simplifies the development workload, but also increases the system deployment flexibility and improves the delivery efficiency, thereby being very suitable for being used in a distributed system.
In one embodiment of the present application, defining a corresponding micro service unit according to the split micro service specifically includes: firstly, decomposing a complex application program into a group of micro-services supporting independent deployment through analysis and modeling of a specific service field, then carrying out corresponding definition of micro-service units according to service micro-service division, and taking the micro-service units as minimum recognition objects for merging and/or splitting deployment of the application program; the micro service unit represents a unit for packing and deploying the micro service program, is a minimum functional set perceived by a user and represents a minimum unit for splitting the micro service.
Based on the domain driving design method as a guide, a set of models is formed for solving the problems in the scene, then the set of models is used for solving the business problems, and the micro-services are divided towards the business. For example, in the online shopping link, the inventory is related to the number of orders, the more orders, the less the inventory, the two micro services are the orders and the inventory, and the corresponding micro service units are respectively built.
As shown in FIG. 2, the micro service units with orders and the micro service units with invoices can be deployed by combining the two micro service units together, that is, by a single deployment mode, or by separately deploying the two micro service units. Since the monomer system is deployed in a process, we often modify a small function, and the operation of other functions is affected in order to deploy the monomer system on line. In addition, the use scenes, concurrency and consumed resource types of the functional modules in the single application are different, and the utilization of the resources is mutually influenced, so that the system capacity of each business concurrency module is most difficult to give accurate assessment. In this case, the micro service units can be deployed separately, and the coupling between services is reduced by adopting multiple processes. The advantage of single deployment is that it can be developed and used very conveniently, for example, in government and military departments, when the change of data of one service does not affect another service too much, the cost can be reduced better by adopting single deployment, and the specific deployment mode depends on the specific situation.
The micro service unit (Micro Service Unit is called MSU for short) represents a unit for packing and deploying micro service programs, and consists of an executable program set, pages, documents (end user support materials and release instructions) and the like, which are the minimum functional set perceived by a user and represent the minimum unit for splitting the micro service. Firstly, analyzing and modeling a specific service field, decomposing a complex application into a group of micro-services supporting independent deployment, then defining corresponding micro-service units according to service micro-service division, and taking the micro-service units as the minimum recognition object of the application program merging/splitting deployment. The evolution of the micro-service architecture is a progressive process, and in the evolution process, the micro-service is often reconstructed or even repartitioned according to the change of the service, so that the architecture is more reasonable.
And according to the micro service, defining the micro service unit, and generating a self-description file of the micro service unit.
In one embodiment of the present application, the micro service unit types specifically include:
a business micro-service unit and a public micro-service unit;
the business micro service unit comprises external services and pages, and information such as a program set, a configuration file and the like related to the module on which the realization depends, is a complete deployment catalog, and has no special requirement on the naming of folders, and is generally the same as the name of the service unit. The public micro-service unit does not contain external service interfaces and implementations, but exists as a common program set and configuration file, provides a common program interface on which programs run, and cannot be deployed independently.
In one embodiment of the present application, the partitioning of the micro service unit types corresponding to the micro service units specifically includes: in the actual splitting of the micro services, the core domain must be included in the traffic micro service unit, while the generic domain and the support domain, because they are generic between different critical applications, even different micro service units of the same critical application, can be split into a common micro service unit in order to avoid repeated deployment in multiple micro service units.
According to different corresponding responsibilities of business and program, the micro-service units are divided into two types: and the service micro-service units and the public micro-service units are independently deployed. The business micro-service unit comprises external services and pages, and information such as a program set, a configuration file and the like related to the module on which the realization depends, is a complete deployment catalog, and has no special requirements on the naming of folders and is generally the same as the name of the service unit; the public micro-service unit does not contain external service interfaces and implementations, but exists as a common program set and configuration file, provides a common program interface on which programs run, and cannot be deployed independently. In the micro-service splitting process, the program needs to be identified as different types of micro-service units according to different functions, and the subsequent steps can be loaded according to different orders according to the types. When the micro service unit is actually split, the core domain in the domain-driven design DDD is a part of the whole service domain, and is also a main contributor to service success. In implementing DDD, we focus mainly on the core domain, so the core domain must be contained in the traffic micro-service unit, while the generic domain and the support domain can be split into a common micro-service unit in order to avoid repeated deployment among multiple micro-service units, as they are generic among different critical applications, even different micro-service units of the same critical application.
In one embodiment of the present application, an application is started, and first, all micro service unit description files in a current system are identified to form a micro service unit list, which specifically includes:
when an application program is started, firstly, all subdirectories in a system are searched circularly, all micro service unit description files in the current system are identified, and a micro service unit list, a corresponding path of each micro service unit and program set information are formed.
In one embodiment of the present application, according to the list of micro service units identified by the system, the program sets are loaded according to the micro service unit types according to different sequences, and specifically includes:
and sequentially loading the program set files under each micro-service unit path through the program integration extension service loop.
In one embodiment of the application, the application server is started by collecting the Controller information of all Web application programming interfaces WebAPI service managers through an extended application model, adding a custom Filter and a route.
1. Sequentially loading the program set files under each micro-service unit path through a program integration extension service cycle;
2. and collecting all the WebAPI service Controller information through the extended application model, adding a custom Filter and a route, and completing the starting of the application server.
In one embodiment of the present application, the micro service units are loosely coupled, isolation between the micro service units is achieved through a remote procedure call RPC framework, and remote procedure call RPC calls are achieved using a DotNetty or a fluen.
Remote procedure call protocol RPC (Remote Procedure Call Protocol), a protocol that requests services from a remote computer program over a network without requiring knowledge of underlying network technology. The RPC protocol assumes the existence of certain transport protocols, such as TCP or UDP, to carry information data between communication programs. In the OSI network communication model, the RPC spans a transport layer and an application layer. RPC makes it easier to develop applications including network distributed multiprogramming. Based on the RPC protocol, the order service and inventory service can be mutually called or isolated through the RPC. Implementation of RPC calls may use the DotNetty or fluen.
The foregoing is merely exemplary of the present application and is not intended to limit the present application. Various modifications and changes may be made to the present application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. which are within the spirit and principles of the present application are intended to be included within the scope of the claims of the present application.

Claims (9)

1. The method for realizing the micro-service supporting different deployment modes based on the NET Core is characterized by comprising the following steps of:
generating a description file of the micro service unit according to the corresponding micro service unit defined by the split micro service;
dividing the micro service unit types corresponding to the micro service units according to different functions of the micro service units;
starting an application program, firstly identifying all the micro service unit description files in the current system to form a micro service unit list;
loading a program set according to the micro service unit type and the sequence according to the micro service unit list identified by the system;
when a micro-service unit is required to be called in a process, calling among the micro-service units through a Remote Procedure Call (RPC) framework;
the corresponding micro service unit is defined according to the split micro service, and specifically comprises the following steps:
firstly, decomposing a complex application program into a group of micro-services supporting independent deployment through analysis and modeling of a specific service field, then carrying out corresponding definition of micro-service units according to service micro-service division, and taking the micro-service units as minimum recognition objects for merging and/or splitting deployment of the application program;
the micro-service unit represents a unit for packing and deploying the micro-service program, is a minimum function set perceived by a user and represents a minimum unit for splitting the micro-service.
2. The method according to claim 1, characterized in that said micro service unit type comprises in particular:
a public micro service unit;
the public micro service unit does not contain an external service interface and implementation, but exists as a common program set and configuration file, provides a common program interface on which programs run and cannot be deployed independently.
3. The method according to claim 2, characterized in that said micro service unit type comprises in particular:
a business micro service unit;
the business micro-service unit comprises external services and pages, and information such as a program set, a configuration file and the like related to the module on which the business micro-service unit is realized, is a complete deployment catalog, has no special requirement on the naming of a folder, and is generally the same as the name of the service unit.
4. A method according to claim 3, wherein the partitioning of the micro service unit types corresponding to the micro service units specifically comprises:
in actually splitting the micro services, the core domain must be included in the business micro service unit, while the generic domain and the support domain are split into the common micro service unit in order to avoid repeated deployment among a plurality of the micro service units, since they are generic among different critical applications, even different ones of the same critical application.
5. The method according to claim 1, wherein starting the application program first identifies all the micro service unit description files in the current system to form a micro service unit list, and specifically comprises:
when an application program is started, firstly, circularly searching all subdirectories in a system, and identifying all micro service unit description files in the current system to form a micro service unit list and corresponding paths and program set information of each micro service unit.
6. The method according to claim 1, wherein loading the program sets in different orders according to the micro service unit types according to the micro service unit list identified by the system, specifically comprises:
and sequentially loading the program set files under each micro service unit path through a program integration extension service loop.
7. The method of claim 6, wherein the method further comprises:
and collecting Controller information of all Web application programming interfaces (WebAPI) service managers through an extended application model, adding a custom Filter and a route, and completing the starting link of an application server.
8. The method according to claim 1, wherein the method further comprises:
and realizing isolation among the micro service units through a Remote Procedure Call (RPC) framework, and realizing Remote Procedure Call (RPC) by using DotNet or Flurl.
9. The method according to claim 1, characterized in that said micro-service unit comprises in particular:
executable program sets, pages, documents that support materials and release notes for end users.
CN202011631150.4A 2020-12-30 2020-12-30 Micro-service implementation method supporting different deployment modes based on NET Core Active CN112685052B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011631150.4A CN112685052B (en) 2020-12-30 2020-12-30 Micro-service implementation method supporting different deployment modes based on NET Core

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011631150.4A CN112685052B (en) 2020-12-30 2020-12-30 Micro-service implementation method supporting different deployment modes based on NET Core

Publications (2)

Publication Number Publication Date
CN112685052A CN112685052A (en) 2021-04-20
CN112685052B true CN112685052B (en) 2024-01-23

Family

ID=75455901

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011631150.4A Active CN112685052B (en) 2020-12-30 2020-12-30 Micro-service implementation method supporting different deployment modes based on NET Core

Country Status (1)

Country Link
CN (1) CN112685052B (en)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110944039A (en) * 2019-10-31 2020-03-31 上海无线通信研究中心 Micro-service discovery method, system and device for 5G access network
CN111782233A (en) * 2020-08-05 2020-10-16 绵阳市智慧城市产业发展有限责任公司 Micro-service multi-scenario deployment adaptive design model

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3069669B1 (en) * 2017-07-25 2019-10-18 Worldline A COMMUNICATION SYSTEM AND A METHOD FOR ACCESSING AND DEPLOYING EPHEMICAL MICROSERVICES ON A HETEROGENEOUS PLATFORM
US10686862B2 (en) * 2017-12-08 2020-06-16 Salesforce.Com, Inc. Apparatus and method for low-latency message request/response processing

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110944039A (en) * 2019-10-31 2020-03-31 上海无线通信研究中心 Micro-service discovery method, system and device for 5G access network
CN111782233A (en) * 2020-08-05 2020-10-16 绵阳市智慧城市产业发展有限责任公司 Micro-service multi-scenario deployment adaptive design model

Also Published As

Publication number Publication date
CN112685052A (en) 2021-04-20

Similar Documents

Publication Publication Date Title
US8990812B2 (en) Task decomposition with throttled message processing in a heterogeneous environment
US8572236B2 (en) Distributing services in graph-based computations
US20240152406A1 (en) Deploying cloud-native services across control planes
Balis HyperFlow: A model of computation, programming approach and enactment engine for complex distributed workflows
CN112394947B (en) Information system based on micro-service architecture
CN101640694B (en) Method for generating simple object access protocol messages and process engine
CN112463290A (en) Method, system, apparatus and storage medium for dynamically adjusting the number of computing containers
CN114296933A (en) Implementation method of lightweight container under terminal edge cloud architecture and data processing system
CN116860746A (en) Processing system for lightweight big data
Czarnul A model, design, and implementation of an efficient multithreaded workflow execution engine with data streaming, caching, and storage constraints
CN112685052B (en) Micro-service implementation method supporting different deployment modes based on NET Core
EP2400390A1 (en) Provision of services and libraries to remote clients
Merzky et al. Application level interoperability between clouds and grids
CN116915700A (en) Front-end micro-service aggregation technology solution
CN116932147A (en) Streaming job processing method and device, electronic equipment and medium
Cai et al. Deployment and verification of machine learning tool-chain based on kubernetes distributed clusters: This paper is submitted for possible publication in the special issue on high performance distributed computing
Yildiz et al. Decaf: Decoupled dataflows for in situ workflows
CN116755799A (en) Service arrangement system and method
Ciatto et al. TuSoW: Tuple spaces for edge computing
Arellanes et al. Decentralized data flows for the functional scalability of service-oriented iot systems
Heydarnoori et al. Towards an automated deployment planner for composition of web services as software components
US20230418681A1 (en) Intelligent layer derived deployment of containers
Al-Jaroodi et al. Distributed systems middleware architecture from a software engineering perspective
González‐López de Murillas et al. Parallel computation of the reachability graph of petri net models with semantic information
CN101739259A (en) Production method and device of service software

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant