文档章节

构建大型网站————系统架构

五大三粗
 五大三粗
发布于 2015/05/22 17:34
字数 9010
阅读 2496
收藏 58


构建大型网站(百万级访问量)的技术准备


对互联网有了解的人都有自己的想法,有人就把想法付诸实现,做个网站然后开始运营。其实从纯网站技术上来说,因为开源模式的发展,现在建一个小网站已经很简单也很便宜。当访问量到达一定数量级的时候成本就开始飙升了,问题也开始显现了。因为带宽的增加、硬件的扩展、人员的扩张所带来的成本提高是显而易见的,而还有相当大的一部分成本是因为代码重构、架构重构,甚至底层开发语言更换引起的,最惨的就是数据丢失,辛辛苦苦好几年,一夜回到创业前。

减少成本就是增加利润。很多事情,我们在一开始就可以避免,先打好基础,往后可以省很多精力,少操很多心。

假设你是一个参与创业的技术人员,当前一穷二白,什么都要自己做,自己出钱,初期几十万的资金,做一个应用不是特别复杂的网站,那么就要注意以下几点:

一、开发语言

一般来说,技术人员(程序员)创业都是根据自己技术背景选择自己最熟悉的语言,不过考虑到不可能永远是您一个人写程序,这点还得仔细想想。无论用什么语言,最终代码质量是看管理,所以我们还是从纯语言层面来说实际一点。现在流行的java、php、.net、python、ruby都有自己的优劣,python和ruby,现在人员还是相对难招一些,性能优化也会费些力气,.net平台买不起windows server。java、php用的还是最多。对于初期,应用几乎都是靠前端支撑的网站来说,php的优势稍大一些,入门简单、设计模式简单、写起来快、性能足够等,不过不注重设计模式也是它的劣势,容易变得松散,隐藏bug稍多、难以维护。java的优势在于整套管理流程已经有很多成熟工具来辅助,强类型也能避免一些弱智BUG,大多数JAVA程序员比较注重设计模式,别管实不实际,代码格式看起来还是不错的。这也是个劣势,初学者可能太注重模式而很难解决实际需求。

前端不只是html、css这类。整个负责跟用户交互的部分都是前端,包括处理程序。这类程序还是建议用php,主要原因就是开发迅速、从业人员广泛。至于后端例如行为分析、银行接口、异步消息处理等,随便用什么程序,那个只能是根据不同业务需求来选择不同语言了。

二、代码版本管理

如果开发人员之间的网络速度差不多,就SVN;比较分散例如跨国,就hg。大多数人还是svn的.

假设选了svn,那么有几点考虑。一是采用什么树结构。初期可能只有一条主干,往后就需要建立分支,例如一条开发分支,一条上线分支,再往后,可能要每个小组一个分支。建议一开始人少时选择两条分支,开发和线上,每个功能本地测试无误后提交到开发分支,最后统一测试,可以上线时合并到上线分支。如果喜欢把svn当做移动硬盘用,写一点就commit一次也无所谓,就是合并的时候头大一些,这些人可以自己建个分支甚至建立个本地代码仓库,随便往自己的分支提交,测试完毕后再提交到开发分支上。

部署,可以手工部署也可以自动部署。手工部署相对简单,一般是直接在服务器上svn update,或者找个新目录svn checkout,再把web root给ln -s过去。应用越复杂,部署越复杂,没有什么统一标准,只要别再用ftp上传那种形式就好,一是上传时文件引用不一致错误率增加,二是很容易出现开发人员的版本跟线上版本不一致,导致本来想改个错字结果变成回滚的杯具。如果有多台服务器还是建议自动部署,更换代码的机器从当前服务池中临时撤出,更新完毕后再重新加入。

不管项目多小,养成使用版本管理的好习惯,最起码还可以当做你的备份,我的 http://zhiyi.us 虽然就是一个wordpress,可还是svn了,只改动一两句css那也是劳动成果。

三、服务器硬件

