CN110955543A - Service processing method, device, equipment and computer readable storage medium - Google Patents

Service processing method, device, equipment and computer readable storage medium Download PDF

Info

Publication number
CN110955543A
CN110955543A CN201911271134.6A CN201911271134A CN110955543A CN 110955543 A CN110955543 A CN 110955543A CN 201911271134 A CN201911271134 A CN 201911271134A CN 110955543 A CN110955543 A CN 110955543A
Authority
CN
China
Prior art keywords
service
interface
spi
api
platform
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.)
Pending
Application number
CN201911271134.6A
Other languages
Chinese (zh)
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.)
Zhejiang Dasou Vehicle Software Technology Co Ltd
Original Assignee
Zhejiang Dasou Vehicle Software Technology 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 Zhejiang Dasou Vehicle Software Technology Co Ltd filed Critical Zhejiang Dasou Vehicle Software Technology Co Ltd
Priority to CN201911271134.6A priority Critical patent/CN110955543A/en
Publication of CN110955543A publication Critical patent/CN110955543A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • 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/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/547Remote procedure calls [RPC]; Web services

Abstract

The application relates to a service processing method, a device, equipment and a computer readable storage medium, wherein the method comprises the following steps: acquiring interface definition of the SPI interface, SDK for realizing definition of the SPI interface and service identification for identifying the SPI interface from a service platform through a service system; the service system realizes the service corresponding to the SPI interface according to the interface definition and the SDK, and packages the service corresponding to the SPI interface into an API interface; and the service system exposes the API interface to the service platform according to the service identifier so that the service platform calls the API interface according to the service identifier. By the method and the device, the problem that codes of the service platform and the service systems are seriously coupled and are difficult to separate in the related technology is solved, and the beneficial effect of decoupling the dependency relationship of the systems is realized.

Description

