"Opening restaurants and making software"--a debate on architecture

"Opening restaurants and making software"--a debate on architecture

Chandler:
In fact, the software architecture is not the so-called right and wrong points, only is not suitable for the points, in fact, the essence of architecture is layering, but there are costs, layering must have the cost of communication (of course, there are benefits, such as reducing coupling, improve expansion, etc.), sometimes, from different angles, there will be different conclusions: performance, scalability, usability, Ease of use, security, a framework can not meet all the requirements, the key is our choice, in addition, is how to better adapt to different changes, this and we make software design is the same as the truth. In addition, in fact, the product architecture is also subject to a lot of technical aspects of the impact, such as the company's strategy, management requirements, real development constraints, and even the preferences of corporate decision-makers, in addition, on the distributed large-scale software architecture, there are many factors to consider, such as clustering, high availability, high-performance, etc., In fact, I personally appreciate the architecture similar to ebay, application layer horizontal and vertical split, application layer stateless, database horizontal and vertical segmentation.

Dreamcode:
Chandler Thank you very much for your reply, your architecture should consider the management of factors that give me great inspiration, benefit, architecture design can be a variety of principles must adhere to, but some superficial phenomenon will let us waver. Large-scale network architecture often shows a short board effect, when the traffic is less, the short board in the system itself, such as communication between modules, data access and so on, we can reduce communication, data caching and other methods, but once the real traffic is very large, when the short board in the processing of access to request the ability, We know that a lot of hackers are causing the target host to crash by making a lot of access requests, so we have to do this by splitting, first of all ensuring system stability, when one of the modules crashes, the rest of the system can continue to operate, when the crash module is repaired can quickly connect with the system, without the need to restart the entire system, At the same time through the horizontal expansion of the server, the table, the library and other methods to improve the ability to handle access requests. Finding that short board is the key to improving the performance of the system, or product development is driven by "real" issues and requirements, rather than advanced methods or concepts. I've mentioned five stages of architecture design, which are driven by problems, from simplicity to complexity, it's not that the last stage is the best, but because when the restaurant is at that stage we have to do this, so are we really at that stage of the problem that we face at that stage? Or is this just our ideal.

Chandler:
As for the evolution of software architecture, there are a lot of evolutionary experiences in software architecture that we can refer to, such as the example of ebay, and the example of a restaurant you're talking about. My view is that, first of all, it is meaningful for us to understand the experience of others, because it is a valuable asset that can help us run a lot less detours, but that's not to say we can skip all the steps to get to the final step, because it's someone else's experience that doesn't suit us because the software industry has no silver bullets, We cannot expect certain technologies to solve all our problems. The second is that we lose our evolutionary experience, and it seems to me that the lessons of the growth process are always more important than the conclusions that come directly. In addition, I think, reality is always our first consideration, such as the concept of "millions", as you said, our server must be a growth, if only to emphasize the long-term ideal, it is possible to short-term goals (such as cost) can not be achieved. However, if we do not target the architecture, then when the scale is increased to such a scale, the problems we face need to be overcome at great cost and even lead to the redesign of the software. All in all, the focus of the different periods may not be the same, so the architecture of the software will take these questions into account and provide a way to adapt to these changes, so this evolutionary process I feel is inevitable. But, after all, reality is the most important problem to solve, so we still have to solve the real problem, but we must be ready for what will happen. "The pattern decides the outcome, the attitude decides the height", puts to the software structure I thought also has the reason.

Welcome to join our discussion.


Opening a restaurant and doing software in the original:

When I was at school, I had the urge to open a restaurant, and bought a very thick book, called "How to open a restaurant." Later made the software, the recent renovation of the house this impulse came again, rummaging through to find this book looked at but think this is a teach how to do a large web site a rare martial arts tips.

A meal tube from small to big can be divided into the following steps, the restaurant in the larger and more customers can accommodate more and more, the efficiency of the meal tube more and more quickly.

First of all, starting a restaurant from scratch is naturally not rich and cannot afford a big storefront, when the kitchen and restaurant are crammed into a room, a chef and a man. Our first idea was to expand the store to move the kitchen out of the way and hire another man, because we had a unique taste that attracted a large number of customers and the customer had to wait in line at the peak. That is, our first step into the performance of the site-the application and database separation, the site's application (the equivalent of restaurants and buddies) and the database (equivalent to kitchen and chef) deployed separately in different servers, to avoid the contention of hardware resources.

This time the store expands, the customer does not have to wait in line waiting, all can enter the dining room. The expansion of the kitchen and restaurant area allows the chef and the man to take the usual tools out of the cupboard and put them on the obvious, ready to be used, so that the efficiency of the work is significantly improved. That is, we enter the second step of the performance of the site-data caching (including page, page fragment cache), the common data from the database, put in memory, improve access speed, reduce database connection.

Efficiency has improved, Word-of-mouth is also better, more and more natural customers. Because we have a limited staff, so many customer needs (such as ordering, paying, etc.) have to wait for some time, so we decided to increase the chef and the man to deal with more customer requests. That's the third step in the performance improvement of our website-horizontally extending the application server and database server (that is, database cluster or sub-Library). By increasing application servers and database servers, sharing more applications and data requests, load Balancing tool support is required to distribute access evenly across multiple application servers.

With the further increase of customers, a very real problem arises, in order to deal with more customers we have purchased a large number of tableware and other essential items, originally because the number of these items are made by the chef and the man at random access, goods storage is very confusing, due to limited space everyone into and out also very crowded, As a result, the use of these items took up a lot of time, and eventually we decided to classify them further and store them separately, with the person responsible for accessing the items, adding new windows and storing and taking them in different windows. That is, our fourth step to improve the performance of the website----the establishment of data access layer (DAL) and data read and write separation, general MySQL, the fastest storage engine MyISAM, it is based on table locking, that is, if a lock, then the entire data file outside the access, must wait until the previous operation is completed, In order to receive the next operation, so we can further decompose the larger data table, that is, by way of the table, reduce congestion to improve the efficiency of database access, the table caused some applications have to consider the table rules, the database access program complexity increased, These table rules can be uniformly processed by establishing a unified data access Layer (DAL). Using data read/write separation technology, the data read and written in different database server, which requires a program-level synchronization program support, but also to the aforementioned Dal layer to transform.

As a restaurant is large enough to become a catering group, the original small restaurant management method obviously does not work, at this time we need to divide according to function, such as the establishment of independent financial department, for the simple application of such an independent department may rather reduce the efficiency, However, for the complex application of this division is necessary for both efficiency and stability, that is, we enter the Web site performance improvement of the fifth step-large distributed applications. In fact, the essence of architecture is layering, but a clear demand after layering is a highly efficient and stable communication framework, and how this architecture is designed is a problem we face.

This article is inspired by the "programmer" November 2008 issue of the "large-scale Web site architecture and Knowledge system" article, the method proposed in this paper also stems from this article, this article also proposed the implementation of these methods, interested friends can look.