系统设计-后台系统的伸缩性

1、软件分层

分层思想很普及，把数据流拆成几段，比如接入层（load balancer+webserver），应用服务层（platformserver），数据存储层（数据库database、nosql）。

2、伸缩性定义

一种设计目标，使得系统通过加硬件（堆机器）能够解决各种业务问题，不存在性能瓶颈问题。比如微信红包，接入层、plaform层、数据存储层的数据通道是否够宽，扛得住上亿人同时在线的请求速度p>

2.1 接入层（loadbalancer + webserver）

请参考一个客户端请求到后台的流程：tcp-ip 7层 络通信、负载均衡、API层、数据库中负载均衡部分的内容

（loadbalancer≈haproxy） + （webserver≈nginx）

haproxy+nginx 增加带宽容量的对策：加更多域名、更多转发机器

负载均衡在有状态情况下，怎么去堆转发机器用户uid=a的所有请求必须转发到某个服务器b上。请参考一致性hash

2.2 Platform层

单例：某个程序，一个时刻所有请求都打到一台机器上，由于一台机器cpu/内存有限，会导致单例性能瓶颈。比如设计了一个请求计数器，让所有请求都得经过这个机器上这个进程，在内存里+1，最后得到结果。

正确做法如下：

（1）各个机器分别计数，然后查询的时候查各个机器结果相加，尽量做分布式（让请求均匀打在各个分布式机器上），避免单例。

（2）尽量只用这一层算，不要用这一层来存具体的数据结果，存数据的话，送到下一层的专门的数据存储层。原因是：业务层的处理逻辑比较多，如果要是再用来维护数据的话，一方面很累，另一方面是数据存储层会有通用的数据接口来存各种各样的数据，没必要用这层来存。存储计算分离，存储统一，计算多样。

2.3 数据存储层

做后台一般不会专门让设计存储层，有很多现成的模型。请参考一个客户端请求到后台的流程：tcp-ip 7层 络通信、负载均衡、API层、数据库中数据库部分的内容。

（1）读写分离，增加读实例。 

读写分离来确保写和读效率都很高。写数据因为要确保数据不丢失，所以要写入硬盘，机械硬盘有一个摆臂，只适合采用log（尾部能添加的文件）的方式顺序写，摆臂不需要来回移动，速度最快。读数据需要随机读，硬盘访问数据比较慢，摆臂来回移动效率低。实际上这里面有三个进程：log方式顺序写，key-value方式随机读，把顺序写转化为随机读（log格式转为key-value格式）。

增加读实例：实际应用中，往往有很多场景，写数据次数很少，读数据次数很多。比如说写博客只需要写一次，但有可能同时有很多人在读博客。

（2）拆分：拆库和拆表

redis这种非关系型数据库相对来说好做伸缩，可以对key做哈希，分片到某一台机器上。

关系型就比较难做伸缩，俗称分库（竖直拆分）分表（水平拆分）：

• 把库拆成多个库（每个库有自己的master/slaves机器集群），一个库里面有很多细小的业务，按照每个小业务来拆。

• 把表拆成多个表，原本只需要查一张表，现在需要查10张表，而且有的表是不能拆的。

每个库里的小业务可以拆到不同机器上。但是一个表拆开的不同表必须放在同一台机器上，因此拆库比拆表性能好点。