I have been engaged in server-side development for some days. When I calm down, I can think about and record some server-side development ideas.
Server-side development, especially web development, is basically all about processing HTTP requests. It is divided into two types according to specific uses: Web page development and API interface development. Web page development can also be regarded as API interface development, but it has two main parts, the page and the ajax request. One is to return html, and the other can return html or other formats. API interface development is for client products. It may be a mobile device, it may be a PC application, etc.
Application framework
The application framework generally uses LNMP or LAMP. The basic framework is the front-end N Web server machines + cgi access to PHP + php access to mysql.
PHP can be regarded as a large-scale Web framework written in C. Its advantage is that it is interpreted and can be modified and updated in real time. Therefore, the cost of online code update and maintenance is extremely low, and in addition, it has some functions that are almost specially customized for web development, so it is suitable for web development. Compared with developing web services in Java, the pain of needing to be recompiled every now and then is enough.
Web servers are now using nginx more and more. The advantages of nginx over apache are its portability and high concurrency performance of static pages. Generally, when you get the equipment, you first need to consider the approximate QPS that a single machine can bear. The method is generally to only consider the memory first, and calculate how many php-cgi can be opened at the same time. For example, in a machine with 4G memory, each php-fpm takes up about 20M of memory. , so almost 200 php-cgi processes can be opened (usually some are left free). Each process can only run one php program at the same time, so assuming that each php program runs for 0.1s, 10 requests can be processed in 1s. , so the single-machine qps will be about 2000. Of course, it is generally not turned on to such an extreme level. There are several reasons:
1 You need to consider the memory usage of other processes
2 Considering that once all the memory is used up, Whether to enable swap, if not, will the machine crash immediately?
3 You also need to consider the usage of CPU and bandwidth. CPU operations such as encryption, decryption, and video transcoding are time-consuming. If the queue is not used at this time, the time of each request will be lengthened.
File Server
Generally requires the file server and web server to be separated. Separation means using different domain names for splitting. Of course, the web server can also be used as a file server, but because the file server needs to upload files, and uploading files is a very time-consuming task, that is, a PHP program needs to stay for a long time, so they need to be separated. On the one hand, it can facilitate the expansion of the file server in the future, and on the other hand, the file service will not affect the normal web service.
Judging from the reasons for splitting the file server, some interfaces that take up resources or are called particularly frequently during operation can or should be considered to be split onto different machines.
Web front-end machines always need to access persistent data, and mysql is the most frequently used. In fact, all web services are basically operations of adding, deleting, modifying and checking the database. When it comes to performance, the performance of the database's add, delete, modify, and query operations actually determines everything. Therefore, the creation of database tables and the use of indexes are particularly important for a website. The few MySQL techniques that I find most useful are:
1 Covering index. It is to find a way to create an index so that the query operation only checks the index and not the table. Creating appropriate indexes and queries that can find data only in the index can improve efficiency.
2 It is best to use auto-increment keys in InnoDB tables to improve the efficiency of insertion operations.
3 Is it better to use varchar or char for the storage format of string type variables? There was once a project table design that changed the database size from char to varchar, and the size difference of the database reached 70G and 20G...
4 When building a table, you need to consider the future sharding of databases and tables. If sharding is used, what is the sharding key? Do you need a reverse lookup table?
5 Even when considering the distribution of databases and web machines in computer rooms, this design becomes even more troublesome...
The table creation process of mysql has a lot to do with demand. Without clear requirements, the table design must be incorrect.
Database support may not be enough, so the first thing that comes to mind may be caching. Is the cache using global cache? Put it on the web front-end machine? What hash algorithm needs to be used? What cache to use? memcache? redis? Mysql also has its own cache. How can I query to better hit this cache? When the data is updated, is the data in the cache dirty? How to update data?
Web page development
When you need to build a website, the first thing to consider is how many users will it have? Making an SNS website and making an operation backend website are two completely different concepts.
First of all, in terms of page pressure, the qps of an SNS website may be in the thousands or tens of thousands, while the operation backend pressure can almost be calculated without calculation. This means that the back-end database support is different. SNS websites may most often call interfaces for friend relationships and personal information. Do such interfaces need to be handled independently? Many such requests will be repeated. Should you consider using middleware or caching to reduce the direct pressure on the database? Operational data can generally be solved using a single table. Personally, I feel that the statistical requirements in operations are the most difficult to accomplish. First of all, statistics cannot satisfy any statistical requirements. This need is related to product discussion requirements. Secondly, statistics generally require the use of access logs and the like, which may involve many shell scripts.
API Development
In fact, compared to web development, API development is passive. This means that the client may be a mobile phone product or a PC product. There are often releases and versions. This means that the API interface cannot update the code at any time like the Web. It requires more consideration of compatibility issues between various versions. Compatibility issues will largely become additions, never subtractions. Personally, I feel that if you meet the needs without restraint, as the number of versions increases, your code will have more and more if elses. In the end, your code will not be maintainable at all. Then someone else will take over your work, step into the trap, refactor while scolding... API development relies most on testing. Often only testers make small changes to each version, and there are countless small features.
Consider the non-functional support:
You may need to keep statistics on API call times, so that you can understand how your interface performs.
Your code may also use services on other machines, such as curling another service. In this case, it is best to consider error handling and logging.
For interface services with monetary transactions, log processing is even more essential.
For some internal errors, it is best not to directly throw them to the user, so it is best to use a whitelist error mechanism.
The encryption method of the interface generally requires at least a signature mechanism. Considering the encryption methods, there are roughly several types: symmetric encryption and asymmetric encryption. When encrypting, you need to consider some circumstances, such as the power consumption of the mobile client.
If you are developing an interface for mobile phones, you need to consider traffic issues and image specifications.
The framework will always change. Not to mention changes in demand, just in terms of changes in the number of users, the frameworks for 200,000 users and 1,000,000 users must be different. At the beginning, you couldn't design a framework based on 1,000,000 users for 200,000 people to use. Therefore, a good server-side framework must undergo several major changes as the number of users changes.
…
Postscript
I wrote this article wherever I thought of it, and I found that I couldn’t continue writing it... In short, web service development There are still a lot of tricks and little things. Some pits need to be stepped on before you know the pain. What’s cute is that I’m still going through the pits...
In addition, interface refactoring is something that almost every server developer must experience. Compared with developing a new system, the difficulty of interface reconstruction can be said to be extremely difficult. Of course, the difficulty here can also be understood as the degree of discomfort...it will also be a very training job. For refactoring, testing is particularly important. How to have a good test set to ensure the correctness of your refactoring is difficult.