文档章节

一步步带你,如何网站架构

陶邦仁
 陶邦仁
发布于 2016/06/26 18:15
字数 3666
阅读 925
收藏 48
点赞 4
评论 5

#何为大型网站# ##大型网站特性## 既然说的是大型网站架构,那么架构的背后自然是解决人因面对大型网站特性而带来的问题。这样可以先给大家说下大型网站的特性,这些特性带来的问题就是人要解决的问题

  1. 高并发、大流量:PV 量巨大;
  2. 高可用:7*24 小时不间断服务;
  3. 海量数据:文件数目分分钟 xxTB;
  4. 用户分布广泛,网络情况复杂:网络运营商;
  5. 安全环境恶劣:黑客的攻击;
  6. 需求快速变更,发布频繁:快速适应市场,满足用户需求;
  7. 渐进式发展:慢慢地运营出大型网站;

##大型网站目标## 既然说到了大型网站的特性,那么**解决这些特性带来的问题要达到什么目标呢?**如下: 大型网站架构目标

每个目标背后面临着技术、设计、维护等诸多方面的挑战; 而目标本身的期望值也会根据实际情况进行调整,这也意味着网站架构建设是个不断调整的过程。

有了问题,也定了伟大的目标,那么网站在不同阶段面对不同的问题,是如何解决的?又是如何一步步成长为大型网站架构,实现这些伟大的目标呢?

##如何网站架构## 首先,什么是大型网站架构呢?

其实大型网站架构的概念对于每一个开发者来说很笼统、很模糊,正如盲人摸象,看到的、了解到的只是很小的一部分,大部分情况下我们只是负责架构中的一小块内容,所以很难清晰地给出具体定义。这就是所谓“不识庐山真面目 只缘身在此山中”的尴尬吧。所以我们要跳出来,站在宏观的角度,从整体到细节实现来认识大型网站架构。

那么从宏观的角度怎么去认识大型网站架构呢?正如前面几篇《细品架构系列》所描述对架构的认识,按照问题识别—>概念认知—>架构切分的思路,来分析大型网站架构的诞生:

  1. **问题识别:**当前什么问题、谁的问题、问题边界;
  2. **概念认知:**通过分析问题,会产生哪些概念,统一概念认知,达成沟通交流规范;
  3. **架构切分:**根据概念来解决问题,如何架构切分,产生哪些架构,提出具体解决方案;

PS:上面的三个步骤具体如何识别、认知、切分,请详细参考前面几篇《细品架构系列》文章,可能使你会对架构有重新的认识。

在进行分析大型网站架构的演进之路前,首先我们要明确的两个价值观:

  1. **核心价值:**随网站所需灵活应对;大型网站不是从无到有一步就搭建好一个大型网站,而是能够伴随小型网站业务的渐进发展,慢慢地演化成一个大型网站;
  2. **驱动力量:**网站的业务发展—业务成就了技术,事业成就了人,而不是相反;

还有,大型网站架构演进必须避免的几个误区:

  1. 一味追随大公司的解决方案;
  2. 为了技术而技术-->常见问题;
  3. **企图用技术解决所有问题:**技术是用来解决业务问题的,而业务的问题,也可以通过业务的手段去解决;

#架构体系演进# ##单机时代## **草根时期,快速开发网站并上线。**当然,通常只是先试水,用户规模也没有形成,经济能力和投入也非常有限应用程序、数据库、文件等所有资源都集中在一台 Server上,典型案例:基于 LAMP 架构的 PHP 网站;

单机时代(纯依赖RDBMS)

  1. **优点:**简单、快速迭代达成业务目标;
  2. **缺点:**存在单点、谈不上高可用;
  3. **技术点:**应用设计要保证可扩展;

##缓存出场## 有一定的业务量和用户规模了,想提升网站速度,于是,缓存出场了

单机时代+缓存出场

  1. **优点:**简单有效、方便维护;
  2. **缺点:**存在单点、谈不上高可用;
  3. **技术点:**客户端(浏览器)缓存、前端页面缓存、页面片段缓存、本地数据缓存/数据库缓存、远程缓存;

如上图,缓存可以分为:

  1. **页面缓存:**客户端缓存,减少对网站的访问;
  2. **本地缓存:**访问速度快,但数据量有限,减少对DB查询;
  3. **远程缓存:**远程访问,可以集群,因此容量不受限制;

##数据服务与应用分离## 市场反响还不错,用户量每天在增长,数据库疯狂读写,逐渐发现一台服务器快撑不住了。于是,决定把数据服务和APP做分离

