This is the 8th day of my participation in the August Text Challenge.More challenges in August

Resources of applets can be broadly divided into front-end and back-end resources: front-end resources can also be called end-to-end resources (including scripts, style files, etc.), and back-end resources refer to some service interfaces of applets.

End – side update policy

  • The front-end resources of a website can be divided into dynamic resources and static resources. Static resources include JS, CSS, images and other files. In order to improve performance, these files are usually cached locally as far as possible. The only dynamic resources are HTML files
  • The HTML files of websites were originally rendered by the server through the template engine, such as Freemarker, Smarty, etc. Many websites still use this method, but React/Vue SSR and SPA static HTML are more popular.
  • In SPA, HTML files are deployed as static resources like JS and CSS files, but unlike JS and CSS, we don’t make browsers cache HTML files. Instead, the server configuration sets the cache-control Header of HTTP requests for HTML files to no-cache. This is to ensure that users will get the latest version of THE HTML file every time they open the website, and other static resources will be introduced through the HTML file, which ensures the real-time performance of the HTML file, and also ensures the real-time performance of all static resources on the website
  • Unlike a web site, “all” of the side resources of an applets are static
  • The resources of the mini program are hosted on the wechat server. Unlike the website, wechat does not pull the latest mini program resources from the server every time the user opens the mini program, but makes full use of the advantages of caching

When the user opens the small program, the wechat client will first pull the side resources of the small program from the cache, if there is, it will be displayed to the user, if not, it will be pulled from the wechat server, at this time, the latest version must be pulled, and then put into the cache and show to the user.

This is the end – side resource management mechanism of small program. One of the questions you can see from this process is: given the priority of using cached resources, how can I ensure that users update to a new version of the applet as soon as possible after I release it? This is the focus of our discussion: the end-to-end resource updating mechanism for applets.

There are two other types of timing besides the simplest one where no local cache fires.

  • Not start: refers to the small program is in a state of non active (for example, in the background), but please note that this state is only after the user has used small program can make, if the user never used you small programs, there is no state concept, because for this user, you small programs are stateless.
  • Cold start: The small program will enter the cold start state after being destroyed and opened again

When you release the new version of the mini program in the mini program management background, wechat will implement different update strategies according to the status of the mini program on the user’s device

If the small program is not started, the wechat client will check whether there is a new version of the small program in the cache at “several times”, and will silently pull the new version of resources to the local cache

If the mini program is in the cold start state, the wechat client will actively check whether there is a new version and show the user the old version in the cache. There is a new version of the words will silently pull to the local, and then the user again triggered the small program cold start when the display to the user. In other words, it takes two cold booting to present the latest version of the applets to the user. The whole process is shown in the figure below:

One conclusion you can draw from this is that when you release a new version, users don’t get updates “immediately.”

The slowest 24 hours when the small program is not started can cover all users, or need to experience two cold start, which is too slow for some urgent version update, so in real work often speed up the update of the small program, so that users can get the new version as soon as possible. The specific implementation method is through the UpdateManager object of the small program, in the code to actively check and apply the update information. Let’s look at the following diagram to illustrate the flow diagram and code:

const axios = require('axios')
const updateManager = wx.getUpdateManager()
updateManager.onCheckForUpdate(function (res) {
  // Mount the new version information to the global object
  this.globalData.hasUpdate = res.hasUpdate
})
updateManager.onUpdateReady(function () {
  if(!this.globalData.hasUpdate){
    return
  }
  const { miniProgram } = wx.getAccountInfoSync()
  // Get the version number of the current applet
  const currVersion = miniProgram.version
  // Check with your developer server interface to see if there are urgent releases that need to be updated
  axios.get(`${? currVersion=${currVersion}`).then(res= >{
    if(res.needUpdate){
      // Emergency version Immediately restart applet application update
      updateManager.applyUpdate()
    }
  })
})
Copy the code
  • Start by creating one in your codeUpdateManagerObject and then addonCheckForUpdate 和onUpdateReadyMonitoring, when the wechat client from the wechat server to obtain the update information of the small program will be triggeredonCheckForUpdateFunction, carried by the input parameterhasUpdateAttribute flag whether a new version has not been updated. We mount this information to the global object for later use.
  • Triggered when the wechat client pulls the latest version of the small program side resources from the wechat server to the localonUpdateReadyFunction, which requires your developer server to provide an interface corresponding to the your-URL in the code above. The input parameter of this interface is the version of the applet that the user is currently using. Based on this version number, it determines whether the applet version of the current user has serious bugs and needs to be updated to the latest version. You need to be in the script code of the applet whenonUpdateReadyThis interface is called when the function is triggered, or if it needs to be updated by callingupdateManager.applyUpdate()Forced restart applet to apply updates.

Compared with the default update mechanism that requires two cold starts, this update mechanism can reduce the time of a cold start and enable users to obtain the latest version of the small program more quickly. It is an effective scheme for some urgent Bug fixes. Of course, we only show the end-to-end invocation process, but when you release your applets on the back end, you need to record the details of each release, including whether there are urgent Bug fixes, so that you can provide a source of data for the end-to-end invocation.

Grayscale publishing strategy for back-end services

There is a very important and common strategy in the publishing process of back-end services: grayscale publishing. So-called gray released a simple understanding is to the new version of the service is available only to a certain percentage of the users, and the other part of the users are still using the old version of the service, and then observe the new version of the state, if everything is all right, slowly expand the proportion of the new version of the user, until all users are cut into the new version, is complete gray released the whole process.

Grayscale publishing requires the formulation of forwarding policies for user requests in advance. Generally, there are two types:

  • Random forwarding according to the proportion of servers occupied by new and old services;
  • Forwarding by user ID.
  • The first is simple and crude. For example, if you have 10 servers, two of which have a new version of the service deployed, the load balancer will randomly forward a user request to the new version of the server with a probability of 20%, and the rest to the old version of the server.
  • For example, Nginx configures Lua script. When receiving a user request, it obtains the user ID from the request, which is the user’s OpenId in the small program scenario, and then matches whether the ID is in the whitelist of the new version of the service in the forwarding policy. If so, forward to the new version service, otherwise forward to the old version service. As shown below: