知识
助手
最大化  清空记录  历史记录
   419  
查询码: 00000420
大型网站架构之架构演变
作者: 系统管理员 于 2018年08月02日 发布在分类 ,于 2018年08月09日 编辑
网站 架构 数据 大型 服务 数据库 用户 业务 应用 服务器

处于这个互联网开发时代,作为一名软件工程师,我们经常会听到大型网站架构这个字眼,那到底什么是大型网站呢,这样的网站又是一种什么样的架构设计呢?今天我们就开始谈谈大型网站架构设计系列,首先我们今天讲讲大型网站架构设计是如何演变的,跟着我一起出发吧。

一、大型网站系统的特点

  • 高并发,大流量 :需要面对高并发用户,大流量访问;

  • 高可用 :系统24小时不间断的提供服务;

  • 海量数据 :需要存储、管理海量的数据,需要使用大量的服务器;

  • 用户分布广泛,网络情况复杂 :很多大型网站都是为全球用户服务,用户的分布范围广泛,各地网络情况差异大;

  • 安全环境恶劣 :互联网的开放性,导致网站更容易受黑客的攻击;

  • 需求快速变更,发布频繁 :相比传统软件,互联网产品为了快速适应市场,满足用户的需求,产品发布的频率是极高的;

  • 渐进式发展 :与传统行业软件不同,互联网产品不是事先就规划好了整个产品的全部功能,几乎每个大型互联网网站都是从一个小网站,慢慢根据市场和用户的改变而慢慢渐进发展成大型网站的;

二、大型网站架构发展历程

大型网站的技术挑战主要来自三个方面: 庞大的用户体系高并发的访问以及 海量数据的存储管理。基于这三点,我们就来看看,整个架构设计方面是如何演变的。

初始阶段:这个阶段一般网站用户量也不多,访问量都不大,数据量也不多,因此一般一台服务器就能搞定,应用程序,数据库和文件都可以部署在一台服务器上,架构图如下:

应用服务和数据服务分离阶段:随着用户数量的增加,越来越多的用户访问导致性能越来越差,数据也越来越多导致存储空间不足,此时我们就需要考虑将应用和数据分离,此时网站需要3台服务器:应用服务器+数据库服务器+文件服务器,架构设计如下图:

使用缓存改善性能阶段:随着数据库压力越来越大,我们需要考虑从数据上优化性能,大家都知道80%的业务访问集中在20%的数据上,既然大部分业务集中访问这少部分数据,那为何我们不考虑把这部分数据缓存在内存中呢,不就可以减小对数据库访问的压力了嘛;

缓存又分为2种,一种是 本地缓存(本地缓存是基于内存的,因此数据量有限,但是访问速度快),另一种是 远程缓存(一些中间件缓存服务器例如redis,这部分数据理论上不限容量,而且可以做成集群模式)。

应用服务器集群优化网站并发能力阶段:当用户越来越多时,对网站的访问量也越来越多,应用服务器处理请求越来越慢,此时我们可以考虑将应用服务器做成集群模式部署,再通过负载均衡调度器,将用户的请求分发给集群上不同的应用服务器。

数据库读写分离阶段:网站在使用了缓存之后,使部分数据可以不通过数据库就能完成,但是对于数据库的修改操作,还是需要访问数据库的,这个时候,数据库的负载压力过高,能为网站的性能瓶颈,此时我们就要考虑数据库的读写分离了,数据库的读写分离是建立在主从热备的基础上的,基本目前大多数主流数据库都支持主从热备,通过配置两台或者多台数据库的主从关系(1主1从,1主多从,多主多从),实现数据的读(从库)写(主库)分离,主库主动将数据同步到从库。

向代理和CDN加速网站响应阶段:为了加快网站的访问速度,我们主要考虑的手段为CDN和反向代理,CDN是部署在网络提供商的机房,用户在访问时,可以从距离自己最近的网络提供商机房获取数据;反向代理是部署在网站自己的中心机房,当用户请求到达机房时,优先访问的服务器是反向代理服务器,如果反向代理中缓存了用户请求的资源,那么就直接返回给用户,加快了响应的速度,也减轻了后端负载的压力。

分布式文件系统和分布式数据库系统阶段:当读写分离之后如果还不能满足网站的需求,那就只能考虑最后的手段了:分布式数据库,网站常用的数据库拆分手段是业务分库,将不同的业务数据库部署在不同的物理机上。

NoSQL和搜索引擎阶段:随着网站业务越来越复杂,对数据的检索和存储的需求也越来越复杂,网站需要采用一些非关系型数据库(NoSQL)和非数据库查询(搜索引擎)技术。

业务拆分阶段:分而治之思想,将整个网站业务划分为不同的产品线,根据不同的产品线划分将网站拆成不同的应用,每个应用独立部署维护如一个电商网站可以分为:首页,订单,商品,活动,优惠卷,个人中心,购物车等等多个应用,应用之间可以通过消息队列来传递数据。

分布式服务阶段:随着业务复杂度提升,我们会发现很多系统之间有着共同的业务,我们可以把这部分业务抽取出来,做成一个共通的基础服务。

三、网站架构设计的误区

  • 一味追求大公司的解决方案 :大公司的架构和成功案例当然值得借鉴,但是不能盲从;

  • 为了技术而技术 :技术是为业务而存在的,在技术选型和架构设计中一定要结合具体业务,脱离业务的架构毫无意义;

  • 企图用技术解决所有问题 :技术是用来解决业务问题的,而业务本身的问题,是可以通过业务去解决,而没有必要企图用技术是解决;

四、总结

设计网站架构时一定要从小开始,架构随业务演变而演变,切记不要在业务还是0的时候去追求1的架构设计,那样的架构只会舍本逐末,得不偿失;

文章转载自:Justin谈开发!

0人参与


 历史版本

修改日期 修改人 备注
2018-08-09 15:32:46[当前版本] 系统管理员 格式调整
2018-08-02 17:40:03 系统管理员 格式调整
2018-08-02 17:39:09 系统管理员 CREAT

  目录
    wcp知识库系统-京ICP备15024440号-1 -V 5.1.3 -wcp