"Forwarding" builds a highly scalable web Interactive system (medium)

Translated from: http://kb.cnblogs.com/page/503953/

In the first chapter of building a highly scalable web interactive system, we describe the scalability of the platform in a Web-based interactive system. This article describes the scalability of the module.

　　The scalability of the module

The scalability of the Web Interactive system to the module also shows:

• Scalability: Fast response to support for new functional requirements of the system
• Scalability: Modules for system degradation can be removed with minimal modification

Here we provide a set of module scheduling system architecture mode, to support the single-page rich application system Design architecture, module splitting, module reorganization, scheduling management and other functions.

　　Module

The module we define is a separate unit that is split from the system and can interact with the user to complete part of the complete function.

　　Module composition

Because the module described here can interact with the user independently, the module contains the following elements:

• Styles: Defining the effects of a module
• Structure: Define the structure of the module
• Logic: Implementing the functionality of the module

The above elements are not unfamiliar to a web system developer, and we only need to find a way to encapsulate the content.

　　Module encapsulation

From the composition of the module we can see that the modules that are separated from the system may look like this, such as module.html, a module that we have separated.

Of course, it can also be encapsulated in script files, with styles and constructs in an injected form. The following examples are encapsulated in HTML files:

<!--module style--><style>    . m-mdl-1. A{color: #aaa;}    . M-mdl-1. B{color: #bbb;}    /* Omit some content here */</style><!--module structure--><div class= "M-mdl-1" >  <p class= "a" > aaaaaaaaaaaaaaaaaaa</p>  <p class= "B" >bbbbbbbbbbbbbbbbbbb</p>  <!--omit a few things here-- </div><!--Module Logic--><script>    (function () {        var a = ' aaa ';        var b = ' BBB ';        Some content omitted here    }) ();</script>

This module is loaded into the client when the user needs it and is displayed to interact with the user to complete the function. However, we will find that if the system pre-loads this module or module in parse, the content will be executed directly, and this result is not what we need, so we need to process the elements of the module text. There are several ways of text processing, such as text script, textarea, and so on, so the module in module.html can be encapsulated as follows to textarea example:

<!--module style--><textarea name= "CSS" >    . M-mdl-1. A{color: #aaa;}    . M-mdl-1. B{color: #bbb;}    /* Omit some content here */</textarea><!--module structure--><textarea name= "html" >    <div class= "M-mdl-1" >      <p class= "A" >aaaaaaaaaaaaaaaaaaa</p>      <p class= "B" >bbbbbbbbbbbbbbbbbbb</p>      <!- -Omit a few things here--    </div></textarea><!--module logic--><textarea name= "JS" >    (function () {        var a = ' aaa ';        var b = ' BBB ';        Some content omitted here    }) ();</textarea>

　　Management dependencies

There is a relationship between the modules that are split from the system, such as the rendering of a module that relies on the rendering of another module. Below we will use a simple example to explain the dependency management between modules, as one of our single-page application systems:

It is easy to see that the entire system contains the following sections:

• Log Management

• LOG: Log list, switchable Inbox/Drafts/Recycle Bin/Label
• Tags: tag list, go to log to view list by label

• Blog settings

• Account Management

• Basic information: User profile settings form
• Personal experience: personal experience filling out a form

• Permission settings: Permission Settings form

The hierarchical relationships between these modules are as follows:

Typical patterns for this hierarchical architecture for interactive systems can be found in the following:

• PAC (Presentation-abstraction-control) mode
• HMVC (hierarchical Model–view–controller) mode

However, in the course of the practice of Web Interactive system, we find that there are some defects in this pattern:

• Because each parent module maintains all of its submodules itself, the coupling between parent and child modules is too strong, and the parent module must couple all submodules
• Because the modules cannot leapfrog directly between calls, the Submodule must pass the event up and down if the sub-module requires additional module assistance, which can affect system efficiency if the hierarchy is too deep
• The changes caused by the change of the module and so on have a large impact, and deleting the module on the intermediate node may result in the change of several adjacent modules.
• Modules that have dependencies when collaborating to develop systems can lead to tight coupling between developers

Here, we give a module identification based on the dependency management configuration scheme, can completely decouple the module, each module can complete their own interactive function, and the integration of the system can be configured in a flexible way to reorganize the modules, the module's add and delete operations only need to modify the configuration can be completed, Without affecting the specific business logic.

Below we will explain the principle and actual operation of this scheme through the above examples.

　　Module identification

Because this scenario will be configured based on the module ID, so before introducing the scheme we introduce the module identification, here we give the module identification named UMI(Uniform module Identifier) Unified Module Identity, hereinafter referred to as UMI, following the rules of the Convention:

• Format the path part of the URI, such as/m/m0/
• Must start with a "/" character
• The private module must have a "/?" Begin
• The dependencies of the bearer modules, such as/m/m0/and/m/m1/, indicate that the parent module identity of the two identity modules is/m

Each Umi uniquely identifies a module and a module's dependencies in the system, and in the Modules section we introduce a module that can be encapsulated in one HTML, so we can get the following results:

Each Umi can be mapped to a module implementation file, so that we can be decoupled from the implementation of the module, adding and removing modifications to the module only need to adjust the mapping of the Umi and module files, without the need to involve specific business logic changes.

　　Module dependencies

After solving the problem of separation between modules and implementations, we need to flatten the hierarchical modules to decouple the dependencies between the modules. Back to the previous example, the hierarchical relationships between the modules are as follows:

If we abstract the dependencies in the diagram, we can see that all the modules are in a flat state:

The management of the dependencies before the module is consistent in all systems, but the specific function implementation of each module is determined by the system, and the different systems are distinct, so the solution provided by this solution is mainly used to maintain the dependencies between the modules.

From what we can clearly see, the dependencies between modules are rendered in a tree-like structure, so we will organize the dependencies between the maintenance modules in the structure of the tree, which we call the dependency tree. And when we serialize the path between any node in this tree and the root node in "/", we find that the Umi that we provide is matched, so the Umi of the module that makes up the system can correspond to node one by one of the dependency tree, as shown in:

In the Module Identification section we show that the Umi and module encapsulation files can be mapped to each other, so the nodes on the dependency tree can correspond directly to the module's implementation file one by one, as shown in:

At this point, we decompose the vertical-level dependent module into a flat modular structure with no relation through the dependency tree.

　　Module combination

The module only needs to have a rendering container to render it, so if the module needs to be able to do any combination, just divide the module into two types: the module that provides the container, and the module that uses the container. Of course, a module can both provide the container and use the container function, the module that provides the container and the module that uses the container can be any combination.

Example of a configuration code for a module combination:

'/m/blog/list/': {    module: ' module/layout/blog.list/index.html ',    composite:{        box: '/?/blog/box/',        tag: '/?/blog/tag/',        list: '/?/blog/list/',        clazz: '/?/blog/class/'    }

　　Scheduling policy

After the module is flattened, the modules can be arranged for different developers to perform functional implementation and testing, after each module is completed according to the dependency tree system integration, the system after the integration of the modules will follow a certain scheduling strategy.

　　Module status

According to the stage division of module scheduling, the state of the module can be divided into the following four kinds:

• Module Building: Building a modular structure
• Module display: Render the module into the specified container
• Module refresh: Get the data and show it according to the parameter information entered by the outside world (mainly doing data processing)
• Module hiding: Modules are put into memory to reclaim additional data and structures generated by the display and refresh phases

The scheduling strategy mainly controls the conversion rules between the modules in these phases.

　　Module display

When a user requests a module to be displayed, the modules follow these steps for scheduling, assuming the request displays the/m/blog/list/module:

1. Check the target node to the root node path registered module, if registered is the module's implementation file address, then request load module implementation file
2. If all ancestor nodes of the module where the node is located are displayed, the current module can be displayed, otherwise wait for the ancestor module's display schedule
3. After the module is loaded, try to schedule the display of the target module according to the second step principle

　　Module switching

When the user switches from one module to another, the modules follow the following steps, assuming the switch from/m/blog/list/to the/m/setting/account/edu/module:

1. Find common parent node of source module and target module

2. Module Dispatch hidden operation from source node to public node

3. Module scheduling refresh operations from the root node to the public node

4. Module dispatch display operation from public node to target node

　　Message Channel

Most of the time we do not recommend the use of the module before the message communication, in practice there are some special circumstances will require the module before the message communication, there are two ways of message communication:

• Point-to-point message: Explicitly specify the Umi of the target module when a module sends a message
• Watch Subscription Message: A module can declare what kind of message is released, the module that needs can subscribe to the message on the module Umi

Some of the principles of module scalability are described above. In the final article in this series, we will take NetEase's nej framework as an example to illustrate the above principles. Please look forward to!

This work is licensed using the Creative Commons Attribution 4.0 International license.

"Forwarding" builds a highly scalable web Interactive system (medium)