Intermediary service system and method for providing an intermediary service

Abstract

The embodiment of the present specification provides an intermediate service system. The system comprises a plurality of dedicated service subsystems corresponding to a plurality of client types one by one, 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, and each dedicated service subsystem, in response to receiving a dedicated service request sent by a first client of the corresponding type, executes the dedicated service logic by using the computing resources dynamically scheduled in the first hardware platform, implements the adaptation processing of the request data carried by the dedicated service request according to the interface requirements of the back-end service system, calls the back-end service interface provided by the back-end service system based on the adapted request data, and implements the adaptation processing of the response data returned by the back-end service interface according to the interface requirements of the first client, and sends the adapted response data to the first client.

Description

Technical Field

[0001] This specification relates to the field of cloud computing technology, and in particular to an intermediate service system and a method for providing intermediate services. Background Technology

[0002] With technological advancements, user-facing client applications are becoming increasingly diverse. Clients now extend beyond traditional PC-based web clients to various types of mobile clients. However, different types of clients differ significantly in hardware capabilities, screen size, operating system characteristics, user interaction methods, and so on. These differences lead to marked variations in client page presentation and interaction logic. This necessitates developers providing and maintaining different data interfaces for different client types, increasing development complexity. Furthermore, these data interfaces are often tightly coupled with the client's display and interaction logic, making them difficult to adjust flexibly or reuse.

[0003] Therefore, there is a need to provide a system that is compatible with multiple types of clients.

[0004] The information in the background section is merely information known only to the inventor and does not imply that such information had entered the public domain before the date of this application, nor does it imply that it can be considered prior art in this disclosure. Summary of the Invention

[0005] This specification provides an intermediate service system and a method for providing intermediate services. The intermediate service system deploys dedicated service subsystems corresponding to different types of clients, executes dedicated service logic, and meets specific needs, thereby achieving compatibility with multiple types of clients.

[0006] Firstly, this specification provides an intermediate service system. The intermediate service system is deployed between a backend service system and various types of clients, including: multiple dedicated service subsystems, each corresponding to a different client type. Each dedicated service subsystem adopts a serverless computing architecture and includes: a first hardware platform and dedicated service logic pre-configured on the first hardware platform based on the specific requirements of the corresponding client type. Each dedicated service subsystem is configured to: in response to receiving a dedicated service request from a first client of the corresponding type, execute the dedicated service logic using dynamically scheduled computing resources on the first hardware platform to achieve the following steps: adapting the request data carried in 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; 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.

[0007] In some embodiments, the intermediate service system further includes: at least one general service subsystem, wherein each general service subsystem adopts a serverless computing architecture, including: a second hardware platform, and general service logic pre-configured on the second hardware platform based on the general requirements of various types of clients. Each general service subsystem is configured to: in response to receiving a general service request sent by any type of second client, execute the general service logic using computing resources dynamically scheduled in the second hardware platform to achieve 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.

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

[0009] In some embodiments, the intermediate service system further includes: a bottom-level service subsystem configured to provide a bottom-level service interface independent of the client type; each dedicated service subsystem selectively invokes the bottom-level service interface during the execution of the dedicated service logic to use the bottom-level services provided by the bottom-level service subsystem; and each general service subsystem selectively invokes the bottom-level service interface during the execution of the general service logic to use the bottom-level services provided by the bottom-level service subsystem.

[0010] In some embodiments, the underlying service interface includes at least one of a thread management interface, a cache management interface, and 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] Secondly, this specification also provides a method for providing intermediate services. The method is applied to an intermediate service system deployed between a backend service system and various types of clients. The intermediate service system includes: multiple dedicated service subsystems corresponding one-to-one with various client types. Each dedicated service subsystem adopts a serverless computing architecture and includes a first hardware platform and dedicated service logic pre-configured on the first hardware platform based on the dedicated requirements of the corresponding client type. The method includes, 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 using dynamically scheduled computing resources on the first hardware platform to achieve 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 includes at least one general service subsystem, wherein each general service subsystem adopts a serverless computing architecture, including: a second hardware platform, and general service logic pre-configured on the second hardware platform based on the general requirements of various types of clients. The method further includes: in response to the general service subsystem receiving a general service request sent by any type of second client, executing the general service logic using computing resources dynamically scheduled in the second hardware platform to achieve 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 includes: a first general service subsystem employing a Backend-as-a-Service (BaaS) architecture; and / or a second general service subsystem employing a Function-as-a-Service (FaaS) architecture.

[0016] In some embodiments, the intermediate service system further includes a low-level service subsystem that provides a low-level service interface independent of the client type. Each dedicated service subsystem selectively calls the low-level service interface to use the low-level services provided by the low-level service subsystem during the execution of the dedicated service logic. Each general service subsystem selectively calls the low-level service interface to use the low-level services provided by the low-level service subsystem during the execution of the general service logic.

[0017] In some embodiments, the underlying service interface includes 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 functionalities of the intermediate service system and methods for providing intermediate services provided in this specification will be partially listed in the following description. The inventive aspects of the intermediate service system and methods for providing intermediate services provided in this specification can be fully understood through practice or use of the methods, apparatus, and combinations described in the detailed examples below. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 A schematic diagram of an intermediate service system and its application scenarios provided according to embodiments of this specification is shown;

[0023] Figure 2 A schematic diagram illustrating another intermediate service system and its application scenarios provided according to embodiments of this specification is shown;

[0024] Figure 3 A schematic diagram illustrating another intermediate service system and its application scenario provided according to embodiments of this specification is shown;

[0025] Figure 4 A schematic diagram illustrating another intermediate service system and its application scenario provided according to embodiments of this specification is shown;