别羡慕大客户和有钱人,看看机房散户区,一台服务器孤独的支撑的网站数不清。如果资金稍微充足,建议至少三台的标准配置,分别用作web处理、数据库、备份。web服务器至少要8G内存,双sata raid1,如果经济稍微宽松,或静态文件或图片多,则15k sas raid1+0。数据库至少16G内存,15k sas raid 1+0。备份服务器最好跟数据库服务器同等配置。硬件可以自己买品牌的底板,也就是机箱配主板和硬盘盒,CPU内存硬盘都自己配,也可以上整套品牌,也可以兼容机。三台机器,市场行情6、7万也就配齐了。

web服务器可以既跑程序又当内存缓存,数据库服务器则只跑主数据库(假如是MySQL的话),备份服务器干的活就相对多一些,web配置、缓存配置、数据库配置都要跟前两台一致,这样WEB和数据库任意一台出问题,把备份服务器换个ip就切换上去了。备份策略,可以drbd,可以rsync,或者其他的很多很多的开源备份方案可选择。rsync最简单,放cron里自己跑就行。备份和切换,建议多做测试,选最安全最适合业务的,并且尽可能异地备份。

四、机房

三种机房尽量不要选:联通访问特别慢的电信机房、电信访问特别慢的联通机房、电信联通访问特别慢的移动或铁通机房。那网通机房呢?亲,网通联通N久以前合并改叫联通了。多多寻找,实地参观,多多测试,多方打探,北京、上海、广州等各个主节点城市,还是有很多优质机房的,找个网络质量好,管理严格的机房,特别是管理要严格,千万别网站无法访问了,打个电话过去才知道别人维护时把你网线碰掉了,这比DOS都头疼。自己扯了几根光纤就称为机房的,看您抗风险程度和心理素质了。机房可以说是非常重要,直接关系到网站访问速度,网站访问速度直接关系到用户体验,我可以翻墙看风景,但买个网游vpn才能打开你这个还不怎么知名的网站就有难度了。或许您网站的ajax很出色,可是document怎么也不ready,一些代码永远绝缘于用户。

五、架构

初期架构一般比较简单,web负载均衡+数据库主从+缓存+分布式存储+队列。大方向上也确实就这几样东西,细节上也无数文章都重复过了,按照将来会有N多WEB,N多主从关系,N多缓存,N多xxx设计就行,基本方案都是现成的,只是您比其他人厉害之处就在于设计上考虑到缓存失效时的雪崩效应、主从同步的数据一致性和时间差、队列的稳定性和失败后的重试策略、文件存储的效率和备份方式等等意外情况。缓存总有一天会失效,数据库复制总有一天会断掉,队列总有一天会写不进去,电源总有一天会烧坏。根据墨菲定律,如果不考虑这些,网站早晚会成为茶几。

六、服务器软件

Linux、nginx、php、mysql,几乎是标配,我们除了看名字,还得选版本。Linux发行版众多,只要没特殊要求,就选个用的人最多的,社区最活跃的,配置最方便的,软件包最全最新的,例如debian、ubuntu。至于RHEL之类的嘛,你用只能在RHEL上才能运行的软件么?剩下的nginx、php、mysql、activemq、其他的等等,除非你改过这些软件或你的程序真的不兼容新版本,否则尽量版本越新越好,版本新,意味着新特性增多、BUG减少、性能增加。总有些道听途说的人跟你说老的版本稳定。所谓稳定,是相对于特殊业务来说的,而就一个php写的网站,大多数人都没改过任何服务器软件源代码,绝大多数情况是能平稳的升级到新版本的。类似于jdk5到jdk6,python2到python3这类变动比较大的升级还是比较少见的。看看ChangeLog,看看升级说明,结合自己情况评估一下,越早升级越好,别人家都用php6写程序了这边还php4的逛游呢。优秀的开源程序升级还是很负责任的,看好文档,别怕。

七、数据库

