The most important technical means of the scalable architecture of the website system is to use the server cluster function to enhance the processing capability of the entire cluster by continuously adding servers to the cluster. "Extension" means that the scale of the website and the scale of the server are always expanding.
1. Scalability design of website architecture
The scalability design of a website can be divided into two categories, one is to achieve scaling based on physical separation of functions, and the other is a single function to achieve scaling through clusters. The former is that different servers deploy different services and provide different functions; the latter is that multiple servers in the cluster deploy the same service and provide related functions.
1.1 Physical separation of different functions to achieve scaling
Vertical separation: that is, separation after layering, deploying different parts of the business process separately to achieve system scalability.
Horizontal separation: that is, after dividing the business, separate and deploy different business modules to achieve system scalability.
1.2 A single function scales with the size of your cluster
When one ox can't pull the cart, don't look for a stronger cow, but use two cows to pull the cart.
Cluster scalability is further divided into application server cluster scalability and data server cluster scalability. Data server clusters can also be divided into cache data server clusters and storage data server clusters.
2. Scalability design of application server cluster
The so-called scalability of the application server means that the HTTP request distribution device can perceive or configure the number of servers in the cluster, and can timely discover the newly online or offline servers in the cluster, and can distribute requests to the newly online servers, and stop sending to offline servers. The server dispatches the request. This HTTP request distribution device is called a load balancing server.
Load balancing is an indispensable basic technical means for a website. It can not only realize the scalability of the website, but also improve the usability of the website. It can be described as one of the killers of the website. There are also various specific technical implementations, ranging from hardware implementation to software implementation, from commercial products to open source, but the basic technologies for implementing load balancing are as follows.
2.1 HTTP redirect load balancing
The HTTP redirection server is an ordinary application server, and its only function is to calculate a real server address according to the user's HTTP request, and write the real server address into the HTTP redirection response (response status 302) to return to the browser, and then the browser automatically requests the real server.
The advantage of this load balancing scheme is that it is relatively simple, but the disadvantage is that the browser needs to request the server twice each time to complete an access, and the performance is poor; using HTTP302 to respond to redirection may be judged by search engines as SEO cheating and reduce search results. ranking. The processing power of the redirect server itself may become a bottleneck. Therefore, this kind of scheme is rarely used in practice.
2.2 DNS domain name resolution load balancing
Using DNS to process domain name resolution requests while performing load balancing is another commonly used solution. Configure multiple A records in the DNS server, such as: www.mysite.com IN A 114.100.80.1, www.mysite.com IN A 114.100.80.2, www.mysite.com IN A 114.100.80.3.
Each time a domain name resolution request is made, a different IP address is calculated and returned according to the load balancing algorithm, so that multiple servers configured in the A record form a cluster and can achieve load balancing.
The advantage of DNS domain name resolution load balancing is that the load balancing work is handed over to DNS, which omits the trouble of network management. The disadvantage is that DNS may cache A records and is not controlled by the website.
In fact, large websites always partially use DNS domain name resolution as the first-level load balancing method, and then do the second-level load balancing internally.
2.3 Reverse proxy load balancing
As we have said before, reverse proxies can cache resources and improve website performance. In fact, reverse proxies can do load balancing, as shown in the figure.
Since the reverse proxy server forwards requests at the HTTP protocol level, it is also called application layer load balancing. The advantage is the simplicity of deployment, the disadvantage is the bottleneck of a likely successful system.
2.4 IP Load Balancing
IP负载均衡：即在网络层通过修改请求目标地址进行负载均衡。
用户请求数据包到达负载均衡服务器后，负载均衡服务器在操作系统内核进行获取网络数据包，根据负载均衡算法计算得到一台真实的WEB服务器地址，然后将数据包的IP地址修改为真实的WEB服务器地址，不需要通过用户进程处理。真实的WEB服务器处理完毕后，相应数据包回到负载均衡服务器，负载均衡服务器再将数据包源地址修改为自身的IP地址发送给用户浏览器。
这里的关键在于真实WEB服务器相应数据包如何返回给负载均衡服务器，一种是负载均衡服务器在修改目的IP地址的同时修改源地址，将数据包源地址改为自身的IP，即源地址转换（SNAT），另一种方案是将负载均衡服务器同时作为真实物理服务器的网关服务器，这样所有的数据都会到达负载均衡服务器。
IP负载均衡在内核进程完成数据分发，较反向代理均衡有更好的处理性能。但由于所有请求响应的数据包都需要经过负载均衡服务器，因此负载均衡的网卡带宽成为系统的瓶颈。
2.5 数据链路层负载均衡
顾名思义：数据链路层负载均衡是指在通信协议的数据链路层修改mac地址进行负载均衡，如下图：
这种数据传输方式又称作三角传输模式，负载均衡数据分发过程中不修改IP地址，只修改目的的mac地址，通过配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP地址一样，从而达到负载均衡，这种负载均衡方式又称为直接路由方式（DR）.
在上图中，用户请求到达负载均衡服务器后，负载均衡服务器将请求数据的目的mac地址修改为真是WEB服务器的mac地址，并不修改数据包目标IP地址，因此数据可以正常到达目标WEB服务器，该服务器在处理完数据后可以经过网管服务器而不是负载均衡服务器直接到达用户浏览器。
使用三角传输模式的链路层负载均衡是目前大型网站所使用的最广的一种负载均衡手段。在linux平台上最好的链路层负载均衡开源产品是LVS(linux virtual server)。
2.6 负载均衡算法
负载均衡服务器的实现可以分成两个部分：
1、根据负载均衡算法和WEB服务器列表计算得到集群中一台WEB服务器的地址；
2、将请求数据发送到改地址对应的WEB服务器上。
常用的负载均衡算法如下几种：
1、轮询：即将请求依次分发到每台应用服务器上。
2、加权轮询：根据应用服务器硬件性能情况，在轮询的基础上，安装配置的权重将请求分发到每个服务器。
3、随机：将请求随机分配到各个应用服务器。
4、最少连接：记录每个服务器正在处理的连接数，将新到的请求分发到最少连接的服务器上。
5、原地址散列：根据请求来源的IP地址进行Hash计算，得到应用服务器，这样来自同一个IP地址请求总在同一个服务器上处理。
3、分布式缓存集群的伸缩性设计
分布式缓存服务器集群中不同服务器中缓存的数据不相同，缓存访问请求不可用在缓存服务器集群中的任意一台处理，必须先找到缓存有需要数据的服务器，然后才能访问。 这个特点会严重制约分布式缓存集群的伸缩性设计，因为新上线的缓存服务器没有缓存数据，而已下线的缓存服务器还缓存着网站的许多热点数据。
分布式缓存集群伸缩性设计的最主要目标即：必须让新上线的缓存服务器对整个分布式缓存集群影响最小，也就是说新加入缓存服务器后应使整个缓存服务器集群中已经缓存的数据 尽可能还被访问到。
3.1 memcached分布式缓存集群访问模型
3.2 分布式缓存的一致性Hash算法
一致性hash算法通过一个叫做一致性hash环的数据结构实现KEY到缓存服务器的Hash映射，如下图：
如果使用上面数据结构的话，那么当新添加一台缓存服务器时，只是影响到了其中一台缓存服务器，其他两头缓存服务器的压力并没有得到缓解，因此此方案还是存在问题。 一种替代的方案就是增加一个虚拟层，即把每台缓存服务器虚拟为一组服务器（比如3个虚拟网元）平均放到上面的环里面。这样当新增加缓存服务器时，把新增加的虚拟网元平均分配 到环中，这样就能缓解每台缓存服务器，达到分布式缓存集群高伸缩性。
4、数据存储服务器集群的伸缩性设计
和缓存服务器集群的伸缩性设计不同，数据存储服务器集群的伸缩性对数据的持久性和可用性提出了更高的要求。具体来说，又可分为关系数据库集群的伸缩性设计和NoSql数据库的伸缩性设计。
4.1 关系数据库集群的伸缩性设计
主要的关系数据库都支持数据复制功能，使用这个功能可以对数据库进行简单伸缩。
另外除了利用数据库主从读写分离外，也可以利用业务分隔模式使不同业务的数据表部署在不同的数据库集群上，即俗称的数据分库。但是这种方式的制约条件时跨库不能进行join操作。
在大型网站的实际应用中，即使使用了分库和主从复制，对一些单表数据任然很大的表还需要进行分片，将一张表拆开分别存储在多个数据库中。
目前支持分布式数据分片的关系数据库产品主要有开源的Amoeba和Cobar（阿里巴巴），下图为Cobar部署模型。
Cobar是一个分布式关系数据库访问代理，介于应用服务器和数据库服务器之间。应用程序通过JDBC驱动访问Cobar集群，Cobar服务器根据SQL和分库规则分解SQL，分发到MySQL集群不同 的数据库实例上执行（每个MySQL实例都部署为主/从结构，保证数据高可用）。
Cobar系统组件模型如下图：
前端通信模块负责和应用程序通信，接搜到SQL请求（select * from users where userid in (12,22,23)）后转交给SQL解析模块，SQL解析模块解析获得SQL中的路由规则查询条件（userid in （12,22,23））再转交给 SQL路由模块，SQL路由模块根据路由规则配置（userid为偶数路由至数据库A，奇数则路由至数据库B）将应用程序提交的SQL分解成两条SQL(select * from users where userid in (12,22)；select * from users where userid in (23))转交给SQL执行代理模块，发送至数据库A和数据库B分别执行。 数据库A和数据库B的执行结果返回至SQL执行模块，通过结果合并模块将两个返回结果集合并成一个结果集，最终返回该应用程序，完成在分布式关系数据库中的一次访问请求。
Cobar的伸缩有两点：Cobar服务器集群的伸缩和MySQL服务器集群的伸缩。
Cobar服务器可以看做是无状态的应用服务器，因此其集群伸缩可以简单实用负载均衡的手段实现。而MySQL中存储着数据，要保证集群扩容后数据一致负载均衡，必须要做数据迁移，如下图（利用数据同步功能进行数据迁移）。
4.2 NoSQL数据库的伸缩设计
NoSQL主要是指非关系的、分布式的数据库设计模式。一般而言，NoSQL数据库产品都放弃了关系数据库的两大重要基础：以关系代数为基础的结构化查询语言（SQL）和事物一致性保证（ACID），而强化了高可用性和可伸缩性。目前应用最广泛的是Apache HBase。
Reprinted in: https://my.oschina.net/zhanghaiyang/blog/594137