Build a highly scalable WEB interactive system (I) to build a highly scalable web

Build a highly scalable WEB interactive system (I) to build a highly scalable web

Source: http://www.zaojuzi.com/nirenju/1287.html

Scalability is a design indicator for the processing capability of software systems. high scalability represents a kind of elasticity. In the process of system expansion, it can ensure vigorous vitality. With few changes, to increase the processing capability of the entire system.

During system design, the scalability of the system is fully considered. On the one hand, it can greatly reduce the maintenance overhead in the future and help decision makers make more accurate estimates of the return on investment. On the other hand, high-scalability systems often have better disaster tolerance capabilities to provide a better user experience.

The scalability of WEB interactive systems is mainly reflected in two aspects:

• Scalability of platforms: With the development of WEB technology, more and more platforms begin to use WEB technology to build systems. On the one hand, the environmental support provided by different platforms is different. On the other hand, with the development of platforms, some old platforms are constantly withdrawn from the historical stage, and the new platform becomes the mainstream platform. Therefore, a WEB system built must be able to quickly respond to such changes, so it must have good platform scalability.
• Module Scalability: As system functions constantly increase, delete, and update requirements change, the system may become more and more complex, redundant information may also increase, and the impact of changes may also increase, therefore, good module scalability can ensure good maintainability of the system and keep the system in the optimal state.

The main applications of WEB interactive systems include:

• Desktop/mobile website systems (such as Netease cloud classrooms, Yixin WebIM, and Lofter mobile WEB edition)
• Mobile hybrid applications (such as Netease cloud album IPad and Lofter)
• Desktop hybrid applications (such as Netease cloud music PC Edition and Netease mailbox Assistant)

This series of articles mainly consists of two main parts: the scalability of the platform and the scalability of the module. This is the first article in the series to discuss the scalability of the platform.

Scalability of the platform

The scalability of the WEB interactive system to the platform is as follows:

• Scalability: quick support for emerging platforms
• Scalability: obsolete redundant platform information can be removed with minimal modification

Let's first introduce the target platform of the WEB interactive system.

Platform category

Based on the differences in the container where the system is located, we divide the platform into two categories: browser platform and hybrid application platform. A detailed description of each category is described below.

Browser Platform

By Engine

The browser platform can be divided into the following categories by mainstream engines:

Hybrid application platform

Based on the differences between the host platform of the hybrid application, we divide the target platform of the hybrid application into the following categories:

Host	Description
Android	For Android hybrid applications, the browser engine automatically adapts to Webkit.
IOS	For iOS hybrid applications, the browser engine automatically adapts to Webkit.
WinPhone	For Windows Phone hybrid applications, the browser engine automatically adapts to Trident.
PC	The desktop application uses CEF as the container, and the browser engine automatically adapts to Webkit.

Platform adaptation

AOP (Aspect-Oriented Programming): The Aspect-Oriented Programming Paradigm. Its core idea is to separate the cross-cutting concerns from the main concerns, therefore, problematic codes in specific fields can be separated from standard business logic, so that there is no coupling between the winner business logic and the leader business logic.

Here, we can use the AOP idea to implement the adaptation strategy of the platform. Combined with the Implementation logic of different platforms, we can consider that the part that uses norms and standards to implement the business logic is our main focus, different platforms can be encapsulated as several considerations. Each platform only needs to focus on the standard correction logic under its own platform, therefore, you can adapt to different platforms by adding or deleting the plane logic corrected by the platform.

When implementing the service, we first extract the standard business logic, and then each platform can correct the business logic based on the actual situation:

• Standard business logic: main focus. Here we mainly use the business logic implemented according to W3C and ES standards.
• Pre-platform correction logic: the focus of specific fields is to revise the standard under the platform based on the platform features. The correction logic will be executed before the Standard logic.
• Post-platform correction logic: Same as the pre-platform correction logic, it is also a domain-specific concern. The correction logic will be executed after the Standard logic is executed.

Based on this idea, we compare the following two pieces of code:

Code 1: Common Platform adaptation methods