[0026] Figure 5 A schematic diagram of a hardware device according to this specification is shown; and

[0027] Figure 6 A flowchart of a method for providing intermediate services according to an embodiment of this specification is shown. Detailed Implementation

[0028] The following description provides specific application scenarios and requirements for this specification, intended to enable those skilled in the art to make and use the contents of this specification. Various partial modifications to the disclosed embodiments will be apparent 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 this specification. Therefore, this specification is not limited to the embodiments shown, but rather to the widest scope consistent with the claims.

[0029] The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not restrictive. For example, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” used herein may also include the plural forms. When used in this specification, the terms “comprising,” “including,” and / or “containing” mean that the associated integers, steps, operations, elements, and / or components are present, 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 may be added to the system / method.

[0030] Considering the following description, these and other features of this specification, as well as the operation and function of the related components of the structure, and the economy of assembly and manufacture of the parts, can be significantly improved. All of these form part of this specification with reference to the accompanying drawings. 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 this specification. It should also be understood that the drawings are not drawn to scale.

[0031] The flowcharts used in this specification illustrate operations implemented according to some embodiments of this specification. It should be clearly understood that the operations in the flowcharts may not be implemented in a sequential order. Instead, the operations may be implemented in reverse order or simultaneously. Furthermore, one or more additional operations may be added to the flowcharts. One or more operations may be removed from the flowcharts.

[0032] Before describing the specific embodiments in this specification, we will first introduce the application scenarios to which the technical solutions provided in this specification are applicable.

[0033] With technological advancements, the forms of user-facing service terminals / clients are becoming increasingly diverse. Clients not only include traditional personal computer (PC)-based web clients, but have also expanded to various types of mobile clients.

[0034] However, different clients vary significantly in hardware capabilities, screen size, operating system characteristics, user interaction methods, and so on. For example, mobile clients have relatively small screen sizes, and the information displayed differs considerably from that of traditional web clients. Furthermore, mobile clients possess unique capabilities such as biometric login and near-field communication (NFC). These differences lead to significant variations in client page presentation and interaction logic. This necessitates developers providing and maintaining different data interfaces for different client types, increasing development complexity. Moreover, these interfaces are often tightly coupled with the client's display and interaction logic, making flexible adjustments or reuse difficult.

[0035] Therefore, one or more embodiments of this specification provide an intermediate service system deployed between various types of clients and backend service systems. The intermediate service system includes multiple dedicated service subsystems corresponding to different client types. Each dedicated service subsystem responds to dedicated service requests from clients of the corresponding type, executes dedicated service logic, and calls backend service interfaces provided by the backend service system, thereby supporting the operation of various client types and meeting the compatibility requirements of multiple client types.

[0036] Figure 1 A schematic diagram illustrating an intermediate service system and its application scenarios according to embodiments of this specification is shown. Figure 1 As shown, application scenario 100 includes user 110, client 120, intermediate service system 130, and backend service system 140. Among them, intermediate service system 130 and backend service system 140 can be collectively referred to as service system.

[0037] User 110 can be any person who interacts with the service system (e.g., intermediate service system 130 and backend service system 140) through client 120.

[0038] Client 120 can serve as the entry point for user 110 to interact with the service system. Client 120 can be a terminal device, or a software program or application running on the terminal device. Client 120 is responsible for providing an interactive interface to user 110. User 110 can perform operations on client 120 (e.g., the interactive interface), and client 120 can respond to user 110's operations, generate corresponding requests and send them to the service system, and receive responses (data) from the service system.

[0039] The terminal devices may include personal computers (PCs), mobile devices (such as mobile phones), tablets, laptops, built-in devices in motor vehicles, or similar content, or any combination thereof. In some embodiments, smart home devices may include smart TVs, desktop computers, etc., or any combination thereof. In some embodiments, smart mobile devices may include smartphones, personal digital assistants, gaming devices, navigation devices, etc., or any combination thereof. In some embodiments, virtual reality devices or augmented reality devices may include virtual reality headsets, virtual reality glasses, virtual reality patches, augmented reality headsets, augmented reality glasses, augmented reality patches, or similar content, or any combination thereof. For example, virtual reality devices or augmented reality devices may include Google Glass, head-mounted displays, VR, etc. In some embodiments, built-in devices in motor vehicles may include in-vehicle computers, in-vehicle televisions, etc.

[0040] Based on the interaction method and architecture of the network system, the client 120 can be mainly divided into mobile clients and web clients.

[0041] Mobile applications (APPs) primarily refer to applications running on portable mobile devices such as mobile devices and tablets, typically providing services in the form of APPs. APPs provide users 110 with the ability and interface to interact with the outside world. APPs include, but are not limited to: web browser APPs, search APPs, chat APPs, shopping APPs, video APPs, instant messaging tools, email terminals, social media platforms, etc. Users 110 interact with the service system by running the target APP and performing various operations within it. For example, if the target APP is a shopping APP, user 110 can perform operations such as logging in, browsing products, submitting orders, selecting payment methods, verification, and payment within the target APP. As an example, when user 110 clicks "login," client 120 can send the corresponding request to the service system and receive the service system's response (data).

[0042] In some embodiments, mobile clients can be further divided into H5 mobile clients and native mobile clients. H5 mobile clients refer to web applications developed based on HTML5 technology and accessed through a mobile device's browser. Native mobile clients refer to applications developed using native development languages ​​(such as Java / Kotlin, Objective-C / Swift) on a specific operating system. Native mobile clients can further include Android mobile clients and iOS mobile clients.