数据服务与应用分离

  1. **优点:**简单有效、方便维护、提高不同Server对硬件资源的利用率;
  2. **缺点:**存在单点、谈不上高可用;
  3. **技术点:**文件服务器部署、数据库服务器,扩展数据访问模块;

分离后三台 Server 对硬件资源的需求各不相同:

  1. **应用服务器:**需要更快更强大的 CPU;
  2. **数据库服务器:**需要更快的硬盘和更大的内存;
  3. **文件服务器:**需要更大的硬盘;

##数据库读写分离## **单台数据库也感觉快撑不住了,一般都会尝试做“读写分离”。**由于大部分互联网“读多写少”的特性所决定的。Salve的台数,取决于按业务评估的读写比例。

数据库读写分离

  1. **优点:**简单有效、降低数据库单台压力;
  2. **缺点:**读写分离,增加程序难度,架构变复杂,维护难度增加;
  3. **技术点:**数据库主从同步部署,扩展数据访问模块,实现读写分离;

##应用服务集群## 数据库层面是缓解了,但是应用程序层面也出现了瓶颈,由于访问量增大,加上早期程序员水平有限写的代码也很烂,人员流动性也大,很难去维护和优化。所以,很常用的办法还是“堆机器”。

应用出现瓶颈 负载均衡集群

  1. **优点:**增加服务器和HA机制,系统性能及可用性得到保证;
  2. **缺点:**应用之间缓存、Session一致性问题;
  3. **技术点:**负载均衡;

通过集群解决高并发、海量数据问题的常用手段,实现系统的可伸缩性。通过负载均衡调度器,可将用户访问分发到集群中的某台 Server 上,应用服务器的负载压力不再成为整个网站的瓶颈。

##集中式缓存、Session集中存储## 加机器谁都会加,关键是加完之后得有效果,**加完之后可能会引发一些问题。**例如非常常见的:集群应用之间页面输出缓存和本地缓存一致性的问题,Session保存的问题......

集中式缓存 Session集中存储

  1. **优点:**应用之间缓存、Session一致,存储无限制,可以扩展;
  2. **缺点:**不如本地缓存访问快,缓存服务器、Session服务器等仍存在单点问题;
  3. **技术点:**缓存服务器部署、Session集中存储方案;

##动静分离## 动静分离也是提高网站响应速度的一种常用方式。**将动态请求与静态请求分离开,尽量减少对应用服务器的压力。同时,可以再进一步对静态请求,进行缓存,以加快响应速度。**可以需要开发人员配合(把静态资源放独立站点下),也可以不需要开发人员配合(利用7层反向代理来处理,根据后缀名等信息来判断资源类型)。

使用动静分离

  1. **优点:**减轻应用负载压力,针对静态文件缓存;
  2. **缺点:**静态文件缓存更新失效问题;
  3. **技术点:**动静分离、静态文件缓存方案;

##反向代理和CDN加速网站响应## 使用反向代理和CDN加速网站响应:CDN 和反向代理的基本原理都是缓存,区别在于:

  1. CDN部署在网络提供商的机房;
  2. 反向代理则部署在网站的中心机房;

使用 CDN 和反向代理的目的都是尽早返回数据给用户,一方面加快用户访问速度,另一方面也减轻后端服务器的负载压力。

使用反向代理和 CDN 加速网站响应

  1. **优点:**减轻应用负载压力,异地缓存有效解决不同地方用户访问过慢的问题;
  2. **缺点:**成本大幅增加,架构进一步复杂化,也维护难度进一步增大,静态文件缓存更新失效问题;
  3. **技术点:**CDN、反向代理方案;

##使用NoSQL和搜索引擎## 到这里,已经基本做到了DB层面和应用层面的横向扩展了,可以开始关注一些其它方面,例如:站内搜索的精准度,对DB的依赖,开始引入全文索引、NoSQL

NoSQL和搜索引擎都是源自互联网的技术手段,对可伸缩的分布式特性具有更好的支持。应用服务器则通过一个统一数据访问模块访问各种数据,减轻应用程序管理诸多数据源的麻烦。

使用NoSQL和搜索引擎

  1. **优点:**降低DB依赖;
  2. **缺点:**单点问题,谈不上高可用;
  3. **技术点:**NoSQL、搜索引擎、分布式;

到目前为止,一个能够承载日均百万级访问量的中型网站架构基本介绍完了。

