Business disaster recovery method, terminal device, software development kit server and communication system

CN117176553BActive Publication Date: 2026-09-11HUAWEI TECH CO LTD
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
CN202210590988.6
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-05-27
Publication Date
2026-09-11
Estimated Expiration
2042-05-27

AI Technical Summary

Technical Problem

[0004]但是,CDN服务器由外部服务商维护,当CDN服务器发生故障,会引发用户功能不可用

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN117176553B_ABST
    Figure CN117176553B_ABST
Patent Text Reader

Abstract

The application discloses a service disaster recovery method, which is used for SDK static resource disaster recovery. The method of the embodiment of the application comprises the following steps: a terminal device sends a first request message to a service server, the first request message can be used for requesting an SDK static resource; the terminal device acquires a first resource address and a second resource address returned by the service server, the first resource address is used for pointing to the SDK static resource located on a content distribution network (CDN) server, and the second resource address is used for pointing to the SDK static resource located on a source server. When the terminal device fails to acquire the SDK static resource based on the first resource address, the terminal device can request the resource from the source server according to the second resource address, so that the service reliability is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a service disaster recovery method, terminal equipment, software development kit server, and communication system. Background Technology

[0002] When users access the business server, the business server can integrate some product functions through software development kit (SDK) technology. Since the access speed of providing static resources of SDK through the origin server can vary greatly for users in different regions, static resources are usually stored on a content delivery network (CDN) server to improve user access speed.

[0003] In the prior art, the terminal device sends a request to the service server, the service server returns the address of the static resource located on the CDN server to the terminal device, and the terminal device requests the static resource from the CDN server based on the address.

[0004] However, CDN servers are maintained by external service providers, and when a CDN server fails, user functions will become unavailable. Summary of the Invention

[0005] This application discloses a business disaster recovery method for SDK static resource disaster recovery.

[0006] The first aspect of this application provides a business disaster recovery method, comprising: a terminal device sending a first request message to a business server, the first request message being used to request resources required to display a business page, the resources including software development kit (SDK) static resources, the SDK static resources being used to implement SDK functions associated with the business page; the terminal device obtaining a response message of the first request message returned by the business server, the response message of the first request message including a first resource address and a second resource address, the first resource address pointing to the SDK static resources located on a content delivery network (CDN) server, and the second resource address pointing to the SDK static resources located on an origin server.

[0007] The disaster recovery method provided in this application involves a terminal device requesting SDK static resource information from a service server. It can obtain two resource addresses from the service server: the address of the SDK static resource located on the CDN server and the address of the SDK static resource located on the origin server. As long as either the CDN server or the origin server is functioning normally, the terminal device can obtain the SDK static resources normally, enabling the SDK functionality associated with the business page. Even if some servers fail, such as the CDN server, the service can still operate normally, thus improving the disaster recovery capability of the service.

[0008] In one possible implementation of the first aspect, the second resource address is a backup address.

[0009] The disaster recovery method provided in this application embodiment can use a second resource address as a backup address. Since CDN servers can be edge servers deployed in various locations, users can obtain the required content from the nearest location, reducing network congestion and improving user access response speed. Typically, SDK resources located on the CDN server pointed to by the first resource address are requested first. However, CDN servers are usually maintained by external service providers, and if a failure occurs, the SDK service will be unavailable, resulting in uncontrollability. Therefore, by providing a second resource address to the terminal device, pointing to SDK resources located on the origin server, the origin server can provide service assurance when the CDN server fails.

[0010] In one possible implementation of the first aspect, the method further includes: the terminal device sending a second request message to the CDN server based on the first resource address, the second request message being used to request the SDK static resource located on the CDN server; the terminal device receiving a response message to the second request message sent by the CDN server; if the response message to the second request message includes information indicating a request failure, then the terminal device sending a third request message to the origin server based on the second resource address, the third request message being used to request the SDK static resource located on the origin server; the terminal device receiving a response message from the origin server returning the third request message, the response message to the third request message including the SDK static resource.

[0011] The business disaster recovery method provided in this application embodiment can obtain the SDK static resources located on the source server based on the second resource address if the request for SDK static resources from the CDN server based on the first resource address fails. This method has strong business disaster recovery capabilities and improves business reliability.

[0012] In one possible implementation of the first aspect, the method further includes: the terminal device implementing the SDK functions based on the SDK static resources, wherein the SDK functions include: login verification function or registration function.

[0013] A second aspect of this application provides a business disaster recovery method, comprising: an SDK server receiving a fourth request message sent by a business server, the fourth request message being used to obtain SDK static resources, the SDK static resources being used to implement SDK functions associated with a business page; the SDK server returning a response message of the fourth request message to the business server, the response message of the fourth request message including a first resource address and a second resource address, the first resource address pointing to the SDK static resources located on a CDN server, and the second resource address pointing to the SDK static resources located on an origin server.