[0043] A web client primarily refers to a web-based application accessed through a browser. User 110 can use it without installation and it's compatible with various browser-enabled devices such as PCs and desktop computers. User 110 can access the target web application through the web client and perform various operations within the target webpage to interact with the service system. For example, if the target web application is a shopping platform, user 110 can log in, browse products, submit orders, select payment methods, verify credentials, and make payments. As an example, when user 110 clicks "submit order," client 120 can send the corresponding request to the service system and receive the service system's response (data).

[0044] In some embodiments, client 120 can also be categorized as a mobile client, a web client, a client running on a specific device (e.g., a smart TV app, a transaction program on a POS device), etc. It is worth noting that this specification does not limit the type of client; all clients capable of accessing the service system / server are within the scope of protection of the embodiments described in this specification.

[0045] However, different types of clients differ significantly in hardware capabilities, screen size, operating system characteristics, user interaction methods, and so on. Let's take mobile clients and web clients as examples. For instance, their interface layout and information presentation methods differ. Web clients typically run on large-screen devices, such as PCs or laptops, while mobile clients typically run on small-screen devices, such as smartphones. Due to the difference in screen size, their information display differs significantly. Web clients can display more content and more complex layouts simultaneously, such as multi-column tables, detailed navigation menus, and rich charts, while mobile clients require a simpler interface design, typically displaying information step-by-step through pagination, collapsible panels, or swiping transitions to ensure clear content and convenient operation. Furthermore, their hardware capabilities and extended functions differ. Mobile clients can have hardware modules such as fingerprint recognition, facial recognition, positioning, and Near Field Communication (NFC) modules, supporting extended functions such as biometric login, location authorization verification, and card reading. These functions are often not available in web clients or have compatibility limitations.

[0046] Therefore, even within the same application scenario, where mobile and web clients serve the same system functions, significant differences remain in their implementation. For example, consider user 110 purchasing goods on a shopping platform. User 110 can complete operations such as logging in, browsing products, submitting orders, selecting payment methods, and making payments within the target web application (web client) or the target app (mobile client). When logging in, user 110 typically uses a username and password on the web client. On the mobile client, in addition to the username and password, a facial recognition module can be used for biometric identification. When browsing products, user 110 can see all products in a store simultaneously on the web client. On the mobile client, user 110 can only see a portion of the products on the current page and needs to swipe to view all products. Therefore, different types of clients require different service logic to implement their specific functions.

[0047] exist Figure 1 In this system, the service system includes an intermediate service system 130 and a backend service system 140. The two work together to receive, process, and respond to requests from the client 120.

[0048] The intermediate service system 130 serves as an intermediary layer between the client 120 and the backend service system 140, enabling effective decoupling and collaboration between them. The intermediate service system 130 is primarily responsible for receiving requests from the client 120, executing service logic, processing request data (e.g., parsing, parameter validation, format conversion, permission verification, etc.), calling backend service interfaces, and adapting response formats according to client type, among other processes.

[0049] In some embodiments, the intermediate service system 130 can be implemented through a Backends For Frontends (BFF) layer (system) that serves the frontend. As mentioned earlier, different types of clients 120 have different requirements for the format, content, and structure of interface data. The BFF layer can call different backend service interfaces according to the characteristics of different types of clients and return adapted response data to the clients. For example, for mobile clients, BFF can return a compact and concise response with graphics and text; while for web clients, BFF supports more fields and more complex data organization structures. The BFF layer can aggregate multiple backend interfaces into a single interface that can be directly used by the client 120, reducing the number of requests made by the client 120 and reducing processing complexity. For example, during the loading of a product details page, the BFF layer can uniformly aggregate the results returned by multiple interfaces such as inventory, price, and promotional information, and package them back to the client 120.

[0050] It is evident that the BFF layer needs to provide different interfaces for different clients, and the design of these interfaces is highly dependent on the display and processing logic on different clients. In this situation, the BFF layer's development and operations personnel are caught in the middle, coordinating and making trade-offs between various modules, resulting in low development efficiency.

[0051] In some embodiments, the BFF layer can adopt a Software as a Service (SaaS) system / architecture, or the BFF layer can be split into multiple independent SaaS systems. However, in this approach, different types of clients often require independent BFF layers, and even if some BFF layers are relatively lightweight, they still require at least one server to run. To achieve high availability, load balancing, and environmental differences, the actual server resource consumption will gradually increase as the number of client types increases, resulting in resource waste and increased service deployment and maintenance costs. At the same time, developers not only need to focus on feature development, but also need to invest in server scaling, log management, and other maintenance work, increasing the development burden and hindering agile delivery.

[0052] Figure 2 A schematic diagram illustrating another intermediate service system and its application scenarios provided according to embodiments of this specification is shown. In some embodiments, such as Figure 2 As shown, the intermediate service system 130 includes multiple dedicated service subsystems 131. Each dedicated service subsystem 131 corresponds one-to-one with a variety of client types 120. Each dedicated service subsystem 131 adopts a serverless computing architecture and includes a first hardware platform and dedicated service logic pre-configured on the first hardware platform based on the specific requirements of the corresponding type of client 120.

[0053] In other words, different types of clients 120 correspond to different dedicated service subsystems 131. For example, Figure 2 Type A clients and Type B clients are shown. The intermediate service system 130 includes a dedicated service subsystem 131 corresponding to Type A client 120 and a dedicated service subsystem 131 corresponding to Type B client 120. For example, Type A client can be a web client, and Type B client can be a mobile client.

