Intermediate service system and method for providing intermediate service

Abstract

The embodiment of the invention provides an intermediate service system. The system comprises a plurality of special service subsystems in one-to-one correspondence with a plurality of client types, and each special service subsystem adopts a server-free computing architecture and comprises a first hardware platform and special service logic configured on the first hardware platform in advance based on special requirements of the client of the corresponding type. Each special service subsystem responds to a received special service request sent by a first client of the corresponding type, special service logic is executed through computing resources dynamically scheduled in a first hardware platform, and adaptation processing is carried out on request data carried by the special service request according to the interface requirement of a back-end service system, so that the service quality of the back-end service system is improved. And calling a back-end service interface provided by the back-end service system based on the adapted request data, performing adaptation processing on response data returned by the back-end service interface according to an interface requirement of the first client, and sending the adapted response data to the first client.

Description

TECHNICAL FIELD

[0001] The present specification relates to the technical field of cloud computing, and particularly relates to an intermediate service system and a method for providing an intermediate service. BACKGROUND

[0002] With the development of technology, the forms of user-oriented clients are increasingly diverse. The clients not only include traditional WEB clients based on personal computers (PCs), but are further extended to various types of mobile clients. However, different types of clients have significant differences in hardware capabilities, screen sizes, operating system characteristics, user interaction modes, and the like. These differences result in obvious differentiation of page presentation and interaction logic of the clients. This makes developers need to provide and maintain different data interfaces for different types of client types when developing, which increases the development difficulty, and the data interfaces are often closely coupled with the display and interaction logic of the clients, and are difficult to flexibly adjust or implement reuse.

[0003] Therefore, it is necessary to provide a system capable of being compatible with multiple types of clients.

[0004] The content of the background section only represents the inventor's own knowledge and does not mean that the above information has entered the public domain before the filing date of the present disclosure, nor does it mean that it can be prior art of the present disclosure. SUMMARY

[0005] The present specification provides an intermediate service system and a method for providing an intermediate service. The intermediate service system deploys special service subsystems corresponding to different types of clients, executes special service logic, meets special requirements, and thus realizes the requirement of compatibility of multiple types of clients.

[0006] In a first aspect, the present specification provides an intermediate service system. The intermediate service system is deployed between a backend service system and multiple types of clients, comprising: a plurality of dedicated service subsystems corresponding to the multiple types of clients one by one, wherein each dedicated service subsystem adopts a serverless computing architecture and comprises: a first hardware platform, and a dedicated service logic pre-configured on the first hardware platform based on the specific needs of the corresponding type of client, each dedicated service subsystem is configured to: in response to receiving a dedicated service request sent by a first client of the corresponding type, execute the dedicated service logic using computing resources dynamically scheduled in the first hardware platform, to implement the following steps: adapt the request data carried by the dedicated service request according to the interface requirements of the backend service system, and call the backend service interface provided by the backend service system based on the adapted request data, and adapt the response data returned by the backend service interface according to the interface requirements of the first client, and send the adapted response data to the first client.

[0007] In some embodiments, the intermediate service system further comprises: at least one general service subsystem, wherein each general service subsystem adopts a serverless computing architecture, comprising: a second hardware platform, and a general service logic pre-configured on the second hardware platform based on the general needs of the multiple types of clients, each general service subsystem is configured to: in response to receiving a general service request sent by a second client of any type, execute the general service logic using computing resources dynamically scheduled in the second hardware platform, to implement the following steps: adapt the request data carried by the general service request according to the interface requirements of the backend service system, and call the backend service interface provided by the backend service system based on the adapted request data, and adapt the response data returned by the backend service interface according to the interface requirements of the second client, and send the adapted response data to the second client.

[0008] In some embodiments, the at least one general service subsystem comprises: a first general service subsystem adopting a Backend as a Service (BaaS) architecture; or a second general service subsystem adopting a Function as a Service (FaaS) architecture.

[0009] In some embodiments, the intermediate service system further comprises: a bottom layer service subsystem configured to provide a bottom layer service interface independent of the types of clients; each dedicated service subsystem selectively calls the bottom layer service interface to use the bottom layer service provided by the bottom layer service subsystem in the process of executing the dedicated service logic; each general service subsystem selectively calls the bottom layer service interface to use the bottom layer service provided by the bottom layer service subsystem in the process of executing the general service logic.

[0010] In some embodiments, the underlying service interface comprises at least one of: a thread management interface, a cache management interface, a database management interface.

[0011] In some embodiments, the underlying service subsystem adopts a Platform as a Service (PaaS) architecture.

[0012] In some embodiments, each dedicated service subsystem adopts a Backend as a Service (BaaS) architecture.

[0013] In the second aspect, the specification also provides a method for providing an intermediate service. The method is applied to an intermediate service system deployed between a backend service system and multiple types of clients, the intermediate service system comprising: multiple dedicated service subsystems corresponding to multiple client types one by one, each dedicated service subsystem adopting a serverless computing architecture and comprising a first hardware platform and dedicated service logic pre-configured on the first hardware platform based on the dedicated requirements of the corresponding type of client, the method comprising, in response to the dedicated service subsystem receiving a dedicated service request sent by a first client of the corresponding type, executing the dedicated service logic by using computing resources dynamically scheduled in the first hardware platform, to implement the following steps: adapting the request data carried by the dedicated service request according to the interface requirements of the backend service system, and calling the backend service interface provided by the backend service system based on the adapted request data, and adapting the response data returned by the backend service interface according to the interface requirements of the first client, and sending the adapted response data to the first client.

[0014] In some embodiments, the intermediate service system further comprises at least one general service subsystem, wherein each general service subsystem adopts a serverless computing architecture and comprises a second hardware platform and general service logic pre-configured on the second hardware platform based on the general requirements of the multiple types of clients, the method further comprising: in response to the general service subsystem receiving a general service request sent by a second client of any type, executing the general service logic by using computing resources dynamically scheduled in the second hardware platform, to implement the following steps: adapting the request data carried by the general service request according to the interface requirements of the backend service system, and calling the backend service interface provided by the backend service system based on the adapted request data, and adapting the response data returned by the backend service interface according to the interface requirements of the second client, and sending the adapted response data to the second client.

[0015] In some embodiments, the at least one general service subsystem comprises: a first general service subsystem adopting a Backend as a Service (BaaS) architecture; and / or a second general service subsystem adopting a Function as a Service (FaaS) architecture.

[0016] In some embodiments, the intermediate service system further comprises an underlying service subsystem providing an underlying service interface independent of client types, each dedicated service subsystem selectively invoking the underlying service interface in executing the dedicated service logic to use underlying services provided by the underlying service subsystem; each general service subsystem selectively invoking the underlying service interface in executing the general service logic to use underlying services provided by the underlying service subsystem.