[0014] The disaster recovery method provided in this application embodiment allows the SDK server to provide at least two addresses of SDK static resources located on different servers. When one server fails, the SDK static resources can be provided through the other server, thereby improving the disaster recovery capability of the business.

[0015] In one possible implementation of the second aspect, the second resource address is a backup address.

[0016] The disaster recovery method provided in this application can use a second resource address as a backup address. Since CDN servers can be edge servers deployed in various locations, users can obtain the resources they need from the nearest location, reducing network congestion and improving user access response speed. Typically, users will preferentially request SDK resources located on the CDN server pointed to by the first resource address. However, CDN servers are usually maintained by external service providers, and if a failure occurs, the SDK service will be unavailable, resulting in uncontrollability. Therefore, by providing a second resource address pointing to SDK resources located on the origin server, the origin server can provide service assurance when the CDN server fails. This can improve user access response speed while providing business disaster recovery capabilities and enhancing business reliability.

[0017] In one possible implementation of the second aspect, the method further includes: the SDK server updating the first resource address and / or updating the second resource address.

[0018] The business disaster recovery method provided in this application update the first resource address and / or the second resource address in the SDK server when the SDK static resources are updated, such as in the case of version upgrade. As a result, the dynamically updated reliable address information can be returned to the business server.

[0019] A third aspect of this application provides a business disaster recovery method, comprising: a business server receiving a first request message sent by a terminal device, the first request message containing resources required to display a business page, the resources including static resources of a software development kit (SDK), the static resources of the SDK used to implement SDK functions associated with the business page; the business server sending a fourth request message to an SDK server according to the first request message, the fourth request message being used to obtain the static resources of the SDK; the business server receiving a response message of the fourth request message returned by the SDK server, the response message of the fourth request message including a first resource address and a second resource address, the first resource address pointing to the static resources of the SDK located on a CDN server, the second resource address pointing to the static resources of the SDK located on an origin server; and the business server forwarding the first resource address and the second resource address to the terminal.

[0020] In one possible implementation of the third aspect, the second resource address is a backup address used when the first resource address fails to acquire the resource.

[0021] A fourth aspect of this application provides a terminal device, comprising:

[0022] The sending module is used to send a first request message to the business server. The first request message is used to request the resources required to display the business page. The resources include SDK static resources, which are used to implement the SDK functions associated with the business page.

[0023] The receiving module is used to obtain a response message of the first request message returned by the business server. The response message of the first request message includes a first resource address and a second resource address. The first resource address points to the SDK static resource located on the Content Delivery Network (CDN) server, and the second resource address points to the SDK static resource located on the origin server.

[0024] In one possible implementation of the fourth aspect, the second resource address is a spare address.

[0025] In one possible implementation of the fourth aspect, the sending module is further configured to send a second request message to the CDN server according to the first resource address, the second request message being used to request the SDK static resource located on the CDN server; the receiving module is further configured to receive a response message to the second request message sent by the CDN server; the sending module is further configured to, if the response message of the second request message includes information indicating a request failure, send a third request message to the origin server according to the second resource address, the third request message being used to request the SDK static resource located on the origin server; the receiving module is further configured to receive a response message from the origin server returning the third request message, the response message of the third request message including the SDK static resource;

[0026] In one possible implementation of the fourth aspect, the terminal device further includes: a processing module that implements the SDK functions based on the SDK static resources, wherein the SDK functions include: login verification function.

[0027] A fifth aspect of this application provides an SDK server, comprising: a receiving module for receiving a fourth request message sent by a business server, the fourth request message being used to obtain SDK static resources, the SDK static resources being used to implement SDK functions associated with a business page; and a sending module for returning a response message of the fourth request message to the business server, the response message of the fourth request message including a first resource address and a second resource address, the first resource address pointing to the SDK static resources located on a CDN server, and the second resource address pointing to the SDK static resources located on an origin server.

[0028] In one possible implementation of the fifth aspect, the second resource address is a backup address.

[0029] In one possible implementation of the fifth aspect, the SDK server further includes: an update module for updating the first resource address and / or updating the second resource address.

[0030] A sixth aspect of this application provides a service server, comprising: a receiving module, configured to receive a first request message sent by a terminal device, the first request message being resources required to display a service page, the resources including software development kit (SDK) static resources, the SDK static resources being used to implement SDK functions associated with the service page; a sending module, configured to send a fourth request message to an SDK server according to the first request message, the fourth request message being used to obtain SDK static resources; the receiving module is further configured to receive a response message to the fourth request message returned by the SDK server, the response message including a first resource address and a second resource address, the first resource address pointing to the SDK static resources located on a CDN server, and the second resource address pointing to the SDK static resources located on an origin server; the sending module is further configured to forward the first resource address and the second resource address to the terminal.

[0031] In one possible implementation of the sixth aspect, the second resource address is a backup address.

[0032] A seventh aspect of this application provides a terminal device, comprising: a memory storing computer-readable instructions; and a processor connected to the memory, wherein when the computer-readable instructions are executed by the processor, the terminal device performs the method as described in any one of the first aspect and various possible implementations above.