[0054] Each dedicated service subsystem 131 adopts a serverless computing architecture. For example, each dedicated service subsystem 131 is implemented through a serverless system. Serverless computing architecture does not mean "no servers," but rather that in this architecture, the cloud service provider is responsible for building and managing the hardware infrastructure platform, including physical servers, storage devices, and network devices, allocating hardware resources to developers through virtualization technology. Application or web page developers do not need to worry about server deployment, management (scaling up and down), and maintenance; they can focus solely on logic development. Therefore, dedicated service subsystem 131 can include the first hardware platform provided by the cloud service provider, and dedicated service logic, such as dedicated service commands, provided and configured by developers on the first hardware platform. Furthermore, the serverless computing architecture of dedicated service subsystem 131 enables dynamic scheduling of computing resources. In other words, dedicated service subsystem 131 can automatically allocate computing resources based on real-time requests and service invocation, achieving elastic scaling and optimized resource allocation without requiring developers to worry about the deployment, operation, and release of the underlying servers, thus saving computing resources.

[0055] In the embodiments described in this specification, a hardware platform (e.g., a first hardware platform, or a second hardware platform mentioned later) can be a collective term for one or more hardware devices; that is, a hardware platform may include one or more hardware devices. The service logic configured on the hardware platform (e.g., dedicated service logic, or general service logic mentioned later) can be an instruction set.

[0056] In some embodiments, different dedicated service subsystems 131 may use different first hardware platforms. In some embodiments, "first hardware platform" is a general term for hardware platforms, and different dedicated service subsystems 131 may also use the same first hardware platform. For example, different dedicated service subsystems 131 may use the same group of physical servers.

[0057] Dedicated service logic is configured by developers based on the specific needs of the corresponding type of client 120. In other words, dedicated service logic is not generic, but rather specific processing logic designed and implemented by developers based on the differentiated characteristics of the corresponding client type (such as different hardware), for example, calling different backend service interfaces. Different types of clients 120 have different specific needs, and therefore different dedicated service logic.

[0058] For mobile clients, for example, in a shopping scenario, when user 110 logs in via the mobile client, in addition to username and password login, the mobile client needs to support user 110 logging in via biometric methods such as fingerprint recognition or facial recognition. Biometric methods are a proprietary requirement of mobile clients, and developers need to configure dedicated service logic for calling biometrics to complete login on the first hardware platform. As another example, in a public transportation scenario, user 110 can use the near field communication (NFC) function of the mobile client to ride public transportation. NFC functionality is a proprietary requirement of mobile clients, and developers need to configure dedicated service logic for NFC functionality on the first hardware platform.

[0059] For web clients, for example, in a corporate contract management scenario, user 110 accesses the company's contract management system via a web client and needs to scan and upload paper contract documents. To adapt to the unique interactive logic of web browsers, the web client needs to support user 110 uploading files via drag-and-drop (dragging the scanned document to a designated area). Uploading files via drag-and-drop is a specific requirement for web mobile clients, and developers need to configure dedicated service logic for this upload method on the primary hardware platform. As another example, in a shopping scenario, web clients typically support high-resolution product images or videos, while mobile clients may only return thumbnail links. Returning high-resolution product images is a specific requirement for web clients, and developers need to configure corresponding dedicated service logic on the primary hardware platform.

[0060] Each dedicated service subsystem 131 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, and provide a dedicated service.

[0061] As mentioned above, user 110 can perform operations on the first client. The first client can be a mobile client or a web client. The first client can generate corresponding dedicated service requests based on the above operations and send them to the corresponding dedicated service subsystem 131. For example, when the first client is a mobile client, and user 110 logs in on the first client and selects face recognition, the first client can generate a corresponding dedicated service request (face recognition request). This dedicated service request can be sent to the dedicated service subsystem 131 corresponding to the mobile client. For example, when the first client is a web client, and user 110 uploads a file on the first client, the first client can generate a corresponding dedicated service request (drag-and-drop file upload). This dedicated service request can be sent to the dedicated service subsystem 131 corresponding to the web client.

[0062] As mentioned earlier, the dedicated service subsystem 131 can dynamically schedule computing resources. Therefore, the dedicated service subsystem 131 can utilize the dynamically scheduled computing resources in the first hardware platform to execute dedicated service logic, such as executing corresponding instruction sets and providing intermediate services, without requiring developers to concern themselves with computing resources. The specific methods by which the dedicated service subsystem provides intermediate services will be described later.

[0063] By deploying dedicated service subsystems 131 for different types of clients 120, the system supports the operation of multiple types of clients 120, meeting the compatibility requirements of various client types 120. Furthermore, the dedicated service subsystems 131 for different types of clients 120 can be designed, developed, and maintained independently, reducing the dependence on R&D. Moreover, by using a serverless computing architecture, developers can focus solely on developing and building the system's functionalities, without needing to worry about system server maintenance, greatly improving R&D efficiency. Furthermore, since the dedicated service subsystems 131 adopt a serverless computing architecture, they possess the characteristics of elastic computing scalability, effectively saving computing resources and system service deployment and maintenance costs.

[0064] 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 authentication, databases, file storage, push notifications, cloud functions, etc. Developers do not need to build and maintain their own servers or databases; they only need to call the required services through interfaces.

[0065] Figure 3 A schematic diagram illustrating another intermediate service system and its application scenario provided according to embodiments of this specification is shown. In some embodiments, such as Figure 3 As shown, the intermediate service system 130 may further include at least one general service subsystem 132. Each general service subsystem 132 employs a serverless computing rack. 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 requirements of various types of clients.

[0066] In other words, the intermediate service system 130 may include one or more general service subsystems 132. Different types of clients 120 may share the at least one general service subsystem 132. For example, Figure 3 A general service subsystem 132 is shown, which can be interacted with by both type A and type B clients to use the general services it provides.