[0017] In some embodiments, the underlying service interface comprises at least one of: a thread management interface, a cache management interface, or a database management interface.

[0018] In some embodiments, the underlying service subsystem adopts a Platform as a Service (PaaS) architecture.

[0019] In some embodiments, each dedicated service subsystem adopts a Backend as a Service (BaaS) architecture.

[0020] Other functions of the intermediate service system and the method of providing intermediate services provided by the present specification will be partially listed in the following description. The creative aspects of the intermediate service system and the method of providing intermediate services provided by the present specification can be fully explained by practicing or using the methods, devices and combinations described in the following detailed examples. BRIEF DESCRIPTION OF DRAWINGS

[0021] In order to more clearly illustrate the technical solutions in the embodiments of the present specification, the following will briefly introduce the drawings needed to be used in the embodiment description. Obviously, the drawings in the following description are only some embodiments of the present specification, and other drawings can also be obtained by those skilled in the art without creative labor based on these drawings.

[0022] Figure 1 A schematic diagram of an intermediate service system and its application scenario provided according to an embodiment of the present specification is shown; Figure 2 A schematic diagram of another intermediate service system and its application scenario provided according to an embodiment of the present specification is shown; Figure 3 A schematic diagram of still another intermediate service system and its application scenario provided according to an embodiment of the present specification is shown; Figure 4A schematic diagram showing still another intermediate service system and its application scenario provided according to an embodiment of the present specification is shown. Figure 5 A structural schematic diagram of a hardware device according to the present specification is shown; and Figure 6 A flowchart of a method for providing an intermediate service provided according to an embodiment of the present specification is shown. DETAILED DESCRIPTION

[0023] The following description provides specific application scenarios and requirements of the present specification, with the purpose of enabling a person skilled in the art to manufacture and use the content of the present specification. Various partial modifications of the disclosed embodiments are obvious to those skilled in the art, and the general principles defined herein can be applied to other embodiments and applications without departing from the spirit and scope of the present specification. Therefore, the present specification is not limited to the shown embodiments, but is consistent with the widest scope of the claims.

[0024] The terms used herein are only for the purpose of describing specific example embodiments, and are not limiting. For example, unless the context clearly indicates otherwise, as used herein, the singular forms "a", "an", and "the" can also include the plural forms. When used in the present specification, the terms "comprise", "contain" and / or "include" mean that the associated integers, steps, operations, elements and / or components exist, but do not exclude the presence of one or more other features, integers, steps, operations, elements, components and / or groups or that other features, integers, steps, operations, elements, components and / or groups can be added in the system / method.

[0025] In view of the following description, these features and other features of the present specification, as well as the operation and function of the related elements of the structure, and the economy of combination and manufacture of components can be obviously improved. Referring to the drawings, all of which form part of the present specification. However, it should be clearly understood that the drawings are for illustrative and descriptive purposes only and are not intended to limit the scope of the present specification. It should also be understood that the drawings are not drawn to scale.

[0026] The flowchart used in the present specification shows the operation of system implementation according to some embodiments of the present specification. It should be clearly understood that the operations of the flowchart can not be implemented in sequence. On the contrary, the operations can be implemented in reverse order or simultaneously. In addition, one or more other operations can be added to the flowchart. One or more operations can be removed from the flowchart.

[0027] Before the specific embodiments of the present specification are described, the application scenarios to which the technical solutions provided by the present specification are suitable are introduced.

[0028] With the development of technology, the forms of user-oriented service terminals / clients are increasingly diverse. The clients include not only traditional WEB clients based on personal computers (PCs), but also extend to various types of mobile clients.

[0029] However, different clients have significant differences in hardware capabilities, screen sizes, operating system features, user interaction modes, and the like. For example, the screen size of a mobile client is relatively small, and the information displayed is quite different from that of a traditional WEB client. For another example, a mobile client also has unique capabilities such as biometric login and near-field communication. These differences result in significant differences in page presentation and interaction logic of the clients. This makes developers need to provide and maintain different data interfaces for different client types when developing, which increases the development difficulty, and the interfaces are often closely coupled with the display and interaction logic of the clients, making it difficult to flexibly adjust or implement reuse.

[0030] Therefore, one or more embodiments of the present specification provide an intermediate service system deployed between various types of clients and a backend service system. The intermediate service system includes a plurality of dedicated service subsystems corresponding to different client types. The dedicated service subsystems execute dedicated service logic by responding to dedicated service requests of the corresponding types of clients, and call backend service interfaces provided by the backend service system, thereby supporting the operation of various types of clients and meeting the needs of compatibility of various types of clients.

[0031] Figure 1 A schematic diagram of an intermediate service system and its application scenario provided by an embodiment of the present specification is shown. As shown in Figure 1 The application scenario 100 includes a user 110, a client 120, an intermediate service system 130, and a backend service system 140. The intermediate service system 130 and the backend service system 140 can be collectively referred to as a service system.

[0032] The user 110 can be any person who interacts with the service system (such as the intermediate service system 130 and the backend service system 140) through the client 120.

[0033] The client 120 can be an entry for the user 110 to interact with the service system. The client 120 can be a terminal device, or a software program or application running on a terminal device. The client 120 can be responsible for providing an interaction interface to the user 110. The user 110 can operate on the client 120 (such as the interaction interface), and the client 120 can respond to the operation of the user 110, generate a corresponding request and send it to the service system, and receive the response (data) of the service system.

[0034] The terminal device can include a personal computer (PC), a mobile device (e.g., a mobile phone), a tablet computer, a notebook computer, a built-in device of a motor vehicle, or the like, or any combination thereof. In some embodiments, the smart home device can include a smart television, a desktop computer, or the like, or any combination thereof. In some embodiments, the smart mobile device can include a smartphone, a personal digital assistant, a gaming device, a navigation device, or the like, or any combination thereof. In some embodiments, the virtual reality device or the augmented reality device can include a virtual reality headset, a virtual reality glasses, a virtual reality patch, an augmented reality headset, an augmented reality glasses, an augmented reality patch, or the like, or any combination thereof. For example, the virtual reality device or the augmented reality device can include Google Glass, a head-mounted display, a VR, or the like. In some embodiments, the built-in device in a motor vehicle can include an on-board computer, an on-board television, or the like.

[0035] According to the interaction mode and architecture of the network system, the client 120 can be mainly divided into a mobile client and a web (WEB) client.

[0036] The mobile end mainly refers to an application program (APP) running on a mobile device, a tablet computer, or the like portable mobile device, and usually provides services in the form of an APP. The APP can provide the user 110 with the ability to interact with the outside world and an interface. The APP includes but is not limited to: a web browser type APP program, a search type APP program, a chat type APP program, a shopping type APP program, a video type APP program, an instant messaging tool, an email terminal device, a social platform software, and the like. The user 110 runs a target APP, completes various operations in the target APP, and realizes interaction with the service system. For example, the target APP is a shopping type APP program, and the user 110 can complete operations such as login, browsing goods, submitting an order, selecting a payment method, verification, and payment in the target APP. As an example, after the user 110 clicks on login, the client 120 can send a corresponding request to the service system and receive a response (data) of the service system.