[0033] An eighth aspect of this application provides an SDK server, comprising: a memory storing computer-readable instructions; and a processor connected to the memory, wherein when the computer-readable instructions are executed by the processor, the SDK server implements the method as described in any one of the second aspect above and various possible implementations.

[0034] A ninth aspect of this application provides a service server, comprising: a memory storing computer-readable instructions; and a processor connected to the memory, wherein when the computer-readable instructions are executed by the processor, the service server implements the method as described in any one of the third aspect above and various possible implementations.

[0035] The tenth aspect of this application provides a computer program product including computer-readable instructions that, when executed on a computer, cause the computer to perform the method as described in any one of the first, second, third aspects and various possible implementations above.

[0036] The eleventh aspect of this application provides a computer-readable storage medium, characterized in that the computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the method as described in any one of the first, second, and third aspects and various possible implementations above.

[0037] A twelfth aspect of this application provides a chip including a processor. The processor is used to read and execute a computer program stored in a memory to perform a method in any possible implementation of any of the above aspects. Optionally, the chip includes a memory, and the processor is connected to the memory via a circuit or wire. Further optionally, the chip also includes a communication interface, to which the processor is connected. The communication interface is used to receive data and / or information to be processed, the processor obtains the data and / or information from the communication interface, processes the data and / or information, and outputs the processing result through the communication interface. The communication interface may be an input / output interface.

[0038] This application's thirteenth aspect provides a communication system, comprising a terminal device, a service server, and an SDK server. The terminal device is configured to send a first request message to the service server, the first request message requesting resources required to display a service page, the resources including software development kit (SDK) static resources, the SDK static resources being used to implement SDK functions associated with the service page. The service server is configured to send a fourth request message to the SDK server based on the first request message, the fourth request message requesting the SDK static resources. The SDK server is configured to return a response message to the service server based on the fourth request message, the response message including a first resource address and a second resource address, the first resource address pointing to the SDK static resources located on a CDN server, and the second resource address pointing to the SDK static resources located on an origin server. The service server is further configured to send a response message to the terminal server, the response message including the first resource address and the second resource address.

[0039] In one possible implementation of the thirteenth aspect, the communication system further includes a CDN server and an origin server; the terminal device is further configured to send a second request message to the CDN server according to the first resource address, the second request message being used to request the SDK static resource located on the CDN server; the CDN server is configured to return a response message to the second request message according to the second request message; if the response message to the second request message includes information indicating a request failure, the terminal device is further configured to send a third request message to the origin server according to the second resource address, the third request message being used to request the SDK static resource located on the origin server; the origin server is configured to return a response message to the terminal device according to the third request message, the response message to the third request message including the SDK static resource.

[0040] In one possible implementation of the thirteenth aspect, the terminal server is further configured to implement the SDK functions based on the SDK static resources, the SDK functions including: login verification function.

[0041] The technical effects of any of the implementation methods in aspects four, five, six, seven, eight, nine, ten, eleven, twelfth and thirteenth can be found in the technical effects of the corresponding implementation methods in aspects one to three, and will not be repeated here.

[0042] The disaster recovery method provided in this application allows terminal devices to obtain two resource addresses for SDK static resources: the address of the SDK static resources located on the CDN server and the address of the SDK static resources located on the origin server. As long as either the CDN server or the origin server is functioning normally, the terminal device can be guaranteed to obtain the SDK static resources normally, enabling the SDK functionality associated with business pages. Even if some servers fail, such as the CDN server, business operations can still be guaranteed, thus improving the disaster recovery capability of the business. Attached Figure Description

[0043] Figure 1 A system architecture diagram of the service disaster recovery method provided in the embodiments of this application;

[0044] Figure 2 This is a schematic diagram of one embodiment of the service disaster recovery method in this application;

[0045] Figure 3 This is a schematic diagram illustrating an embodiment of the interaction between the business server and the SDK server in this application.

[0046] Figure 4This is a schematic diagram of an embodiment of module interaction in a terminal device according to the present application.

[0047] Figure 5 This is a schematic diagram of another embodiment of the service disaster recovery method in this application;

[0048] Figure 6 This is a schematic diagram of the code used by the service server to return information to the terminal device in an embodiment of this application;

[0049] Figure 7 This is a schematic diagram of the code for switching the SDK static resource address of the loading source server in the embodiment of this application;

[0050] Figure 8 This is a rendering of the e-commerce login interface in an embodiment of this application;

[0051] Figure 9 This is a schematic diagram of one embodiment of the terminal device in this application;

[0052] Figure 10 This is a schematic diagram of one embodiment of the SDK server in this application.

[0053] Figure 11 This is a schematic diagram of another embodiment of the terminal device in this application;

[0054] Figure 12 This is a schematic diagram of another embodiment of the SDK server in this application. Detailed Implementation

[0055] This application discloses a business disaster recovery method for SDK static resource disaster recovery, which can improve business reliability.

