写点什么

图解大型网站技术架构的历史演化过程

  • 2019-11-07
  • 本文字数:2024 字

    阅读完需:约 7 分钟

图解大型网站技术架构的历史演化过程

开篇明义:


【大型网站技术架构笔记】系列是阅读《大型网站技术架构核心原理与实践》一书的一些笔记,记录了原书的一些重要内容以及我的个人理解。其中很多内容网上都能找得到。其实整本书,我最赞同的是作者阐述的网站架构的价值观——“业务成就技术,而不是相反”。在没有业务场景的时候就一味追逐架构,为技术而技术,或者一上来就想要设计出一个可以适用所有场景的解决方案,是不理智的。我们有的时候可能会陷入技术的怪圈而忘了考虑业务本身。我曾经看到的一句我很喜欢的话,在这边也与诸君分享:好的架构都是进化来的,不是设计来的。


以下为 (一)演化过程 内容:

一、初始阶段

初始阶段考虑到使用量规范较小,且快速开发等原因,采用单服务器,将文件、数据库与应用程序一起部署即可。语言可以采用 LAMP。如下图:


二、应用服务于数据服务分离

随着访问量的增多,导致存储空间不足,所以需要将应用与数据存储分离部署。文件和数据库存储需要分开。以避免由于大文件 io 而导致实时数据库服务的长响应延时。文件服务器需要更多的磁盘空间,数据库服务由于需要进行磁盘检索和数据缓存,所以需要较多的磁盘和内存。而应用服务器由于需要业务逻辑带来的频繁密集计算,所以需要较好的 CPU。如下图。


三、使用缓存改善网站性能

网站访问中,对访问频率比较高的数据进行本地缓存和分布式缓存,能够很好地提高网站性能。什么时候采用本地缓存,什么时候采用分布式缓存呢?一些公司会选择将热点数据存入本地缓存,同时异步写入分布式缓存。而更多时候,我们较少采用本地缓存,因为其会占用宝贵的应用程序的内存空间。采用本地缓存只有那种占用少量内存,且使用率非常高的数据。比如每次请求都需要判断用户是否在黑名单中。此时就可以把名单加载入本地缓存。分布式缓存我们常用的就是 memcached 和 redis。二者的伸缩性都非常优秀。


四、应用服务集群化

单一的服务器存在着并发处理能力不足,高峰期负载过高,单点等问题。此时可以用过简单的同构集群化部署来解决这一问题。


五、数据库读写分离

随着网站的发展,数据库的负载会变得越来越大。而且读、写数据库的操作本身就不是一个时间量级上的操作。如果都混在一起处理,则将很可能导致操作长时间阻塞等其他问题。大部分的主流数据库都自带主从热备的功能,所以部署起来还是比较简单的。而读写分离以及下面将提到的分库之后,我们常会采用一些中间件来对这个底层数据访问进行封装,从而对应用透明。比如 mybatis 有阿里巴巴的 cobar client 框架。读写分离后,我们的应用服务的设计中,就需要慎重考虑,读写同步的延时这一最终一致性的保证,对用户体验带来的影响是否可以接受。


六、采用其他缓存代理技术

以上说的基本都是服务器端的优化,而用户访问网站时候,带宽、地域等其他因素会对访问体验带来不可忽视的影响。来改善这一体验,加快网站访问速度的办法主要有 cdn 加速和反向代理。可以认为 cdn 是一种特殊的反向代理,其也是基于反向代理的原理过来实现的缓存和加速。其主要缓存一些静态资源到离用户最近的网络提供商的机房。而此处的反向代理则是部署在网站服务端的机房。其既可以进行一些静态数据的高速缓存,也由于采用了 SSL 与内部服务器进行交互从而节省了大量开销。


七、采用分布式数据库和分布式文件系统

随着网站规模的增大,单一的数据库和文件服务器已经无法很好迎合业务场景。所以同理地,也会将其集群化部署。


