Design of Distributed System architecture

a complete e-commerce system, divided into front-end trading system and background operating system, front and back of the common library is a traditional enterprise in the design of e-commerce projects a common practice. But this has caused a lot of trouble on the line. At the peak of the foreground trading system, the database itself is already under a lot of pressure, if the background job system produces large-scale query or write requests, it is easy to cause the database can not respond. We found in many customer cases, if the front and back of the common pool, normal non-peak conditions, the number of daily orders only to more than A single, there will be different degrees of interference between the front and back, the database becomes the main bottleneck. At this point, the customer had to stop in the system at the peak of the operation of the operating system, which caused great harm to the business, delivery delay, customer service level decline, statistical inaccuracies and other conditions became commonplace. In fact, from the architecture, the front-end trading system and the background operating system service user objects, the former is the consumer, the latter is the enterprise internal staff, can be completely separated from the system, the use of Message Queuing between the asynchronous order transmission, in order to isolate the impact of each other.

Of course, for trading systems, we also need to conduct distributed design according to business characteristics, improve business scalability, and deal with high loads. For example, the commodity shelf system, membership system, core trading system, capital system, log system and so on high cohesion, low coupling principle to separate, according to different access characteristics to optimize.

based on the CAP theory of the distributed architecture ,consistency(consistency), availability (availability) and Partition tolerance (partition tolerance) can only meet up to two points at a time. for a peak system, the distributed (partitioned) design is inevitable and usability is the underlying requirement, so we can only abandon conformance requirements and achieve eventual consistency. However, in the architecture design of an e-commerce system, the most likely problem is the misuse CAPprinciples. For example, in the process of trading, the back-end supply Capacity (inventory) is crucial, in the transaction generation process must ensure strict consistency, rather than final consistency, which requires us to resolve in a transactional manner. Otherwise, although it is easy to achieve the goal of peak access in architectural practice, it is inevitable that the phenomenon of oversold and other harmful business will occur.

in the design of distributed system, we must adopt the Service Oriented architecture (SOA). But there are a few points to note in the design. First, in peak systems, the transmission of every extra byte means a significant overhead on the system, with a daily +millionPVas an example, suppose this is the service that each request calls, and each new byte adds a new10MBof traffic. Second, do not directly use their own enterprise internalITthe service that was originally deployed. This is because the company's internalSOAservices are not designed for the Internet peak system. We used to have a client that uses the intranet on the e-commerce websiteITThe Customer authentication service, which appears to be just a simple query, results in a direct crash of the service, causing the entire internalIT SOAsystem of the offline, the impact on the internal system for several days to be eliminated, let alone the impact on the online system, seriously hurt the image of the enterprise. Third, the principle of power. Assuming that all service invocations are unreliable, retry is the norm, so for duplicateAPIThe write operation should be re-processed.

Design of Distributed System architecture