[0056] The embodiments of this application are described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. As those skilled in the art will recognize, with the development of technology and the emergence of new scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0057] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules is not necessarily limited to those explicitly listed, but may include other steps or modules not explicitly listed or inherent to such processes, methods, products, or devices. The naming or numbering of steps appearing in this application does not imply that the steps in the method flow must be performed in the chronological / logical order indicated by the naming or numbering. The execution order of named or numbered process steps can be changed according to the desired technical purpose, as long as the same or similar technical effect is achieved.

[0058] For ease of understanding, the following is a brief introduction to some of the technical terms used in the embodiments of this application:

[0059] 1. Software Development Kit (SDK)

[0060] Software development kits (SDKs) are generally collections of development tools used by software engineers to create application software for specific software packages, frameworks, hardware platforms, operating systems, etc. In a broader sense, software development tools refer to a collection of related documents, examples, and tools that assist in the development of a particular type of software.

[0061] A Software Development Kit (SDK) is a collection of development tools used by software engineers to create application software for specific software packages, frameworks, hardware platforms, and operating systems. Generally, an SDK is used to develop applications for the Windows platform. It can be as simple as some files providing an Application Programming Interface (API) for a programming language, but it may also include complex hardware capable of communicating with embedded systems. Common tools include utilities for debugging and other purposes. SDKs often also include sample code, supporting technical annotations, or other supporting documentation to clarify ambiguities for basic reference materials.

[0062] 2. JS-SDK (JavaScript Software Development Kit, JavaScript SDK) JS software development toolkit

[0063] JavaScript (JS for short) is a lightweight, interpreted or just-in-time (JIT) programming language with a function-first approach. The JS-SDK is an optional implementation of static resources for the SDK in this application embodiment.

[0064] 3. Content Delivery Network (CDN)

[0065] A CDN is an intelligent virtual network built on top of the existing network infrastructure. Relying on edge servers deployed in various locations, it uses a central platform's load balancing, content distribution, and scheduling modules to enable users to access the content they need from the nearest location, reducing network congestion and improving user access response speed and hit rate. The key technologies of a CDN mainly include content storage and distribution technologies.

[0066] 4. Disaster tolerance

[0067] A disaster recovery system refers to establishing two or more functionally identical systems in geographically dispersed locations. These systems can monitor each other's health status and switch functions. If one system stops working due to an accident (such as a fire, earthquake, or malfunction), the system can switch to another system, allowing the latter to continue functioning normally. Disaster recovery technology is a component of high availability technology, providing node-level system recovery capabilities.

[0068] The following describes the application scenario architecture of the service disaster recovery method in the embodiments of this application. Please refer to [link / reference]. Figure 1 The application scenario architecture includes: terminal device 100, business server 200, SDN server 300, CDN server 400 and source server 500.

[0069] Specifically, terminal device 100 communicates with business server 200 via a network connection, business server 200 communicates with SDN server 300 via a network connection, terminal device 100 communicates with CDN server 400 via a network connection, and communicates with origin server 500 via a network connection. It should be noted that CDN server 400, as an edge server deployed in various locations, is used to enable users to access the content they need from the nearest location, and is usually physically close to terminal device 100. However, the physical location of origin server 500 may be close to or far from terminal device 100, meaning that the access speed from different terminal devices 100 to origin server 500 can vary significantly.

[0070] Users access the business interface through the browser of terminal device 100. The browser can request the resources required to display the business interface from the business server 200. It should be noted that some product functions, such as login verification or registration information verification, are integrated through JS-SDK. Terminal device 100 needs to obtain the static resources of the SDK to implement these business functions.

[0071] Previously, the SDK static resources were stored on the origin server 500. Due to the large differences in user access speed, the user experience was affected. Therefore, it was possible to purchase CDN services to store the SDK static resources on CDN server 400. However, CDN servers are maintained by external service providers, and once a failure occurs, user functions will be unavailable.

[0072] In view of this, embodiments of this application provide a service disaster recovery method and network device for SDK static resource disaster recovery, which can improve service reliability.

[0073] See Figure 2 This application proposes a service disaster recovery method, which can be applied to... Figure 1 In the scenario shown, where, Figure 1 In the application scenario shown, the user terminal is equivalent to Figure 1 As shown, the method includes steps 201-208.

[0074] 201. The terminal device sends a first request message to the service server;

[0075] When a user accesses a business webpage through a browser on a terminal device, after the browser obtains the address accessed by the user, it can send a first request message to the business server. The first request message is used to request the resources required to display the business page. The resources include software development kit (SDK) static resources. The SDK static resources are used to implement the SDK functions associated with the business page.

[0076] In one possible implementation, the second resource address is a backup address. It is understood that the backup address can be used when the first resource address fails to acquire the resource.

[0077] 202. The business server sends a fourth request message to the SDK server;

[0078] The SDK server receives a fourth request message sent by the business server. The fourth request message is used to obtain SDK static resources, which are used to implement SDK functions associated with the business page.

