分布式系统的架构思路

一、前言

在计算机领域，当单机性能达到瓶颈时，有两种方式可以解决性能问题，一是堆硬件，进一步提升配置，二是分布式，水平扩展。当然，两者都是一样的烧钱。
今天聊聊我所理解的分布式系统的架构思路。

二、分布式系统的两种方式

平时接触到的分布式系统有很多种，比如分布式文件系统，分布式数据库，分布式WebService，分布式计算等等，面向的情景不同，但分布式的思路是否是一样的呢?

1.简单的例子

假设我们有一台服务器，它可以承担1百万/秒的请求，这个请求可以的是通过http访问网页，通过tcp下载文件，jdbc执行sql，RPC调用接口…，现在我们有一条数据的请求是2百万/秒，很显然服务器hold不住了，会各种拒绝访问，甚至崩溃，宕机，怎么办呢。一台机器解决不了的问题，那就两台。所以我们加一台机器，每台承担1百万。如果请求继续增加呢，两台解决不了的问题，那就三台呗。这种方式我们称之为水平扩展。如何实现请求的平均分配便是负载均衡了。

另一个栗子，我们现在有两个数据请求，数据1 90万，数据2 80万，上面那台机器也hold不住，我们加一台机器来负载均衡一下，每台机器处理45万数据1和40万数据2，但是平分太麻烦，不如一台处理数据1，一台处理数据2，同样能解决问题，这种方式我们称之为垂直拆分。

水平扩展和垂直拆分是分布式架构的两种思路，但并不是一个二选一的问题，更多的是兼并合用。下面介绍一个实际的场景。这也是许多互联网的公司架构思路。

2.实际的例子

我此时所在的公司的计算机系统很庞大，自然是一个整的分布式系统，为了方便组织管理，公司将整个技术部按业务和平台拆分为部门，订单的，会员的，商家的等等，每个部门有自己的web服务器集群，数据库服务器集群，通过同一个网站访问的链接可能来自于不同的服务器和数据库，对网站及底层对数据库的访问被分配到了不同的服务器集群,这个便是典型的按业务做的垂直拆分，每个部门的服务器在hold不住时，会有弹性的扩展，这便是水平扩展。

在数据库层，有些表非常大，数据量在亿级，如果只是纯粹的水平的扩展并不一定最好，如果对表进行拆分，比如可以按用户id进行水平拆表，通过对id取模的方式，将用户划分到多张表中，同时这些表也可以处在不同的服务器。按业务的垂直拆库和按用户水平拆表是分布式数据库中通用的解决方案。

三、负载均衡

前面我们谈到了分布式来解决性能问题，但其附带的问题是怎么分布，即如何负载均衡。这里要解决的问题是当客户端请求时，应该让它请求分布式系统中哪一台服务器，通常的做法是通过一台中间服务器来给客服端分配目标服务器。

这里同样拿两个不同的分布式系统做说明，下图左边是分布式文件系统FastDFS,右边是一个用于分布式的RPC中间件。


FastDFS的一次文件下载请求过程是这样的
1.client询问tracker可以下载指定文件的storage；
2.tracker返回一台可用的storage；
3.client直接和storage通信完成文件下载。
其中tracker便是负载均衡服务器，storage是存储文件和处理上传下载请求的服务器。

而另一个RPC中间件Hedwig也是类似的
1.client询问zookeeper哪台server可以执行请求；
2.zookeeper返回一台可用server；
3.client直接与service完成一次RPC。
zookeeper是分布式系统中一个负载均衡框架，google的chubby的一个开源实现，是是Hadoop和Hbase的重要组件。

同样的在http中，常听说的nginx也是一个负载均衡服务器，它面向的是分布式web服务器。至于具体的负载均衡算法轮询，hash等这里就不深入了。

四、同步

分布式系统中，解决了负载均衡的问题后，另外一个问题就是数据的一致性了，这个就需要通过同步来保障。根据不同的场景和需求，同步的方式也是有选择的。

在分布式文件系统中，比如商品页面的图片，如果进行了修改，同步要求并不高，就算有数秒甚至数分钟的延迟都是可以接受的，因为一般不会产生损失性的影响，因此可以简单的通过文件修改的时间戳，隔一定时间扫描同步一次，可以牺牲一致性来提高效率。

但银行中的分布式数据库就不一样了，一丁点不同步就是无法接受的，甚至可以通过加锁等牺牲性能的方式来保障完全的一致。

在一致性算法中paxos算法是公认的最好的算法，chubby、zookeeper中paxos是它保证一致性的核心。这个算法比较难懂，我目前也没弄懂，这里就不深入了。原文链接:https://chulung.com/article/architecture-of-distributed-system