互联网分布式系统架构演进之路

前言:

这是一篇学习心得的分享,告诉大家一个小系统是如何变得越来越复杂的。随着参与开发项目的增多,每天也在用很多app或者网站。那么大型网站一开始就是大型的吗?我们应该一开始就设计一个大型网站吗?可以带着这样的思考来一起阅读这篇文章。

正文:

一、初生

一个小网站刚做出来的的时候,往往都是没有什么人知道,所以单个服务器就可以满足需求。使用LAMP技术就可以。

二、成长(发展问题)

1.随着网站业务的发展,越来越多的用户访问,面临的问题:

  • 性能越来越差
  • 越来越多的数据导致存储空间不足

 解决方案:升级项目架构,应用服务与数据服务分离。(一个框框代表一个服务器)

 这样处理带来的好处:充分发挥不同类型服务器的特点

2.随着用户逐渐增多,网站再次面临挑战:

  • 数据库压力太大导致访问延迟,进而影响整个网站的性能,用户体验受到影响!

 解决方案:使用缓存改善性能

本地缓存和远程分布式缓存的优缺点:

  • 本地缓存速度极快,但是缓存的数据量有限,毕竟本地服务器内存有限
  • 远程分布式缓存相对于本地缓存性能稍差一点(因为要进行一次网络访问才可以拿到数据),但是又要比从数据库直接读取数据快,相当于利用空间换取时间

3.随着用户逐渐增多,单一应用服务器面临新的问题:

  • 能够处理的请求有限,网站访问高峰期,应用服务器成为整个网站的瓶颈

解决方案:应用服务器集群(分流)

 常用负载均衡实现的方式:

4. 使用缓存后,虽然大大减轻数据库的读压力,但是又同时引出了新的问题:

有一部分读操作(缓存访问不命中,缓存过期)和全部的写操作要访问数据库,当用户要达到一定规模后,数据库因为负载压力过高而成为整个系统的瓶颈。

解决方案:数据库读写分离

数据访问模块的作用?

单体应用的时候,只有一个数据库,我们在dao层写sql的时候不用考虑,这条sql去哪个数据库执行,因为就一个库,但是读写分离后如果再做数据库集群,就会有多个数据库,这时候我们在dao层不仅需要写业务代码还得兼顾考虑连接哪个库执行,就大大增加了开发的难度,所以这时候数据访问模块就可以为我们解决这个问题,让我们专注开发业务代码。

数据访问模块的实现?

5. 用户规模越来越大,发布地域越来越广,地域网络环境差别很大,面临问题:

如何保证用户的访问体验,不至于因访问慢而流失用户?

解决方案:反向代理和CDN加速

 反向代理和CDN加速有哪些好处:

  • 加快用户访问响应速度
  • 减轻后端服务器的负载压力

6.单文件服务器、单数据库服务器,面临的问题:

存不下日益增长的数据库

解决方案:分布式文件系统和分布式数据库系统

 分布式文件系统和分布式数据库系统的中间件:

7.随着业务的发展,数据的存储和检索需求越来越复杂,面临的问题:

  • 存储的字段差异较大,骷髅表
  • 复杂的文本检索

解决方案:使用NoSQL解决骷髅表、搜索引擎解决复杂的文本检索

 NoSQL、搜索引擎的中间件有哪些?

 8.网站越做越好,业务不断扩大,越来越复杂,面临的问题:

应用程序将变得无比庞大,迭代周期越来越快,牵一发而动全身,怎么应对快速的业务发展?

解决方案:业务拆分

 如大型电商网站会将首页、商铺、订单、买家等拆分成不同的产品线,分归不同的团队负责,分成不同的应用,独立部署。通过链接、MQ、是数据存储系统建立关联。

这时候需要引入消息中间件来做业务拆分:

 

9.业务规模不断增大,应用拆分越来越小,越来越多,面临的问题:

  • 应用间的关系越来越复杂,应用中存在大量相同的业务操作
  • 后端的数据库要被成千上万台应用服务器连接,数据库连接资源不足

解决方案: 分布式服务(服务化)

分布式服务化需要用的中间件:

 9.再往后,需要什么,面临的问题:

数据挖掘、分析、推荐等业务需求,庞大系统的监控、问题分析等需求。

解决方案:大数据技术、监控、日志分析系统

大数据技术、监控、日志分析系统的中间件:

 

 

总结:

技术的选择是具有阶段性的,当前阶段要优先考虑现阶段需要的技术,没有什么技术是一劳永逸的,随着网站发展要灵活应对。

今日分享一句话:其实在这个世界上,正常和不正常从来都是相对的。当我们看到一些与自己不同的人,就把他们归类于“不正常”时,这其实是一种狭隘的偏见。

我是阿达,一名喜欢分享知识的程序员,时不时的也会荒腔走板的聊一聊电影、电视剧、音乐、漫画,这里已经有10501位小伙伴在等你们啦,感兴趣的就赶紧来点击关注我把,哪里有不明白或有不同观点的地方欢迎留言!

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页