[0037] In some embodiments, the mobile client can be further divided into an H5 mobile end and a native mobile end. The H5 mobile end refers to a web application developed based on HTML5 technology and accessed through a mobile device browser. The native mobile end refers to an application program developed based on a specific operating system using a native development language (such as Java / Kotlin, Objective-C / Swift). The native mobile end can further include an Android mobile end and an iOS mobile end.

[0038] WEB client mainly refers to a web-based application accessed through a browser, which can be used by the user 110 without installation and is applicable to PC, desktop computer and various browser-supported devices. The user 110 can access the target web application through the WEB client, complete various operations in the target web page, and realize interaction with the service system. For example, the target web application is a shopping platform, and the user 110 can complete operations such as login, browsing goods, submitting an order, selecting a payment method, verification, and payment in the target web application. As an example, when the user 110 clicks to submit an order, the client 120 can send a corresponding request to the service system and receive a response (data) of the service system.

[0039] In some embodiments, the client 120 can also be divided into a mobile client, a WEB client, a client running on a specific device (such as a smart TV APP, a transaction program on a cash register device), and the like. It is worth noting that the type of the client is not limited in the present description, and all clients that can access the service system / server are within the protection scope of the embodiments of the present description.

[0040] However, different types of clients have significant differences in hardware capabilities, screen sizes, operating system characteristics, user interaction methods, and the like. Taking the client including a mobile client and a WEB client as an example for illustration. For example, the interface layout and information presentation method are different. The WEB client usually runs on a large-screen device such as a PC or a notebook computer, and the mobile client usually runs on a small-screen device such as a mobile phone. Due to the difference in screen size, there are significant differences in information display between the two. The WEB client can display more content and complex layout at the same time, such as a multi-column data table, a detailed navigation menu, and a rich chart, while the mobile client needs to use a simple interface design, usually through paging, folding panels, or sliding switching to display information step by step, to ensure that the content is clear and the operation is convenient. For another example, the hardware capabilities and extended functions of the two are different. The mobile client can have hardware modules such as a fingerprint recognition module, a face recognition module, a positioning module, and a near field communication (NFC) module, thereby supporting extended functions such as biometric login, location authorization verification, and card reading. However, these functions often cannot be realized in the WEB client or have compatibility limitations.

[0041] Therefore, even in the same application scenario, mobile clients and WEB clients serve the same system functions, but there are still significant differences in the implementation. For example, taking the user 110 purchasing goods on a shopping platform as an example. The user 110 can complete login, browse goods, submit an order, select a payment method, and pay in the target web application (WEB client) or the target APP (mobile client). Among them, when logging into an account, the user 110 usually logs in through a username and password in the WEB client. In addition to the account password, the mobile client can call a face recognition module to perform biometric identification on the user 110. When browsing goods, the user 110 can see all the goods under the store in the WEB client. In the mobile client, the user 110 can only see part of the goods on the current page and needs to slide the page to browse all the goods. Therefore, different types of clients need to deploy different service logic to realize their specific functions.

[0042] In Figure 1 The service system includes an intermediate service system 130 and a backend service system 140. The two work together to realize the receiving, processing, and responding to the requests of the client 120.

[0043] The intermediate service system 130 is an intermediate layer between the client 120 and the backend service system 140 to realize the effective decoupling and cooperation between the client 120 and the backend service system 140. The intermediate service system 130 is mainly responsible for receiving the requests sent by the client 120, executing service logic, processing request data (such as parsing, parameter verification, format conversion, permission verification, etc.), backend service interface calling, and adapting the response format according to the client type, and the like.

[0044] In some embodiments, the intermediate service system 130 can be implemented through a Backends For Frontends (BFF) layer (system). As mentioned earlier, different types of clients 120 have different requirements for the format, content, and structure of interface data, and the like. The BFF layer can call different backend service interfaces according to the characteristics of different types of clients and return adapted response data for the client. For example, for mobile clients, the BFF can return a response with a compact structure and simple text and graphics; while for WEB clients, the BFF supports more fields and more complex data organization structures. The BFF layer can aggregate multiple backend interfaces into an interface that can be directly used by the client 120, reducing the number of requests of the client 120 and reducing the processing complexity. For example, in the process of loading a product detail page, the BFF layer can uniformly aggregate the inventory, price, promotion information, and other multi-interface return results and package them and return them to the client 120.

[0045] It can be seen that the BFF layer needs to provide different interfaces for different clients, and the design of these interfaces is closely related to the display and processing logic on different clients. In this case, the R&D and operation personnel of the BFF layer will be sandwiched between various modules to coordinate and make choices, which is inefficient for R&D.

[0046] In some embodiments, the BFF layer can adopt a Software as a Service (SaaS) system / architecture, or split the BFF layer into multiple independent SaaS systems. However, in this way, different types of clients often need independent BFF layers, and even if some BFF layers are lightweight, at least one server needs to be provided for running. In order to achieve high availability, load balancing and environment differences, with the increase of the types of clients, the actual resource consumption of the server will gradually increase, causing resource waste and increasing the service deployment and operation cost. At the same time, developers not only need to focus on the development of functions, but also need to invest in server expansion and contraction, as well as log management and other operation work, which increases the development burden and is not conducive to agile delivery.

[0047] Figure 2 Another intermediate service system and its application scenario provided by embodiments of the present specification are shown in the schematic diagram. In some embodiments, as shown in Figure 2 The intermediate service system 130 includes a plurality of dedicated service subsystems 131. The plurality of dedicated service subsystems 131 correspond one-to-one to a plurality of client 120 types. Each dedicated service subsystem 131 adopts a serverless computing architecture and includes a first hardware platform and a dedicated service logic pre-configured on the first hardware platform based on the specific needs of the corresponding type of client 120.

[0048] That is, different types of clients 120 correspond to different dedicated service subsystems 131. For example, Figure 2 The A-type client and the B-type client are shown. The intermediate service system 130 includes: a dedicated service subsystem 131 corresponding to the A-type client 120, and a dedicated service subsystem 131 corresponding to the B-type client 120. For example, the A-type client can be a WEB client, and the B-type client can be a mobile client.

