Introduction to the Enode Framework: a framework for physical deployment ideas

In the last article, it introduces the overall goal of the Enode framework, and how to realize the idea of high throughput, low latency, high availability and no single point problem. In this article, we'll analyze some other issues that need to be considered. I found it very tiring to write articles, time-consuming and brain, but I will stick to it. This article mainly analyzes the physical deployment of the Enode framework:

The physical deployment idea of the Enode framework: Clustered Web sites + distributed caching and storage

Cluster concept: Many machines do the same business, external as a machine in doing things like, the cluster of any machine hanging without effect, because the other machines are still working; the design of the data to be accessed by the cluster machine, I think there are generally two kinds of ideas:

Each machine in the cluster uses its own data. Data consistency is achieved by synchronizing data between each machine, and the main challenge is the inconsistency of data synchronization delays, but the advantage is that because there is no shared data, a machine hangs completely without any impact on the entire system. Because such a design is equivalent to completely at the same time by a lot of independent and do not share any data machine at the same time work, of course, is the most disaster-tolerant;

There is a machine that holds the shared data of the data, and each machine in the cluster accesses the shared data. The advantage of this design is that the data is not synchronized and no data latency is associated with data inconsistency, but the downside is that there is a single point of failure, in case the server sharing the data is not in trouble. Fortunately, there are a lot of open source mature distributed cache and distributed storage products, such as memcached, Redis These are distributed cache, can effectively avoid the problem of single point of failure, although a single memcached server will affect the part of the data read and write, but is at least not going to bring the whole system to a dead end; the same can be done with distributed storage such as MongoDB. These two products, in the distributed deployment aspect I have not any practical experience, usually does not have encountered in the work, therefore also needs to have the good study and the practice in the future.

The concept of distributed: a business is done at different physical points, such as Web server (processing UI logic), Application Server (processing business logic), these two nodes are deployed on different machines, together to complete a business; The distributed feature is that each node can not be hung, otherwise the business can not be completed; , we can do cluster processing for each node in the distributed system, which can reduce the single node fault of distributed systems, but because distributed to complete a business, the internal to boast network communication such as calling remote services, so performance is certainly less than the design does not invoke remote services. Generally we do not use distributed, distributed are forced, such as the following circumstances, we may adopt a distributed design:

A system, there are several large business, each other more independent, in order to allow each piece of business can be independently designed and developed, we will separate these different business modules design and implementation, such as an E-commerce site trading center and Commodity Center, can be independently designed;

The amount of data is too large, there is no way to store at a point, so you can only separate storage; In this case, we usually put data partitions, different partitions of data at different points, such as the database of the library, and some distributed caching such as memcached, Redis, as well as mongodb such a branch A document-type database with distributed storage;

A system, different levels using completely different technology implementations, for example, because of historical reasons, we have to change a system, but the business logic of this system is very complex, and are written in C + +, we do not dare to move, but we want to be able to redesign the system on the UI to bring a better user experience, For example, the original is written in C + + interface, now hope that through WPF this more advanced and more dazzling development of maintenance costs more dazzling technology to achieve. Then we will use different languages and technologies in the same system. In this case, we may need to expose the business logic implemented by C + + to the remote service, such as through WCF exposure, the WCF remote service itself can be written by C #, then C # calls managed C + +, and then managed C + + calls unmanaged C + +. To achieve the remote service exposure of the business logic, and at the UI layer, we can implement it in a C#+WPF way, and then the UI layer invokes the WCF remote service. This architecture is because of the different levels of a system that require a distributed situation because of the use of completely different technologies.