[0067] Each general-purpose service subsystem 132 also adopts a serverless computing architecture. For example, each general-purpose service subsystem 132 is implemented through a serverless system. Similar to the dedicated service subsystem 131, the general-purpose service subsystem 132 can also automatically allocate computing resources based on real-time requests and service invocation, achieving elastic scaling and optimized resource allocation, without requiring developers to concern themselves with the deployment, operation, and release of the underlying servers. For details, please refer to the dedicated service subsystem 131; further details will not be elaborated here.

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

[0069] The general service logic is configured by developers based on the common needs of multiple or all types of clients 120. In other words, the general service logic is independent of client type, reusable and common across multiple types or all clients, providing 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 handle the common needs of user 110.

[0070] For example, in a shopping scenario, user 110 selects products and places an order (submits the order). Submitting an order is one of the most basic operations in a shopping system. Therefore, order submission is usually a common requirement. Both mobile and web clients need to deploy corresponding common service logic. Different types of clients 120 can then share a common service subsystem 132. Developers can configure the common service logic for order submission on a second hardware platform. Both mobile and web clients can call the same service interface to complete the order submission. As another example, in a product after-sales scenario, user 110 needs to take pictures of the product and upload them to the system so that the merchant can review the product status and perform corresponding after-sales operations. Therefore, uploading images is usually a common requirement. Both mobile and web clients need to deploy corresponding common service logic. Developers can configure and implement the common service logic for uploading images on a second hardware platform.

[0071] In some embodiments, the intermediate service system 130 may include multiple general service subsystems 132. These multiple general service subsystems 132 are responsible for providing different general services. For example, one general service subsystem 132 is responsible for providing an order submission service, while another general service subsystem 132 is responsible for providing a file upload service.

[0072] Each general service subsystem 132 is configured to: in response to receiving a general service request from a second client of any type, execute general service logic using computing resources dynamically scheduled in the second hardware platform to provide general services.

[0073] The second client can be any type of client. For example, the second client can be a mobile client or a web client.

[0074] User 110 can perform operations on the second client. The second client can generate a corresponding general service request based on this operation and send it to the general service subsystem 132. As an example, in a shopping scenario, when user 110 selects goods and submits the order, the second client can generate a corresponding general service request (order submission). This general service request can be sent to the general service subsystem 132.

[0075] As mentioned earlier, the general service subsystem 132 can dynamically schedule computing resources. Therefore, the general service subsystem 132 can utilize the dynamically scheduled computing resources in the second hardware platform to execute general service logic and provide intermediate services without requiring developers to concern themselves with computing resources. The specific methods by which the general service subsystem 132 provides intermediate services will be described later.

[0076] In some embodiments, the at least one general service subsystem 132 includes a first general service subsystem employing a Backend-as-a-Service (BaaS) architecture. As mentioned earlier, BaaS can provide developers with a complete set of backend functionalities, allowing developers to directly call these services to build systems without having to build and maintain backend servers, databases, and other infrastructure themselves.

[0077] In some embodiments, the at least one general-purpose service subsystem 132 may include a second general-purpose service subsystem employing a Function as a Service (FaaS) architecture. FaaS is a cloud computing service model that allows developers to deploy and run individual functions (functional modules) without managing servers themselves. Developers only need to write the functions corresponding to the service; the system automatically handles deployment, scaling, resource management, on-demand invocation, and pay-as-you-go billing. In other words, when user 110 triggers the corresponding service or request, the function runs automatically, and releases the corresponding computing resources upon completion.

[0078] 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.

[0079] 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.

[0080] 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.

[0081] 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.

[0082] 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.

[0083] In some embodiments, each dedicated service subsystem 131 may selectively invoke the underlying service interface to use the underlying services provided by the underlying service subsystem 133 during the execution of the dedicated service logic. Similarly, each general service subsystem 132 may selectively invoke the underlying service interface to use the underlying services provided by the underlying service subsystem 133 during the execution of the general service logic.

[0084] In other words, when executing their respective service logic, dedicated service subsystem 131 and general service subsystem 132 will call the underlying service interfaces provided by the underlying service subsystem 133 as needed, thereby utilizing the resources and capabilities of the underlying service subsystem 133 to complete the request. In other words, dedicated service subsystem 131 and general service subsystem 132 are request-oriented service layers; they can implement higher-level service logic by calling the underlying or basic functions provided by the underlying service subsystem 133.

[0085] The dedicated service subsystem 131 and the general service subsystem 132 can selectively call the underlying service interface according to actual needs. For example, during the execution of a dedicated service request, the dedicated service subsystem 131 may call the underlying service interface or it may not call the underlying service interface.

[0086] In some embodiments, the underlying service interface may include at least one of a thread management interface, a cache management interface, and a database management interface. The thread management interface provides functions for creating, scheduling, and managing threads within the program. The cache management interface provides the ability to access, update, and clear cached data. The database management interface provides the ability to connect to a database, execute Structured Query Language (SQL) statements, and perform data queries and updates.

[0087] As an example, when the underlying service interface includes a database management interface, the General Service Subsystem (BaaS) 132 will call the database management interface to query product inventory, write order information to the database, and update product inventory quantity when implementing the order creation function.

[0088] In some embodiments, the underlying service subsystem 133 adopts a Platform as a Service (PaaS) architecture. PaaS architecture is also a cloud computing service model that provides developers with the platform and tools needed to build, deploy, run, and manage applications without having to worry about the underlying infrastructure (such as servers, storage, networks, etc.).

