Factors to consider before web development

function implementation

This is needless to say.

Performance and Scalability

The machine load is evaluated according to the expected number of visits. It is not necessary to use multiple servers if a server can survive in the foreseeable future. Several aspects of performance evaluation are required: Web servers, logical servers, DB, and so on. At the same time each link can consider whether the cache is required.

At the Web server level, there is an important point, that is, the URL selection of the system. First, try to avoid sharing a domain name with a system that has a large number of different visits. Because with the development of the system, it is very likely to need to expand the capacity of the system with large access. The expansion introduces the shunt mechanism. If the two systems share the same domain name, and the URL is not highly differentiated, it will create a significant barrier to the shunt mechanism. Although the URLs of some systems or modules (or pages) are relatively variable, changes are not possible for URLs that are open to external access, especially outside the company. This type of URL is essentially an API. This involves another theme: API design. Here's the pass.

At the logical server level, remember that read and write separation, if the system is not expected to need more than one server, you should leave a posterior reading and writing separation. Another thing to be concerned about is that different services are accessible to each other, not directly in the form of IP: ports, and as much as possible in the way of domain names. Virtual IP remediation can also be introduced if the former is used for later expansion.

At the DB level, consider whether you need to introduce caches such as Memcache or Redis. Consider whether you need to do m-s. Also, consider whether the DB layer exposes IP ports directly to the upper layers, or introduces an abstraction layer (such as virtual IP). Furthermore, when doing the design of the library table, consider whether the library should be divided into tables.

With the introduction of a multi-server architecture, data synchronization and merging issues are followed. For example, a server generates a picture that may need to be synced to a B server. or the database needs to do m-s synchronization. Need to merge, most typical is the log. If the logs are scattered across many machines, locating problems and analyzing logs can be cumbersome and require a merging mechanism. There is also a very important point, that is, the merging of the session. The same user, may first request to a server, the next request to B server, how to make the two machines can share a session, is a need to solve the problem. One solution is to use Redis to store session information.

In a multi-server architecture, dynamic scripting and static file separation is a good experience. Here the separation of the different domain names, code files placed on different machines. This is because the performance properties of dynamic scripts and static files are significantly different. Separating them allows you to use a different deployment strategy for them. For example, static files can make more efficient use of browser caching.

Availability of

Usability in this aspect, there are many overlaps with the previous place, because all involve multiple servers. The difference between them is that scalability is about whether the system can hold a large amount of traffic, and when the traffic unexpectedly increases, the system can quickly improve its processing power to respond. The question of usability is: how important is this service? If it's especially important, how do you guarantee it won't hang?

One of the most common means of improving usability is the introduction of redundant disaster preparedness measures. It also covers the links mentioned above. If you want to introduce redundancy, remember to focus on two issues: 1, single point of failure, 2, cross-room.

Single point of failure. Assume that the architecture is designed to: the front-end two Web servers, domain names through DNS resolution to both machines, logical server also two, but DB only one. So the DB link is a single point. If the DB server is hung up, the entire system will be hung out. There is no point in designing two Web servers and two logical servers in front of each other.

Then say the cross-room. Cross-room is a big challenge, unless it is necessary to avoid the use of cross-room architecture. As a rule, it is almost impossible to deploy all of our services in two locations. 99.99% This scenario occurs when you deploy a system that spans a room, and you need access to another service that is deployed only in one room. At this time, one of the rooms must be accessed through a channel to another room. In this way, two rooms are not exactly the same. In addition, two computer room data, logs and so on need to synchronize, merge. These will make operation and maintenance of the difficulty greatly improved.

In addition to redundancy, consider usability, and you should also think about monitoring measures. There are several ways to monitor. The common methods are:

1, log or data analysis. The background running process on the server, the data of log or class log is analyzed continuously, and the alarm happens when abnormal occurs.

2, the code is embedded in the monitoring of the service or interface. When you access a service with code, check its response. If the response is abnormal, the alarm.

3, heartbeat polling detection. Each time a special request is sent to the service to check its response. If the response is abnormal, the alarm.

4, server load monitoring. such as CPU, memory, hard disk, IO, number of CGI processes, and so on. In some cases the work is done by an OPS engineer.

5, the code is populated with response time statistics, and another background process to monitor the response time.

Among them, 1, 2, 4, 5 is the system internal monitoring, 3 is the system external monitoring. The internal monitoring of the system can be more detailed and can monitor something that is not externally monitored. However, if the system itself is hung up (for example, the server is hung), internal monitoring will also fail.

Scalability

This aspect involves the logical architecture of the software and is more relevant to the business. The purpose of considering extensibility is to respond to changes in requirements. This requires a more in-depth understanding of the requirements, and the ability to roughly grasp the direction of change in demand. After this, at the code structure level, leave room for the intended change direction. Designers are required to have a very rich coding experience and a deep understanding of design patterns.

Debugger-Selectable

This aspect is easy to overlook, but it is a very important link. The deployment environment and interaction processes of web systems are becoming more complex, and it is sometimes difficult to locate a line problem. The development environment is usually not reproducible, and you are not getting enough information to locate it. So this factor should be taken into account in the design of the system: how can I easily locate and debug when problems arise? Here are the sub-server and page two sections to consider.

The log does not have to be said to be an important source of information. The service side writes the log, needs the log to be effective organization (here is also a science).

In addition, the service side need to pay attention to, is a unified error code processing. Error code management Confusion can affect the location of the problem. In the best case, the error code is finely divided and guaranteed to be absolutely non-repeatable. In this way, once the development gets the error code, it can probably determine the problem.

Furthermore, the service side may need to be ready for debugging tools. Can be understood as backdoor, but only authorized to use.

The front end can not write the log is a big problem, need to find another way to get the wrong information hand. The worst way is to sacrifice some of the user experience, display the error code in some way, and then get the error code by asking the user. It is not recommended in this way. A better practice is to collect the error message at the front end and then escalate it to the server for storage via the interface.

Safety

The importance of safety cannot be overemphasized. XSS, CSRF, SQL injection, sensitive information disclosure, brush interface, replay, and so on. There are many things involved in the security field.

Data statistics and background

Consider whether the system needs background management, whether the need to collect data for statistical analysis, which will affect the design of the system. Background managers are typically granted high privileges after authorization, so the system is designed to differentiate roles. The collection of data leads to the so-called "shotgun modification" that causes the system to decay quickly.

Factors to consider before web development