##如何保证高可用## 在做扩展满足了基本的性能需求后,我们会逐渐关注“可用性”(也就是我们通常听别人吹牛时说的SLA、几个9)。如何保证真正“高可用”,也是个难题。

对关键应用/服务,做集群冗余负载,这也是保证高可用比较常用的手段:

  1. 文件系统、数据库系统集群;
  2. 静态内容服务器集群;
  3. CDN服务器集群;
  4. 反向代理服务器集群;
  5. 负载均衡调度器集群;
  6. 分布式NoSQL服务器集群;
  7. 搜索引擎服务器集群;
  8. 分布式缓存服务器集群;
  9. 分布式Session服务器集群;

使用集群冗余负载 保证高可用

  1. **优点:**集群负载,保证高可用;
  2. **缺点:**数据一致性、数据有状态问题;
  3. **技术点:**负载调度器、集群方案;

截止目前为止,都没有怎么去改动应用程序的架构,或者说通俗点,都不怎么需要大面积的修改代码。

如果上面那些手段都用光了,还是支撑不住怎么办?不停的加机器也不是办法啊?

##应用垂直拆分## 随着业务越来越复杂,网站的功能越来越多,虽然部署层面是采用的集群,但是应用程序架构层面还是“集中式”的,这样会导致很多耦合,不便于开发、维护,而且容易“一荣俱损”。所以,通常会把网站拆分出不同的子站点来单独宿主。

通过分而治之的手段将整个网站业务分成不同的产品线,如首页、商铺、订单、卖家、买家等拆分成不同的产品线,分归不同的业务团队负责。各个应用之间可以通过建立一个超链接建立关系,也可以通过消息队列进行数据分发。

应用垂直拆分(分压,解耦)

  1. **优点:**降低耦合、分压;
  2. **缺点:**应用架构复杂;
  3. **技术点:**业务抽取拆分;

##业务垂直分库## 应用都拆了,由于单个数据库的连接,QPS,TPS,I/O处理能力都非常有限,DB层面也可以去做垂直分库操作。

业务垂直分库 分压 解耦

  1. **优点:**降低DB耦合、分压DB;
  2. **缺点:**数据访问模块复杂;
  3. **技术点:**业务抽取拆分;

##分布式服务化## 拆分应用和DB之后,其实还是会有很多问题。**不同的站点,里面可能会有相同逻辑和功能的代码。**当然,对于一些基础的功能我们可以封装DLL或者Jar包去到处提供引用,但是这种强依赖也很容易造成一些问题(版本问题、依赖关系等处理起来非常麻烦)。

既然每一个应用系统都需要执行许多相通的业务操作,比如用户管理、商品管理等,那么可以将这些共用的业务提取出来,独立部署。这样,传说中的SOA的价值就得到体现了。

分布式服务化(解耦,去重复)

  1. **优点:**服务统一管理,提供重用度;
  2. **缺点:**应用架构更复杂;
  3. **技术点:**业务抽取拆分、服务化技术方案;

##消息队列## 应用、服务之间还是会出现一些依赖问题,这时候,高吞吐量的解耦利器出现了

消息队列(服务间异步解耦 高吞吐量)

  1. **优点:**提高吞吐量、应用、服务之间解耦;
  2. **缺点:**存在消息消费延迟问题;
  3. **技术点:**消息队列技术方案;

##分库分表## 最后,再介绍一个大型互联网公司都用的绝技--分库分表。个人经验,不是业务发展和各方面非常迫切,不要轻易走这一步

因为分库分表谁都会干,关键是拆完之后怎么办。目前,市面上还没有完全开源免费的方案,能让你一劳永逸地解决数据库拆分问题。

分库分表:

  1. 横向拆分;
  2. 纵向拆分;
  3. 分布式数据库访问层;
  4. 数据库中间件(代理);

#网站架构总结# 上面讲述了在网站业务发展的不同阶段,会面临不同的问题,针对不同的问题,会选择不同的架构。大型网站架构就是在不同阶段时解决不同问题的过程中慢慢演进来的。

最后几句话,送给有缘的你:

  1. 一切以解决业务目标为首要任务;
  2. 没有以业务为目标的任何架构、技术,都是毫无意义的耍流氓;
  3. 再牛逼的架构、再牛逼的技术,不能够解决业务的问题,你也只能算是会架构、会技术的工匠,而不能算是真正意义上的架构师;
  4. 业务成就了技术,平台成就了人,事业成就了人,而不是相反;

本文思维导图,如下:

本文思维导图

© 著作权归作者所有