[0089] In some embodiments, the underlying service subsystem 133 may also call the backend service interface provided by the backend service system 140.

[0090] By deploying the underlying service subsystem 133, a stable and scalable operating environment is provided for the general service subsystem 132 and the dedicated service subsystem 131, reducing their operation and maintenance costs and complexity.

[0091] Backend service system 140 can refer to a service component that runs on the server side of the entire system, responsible for handling service logic, managing data resources, and interacting with databases or other systems. Backend service system 140 can provide backend service interfaces for middleware service systems to call, in order to achieve distributed collaboration.

[0092] For example, backend service interfaces may include a biometric interface. The biometric interface provides the ability to collect, verify, and manage user biometric features, supporting the uploading of biometric data and identity verification. The dedicated service subsystem 131 corresponding to mobile client 120 can call this biometric interface during user login verification. As another example, backend service interfaces may include an order creation interface. The order creation interface supports users submitting order requests, entering, verifying, and generating order information, ensuring the order is valid and triggering subsequent processes. The general service subsystem 132 of client 120 can call this interface when a user creates an order. As yet another example, backend service interfaces may include a file upload interface. The file upload interface provides file upload, storage, and management services, supporting the reception of multiple file formats. The general service subsystem 132 of client 120 can call this interface when a user uploads a file.

[0093] In some embodiments, the interface requirements for different backend service interfaces may differ. The request data transmitted by different types of clients 120 may vary, and the specifications of different backend service interfaces may also differ.

[0094] The intermediate service system 130 needs to adapt the request data to ensure that the processed request data conforms to the specifications of the backend service interface. For example, the request data format, fields, and types must conform to the specifications to ensure that the backend service interface can correctly identify the request.

[0095] In some embodiments, different backend service interfaces return different formats. After the intermediate service system 130 calls the backend service interfaces, the response data structures returned by the backend service interfaces vary greatly. For example, some backend service interfaces return data in JSON format after processing the request, while others return data in XML format, and so on.

[0096] The intermediate service system 130 needs to transform the response data returned by different backend service interfaces into response data adapted to the format returned by the corresponding client 120, ensuring that the client 120 can correctly identify and efficiently process the corresponding response data, thereby improving response speed and user experience. The intermediate service system 130 performs bidirectional data adaptation between the client 120 and the backend service system 140.

[0097] As an example, Figure 4 A schematic diagram illustrating another intermediate service system and its application scenario provided according to embodiments of this specification is shown. Figure 4 As shown, the dedicated service subsystem adopts the BaaS architecture, and the general service subsystem includes a general service subsystem that adopts the BaaS architecture and a general service subsystem that adopts the FaaS architecture.

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

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

[0100] It should be understood that Figures 1-4 The number of users 110, clients 120, dedicated service subsystems 131, general service subsystems 132, and underlying service subsystems 133 in the intermediate service system 130 are merely illustrative. Depending on implementation needs, the number of users 110, clients 120, and systems / subsystems can be arbitrary.

[0101] Figure 5 A schematic diagram of a hardware device 500 according to this specification is shown. The first hardware platform and the second hardware platform may have, for example... Figure 5 The structure of the hardware device 500 shown (or, in other words, the first hardware platform may include one or more such as Figure 5 The hardware device shown is 500. The backend service system can also have, for example, [the following]. Figure 5 The structure of the hardware device 500 shown (or, in other words, the backend service system may include one or more such devices) Figure 5The hardware device shown is 500.

[0102] like Figure 5 As shown, the hardware device 500 includes at least one storage medium 530 and at least one processor 520. In some embodiments, the hardware device 500 may further include a communication port 550 and an internal communication bus 510. Additionally, the hardware device 500 may also include I / O components 560.

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

[0104] Storage medium 530 may include a data storage device. The data storage device may be a non-transitory storage medium or a transient storage medium. For example, the data storage device may include one or more of a disk 532, a read-only storage medium (ROM) 534, or a random access storage medium (RAM) 536. Storage medium 530 also includes at least one instruction set stored in the data storage device. The instruction set is computer program code, which may include programs, routines, objects, components, data structures, procedures, modules, etc., that perform the methods for providing intermediate services shown in this specification.

[0105] Communication port 550 is used for data communication between hardware device 500 and the outside world. For example, hardware device 500 can connect to a network through communication port 550. At least one processor 520 is communicatively connected to at least one storage medium 530 via an internal communication bus 510. At least one processor 520 is used to execute at least one instruction set. When hardware device 500 is running, at least one processor 520 reads at least one instruction set and executes the method for providing intermediate services shown in this specification according to the instructions of at least one instruction set.

[0106] Processor 520 can execute all the steps included in the method providing intermediate services. Processor 520 can be in the form of one or more processors. Processor 520 can issue execution instructions. Processor 520 can include one or more hardware processors, such as microcontrollers, microprocessors, reduced instruction set computers (RISC), application-specific integrated circuits (ASICs), application-specific instruction set processors (ASIPs), central processing units (CPUs), graphics processing units (GPUs), physical processing units (PPUs), microcontroller units, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), advanced RISC machines (ARMs), programmable logic devices (PLDs), any circuit or processor capable of performing one or more functions, or any combination thereof.

[0107] For illustrative purposes only, only one processor 520 is described in this specification for hardware device 500. However, it should be noted that hardware device 500 may also include multiple processors. Therefore, the operation and / or method steps disclosed in this specification may be executed by one processor as described herein, or they may be executed jointly by multiple processors. For example, if processor 520 of hardware device 500 in this specification executes steps A and B, it should be understood that steps A and B may also be executed jointly or separately by two different processors 520 (e.g., a first processor executes step A, a second processor executes step B, or the first and second processors jointly execute steps A and B).