几乎所有操作最后都要落到数据库身上,它又最难扩展(存储也挺难)。对于mysql,什么样的表用myisam,什么样的表用innodb,在开发之前要确定。复制策略、分片策略,也要确定。表引擎方面,一般,更新不多、不需要事务的表可以用myisam,需要行锁定、事务支持的,用innodb。myisam的锁表不一定是性能低下的根源,innodb也不一定全是行锁,具体细节要多看相关的文档,熟悉了引擎特性才能用的更好。现代WEB应用越来越复杂了,我们设计表结构时常常设计很多冗余,虽然不符合传统范式,但为了速度考虑还是值得的,要求高的情况下甚至要杜绝联合查询。编程时得多注意数据一致性。

复制策略方面,多主多从结构也最好一开始就设计好,代码直接按照多主多从来编写,用一些小技巧来避免复制延时问题,并且还要解决多数据库数据是否一致,可以自己写或者找现成的运维工具。

分片策略。总会有那么几个表数据量超大,这时分片必不可免。分片有很多策略,从简单的分区到根据热度自动调整,依照具体业务选择一个适合自己的。避免自增ID作为主键,不利于分片。

用存储过程是比较难扩展的,这种情形多发生于传统C/S,特别是OA系统转换过来的开发人员。低成本网站不是一两台小型机跑一个数据库处理所有业务的模式,是机海作战。方便水平扩展比那点预分析时间和网络传输流量要重要的多的多。

NoSQL。这只是一个概念。实际应用中,网站有着越来越多的密集写操作、上亿的简单关系数据读取、热备等,这都不是传统关系数据库所擅长的,于是就产生了很多非关系型数据库,比如Redis/TC&TT/MongoDB/Memcachedb等,在测试中,这些几乎都达到了每秒至少一万次的写操作,内存型的甚至5万以上。例如MongoDB,几句配置就可以组建一个复制+自动分片+failover的环境,文档化的存储也简化了传统设计库结构再开发的模式。很多业务是可以用这类数据库来替代mysql的。

八、缓存

数据库很脆弱,一定要有缓存在前面挡着,其实我们优化速度,几乎就是优化缓存,能用缓存的地方,就不要再跑到后端数据库那折腾。缓存有持久化缓存、内存缓存,生成静态页面是最容易理解的持久化缓存了,还有很多比如varnish的分块缓存、前面提到的memcachedb等,内存缓存,memcached首当其冲。缓存更新可用被动更新和主动更新。被动更新的好处是设计简单,缓存空了就自动去数据库取数据再把缓存填上,但容易引发雪崩效应,一旦缓存大面积失效,数据库的压力直线上升很可能挂掉。主动缓存可避免这点但是可能引发程序取不到数据的问题。这两者之间如何配合,程序设计要多动脑筋。

九、队列

用户一个操作很可能引发一系列资源和功能的调动,这些调动如果同时发生,压力无法控制,用户体验也不好,可以把这样一些操作放入队列,由另几个模块去异步执行,例如发送邮件,发送手机短信。开源队列服务器很多,性能要求不高用数据库当做队列也可以,只要保证程序读写队列的接口不变,底层队列服务可随时更换就可以,类似Zend Framework里的Zend_Queue类,java.util.Queue接口等。

十、文件存储

除了结构化数据,我们经常要存放其他的数据,像图片之类的。这类数据数量繁多、访问量大。典型的就是图片,从用户头像到用户上传的照片,还要生成不同的缩略图尺寸。存储的分布几乎跟数据库扩展一样艰难。不使用专业存储的情况下,基本都是靠自己的NAS。这就涉及到结构。拿图片存储举例,图片是非常容易产生热点的,有些图片上传后就不再有人看,有些可能每天被访问数十万次,而且大量小文件的异步备份也很耗费时间。

为了将来图片走cdn做准备,一开始最好就将图片的域名分开,且不用主域名。很多网站都将cookie设置到了.domain.ltd,如果图片也在这个域名下,很可能因为cookie而造成缓存失效,并且占多余流量,还可能因为浏览器并发线程限制造成访问缓慢。