共有 人打赏支持
陶邦仁
粉丝 1557
博文 388
码字总数 1483822
作品 0
海淀
技术主管
加载中

评论(5)

jwdstef
jwdstef
思维导图能提供下清晰版的么
陶邦仁
陶邦仁

引用来自“翼动动空”的评论

请问如果采用数据库集群的话,是采用1.多节点数据库部署,然后数据同步?2.数据库集群部署在统一服务器,多节点连接一个服务器集群?中的哪个方案好?如果采用1的话保证多节点读写速度快,不会产生节点数据跳跃问题,但是数据一致性保证差?采用2的话数据节点一致性可以保证。但是多节点之间读写存在跳跃,如电信、联通、移动节点跳跃
您的这个问题非常好,对于任何存储或缓存来说都会存在一致性问题,只要保证在做Hash环时,尽量保证多个同样的请求读写落到同一个节点,即可。这里说的数据库集群,指主库集群和从库集群,这两个集群节点是一一对应。所以对集群库的Hash是重中之重。再说下数据库集群与数据库分布式区别,集群是分布式中的一种,分布式可以理解为每个库的表都不一样,但集群是每个库的表一样,每个库存储的数据做Hash切分入库。严格上来说,应该先做分布式分库,然后根据每个库的压力,适当针对某个库做集群。不过也可以一上来对大库做集群,但之后再做分布式分库就不好搞了。
翼动动空
翼动动空
请问如果采用数据库集群的话,是采用1.多节点数据库部署,然后数据同步?2.数据库集群部署在统一服务器,多节点连接一个服务器集群?中的哪个方案好?如果采用1的话保证多节点读写速度快,不会产生节点数据跳跃问题,但是数据一致性保证差?采用2的话数据节点一致性可以保证。但是多节点之间读写存在跳跃,如电信、联通、移动节点跳跃
LiLiang
LiLiang
HeyS1
HeyS1
太厉害了,准备毕业小菜膜拜一下
大型网站架构_Index

大型分布式网站架构 大型分布式网站架构技术总结 大型网站架构系列:电商网站架构案例 大型网站架构系列:负载均衡详解 大型网站架构系列:分布式消息队列 一步步带你,如何网站架构 秒杀系统...

陶邦仁 ⋅ 2014/03/24 ⋅ 0

.NET架构中的通用权限系统 -- 如何控制用户显示的菜单权限

菜单权限是我们经常会遇到的权限,也是经常需要进行处理的权限,往往权限是通过控制菜单权限开始折腾起来的。 第一步:我的后台管理控制端,有一个叫模块配置的功能,这里集中配置,哪些模块...

Gute_Nacht ⋅ 2014/04/28 ⋅ 0

Linux运维有绝招

想要成为新时代的运维达人吗?全面掌握正确的学习路线。介绍一些入门教程带你轻松走进Linux世界的大门:1、Linux基础入门和架构了解:http://edu.51cto.com/course/course_id-948.html简介:...

让往事随风 ⋅ 2016/06/07 ⋅ 0

一步步教你如何用疯狂.NET架构中的通用权限系统 -- 在页面中的调用讲解

以下讲解是按最复杂的情况,讲解权限的要用法,若页面上不需要判断那么多,那么复杂的权限,那也不用搞得这么复杂,简单才是硬道理。 第一步: 首先需要在你需要用的页面里,把权限变量定义好...

技术小阿哥 ⋅ 2017/11/27 ⋅ 0

创业公司的研发架构:Step By Step

如何管理一家创业型公司,举目四望要做的很多,但资源、精力有限,如何从白纸一张一步步地架设起高楼大厦?我想这是困扰很多管理者的难题,我经手过几家创业公司,在这方面算是有些经验可以分...

孤岛旭日 ⋅ 2015/04/14 ⋅ 0

一步步构建大型网站架构

之前我简单向大家介绍了各个知名大型网站的架构,亿万用户网站MySpace的成功秘密、Flickr架构、YouTube网站架构、PlentyOfFish 网站架构学习、WikiPedia技术架构学习笔记。这几个都很典型,我...

考拉睡 ⋅ 2013/06/09 ⋅ 8

一步步构建大型网站架构

之前我简单向大家介绍了各个知名大型网站的架构,MySpace的五个里程碑、Flickr的架构、YouTube的架构、PlentyOfFish的架构、WikiPedia的架构。这几个都很典型,我们可以从中获取很多有关网站...

huojiao2006 ⋅ 2017/03/06 ⋅ 0

疯狂.NET架构通用权限后台管理工具演示版2.0下载