Function doSomething () {if (isTrident) {// TODO trident implement} else if (isWebkit) {// TODO webkit implement} else if (isGecko) {// TODO gecko implement} else if (isPresto) {// TODO presto implement} else {// TODO w3c implement} // upper-layer applications use doSomething (1, 2, 3 );

This method implements the correction logic of all platforms in the main logic and has the following drawbacks:

• The correction logic unique to the platform is coupled in the main logic. The updates unique to the platform will inevitably lead to the updates of the main logic.
• Support for new or deleted platforms must be modified to the primary business logic
• Unnecessary platform corrections cannot be separated. For example, mobile platform applications based on the webkit engine do not need correction logic from other platforms.

Code 2: a platform adaptation method that draws on the idea of AOP

Function doSomething () {// TODO w3c/es implement} // upper-layer applications use doSomething (1, 2, 3 );

Applicable logic for the Trident platform, such as in trident. js

// trident implementdoSomething = doSomething._$aop(    function(_event){        // TODO trident implement    },    function(_event){        // TODO trident implement    });

Compared with code 1, we can find that the interface adaptation method based on the AOP idea separates the standard business logic from the platform-specific business logic. whether to add the platform-specific business logic does not affect the execution of the main business logic, the Platform correction logic can be added or deleted by means of configuration. Therefore, the following benefits can be obtained:

• The main logic and platform-specific logic are not coupled and can be freely separated and integrated.
• Only the specific logic of the newly added Platform is required for adaptation to the new platform, without affecting the main business logic.
• You can choose to export the specific business logic of the platform through the Target Platform Supported by configuration control.

Implementation example

The NEJ Framework draws on the idea of AOP to provide a configuration-based platform adaptation system, for details about this part, refer to NEJ dependency management system and platform adaptation system for more detailed information. The following is only an example of how to use it in NEJ.

Shows a typical adaptive control structure:

The widget. js is the business logic implementation file of the control. The implementation of this control depends on APIs with platform differences. The dependent code is as follows:

NEJ.define([    'util/event',    '{platform}api.js'],function(t,h,p){    // TODO});

The Processing Method for {platform} api. js is shown in. The./is relative to the current code file, that is, the directory where the widget. js file is located.

The api here. the js file is the standard implementation logic that must adapt to the API, while the api. patch. js files use NEJ. the patch interface provides on-demand adaptation logic for each platform. the patch interface provides on-demand output for the platform's condition recognition, because the api. patch. the js file will be output as needed, so in addition to using NEJ. in addition to the platform adaptation logic, patch cannot contain other business logic.

// This file can only define NEJ. patch cannot execute other business logic // when packaging and outputting, it only depends on the processing logic required by the platform configuration output // the actual situation. You can separate the platform-related logic into a separate module NEJ. define (['. /hack. js'], function (h) {// processing logic NEJ for the trident platform. patch ('tr', function () {// TODO}); // The processing logic NEJ for the gecko platform. patch ('gr ',['. /hack. firefox. js'], function (fh) {// TODO}); // The processing logic nej for the IE6 platform. patch ('tr = 2.0 ',['. /hack. ie6.js ']); // processing logic NEJ for IE7-IE9. patch ('3. 0 <= TR <= 5.0 ', function () {// TODO}); // it must be the same as hack. the return Value of the js file is the same as return h ;});

Finally, we only need to configure the target platform of the product to output the corresponding adaptation of the platform, without the additional impact of other platforms:

<script src="/path/to/nej/define.js?p=wkgktd"></script><script src="/path/to/nej/define.js?p=cef"></script>

Platform change

Through the above implementation example, we can see that when the platform changes, we can quickly scale up or down

Platform Expansion

When a new platform needs to be a system target platform, we only need to do the following:

• Add platform configuration identifier, such as nxw
• Identify the differences between the platform and the standard, and add the platform-specific business logic to the patch

• The system adds a new identifier to the platform configuration section, as shown in figure

  Original platform Adaptation: <script src = "/path/to/nej/define. js? P = wkgktd "> </script>

  New platform Adaptation: <script src = "/path/to/nej/define. js? P = wkgktdnxw "> </script>

You can complete the expansion of the platform without affecting the original business logic.

Platform reduction

When the target platform adapted to the system exits the historical stage for some reason, the system also needs to remove the redundant code of the platform from the system. We only need to do the following:

• The system deletes the platform ID to be removed from the platform configuration section, for example:

  Original platform Adaptation: <script src = "/path/to/nej/define. js? P = wkgktd "> </script>

  After the scale-down, the platform Adaptation: <script src = "/path/to/nej/define. js? P = wk "> </script>

You can scale down the platform without modifying any business logic.

The preceding section describes the platform scalability. The next article will describe the scalability of the module, so stay tuned!

This work is licensed using the "knowledge sharing" 4.0 international license agreement.

Original article link: http://www.zaojuzi.com/nirenju/1287.html