[0049] Each dedicated service subsystem 131 adopts a serverless computing architecture. For example, each dedicated service subsystem 131 is implemented by a Serverless system. The serverless computing architecture does not mean “without servers”, but means that under this architecture, the cloud service provider is responsible for building and managing the hardware infrastructure platform such as physical servers, storage devices, network devices, etc., and allocates hardware resources to developers through virtualization technology. The developer of an application or webpage does not need to care about the deployment, management (scaling), operation and maintenance of the server, and only needs to focus on logical development. Therefore, the dedicated service subsystem 131 can include a first hardware platform provided by the cloud service provider, and a dedicated service logic such as a dedicated service instruction provided and configured by the developer on the first hardware platform. Moreover, the dedicated service subsystem 131 adopts a serverless computing architecture, which enables the dedicated service subsystem 131 to realize dynamic scheduling of computing resources. That is, the dedicated service subsystem 131 can automatically allocate computing resources according to real-time requests and service invocation conditions, realize elastic scaling and optimal allocation of resources, and developers do not need to care about the deployment, operation and release process of the underlying server, and computing resources can also be saved.

[0050] In embodiments of the present specification, a hardware platform (for example, the first hardware platform, or the second hardware platform mentioned later) can be a collective term for one or more hardware devices, that is, the hardware platform can include one or more hardware devices. The service logic (for example, the dedicated service logic, or the general service logic mentioned later) configured on the hardware platform can be a set of instructions.

[0051] In some embodiments, different dedicated service subsystems 131 can use different first hardware platforms. In some embodiments, the first hardware platform is a collective term for hardware platforms, and different dedicated service subsystems 131 can also use the same first hardware platform. For example, different dedicated service subsystems 131 use the same set of physical servers, etc.

[0052] The dedicated service logic is configured by the developer based on the specific needs of the corresponding type of client 120. That is, the dedicated service logic is not universal, but is a specific processing logic designed and implemented by the developer based on the differentiated characteristics (for example, different hardware) possessed by the corresponding type of client, such as calling different backend service interfaces. The specific needs of different types of clients 120 are different, and the dedicated service logic is also different.

[0053] For a mobile client, for example, in a shopping scenario, when the user 110 logs in the mobile client, in addition to the account password login, the mobile client needs to support the user 110 to log in through the biometric identification such as fingerprint identification or face recognition. The biometric identification is a special requirement of the mobile client, and the developer needs to configure a special service logic for calling the biometric identification to complete the login on the first hardware platform. For another example, in a ride scenario, the user 110 can use the near field communication (NFC) function of the mobile client to take a ride. The NFC function is a special requirement of the mobile client, and the developer needs to configure a special service logic for the NFC function on the first hardware platform.

[0054] For a WEB client, for example, in an enterprise contract management scenario, when the user 110 accesses the enterprise's contract management system through the WEB client, the user 110 needs to scan a paper contract file and upload it to the system. In order to adapt to the interactive implementation logic specific to the WEB browser, the WEB client needs to support the user 110 to upload the file through the drag-and-drop method (dragging the scanned file to the specified area). The drag-and-drop method for uploading the file is a special requirement of the WEB mobile client, and the developer needs to configure a special service logic for the uploading method on the first hardware platform. For another example, in a shopping scenario, the WEB client usually supports high-resolution product picture or video display, and the mobile client can only return a thumbnail connection. Returning a high-definition product picture is a special requirement of the WEB client, and the developer needs to configure a corresponding special service logic on the first hardware platform.

[0055] Each special service subsystem 131 is configured to: in response to receiving a special service request sent by a first client of a corresponding type, execute the special service logic by using the computing resources dynamically scheduled in the first hardware platform, and provide a special service.

[0056] As described above, the user 110 can operate on the first client. The first client can be a mobile client or a WEB client. The first client can generate a corresponding special service request based on the above operation and send it to the corresponding special service subsystem 131. As an example, when the first client is a mobile client, the user 110 logs in the first client and selects face recognition, the first client can generate a corresponding special service request (face recognition request). The special service request can be sent to the special service subsystem 131 corresponding to the mobile client. As an example, when the first client is a WEB client, the user 110 uploads a file on the first client, the first client can generate a corresponding special service request (drag-and-drop file upload). The special service request can be sent to the special service subsystem 131 corresponding to the WEB client.

[0057] As mentioned above, the dedicated service subsystem 131 is capable of implementing dynamic scheduling of computing resources. Therefore, the dedicated service subsystem 131 can execute the dedicated service logic, e.g., execute the corresponding instruction set, provide the intermediate service, using the dynamically scheduled computing resources in the first hardware platform, without the developer's attention to the computing resources. The method by which the dedicated service subsystem specifically provides the intermediate service will be described later.

[0058] By deploying the corresponding dedicated service subsystem 131 for different types of clients 120, the running of multiple types of clients 120 is supported, and the needs of multiple types of clients 120 are met. Moreover, the dedicated service subsystem 131 corresponding to different types of clients 120 can be independently designed, developed and maintained, reducing the dependence of research and development. Further, by using the serverless computing architecture, the developer only needs to focus on the development and construction of the system function itself, and no longer needs to pay attention to the operation and maintenance of the system server, greatly improving the research and development efficiency. Moreover, since the dedicated service subsystem 131 adopts the serverless computing architecture, it has the characteristics of computing elasticity, which can effectively save computing resources and system service deployment and operation and maintenance costs.

[0059] In some embodiments, each dedicated service subsystem 131 adopts a Backend as a Service (BaaS) architecture. Different types of clients 120 correspond to different BaaS architectures. BaaS is a cloud service model that provides application developers with ready-to-use backend service components, such as identity verification, database, file storage, message push, cloud function, etc. The developer does not need to build and maintain servers or databases, but only needs to call the required services through an interface.

[0060] Figure 3 A schematic diagram of yet another intermediate service system and its application scenario provided according to an embodiment of the present specification is shown. In some embodiments, as shown in Figure 3 The intermediate service system 130 can also include at least one general service subsystem 132. Each general service subsystem 132 adopts a serverless computing architecture. The general service subsystem 132 includes a second hardware platform and general service logic pre-configured on the second hardware platform based on the general needs of multiple types of clients.

[0061] That is, the intermediate service system 130 can include one or more general service subsystems 132. Different types of clients 120 can share the at least one general service subsystem 132. For example, Figure 3 One general service subsystem 132 is shown, which can be interacted with by A-type clients and B-type clients, and provides general services for them.

[0062] Each general service subsystem 132 also adopts a serverless computing architecture. For example, each general service subsystem 132 is implemented by a serverless system. Similar to the dedicated service subsystem 131, the general service subsystem 132 can also automatically allocate computing resources according to real-time requests, invocation of services, and achieve elastic scaling and optimal allocation of resources, without the developer needing to care about the deployment, operation and release process of the underlying servers. Details can refer to the dedicated service subsystem 131, which will not be described here.

[0063] The second hardware platform can also be provided by a cloud service provider. In some embodiments, different general service subsystems 132 can use different second hardware platforms. In some embodiments, the second hardware platform is a general term for hardware platforms, and different general service subsystems 132 can also use the same second hardware platform. For example, different general service subsystems 132 use the same set of physical servers, etc.

