CN112965705A - Publishing method and device of micro-service interface, electronic equipment and storage medium - Google Patents

Publishing method and device of micro-service interface, electronic equipment and storage medium Download PDF

Info

Publication number
CN112965705A
CN112965705A CN202110260566.8A CN202110260566A CN112965705A CN 112965705 A CN112965705 A CN 112965705A CN 202110260566 A CN202110260566 A CN 202110260566A CN 112965705 A CN112965705 A CN 112965705A
Authority
CN
China
Prior art keywords
interface
micro
micro service
service
name
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.)
Granted
Application number
CN202110260566.8A
Other languages
Chinese (zh)
Other versions
CN112965705B (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.)
China Travelsky Holding Co
Original Assignee
China Travelsky Holding Co
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 China Travelsky Holding Co filed Critical China Travelsky Holding Co
Priority to CN202110260566.8A priority Critical patent/CN112965705B/en
Priority claimed from CN202110260566.8A external-priority patent/CN112965705B/en
Publication of CN112965705A publication Critical patent/CN112965705A/en
Application granted granted Critical
Publication of CN112965705B publication Critical patent/CN112965705B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/30Creation or generation of source code
    • G06F8/31Programming languages or programming paradigms
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems
    • G06F16/252Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/283Multi-dimensional databases or data warehouses, e.g. MOLAP or ROLAP
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/448Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4482Procedural

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Stored Programmes (AREA)

Abstract

The invention provides a method and a device for publishing a micro-service interface, electronic equipment and a storage medium. The method comprises the following steps: checking the input micro service interface definition described by an interface definition language IDL, and determining whether the micro service interface is a micro service new interface or a micro service upgrading interface; checking the determined micro-service newly-built interface or the micro-service upgrading interface; if the micro-service newly-built interface is effective or the micro-service upgrading interface is effective and compatible, taking the micro-service newly-built interface or the micro-service upgrading interface as a micro-service interface to be processed; converting the micro service interface definition described by the micro service interface to be processed by IDL into a program design language source code SDK packet; and checking the SDK package, and issuing the SDK package passing the checking to a predefined software warehouse. Therefore, the purpose of meeting the high requirement of releasing the micro service interface in the micro service mode is achieved when the micro service interface is released.

Description

