"9 No" principle and "5 measurement dimensions" of extensible system

Building scalable systems Purpose Is to achieve scalable applications and services .

First, let's take a look at extensible applications and services “9 No ” principle .

· Don't rely entirely on local resources ： Data must be cloud enabled （ The Internet ） Storage ,Hadoop HDFS This is a good example , Three copies of data （ Two copies for different hosts in the same rack 、 Cross rack third ） To ensure high availability .

· Services should try to avoid strong dependencies ： Strong service dependency refers to when B Service depends on A, and A It directly leads to B Offline service . In the architecture design of the third platform, we should take B The service is designed to be A Is not available , Continue to provide services through other channels , For example, from CDN Or the data stored in the cache continues to provide services , To improve the user experience （ At the same time, notify in the background DevOps Team repair fault service ）.

·CDN Uselessness theory ：Content-Delivery-Network（ Content distribution acceleration network ） The biggest value of is to reduce the server 、 Network pressure and improving the user experience . Unless you build it yourself CDN The Internet , Otherwise, use existing CDN The service provider network is the best policy （ Economies of scale ）.

· Cache uselessness theory ：Caching It is another double-edged sword to accelerate the overall efficiency of the system , Good design principles will make the system get twice the result with half the effort , A bad implementation may allow users to always get expired data . In the following, we will introduce the methods of using cache correctly .

· Scale-up Instead of Scale-out：Scale-up Generally speaking, the system of is the so-called stand-alone version , Its biggest problem is that the system is offline due to system upgrade , Another problem is based on Scale-up The bottleneck of the designed system is limited by the upper limit of the hardware configuration of a single machine , Therefore, it is widely considered that scalability is worrying . Another dimension to look at this problem is ,Scale-up and Scale-out Not conflict , You can have both 、 make the old and new contrast and complement each other ！

·SPOF It's tolerable ：Single-Point-of-Failure Single point of failure . Any possible single point of failure should be avoided in the construction of scalable systems , From storage 、 The Internet 、 Calculated IaaS Layers down to the application layer should be implemented as fully as possible HA（ High availability ）.

· Statelessness and decoupling do not matter ： Statelessness is a prerequisite for decoupling architecture from services , A typical stateful service is a traditional database service , Each transaction will have multiple operations , There is a state dependency between before and after , To achieve data consistency . Stateless services do not have such strong consistency 、 Dependency requirements , Therefore, it is easier to implement distributed processing 、 parallel processing . No state + Decoupling is also the core idea of microservice architecture — The main principles for building cloud or big data services .

· Just a relational database ： The other extreme corresponding to this view is RDBMS Completely useless . Both are either or , Especially in the era of big data ,RDBMS unable to support single-handed , But no RDBMS It is also biased . Except for a few very specific applications and services, only a single database is required , For example, key value type NoSQL, Most systems require two or more databases to enrich their data processing capabilities .

· Data replication （Data Replication） Uselessness theory ： This point echoes the first , The core problem to be solved in scalable applications and infrastructure is the high availability of data 、 Extensibility , The two are mainly realized through data replication , For example, read and copy in database system （Data Replica） And Shards （Sharding） Processing technology, etc .

---

Measure the scalability of a system , It can usually be seen from the following “5 individual ” Dimension .

· load ： Load scalability is our main measure of distributed system capability , It focuses on the scalability of the system as the load increases or decreases （ elastic ）. In the first place 、 The second platform era , We expand vertically （Scale-Up） For the main way , In the era of the third platform, it is mainly horizontal expansion （Scale-Out）-- above 9 We also mentioned in the no principle ,Scale-out And Scale-up It is not the opposite , In a distributed system , It is obvious that both can be combined , In some cases , Upgrading the hardware can improve the performance and cost performance , In other cases , Increasing the number of cluster nodes through horizontal expansion can obtain more load capacity , Specific problems always need to be analyzed in detail .

· function ： The cost and convenience of realizing and providing new functions .

· Across the region ： The ability of the system to support a wide range of users and loads , for example , The ability to extend from one regional data center to another or more regional data centers to better support local loads nearby .

· management ： Security and convenience of system management , And the ability to support new customers , for example , Support for multi tenant environments , How to achieve good data security and consistency support on the same physical architecture .

· isomerism ： Heterogeneous scalability mainly refers to the support for different hardware configurations , Including system hardware upgrade , Seamless inheritance of hardware from different vendors, etc .

If from mathematics （ Algorithm ） To measure scalable systems from an angle , We usually use time complexity （Time Complexity）Big-O Notation To describe . If a system is sensitive to resources （ Calculation 、 The Internet 、 Storage, etc ） Demand and input （ The node of the service 、 Number of users, etc ） Our relationship is in line with O（log N）, Then we think the system has scalability . On the contrary, if it is O(） Or higher order relationships , Then the system has no scalability .

In the field of network , Such as routing protocol , When the router node is increased , Route list length （ Memory resources ） The relationship with the routing node is O（log N） when , That is, as the routing nodes grow , The growth of routing list slows down （ The growth curve flattens ）, Then the routing protocol has scalability .

Point to point （P2P） File sharing network （ service ） Take the development of science and technology as an example , The earliest content sharing system Napster The design architecture of is a central index server （Central Index Server） Be responsible for collecting the list of shareable files of each participating node , This design leads to a single point of failure in the system （SPOF）, It is also vulnerable to hacker attacks or legal proceedings .

In view of Napster The final legal proceedings were lost , Later Gnutella Learn from it Napster Of SPOF problem , Launched pure distributed （Fully-decentralized） Peer to peer file sharing service . At an early stage Gnutella The design of online file query of the system adopts flooding query （Flooding-Query） Pattern , That is, the file search request sent by one node will be distributed to all other nodes in the network , As a result, most queries will fail due to timeout after the entire network scale exceeds a certain scale （ This expansionary reform has avoided SPOF, However, the efficiency of the system is reduced ）. later Gnutella Adopted DHT（Dynamic Hash-Table Distributed hash table , Its design principle is that each node in the network only needs to communicate with other nodes log N Nodes interact to generate DHT Key values in the hash table , Therefore, the system can be expanded to accommodate millions of nodes ） The solution solves the problem of file query scalability .

Of course , In pure distributed P2P In the system ,DHT The problem is that query keywords only support exact matching , Fuzzy... Is not supported 、 Pattern query . This problem is in hybrid P2P The system has been solved . for example ,Skype Audio and video service system , It adopts a two-level user architecture , Super nodes + Common node , The super node is responsible for establishing the query index and routing between ordinary nodes , Ordinary nodes are the end user terminals . The picture below shows Skype The hybrid architecture of . blend P2P The architecture solves the problem of scalability in practice （ There is SPOF） The problem of , It also solves the problem of information index and query in the pure distributed system .

chart ：Skype A hybrid P2P framework 1： Super node and normal node