Large-scale website technical architecture: abstract and reading notes

 

  I spent a few nights reading the book " Technical Architecture of Large Websites ". Personally, I feel that the breadth of this book is good, but the depth is still lacking (after all, it is only about 200 pages). However, as an IT migrant worker who lacks large-scale website technology, it is still very rewarding to read it once, and at least have a comprehensive understanding of the technological evolution of a website and the problems that need to be solved. There are also some personal experiences, insights and summaries of the author in the article, which I think are very pertinent.

  A search on the Internet shows that there are still a lot of reading notes for this book, and I decided to write a reading note myself, mainly to avoid forgetting too quickly. The content of the notes is not completely in accordance with the content of the original book, and mainly records the parts that I am interested in.

  Address of this article: http://www.cnblogs.com/xybaby/p/8907880.html

The evolutionary history of a website

  The author repeatedly mentioned a point in the article: large websites are gradually evolved according to business needs, not designed .

  I have to admit that with the development of the Internet industry today, it is still very common for big fish to eat small fish. The micro-innovation ability of a large company can kill a small project in minutes, so small companies need to develop fast enough and keep fast. Iteration and trial and error.

  The following is an evolutionary process, and the picture comes from the Internet.

Website architecture at initial stage

 

  In the initial stage, the amount of access is not large, so all resources such as applications, databases, files, etc. are on one server.

Separation of application services and data services

 

  With the development of the business, it will be found that a server cannot withstand it, so the application server is separated from the data (file, database) server. The three servers have different requirements for hardware resources: application servers require faster CPUs, file servers require larger disks and bandwidth, and database servers require faster disks and larger memory. After the separation, the three servers perform their own duties, which is also convenient for targeted optimization.

Using caching to improve website performance

  "There is no problem in the world that cannot be solved by adding a first-level cache. If there is, add a first-level cache"

  The use of cache is ubiquitous, and the fundamental purpose of cache is to speed up access. When the access pressure of the database is too high, you can consider using the cache. There are two types of caches used by websites: local caches cached on application servers and remote caches cached on specialized distributed cache servers.

Improve the concurrent processing power of your website using a cluster of application servers

  

  

   With the development of business, a single application server will definitely become a bottleneck. Application server clustering is a relatively simple and mature type of website scalable cluster architecture design. As will be mentioned later, by designing the application server to be stateless (no context information to be saved), it can be scaled out by adding machines and using load balancing.

Database read and write separation

  

  Even if the cache is used, the database still needs to be accessed when the cache misses or the cache service is out of date. At this time, the read-write separation of the database is required: the main library provides write operations, and the slave library provides read services. Note that a data access module is added in the above figure, which can transparently separate the master-slave information of the database to the application layer.

Speed ​​up website response with reverse proxy and CDN

 

  CDN and reverse proxy are actually caches, the difference is that CDN is deployed in the computer room of the network provider; while the reverse proxy is deployed in the central computer room of the website. The purpose of using CDN and reverse proxy is to return data to users as much as possible, on the one hand to speed up user access speed, and on the other hand to reduce the load pressure on back-end servers.

Working with distributed file systems and distributed database systems

  

  The disk of a single physical machine is limited, and the processing capacity of a single relational database is also limited, so distributed file storage and distributed database are required. Of course, a "unified data access module" is also required, so that the application layer does not need to care about the specific location of files and data. It is worth mentioning that the relational database itself does not have a good horizontal expansion scheme, so a database proxy layer is generally required, such as cobar and mycat.

Use NoSQL and search engines

 

  Many applications of web2.0 are not necessarily suitable for relational database storage. The more flexible NoSql can solve some problems more conveniently, and NoSQL naturally supports distributed. Specialized search engines have greatly reduced the pressure on databases while providing better services.

business split

   

  Divide a website into many different applications, and each application is deployed and maintained independently. A relationship can be established between applications through a hyperlink (the navigation links on the home page each point to a different application address), and data can also be distributed through message queues. Of course, most of them are formed by accessing the same data storage system. Associated complete system

Distributed service

  

 

  Since each application system needs to perform many of the same business operations, such as user management, commodity management, etc., these shared services can be extracted and deployed independently .

   Through the distribution of services, each application can develop independently and realize the transition from dependent modules to dependent services . Separating general public services is also convenient for service management and control, such as monitoring service requests of various applications, restricting and closing access to certain applications during peak hours, etc.