Publishing method and device of micro-service interface, electronic equipment and storage medium
Technical Field
The invention relates to the technical field of cloud computing, in particular to a method and a device for publishing a micro-service interface, electronic equipment and a storage medium.
Background
At present, as enterprise services are continuously increased, a service system is also converted to a micro service mode, so that the number of micro service interfaces is correspondingly increased, and the requirements on the related attributes of the micro service interfaces are correspondingly improved.
In the prior art, after a service system is converted into a micro service mode, the number of services is increased in geometric progression compared with the traditional service system, and the number of micro service interfaces is also increased synchronously. In the micro-service mode, the interface is used as a contract carrier for calling between the description services, so that the attributes of the interface in the aspects of design normalization, definition stability, test completeness and the like are higher in requirements, and the release of the micro-service interface has direct influence on the attributes, but the current release mode of the micro-service interface cannot meet the requirements.
Therefore, a new issue method is needed to implement the issue of the micro service interface.
Disclosure of Invention
In view of this, embodiments of the present invention provide a method and an apparatus for issuing a micro service interface, an electronic device, and a storage medium, so as to solve the problem that the prior art cannot meet a high requirement for issuing a micro service interface in a micro service mode.
In order to achieve the above purpose, the embodiments of the present invention provide the following technical solutions:
the first aspect of the embodiment of the invention discloses a method for publishing a micro-service interface, which comprises the following steps:
checking the input micro service interface definition described by an interface definition language IDL, and determining whether the micro service interface is a micro service new interface or a micro service upgrading interface;
if the new micro-service interface is determined, checking whether the new micro-service interface is effective;
if the micro service upgrading interface is determined, checking whether the micro service upgrading interface is effective and compatible;
if the micro-service newly-built interface is effective or the micro-service upgrading interface is effective and compatible, taking the micro-service newly-built interface or the micro-service upgrading interface as a micro-service interface to be processed;
converting the micro service interface definition described by the IDL of the micro service interface to be processed into a programming language source code (SDK) packet;
and auditing the SDK package, and issuing the SDK package passing the auditing to a predefined software warehouse.
Optionally, the verifying the input micro service interface definition described in the interface definition language IDL to determine whether the micro service interface is a micro service new interface or a micro service upgrade interface includes:
acquiring a service system name, a micro service interface name and a micro service interface version field value in the IDL description;
determining a service system with the same service system name by using the service system name, searching all micro service interfaces stored in the service system based on the micro service interface name, and determining whether a micro service interface with an interface name matched with the micro service interface exists;
if the matched micro service interface is not searched, determining the micro service interface as a new micro service interface;
if the matched micro service interface is searched, comparing whether the version field value of all the micro service interfaces in the matched micro service interface is smaller than the version field value of the micro service interface;
and if the number of the micro service interfaces is less than the preset value, determining that the micro service interface is a micro service upgrading interface.
Optionally, the verifying whether the new micro-service interface is valid includes:
reading the definition of the newly-built interface of the micro-service described by the IDL, and extracting the feature points in the definition of the newly-built interface of the micro-service, wherein the feature points at least comprise field names and field types of fields defined by a data structure and parameter names and parameter types of parameters defined by a method;
inquiring whether a preset data dictionary has a name which is the same as the field name and/or a name which is the same as the parameter name, wherein the data dictionary comprises semantics of preset names and types;
if the name same as the field name exists, checking whether the field type of the field with the same name is consistent with the semantic type, and/or checking whether the parameter type of the parameter with the same name is consistent with the semantic type if the name same as the parameter name exists;
and if so, determining that the newly established interface of the micro-service is effective.
Optionally, the verifying whether the micro service upgrade interface is valid and compatible includes:
reading the definition of the micro service upgrade interface described by the IDL, and extracting feature points in the definition of the micro service upgrade interface, wherein the feature points at least comprise field names and field types of fields defined by a data structure and parameter names and parameter types of parameters defined by a method; inquiring whether a preset data dictionary has a name which is the same as the field name and/or a name which is the same as the parameter name, wherein the data dictionary comprises semantics of preset names and types;
if the name same as the field name exists, checking whether the field type of the field with the same name is consistent with the semantic type, and/or checking whether the parameter type of the parameter with the same name is consistent with the semantic type if the name same as the parameter name exists;
if the data structure of the matched micro service interface is consistent with the data structure of the micro service interface, determining that the micro service upgrading interface is valid, comparing all fields defined by the data structure in the matched micro service interface with all fields defined by the data structure in the definition of the micro service upgrading interface, and comparing parameters defined by a method in the matched micro service interface with parameters defined by a method in the definition of the micro service upgrading interface;
if the micro service upgrading interface and the matched micro service interface are all satisfied with the comparison condition, determining that the micro service upgrading interface is compatible with the matched micro service interface;
if any one of the micro service upgrading interfaces does not meet the comparison condition, determining that the micro service upgrading interface is incompatible with the matched micro service interface;
wherein the comparison conditions include:
querying whether field names of all fields defined by a data structure in the matched micro service interface and parameter names of parameters defined by a method exist in the micro service upgrade interface definition;
and if so, checking whether the field types of the fields with the same name and the parameter types of the parameters with the same name are completely consistent.
Optionally, the converting the micro service interface definition described by the IDL for the micro service interface to be processed into a programming language source code SDK package includes:
acquiring a definition of the micro service interface to be processed;
converting the micro service interface definition to be processed into a corresponding programming language source code according to a preset output programming language and a preset conversion rule;
and compiling the source code into a programming language source code SDK package.
Optionally, after the converting the micro service interface definition described by the IDL for the micro service interface to be processed into the programming language source code SDK packet, the method further includes:
and releasing the SDK package to a preset formal software warehouse through an informal software warehouse.
Optionally, the auditing the SDK package and issuing the SDK package that passes the auditing to a predefined software warehouse include:
acquiring the micro service interface definition described by an interface definition language IDL;
performing automatic audit and/or manual audit on the microservice interface;
and if the micro-service interface passes automatic verification and manual verification, releasing the SDK package to a predefined formal software warehouse.
The second aspect of the embodiment of the invention discloses a release device of a micro-service interface, which comprises an interface definition checking component, an interface programming language source code SDK conversion component, an interface auditing component and an interface release component;
the interface definition checking component is used for checking an input micro service interface definition described by an interface definition language IDL (interface definition language), determining whether the micro service interface is a micro service new interface or a micro service upgrading interface, checking whether the micro service new interface is effective or not if the micro service interface is determined to be the micro service new interface, checking whether the micro service upgrading interface is effective and compatible or not if the micro service upgrading interface is determined to be the micro service upgrading interface, and taking the micro service new interface or the micro service upgrading interface as a micro service interface to be processed if the micro service new interface is effective or the micro service upgrading interface is effective and compatible;
an interface programming language source code SDK conversion component, which is used for converting the micro service interface definition described by the IDL of the micro service interface to be processed into a programming language source code SDK packet;
the interface auditing component is used for auditing the SDK package;
and the interface issuing component is used for issuing the SDK package which passes the auditing to a predefined software warehouse.
The third aspect of the embodiment of the present invention discloses an electronic device, where the electronic device is configured to run a program, and when the program runs, the method for issuing a micro service interface disclosed in the first aspect of the embodiment of the present invention is executed.
The fourth aspect of the embodiment of the present invention discloses a computer storage medium, where the storage medium includes a storage program, and when the program runs, a device in which the storage medium is located is controlled to execute the method for issuing the micro service interface disclosed in the first aspect of the embodiment of the present invention.
Based on the publishing method, device, electronic device and storage medium of the micro service interface provided by the embodiment of the invention, the method comprises the following steps: checking the input micro service interface definition described by an interface definition language IDL, and determining whether the micro service interface is a micro service new interface or a micro service upgrading interface; if the new micro-service interface is determined, checking whether the new micro-service interface is effective; if the micro service upgrading interface is determined, checking whether the micro service upgrading interface is effective and compatible; if the micro-service newly-built interface is effective or the micro-service upgrading interface is effective and compatible, taking the micro-service newly-built interface or the micro-service upgrading interface as a micro-service interface to be processed; converting the micro service interface definition described by the IDL of the micro service interface to be processed into a programming language source code (SDK) packet; and auditing the SDK package, and issuing the SDK package passing the auditing to a predefined software warehouse. In the embodiment of the invention, the input micro-service interface definition described by IDL is verified, whether the micro-service interface described by IDL is a new interface or an upgrading interface is determined, the effectiveness of the new micro-service interface and the compatibility of the micro-service upgrading interface are verified, the verified micro-service interface definition is converted into an SDK package, the SDK package is verified, and the verified SDK package is issued to a predefined software warehouse, so that the aim of meeting the high requirement of issuing the micro-service interface in a micro-service mode is fulfilled when the micro-service interface is issued.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.
Fig. 1 is a schematic flowchart of a method for publishing a micro service interface according to an embodiment of the present invention;
fig. 2 is a schematic flowchart of determining whether a microservice interface is a microservice new interface or a microservice upgrade interface according to an embodiment of the present invention;
fig. 3 is a schematic flowchart of a process for verifying whether a new interface of a microservice is valid according to an embodiment of the present invention;
fig. 4 is a schematic flowchart of a process for checking whether a microservice upgrade interface is compatible according to an embodiment of the present invention;
FIG. 5 is a diagram illustrating an example of IDL conversion into SDK packets according to an embodiment of the present invention;
FIG. 6 is an exemplary diagram of validity checking and compatibility checking for interface definitions provided by an embodiment of the present invention;
fig. 7 is a block diagram of a micro service interface issuing apparatus according to an embodiment of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
In this application, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
As can be seen from the background art, in the micro service mode, the interface is used as a contract carrier for calling between the description services, so that higher requirements are placed on attributes in the aspects of design normalization, definition stability, test completeness and the like of the interface, and the release of the micro service interface directly affects the attributes, but the current release mode of the micro service interface cannot meet the requirements.
In the embodiment of the present invention, by checking an input micro service Interface Definition described in an IDL (Interface Definition Language), determining whether a micro service Interface described in the IDL is a new Interface or an upgraded Interface, checking validity of the new micro service Interface and compatibility of the micro service upgraded Interface, converting the checked micro service Interface Definition into an SDK (Software Development Kit) package, checking the SDK package, and publishing the checked SDK package to a predefined Software repository, thereby achieving a purpose of satisfying a high requirement for publishing the micro service Interface in a micro service mode when publishing the micro service Interface.
Referring to fig. 1, a schematic flowchart of a method for publishing a micro service interface according to an embodiment of the present invention is provided. The method for issuing the micro-service interface comprises the following steps:
step S101: checking the input micro service interface definition described by IDL, if the micro service interface is a micro service new interface, executing step S102, if the micro service interface is a micro service upgrade interface, executing step S103, if the micro service interface is not a micro service new interface or a micro service upgrade interface, ending the release process.
In step S101, the verification is performed on the business system name, the micro service interface name and the micro service interface version field value in the read IDL description.
In the process of implementing step S101 specifically, according to the name of the service system, determining a service system having the same service system name, retrieving all micro service interfaces stored in the service system based on the name of the micro service interface, determining whether the micro service interface is a micro service newly-built interface, if it is determined that the micro service interface is the micro service newly-built interface, executing step S102, if it is determined that the micro service interface is not the micro service newly-built interface, determining whether the micro service interface is a micro service upgrade interface based on the version field value of the micro service interface, if it is determined that the interface is the micro service upgrade interface, executing step S103, and if it is determined that the interface is neither the micro service newly-built interface nor the micro service upgrade interface, ending the publishing process.
It should be noted that the matched micro service interface refers to a micro service interface with the same interface name in the service system having the same service system name as the micro service interface described in the IDL.
To better understand the process of checking the input micro service interface definition described in IDL, as shown in fig. 2, a schematic flow chart for determining whether the micro service interface is a micro service new interface or a micro service upgrade interface according to an embodiment of the present invention is provided:
step S201: and acquiring the business system name, the micro service interface name and the micro service interface version field value in the IDL description.
Step S202: and determining the service systems with the same service system name by using the service system name, and searching all micro service interfaces stored in the service system based on the micro service interface name.
Step S203: and determining whether a micro service interface with an interface name matched with the micro service interface exists, if not, determining that the micro service interface is a micro service newly-built interface, and if so, executing the step S204.
In the process of implementing step S203 specifically, all the micro service interfaces stored in the service system are retrieved according to the acquired name of the micro service interface, and it is determined whether the micro service interface is a new micro service interface. If the micro service interface is determined to be a micro service new interface, indicating that no micro service interface with the interface name matched with the micro service interface exists; if the micro service interface is determined not to be the new micro service interface, indicating that a micro service interface with an interface name matched with the micro service interface exists, executing step S204.
Step S204: and comparing whether the version field values of all the micro service interfaces in the matched micro service interfaces are smaller than the version field values of the micro service interfaces, if so, determining that the micro service interfaces are micro service upgrading interfaces, and if any one of the micro service interfaces is larger than the micro service upgrading interface, determining that the micro service interfaces are not the micro service upgrading interfaces.
In the process of implementing step S204 specifically, according to the obtained micro service interface name and micro service interface version field value in the IDL description, the magnitude of all the micro service interface version field values in the micro service interfaces with the same interface name and the magnitude of the micro service interface version field value described in the IDL are compared. If the micro service interfaces with the same interface name are determined to be smaller than the IDL, the micro service interface is determined to be a micro service upgrading interface, and the micro service interface version field value is larger than the micro service interface version field value described by the IDL; if any one of the micro service interfaces with the same interface name is determined to be larger than the IDL, the micro service interface is determined not to be a micro service upgrade interface, wherein the micro service interface version field value is larger than the micro service interface version field value described by the IDL.
Step S102: and checking whether the micro-service new interface is effective, if so, executing the step S104, and if not, ending the release process.
In step S102, the verification is performed on the feature points in the micro service interface definition extracted from the micro service interface definition described by the read IDL.
Wherein the feature points include, but are not limited to, field names and field types of fields defined by the data structure, and parameter names and parameter types of parameters defined by the method.
In the specific implementation process of step S102, according to the verification of the input micro service interface definition described in the interface definition language IDL, it is determined that the micro service interface is a micro service newly-built interface, and it is determined whether the micro service newly-built interface is valid, if it is determined that the micro service newly-built interface is valid, step S104 is executed, and if it is determined that the micro service newly-built interface is invalid, the release process is ended.
In order to better understand the process of verifying whether the new interface of the microservice is valid, as shown in fig. 3, a schematic flow chart of verifying whether the new interface of the microservice is valid is provided in the embodiment of the present invention:
step S301: reading the definition of the micro-service new interface described by the IDL, and extracting the characteristic points in the definition of the micro-service new interface.
In the process of implementing step S301 specifically, according to the read new interface definition of the micro service described by the IDL, a feature point is extracted from the new interface definition of the micro service.
Step S302: and inquiring whether a preset data dictionary has a name which is the same as the field name and/or a name which is the same as the parameter name, if so, executing the step S303, and if not, determining that the new micro-service interface is invalid.
In step S302, the data dictionary entries of the data dictionary at least include semantics in which names and types are preset.
In the process of implementing step S302, the semantics in the data dictionary are retrieved according to the field names of the fields defined by the data structure and the parameter names of the parameters defined by the method, which are extracted from the micro service interface definition. If the preset data dictionary has the semantics with the same name as the field name and/or the semantics with the same name as the parameter name, executing step S303; and if the preset data dictionary does not have the semantics with the same name as the field name and/or the semantics with the same name as the parameter name, determining that the newly-built interface of the micro-service is invalid.
Step S303: and checking whether the field type of the field with the same name is consistent with the semantic type and/or checking whether the parameter type of the parameter with the same name is consistent with the semantic type, if so, determining that the new interface of the micro-service is valid, and if not, determining that the new interface of the micro-service is invalid.
In the process of implementing step S303 specifically, the type of the semantic is retrieved according to the field type of the field having the same name as the semantic in the data dictionary and the parameter type of the parameter having the same name. If the field type of the field with the same name is consistent with the semantic type, and/or the parameter type of the parameter with the same name is consistent with the semantic type, determining that the micro-service interface is effective; and if the field type of the field with the same name is not consistent with the semantic type and/or the parameter type of the parameter with the same name is not consistent with the semantic type, determining that the micro-service newly-built interface is invalid.
Step S103: and checking whether the micro service upgrading interface is effective and compatible, if so, executing the step S104, and if not, ending the issuing process.
In step S103, the verification is performed on the feature points in the micro service upgrade interface definition extracted from the micro service upgrade interface definition described by the read IDL.
Wherein the feature points include, but are not limited to, field names and field types of fields defined by the data structure, and parameter names and parameter types of parameters defined by the method.
In the process of implementing step S103, it is checked whether the micro service upgrade interface is valid, if not, the release process is ended, if so, it is determined whether the micro service upgrade interface is compatible, if it is determined that the micro service upgrade interface is compatible, step S104 is executed, and if it is determined that the micro service upgrade interface is incompatible, the release process is ended.
In order to better understand the process of checking whether the microservice upgrade interface is valid and compatible, as shown in fig. 4, a schematic flow chart for checking whether the microservice upgrade interface is valid and compatible according to an embodiment of the present invention is shown:
step S401: reading the definition of the micro service upgrade interface described by the IDL, and extracting the characteristic points in the definition of the micro service upgrade interface.
In the process of implementing step S401 specifically, feature points are extracted from the micro service upgrade interface definition according to the read micro service upgrade interface definition described by the IDL.
Step S402: and inquiring whether a preset data dictionary has a name which is the same as the field name and/or a name which is the same as the parameter name, if so, executing a step S403, and if not, determining that the micro-service upgrade interface is invalid.
In step S402, the data dictionary includes semantics in which names and types are set in advance.
Step S403: checking whether the field type of the field with the same name is consistent with the semantic type, and/or checking whether the parameter type of the parameter with the same name is consistent with the semantic type if the field type of the field with the same name is consistent with the semantic type, if so, determining that the micro-service upgrading interface is valid, executing a step S404, and if not, determining that the micro-service upgrading interface is invalid.
It should be noted that the technical means for checking whether the micro service upgrade interface is valid is the same as the technical means for checking whether the micro service new interface is valid.
Step S404: inquiring whether field names of all fields defined by the data structure in the matched micro service interface and parameter names of parameters defined by the method exist in the definition of the micro service interface, if so, executing a step S405, and if not, determining that the micro service upgrading interface is incompatible with the matched micro service interface.
In the process of implementing step S404 specifically, according to the field names of the fields defined by the data structure and the parameter names of the parameters defined by the method extracted from the definition of the micro service upgrade interface, the field names of all the fields defined by the data structure and the parameter names of the parameters defined by the method in the matched micro service interface are queried.
If all field definitions in the data structure of the matched micro service interface exist in the data structure of the same name in the micro service upgrade interface, the field names of the corresponding fields are the same, and the parameter names of the parameters in the method definition of the same name are the same, it is described that the field names of all the fields defined by the data structure and the parameter names of the parameters defined by the method exist in the matched micro service interface definition, then step S405 is executed;
if all field definitions in the data structure of the matched micro service interface do not exist in the data structure of the same name in the micro service upgrading interface, the field names of the corresponding fields are different, or the parameter names of the parameters in the method definition of the same name are different, the field names of all fields defined by the data structure or the parameter names of the parameters defined by the method in the micro service interface definition do not exist, and the micro service upgrading interface is determined to be invalid and incompatible with the matched micro service interface.
Step S405: checking whether the field types of the fields with the same name and the parameter types of the parameters with the same name are completely consistent, if so, determining that the micro-service upgrading interface is compatible with the matched micro-service interface, and if not, determining that the micro-service upgrading interface is incompatible with the matched micro-service interface.
In the process of implementing step S405 specifically, according to the field type of the field with the same name in the data structure of the same name in the micro service upgrade interface as the matched micro service interface and the parameter type of the parameter with the same name in the definition of the method with the same name, the field type of the field with the same name in the data structure of the same name in the matched micro service interface and the parameter type of the parameter with the same name in the method with the same name are queried.
If the field types of the fields with the same name in the data structure with the same name of the micro service upgrading interface and the matched micro service interface are consistent, and the parameter types of the parameters with the same name in the method definition of the same name of the micro service upgrading interface and the matched micro service interface are completely consistent, determining that the micro service upgrading interface is compatible with the matched micro service interface;
and if the field types of the fields with the same name in the data structure with the same name of the micro service upgrading interface and the matched micro service interface are not consistent, or the parameter types of the parameters with the same name in the method definition of the same name of the micro service upgrading interface and the matched micro service interface are not consistent, determining that the micro service upgrading interface is not compatible with the matched micro service interface. .
Step S104: and establishing a new interface or a micro-service upgrading interface for the service as a micro-service interface to be processed.
Step S105: and converting the micro service interface definition described by the micro service interface to be processed in IDL into an SDK packet.
In the process of implementing step S105, first, a to-be-processed micro service interface definition of the to-be-processed micro service interface is obtained, then, the read to-be-processed micro service interface definition is converted according to a preset output programming language and a preset conversion rule, so as to obtain a corresponding programming language source code, and finally, the programming language source code is compiled into an SDK package.
In order to better understand the process of converting the micro service interface definition described by IDL of the micro service interface to be processed into the SDK packet, taking the SDK packet code of IDL converted into Java as an example herein, how the interface SDK packet conversion component converts IDL into the SDK packet written in the programming language source code is described, referring to fig. 5, an example diagram of converting IDL into SDK packet is provided for the embodiment of the present invention:
part (r) of fig. 5 is IDL description written in YAML format, and part (r) of fig. 5 obtains feature points in IDL description through interface SDK packet conversion component, including but not limited to interface type, service system name, interface version, data structure definition and method definition.
Wherein the data structure definitions include, but are not limited to, data structure names, field names, and field data types, and the method definitions include, but are not limited to, method names, parameter types, and return value data types.
Specifically, as shown in part iii of fig. 5, a data structure definition code is generated by an interface SDK packet conversion component according to IDL description shown in part i of fig. 5, a < prefix >. service > < system name > < interface version >. data "is used as a packet name of a source code file of the data structure part, a corresponding Java import statement is generated for each data type according to data types of all fields in the data structure, a Java class having the same name is generated for each data structure definition, and a variable definition, a get method, and a set method having the same name are generated for each field of the data structure in the Java class.
The part of < prefix > "is a fixed character string in the actual implementation system, such as part of com.
As described in part c of fig. 5, "com.contoso.service.invoke.comm v4. data" is used as the packet name of the source code file of the data structure part, and the data type includes the "int" type and the "string" type, so that the "import java.lang.integer" import statement and the "import java.lang.string" import statement are generated.
It should be noted that the variable type is a Java data type corresponding to the data type of the field in the IDL description.
Specifically, as shown in the fourth part of fig. 5, a source code that needs to be introduced by a micro service interface user is generated according to the IDL description shown in the first part of fig. 5 through an interface SDK packet conversion component, a packet name of a source code file that needs to be introduced by the interface user is adopted as "< prefix >. service. < system name > < interface version >. provider", a corresponding Java import statement is generated for each data type according to the data types of all fields in the data structure, a Java interface with the same name is generated according to the interface name, and a corresponding synchronous call Java method definition and an asynchronous call Java method definition are generated for each method of the interface in the Java interface.
As described in fig. 5, part (r), the package name of the source code file that needs to be introduced by the interface user is "com.
It should be noted that, when the synchronous call type Java method definition is generated, the method name of the Java method is consistent with the method name in the interface definition, in the parameters of the Java method, except for the last timeout parameter, the names and positions of the other parameters are consistent with the parameter definition of the method with the same name in the interface definition, and the parameter type and the return value type of the parameter generate corresponding Java data types according to the types of the parameter and the return value in the interface definition;
when the asynchronous call type Java method definition is generated, the method name of the Java method adds a prefix of "async _" to the method name in the interface definition, the return value type of the interface is changed to "Future < synchronous interface return value type >", and the remaining rules are the same as the corresponding parts in the generation of the synchronous call type Java method definition, and are not described herein again.
As described in part (c) of fig. 5, the method name of method 1 is "searchFlight" and the interface return value type is "FlightInfo". When the asynchronous call Java method definition is generated, as shown in the section (r) in fig. 5, the method name is "async _ search flight", and the return value type is changed to "Future < FlightInfo >".
Specifically, as shown in part fifthly in fig. 5, a source code that needs to be introduced by a micro service interface provider is generated according to IDL description shown in part r in fig. 5 through an interface SDK packet conversion component, a < prefix >. service > < system name > < interface version >. producer "is used as a packet name of a source code file that needs to be introduced by the interface provider, a corresponding Java import statement is generated for each data type according to the data types of all fields in the data structure, a Java interface with the same name is generated according to the interface name, and a corresponding synchronous call Java method definition and an asynchronous call Java method definition are generated for each method of the interface in the Java interface.
As described in part of fig. 5, the "com.contoso.service.invoke.v. 4.producer" is used as the packet name of the source code file that the interface provider needs to introduce.
It should be noted that, in the parameters of the Java method, except for the last callback parameter, the names and positions of the other parameters are consistent with the parameter definition of the method with the same name in the interface definition, and the parameter type and the return value type of the parameter generate corresponding Java data types according to the types of the parameter and the return value in the interface definition.
Optionally, in another embodiment of the present application, after performing step S105, the method may further include:
and releasing the SDK package to a preset formal software warehouse through an informal software warehouse.
Specifically, if an informal software warehouse is configured in the enterprise, the SDK package is pre-released to the informal software warehouse, the SDK package is released to a preset formal software warehouse through the informal software warehouse, and if the informal software warehouse is not configured in the enterprise, a link for directly downloading the interface SDK package is provided.
Step S106: and checking the SDK package, and issuing the SDK package passing the checking to a predefined software warehouse.
In the process of implementing step S106 specifically, according to the acquired micro service interface definition described by IDL, performing automatic audit and/or manual audit on the micro service interface, if the SDK package is already issued to a predefined formal software warehouse before the issue process is finished, it indicates that the micro service interface passes the automatic audit and the manual audit, and if the issue process is directly finished, it indicates that the micro service interface does not pass the automatic audit and the manual audit.
It should be noted that, for any micro service interface, either automatic audit or manual audit may be performed separately, or both automatic audit and manual audit are performed, as long as either automatic audit or manual audit is given to fail, the framework audit defined by the micro service interface does not pass, and if both the automatic audit and the manual audit are given to fail, the framework audit defined by the micro service interface passes.
Optionally, the process of automatically auditing is specifically implemented by, first, defining a set of auditing rules in advance, then, executing the auditing rules one by one on each input micro-service interface definition described by the IDL through an interface auditing component, and outputting a pass or fail after each rule is executed.
If the two pass, the automatic audit is passed;
if any one of the two is not passed, the automatic audit is not passed.
And finally, feeding back the result of automatic audit.
Optionally, the process of specifically implementing manual review includes, first, displaying the micro service interface definition on the human-computer interaction interface through the interface review component, then, selecting to pass or not to pass by the reviewer through a manner of clicking the human-computer interaction interface, and finally, obtaining a click feedback result of the human-computer interaction interface through the interface review component, and determining that the result is pass or not pass.
The devices of the human-computer interaction interface can be set by technicians, including but not limited to a PC, a PAD and a mobile phone.
The micro-service interface release method disclosed by the embodiment of the invention checks the input micro-service interface definition described by IDL, determines whether the micro-service interface described by IDL is a new interface or an upgrade interface, checks the effectiveness of the new micro-service interface and the compatibility of the micro-service upgrade interface, converts the checked micro-service interface definition into an SDK package, checks the SDK package, and releases the SDK package passing the check to a predefined software warehouse, thereby achieving the purpose of meeting the high requirement of releasing the micro-service interface under a micro-service mode when releasing the micro-service interface.
Based on the method for releasing the micro service interface provided in the embodiment of the present invention, in order to better understand whether the process of verifying whether the newly-built interface of the micro service is valid and whether the upgrade interface of the micro service is compatible, refer to fig. 6, which is an exemplary diagram of validity verification and compatibility verification defined for the interface provided in the embodiment of the present invention.
In an optional implementation manner, the process of checking whether the micro-service newly-established interface is valid is as follows:
first, as shown in part (1) in fig. 6, a data dictionary definition is obtained, and as shown in parts (2) and (3) in fig. 6, a feature point in an interface definition is extracted by an interface definition checking component, where the feature point includes field names and field types of fields in all data structures and parameter names and parameter types of parameters in all methods, as shown in two columns on the left side of a table in part (3) in fig. 6.
Wherein the data dictionary definition includes names and types of semantics in data dictionary entries.
It should be noted that the data dictionary definition includes three semantic items, which are an airline code, a flight number, and a seat number.
Then, as shown in the tables of parts (1) and (3) in FIG. 6, it is compared whether the names in the data dictionary definition are the same as those in the feature points, because the data dictionary has no semantics with the same name as the parameter named 'hkgs' in the method 'searchFlight' and the description name is different, the feature point can not pass validity check if the data dictionary has no semantics with the same name as the parameter named 'hkgs', and if the data dictionary has the same name, comparing whether the types in the data dictionary definition corresponding to the same names in the feature points are the same, because the type of the 'airlineno' in the data dictionary is 'int' and the data type of the 'airlineno' in the data structure 'FlightInfo' is 'string', the description types are different, it is determined that the feature point cannot pass validity check, since the data dictionary has the semantics with the same name and type as those of the "airline" in the data structure "FlightInfo", it is determined that the feature point passes the validity check. And finally, determining that the newly established interface of the micro-service is valid only if all the feature points pass validity check. If it is determined that there are two feature points that fail to pass the validity check as shown in parts (2) and (3) of fig. 6, it is determined that the microservice new interface in part (2) of fig. 6 is invalid, and if it is determined that all the feature points pass the validity check as shown in part (4) of fig. 6, it is determined that the microservice new interface in part (4) of fig. 6 is valid.
In an optional implementation manner, the process of checking whether the micro service upgrade interface is compatible is as follows:
suppose that: the interface definition shown in part (4) in fig. 6 is an old version interface definition, and the interface definitions shown in parts (5) and (6) in fig. 6 are microservice upgrade interface definitions.
Firstly, two microservice upgrade interface definitions of parts (5) and (6) in fig. 6 are obtained through an interface definition checking component, whether all data structure names and method names in the old version interface definitions exist in the microservice upgrade interface definitions is confirmed, all data structure names and method names in the part (4) exist as shown in parts (5) and (6) in fig. 6, and if none exists, the microservice upgrade interfaces are determined to be incompatible.
Then, inquiring whether all field definitions in the data structure of the old version interface exist in the data structure of the same name in the micro service upgrading interface and whether the names and the types of the corresponding fields are consistent, judging whether the parameter quantity, the parameter name, the parameter type and the types of the return values of the parameters in the method definition of the same name in the micro service upgrading interface are completely consistent with those in the interface of the old version, if all judgment conditions are met, determining that the micro service upgrading interface is compatible, and if any judgment condition is not met, determining that the micro service upgrading interface is incompatible.
Finally, the definition of the microservice upgrade interface shown in part (5) in fig. 6 satisfies all judgment conditions, which indicates that the definition can pass the compatibility check, and then it is determined that the microservice upgrade interface shown in part (5) is compatible, and as shown in part (6) in fig. 6, a field "airlineno" is absent in the data structure "FlightInfo" in the definition of the microservice upgrade interface, and a parameter "airlineno" is added in the method "searchFlight", which does not satisfy two judgment conditions, which indicates that the definition of the microservice upgrade interface shown in part (6) cannot pass the compatibility check, then it is determined that the microservice upgrade interface shown in part (6) is not compatible.
The micro-service interface release method disclosed by the embodiment of the invention checks the input micro-service interface definition described by IDL, determines whether the micro-service interface described by IDL is a new interface or an upgrade interface, checks the effectiveness of the new micro-service interface and the compatibility of the micro-service upgrade interface, converts the checked micro-service interface definition into an SDK package, checks the SDK package, and releases the SDK package passing the check to a predefined software warehouse, thereby achieving the purpose of meeting the high requirement of releasing the micro-service interface under a micro-service mode when releasing the micro-service interface.
Based on the publishing method of the micro service interface provided by the embodiment of the invention, the embodiment of the invention also provides a corresponding publishing device of the micro service interface.
Referring to fig. 7, a block diagram of a micro service interface issuing apparatus according to an embodiment of the present invention is shown, where the micro service interface issuing apparatus includes: an interface definition checking component 701, an interface SDK conversion component 702, an interface auditing component 703, and an interface publishing component 704.
The interface definition checking component 701 is used for checking an input micro service interface definition described by IDL (interface data link), determining whether the micro service interface is a micro service new interface or a micro service upgrading interface, checking whether the micro service new interface is effective if the micro service new interface is determined, checking whether the micro service upgrading interface is effective and compatible if the micro service upgrading interface is determined, and taking the micro service new interface or the micro service upgrading interface as a micro service interface to be processed if the micro service new interface is effective or the micro service upgrading interface is effective and compatible.
The interface definition checking component 701 may optionally include:
an obtaining unit 7011, configured to obtain a service system, a micro service interface name, and a micro service interface version field value in the IDL description;
a first checking unit 7012, configured to determine a same service system by using the service system, and retrieve, based on the name of the micro service interface, whether a matched micro service interface exists in all micro service interfaces stored in the same service system, if a matched micro service interface is not retrieved, the micro service interface is a new micro service interface, and execute a valid determining unit 7014, and if a matched micro service interface is retrieved, execute a second checking unit;
the second checking unit 7013 is configured to compare whether all micro service interface version field values in the matched micro service interfaces are smaller than the micro service interface version field value, if so, determine that the micro service interface is a micro service upgrade interface, first execute the effective determining unit 7014, and then execute the compatibility determining unit 7015;
the effective judgment unit 7014 is configured to extract feature points in the micro service interface definition, the characteristic points include at least a field name and a field type of a field defined by the data structure, and parameter names and parameter types of the parameters defined by the method, inquiring whether a preset data dictionary has the same name as the field name, and/or the name same as the parameter name, the data dictionary comprises the semantics of preset name and type, if the name same as the field name exists, whether the field type of the field with the same name is consistent with the type of the semantics is checked, and/or the name same as the parameter name exists, whether the parameter type of the parameter with the same name is consistent with the semantic type is checked, if so, the micro service interface is determined to be effective, and the micro service interface comprises a micro service new interface or a micro service upgrading interface.
The compatibility determining unit 7015 is configured to compare all fields defined by a data structure in the matched micro service interface with all fields defined by a data structure in the definition of the micro service interface, compare parameters defined by a method in the matched micro service interface with parameters defined by a method in the definition of the micro service interface, determine that the micro service upgrade interface is compatible with the matched micro service interface if both comparison conditions are met, and determine that the micro service upgrade interface is incompatible with the matched micro service interface if any comparison condition is not met, where the comparison conditions include: inquiring field names of fields defined by data structures in the matched micro service interfaces and whether parameter names of parameters defined by the method exist in the micro service interface definition, and if so, checking whether the field types of the fields with the same names and the parameter types of the parameters with the same names are completely consistent;
an interface SDK packet converting component 702, configured to convert the micro service interface definition described by the IDL for the to-be-processed micro service interface into an SDK packet.
The interface SDK packet conversion component 702 may optionally include:
an obtaining unit 7021, configured to obtain a to-be-processed microservice interface definition of the to-be-processed microservice interface;
the conversion unit 7022 converts the to-be-processed microservice interface definition into a source code of a corresponding programming language according to a preset output programming language and a preset conversion rule, and compiles the source code into an SDK package.
And an interface auditing component 703, configured to audit the SDK package.
The interface auditing component 703 optionally includes:
an obtaining unit 7031, configured to obtain the micro service interface definition described in IDL;
an auditing unit 7032, configured to perform automatic auditing and/or manual auditing on the microservice interface.
An interface issuing component 704 for issuing the SDK package that passes the audit to a predefined software repository.
In this embodiment of the present invention, the interface publishing component 704 is further configured to: and releasing the SDK package to a preset formal software warehouse through an informal software warehouse.
It should be noted that, the specific principle and the execution process of each module in the micro service interface publishing device disclosed in the embodiment of the present invention are the same as those of the corresponding part in the micro service interface publishing method disclosed in the embodiment of the present invention in fig. 1 to fig. 6, and reference may be made to the corresponding part in the micro service interface publishing method disclosed in the embodiment of the present invention, which is not described herein again.
The micro-service interface release device disclosed by the embodiment of the invention checks the input micro-service interface definition described by IDL, determines whether the micro-service interface described by IDL is a new interface or an upgrade interface, checks the effectiveness of the new micro-service interface and the compatibility of the micro-service upgrade interface, converts the checked micro-service interface definition into an SDK package, checks the SDK package, and releases the SDK package passing the check to a predefined software warehouse, thereby achieving the purpose of meeting the high requirement of releasing the micro-service interface under a micro-service mode when releasing the micro-service interface.
The embodiment of the present invention further provides an electronic device, configured to run a program, where when the program runs, the electronic device is specifically configured to implement the method for issuing the micro service interface provided in any one of the above embodiments.
The embodiment of the present invention further provides a storage medium, where the storage medium includes a storage program, and when the program runs, the storage medium is specifically configured to control a device in which the storage medium is located to implement the method for publishing the micro service interface provided in any of the above embodiments.
In the context of this disclosure, a computer storage medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, 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), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, the system or system embodiments are substantially similar to the method embodiments and therefore are described in a relatively simple manner, and reference may be made to some of the descriptions of the method embodiments for related points. The above-described system and system embodiments are only illustrative, wherein the units described as separate parts may or may not be physically separate, and the parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
Those of skill would further appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both, and that the various illustrative components and steps have been described above generally in terms of their functionality in order to clearly illustrate this interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (10)