[0108] Figure 6 A flowchart of a method P600 for providing an intermediate service according to an embodiment of this specification is shown. The method P600 for providing an intermediate service can be executed by an intermediate service system. Figure 6 As shown, method P600 includes S610.

[0109] S610: In response to the dedicated service subsystem receiving a dedicated service request sent by a first client of the corresponding type, the dedicated service logic is executed using computing resources dynamically scheduled in the first hardware platform to implement steps S610-1 to S610-2.

[0110] As previously mentioned, a user can trigger a dedicated service request on the first client. The dedicated service request can be sent to the corresponding dedicated service subsystem. The dedicated service subsystem, which adopts a serverless computing architecture, can dynamically schedule computing resources in the first hardware platform to execute dedicated service logic (e.g., instruction sets) to achieve the following steps S610-1 to S610-2.

[0111] S610-1: According to the interface requirements of the backend service system, adapt the request data carried by the dedicated service request, and call the backend service interface provided by the backend service system based on the adapted request data.

[0112] As mentioned earlier, the dedicated service subsystem can process the corresponding request data, making the request data compatible with the interface requirements of the backend service system. For example, the dedicated service subsystem can convert and adjust the structure, name, type, etc. of the request data to conform to the interface requirements of the backend service system.

[0113] The dedicated service subsystem can call the backend service interface based on the adapted request data, thereby using the service capabilities provided by the backend service system.

[0114] S610-2: 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.

[0115] As mentioned earlier, the structure of the response data returned by the backend service interfaces differs. The dedicated service subsystem needs to process the returned response data to adapt it to the interface requirements of the first client, ensuring that the first client can correctly identify and efficiently process the corresponding response data, thereby improving response speed and user experience.

[0116] By deploying a dedicated service subsystem between the client and backend service systems, and enabling bidirectional adaptation between them, the intermediate service system can meet the compatibility requirements of various client types. Furthermore, the dedicated service subsystem can dynamically schedule computing resources during operation, saving computing resources and freeing developers from the burden of managing and maintaining them.

[0117] As mentioned earlier, the intermediate service subsystem may also include a general service subsystem. Therefore, in some embodiments, such as Figure 5 As shown, method P600 may also include:

[0118] S620: In response to the general service subsystem receiving a general service request sent by a second client of any type, the general service logic is executed using computing resources dynamically scheduled in the second hardware platform to implement steps S620-1 to S620-2.

[0119] As previously mentioned, a user can trigger a general service request on a second client. The general service request can be sent to the general service subsystem. The general service subsystem, which employs a serverless computing architecture, can dynamically schedule computing resources in the second hardware platform to execute general service logic (e.g., instruction sets) to achieve steps S620-1 to S620-2 below.

[0120] S620-1: According to the interface requirements of the backend service system, adapt the request data carried by the general service request, and call the backend service interface provided by the backend service system based on the adapted request data.

[0121] For details, please refer to the dedicated service request; this manual will not repeat them here.

[0122] S620-2: According to the interface requirements of the second client, adapt the response data returned by the backend service interface and send the adapted response data to the second client.

[0123] For details, please refer to the dedicated service request; this manual will not repeat them here.

[0124] In summary, this specification provides an intermediate service system deployed between the client and the backend service system. The intermediate service system includes multiple dedicated service subsystems corresponding to different client types. These subsystems respond to dedicated service requests from their respective client types, execute dedicated service logic, and call backend service interfaces provided by the backend service system, thereby supporting the operation of multiple client types and meeting the compatibility requirements of various client types. Furthermore, since the dedicated service subsystems adopt a serverless architecture, they can dynamically call computing resources, effectively saving computing resources and system service deployment and maintenance costs. Furthermore, the intermediate service system also includes a general service subsystem, allowing multiple client types to share or reuse this general service subsystem, avoiding redundant development. Deploying the general service subsystem facilitates unified maintenance and modification of general services for different client types, enhances system independence, and facilitates development and functional expansion by developers. Moreover, the general service subsystem also adopts a serverless architecture, effectively saving computing resources and system service deployment and maintenance costs.

[0125] This specification, in another aspect, provides a non-transitory storage medium storing at least one set of executable instructions for providing an intermediate servicing method. When the executable instructions are executed by a processor, they instruct the processor to perform the steps of method P600 described herein. In some possible embodiments, various aspects of this specification can also be implemented as a program product comprising program code. When the program product is run on an intermediate servicing system, the program code causes the intermediate servicing system to perform the steps of method P600 described herein. The program product for implementing the above method may employ a portable compact disc read-only memory (CD-ROM) containing program code and may run on an intermediate servicing system. However, the program product of this specification is not limited thereto. In this specification, a readable storage medium may 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 may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. The computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can send, propagate, or transmit programs for use by or in connection with an instruction execution system, apparatus, or device. Program code contained on a readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof. Program code for performing the operations described herein can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on an intermediate server system, partially on an intermediate server system, as a standalone software package, partially on an intermediate server system and partially on a remote computing device, or entirely on a remote computing device.

[0126] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0127] In summary, after reading this detailed disclosure, those skilled in the art will understand that the foregoing detailed disclosure is presented by way of example only and is not restrictive. Although not explicitly stated herein, those skilled in the art will understand that this specification requires various reasonable changes, improvements, and modifications to the embodiments. These changes, improvements, and modifications are intended to be made by this specification and are within the spirit and scope of the exemplary embodiments described herein.

