We often see analysis of large-scale, high-traffic, high-performance website architecture on some technical sites Design articles basically satisfy people's curiosity, but the actual benefits after reading them may not be great. Because most people may not have many opportunities to be exposed to this kind of opportunity. Even if you come into contact with it, the actual situation you encounter is often different from the many articles you have read.
In addition, a side effect of reading too many articles like this is that it can easily make people excited and make them learn to run before they learn to walk. As a result, many people over-design, over-extend, and do things prematurely when many conditions are not met. Thinking about some unnecessary issues often leads to the opposite of what you want.
Today’s article mainly discusses how to design and develop small-scale, low-performance, low-traffic websites.
If the site may be a machine or a space in its initial stage (such as www.phpernote.com, a site with less than 5,000 daily IPs), at this time, we should pay attention to data splitting and load balancing. These are all things that have no shadow. The experience of many large sites must not be copied. It is the last word to look at the problem dialectically based on the actual situation.
Embrace familiar technology
When building a website, don’t go around asking others what to use and what you are familiar with. If you use technical means that you are not good at to write a website, by the time you finish writing, the day lily may be cold. So, if there are ready-made software components available, don’t reinvent the wheel yourself. People say that Python is awesome, but they only know PHP, so PHP is fine. If you are only familiar with .net, that’s not bad either. It is not shameful to use bad technology, it is shameful to use good technology badly.
Clarity of architecture levels
The level of the architecture should be clearly determined in the initial stage. If they are all mixed together, once the business expands, it will be very painful if the original pile of things cannot be separated.
Web Server (AppServer)Cache(eg. Memcached)DB
One manifestation of the clarity of the hierarchy is (taking the LAMP architecture as an example): even if there is only one machine, an instance of Memcached should be set up. The effect is indeed very good. I don’t tell ordinary people not to put everything on the DB. All the I/O pressure of the DB goes to the disk, and problems will be exposed very quickly. Yes, DB itself will also use its own Cache, but the design starting points of DB's Cache and Memcached are different after all.
How to correctly view data redundancy
Many people are not experts in database design. If a project requires them to design a table structure or something, they will basically do it temporarily. However, many people remember the three paradigms quite well. This is what most small Web sites encounter. It’s a headache. I have dozens of watches for a small project. Forget about this paradigm thing!
Remember, make as much redundant data as possible. Disk space is not expensive now, but time is always much more expensive than space. The more time you spend mired in the data layer, the less you will invest in the product. What users care more about is the design of the product.
Front-end optimization is important
Because the traffic is low, there may not be many visitors. At this time, it is worth noting that the page should not be too large. Most sites with low traffic suffer because a page can easily be several megabytes (I saw a Startup homepage two days ago that was 4 megabytes in size). (It’s so big, it’s astonishing). Users can’t even open a page after looking at it for half a minute. How do you think it will develop? First meet the basic conditions, and then study front-end optimization.
Be cautious when adding functions
Isn’t there an 80/20 principle? Put your most important energy where it can bring you the most business value. Some fancy features bring a lot of expense, but have little effect. Remember, for a small site, the most valuable thing is the business model, not how awesome your technology is. Technology serves the business, don't show off your skills.
Some websites keep adding features, which turns these new features into the straw that breaks them.
Think about performance from the beginning
This is optional, but important. Profile should be considered at the beginning when designing the application. Whether an application can be effectively optimized and expanded in the later stage is largely limited by whether there is a more appropriate Profile mechanism. What needs to be added is that when considering performance, relevant historical data must be taken into account.
Good architecture is not designed
This is the last point to add. Good architecture has something to do with the initial design, but the most important thing is the evolution in development:
Development-->Discover problems-->Feedback-->Problem-solving (execution)--> Improve->Evolve to the next stage--New problems emerge (cycle)
Some sites stop moving forward at a certain stage, and may be stuck in execution. After feedback from users comes in, there is no driving force to make improvements. In the end, the dead pig is not afraid of being scalded by boiling water. What I'm most afraid of hearing is the excuse that "the business doesn't allow it." Just imagine if the business is gone if you don't improve it, will the business still be allowed? In fact, it's a psychological barrier.
This article has a strong copycat style, so don’t take it too seriously. If you are building some copycat website in a short, flat, and fast way, you can refer to the points that are beneficial to you. If you disagree, you can just ignore it. There is no need to leave a message to argue.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