1. A method for publishing a micro service interface is characterized by comprising the following steps:
checking the input micro service interface definition described by an interface definition language IDL, and determining whether the micro service interface is a micro service new interface or a micro service upgrading interface;
if the new micro-service interface is determined, checking whether the new micro-service interface is effective;
if the micro service upgrading interface is determined, checking whether the micro service upgrading interface is effective and compatible;
if the micro-service newly-built interface is effective or the micro-service upgrading interface is effective and compatible, taking the micro-service newly-built interface or the micro-service upgrading interface as a micro-service interface to be processed;
converting the micro service interface definition described by the IDL of the micro service interface to be processed into a programming language source code (SDK) packet;
and auditing the SDK package, and issuing the SDK package passing the auditing to a predefined software warehouse.
2. The method of claim 1, wherein said checking the input micro service interface definition described in the interface definition language IDL to determine whether the micro service interface is a micro service new interface or a micro service upgrade interface comprises:
acquiring a service system name, a micro service interface name and a micro service interface version field value in the IDL description;
determining a service system with the same service system name by using the service system name, searching all micro service interfaces stored in the service system based on the micro service interface name, and determining whether a micro service interface with an interface name matched with the micro service interface exists;
if the matched micro service interface is not searched, determining the micro service interface as a new micro service interface;
if the matched micro service interface is searched, comparing whether the version field value of all the micro service interfaces in the matched micro service interface is smaller than the version field value of the micro service interface;
and if the number of the micro service interfaces is less than the preset value, determining that the micro service interface is a micro service upgrading interface.
3. The method of claim 1, wherein said verifying whether said micro-service new interface is valid comprises:
reading the definition of the newly-built interface of the micro-service described by the IDL, and extracting the feature points in the definition of the newly-built interface of the micro-service, wherein the feature points at least comprise field names and field types of fields defined by a data structure and parameter names and parameter types of parameters defined by a method;
inquiring whether a preset data dictionary has a name which is the same as the field name and/or a name which is the same as the parameter name, wherein the data dictionary comprises semantics of preset names and types;
if the name same as the field name exists, checking whether the field type of the field with the same name is consistent with the semantic type, and/or checking whether the parameter type of the parameter with the same name is consistent with the semantic type if the name same as the parameter name exists;
and if so, determining that the newly established interface of the micro-service is effective.
4. The method of claim 2, wherein said verifying whether said micro-service upgrade interface is valid and compatible comprises:
reading the definition of the micro service upgrade interface described by the IDL, and extracting feature points in the definition of the micro service upgrade interface, wherein the feature points at least comprise field names and field types of fields defined by a data structure and parameter names and parameter types of parameters defined by a method; inquiring whether a preset data dictionary has a name which is the same as the field name and/or a name which is the same as the parameter name, wherein the data dictionary comprises semantics of preset names and types;
if the name same as the field name exists, checking whether the field type of the field with the same name is consistent with the semantic type, and/or checking whether the parameter type of the parameter with the same name is consistent with the semantic type if the name same as the parameter name exists;
if the data structure of the matched micro service interface is consistent with the data structure of the micro service interface, determining that the micro service upgrading interface is valid, comparing all fields defined by the data structure in the matched micro service interface with all fields defined by the data structure in the definition of the micro service upgrading interface, and comparing parameters defined by a method in the matched micro service interface with parameters defined by a method in the definition of the micro service upgrading interface;
if the micro service upgrading interface and the matched micro service interface are all satisfied with the comparison condition, determining that the micro service upgrading interface is compatible with the matched micro service interface;
if any one of the micro service upgrading interfaces does not meet the comparison condition, determining that the micro service upgrading interface is incompatible with the matched micro service interface;
wherein the comparison conditions include:
querying whether field names of all fields defined by a data structure in the matched micro service interface and parameter names of parameters defined by a method exist in the micro service upgrade interface definition;
and if so, checking whether the field types of the fields with the same name and the parameter types of the parameters with the same name are completely consistent.
5. The method of claim 1, wherein converting the micro service interface definition described by the IDL for the to-be-processed micro service interface into a programming language source code (SDK) package comprises:
acquiring a definition of the micro service interface to be processed;
converting the micro service interface definition to be processed into a corresponding programming language source code according to a preset output programming language and a preset conversion rule;
and compiling the source code into a programming language source code SDK package.
6. The method of claim 1, wherein after converting the micro service interface definition described by the IDL for the micro service interface to be processed into the SDK package, further comprising:
and releasing the SDK package to a preset formal software warehouse through an informal software warehouse.
7. The method of claim 1, wherein auditing the SDK package and publishing the SDK package that is approved to a predefined software repository comprises:
acquiring the micro service interface definition described by an interface definition language IDL;
performing automatic audit and/or manual audit on the microservice interface;
and if the micro-service interface passes automatic verification and manual verification, releasing the SDK package to a predefined formal software warehouse.
8. The release device of the micro-service interface is characterized by comprising an interface definition checking component, an interface programming language source code SDK conversion component, an interface auditing component and an interface release component;
the interface definition checking component is used for checking an input micro service interface definition described by an interface definition language IDL (interface definition language), determining whether the micro service interface is a micro service new interface or a micro service upgrading interface, checking whether the micro service new interface is effective or not if the micro service interface is determined to be the micro service new interface, checking whether the micro service upgrading interface is effective and compatible or not if the micro service upgrading interface is determined to be the micro service upgrading interface, and taking the micro service new interface or the micro service upgrading interface as a micro service interface to be processed if the micro service new interface is effective or the micro service upgrading interface is effective and compatible;
an interface programming language source code SDK conversion component, which is used for converting the micro service interface definition described by the IDL of the micro service interface to be processed into a programming language source code SDK packet;
the interface auditing component is used for auditing the SDK package;
and the interface issuing component is used for issuing the SDK package which passes the auditing to a predefined software warehouse.
9. An electronic device, characterized in that the electronic device is configured to run a program, wherein the program is configured to execute the publishing method of the micro service interface according to any one of claims 1-7 when running.
10. A computer storage medium, characterized in that the storage medium comprises a stored program, wherein when the program runs, the device on which the storage medium is located is controlled to execute the publishing method of the micro service interface according to any one of claims 1-7.
CN202110260566.8A 2021-03-10 Method and device for issuing micro-service interface, electronic equipment and storage medium Active CN112965705B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110260566.8A CN112965705B (en) 2021-03-10 Method and device for issuing micro-service interface, electronic equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110260566.8A CN112965705B (en) 2021-03-10 Method and device for issuing micro-service interface, electronic equipment and storage medium