[0128] Furthermore, certain terms in this specification have been used to describe embodiments of this specification. For example, "an embodiment," "an embodiment," and / or "some embodiments" mean that a particular feature, structure, or characteristic described in connection with that embodiment may be included in at least one embodiment of this specification. Therefore, it is to be emphasized and understood that two or more references to "an embodiment" or "an embodiment" or "alternative embodiment" in various parts of this specification do not necessarily refer to the same embodiment. Moreover, specific features, structures, or characteristics may be suitably combined in one or more embodiments of this specification.

[0129] It should be understood that in the foregoing description of the embodiments in this specification, various features are combined in a single embodiment, drawing, or description for the purpose of simplifying the description and to aid in understanding a feature. However, this does not mean that the combination of these features is necessary, and those skilled in the art, upon reading this specification, may readily identify some of the devices as separate embodiments. That is, the embodiments in this specification can also be understood as an integration of multiple secondary embodiments. And the content of each secondary embodiment is valid even if it contains fewer than all the features of a single foregoing disclosed embodiment.

[0130] Every patent, patent application, publication of a patent application, and other material such as articles, books, specifications, publications, documents, articles, etc., cited herein, except for those inconsistent with or conflicting with this document, or those having a restrictive effect on the widest scope of the claims, may be incorporated herein by reference for all purposes now or hereafter associated with this document. Furthermore, in the event of any inconsistency or conflict between the description, definition, and / or use of relevant terms in any material and the description, definition, and / or use of relevant terms in this document, the terms in this document shall prevail.

[0131] Finally, it should be understood that the embodiments disclosed herein are illustrative of the principles of the embodiments described in this specification. Other modified embodiments are also within the scope of this specification. Therefore, the embodiments disclosed in this specification are merely examples and not limitations. Those skilled in the art can implement the applications described in this specification using alternative configurations based on the embodiments in this specification. Therefore, the embodiments in this specification are not limited to the embodiments precisely described in the applications.

Claims

1. An intermediary service system deployed between a backend service system and various types of clients, comprising: Multiple dedicated service subsystems correspond one-to-one with various client types. Each dedicated service subsystem adopts a serverless computing architecture and includes: a first hardware platform and dedicated service logic pre-configured on the first hardware platform based on the specific requirements of the corresponding client type. Each dedicated service subsystem is configured to: in response to receiving a dedicated service request from a first client of the corresponding type, execute the dedicated service logic using dynamically scheduled computing resources in the first hardware platform to achieve 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 the backend service interface provided by the backend service system is called based on the adapted request data. 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.

2. The system of claim 1, wherein, The intermediate service system also includes: At least one general-purpose service subsystem, wherein each general-purpose service subsystem adopts a serverless computing architecture, including: a second hardware platform, and general-purpose service logic pre-configured on the second hardware platform based on the general requirements of multiple types of clients. Each general service subsystem is configured to: in response to receiving a general service request from a second client of any type, execute the general service logic using dynamically scheduled computing resources in the second hardware platform to achieve the following steps: According to the interface requirements of the backend service system, the request data carried in the general service request is adapted, and the backend service interface provided by the backend service system is called based on the adapted request data. According to the interface requirements of the second client, the response data returned by the backend service interface is adapted and sent to the second client.

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

4. The system of claim 2, wherein, The intermediate service system also includes: The underlying service subsystem is configured to provide underlying service interfaces that are independent of client type; During the execution of the dedicated service logic, each dedicated service subsystem selectively calls the underlying service interface to use the underlying services provided by the underlying service subsystem. During the execution of the general service logic, each general service subsystem selectively calls the underlying service interface to use the underlying services provided by the underlying service subsystem.

5. The system according to claim 4, wherein, The underlying service interfaces include at least one of the following: thread management interface, cache management interface, or database management interface.

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

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

8. A method for providing an intermediary service, applied to an intermediary service system deployed between a backend service system and multiple types of clients, the intermediary service system comprising: The method comprises multiple dedicated service subsystems corresponding to various client types, each employing a serverless computing architecture and including a first hardware platform and dedicated service logic pre-configured on the first hardware platform based on the specific requirements of the corresponding client type. In response to the dedicated service subsystem receiving a dedicated service request from a first client of the corresponding type, the dedicated service logic is executed using computing resources dynamically scheduled in the first hardware platform to achieve 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 the backend service interface provided by the backend service system is called based on the adapted request data. 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 according to claim 8, wherein, The intermediate service system further includes at least one general service subsystem, wherein each general service subsystem adopts a serverless computing architecture, including: a second hardware platform, and general service logic pre-configured on the second hardware platform based on the general requirements of various types of clients. The method further includes: In response to the general service subsystem receiving a general service request from a second client of any type, the general service logic is executed using dynamically scheduled computing resources in the second hardware platform to achieve the following steps: According to the interface requirements of the backend service system, the request data carried in the general service request is adapted, and the backend service interface provided by the backend service system is called based on the adapted request data. According to the interface requirements of the second client, the response data returned by the backend service interface is adapted and sent to the second client.

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

11. The method according to claim 9, wherein, The intermediate service system also includes: a low-level service subsystem that provides low-level service interfaces independent of client type. During the execution of the dedicated service logic, each dedicated service subsystem selectively calls the underlying service interface to use the underlying services provided by the underlying service subsystem. During the execution of the general service logic, each general service subsystem selectively calls the underlying service interface to use the underlying services provided by the underlying service subsystem.

12. The method according to claim 11, wherein, The underlying service interfaces include at least one of the following: thread management interface, cache management interface, or database management interface.

13. The method according to claim 11, wherein, The underlying service subsystem adopts a Platform as a Service (PaaS) architecture.

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

Images