程序未必是最好的,但是我目前所能拥有的程序里是最好的, 功能未必是最全的,但是我目前所能拥有的程序里是最好的。 不管我的再怎么不好,也有成熟的产品,商品化的成果物,请不要乱打击我,...

Gute_Nacht ⋅ 2014/04/28 ⋅ 0

【省带宽、压成本专题】爱奇艺第一季度又烧了11个亿元,什么时候是个头?

过去几年,又拍云一直在点播、直播等视频应用方面潜心钻研,取得了不俗的成果。我们结合点播、直播、短视频等业务中的用户场景,推出了“省带宽、压成本”系列文章,从编码技术、网络架构等角...

又拍云 ⋅ 05/10 ⋅ 0

优酷网的架构学习笔记

记得以前给大家介绍过视频网站龙头老大YouTube的技术架构, 相信大家看了都会有不少的感触,互联网就是这么一个神奇的东西。今天我突然想到,优酷网在国内也算是视频网站的老大了,不知道他的...

红薯 ⋅ 2011/11/21 ⋅ 32

没有更多内容

加载失败,请刷新页面

加载更多

下一页

中标麒麟(龙芯版)7.0优盘安装

########################################## 制作U盘安装盘: 1.准备U盘: PMON环境下U盘必须格式化成ext3; 昆仑固件环境下可以格式化成ext3,ext4 2.把整个镜像 xxx.iso 复制到U盘下面 3....

gugudu ⋅ 19分钟前 ⋅ 0

老司机写的大数据建模五步走

本文将尝试来梳理一下数据建模的步骤,以及每一步需要做的工作。 01 第一步:选择模型或自定义模式 这是建模的第一步,我们需要基于业务问题,来决定可以选择哪些可用的模型。 比如,如果要预...

gulf ⋅ 28分钟前 ⋅ 0

PacificA 一致性协议解读

PacificA 的 paper 在 08 年左右发出来的,比 Raft 早了 6,7 年。 在 PacificA 论文中,他们强调该算法使用范围是 LAN (Local Area Network),讲白了就是对跨机房不友好。 不管是 ZAB,Raf...

黑客画家 ⋅ 30分钟前 ⋅ 0

盘符图标个性化

设置自己的专属盘符图标 准备ico格式的图片文件一个,在根目录下创建autorun.inf文件 文件内容 [Autorun]icon=logo.ico 重新启动或者插拔U盘即可看到结果...

阿豪boy ⋅ 30分钟前 ⋅ 0

Windows下QQ聊天记录中图片的默认存放位置

Windows下QQ聊天记录中图片的默认存放位置在设置中是没有说明的。 实测位置在:D:\Documents\Tencent Files\974101467\Image 其中: “974101467”为对应的QQ号; “C2C”为个人之间的聊天图...

临江仙卜算子 ⋅ 37分钟前 ⋅ 0

GC 的三种基本实现方式

参考资料《代码的未来》(作者: [日] 松本行弘)。 由于并非本人原著(我只是个“搬运工“),SO 未经本人允许请尽情转载。 另外个人像说明一下这里所说的GC指泛指垃圾回收机制,而单指Jav...

xixingzhe ⋅ 38分钟前 ⋅ 0

Android双击退出

/** * 菜单、返回键响应 */ @Override public boolean onKeyDown(int keyCode, KeyEvent event) { // TODO Auto-generated method stub if(keyCode......

王先森oO ⋅ 42分钟前 ⋅ 0

idea 整合 vue 启动

刚学习Vue 搭建了一个项目 只能命令启动 Idea里面不会启动 尝试了一下修改启动的配置 如下: 1.首先你要保证你的package.json没有修改过 具体原因没有看 因为我改了这个name的值 就没办法启动...

事儿爹 ⋅ 47分钟前 ⋅ 0

redis在windows环境的后台运行方法

在后台运行,首先需要安装redis服务,命令为 redis-server.exe --service-install redis.windows.conf --loglevel verbose 启动,命令为 redis-server --service-start 停止,命令为 redis-...

程序羊 ⋅ 51分钟前 ⋅ 0

比特币现金开发者提出新的交易订单规则

本周,四位比特币现金的四位开发者和研究员:Joannes Vermorel(Lokad),AmaurySéchet(比特币ABC),Shammah Chancellor(比特币ABC)和Tomas van der Wansem(Bitcrust)共同发表了一篇关...

lpy411 ⋅ 54分钟前 ⋅ 0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

返回顶部
顶部