Publications (2)

Publication Number Publication Date
CN112965705A true CN112965705A (en) 2021-06-15
CN112965705B CN112965705B (en) 2024-06-04

Family

ID=

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6263485B1 (en) * 1996-07-11 2001-07-17 Andrew Schofield Method and apparatus for describing an interface definition language-defined interface, operation, and data type
US6496833B1 (en) * 1999-11-01 2002-12-17 Sun Microsystems, Inc. System and method for generating code for query object interfacing
CN107103211A (en) * 2016-02-19 2017-08-29 腾讯科技(深圳)有限公司 SDK is sent, using issue, using operation method and device
CN107291447A (en) * 2017-05-17 2017-10-24 四川新网银行股份有限公司 A kind of method for automatically generating and issuing SDK codes
CN111367547A (en) * 2020-02-27 2020-07-03 平安国际智慧城市科技股份有限公司 Automatic interface code synchronization method, device and storage medium
CN111767035A (en) * 2020-06-22 2020-10-13 星辰天合(北京)数据科技有限公司 Application interface docking method and device based on OpenAPI
CN111930363A (en) * 2020-08-07 2020-11-13 北京字节跳动网络技术有限公司 Block interface code generation method and device

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6263485B1 (en) * 1996-07-11 2001-07-17 Andrew Schofield Method and apparatus for describing an interface definition language-defined interface, operation, and data type
US6496833B1 (en) * 1999-11-01 2002-12-17 Sun Microsystems, Inc. System and method for generating code for query object interfacing
CN107103211A (en) * 2016-02-19 2017-08-29 腾讯科技(深圳)有限公司 SDK is sent, using issue, using operation method and device
CN107291447A (en) * 2017-05-17 2017-10-24 四川新网银行股份有限公司 A kind of method for automatically generating and issuing SDK codes
CN111367547A (en) * 2020-02-27 2020-07-03 平安国际智慧城市科技股份有限公司 Automatic interface code synchronization method, device and storage medium
CN111767035A (en) * 2020-06-22 2020-10-13 星辰天合(北京)数据科技有限公司 Application interface docking method and device based on OpenAPI
CN111930363A (en) * 2020-08-07 2020-11-13 北京字节跳动网络技术有限公司 Block interface code generation method and device