如果用普通的文件系统存储图片,有一个简单的方法。计算文件的hash值,比如md5,以结果第一位作为第一级目录,这样第一级有16个目录。从0到F,可以把这个字母作为域名,0.yourimg.com到f.yourimg.com(客户端dns压力会增大),还可以扩展到最多16个NAS集群上。第二级可用年月例如,201011,第三级用日,第四级可选,根据上传量,比如am/pm,甚至小时。最终的目录结构可能会是 e/201008/25/am/e43ae391c839d82801920cf.jpg。rsync备份时可以用脚本只同步某年某日某时的文件,避免计算大量文件带来的开销。当然最好是能用专门的分布式文件系统或更专业点的存储解决方案。

EverNote的系统架构

我们就先初略的从Evernote 服务的物理构造说起,这里我不会详细的介绍每一个组件。有意思的点会在接下来的文章中详述。

我们先从图片的左上角开始说起,所有的服务器状态截止为2011年5月17日。

网络:几乎所有的Evernote流量都是通过https://www.evernote.com:443 传输的。包括所有的“网络”的活动,还包括基于Thrift的客户端同步服务API 。他每天可以处理1.5亿的HTTPS请求,峰值为250Mbps的流量。(对于我们半夜运营的团队来说,最不幸的是,每天的峰值时间发生在太平洋时间每天的6:30左右)

我们通过主要网络供应商(NTT)和次要供应商(Level 3)使用BGP(边界网关协议)来完全独立的分配流量,在一月份我们的SSL流量达到了老的负载均衡设备的极限后我们就新上了通过Vyatta防火墙过滤的A10 负载均衡,我们很容易的使用一台AX 2500设备来转移服务器故障。但我们准备测试其N +1群集配置以备未来的增长。

碎片:Evernote服务的核心是一组称为“碎片”的服务器组。每一台“碎片”用来保存和处理10万Evernote注册用户的所有数据和流量(Web和API)因为我们有超过900万用户,将有大约有90台“碎片”。

设备上,“碎片”被部署为一对有两个四核英特尔处理器,很多内存和镜像RAID配的置希捷企业级硬盘的SuperMicro盒子。在每个盒子中我们运行了 Debian的 主机管理两个 Xen的 虚拟机。盒子上的主虚拟机运行核心应用程序 Debian + Java 6 + Tomcat + Hibernate + Ehcache +  Stripes + GWT + MySQL (for metadata)/ (元数据)+ hierarchical local file systems (for file data)/本地文件系统层次结构(数据文件)。

盒子上主虚拟机中的所有用户数据使用 DRBD技术 将同步复制到不同盒子的备份虚拟机上。这就意味着每一种用户数据会存在于两台物理服务器中,并有四份拷贝,并且每晚都会备份。如果我们的一台服务器存在问题,我们可以使用Heartbeat在最短的时间内将服务从注虚拟机切换到另一台盒子的备虚拟机上。

因为每个用户的数据汇总在一个虚拟服务器,我可以在没有与外部依赖的情况下独立运行“碎片”, 因此,一台“碎片”出现了问题并不会影响其他“碎片”。

为了连接用户和负载均衡设备,我们在浮躁均衡设备上花了大量的工作来通过UR L或Cookies来寻找对应的“碎片”。

用户信息保存:绝大多数的用户数据存储在单层的NoteStore碎片中,同时他们共享一个主“UserStore”帐户数据库(MySQL)。数据中包含少量的信息,如:用户名、MD5处理过的密码和“碎片”服务器的ID。这些数据足够的小,以至于可以在内存中储存。但是我们还会使用RAID镜像、DRBD复制确保数据备份的高度冗余。

高级图片处理:为了让你在笔记中可以搜索图片,我们每天使用28台8核服务器处理新图片。在忙的时候,一天可以处理130万到140万张图片。目前服务器Linux和Windows一起在使用,但是我们已经计划化把我们把所有的服务器在本月底换成debian系统来解决先前一些很老的问题。

