需要按照功能点把系统拆分,拆分成独立的功能。单独为某一个节点添加服务器。需要系统之间配合才能完成整个业务逻辑。叫做分布式。多个子系统相互协作才能完成业务流程。系统之间需要进行通信。
分布式系统的两种方式:
平时接触到的分布式系统有很多种,比如分布式文件系统,分布式数据库,分布式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等这里就不深入了。
分布式架构的优势: 互联网应用的特点是:高并发,海量数据。互联网应用的用户数是没有上限的(取决于其开放特性),这也是和传统应用的本质区别。高并发指系统单位时间内收到的请求数量(取决于使用的用户数),没有上限。海量数据包括:海量数据的存储和海量数据的处理。这两个工程难题都可以使用分布式系统来解决。