[0064] The general service logic is configured by the developer based on the general needs of multiple or all types of clients 120. That is, the general service logic is independent of the type of client, reusable and common between multiple types or all clients, and provides basic or general processing logic. Whether the client is a mobile client or a WEB client, the general service subsystem 132 can be used to process the general needs of the user 110.

[0065] For example, in a shopping scenario, the user 110 selects a good and places an order (submits an order) after selecting the good. Submitting an order is one of the most basic operations in a shopping system. Therefore, submitting an order usually belongs to general needs. Whether it is a mobile client or a WEB client, the corresponding general service logic needs to be deployed. Then, different types of clients 120 can share one general service subsystem 132. The developer can configure the general service logic for submitting an order on the second hardware platform. Whether it is a mobile client or a WEB client, the same service interface can be called to complete the submission of the order. For another example, in a good after-sales scenario, the user 110 needs to upload a picture of the good to the system to facilitate the merchant to audit the status of the good and perform corresponding after-sales operations. Therefore, uploading a picture usually belongs to general needs. Whether it is a mobile client or a WEB client, the corresponding general service logic needs to be deployed. The developer can configure the general service logic for uploading a picture on the second hardware platform.

[0066] In some embodiments, the intermediate service system 130 can include multiple general service subsystems 132. The multiple general service subsystems 132 are responsible for providing different general services. For example, one general service subsystem 132 is responsible for providing a service for submitting an order, and another general service subsystem 132 is responsible for providing a service for uploading a file.

[0067] Each general service subsystem 132 is configured to, in response to receiving a general service request sent by any type of second client, execute general service logic with computing resources dynamically scheduled in the second hardware platform to provide a general service.

[0068] Here, the second client is any type of client. For example, the second client can be a mobile client or a WEB client.

[0069] The user 110 can operate at a second client. The second client can generate and send a corresponding general service request to the general service subsystem 132 based on the operation. As an example, in a shopping scenario, when the user 110 selects goods and submits an order, the second client can generate a corresponding general service request (submitting an order). The general service request can be sent to the general service subsystem 132.

[0070] As described above, the general service subsystem 132 can dynamically schedule computing resources. Therefore, the general service subsystem 132 can execute general service logic with computing resources dynamically scheduled in the second hardware platform to provide an intermediate service without the developer's concern for computing resources. The method by which the general service subsystem 132 specifically provides the intermediate service will be described later.

[0071] In some embodiments, the at least one general service subsystem 132 includes a first general service subsystem that adopts a Backend as a Service (BaaS) architecture. As described above, BaaS can provide a complete set of backend functions for developers, and developers do not need to build and maintain backend servers, databases, and other infrastructure themselves, but can directly call these services to build a system.

[0072] In some embodiments, the at least one general service subsystem 132 can include a second general service subsystem that adopts a Function as a Service (FaaS) architecture. The FaaS architecture is a cloud computing service mode, and the FaaS architecture allows developers to deploy and run individual functions (functional modules) without having to manage servers themselves. Developers only need to write functions corresponding to services, and the system will automatically complete deployment, scaling, resource management, on-demand invocation, and pay-per-use billing. That is, when the user 110 triggers a corresponding service or demand, the function automatically runs and releases the corresponding computing resources after running.

[0073] The middleware service system 130 can include both a first general-purpose service subsystem and a second general-purpose service subsystem. The main difference between the first and second general-purpose service subsystems is that the BaaS architecture provides standardized backend capabilities, allowing developers to directly call existing backend services; the FaaS architecture focuses on executing developer-defined function logic on demand, suitable for implementing specific requirements. Using both in combination can achieve a highly efficient, low-maintenance, and scalable system architecture.

[0074] As an example, in a shopping scenario, developers can leverage the services provided by the BaaS architecture / platform, such as order submission and message push, to complete the functions of order creation and message push, while implementing functions such as file upload and promotion calculation through the FaaS architecture.

[0075] By deploying the general service subsystem 132, various types of clients 120 can share or reuse the general service subsystem 132, avoiding redundant development. Furthermore, deploying the general service subsystem 132 facilitates unified maintenance and modification of general services for different types of clients 120, enhances system independence, and makes it easier for developers to develop and extend functionality. Moreover, since the general service subsystem 132 adopts a serverless architecture, it possesses the characteristics of elastic computing scalability, effectively saving computing resources and system service deployment and maintenance costs.

[0076] In some embodiments, such as Figure 3 As shown, the intermediate service system 130 may also include a lower-level service subsystem 133. The lower-level service subsystem 133 is configured to provide a lower-level service interface independent of the client 120 type. In other words, by providing a unified lower-level service interface, the lower-level service subsystem 133 enables different types of clients 120 to access the lower-level services in the same way. This allows the developers of the intermediate service system 130 to develop and maintain only one set of lower-level service interfaces, without having to develop different interfaces or adaptation logic for each client 120, greatly simplifying development work and improving the maintainability and scalability of the system.

[0077] As an example, in a shopping scenario, the underlying service subsystem 133 provides a unified interface for product query and inventory management. When user 110 views product details through a browser (web client), the unified product query interface is called to obtain product information and inventory status. When user 110 browses products in a mobile app (mobile client), the same interface is called to display the latest product and inventory data. In other words, regardless of the type of client 120 accessing the system, the underlying service subsystem 133 provides real-time and accurate product and inventory information to client 120 through a consistent interface, ensuring data synchronization and consistent user experience.

[0078] In some embodiments, each dedicated service subsystem 131 can selectively invoke the underlying service interface to use the underlying services provided by the underlying service subsystem 133 in the process of executing the dedicated service logic. Similarly, each general service subsystem 132 can selectively invoke the underlying service interface to use the underlying services provided by the underlying service subsystem 133 in the process of executing the general service logic.

[0079] That is, the dedicated service subsystem 131 and the general service subsystem 132 can invoke the underlying service interface provided by the underlying service subsystem 133 as needed in the process of executing the service logic responsible for them, so as to complete the request by using the resources and capabilities of the underlying service subsystem 133. In other words, the dedicated service subsystem 131 and the general service subsystem 132 are request-oriented service layers, which can implement higher-level service logic by invoking the underlying or basic functions provided by the underlying service subsystem 133.

[0080] The dedicated service subsystem 131 and the general service subsystem 132 can selectively invoke the underlying service interface according to actual needs. For example, the dedicated service subsystem 131 may

[0081] In some embodiments, the underlying service interface can include at least one of a thread management interface, a cache management interface, and a database management interface. The thread management interface provides functions of creating, scheduling and managing threads in a program. The cache management interface provides capabilities of accessing, updating and clearing cache data. The database management interface provides capabilities of connecting to a database, executing Structured Query Language (SQL) statements, and querying and updating data.

