分布式系统进化历史
一个成熟的大型分布式系统,并不是在其开始时,就设计为这样,而是在之后的不断优化,迭代而不断的进化成熟的。
在一个系统刚开始运行时,可能用户数,业务处理等都还比较简单,因此由一台服务器就能支撑起其正常的业务处理。其系统架构模型可能如下所示:
1,单应用架构
其应用服务和数据库服务,都部署在同一台服务器上。此时应用的实现简单,能够快速上线,为用户提供服务。比如很简单的可以使用tomcat+mysql部署在同一台机器上,提供服务。
但是随着用户数量的增加,业务内容的不断增加。其应用服务器的响应可能会慢慢变得迟缓,此时需要提升应用服务器的负载能力,保证用户的使用体验。因此需要采用更好的系统架构:
2,应用服务器和数据库服务器分离:
应用服务器和数据库服务器的分离,使得应用能够获得整个服务器的cpu资源来响应用户请求。应用服务器和数据库服务器的分离,也大大减少了应用的宕机风险。此时我们开始关注服务器的管理了。
3,应用服务器集群:
随着用户量的继续增加,一台应用服务器可能不能满足系统的需求,因此我们需要采用应用服务器的集群架构。
通过将用户的请求分流到不同的应用服务器,从而提高整个系统的负载能力,保证用户的使用体验。
但是当应用服务器采用集群结构后,遇到了之前不存在的新问题,比如:
(1):用户的请求由谁来决定,分发给哪个服务器来处理(负载均衡问题)。
(2):用户在使用网站的过程中,如何维护用户session,保证不同的服务器响应请求时,能保证用户session数据共享。
因此这个应用集群架构中,需要在应用服务器之上,新增一层进行负载均衡。
负载均衡器,可以分为软负载和硬负载。
软负载: nginx或apache等。
硬负载:f5等.
session共享,可通过配置tomcat的session共享来解决。但是由于session在服务器间的复制,占用浪费带宽比较严重,此时建议tomcat的实例不能过多。
4,数据库服务器读写分离:
在完成了应用服务器的集群分布后,此时的系统瓶颈就卡在数据库服务这块了。在对数据库服务器进行分布式集群时,很容易碰到多个数据库实例上的数据不一致的问题,因此一般我们会根据提供的应用服务具体类型,综合考虑应用提供的读写服务频率等特点。可以考虑先把数据库服务的读写进行分离。
此时,系统遇到的问题是:
(1):主从服务器上的数据同步。可以使用mysql自带的主从复制。
(2):可以根据业务选择对应的数据库中间件,屏蔽具体的数据库访问细节,如mycat等。
5,使用搜索引擎,缓解数据库读库压力
根据具体的业务类型,如果设计到很多模糊查询,而且数据量比较大,此时可以引入搜索引擎,如elasticsearch。
引入了搜索引擎,则需要额外的工作,如维护索引的构建,数据同步到搜索引擎等。
6,引入缓存机制
随着用户请求数量的增加,有一些热点数据,可能会不断的被用户访问,此时,可以把这些数据放进内存中,既避免访问数据库,又能加速响应用户请求。此时可以开始使用缓存技术,比如redis,memcache等。
使用缓存机制,能够缓存读库压力,提升应用性能,与读库相比,从缓存中读取数据,也能够更快的响应用户请求。
在有些使用场景中,可能需要使用一些数据,这些数据放在内存中不太合适,而放到数据库中又太麻烦,此时可以考虑使用nosql产品,来代替传统的关系型数据库,保持这些数据。
在分布式系统中,使用nosql时,也需要考虑缓存是否支持分布式集群。
7,数据库的水平/垂直拆分
随着业务量和数据量的持续增加,由于所有的数据都在同一个数据库中,数据库表非常多且杂,有些一个表中的数据记录已经达到了很大的数量。尽管采取了读写分离,缓存机制等,但是单个数据库中的并发连接数有一个上限,因此对数据库的访问依然会成为一个瓶颈。
因此需要考虑对数据库进行拆分。
垂直拆分:把不同的业务数据拆分到不同的数据库中。
水平拆分:把同一张表中的数据,拆分到不同的数据库中,水平拆分的原因是某些表中的数据量记录太大,达到了单个数据库的瓶颈。
8,应用的拆分
随着业务越来越多,整个应用越来越复杂,工程规模也越来越大。此时的管理维护工作量会越来越复杂。可以考虑根据领域模型,对系统进行拆分
对应用进行拆分后,可能有一些基本的操作,在每个子系统中,都会使用到,比如访问用户数据等,此时可以把这些相同的操作,抽象出来,通过提供服务的方式,提供给各个子系统使用。
因此此时遇到的一些新问题是,多个子系统之间如何进行远程通信。比如通过rpc技术(dubbo,webservice,hession,heep,rmi等),解决远程通信问题。
在系统不断进化时,整个系统也变得越来越复杂,管理难度越来越大,同时也会不断的出现新的技术,来解决不断出现的新问题,如微服务,docker容器技术,容器编排等。
最重要的是,根据应用的实际情况,如用户量,并发数,数据量等采用最合适的架构。
推荐阅读