从单机到分布式的架构漫谈系列

1. 摩尔定律

当价格不变时,集成电路上可容纳的元器件的数目,约每隔18-24个月便会增加一倍,性能也将提升一倍。换言之,每一美元所能买到的电脑性能,将每隔18-24个月翻一倍以上。这一定律揭示了信息技术进步的速度。 但现在,这种发展轨迹要告一段落。由于同样小的空间里集成越来越多的硅电路,产生的热量也越来越大,这种原本两年处理能力加倍的速度已经慢慢下滑。所以不言而喻,单机的性能会遇到瓶颈,这仅仅是从性能来看。即使不从性能来看,如果一个机器的性能足够,那么也会存在单点故障的问题,所以我们需要分布式的高可用。

2. 分布式

单机拓展到分布式:

输入/输出变化

分布式系统通过网络连接多个节点组成,那么输入/输出可以分为两种,一种是通过互相连接的多个节点,在接受其他节点传来的信息时,该节点可以看作输入/输出设备,另外一种就是传统的人机交互输入/输出设备。

控制变化

分布式系统通过网络连接多个节点组成,每一个节点是通过消息的传递进行协调,在请求发起方和请求处理方中间有一个控制器,所有的请求通过中央控制器来进行负载均衡,中央控制器可以分为:硬件负载均衡和软件负载均衡。

3.传统单体应用

传统的单体应用的应用链路比较简单,就以WEB应用举例,基本都是MVC的模式。Controller层,Service层,Dao层,数据请求的流向由上层逐层向下。

这是从代码结构来看,然后就将其打包发布到Tomcat里面,可能随着访问量的越来越多,单台机器的处理性能不足,就需要加入新的服务器,这时候就需要做一个负载均衡,在请求到后端业务逻辑的的前面,现在使用的是Nginx作为反向代理。同时将一些静态的资源文件放在前端,这样后端的Tomcat服务器直接处理具体的业务请求。类似于这样最简单的结构:

与此同时加入了负载均衡,就会产生一个session的问题。在单体应用上面,会话保存在单机上,请求也都是由一个机器来处理,所以不会出现问题。web服务器变成了多台之后,如何保证同一会话请求都在同一个web服务器上面处理?常用的有这么几种可选方案:

Session Sticky

在负载均衡那台服务器里面,将同一个请求发送到相同的web server上处理即可。同时也会带来一些问题,如果有一台web server宕机,那么这台机器上的seesion会丢失,如果有登录状态那么用户需要重新登录。session是http层进行解析的,如果要保证同一个session在同一台机器,那么需要在这里进行转换,这一层的开销也是不能忽略掉的;如果负载均衡是一个有状态的,需要将会话和web服务进行映射,如果机器宕机,在恢复的过程也是具有很大的挑战。

Session Replication

将两台的session进行同步,如果同步session的数据造成了网络开销,只要session数据有变化,就需要将同步到所有其他机器上,机器越多,同步带来的网络开销也就越大;如果每台web服务器都要保存所有的session,整个集群的session就会很多,每台机器保存session消耗的内存也会很严重。

Session集中管理

相比于Session Replication来说,减少了多台机器的网络同步,不过相对于单体的session来说,就是增加了延迟,不过在实际的工程化中,这些都是内网访问,所以问题不大。但是会存在单体失败的情况,这样就会影响我们的使用。

随着业务的发展,数据量和访问量都是在增长的。对现在的互联网来说,有很多场景都是读多写少,这种情况直接反映到数据库上面,那么对于这样的情况我们将数据进行读写分离。

web server 的读请求去读取dbForRead,如果是写请求则写入db数据库,这里MySQL采用的是master-slave,有可能会出现不一致的情况,当然在MySQL 5.7 以后,可以使用mysql group replication。

与此同时,为了弥补关系型数据库的不足,引入分布式存储系统。虽然我们在平时使用的是单机数据库,提供了较强的单机事务支持,但在其他方面会有不适合的场景。常见的分布式是大家熟知的分布式文件系统、分布式Key-Value系统和分布式数据库。分布式文件系统就是在分布式环境中由多个节点组成的功能与单机系统一样的文件系统,它是弱化格式的,内容的格式需要使用者自己组织;而分布式Key-Value系统相对分布式文件系统严格一些;分布式数据库对数据格式限定更加严格。

数据进行读写分离过后,又遇到了瓶颈,那就是进行业务的垂直/水平拆分。水平拆分过后对业务是会带来一定的影响,首先,访问用户信息的应用系统需要解决SQL路由的问题。为现在的用户信息分在两个数据库中,需要在进行数据库操作时,了解需要操作的数据库在哪里。此外,主键的处理也会变得不同,原来以单个数据库的一些机制需要变化,例如原来使用MySQL表上的自增字段,现在不能简单继续使用,并且在不同的数据库中也不能直接使用一些数据库限制来保证主键不重复。最后由于同一业务数据被拆分到了不同的数据库中,因此一些查询需要从两个数据库读取,如果数据量太大而需要分页,就会比较难处理。

也许将所有的功能集成在一个单体的应用里面,会给开发带来很多的问题,所以我们才需要拆分应用,以应用服务化的形式呈现给使用方。当然搜索对于一个系统来说必不可少,对于快速查找绝对是一个利器。以及在进行服务化的过程,难免会用消息队列来进行解耦和异步操作。

至此我们通过不断的演进,我们的系统架构图如下:

出处:

版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢。

架构文摘

互联网应用架构丨架构技术丨大型网站丨大数据丨机器学习

  • 发表于:
  • 原文链接:https://kuaibao.qq.com/s/20180617B0BUBB00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券