[0082] As an example, when the underlying service interface includes a database management interface, the general service subsystem (BaaS) 132 implements the order creation function, and invokes the database management interface to implement the query of commodity inventory, write order information into the database, update the commodity inventory quantity, and the like.

[0083] In some embodiments, the underlying service subsystem 133 adopts a Platform as a Service (PaaS) architecture. The PaaS architecture is also a cloud computing service model, which provides developers with platforms and tools needed to build, deploy, run and manage applications, without worrying about the underlying infrastructure (such as servers, storage, network, etc.).

[0084] In some embodiments, the underlying service subsystem 133 can also invoke the backend service interfaces provided by the backend service system 140.

[0085] By deploying the underlying service subsystem 133, a stable and scalable running environment is provided for the general service subsystem 132 and the special service subsystem 131, reducing the operation and maintenance cost and complexity of the two.

[0086] The backend service system 140 can refer to a service component running on the server side in the entire system, responsible for processing service logic, managing data resources, and interacting with databases or other systems. The backend service system 140 can provide a backend service interface for the intermediate service system to invoke to achieve distributed collaboration.

[0087] For example, the backend service interface can include a biometric interface. The biometric interface provides the ability to collect, verify, and manage user biometric features, supports the uploading and identity verification of biometric data. The special service subsystem 131 corresponding to the mobile client 120 can invoke the biometric interface when the user logs in and verifies. For another example, the backend service interface can include an order creation interface. The order creation interface supports user submission of order requests, entry, verification, and generation of order information, ensures order validity and triggers subsequent processes. The general service subsystem 132 of the client 120 can invoke the interface when the user creates an order. For another example, the backend service interface can include a file upload interface. The file upload interface provides file upload, storage, and management services, and supports the reception of files in multiple formats. The general service subsystem 132 of the client 120 can invoke the interface when the user uploads a file.

[0088] In some embodiments, different backend service interfaces have different interface requirements. The request data passed by different types of clients 120 can be different, and the specifications of different backend service interfaces can be different.

[0089] The intermediate service system 130 needs to perform adaptation processing on the request data, so that the processed request data meets the specifications of the backend service interface, such as the request data format and field, type, etc., to ensure that the backend service interface can correctly identify the request.

[0090] In some embodiments, different backend service interfaces have different interface return forms. After the intermediate service system 130 invokes the backend service interface, the response data structure returned by the backend service interface is different. For example, some backend service interfaces return JSON format data after processing the request, and some backend service interfaces return XML format data after processing the request, etc.

[0091] The intermediate service system 130 needs to convert the response data returned by different backend service interfaces into response data in a form suitable for the corresponding client 120, so as to ensure that the client 120 can correctly identify and efficiently process the corresponding response data, and improve the response speed and user experience. The intermediate service system 130 performs bidirectional adaptation of data between the client 120 and the backend service system 140.

[0092] As an example, Figure 4 A schematic diagram of still another intermediate service system and an application scenario thereof provided by an embodiment of the present specification is shown. As Figure 4 shown, the special service subsystem adopts a BaaS architecture, and the general service subsystem includes a general service subsystem adopting a BaaS architecture and a general service subsystem adopting a FaaS architecture.

[0093] As Figure 4 shown, when the user 110 uses an A-type client, the A-type client can call an A-type-special service subsystem (A-type BaaS) 131, a general service subsystem (general BaaS) 132, and a general service subsystem (general FaaS) 132. The A-type BaaS, the general BaaS, and the general FaaS can selectively call an underlying service subsystem (underlying PaaS) 133 and a backend service system 140.

[0094] When the user 110 uses a B-type client, the B-type client can call a B-type-special service subsystem (B-type BaaS) 131, a general BaaS, and a general FaaS. The B-type BaaS, the general BaaS, and the general FaaS can selectively call the underlying PaaS and the backend service system 140.

[0095] It should be understood that Figures 1-4 the number of users 110, clients 120, special service subsystems 131, general service subsystems 132, and underlying service subsystems 133 in the intermediate service system 130 in the present specification is only illustrative. According to the implementation needs, the user 110, the client 120, the system / subsystem can have any number of