八、采用 nosql 和搜索引擎

随着数据需求越来越复杂,比如需要对 log 进行存储和分析以及检索。此时可以引入 nosql 数据库(如 mongodb、hbase 等)和搜索引擎技术(如 lucense 等)。同时,此时的数据源可能已经比较多,可以来自关系型数据库集群、非关系型数据库、缓存、文件系统甚至从消息队列订阅的数据等等。所以需要一个统一的数据访问模块(DAL)来统一对这一过程进行封装和管理。


九、业务拆分与分布式化

前面我们提到,对业务服务进行同构部署来实现业务的并发处理。而我们知道这样简单的加机器在前期确实可以实现服务性能的线性增长,但是到了后期,并发量上来了之后,会发现这一处理将会很快达到瓶颈。而且于此同时,各个子业务的差异性带来的架构以及请求量方面的差异将日趋明显,如果还这样进行同构化的混部,其服务的性能将可能最终跟不上业务的发展,甚至可能导致雪崩。所以最好的做法,就是对业务服务进行垂直拆分。同时对基础服务进行水平拆分。真正实现 SOA。



如此,便是一个网站架构演化的常见路径。


作者介绍:


陈超,猫眼娱乐基础架构负责人,腾讯云 TVP,历任百度凤巢某业务团队技术负责人、丁丁租房基础架构与运维部负责人,现猫眼娱乐基础架构负责人。参与国内最大的商业广告平台“凤巢系统”服务化过程,从 0-1 搭建丁丁租房整体业务微服务架构和基础架构体系,从 0-1 搭建猫眼娱乐基础架构体系。具备 8 年互联网工作经验,在服务治理领域具备丰富经验。


本文转载自公众号云加社区(ID:QcloudCommunity)。


原文链接:


https://mp.weixin.qq.com/s/RZvJYQdd6CQofyPoSRgHdQ


2019-11-07 10:281421

评论

发布
暂无评论
发现更多内容

架构师训练营第 1 期 -Week6 - 课后练习

鲁大江

极客大学架构师训练营

第六周作业 (作业一)

Geek_83908e

极客大学架构师训练营

架构师训练营—第五周学习总结

Geek_shu1988

架构师训练营—第六周学习总结

Geek_shu1988

第六周总结

Geek_ac4080

架构师训练营第六周课程笔记及心得

Airs

架构师训练营第二周作业

张小胖

极客大学架构师训练营

第二周作业

阿呆

第 2 周 框架设计总结

心在那片海

第 2 周 框架设计作业

心在那片海

doris临时故障恢复图

happy

架构师训练营 week2 学习总结

花果山

极客大学架构师训练营

第六周-CAP原则理解

袭望

架构师训练营第六周作业

郎哲158

极客大学架构师训练营

架构师训练营 - 第 6周课后作业-CAP原理

树森

week06学习总结

龙卷风

架构师一期

分布式CAP原理

Jacky.Chen

架构师训练营第二期 Week 2 总结

bigxiang

架构师训练营 第六周学习总结

郎哲158

极客大学架构师训练营

架构一期第六周作业

Airs

架构师训练营第六周总结

月殇

极客大学架构师训练营

架构师训练营—第五周作业

Geek_shu1988

第二周课后练习

jizhi7

极客大学架构师训练营

第六周作业

Geek_ac4080

WK1作业

Gavin_From_Mars

第六周作业

wanlinwang

极客大学架构师训练营

架构师训练营 Week6 - 技术选型 - 分布式数据库,NoSQL,Zookeeper,搜索引擎

极客大学架构师训练营

架构师训练营第 2 期 第二周作业 1

月下独酌

架构师训练营第 1 期 -Week6 - 技术选型二学习总结

鲁大江

极客大学架构师训练营

架构师训练营—第六周作业

Geek_shu1988

技术选型(1) 课后作业

ABS

图解大型网站技术架构的历史演化过程_文化 & 方法_陈超_InfoQ精选文章