[0079] 203. The SDK server returns a response message to the business server for the fourth request message;

[0080] The SDK server returns a response message to the business server for the fourth request message. The response message for the fourth request message includes a first resource address and a second resource address. The first resource address points to the SDK static resource located on the CDN server, and the second resource address points to the SDK static resource located on the origin server.

[0081] In other words, the SDK server not only provides the SDK static resources located on the CDN server, but also provides the address of the SDK static resources located on the origin server for switching in case of CDN server failure.

[0082] In one possible implementation, the SDK server updates the first resource address and / or updates the second resource address.

[0083] 204. The service server returns a response message to the terminal device for the first request message;

[0084] The terminal device obtains a response message to the first request message returned by the service server. The response message to the first request message includes a first resource address and a second resource address. The first resource address points to the SDK static resource located on the Content Delivery Network (CDN) server, and the second resource address points to the SDK static resource located on the origin server.

[0085] In one possible implementation, before executing step 205, the terminal device can first check whether the CDN network is normal. The checking method can refer to existing methods and is not limited here. If the check result is normal, a second request message is sent to the CDN server; if the check result is abnormal, steps 207-208 are executed.

[0086] 205. The terminal device sends a second request message to the CDN server;

[0087] The terminal device sends a second request message to the CDN server based on the first resource address. The second request message is used to request the SDK static resources located on the CDN server.

[0088] 206. The CDN server returns a response message to the terminal device for the second request message;

[0089] The terminal device receives a response message to the second request message sent by the CDN server;

[0090] 207. The terminal device sends a third request message to the source server;

[0091] If the response message of the second request message includes information about request failure, then the terminal device sends a third request message to the source server according to the second resource address. The third request message is used to request the SDK static resource located on the source server.

[0092] 208. The source server returns a response message to the terminal device for the third request message.

[0093] The terminal device receives a response message from the source server in response to the third request message, the response message of which includes the SDK static resources.

[0094] The disaster recovery method provided in this application involves a terminal device requesting SDK static resource information from a service server. It can obtain two resource addresses from the service server: the address of the SDK static resource located on the CDN server and the address of the SDK static resource located on the origin server. As long as either the CDN server or the origin server is functioning normally, the terminal device can obtain the SDK static resources normally, enabling the SDK functionality associated with the business page. Even if some servers fail, such as the CDN server, the service can still operate normally, thus improving the disaster recovery capability of the service.

[0095] Please see Figure 3 and Figure 4 This document provides a brief description of the modules in the terminal device, service server, and SDK server involved in this method in the embodiments of this application. For example... Figure 3 As shown in the above embodiment, the business server requests SDK static resources from the SDK server through the request module 301. The SDK server is configured with a storage module 302, which can store the address information of the SDK static resources. The SDK server reads a first resource address and a second resource address from the storage module 302. The first resource address points to the SDK static resources located on the Content Delivery Network (CDN) server, and the second resource address points to the SDK static resources CDN and origin server configuration address information located on the origin server, and returns this information to the business server.

[0096] like Figure 4 As shown, in one possible implementation, the terminal device includes a JS processing module 401 and a cache module 402. The browser JS processing module 401 is used to handle CDN exceptions. If an exception is found, it stores an identifier in the cache module 402. When loading SDK static resources in the same session later, it can first check whether the identifier exists in the cache module. If the identifier exists, it directly requests SDK resources from the origin server.

[0097] To facilitate understanding, the following example is provided. Please refer to the detailed explanation below. Figure 5This application proposes a method for business disaster recovery. The method can be applied to... Figure 1 In the scenario shown, where, Figure 1 In the application scenario shown, the user terminal is equivalent to Figure 1 The terminal device 100 shown is equivalent to an e-commerce server. Figure 1 The business server 200 shown is equivalent to the login verification server. Figure 1 The SDN server shown in the figure includes steps 501-511.

[0098] 501. The terminal device requests the resources required to display the business page from the e-commerce server;

[0099] The terminal device requests resources from the e-commerce server to display the business page. For example, the terminal device is a personal computer. It obtains the user's request to browse the e-commerce website in the browser. If the user is preparing to shop on the e-commerce website, they need to log in to the website first and access the e-commerce shopping login interface https: / / www.shop.com / index.html. After obtaining the access address through the browser, the terminal device will resolve the www.shop.com domain name to the e-commerce server and query the e-commerce server for the content to be displayed on the login interface.

[0100] 502. The e-commerce server requests SDK information from the login verification server;

[0101] After receiving the interface request from the browser, the e-commerce server organizes the content such as the page title and background image to be displayed. In addition, some SDK functions, such as those involving user login, verification, or registration, are delegated to the login verification server. The e-commerce server needs to request SDK information from the login verification server. The SDK information is the address of the SDK static resources (exemplarily, in this embodiment, the SDK static resources are specifically JS-SDK static resources).

[0102] 503. Login verification server confirms SDK information;