Service processing method, device, equipment and computer readable storage medium
Technical Field
The present application relates to the field of computer application technologies, and in particular, to a service processing method, an apparatus, a device, and a computer-readable storage medium.
Background
A system for processing a service in the related art generally includes a service platform and a plurality of service systems, and a certain service processing is usually implemented by a service system calling a certain API interface of the service platform. In some cases, when a plurality of service systems implement the same service process, interfaces corresponding to the service process may be defined separately, and then the interfaces defined by the service systems need to be implemented separately on the service platform.
Taking a service processing system composed of a service platform A, a service system B and a service system C as an example: the service system B and the service system C both depend on the user data of the service platform a, that is, the service platform a stores the user data of the service system B and also stores the user data of the service system C. Assuming that a user leave interface is provided on the service platform a, when a user has a leave logic, the service platform a needs to notify the service system B and the service system C after the leave logic is executed, so that the service system B and the service system C execute their respective related service logic after the leave. In the related art, it is first necessary to identify whether the leave-job user belongs to the service system B or the service system C in the code of the service platform a, and then call a leave-job interface of the corresponding service system. Because the job leaving interfaces of the service system B and the service system C are defined by the service system itself, and the interfaces are not necessarily the same, the service platform a needs to write a code for calling the corresponding interfaces of the service system B and the service system C respectively when implementing the job leaving interfaces.
Therefore, with the continuous development of services, the increasing number of service domains (service systems), the increasing number of service types and the continuous added service requirements, the codes of the service platform and the codes of each service system are seriously coupled and are difficult to separate, and the codes of each service system are interleaved and difficult to disassemble, so that the codes of the service platform are bloated.
In the related art, an effective solution has not been proposed yet to the problem that the codes of the service platform and the codes of the business systems are seriously coupled and are difficult to separate.
Disclosure of Invention
Based on this, the present application provides a business processing method, apparatus, device and computer readable storage medium, so as to solve the problem that the codes of the service platform and the codes of the respective business systems are seriously coupled and are difficult to separate in the related art.
In a first aspect, the present application provides a service processing method, where the method includes:
the service system acquires an interface definition of an SPI interface, an SDK for realizing the definition of the SPI interface and a service identifier for identifying the SPI interface from a service platform;
the service system realizes the service corresponding to the SPI interface according to the interface definition and the SDK, and packages the service corresponding to the SPI interface into an API interface;
and the service system exposes the API to the service platform according to the service identifier so that the service platform can call the API according to the service identifier.
In a possible implementation manner, the exposing, by the service system, the API interface to the service platform according to the service identifier includes:
and the service system exposes the API to the service platform on the dubbo according to the service identifier.
In a possible implementation manner, the service system implements the service corresponding to the SPI interface according to the interface definition and the SDK, and encapsulates the service corresponding to the SPI interface into an API interface includes:
the service system packages the service logic corresponding to the interface definition to obtain the service corresponding to the SPI interface;
and the service system issues the service corresponding to the SPI interface as an API interface through a dubbo.
In one possible implementation manner, the exposing, by the service system, the API interface to the service platform on a dubbo according to the service identifier includes:
and the business system exposes the API to the service platform in a dubbo annotation mode.
In a possible implementation manner, before the service system obtains the interface definition of the SPI interface and the SDK for implementing the SPI interface from the service platform, the method further includes:
the service platform acquires the user-defined requirement of the business system;
and the service platform generates the interface definition of the SPI interface and the SDK for realizing the definition of the SPI interface according to the user-defined requirement.
In one possible implementation manner, after the service platform generates the interface definition of the SPI interface and the SDK for implementing the SPI interface according to the custom requirement, the method further includes:
the service platform determines the service identifier corresponding to the SPI interface;
and the service platform allocates the service identifier to the service system so that the service system can acquire the interface definition and the SDK defined by the SPI interface according to the service identifier.
In one possible implementation manner, after the service system exposes the API interface to the service platform on a dubbo according to the service identifier, the method further includes:
and the service platform discovers and calls the API through a dubbo according to the service identifier.
In a second aspect, the present application provides a service processing apparatus, which is applied to a service system, and the apparatus includes:
the acquisition module is used for acquiring an interface definition of an SPI (Serial peripheral interface), an SDK (software development kit) defined by the SPI and a service identifier for identifying the SPI from a service platform;
the realization module is used for realizing the service corresponding to the SPI interface according to the interface definition and the SDK and packaging the service corresponding to the SPI interface into an API interface;
and the exposure module is used for exposing the API interface to the service platform according to the service identifier so that the service platform can call the API interface according to the service identifier.
In a third aspect, the present application provides a service processing device, which includes a memory, a processor, and a computer program stored on the memory and executable on the processor, and when the processor executes the computer program, the service processing method of the first aspect is implemented.
In a fourth aspect, the present application provides a computer-readable storage medium storing a computer program which, when executed by a processor, implements the business process method of the first aspect.
The service processing method, the service processing device, the service processing equipment and the computer readable storage medium provided by the application acquire an interface definition of an SPI interface, an SDK for realizing the definition of the SPI interface and a service identifier for identifying the SPI interface from a service platform through a service system; the service system realizes the service corresponding to the SPI interface according to the interface definition and the SDK, and packages the service corresponding to the SPI interface into an API interface; the service system exposes the API interface to the service platform according to the service identifier so that the service platform calls the API interface according to the service identifier, the problem that codes of the service platform and codes of various service systems are seriously coupled and are difficult to separate in the related technology is solved, and the beneficial effect of decoupling the dependency relationship of the systems is achieved.
The details of one or more embodiments of the application are set forth in the accompanying drawings and the description below to provide a more thorough understanding of the application.
Drawings
In order to more clearly illustrate the embodiments of the present application or technical solutions in related arts, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without inventive exercise.
Fig. 1 is a flowchart of a service processing method according to an embodiment of the present application;
fig. 2 is a block diagram of a service processing apparatus according to an embodiment of the present application;
fig. 3 is a schematic hardware structure diagram of a service processing device according to an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application. All other examples, which can be obtained by a person skilled in the art without making any inventive step based on the examples in this application, are within the scope of protection of this application.
It is obvious that the drawings in the following description are only examples or embodiments of the application, from which the application can also be applied to other similar scenarios without inventive effort for a person skilled in the art. Moreover, it should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another.
Reference in the specification to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the specification. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. It is explicitly and implicitly understood by one skilled in the art that the embodiments described herein can be combined with other embodiments.
Unless otherwise defined, technical or scientific terms used in the claims and the specification should have the ordinary meaning as understood by those of ordinary skill in the art to which this application belongs. The use of the terms "a" and "an" and "the" and similar referents in the context of describing and claiming the application are not to be construed as limiting in any way, but rather as indicating the singular or plural. The word "comprise" or "comprises", and the like, means that the element or item listed before "comprises" or "comprising" covers the element or item listed after "comprising" or "comprises" and its equivalent, and does not exclude other elements or items. "connected" or "coupled" and similar terms are not restricted to physical or mechanical connections, but may include electrical connections, whether direct or indirect. As used in the specification and claims of this application, "a plurality" means two or more. "and/or" describes the association relationship of the associated objects, meaning that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.
The embodiment is applied to a system consisting of a service platform and a business system, and is particularly suitable for a system consisting of at least one service platform and a plurality of business systems. Generally, in the above system, a service platform uses data of the service platform to implement a specific service.
The present embodiment provides a service processing method, as shown in fig. 1, which is a flowchart of a service processing method according to an embodiment of the present application, where the flowchart includes the following steps:
step S102, the Service system obtains, from a Service platform, an interface definition of a Service provider interface (SPI for short), a Software Development Kit (SDK for short) for implementing the SPI interface, and a Service identifier for identifying the SPI interface.
Taking a service processing system composed of a service platform and a plurality of service systems as an example, the service systems depend on data of the service platform, and generally, when a user finishes executing a certain service logic on the service platform, the service platform needs to notify a plurality of related service systems after the service logic is executed, so that the plurality of service systems execute their respective other related service logic after the service logic.
In step S102, the SPI interface defined on the service platform is a service discovery mechanism, and the service system can discover an interface implementing the service logic through the definition of the SPI interface. The SDK defined by the service platform provides implementation classes needed to implement the SPI interface, and may also provide examples, related documents, and other files for implementing the SPI interface. Through step S102, the business system obtains information required to implement the API interface. Wherein, the implementation class instance can be obtained by a (serviceloader.
Step S104, the service system implements the service corresponding to the SPI Interface according to the Interface definition and the SDK, and encapsulates the service corresponding to the SPI Interface into an Application Programming Interface (API for short).
For example, the service party refers to the SPI-SDK defined by the general service platform, implements the service logic related to the customized extension service of the general service platform, and carries its own service identifier.
In this embodiment, the service system implements a service corresponding to the SPI interface according to the interface definition of the SPI interface obtained from the service platform and the SDK for implementing the SPI interface. In order that the service platform can call the service corresponding to the SPI interface, the service system further encapsulates the service corresponding to the SPI interface into an API interface.
And step S106, the service system exposes the API interface to the service platform according to the service identifier so that the service platform can call the API interface according to the service identifier.
By the method, the service system acquires the service identifier for identifying the SPI interface from the service platform so as to realize the service corresponding to the SPI interface, packages the service corresponding to the SPI interface into the API interface, attaches the service identifier corresponding to the API interface and exposes the API interface to the service platform according to the service identifier. The exposed information includes, but is not limited to, at least one of: IP address, port, service name (or interface name), method name, etc.
In the above embodiment, the service platform may define the SPI interface according to the service logic that needs to be implemented, configure the SDK for implementing the SPI interface, and allocate the service identifier of the SPI interface to the corresponding service system, so that the service platform implements definition of the service extension point. After the service system obtains the definition of the SPI interface and the SDK for realizing the definition of the SPI interface, corresponding service is realized, and the service identifier of the service is exposed to the service platform again so that the service platform can call the service realized by the service system according to the service identifier, thereby realizing the service development point defined by the service platform.
Through the steps, the service system refers to the SPI-SDK defined by the service platform, realizes and encapsulates the SPI-SDK, namely realizes the service logic of the service system, forms the service corresponding to the SPI-SDK, and exposes the service to the service platform through the dubbo. The method solves the problem that codes of the service platform and the service systems are seriously coupled and difficult to separate in the related technology, and improves the delivery efficiency by decoupling the dependency relationship between the service platform and the service systems through plug-in development.
In some embodiments, in step S106, the service system exposes the API interface to the service platform on the dubbo according to the service identifier.
In this embodiment, the service system exposes the API interface to the service platform through the dubbo, so that the service platform can call the API interface. The dubbo as a remote procedure call framework can realize call among different servers and can improve the expansibility of projects.
In this embodiment, a tool service of a dubbo business is provided, and the tool service of the dubbo business can be configured in a service platform and/or a business system, so as to implement all or part of the method provided by this embodiment. The tool services include, but are not limited to, functions of at least one of:
(1) the SPI exposure tool is arranged, and the service system can conveniently expose the user-defined service expanded by the service platform to the dubbo.
(2) The service platform is provided with an SPI service acquisition tool, so that the service platform can call expanded custom services realized by the service system through the service identification in the service logic execution.
(3) The annotation is configured, so that the service platform can conveniently obtain the self-defining requirements of different service systems, and the obtained self-defining requirements are abstracted into a realizable interface, namely the SPI-SDK is defined; the business system can expose the expanded self-defined service with the business identification.
In a preferred embodiment, in step S106, when the service system is released and started, first, a tool service may be initialized by constructing a Spring-Bean, the tool service collects API interfaces implemented by the service system, and then exposes the API interfaces to the service platform according to an API release format on the dubbo according to the service identifiers attached to the API interfaces, so as to declare and provide services corresponding to the API interfaces.
In some embodiments, in step S104, the method further comprises: the service system packages the service logic corresponding to the interface definition to obtain the service corresponding to the SPI interface; and the service system publishes the service corresponding to the SPI interface as an API interface through the dubbo.
By the method, the service system packages the service logic corresponding to the interface definition, so that different service systems can realize the service logic of themselves, and the service system issues the service corresponding to the SPI interface as the API interface through the dubbo, so that in step S106, the service system exposes the API interface to the service platform through the dubbo for the service platform to call the API interface.
In some embodiments, in step S106, the method further comprises: and the business system exposes the API interface to the service platform in a dubbo annotation mode.
According to the method, the API interface is exposed to the service platform through an annotation mode, so that the service platform can define the SPI-SDK conveniently, and meanwhile, the service system can expose the dubbo service attached with the corresponding service identifier conveniently, and the service platform can call the dubbo service provided by the service system conveniently.
In some embodiments, before the service system obtains the interface definition of the SPI interface and the SDK for implementing the SPI interface from the service platform, the method further includes: the service platform acquires the user-defined requirement of the service system; and the service platform generates an interface definition of the SPI interface and an SDK for realizing the definition of the SPI interface according to the self-defined requirement.
By the method, the service platform acquires the custom requirements of different service systems, abstracts the acquired custom requirements into realizable interfaces, namely defines the SPI-SDK, and preferably opens the interfaces to the service systems after defining the SPI-SDK so as to expand the custom services required to be opened.
In some embodiments, after the service platform generates the interface definition of the SPI interface and the SDK for implementing the SPI interface according to the custom requirements, the method further includes: the service platform determines a service identifier corresponding to the SPI interface; the service platform distributes the service identifier to the service system, so that the service system obtains the interface definition according to the service identifier and the SDK defined by the SPI interface.
According to the method, after the service platform acquires the self-defining requirements of different service systems and abstracts the acquired self-defining requirements into a realizable interface, namely SPI-SDK is defined, the service platform determines the service identifier corresponding to the SPI and distributes the service identifier to the service system so as to open the expanded self-defining service, so that the service system acquires the interface definition and the SDK for realizing the SPI interface definition according to the service identifier, and the expanded self-defining service of the service platform is realized. The method for defining the interface specification by the basic platform system decouples the dependency relationship between the service platform and the service system through the development of the plug-in.
In some embodiments, after the service system exposes the API interface to the service platform on the dubbo according to the service identifier, the method further includes: and the service platform discovers and calls the API interface through the dubbo according to the service identifier.
By the method, the service platform discovers and calls the API (application programming interface) exposed by the service system through the referenceConfig of dubbo according to the service identifier appearing in the service logic, namely the calling tool class of the tool service is used for executing the service logic.
The embodiments of the present application will be described and illustrated below with reference to the preferred embodiments.
Taking a service processing system composed of a service platform A, a service system B and a service system C as an example: the service system B and the service system C both depend on the user data of the service platform a, that is, the service platform a stores the user data of the service system B and also stores the user data of the service system C. Assuming that a user leave interface is provided on the service platform a, when a user has a leave logic, the service platform a needs to notify the service system B and the service system C after the leave logic is executed, so that the service system B and the service system C execute their respective related service logic after the leave. In the related art, it is first necessary to identify whether the leave-job user belongs to the service system B or the service system C in the code of the service platform a, and then call a leave-job interface of the corresponding service system. Because the job leaving interfaces of the service system B and the service system C are defined by the service system itself, and the interfaces are not necessarily the same, the service platform a needs to write a code for calling the corresponding interfaces of the service system B and the service system C respectively when implementing the job leaving interfaces.
In the service processing method provided by the application, tool services of the dubbo service can be used, the service platform A only needs to define the job leaving interface, the service system B and the service system C respectively refer to the job leaving interface defined by the service platform A, and the service platform A does not need to write and call the corresponding job leaving interfaces of the service system B and the service system C, because the interfaces are unified. And the tool service of the dubbo service calls the off-duty interface of the service system B or the service system C according to the service identification in service execution.
If the service system D is accessed later, the service platform A does not need to add a code for calling the leaving interface of the service system D in the logic of the service platform A. The tool service of the dubbo service can call the corresponding job leaving interface according to the service identifier in the service execution process as long as the service of the service system D references the job leaving interface defined by the service platform A, so that the service coupling of the service platform A is reduced. After the service platform A defines an expansion interface (a deputy interface), the service system is only required to realize the expansion interface when a new service system is docked, and the service platform A does not need to be released again, so that API interaction between the service platform and the service system is reduced, and the service standardization is improved.
Summarizing the above preferred embodiments: the service platform A model defines a set of SPI-SDKs, a service system B, a service system C or other service systems are needed to realize the set of SDKs, realized API interfaces are exposed on the dubbo, then the service platform A selectively calls tool services of the dubbo service provided by the service system B or the service system C in the execution of the service logic according to service scene identification in the operation of the service logic, namely, tools for facilitating the exposure, discovery and calling of the service SPI interfaces of the service platform and the service system on the dubbo.
It can be known from the foregoing preferred embodiment that, the service processing method provided in the present application can ensure that the service expansion is supported even when the basic model is stable by injecting the data of the different domain services into the abstract model, and make the redundant service system logic into a standardized interface, so that the service system implements the service externalization of this part of logic through the SPI, thereby reducing the coupling of the basic service to the service.
In this embodiment, a service processing apparatus is further provided, which is applied to a service system, and is used to implement the foregoing embodiments and preferred embodiment modes, which have already been described and are not described again. As used below, the terms "module," "sub-module" may implement a combination of software and/or hardware for a predetermined function. While the system described in the embodiments below is preferably implemented in software, implementations in hardware, or a combination of software and hardware are also possible and contemplated.
Fig. 2 is a block diagram of a service processing apparatus according to an embodiment of the present application, and as shown in fig. 2, the apparatus includes: an acquisition module 202, an implementation module 204, an exposure module 206, wherein,
an obtaining module 202, configured to obtain, from a service platform, an interface definition of an SPI interface, an SDK for implementing the definition of the SPI interface, and a service identifier for identifying the SPI interface;
the implementation module 204 is coupled to the obtaining module 202, and configured to implement, according to the interface definition and the SDK, a service corresponding to the SPI interface, and package the service corresponding to the SPI interface into an API interface;
and an exposing module 206, coupled to the implementing module 204, configured to expose the API interface to the service platform according to the service identifier, so that the service platform calls the API interface according to the service identifier.
In some embodiments, the obtaining module 206 is configured to obtain, from the service platform, a service identifier for identifying the SPI interface.
In some embodiments, the exposing module 206 is configured to expose the API interface to the service platform on the dubbo according to the service identifier, so that the service platform calls the API interface according to the service identifier.
In some embodiments, the implementation module 204 further comprises: the packaging submodule is used for packaging the business logic corresponding to the interface definition to obtain the service corresponding to the SPI interface; and the issuing submodule is used for issuing the service corresponding to the SPI interface as the API interface through the dubbo.
In some embodiments, the exposing module 206 is configured to expose the API interface to the service platform through the dubbo annotation.
In some of these embodiments, the apparatus further comprises: the second acquisition module is used for acquiring the user-defined requirements of the service system; and the generating module is used for generating the interface definition of the SPI interface according to the user-defined requirement and realizing the SDK defined by the SPI interface.
In some of these embodiments, the apparatus further comprises: the determining module is used for determining a service identifier corresponding to the SPI interface; and the distribution module is used for distributing the service identifier to the service system so as to obtain the interface definition according to the service identifier and realize the SDK defined by the SPI interface.
In some of these embodiments, the apparatus further comprises: the discovery module is used for discovering the API interface through the dubbo according to the service identifier; and the calling module is used for calling the API through the dubbo according to the service identifier.
In addition, the service processing method described in the embodiment of the present application with reference to fig. 1 may be implemented by a service processing device. Fig. 3 shows a hardware structure diagram of a service processing device according to an embodiment of the present application.
The service processing device may comprise a processor 301 and a memory 302 in which computer program instructions are stored.
Specifically, the processor 301 may include a Central Processing Unit (CPU), or an Application Specific Integrated Circuit (ASIC), or may be configured to implement one or more Integrated circuits of the embodiments of the present Application.
Memory 302 may include mass storage for data or instructions. By way of example, and not limitation, memory 302 may include a Hard Disk Drive (HDD), floppy Disk Drive, flash memory, optical Disk, magneto-optical Disk, tape, or Universal Serial Bus (USB) Drive or a combination of two or more of these. Memory 302 may include removable or non-removable (or fixed) media, where appropriate. The memory 302 may be internal or external to the data processing apparatus, where appropriate. In a particular embodiment, the memory 302 is a non-volatile solid-state memory. In a particular embodiment, the memory 302 includes Read Only Memory (ROM). Where appropriate, the ROM may be mask-programmed ROM, Programmable ROM (PROM), Erasable PROM (EPROM), Electrically Erasable PROM (EEPROM), electrically rewritable ROM (EAROM), or flash memory or a combination of two or more of these.
The processor 301 reads and executes the computer program instructions stored in the memory 302 to implement any of the service processing methods in the above embodiments.
In one example, the traffic processing device may also include a communication interface 303 and a bus 300. As shown in fig. 3, the processor 301, the memory 302, and the communication interface 303 are connected via a bus 300 to complete communication therebetween.
The communication interface 303 is mainly used for implementing communication between modules, apparatuses, units and/or devices in the embodiment of the present application.
The bus 300 includes hardware, software, or both to couple the components of the business processing apparatus to one another. By way of example, and not limitation, a bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hypertransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an infiniband interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a video electronics standards association local (VLB) bus, or other suitable bus or a combination of two or more of these. Bus 110 may include one or more buses, where appropriate. Although specific buses are described and shown in the embodiments of the application, any suitable buses or interconnects are contemplated by the application.
The service processing device may execute the service processing method in the embodiment of the present application based on the acquired interface definition of the SPI interface, the SDK for implementing the definition of the SPI interface, and the service identifier for identifying the SPI interface, thereby implementing the service processing method described in conjunction with fig. 1.
In addition, in combination with the service processing method in the foregoing embodiment, the embodiment of the present application may provide a computer-readable storage medium to implement. The computer readable storage medium having stored thereon computer program instructions; the computer program instructions, when executed by a processor, implement any of the service processing methods in the above embodiments.
The technical features of the above embodiments can be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the above embodiments are not described, but should be considered as the scope of the present specification as long as there is no contradiction between the combinations of the technical features.
The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the present application. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present patent shall be subject to the appended claims.

Claims (10)

1. A method for processing a service, the method comprising:
the service system acquires an interface definition of an SPI interface, an SDK for realizing the definition of the SPI interface and a service identifier for identifying the SPI interface from a service platform;
the service system realizes the service corresponding to the SPI interface according to the interface definition and the SDK, and packages the service corresponding to the SPI interface into an API interface;
and the service system exposes the API to the service platform according to the service identifier so that the service platform can call the API according to the service identifier.
2. The method of claim 1, wherein the business system exposing the API interface to the service platform according to the business identifier comprises:
and the service system exposes the API to the service platform on the dubbo according to the service identifier.
3. The method of claim 1, wherein the service system implements the service corresponding to the SPI interface according to the interface definition and the SDK, and encapsulating the service corresponding to the SPI interface into an API interface comprises:
the service system packages the service logic corresponding to the interface definition to obtain the service corresponding to the SPI interface;
and the service system issues the service corresponding to the SPI interface as an API interface through a dubbo.
4. The method of claim 2, wherein the service system exposing the API interface to the service platform on a dubbo according to the service identifier comprises:
and the business system exposes the API to the service platform in a dubbo annotation mode.
5. The method of claim 2, wherein before the service system obtains the interface definition of the SPI interface and the SDK for implementing the definition of the SPI interface from the service platform, the method further comprises:
the service platform acquires the user-defined requirement of the business system;
and the service platform generates the interface definition of the SPI interface and the SDK for realizing the definition of the SPI interface according to the user-defined requirement.
6. The method of claim 5, wherein after the service platform generates the interface definition of the SPI interface and the SDK for implementing the definition of the SPI interface according to the custom requirements, the method further comprises:
the service platform determines the service identifier corresponding to the SPI interface;
and the service platform allocates the service identifier to the service system so that the service system can acquire the interface definition and the SDK defined by the SPI interface according to the service identifier.
7. The method of claim 2, wherein after the service system exposes the API interface to the service platform on a dubbo according to the service identification, the method further comprises:
and the service platform discovers and calls the API through a dubbo according to the service identifier.
8. A service processing device applied to a service system is characterized in that the device comprises:
the acquisition module is used for acquiring an interface definition of an SPI (Serial peripheral interface), an SDK (software development kit) defined by the SPI and a service identifier for identifying the SPI from a service platform;
the realization module is used for realizing the service corresponding to the SPI interface according to the interface definition and the SDK and packaging the service corresponding to the SPI interface into an API interface;
and the exposure module is used for exposing the API interface to the service platform according to the service identifier so that the service platform can call the API interface according to the service identifier.
9. A transaction device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the method of any of claims 1 to 7 when executing the computer program.
10. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1 to 7.
CN201911271134.6A 2019-12-12 2019-12-12 Service processing method, device, equipment and computer readable storage medium Pending CN110955543A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911271134.6A CN110955543A (en) 2019-12-12 2019-12-12 Service processing method, device, equipment and computer readable storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911271134.6A CN110955543A (en) 2019-12-12 2019-12-12 Service processing method, device, equipment and computer readable storage medium

Publications (1)

Publication Number Publication Date
CN110955543A true CN110955543A (en) 2020-04-03

Family

ID=69981120

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911271134.6A Pending CN110955543A (en) 2019-12-12 2019-12-12 Service processing method, device, equipment and computer readable storage medium

Country Status (1)

Country Link
CN (1) CN110955543A (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112217738A (en) * 2020-11-04 2021-01-12 成都中科大旗软件股份有限公司 Flow control method, system, storage medium and terminal for text and travel data service
CN112380033A (en) * 2020-11-17 2021-02-19 北京百度网讯科技有限公司 Vehicle-mounted android operating system architecture, vehicle-mounted operating system calling method, electronic device and storage medium
CN112559095A (en) * 2020-12-16 2021-03-26 微医云(杭州)控股有限公司 Target service execution method, system, server and storage medium
CN112685020A (en) * 2020-12-24 2021-04-20 京东数字科技控股股份有限公司 Method and device for dynamically creating service interface, electronic equipment and storage medium
CN113795001A (en) * 2021-09-18 2021-12-14 上海中通吉网络技术有限公司 Method and device for sending system short message based on SPI
CN114090126A (en) * 2021-11-23 2022-02-25 浩云科技股份有限公司 Method and device for customizing system variable, terminal equipment and storage medium

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106651586A (en) * 2016-12-30 2017-05-10 上海富聪金融信息服务有限公司 Multi-distributor oriented financial product marketing open service platform
US20190057016A1 (en) * 2017-08-21 2019-02-21 Amadeus S.A.S. Multi-layer design response time calculator
CN109377348A (en) * 2018-09-27 2019-02-22 深圳市佰仟金融服务有限公司 Applied to the business interface call method for helping loan operation system and help loan operation system
WO2019104975A1 (en) * 2017-11-30 2019-06-06 平安科技(深圳)有限公司 Dubbo framework–based remote invoking method, server, and storage medium
CN110191164A (en) * 2019-05-20 2019-08-30 中国工商银行股份有限公司 Distributed Services access system and method
CN110381135A (en) * 2019-07-18 2019-10-25 北京奇艺世纪科技有限公司 Interface creation method, service request method, device, computer equipment and medium

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106651586A (en) * 2016-12-30 2017-05-10 上海富聪金融信息服务有限公司 Multi-distributor oriented financial product marketing open service platform
US20190057016A1 (en) * 2017-08-21 2019-02-21 Amadeus S.A.S. Multi-layer design response time calculator
WO2019104975A1 (en) * 2017-11-30 2019-06-06 平安科技(深圳)有限公司 Dubbo framework–based remote invoking method, server, and storage medium
CN109377348A (en) * 2018-09-27 2019-02-22 深圳市佰仟金融服务有限公司 Applied to the business interface call method for helping loan operation system and help loan operation system
CN110191164A (en) * 2019-05-20 2019-08-30 中国工商银行股份有限公司 Distributed Services access system and method
CN110381135A (en) * 2019-07-18 2019-10-25 北京奇艺世纪科技有限公司 Interface creation method, service request method, device, computer equipment and medium

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
MARSJHE: "由浅入深理解Dubbo的SPI机制", 《HTTPS://WWW.JIANSHU.COM/P/B5B6328A427B》 *
新栋BOOK: "如何设计一套SPI应用架构", 《HTTPS://BLOG.CSDN.NET/WANGXINDONG11/ARTICLE/DETAILS/103405344》 *
陈德人等编, 北京:高等教育出版社 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112217738A (en) * 2020-11-04 2021-01-12 成都中科大旗软件股份有限公司 Flow control method, system, storage medium and terminal for text and travel data service
CN112217738B (en) * 2020-11-04 2023-08-25 成都中科大旗软件股份有限公司 Flow control method, system, storage medium and terminal for travel data service
CN112380033A (en) * 2020-11-17 2021-02-19 北京百度网讯科技有限公司 Vehicle-mounted android operating system architecture, vehicle-mounted operating system calling method, electronic device and storage medium
CN112559095A (en) * 2020-12-16 2021-03-26 微医云(杭州)控股有限公司 Target service execution method, system, server and storage medium
CN112685020A (en) * 2020-12-24 2021-04-20 京东数字科技控股股份有限公司 Method and device for dynamically creating service interface, electronic equipment and storage medium
CN113795001A (en) * 2021-09-18 2021-12-14 上海中通吉网络技术有限公司 Method and device for sending system short message based on SPI
CN114090126A (en) * 2021-11-23 2022-02-25 浩云科技股份有限公司 Method and device for customizing system variable, terminal equipment and storage medium

Similar Documents

Publication Publication Date Title
CN110955543A (en) Service processing method, device, equipment and computer readable storage medium
CN110417766B (en) Protocol analysis method and device
CN108701017B (en) Method and device for updating operating system
CN110048879B (en) Microservice registration method, microservice registration device, electronic equipment and computer-readable storage medium
US20110125967A1 (en) Interface system between a terminal and a smart card, method for same, and smart card applied to same
CN101427228A (en) USB connection
US9172710B2 (en) Media transport protocol extensions for system integrity and robustness, and applications thereof
WO2010127514A1 (en) Value-added service smart card capable of carrying mobile communication smart card
WO2022267815A1 (en) Data packet filtering method and apparatus, and electronic device and computer-readable storage medium
CN110213250B (en) Data processing method and terminal equipment
CN105871539B (en) Key processing method and device
CN113626276B (en) Method, system, terminal and storage medium for identifying type of server HBA card
CN112631632B (en) System upgrade method, framework, electronic device and readable storage medium
WO2013016994A1 (en) Message sending method and system
CN108605222A (en) Method, the system for being used for transmission supplemental characteristic, telecommunication terminal equipment, computer program and the computer program product for being used for transmission supplemental characteristic for the configured transmission data between telecommunication network and telecommunication terminal equipment and for activating and/or changing and/or deactivate the communication configuration file for limiting or indicating by supplemental characteristic on telecommunication terminal equipment
CN108153564B (en) Interface management method, device and system and computer readable storage medium
CN114697440B (en) Network management method and mobile terminal
KR20090106103A (en) System and Method for Managing Smart Card Information
US8978050B2 (en) Program calling method, and mobile device
RU2613041C2 (en) Method of compressing messages, corresponding device and program
US10754661B1 (en) Network packet filtering in network layer of firmware network stack
JP5502051B2 (en) Method for processing step execution results in software application control managed objects
CN114237758B (en) Communication connection method, device, electronic equipment and computer readable storage medium
CN111736859B (en) Version updating method of operating system, server and terminal
CN114567902B (en) Real network test system of user identity module

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
RJ01 Rejection of invention patent application after publication

Application publication date: 20200403

RJ01 Rejection of invention patent application after publication