这些服务器运行了我们研发团队自行开发的“先进的图像识别”程序。这个程序清每幅图片,识别文字形区域,然后和“识别引擎”进行匹配,这种识别引擎,比如我们的专业团队制作开发手写识别引擎,其中包括授权给我们商业合作伙伴的技术。

其他服务:我们所有的服务器都位于California,Santa Clara 的两个数据中心,除了我们核心服务的设备以外,我们也有小的服务器群组来处理小的任务,小的服务器群组只要小的服务器群组只要一到两个“盒子”或虚拟机。例如,我们的

SMTP邮件网关服务器就是由两台装有Postfix和一个基于Dwarf 的Java邮件处理程序的debian服务器。我们的@myen Twitter gateway 是一个简单的基于twitter4j的内部服务程序。

我们公司的网站使用的是Apache,公司的博客使用的是WordPress系统,我们大部份使用的拓扑结构交换机来自于惠普 ,我们使用Puppet来进行配置管理,使用Zabbix、Opsview和AlertSite来进行监测性能。我们每晚通过一个千兆的使用比较软件将数据备份到另一个数据中心。

等等,为什么?我知道这个文章留下了明显的问题,比如为什么我们在许多地方选择了X而没有选择Y,为什么我们使用自己的服务器群组而不实用云提供商?为什么我们还在使用一些旧的技术(Java,SQL,local storage等)而不是新的神奇的技术。

这些问题我们会在未来几个月在后面的文章中进行详述,尽情大家期待!

Facebook的系统架构

根据我现有的阅读和谈话,我所理解的今天Facebook的架构如下:

 

关于那些供给给上述组件的资源,下面是一些信息和数量,但是有一些是未知的:

一. 何为session

用户使用网站的服务,基本上需要浏览器和web服务器进行多次交互,web服务器如何知道哪些请求是来自哪个会话的?

具体方式为:在会话开始时,分配一个唯一的会话标识(sessionId),通过cookie把这个标识告诉浏览器,以后每次请求的时候,浏览器都会带上这个会话标识来告诉web服务器请求是属于哪个会话的。如果遇到禁用cookie的情况,一般的做法就是把这个会话标识放到url的参数中。



二. 问题

因为会话信息保存在单机上,当我们的应用服务器从一台变成两台后,我们就会遇到session的问题了!

如下图所示,当我们第一次访问网站时请求落到了左边的服务器,那么我的session就创建在左边的服务器上了,如果我们不做处理,就不能保证接下来的请求每次都落在同一边的服务器上了,这就是session问题。



三. 解决办法:

1. session sticky

在web服务器变成多台后,如果我们可以保证同一个会话请求都能在同一个web服务器上处理,那么对于这个会话个体来说,和单机的情况是一样的。这就需要负载均衡器能够根据每次请求的会话标识来进行请求转发。

有何问题:

① 如果有一台web服务器宕机或重启,那么这台机器上的会话数据会丢失

② 负载均衡器变成了一个有状态的结点,要保存会话到具体web服务器的映射,要消耗一定的内存。




2. session replication

web服务器之间增加了会话数据的同步,通过同步就保证了不同web服务器之间的session数据一致,一般的应用容器都支持这种方式。

问题:

① 只要session数据有变化,就需要将数据同步到其他机器上,会带来一定的网络带宽开销

② 每台web服务器都要保存所有的session数据,如果整个集群session数很多的话,对内存资源消耗较大。

该方案不适合集群机器较多的场景。



3. session数据集中存储

把session数据集中存储起来,然后不同的web服务器从相同的地方来获取session,存储session数据的方式可以为数据库,也可以使用其他分布式存储系统。

问题:

① 获取session存在延时和不稳定性,不过我们的通信基本在内网,问题不大。

② 如果存储session的机器或集群发生问题,就会影响到应用。

当集群规模较大时,session数较多时,该方案可以考虑。



4. cookie based

该方案通过cookie来传递session数据,即把session数据存在cookie中

问题:

① cookie有长度限制,这也就会限制session数据的长度

② 安全性,cookie的数据保存在客户端,这就存在安全性的问题,我们需要对写入cookie的session数据做加密处理