[0103] After receiving the request from the e-commerce server, the login verification server determines the static resource address of the JS-SDK, that is, obtains the URL address information of loginJSSDK.js.

[0104] This JS-SDK static resources are stored on two static resource servers and have two URLs:

[0105] a. Placed on the purchased CDN service, the SDK static resource address (i.e., the first resource address) located on the CDN server is https: / / www.cdn.com / loginJSSDK.js;

[0106] b. The SDK static resource address (i.e., the second resource address) on the source server of the Nginx static resources built on the account platform is https: / / www.account.com / loginJSSDK.js.

[0107] 504. The login verification server returns SDK information to the e-commerce server.

[0108] The login verification server returns SDK information to the e-commerce server. For an example, please refer to [link to example]. Figure 6 The JS-SDK information includes a first resource address and a second resource address. When the e-commerce server returns a page to the terminal device, it also returns the JS-SDK static resource address information to the terminal device's browser. The browser can then download and execute the JS-SDK static resource based on this address, rendering the account login interface. This JS-SDK static resource implements the functionality of an SDK (Software Development Kit) and is therefore called JS-SDK. To obtain the URL address information of loginJSSDK.js, the e-commerce server requests the login verification server to obtain the latest JS-SDK information for the login function.

[0109] 505. The e-commerce server returns SDK information to the terminal device;

[0110] The e-commerce server returns the resources needed to display the business page to the terminal device, including the title, background image, and HTML-formatted JavaScript URL information for login verification. Please refer to [link / reference]. Figure 6 The e-commerce server returns information to the terminal device.

[0111] 506. The terminal device requests static SDK resources from the CDN server;

[0112] The browser on the terminal device parses the information returned by the e-commerce server, initializes the login verification JS-SDK function, loads the JS static resource for login verification: jsSdkUrl, and requests the CDN server to download the SDK static resource https: / / www.cdn.com / loginJSSDK.js, sending a request to the domain www.cdn.com to download the JS-SDK static resource.

[0113] 507. The CDN server returns a response message to the terminal device;

[0114] If the response message returned in step 507 includes information indicating a failure to request static resources from the SDK, the terminal device loads the second resource address, triggering steps 508-511. If the download of https: / / www.cdn.com / loginJSSDK.js fails, step 507 returns an error code 404, and the browser receives a 404 error.

[0115] If the response message returned in step 507 includes SDK static resources, then proceed directly to step 511.

[0116] 508. If an exception is caught, load the second resource address;

[0117] If the terminal device returns a 404 error, it will load https: / / www.account.com / loginJSSDK.js. Please refer to [link / reference]. Figure 7 The illustrated code is shown.

[0118] 509. The terminal device requests static SDK resources from the source server;

[0119] The terminal device requests the source server to download the JS-SDK static resources.

[0120] 510. The source server returns static SDK resources to the terminal device;

[0121] 511. Terminal devices implement business functions based on SDK resources.

[0122] The browser retrieves `loginJSSDK.js` returned by the origin server and executes it. This JavaScript module dynamically loads other JavaScript or CSS files that the login verification function depends on. Ultimately, the business interface at https: / / www.shop.com / index.html displays the following... Figure 8 The image shown is a screenshot of an e-commerce login interface. The white area containing the username and password input boxes is the login box rendered after loading the JS-SDK static resources. The other parts are the title and background image returned by the e-commerce platform.

[0123] The above describes the service disaster recovery method provided in this application. The following describes the terminal devices that implement this service disaster recovery method. Please refer to [link / reference]. Figure 9 This is a schematic diagram of one embodiment of the terminal device in this application.

[0124] This application provides a terminal device, including:

[0125] The sending module 901 is used to send a first request message to the business server. The first request message is used to request the resources required to display the business page. The resources include information on static resources of the software development kit (SDK). The static resources of the SDK are used to implement the SDK functions associated with the business page.

[0126] The receiving module 902 is used to obtain a response message of the first request message returned by the service server. The response message of the first request message includes a first resource address and a second resource address. The first resource address points to the SDK static resource located on the content delivery network CDN server, and the second resource address points to the SDK static resource located on the origin server.

[0127] In one possible implementation, the second resource address is a backup address.

[0128] In one possible implementation, the sending module 901 is further configured to send a second request message to the CDN server based on the first resource address, the second request message being used to request the SDK static resource located on the CDN server; the receiving module 902 is further configured to receive a response message to the second request message sent by the CDN server; the sending module 901 is further configured to, if the response message of the second request message includes information indicating a request failure, send a third request message to the origin server based on the second resource address, the third request message being used to request the SDK static resource located on the origin server; the receiving module 902 is further configured to receive a response message from the origin server returning the third request message, the response message of the third request message including the SDK static resource;

[0129] In one possible implementation, the terminal device further includes a processing module 903, which implements the SDK functions based on the SDK static resources, the SDK functions including a login verification function.