Large-scale website architecture patterns and core elements

  This part is about the core problems that large websites need to solve, and the general ideas for solving these problems.

the core element

  Five Key Points: Performance, Availability, Scalability, Scalability, Security

  The author pointed out that many times people confuse scalability (Scalability) and scalability (Extensibility). I used to call Scalability extensibility, but think about it, when we talk about code quality, extensibility also refers to Extensibility, and we should just say these two English words directly in the future.

  These points will be detailed later

Website Architecture Patterns

  The definition of patterns is well described in the book:

  "Each pattern describes a recurring problem around us and the core of the solution to that problem. That way, you can use the solution again and again without having to do repetitive work." The key to the pattern is the repeatability of the pattern, and the repeatability of the problem and the scenario leads to the repeatability of the solution .

   In my own words, patterns are routines. These models are designed to achieve the core elements mentioned above. So what are the modes?

Layered

  Layering is the most common architectural pattern in enterprise application systems. It divides the system into several parts in the horizontal dimension, each part is responsible for a relatively single part, and then forms a complete system through the dependence and invocation of the upper layer on the lower layer. system.

  Hierarchical structure is also adopted in the large-scale website architecture, and the software system of the web master is divided into application layer, service layer and data layer.

  The benefits of layering are: decoupling, independent development, scalability, and extensibility. The evolutionary history of the site above also highlights the importance of layering.

  However, the layered architecture also has some challenges, that is, the layer boundaries and interfaces must be reasonably planned . During the development process, the constraints of the layered architecture must be strictly followed, and cross-layer calls (the application layer directly calls the data layer) and reverse calls (the data layer call) are prohibited. service layer, or the service layer calls the application layer).

Split

  Hierarchy emphasizes horizontal segmentation, while segmentation is vertical segmentation. The above business segmentation in the evolution history of the website includes segmentation.

  Segmentation targets highly cohesive, low-coupling modular units

distributed

  One of the main purposes of layering and partitioning is distributed deployment, but distribution also has its own problems: performance issues brought about by network communication, availability, consistency and distributed transactions, and system maintenance and management complexity.

cluster

  Problems that cannot be solved by one machine can be solved with several machines. When the service is stateless, most problems can be solved by adding machines to the cluster. Corresponds to "Using Application Server Clusters to Improve the Concurrent Processing Capability of Websites" in the History of Website Evolution

cache

  Caching is to store data in the closest location to the calculation to speed up processing and greatly reduce the pressure on data providers

  Large-scale website architecture design uses cache design in many ways: CDN, reverse proxy, local cache, distributed cache

asynchronous

  Asynchrony is an important means of decoupling, and the common producer-consumer model is an asynchronous pattern.

  Out of decoupling, asynchronous can also improve system availability, speed up response, and reduce traffic peaks

redundancy

  Redundancy is an important guarantee for system availability and an important means for data reliability

automation

  Mortals will always make mistakes of this kind and that, and those who can speak automatically should be automated. Automation has greatly liberated the productivity of programmers and operation and maintenance personnel!

  Release process automation, automated code management, automated testing, automated security detection, automated deployment, automated monitoring, automated alarms, automated failover, automated failure recovery, and automated degradation.

performance

  Olympic Spirit: Faster, Higher, Stronger

  

  The pursuit of performance by technicians is endless.

  Performance, from different angles, the measurement indicators are different:

  • User perspective: response time, optimization methods: (browser optimization, page layout, compressed files, http long links), CND, reverse proxy

  • Developer Perspective: System Latency, Throughput, Stability. Optimization means: caching, asynchronous, clustering, code optimization

  • Operational perspective: infrastructure performance resource utilization. Optimization methods: customized backbone network, customized server, virtualization

  Common metrics include: response time, throughput, concurrency. There is a good analogy in the text regarding these metrics:

  The relationship between system throughput, system concurrency, and response time can be visually understood as the traffic conditions of expressways: throughput is the number of vehicles passing through toll booths every day (which can be converted into high-speed fees charged by toll booths), and the number of concurrency is high-speed The number of moving vehicles on the road, the response time is the vehicle speed. When there are few vehicles, the speed is fast, but the high-speed toll received is correspondingly small; with the increase of the number of vehicles on the highway, the speed is slightly affected, but the high-speed fee received increases rapidly; as the vehicles continue to Increase, the speed becomes slower and slower, the highway becomes more and more congested, and the toll does not increase but decreases; if the traffic volume continues to increase, after a certain limit, any accidental factors will cause the high-speed to be completely paralyzed, the car can not move, and the toll will be reduced. Of course, it can't be closed, and the highway becomes a parking lot (resources are exhausted).