[0096] Figure 5 A structural schematic diagram of a hardware device 500 according to an embodiment of the present specification is shown. The first hardware platform and the second hardware platform can have the structure of the hardware device 500 as Figure 5 shown (or in other words, the first hardware platform can include one or more hardware devices 500 as Figure 5 shown). The backend service system can also have the structure of the hardware device 500 as Figure 5 shown (or in other words, the backend service system can include one or more hardware devices 500 as Figure 5The illustrated hardware device 500.

[0097] As Figure 5 illustrated, the hardware device 500 includes at least one storage medium 530 and at least one processor 520. In some embodiments, the hardware device 500 can also include a communication port 550 and an internal communication bus 510. Also, the hardware device 500 can also include an I / O component 560.

[0098] The internal communication bus 510 can connect different system components, including the storage medium 530 and the processor 520. The I / O component 560 supports input / output between the hardware device 500 and other components.

[0099] The storage medium 530 can include a data storage. The data storage can be a non-transitory storage medium or a transitory storage medium. For example, the data storage can include one or more of a disk 532, a read-only memory (ROM) 534, or a random access memory (RAM) 536. The storage medium 530 also includes at least one instruction set stored in the data storage. The instruction set is computer program code that can include programs, routines, objects, components, data structures, procedures, modules, and the like that perform the methods illustrated in this specification to provide intermediate services.

[0100] The communication port 550 is used for data communication between the hardware device 500 and the outside world. For example, the hardware device 500 can connect to a network through the communication port 550. The at least one processor 520 and the at least one storage medium 530 are communicatively connected through the internal communication bus 510. The at least one processor 520 is used to execute the at least one instruction set described above. When the hardware device 500 is running, the at least one processor 520 reads the at least one instruction set and executes the methods illustrated in this specification to provide intermediate services according to the instructions of the at least one instruction set.

[0101] The processor 520 can perform all steps of the method of providing intermediate services. The processor 520 can be in the form of one or more processors. The processor 520 can issue execution instructions. The processor 520 can include one or more hardware processors, such as a microcontroller, a microprocessor, a reduced instruction set computer (RISC), an application-specific integrated circuit (ASIC), an application-specific instruction set processor (ASIP), a central processing unit (CPU), a graphics processing unit (GPU), a physical processing unit (PPU), a microcontroller unit, a digital signal processor (DSP), a field programmable gate array (FPGA), an advanced RISC machine (ARM), a programmable logic device (PLD), any circuit or processor capable of executing one or more functions, or any combination thereof.

[0102] For the sake of illustration only, only one processor 520 is described in the hardware device 500 in the present specification. However, it should be noted that the hardware device 500 can also include multiple processors in the present specification, and thus the operations and / or method steps disclosed in the present specification can be performed by one processor as described in the present specification, or jointly performed by multiple processors. For example, if the processor 520 of the hardware device 500 performs step A and step B in the present specification, it should be understood that step A and step B can also be performed jointly or separately by two different processors 520 (for example, a first processor performs step A, and a second processor performs step B, or the first and second processors jointly perform steps A and B).

[0103] Figure 6 A flowchart of a method P600 of providing an intermediate service is shown, according to an embodiment of the present specification. The method P600 of providing an intermediate service can be performed by an intermediate service system. As shown, the method P600 includes S610. Figure 6

[0104] S610: In response to a dedicated service subsystem receiving a dedicated service request sent by a first client of a corresponding type, executing the dedicated service logic with a computing resource dynamically scheduled in the first hardware platform, to implement steps S610-1 to S610-2.

[0105] As previously described, a user can trigger a dedicated service request at a first client. The dedicated service request can be sent to a corresponding dedicated service subsystem. The dedicated service subsystem adopting a serverless computing architecture can dynamically schedule a computing resource in the first hardware platform, execute the dedicated service logic (e.g., instruction set), to implement the following steps S610-1 to S610-2.

[0106] S610-1: According to the interface requirements of the backend service system, performing adaptation processing on the request data carried by the dedicated service request, and calling the backend service interface provided by the backend service system based on the adapted request data.

[0107] As previously described, the dedicated service subsystem can process the corresponding request data, so that the request data is adapted to the interface requirements of the backend service system. For example, the dedicated service subsystem converts and adjusts the structure, name, type, etc. of the request data, so as to conform to the interface requirements of the backend service system.

[0108] The dedicated service subsystem can call the backend service interface based on the adapted request data, so as to use the service capabilities provided by the backend service system.

[0109] ​S610-2: Adapt the response data returned by the backend service interface according to the interface requirement of the first client, and send the adapted response data to the first client.

[0110] As mentioned above, the structure of the response data returned by the backend service interface is different. The special service subsystem needs to process the returned response data so that the response data is adapted to the interface requirement of the first client, ensuring that the first client can correctly identify and efficiently process the corresponding response data, improving the response speed and user experience.

[0111] By deploying a special service subsystem between the client and the backend service system, and realizing the bidirectional adaptation between the client and the backend service system through the special service subsystem, the intermediate service system can meet the needs of compatibility of multiple types of clients. Moreover, the special service subsystem can dynamically schedule computing resources during operation, which can save computing resources on the one hand, and enable developers to not need to focus on the management and maintenance of computing resources on the other hand.

[0112] As mentioned above, the intermediate service subsystem can also include a general service subsystem. Therefore, in some embodiments, as shown in Figure 5 The method P600 can also include the following steps: S620: In response to the general service subsystem receiving a general service request sent by any type of second client, executing the general service logic by using the computing resources dynamically scheduled in the second hardware platform to realize steps S620-1 to S620-2.

[0113] As mentioned above, the user can trigger a general service request at the second client. The general service request can be sent to the general service subsystem. The general service subsystem adopting a serverless computing architecture can dynamically schedule computing resources in the second hardware platform to execute the general service logic (such as instruction set) to realize the following steps S620-1 to S620-2.

[0114] S620-1: Adapt the request data carried by the general service request according to the interface requirement of the backend service system, and call the backend service interface provided by the backend service system based on the adapted request data.

[0115] The specific content can refer to the special service request, and this specification will not be repeated here.

[0116] S620-2: Adapt the response data returned by the backend service interface according to the interface requirement of the first client, and send the adapted response data to the first client.

[0117] The specific content can refer to the dedicated service request, and the specification will not be repeated here.

[0118] In summary, the specification provides an intermediate service system deployed between a client and a backend service system. The intermediate service system includes a plurality of dedicated service subsystems corresponding to different client types. The dedicated service subsystems execute dedicated service logic by responding to dedicated service requests of corresponding types of clients and calling backend service interfaces provided by the backend service system, thereby supporting the operation of multiple types of clients and meeting the needs of multiple types of client compatibility. Further, since the dedicated service subsystems adopt a serverless architecture, the dedicated service subsystems can dynamically call computing resources, thereby effectively saving computing resources and system service deployment and operation and maintenance costs. Further, the intermediate service system also includes a general service subsystem, thereby enabling multiple types of clients to share or reuse the general service subsystem, avoiding repeated development. Moreover, deploying the general service subsystem facilitates unified maintenance and modification of the general services of different types of clients, and can enhance the independence of the system, facilitating developers to develop and expand functions. Furthermore, the general service subsystem also adopts a serverless architecture, which can effectively save computing resources and system service deployment and operation and maintenance costs.

[0119] Another aspect of the present specification provides a non-transitory storage medium storing at least one set of executable instructions providing a method of intermediate service. When the executable instructions are executed by a processor, the executable instructions direct the processor to implement the steps of the method P600 described in the present specification. In some possible implementation, various aspects of the present specification can also be implemented as a program product in the form of a computer readable medium embodying program code. When the program product is run on an intermediate service system, the program code is used to cause the intermediate service system to perform the steps of the method P600 described in the present specification. The program product for implementing the above method can include program code in a portable compact disc read-only memory (CD-ROM) and can be run on the intermediate service system. However, the program product of the present specification is not limited to this, and in the present specification, the readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system. The program product can take any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium may, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or apparatus, or any suitable combination of the above. More specific examples of the readable storage medium include an electrical connection having one or more wires, a portable disc, 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 above. The computer readable storage medium can include a data signal propagating in a baseband or as a carrier wave in a propagated signal, in which the readable program code is carried. Such a propagated data signal can take various forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The readable storage medium can also be any readable medium that is not a storage medium and that can send, propagate or transmit the program for use by or in connection with an instruction execution system, apparatus or device. The program code contained on the readable storage medium can be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination of the above. The program code for performing the operations of the present specification can be written in any combination of one or more programming languages, including an object-oriented programming language such as Java, C++, etc., and a conventional procedural programming language such as the "C" language or a similar programming language. The program code can be executed entirely on the intermediate service system, partially on the intermediate service system, as an independent software package, partially on the intermediate service system and partially on a remote computing device, or entirely on a remote computing device.

[0120] The above described embodiments of the disclosure have been described. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order and still accomplish desirable results. Additionally, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order to achieve desirable results. In certain implementations, multitasking and parallel processing can be advantageous.

[0121] In light of the above, those skilled in the art will appreciate that the foregoing detailed description of the present disclosure is susceptible to various modifications and / or revisions without departing from the spirit and scope of the present disclosure. Although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement which is calculated to achieve the same purpose can be substituted for the specific embodiments shown. This disclosure is intended to cover any adaptations or variations of the present disclosure. Therefore, it is intended that the application be protected by: the broadest interpretation of the appended claims to take into account unforeseen equivalents and alternatives based on current knowledge, or future knowledge.

[0122] In addition, certain terminology has been used to describe embodiments of the disclosure. For example, "one embodiment," "an embodiment," and / or "some embodiments” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosure. Therefore, it is understood that the use of "embodiment" or "one embodiment" or "an embodiment" or "some embodiments” in various places throughout this specification are not necessarily referring to the same embodiment. Furthermore, the particular features, structures, or characteristics can be combined in any suitable manner on one or more embodiments without limitation.

[0123] It should be understood that in the foregoing description of embodiments of the disclosure, various features are sometimes grouped together in a single embodiment, figure, or description of a figure for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various aspects, embodiments, and / or features. However, this should not be interpreted as a requirement that these features must be provided together in order to form an embodiment of the disclosure. In fact, some embodiments of the disclosure can provide only a subset of these features. In addition, streams of features from different embodiments can be combined to provide an embodiment of the disclosure. In some cases, features from one embodiment can be combined with features from another embodiment to provide an embodiment of the disclosure. In some cases, features from one embodiment can be combined with features from another embodiment to provide an embodiment of the disclosure.

[0124] Each patent, patent application, publication of a patent application, and other material, for example articles, books, specifications, publications, documents, things, and / or the like which can have been cited or referred to in this document, are incorporated by reference into the present document, and are hereby made part of the present document, for all purposes, to the same extent as if each individual publication or item had been individually cited or incorporated by reference. Additionally, where a definition or use of a term in an incorporated reference is inconsistent or contrary to the definition or use of that term in the present document, the definition or use that appears in the present document applies and the opposite definition or use does not apply.

[0125] Finally, it should be understood that the embodiments of the application disclosed herein are illustrative of the principles of the present specification. Other modifications that fall within the scope of the present specification can also be made. Accordingly, the present specification discloses embodiments only as examples. Substantially any arrangement, which is neither specifically described nor explicitly illustrated, can be substituted for the specific embodiments disclosed, without departing from the scope of the present specification. Accordingly, the present specification discloses embodiments only as examples.

Claims

1. An intermediate service system deployed between a backend service system and multiple types of clients, comprising: a plurality of dedicated service subsystems corresponding to the multiple types of clients one-to-one, wherein each dedicated service subsystem adopts a serverless computing architecture and comprises: a first hardware platform, and a dedicated service logic pre-configured on the first hardware platform based on specific requirements of a corresponding type of client, each dedicated service subsystem is configured to, in response to receiving a dedicated service request sent by a first client of the corresponding type, execute the dedicated service logic by using computing resources dynamically scheduled in the first hardware platform, to implement the following steps: adapt a request data carried by the dedicated service request according to interface requirements of the backend service system, and invoke a backend service interface provided by the backend service system based on the adapted request data, and adapt a response data returned by the backend service interface according to interface requirements of the first client, and send the adapted response data to the first client.

2. The system of claim 1, wherein, The intermediate service system further comprises: at least one general service subsystem, wherein each general service subsystem adopts a serverless computing architecture and comprises: a second hardware platform, and a general service logic pre-configured on the second hardware platform based on general requirements of the multiple types of clients, each general service subsystem is configured to, in response to receiving a general service request sent by a second client of any type, execute the general service logic by using computing resources dynamically scheduled in the second hardware platform, to implement the following steps: adapt a request data carried by the general service request according to interface requirements of the backend service system, and invoke a backend service interface provided by the backend service system based on the adapted request data, and adapt a response data returned by the backend service interface according to interface requirements of the second client, and send the adapted response data to the second client.

3. The system of claim 2, wherein, The at least one general service subsystem comprises: a first general service subsystem adopting a Backend as a Service (BaaS) architecture; and / or a second general service subsystem adopting a Function as a Service (FaaS) architecture.

4. The system of claim 2, wherein, The intermediate service system further comprises: an underlying service subsystem configured to provide an underlying service interface independent of client types; each dedicated service subsystem selectively invokes the underlying service interface to use an underlying service provided by the underlying service subsystem in the process of executing the dedicated service logic; each general service subsystem selectively invokes the underlying service interface to use an underlying service provided by the underlying service subsystem in the process of executing the general service logic.

5. The system of claim 4, wherein, The underlying service interface comprises at least one of: a thread management interface, a cache management interface, or a database management interface.

6. The system of claim 4, wherein, The underlying service subsystem adopts a Platform as a Service (PaaS) architecture.

7. The system of claim 1, wherein, Each dedicated service subsystem adopts a Backend as a Service (BaaS) architecture.

8. A method of providing intermediary services, applied to an intermediary service system deployed between a backend service system and a plurality of types of clients, the intermediary service system comprising: The method comprises: In response to the dedicated service subsystem receiving a dedicated service request sent by a first client of the corresponding type, executing the dedicated service logic by using a computing resource dynamically scheduled in the first hardware platform to implement the following steps: According to the interface requirements of the backend service system, the request data carried by the dedicated service request is adapted and processed, and the backend service interface provided by the backend service system is called based on the adapted request data, and According to the interface requirements of the first client, the response data returned by the backend service interface is adapted and processed, and the adapted response data is sent to the first client.

9. The method of claim 8, wherein, The intermediate service system further comprises at least one general service subsystem, wherein each general service subsystem adopts a serverless computing architecture and comprises: a second hardware platform, and general service logic pre-configured on the second hardware platform based on general requirements of multiple types of clients, and the method further comprises: In response to the general service subsystem receiving a general service request sent by a second client of any type, executing the general service logic by using a computing resource dynamically scheduled in the second hardware platform to implement the following steps: According to the interface requirements of the backend service system, the request data carried by the general service request is adapted and processed, and the backend service interface provided by the backend service system is called based on the adapted request data, and According to the interface requirements of the second client, the response data returned by the backend service interface is adapted and processed, and the adapted response data is sent to the second client.

10. The method of claim 9, wherein, The at least one general service subsystem comprises: A first general service subsystem adopting a Backend as a Service (BaaS) architecture; and / or A second general service subsystem adopting a Function as a Service (FaaS) architecture.

11. The method of claim 9, wherein, The intermediate service system further comprises a bottom service subsystem providing a bottom service interface irrelevant to the type of the client, Each dedicated service subsystem selectively calls the bottom service interface to use the bottom service provided by the bottom service subsystem in the process of executing the dedicated service logic; Each general service subsystem selectively calls the bottom service interface to use the bottom service provided by the bottom service subsystem in the process of executing the general service logic.

12. The method of claim 11, wherein, The bottom service interface comprises at least one of a thread management interface, a cache management interface, or a database management interface.

13. The method of claim 11, wherein, The bottom service subsystem adopts a Platform as a Service (PaaS) architecture.

14. The method of claim 8, wherein, Each dedicated service subsystem adopts a Backend as a Service (BaaS) architecture.

Images