[0130] It should be understood that the division of the various units in the above terminal device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these units can be implemented entirely in software through processing element calls; they can be implemented entirely in hardware; or some units can be implemented in software through processing element calls, while others can be implemented in hardware.

[0131] For example, these units can be one or more integrated circuits configured to implement the above methods, such as one or more application-specific integrated circuits (ASICs), one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs). As another example, when one of the above units is implemented through a processing element scheduler, the processing element can be a general-purpose processor, such as a central processing unit (CPU) or other processor capable of calling programs. Furthermore, these units can be integrated together to implement a system-on-a-chip (SOC).

[0132] The above describes the business disaster recovery method provided in this application. The following describes the SDK server that implements this method. Please refer to [link / reference]. Figure 10 This is a schematic diagram of one embodiment of the SDK server in this application.

[0133] This application provides an SDK server, including: a receiving module 1002, configured to receive a fourth request message sent by a business server, the fourth request message being used to obtain information about SDK static resources, the SDK static resources being used to implement SDK functions associated with a business page; and a sending module 1001, configured to return a response message of the fourth request message to the business server, the response message of the fourth request message including a first resource address and a second resource address, the first resource address pointing to the SDK static resources located on a CDN server, and the second resource address pointing to the SDK static resources located on an origin server.

[0134] In one possible implementation, the second resource address is a backup address.

[0135] In one possible implementation, the SDK server further includes an update module 1003, used to update the first resource address and / or update the second resource address.

[0136] It should be understood that the above division of the various units of the SDK server is only a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, these units can be implemented entirely in software through processing element calls; they can be implemented entirely in hardware; or some units can be implemented in software through processing element calls, while others can be implemented in hardware.

[0137] For example, these units can be one or more integrated circuits configured to implement the above methods, such as one or more application-specific integrated circuits (ASICs), one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs). As another example, when one of the above units is implemented through a processing element scheduler, the processing element can be a general-purpose processor, such as a central processing unit (CPU) or other processor capable of calling programs. Furthermore, these units can be integrated together to implement a system-on-a-chip (SOC).

[0138] Please see Figure 11 This is a schematic diagram of another embodiment of the terminal device in this application;

[0139] The terminal device provided in this embodiment can be an electronic device such as a mobile phone, laptop, desktop computer, tablet computer, or wearable device. The specific device form is not limited in this embodiment.

[0140] The terminal device 1100 may vary considerably due to different configurations or performance, and may include one or more processors 1101 and memory 1102, in which programs or data are stored.

[0141] The memory 1102 can be volatile or non-volatile. Optionally, the processor 1101 is one or more central processing units (CPUs), which can be single-core or multi-core CPUs. The processor 1101 can communicate with the memory 1102 and execute a series of instructions stored in the memory 1102 on the terminal device 1100.

[0142] The terminal device 1100 also includes one or more wired or wireless network interfaces 1103, such as Ethernet interfaces.

[0143] Optionally, although Figure 11 As not shown in the diagram, the terminal device 1100 may also include one or more power supplies; one or more input / output interfaces, which can be used to connect to a monitor, mouse, keyboard, touch screen device or sensing device, etc. The input / output interfaces are optional components and may or may not be present, and are not limited here.

[0144] The process executed by the processor 1101 in the terminal device 1100 in this embodiment can refer to the method flow described in the foregoing method embodiment, and will not be repeated here.

[0145] Please see Figure 12 This is a schematic diagram of another embodiment of the SDK server in this application.

[0146] The SDK server provided in this embodiment can be a virtual machine or a physical server, etc., and the specific device form is not limited in this embodiment.

[0147] The SDK server 1200 can vary considerably depending on its configuration or performance, and may include one or more processors 1201 and memory 1202, in which programs or data are stored.

[0148] The memory 1202 can be volatile or non-volatile memory. Optionally, the processor 1201 is one or more central processing units (CPUs), which can be single-core or multi-core CPUs. The processor 1201 can communicate with the memory 1202 and execute a series of instructions stored in the memory 1202 on the SDK server 1200.

[0149] The SDK server 1200 also includes one or more wired or wireless network interfaces 1203, such as Ethernet interfaces.

[0150] Optionally, although Figure 12 As not shown in the diagram, the SDK server 1200 may also include one or more power supplies; one or more input / output interfaces, which can be used to connect to a monitor, mouse, keyboard, touch screen device or sensing device, etc. The input / output interfaces are optional components and may or may not be present, and are not limited here.

[0151] The process executed by the processor 1201 in the SDK server 1200 in this embodiment can refer to the method flow described in the foregoing method embodiment, and will not be repeated here.

[0152] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0153] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0154] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0155] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0156] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0157] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A service disaster recovery method, characterized by, include: The terminal device sends a first request message to the business server. The first request message is used to request the resources required to display the business page. The resources include static resources of the software development kit (SDK). The static resources of the SDK are used to implement the SDK functions associated with the business page. The SDK functions include login verification functions or registration functions. The terminal device obtains a response message to the first request message returned by the service server. The response message to the first request message includes a first resource address and a second resource address. The first resource address points to the SDK static resource located on the Content Delivery Network (CDN) server, and the second resource address points to the SDK static resource located on the origin server. The second resource address is a backup address used to provide service assurance when the CDN server corresponding to the first resource address fails.