Similar Documents

Publication Publication Date Title
US8024196B1 (en) Techniques for creating and translating voice applications
US6832196B2 (en) Speech driven data selection in a voice-enabled program
CN109542445A (en) A kind of method and apparatus that Android plug-in unit melts hair
CN101305590B (en) Extending voice-based markup using a plug-in framework
CN110244941B (en) Task development method and device, electronic equipment and computer readable storage medium
CN101101602A (en) Data format verification method and device
US20080120111A1 (en) Speech recognition application grammar modeling
CN110020358B (en) Method and device for generating dynamic page
CN102946415B (en) A kind of implementation method of mobile terminal this locality application and device
CN101763255A (en) Format conversion method and device of special interface tool
CN111814449B (en) Form analysis method, device, equipment and storage medium
CN101799766A (en) Method and device for analyzing script file by using third engine in Widget engine
CN109116828B (en) Method and device for configuring model codes in controller
US20080127128A1 (en) Type Validation for Applications Incorporating A Weakly-Typed Language
CN114217789A (en) Function component expansion method, device, equipment, storage medium and program product
CN113778897A (en) Automatic test method, device, equipment and storage medium of interface
CN112965705A (en) Publishing method and device of micro-service interface, electronic equipment and storage medium
CN112965705B (en) Method and device for issuing micro-service interface, electronic equipment and storage medium
CN112631563A (en) System development method and device based on framework, computer equipment and storage medium
US20230072988A1 (en) System and a method for automatic generation of smart contracts across blockchain platforms
CN114115954B (en) Method and device for automatically and integrally deploying service, electronic equipment and storage medium
CN113568678B (en) Method and device for dynamically loading resources and electronic equipment
CN115495081A (en) Method and system for generating and loading low-code page component based on JSON data
CN113590125A (en) Applet development method and device
US8196092B2 (en) XSL dialog modules

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