This is the 18th day of my participation in the August Challenge
Remember at the beginning of their began to develop software is essentially a single application, just in the code module development, according to the MVC pattern is divided into the presentation layer, business layer and persistence layer, and then to write data into the database, are basically the following graph model, the presentation layer is responsible for rendering the HTML page, and the front-end interface interaction, The business layer handles the data logic processing, while the persistence layer writes data to the database and the DB persists data. This is the classic MVC pattern, which is still in use today, but a few days ago when I started working, I was able to develop CRUD and then package it into a WAR and run it in Tomcat (oh, no, When I worked as an intern at that time did is c #, then use the IIS server, ah, have to ridicule the IIS really difficult, to learn skills may be myself not jing, with each deployment to IIS is a painful experience, then turn yourself off doing JAVA development), overall a website is basically a single application, have thrown all the code in a project, Sometimes changes a little function, want to move the whole body, see other people’s code that is the true pain, remember oneself read an online education program code, is written with c #, pack out online lib is about 1 G, interaction with the database using stored procedures to write, some of the stored procedure has more than 1000 lines, There are about 400 tables, that is really a pain ah, well not to pull, continue today’s main body, talk about architecture related things.
In accordance with the MVC pattern development after the completion of the above, throw, to online resources abundant, the database with the server to deploy alone, not enough and the application and the database resources to deploy to a machine, fundamental don’t consider what the high availability data traffic problem, those are floating clouds, as long as the normal function is right.
Next, I will use the familiar e-commerce website to show how I have changed my thinking about software development architecture over the years. First of all, THE following evolution path only represents my own changes and opinions about software development architecture. If you don’t like it, please do not comment on it. E-commerce involves a lot of modules, so it only uses the user module, commodity module and order module as a breakthrough point for analysis.
In the earliest days, it was basically a single application, with all modules in one project and relatively single structure.
Must have looked at the above structure, basically everyone came up from this stage, after all, practice is the sole criterion for testing truth, follower website users keep up more, big up traffic at this time, everything on a single server, every server in high load operation, the CPU turn fast, At this time you need to take out the database, a separate server to deploy.
Will be deployed to another server, database alone so can hold out again, but not for long, suddenly one day suddenly database server is down, part of trading data lost, helpless pain through several overnight finally will be lost from the log data back, later found the MySQL with master-slave architecture on the Internet, decisive arrangement.
For the database storage scheme is actually evolved step by step, here is not detailed, behind the special article to talk about the evolution of storage scheme. With the increase of business volume, the business server and can not support, the traffic is large, a peak will appear stuck, slow response, serious time will also occur OOM, found a good thing on the Internet, Nginx used to do the load, quickly expand the business server, with more than one to respond to the client request.
Before Nginx is scheduled, the overall project needs to do this. The most typical problem is Session synchronization, which will be covered in the next article. Behind along with the expansion of the company, recruit people more and more, for this kind of monomer project maintenance cost is higher and higher, with the rise of the service to the back of the long development, and framework of Dubbo, began to monomer break up of the project, between different modules are split into different systems, each module of the database also split out. Then pay attention to high availability, basically every component with high availability to ensure.
Look at the figure feel this thing is less, in fact this is a general designation, basically every point high availability can be achieved, but now have a very mature, with the rise of K8s + Docker, each point can be dynamically according to the traffic capacity, the real realization of high availability, the architecture of the picture above is more detailed, Here is just a review of the changes in the project architecture that I have been exposed to in the past six years. Many details have not been drawn.
In fact, the improvement of these programs is the result of the older generation. Now we are just standing on the shoulders of giants.