③ 带宽消耗, 客户端每次都要带着session过来,会消耗一定网络资源

④ 性能影响,每次http请求和响应都带有session数据,对web服务器来说,在同样的处理情况下,响应的结果输出越少,支持的并发请求就会越多。



综上方案都是解决session问题的方案,对于大型网站来说,session sticky和session集中管理是比较好的方案。




© 著作权归作者所有

上一篇: TCP,IP协议
下一篇: HEAD FIRST JAVA教程
五大三粗
粉丝 163
博文 2291
码字总数 4764188
作品 0
广州
程序员
私信 提问
加载中

评论(1)

查封炉台
查封炉台
嗯,很实用。
架构学习资料汇总

知名网站架构分析 探索Google App Engine背后的奥秘(1)–Google的核心技术 探索Google App Engine背后的奥秘(2)–Google的整体架构猜想 探索Google App Engine背后的奥秘(3)- Google App Eng...

peter8015
2016/04/22
279
0
[招聘] 淘宝[急招]应用运维工程师(工作点: 杭州/北京)

详细招聘要求请查看 http://job.taobao.com 校园招聘需求请查看 http://campus.taobao.com 淘宝[急招]运维工程师(工作点: 杭州/北京) 目前社会招聘需求:年薪 10-20万 岗位名称:应用运维工程...

zhengshanda
2011/04/11
1K
3
型网站的架构设计问题----大型高并发高负载网站的系统架构

随着中国大型IT企业信息化速度的加快,大部分应用的数据量和访问量都急剧增加,大型企业网站正面临性能和高数据访问量的压力,而且对存储、安全以及信息检索等等方面都提出了更高的要求…… ...

springfe
2008/08/21
0
0
OLAP 数据查询引擎--Druid Analytics

Druid 是为大型数据集上实时探索查询的引擎,提供专为 OLAP 设计的开源分析数据存储系统,它的设计意图是在面对代码部署、机器故障以及其他产品系统遇到不测时能保持100%正常运行。它也可以用...

大土豆
2014/11/12
14.8K
2
druid-0.9.1-rc4 发布下载,OLAP 数据查询引擎

druid-0.8.3-rc2 发布下载: Source code (zip) Source code (tar.gz) Druid 是为大型数据集上实时探索查询的引擎,提供专为 OLAP 设计的开源分析数据存储系统,它的设计意图是在面对代码部署...

oschina
2016/06/15
2.9K
4

没有更多内容

加载失败,请刷新页面

加载更多

redis 学习2

网站 启动 服务端 启动redis 服务端 在redis 安装目录下 src 里面 ./redis-server & 可以指定 配置文件或者端口 客户端 在 redis 的安装目录里面的 src 里面 ./redis-cli 可以指定 指定 连接...

之渊
昨天
2
0
Spring boot 静态资源访问

0. 两个配置 spring.mvc.static-path-patternspring.resources.static-locations 1. application中需要先行的两个配置项 1.1 spring.mvc.static-path-pattern 这个配置项是告诉springboo......

moon888
昨天
4
0
hash slot(虚拟桶)

在分布式集群中,如何保证相同请求落到相同的机器上,并且后面的集群机器可以尽可能的均分请求,并且当扩容或down机的情况下能对原有集群影响最小。 round robin算法:是把数据mod后直接映射...

李朝强
昨天
4
0
Kafka 原理和实战

本文首发于 vivo互联网技术 微信公众号 https://mp.weixin.qq.com/s/bV8AhqAjQp4a_iXRfobkCQ 作者简介:郑志彬,毕业于华南理工大学计算机科学与技术(双语班)。先后从事过电子商务、开放平...

vivo互联网技术
昨天
24
0
java数据类型

基本类型: 整型:Byte,short,int,long 浮点型:float,double 字符型:char 布尔型:boolean 引用类型: 类类型: 接口类型: 数组类型: Byte 1字节 八位 -128 -------- 127 short 2字节...

audience_1
昨天
11
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部