web front-end performance optimization

  Browser optimization: reduce http requests, browser caching, compression. CDN optimization, reactive proxy

Application server performance optimization

  Four tricks: caching, clustering, asynchrony, and code optimization

cache

  First of all, the cache

  The First Law of Website Performance Optimization: Prioritize using cache to optimize performance.

  When using a cache, the problem of cache replacement and consistency needs to be considered. Among them, the problem of cache consistency is also a problem that needs to be solved in a distributed system. The main solutions are lease period and version number.

  Not all occasions are suitable for caching, such as frequently modified data, data without hotspot access.

  Availability of the cache: In theory, it cannot be completely relied on, but in fact it is as highly available as possible, otherwise the database will be down and the system will be unavailable. Therefore, the cache server should also be included in the monitoring, and the availability should be as high as possible.

  Cache penetration : If a non-existent data is requested continuously and concurrently due to inappropriate business or malicious attacks, because the cache does not save the data, all requests will fall on the database, which will cause great pressure on the database. even collapsed. A simple countermeasure is to also cache non-existent data (its value is null).

Code optimization

Multithreading

  Why use multi-threading, IO blocking and multi-core CPU

  The ideal load is: that is, no processes (threads) are waiting, and no CPU is idle

  Number of startup threads = [task execution time / (task execution time - 10 wait time) J x number of CPU cores

Resource reuse

  This is very common, various pools (pool): thread pool, connection pool

High availability

  Website Annual Availability Metrics = (1- Website Unavailable Time/Total Annual Time) x 100%

  The industry usually uses N 9s to measure the availability of the system. For example, 2 9s are basically available, the annual website unavailable time is less than 88 hours; 3 9s are high availability, the website annual unavailable time is less than 9 hours; 4 9s are high availability with automatic recovery capability, the website annual Unavailable time is less than 53 minutes; 5 9s are extremely high availability, and the site is unavailable for less than 5 minutes per year.

  Usability is the lifeblood of a large website. Users can immediately perceive whether it is available or not. A short-term unavailability will also bring huge losses. This is why large websites pay more attention to A (avalibility) when faced with CAP problems.

  The main means of high-availability architecture are redundant backup and failover of data and services .

  In the layered network architecture, by ensuring the high availability of each layer, the high availability of the entire system is achieved. And each layer has its own high availability means

Application layer high availability

  Servers located at the application layer usually use a load balancing device to form a cluster of servers to provide services to the outside world in order to cope with high concurrent access requests. When the load balancing device monitors that an application server is unavailable through heartbeat detection and other means, Remove it from the cluster list and distribute the request to other available servers in the cluster, so that the entire cluster remains available, thereby achieving high application availability.

   High availability at the application layer is easy because application servers are often stateless.

  But there are also times when it is necessary to maintain data, such as sessions, so that a request cannot be routed to an arbitrary application server. To solve the problem of session, there are the following methods:

  • Session binding: implemented using the source address Hash algorithm of load balancing, the load balancing server always distributes requests from the same IP to the same server

  • Use cookies to record sessions: Cookies are stored on the client (browser), and you can bring the information in the cookie with each visit.

  • Dedicated session server: separates the state of the application server into a stateless application server and a stateful session . The simple way is to use distributed cache and database (redis) to realize the function of Session server

High availability at the service layer

  The high availability of the service layer also uses clusters, but requires the help of a distributed service invocation framework.

  The server of the service layer is accessed by the application layer through the distributed service invocation framework. The distributed service invocation framework will implement software load balancing in the client program of the application layer, and perform heartbeat detection on the server providing the service through the service registry, and find that there is a service Unavailable, immediately notify the client program to modify the service access list and remove the unavailable server.

  In order to ensure the high availability of the service layer, the following strategies can be adopted

  • Hierarchical management

  • timeout setting

  • Asynchronous call

  • Service degradation, including: denial of service, peak hours, denial of access to low-priority applications; shutting down services, turning off certain unimportant functions

  • Idempotent design, easy to retry on failure

High availability of the data layer

  Including distributed file systems and distributed databases, the core is redundancy plus failover.

  The core problem that redundancy (replication set, replica) needs to solve is the consistency problem

  The failover operation consists of three parts: failover confirmation, access transfer, and data recovery.

  

  The two methods of failure confirmation are described above: the control center detects the survivability of the storage server through heartbeat; the application notifies the control center to check the survivability of the storage service when it fails to access the storage service

Scalability

  The scalability of the website means that the service processing capacity of the website can be expanded or reduced by only changing the number of deployed servers without changing the software and hardware design of the website.

Application Layer Scalability

  By designing the application layer to be stateless, clustering + load balancing can be used to solve the scalability problem.

  Regarding load balancing, I also wrote an article "Everything About Load Balancing: Summary and Thinking" before .

Cache scalability

  First of all, the cache is stateful. The data cached in different servers in the distributed cache server cluster is different. The cache access request cannot be processed by any one of the cache server clusters. The server that has the required data in the cache must be found first. then access.

  If the cache access is routed to a server that does not cache related data, the access request will land on the database, increasing the pressure on the database. Therefore, the newly launched cache server must have the least impact on the entire distributed cache cluster, that is, the higher the cache hit rate, the better.

  In this scenario, the best load balancing algorithm is consistent hashing

Data Layer Scalability

  A relational database that relies on a distributed database proxy. NoSQL database products have abandoned two important foundations of relational databases: Structured Query Language (SQL) based on relational algebra and Transaction Consistency Guarantee (ACLD). And to enhance some other features that larger websites are more concerned about: high availability and scalability.

 

  Scalability summary: A website with a good scalability architecture design is always ahead of business development. It is fully prepared before the business needs to handle more visits and services. When the business needs it, it only needs to You can simply deploy and implement by purchasing or renting a server.

Extensibility

  The core idea of ​​designing the scalable architecture of the website is modularization, and on this basis, the coupling between modules is reduced and the reusability of modules is improved.

  There are mainly distributed message queues and distributed services.

  Distributed message queues decompose system coupling through message objects, and different subsystems process the same message.

  Distributed services decompose system composition through interfaces, and different subsystems make service calls through the same interface description.

Distributed service

  Vertical splitting: Split a large application into multiple small applications. If the newly added business is relatively independent, then directly design and deploy it as an independent Web application system.

  Horizontal splitting: Split the reused business and deploy it as a distributed service independently. The new business only needs to call these distributed services without relying on specific module codes, and an application system can be quickly built. When the business logic changes, as long as the interface remains consistent, the business program and other modules will not be affected.

  Distributed services rely on a distributed service governance framework

Distributed Service Governance Framework

  There is very little contact in this area, and it takes some time to study and learn

  

 

  Functions and features of the service governance framework:

  • Service registration and discovery

  • service call

  • load balancing

  • Failover: The distributed service framework supports the failover mechanism of service providers. When a service instance is unavailable, access is switched to other service instances to achieve overall high availability of services.

  • Efficient remote communication

  • Integrate heterogeneous systems

  • Minimal intrusion into applications

  • Version management: The distributed service framework needs to support the release of multiple versions of the service. The service provider first upgrades the interface to release the new version of the service, and also provides the old version of the service for the requester to call. The old version can be closed only after the requester calls the interface to upgrade. Serve.

  • real time monitoring

 Others

  The so-called problem is the experience-expectation. When the experience fails to meet the expectation, it will feel that there is a problem. There are two ways to eliminate the problem: improve the experience or reduce expectations.

  The problem is discovered, it is only the problem of the problem finder, not the problem of the problem owner. If you want to solve a problem, you must ask the problem and let the problem owner know that the problem exists.

     Ask questions Tips:

1. Express "my problem" as "our problem"
2. Ask closed-ended questions to your boss and open-ended questions to your subordinates
3. Point out the problem instead of criticizing the person
4. Ask the question in an agreeable way -- "No Say you have a problem here, but say, the plan is good, I have a little doubt (suggestion)

 

 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326543850&siteId=291194637