2. The method of claim 1, wherein, The method further includes: The terminal device sends a second request message to the CDN server based on the first resource address. The second request message is used to request the SDK static resource located on the CDN server. The terminal device receives a response message to the second request message sent by the CDN server; If the response message of the second request message includes information about request failure, then the terminal device sends a third request message to the source server according to the second resource address. The third request message is used to request the SDK static resource located on the source server. The terminal device receives a response message from the source server in response to the third request message, the response message of which includes the SDK static resources.

3. A business disaster recovery method, characterized in that, include: The SDK server receives a fourth request message sent by the business server. The fourth request message is used to obtain SDK static resources. The SDK static resources are used to implement SDK functions associated with the business page. The SDK functions include login verification functions or registration functions. The SDK server returns a response message to the business server for the fourth request message. The response message for the fourth request message includes a first resource address and a second resource address. The first resource address points to the SDK static resource located on the CDN server, and the second resource address points to the SDK static resource located on the origin server. The second resource address is a backup address used to provide business assurance when the CDN server corresponding to the first resource address fails.

4. The method according to claim 3, characterized in that, The method further includes: The SDK server updates the first resource address and / or updates the second resource address.

5. A terminal device, characterized in that, include: The sending module is used to send a first request message to the business server. The first request message is used to request the resources required to display the business page. The resources include SDK static resources. The SDK static resources are used to implement the SDK functions associated with the business page. The SDK functions include login verification functions or registration functions. The receiving module is used to obtain the response message of the first request message returned by the business server. The response message of the first request message includes a first resource address and a second resource address. The first resource address points to the SDK static resource located on the content delivery network CDN server, and the second resource address points to the SDK static resource located on the origin server. The second resource address is a backup address used to provide business assurance when the CDN server corresponding to the first resource address fails.

6. The terminal device according to claim 5, characterized in that, The sending module is further configured to send a second request message to the CDN server according to the first resource address, the second request message being used to request the SDK static resource located on the CDN server; The receiving module is further configured to receive a response message to the second request message sent by the CDN server; The sending module is further configured to, if the response message of the second request message includes information indicating a request failure, send a third request message to the source server based on the second resource address, wherein the third request message is used to request the SDK static resource located on the source server; The receiving module is further configured to receive a response message from the source server to the third request message, wherein the response message to the third request message includes the SDK static resources.

7. An SDK server, characterized in that, include: The receiving module is used to receive a fourth request message sent by the business server. The fourth request message is used to obtain SDK static resources. The SDK static resources are used to implement SDK functions associated with the business page. The SDK functions include login verification functions or registration functions. The sending module is used to return a response message of the fourth request message to the service server. The response message of the fourth request message includes a first resource address and a second resource address. The first resource address points to the SDK static resource located on the CDN server, and the second resource address points to the SDK static resource located on the origin server. The second resource address is a backup address used to provide service assurance when the CDN server corresponding to the first resource address fails.

8. The SDK server according to claim 7, characterized in that, The SDK server also includes: An update module is used to update the first resource address and / or update the second resource address.

9. A terminal device, characterized in that, include: A memory that stores computer-readable instructions; A processor connected to the memory, when the computer-readable instructions are executed by the processor, causes the terminal device to implement the method as described in claim 1 or 2.

10. An SDK server, characterized in that, include: A memory that stores computer-readable instructions; When the computer-readable instructions are executed by the processor connected to the memory, the SDK server causes the processor to implement the method as described in claim 3 or 4.

11. A computer program product, characterized in that, Includes computer-readable instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 4.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 4.

13. A communication system, characterized in that, The communication system includes terminal equipment, a service server, and an SDK server; The terminal device is used to send a first request message to the business server. The first request message is used to request resources required to display the business page. The resources include static resources of the software development kit (SDK). The static resources of the SDK are used to implement SDK functions associated with the business page. The SDK functions include login verification functions or registration functions. The business server is used to send a fourth request message to the SDK server according to the first request message, and the fourth request message is used to obtain SDK static resources; The SDK server is used to return a response message of the fourth request message to the business server according to the fourth request message. The response message of the fourth request message includes a first resource address and a second resource address. The first resource address points to the SDK static resource located on the CDN server, and the second resource address points to the SDK static resource located on the origin server. The second resource address is a backup address used to provide business assurance when the CDN server corresponding to the first resource address fails. The service server is also used to send the first resource address and the second resource address to the terminal device.

Citation Information

Patent Citations

  • Data downloading method, client-side and system

    CN104283933A

  • Resource acquisition method and device, equipment and computer readable storage medium

    CN108200132A

  • Resource access method, device and system, electronic equipment and storage medium

    CN112202631A