one, the optimization of the picture experience.
Display pictures on the phone, speed is a very important point of experience, imagine, if you open a website, found that the picture has been shown that the failure or X, a little bit better, may be a loading or chrysanthemum and so on, but anyway, Not being able to pull and display pictures quickly is a great challenge for the user experience. So, how does the picture experience on the phone do? Here I have some small summary:
1, reduce the size of the picture. Make a tradeoff between distortion and image size, use tools to reduce the size of the image, and consider using different picture formats as well.
2, reduce the number of requests for pictures. Consider merging multiple images using CSS-like sprites, which can be loaded once;
3, consider caching. Cache the image on the client, set the cache length and update mechanism;
4, consider the use of CDN loading pictures, to achieve access to the nearest access;
5. Resolve DSN hijacking issues. Experience in the mobile phone business tells us, it is likely that some areas, some operators have our domain name is blocked or hijacked, so that the image of the domain name to interpret the IP is not the IP we provide image services, and this situation is difficult to find, because, if the operator by random hijacking by sampling, it is difficult to find. The solution can:
Remove DNS, change to direct access to IP, but need to solve the IP address of the nearest image service according to the user's IP, realize: here CGI when spit out the address of the access picture, get the user's source gateway IP, call the IP address library to determine the source IP location and operator, And then issued the corresponding image to deploy access to IP, the client uses IP direct image server, fast access to resources.
The problem is, there is the realization of the cost, the business itself to achieve a similar DNS interpretation of the logic, especially the picture into the CDN, so the transformation will not be able to use the CDN to provide the acceleration of service capabilities.
To do a good job of monitoring DNS hijacking, the actual piece of DNS interpretation to the VIP list is definitely in one of our white list, if not, it certainly belongs to the DNS hijacking, the client can at some point to pull our VIP list, as a monitoring and judge whether the problem of DNS hijacking, If the IP address of the DNS is not in the whitelist, it is replaced with an IP that is in the whitelist.
Consider the alternative domain name, that is, if a domain name is not pulled, use the alternate domain name to access, of course, if the alternate domain name is also hijacked, it is not.
6, without the picture, consider the text substitution scheme.
Two, optimize the background of the architecture
Background return faster, the front-end experience is better, therefore, also need to comb the call chain of the backend services, avoid cyclic calls, fast and slow mixed problems, the basic principle is relatively simple, are some of the principles of design
1, weight separation. Services in the large number of visits, the need for fast service and access is small, but the business logic complex process from the code implementation and physical deployment of a thorough separation, such as the use of access to CGI (or even different domain names), different background server, different clusters to isolate.
If put together, slow will stall fast, this is like the barrel principle, the final speed is the slowest decision, if not handled well, may cause the entire service jam is not available.
2, evaluate the business access process and path design, distinguish between critical path and non-critical path, design to consider the key path to non-critical path, the critical path needs to have multi-level disaster recovery considerations, non-critical anomalies need to be monitored.
3, consider asynchrony. Asynchrony is slightly more complex than synchronous implementations, or more work may be required, but the benefits of asynchrony can be obvious, especially for high-performance business processes. The common asynchronous implementation strategy is to use MQ as a buffer for each system, the producer process or subsystem writes the message to MQ to return immediately, and the consumer process or subsystem periodically reads the message from the MQ to continue processing, and the results of the processing through callback notification or write back to MQ to the producer query. Of course, if the producer is not paying attention to the result, it is much simpler, and after it is dropped into MQ, the problem here is that the whole MQ is the key to the entire business process and needs to ensure the high availability and performance of the service.
4, some configuration of dynamic loading, localized storage, plus version-based update mechanism. The author also found that some business CGI in a small number of requests when the high load, and eventually have to use more machines to bear the corresponding request volume, positioning the final reason is that CGI needs to load a lot of configuration at the start of the thing, and even many configurations are not required by the CGI, The optimization idea is: Load on demand, load only the CGI required, load the configuration to shared memory at the same time, increase the version number, maintain a private version of the CGI process and share the version of the memory, CGI when the start of the comparison version number, found different, then the real file re-load to memory. Another mode is to use the configuration center to push the mode, to achieve centralized management.
5, do the management of external dependence. A business process can often be called to external systems, and these systems may not be maintained by your team, if the system is a non-critical path is OK, if it is a critical path, then the management of external dependence is more important, then how to do a good job of external dependency management?
Here are a few tips:
. The external invocation of the service is individually encapsulated, such as the design of a separate proxy to invoke external services, the benefit is convenient centralized monitoring and disaster tolerance logic, the first step in the design of physical isolation of external factors, and subsequent if the External System protocol or IP address changes, you can only modify the module Quick fix;
. Serious recommendations for external interface error and time-out monitoring, once the problem, early warning and quick resolution, here is the lesson of the blood, a business and a platform provider on both sides in the tangle is the problem of who is very noisy, do not know who is the problem, the business said he did not have a problem, the platform said their services also quickly, if You can come up with your monitoring data, the interface timeout setting is 1s, timeout record has n, time is NS, error records have M bar, the main error type is XXX, that is very helpful for quick positioning.
. Consider whether it can be weakened as a non-critical path? Some calls may not be weakened to the non-critical path, such as the login state check, failed only the business process is terminated, to the user return failure (of course, there may be some business cache session ID as an exception when the standby, but this is not very recommended, the reason is very simple, may cause the portal is not unique, Even create a security breach, where specific case specific analysis is required. Some paths can be designed as non-critical paths, such as data escalation,
. Multilevel grayscale mode for critical paths. If it is known that a service is a critical path, such as a request Billno_server to obtain a unique order number before payment, from the business process, this is definitely a critical path, no order number cannot be placed, the orchestration does not go down, but if each order is called once Billno_ Server generates an order number, the occasional network time-out or failure is possible, and for the user, is the next single prompt everyone is very familiar with the word: "The system is busy, please try again later", then whether can do better? Or at least reduce that probability? One idea is to request a batch of Billno cache to the local process space each time, Then use the time to take from the local cache, no more requests, one is the request fails, whether you can consider to generate a local randomly, in extreme cases weaken the dependency on the critical path?
. If the data of the key path is the only source of the business, you can consider self-built part of the hotspot data, a problem, then switch to the self-built part of the hotspot data, continue to provide services.
6, considering that the computing power of the mobile client is weaker, in the design of whether to move the computational cost more to the service side, the use of powerful server-side computing power to enhance the user experience, this is the architecture design to the author of a feeling.
third, optimize the link
How to manage links is a cliché topic, here are the main long connections and short connection issues. Of course there are some other strategies such as connection pooling.
Weak network environment, the establishment of a link for a very long time, network quality test data show that the establishment of link occupancy time is close to 1/3, short links lead to frequent links, so consider the short link to the growth of links, in the fragmentation of time to reuse, reduce time to build the chain, in addition, there are several advantages:
1,c/s continuous link enables the backend to actively push critical data to the client, such as real-time notifications, new digital reminders and so on, can improve the experience, in the case of short links, can only rely on the client for timed polling, inevitably make new data delayed.
2, to further save the package size in the short link process, in case of short link, each back and forth request, inevitably need to bring some public data. Long links only use the first package in the successful construction link to uplink the data, and subsequent packages can eliminate these fields to further reduce traffic;
3, long link can also effectively reduce the flow limit of mobile phone software caused by the problem of the service is not available, some traffic restriction software will take over all network requests of users to achieve the purpose of traffic calculation and disconnection, this is essentially a hijacking, using long link + Private encryption protocol, can make the other party cannot accurately analyze the package situation, Reduce hijacking of incoming service unavailability.
4, long links can also reduce the dependence on temporary ports under high concurrency, some services that use short links, under high concurrency, the problem of discovering that temporary ports are unavailable can also be prioritized by long links.
Note: When using long links, there must be a case where the long link is not available, so the business implementation needs to be embedded in the re-connect mechanism.
four, multi-level service design based on network quality
Mobile phone network environment is more diverse, such as WiFi, 3G, 4G and 2G, and so on, different network environment experience is different, for very good network environment we will not say, the key to discuss in the case of 2G and other adverse circumstances of some thinking.
1, whether different network environment has multi-level service capability? For users with 2g networks, less content is displayed? The picture becomes text? Some feature portals are not available?
2, reduce the size of the network protocol packet. In the case of slow network speed, the size of the package is critical, directly affecting the success rate, you can consider a more compact protocol (including unnecessary fields do not send) + compression algorithm. Here is a tip, you know that the content of the cookie is every time with the HTTP request sent to the server, on the picture, JS,CCS, etc. recommended to deploy other domain names for cookie isolation, which can also reduce the size of a certain package.
