试谈百万级访问网站前期的技术准备

1、对互联网有了解的人都有自己的方法，有人就把方法付诸实现，做个网站然后开始运营。事实上从纯网站技术上来讲，因为开源模式的进展，现在建一个小网站 差不多专门简单也专门廉价。当访问量到达一定数量级的时候成本就开始飙升了，问题也开始显现了。因为带宽的增加、硬件的扩展、人员的扩张所带来的成本提高是显而 易见的，而还有相当大的一部分成本是因为代码重构、架构重构，甚至底层开发语言更换引起的，最惨的确实是数据丢失，辛辛苦苦好几年，一夜回到创业前。减少成本确实是增加利润。专门多情况，我们在一开始就能够幸免，先打好基础，往后能够省专门多精力，少操专门多心。假设你是一个参与创业的技术人员，当前一穷二白，什么都要自己

2、做，自己出钞票，初期几十万的资金，做一个应用不是特不复杂的网站，那么就要注意以下几点：一、开发语言一般来讲，技术人员（程序员）创业差不多上依照自己技术背景选择自己最熟悉的语言，只是考虑到不可能永久是您一个人写程序，这点还得认真想想。不管用什么语言，最终代码质量是看治理，因此我们依旧从纯语言层面来讲实际一点。现在流行的 HYPERLINK /zh_CN/ t _blank java、 HYPERLINK t _blank php、 HYPERLINK /net/ t _blank .net、 HYPERLINK / t _blank python、 HYPERLINK /en/ t _blank

3、 ruby都 有自己的优劣，python和ruby，现在人员依旧相对难招一些，性能优化也会费些力气，.net平台买不起windows server。java、php用的依旧最多。关于初期，应用几乎差不多上靠前端支撑的网站来讲，php的优势稍大一些，入门简单、设计模式简单、写起来快、 性能足够等，只是不注重设计模式也是它的劣势，容易变得松散，隐藏bug稍多、难以维护。java的优势在于整套治理流程差不多有专门多成熟工具来辅助，强类 型也能幸免一些弱智BUG，大多数JAVA程序员比较注重设计模式，不管实不实际，代码格式看起来依旧不错的。这也是个劣势，初学者可能太注重模式而专门难 解决实际需求。前端

4、不只是html、css这类。整个负责跟用户交互的部分差不多上前端，包括处理程序。这类程序依旧建议用php，要紧缘故确实是开发迅速、从业人员广泛。至于后端例如行为分析、银行接口、异步消息处理等，随便用什么程序，那个只能是依照不同业务需求来选择不同语言了。二、代码版本治理假如开发人员之间的网络速度差不多，就 HYPERLINK / t _blank SVN；比较分散例如跨国，就 HYPERLINK / o Mercurial SCM(hg) t _blank hg。大多数人依旧svn的.假设选了svn，那么有几点考虑。一是采纳什么树结构。初期可能只有一条主干，往后就需要建立分支，例如一条开发分支，

5、一条上线分支，再往后，可能 要每个小组一个分支。建议一开始人少时选择两条分支，开发和线上，每个功能本地测试无误后提交到开发分支，最后统一测试，能够上线时合并到上线分支。假如 喜爱把svn当做移动硬盘用，写一点就commit一次也无所谓，确实是合并的时候头大一些，这些人能够自己建个分支甚至建立个本地代码仓库，随便往自己的 分支提交，测试完毕后再提交到开发分支上。部署，能够手工部署也能够自动部署。手工部署相对简单，一般是直接在服务器上svn update，或者找个新目录svn checkout，再把web root给ln -s过去。应用越复杂，部署越复杂，没有什么统一标准，只要不再用ftp上传那种

6、形式就好，一是上传时文件引用不一致错误率增加，二是专门容易出现开发人员 的版本跟线上版本不一致，导致本来想改个错字结果变成回滚的杯具。假如有多台服务器依旧建议自动部署，更换代码的机器从当前服务池中临时撤出，更新完毕后 再重新加入。不管项目多小，养成使用版本治理的好适应，最起码还能够当做你的备份，我的 HYPERLINK http:/zhiyi.us http:/zhiyi.us 尽管确实是一个wordpress，可依旧svn了，只改动一两句css那也是劳动成果。三、服务器硬件不艳羡大客户和有钞票人，看看机房散户区，一台服务器孤独的支撑的网站数不清。假如资金略微充足，建议至少三台的标准配置，分不

7、用作web处理、数据 库、备份。web服务器至少要8G内存，双sata raid1，假如经济略微宽松，或静态文件或图片多，则15k sas raid1+0。数据库至少16G内存，15k sas raid 1+0。备份服务器最好跟数据库服务器同等配置。硬件能够自己买品牌的底板，也确实是机箱配主板和硬盘盒，CPU内存硬盘都自己配，也能够上整套品牌，也可 以兼容机。三台机器，市场行情6、7万也就配齐了。web服务器能够既跑程序又当内存缓存，数据库服务器则只跑主数据库（假如是 HYPERLINK /products/standard/ o MySQL Standard Edition t _blank

8、 MySQL的话），备份服务器干的活就相对多一些，web配置、缓存配置、数据库配置都要跟前两台一致，如此WEB和数据库任意一台出问题，把备份服务器换个ip就切换上去了。备份策略，能够 HYPERLINK / o DRBD t _blank drbd，能够 HYPERLINK .au/rsync/ o rsync t _blank rsync，或者其他的专门多专门多的开源备份方案可选择。rsync最简单，放cron里自己跑就行。备份和切换，建议多做测试，选最安全最适合业务的，同时尽可能异地备份。四、机房三种机房尽量不要选：联通访问特不慢的电信机房、电信访问特不慢的联通机房、电信联通访问特不慢的移

9、动或铁通机房。那网通机房呢？亲，网通联通N久 往常合并改叫联通了。多多查找，实地参观，多多测试，多方打探，北京、上海、广州等各个主节点都市，依旧有专门多优质机房的，找个网络质量好，治理严格的机 房，特不是治理要严格，千万不网站无法访问了，打个电话过去才明白不人维护时把你网线碰掉了，这比DOS都头疼。自己扯了几根光纤就称为机房的，看您抗风 险程度和心理素养了。机房能够讲是特不重要，直接关系到网站访问速度，网站访问速度直接关系到用户体验，我能够翻墙看风景，但买个网游vpn才能打开你这 个还不如何知名的网站就有难度了。或许您网站的ajax专门出色，但是document如何也不ready，一些代码永久

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

11、K / o nginx t _blank nginx、php、mysql，几乎是标配，我们除了看名字，还得选版本。Linux发行版众多，只要没专门要求，就选个用的人最多的，社区最活跃的，配置最方便的，软件包最全最新的，例如 HYPERLINK / o Debian t _blank debian、 HYPERLINK o Ubuntu t _blank ubuntu。 至于RHEL之类的嘛，你用只能在RHEL上才能运行的软件么？剩下的nginx、php、mysql、activemq、其他的等等，除非你改过这些软 件或你的程序确实不兼容新版本，否则尽量版本越新越好，版本新，意味着新特性增多、BU

12、G减少、性能增加。总有些道听途讲的人跟你讲老的版本稳定。所谓稳 定，是相关于专门业务来讲的，而就一个php写的网站，大多数人都没改过任何服务器软件源代码，绝大多数情况是能平稳的升级到新版本的。类似于jdk5到 jdk6，python2到python3这类变动比较大的升级依旧比较少见的。看看ChangeLog，看看升级讲明，结合自己情况评估一下，越早升级 越好，不人家都用php6写程序了这边还php4的逛游呢。优秀的开源程序升级依旧专门负责任的，看好文档，不怕。以上这六点预备完毕，现在我们有了运行环境，有了差不多架构骨架，有了备份和切换方案，应该开始着手设计开发方面的情况了。开发方面的情况许多，

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

14、注意数据一 致性。复制策略方面，多主多从结构也最好一开始就设计好，代码直接按照多主多从来编写，用一些小技巧来幸免复制延时问题，同时还要解决多数据库数据是否一致，能够自己写或者找现成的运维工具。分片策略。总会有那么几个表数据量超大，这时分片必不可免。分片有专门多策略，从简单的分区到依照热度自动调整，依照具体业务选择一个适合自己的。幸免自增ID作为主键，不利于分片。用存储过程是比较难扩展的，这种情形多发生于传统C/S，特不是OA系统转换过来的开发人员。低成本网站不是一两台小型机跑一个数据库处理所有业务的模式，是机海作战。方便水平扩展比那点预分析时刻和网络传输流量要重要的多的多。NoSQL。这只是一

15、个概念。实际应用中，网站有着越来越多的密集写操作、上亿的简单关系数据读取、热备等，这都不是传统关系数据库所擅长的，因此 就产生了专门多非关系型数据库，比如Redis/TC&TT/MongoDB/Memcachedb等，在测试中，这些几乎都达到了每秒至少一万次 的写操作，内存型的甚至5万以上。例如MongoDB，几句配置就能够组建一个复制+自动分片+failover的环境，文档化的存储也简化了传统设计库 结构再开发的模式。专门多业务是能够用这类数据库来替代mysql的。八、缓存。数据库专门脆弱，一定要有缓存在前面挡着，事实上我们优化速度，几乎确实是优化缓存，能用缓存的地点，就不要再跑到后端数据库

16、那折腾。缓存有持久化缓存、 内存缓存，生成静态页面是最容易理解的持久化缓存了，还有专门多比如varnish的分块缓存、前面提到的memcachedb等，内存缓 存，memcached首当其冲。缓存更新可用被动更新和主动更新。被动更新的好处是设计简单，缓存空了就自动去数据库取数据再把缓存填上，但容易引发雪 崩效应，一旦缓存大面积失效，数据库的压力直线上升专门可能挂掉。主动缓存可幸免这点然而可能引发程序取不到数据的问题。这两者之间如何配合，程序设计要多 动脑筋。九、队列。用户一个操作专门可能引发一系列资源和功能的调动，这些调动假如同时发生，压力无法操纵，用户体验也不行，能够把如此一些操作放入队列，

17、由另几个模块 去异步执行，例如发送邮件，发送手机短信。开源队列服务器专门多，性能要求不高用数据库当做队列也能够，只要保证程序读写队列的接口不变，底层队列服务可随 时更换就能够，类似Zend Framework里的Zend_Queue类，java.util.Queue接口等。十、文件存储。除了结构化数据，我们经常要存放其他的数据，像图片之类的。这类数据数量繁多、访问量大。典型的确实是图片，从用户头像到用户上传的照片，还要生成不 同的缩略图尺寸。存储的分布几乎跟数据库扩展一样困难。不使用专业存储的情况下，差不多差不多上靠自己的NAS。这就涉及到结构。拿图片存储举例，图片是特不容 易产生热点的，有些

18、图片上传后就不再有人看，有些可能每天被访问数十万次，而且大量小文件的异步备份也专门耗费时刻。为了今后图片走cdn做预备，一开始最好就将图片的域名分开，且不用主域名。专门多网站都将cookie设置到了.domain.ltd，假如图片也在那个域名下，专门可能因为cookie而造成缓存失效，同时占多余流量，还可能因为扫瞄器并发线程限制造成访问缓慢。假如用一般的文件系统存储图片，有一个简单的方法。计算文件的hash值，比如md5，以结果第一位作为第一级目录，如此第一级有16个目录。从0 到F，能够把那个字母作为域名，0.到（客户端dns压力会增大），还能够扩展到最多16个NAS集群 上。第二级可用年月

19、例如，201011，第三级用日，第四级可选，依照上传量，比如am/pm，甚至小时。最终的目录结构可能会是 e/201008/25/am/e43ae391c839d82801920cf.jpg。rsync备份时能够用脚本只同步某年某日某时的文件，幸免计 算大量文件带来的开销。因此最好是能用专门的分布式文件系统或更专业点的存储解决方案。下面，我们要谈谈代码了。这一系列的最后一篇写给一般编程人员，假如不感兴趣可直接看本文最后几段。开始设计代码结构之前，先回忆一下之前预备过的情况：我们有负载均衡的 WEB服务器，有主从DB服务器并可能分片，有缓存，有可扩展的存储。在组织代码的各个方面，跟这些预备息息相

20、关，我一二三的列出来分不讲，同时每一条都 以“前面讲到”那个经典句式开头，为了方便对比。不着急看经典句式，我思维跳跃了，插一段。实际开发中，我们总会在性能和代码优雅性上作折中。关于当今的计算机和语言解释器，多 几层少几层对象调 用、声明变量为Map依旧HashMap这种问题是最后才需要考虑的问题，永久要考虑系统最慢的部分，从最慢的部分解决。例如看看你用的ORM是不是做了 专门多你用不到的情况，是不是有重复的数据调用。我们做的是web应用开发，不是底层框架API，代码易读易明白是保证质量专门重要的一方面，你的程序是为了什 么而设计，有不同的方法罢了，那个话题另起一篇文章来讲，扯远了，想交流可关注

21、我的微博 HYPERLINK /liuzhiyi /liuzhiyi，咱接着 HYPERLINK http:/zhiyi.us/internet/thinking-twice-before-building-your-site-one.html 前面讲到，WEB 服务器是要做负载均衡的，图片服务器是要分开的。关于这点，代码在处理客户端状态时，不要把状态放到单机上，举例，不要用文件session，嗯，常识。 假如有可能，最好在一开始就做好用户单点认证的统一接口，包括跨域如何推断状态、静态页面如何推断状态，需要登录时的跳转和返回参数定义，底层给好接口， 应用层直接就用（可参考 HYPERLINK

22、/intl/zh-CN/appengine/ GAE的 user服务）。登录方面的设计要考虑移动设备的特性，比如电脑能够用浮动层窗口，但NOKIA自带的扫瞄器或UCWEB就无法处理这种表现形式，程序一 定既能处理AJAX请求又能直接通过URL来处理请求。图片服务器分开，资源文件最好也布局到图片服务器，也确实是WEB服务器只服务动态程序。尽管开发测 试时略微复杂（因为需要绝对URI才能访问），但今后页面前端优化上会轻松许多，同时你的WEB服务器IO优化也轻松许多。程序引用资源文件时，要有一个 统一的处理方法，在方法内部能够自动完成专门多情况，例如将css/js依照组合，拼成一个文件，或者自动在生

23、成的URI后面加上QUERYSTRING， 假现在后前端用了缓存服务，那生成QUERYSTRING是最简单的刷新服务端缓存和客户端缓存的方法。 HYPERLINK http:/zhiyi.us/internet/thinking-twice-before-building-your-site-two.html 前面讲到， 数据库会有复制，可能会多主多从，可能会分片。我们程序在处理数据的过程中，最好能抽象出来单独放做一层。拿现在流行的MVC模式来讲，确实是在M层下方再 放一个数据层，那个数据层不是通常所讲的JDBC/PDO/ActiveRecord等，而是你自己的存取数据层，仅对外暴露方法，隐藏

24、数据存取细节。这 个数据层内部不要怕写的难看，但一定要提供所有的数据存储功能，其他任何层次不要看到跟数据库打交道的字眼。之因此如此做，是因为在单关系数据库的情况 下，可能会SELECTJOIN或直接INSERTINTO，可你可能会将一些表放到key-value数据库里存储，或者分片，这么做之后原来 的语句和方式要全部改变，假如过于分散，则移植时会耗费专门大精力，或得到一个专门大的Model。在数据层面的设计上，尽量幸免JOIN查询，我们能够多做 冗余，多做缓存，每种数据尽量只需要一次查询，然后在你的程序里面进行组合。关于比较复杂的数据组合，在实时性要求不高的情况下，可采纳异步处理，用户访 问时

25、只取处理后的结果。在关于主键的处理上，幸免使用自增ID，能够用一定规则生成的唯一值当做主键，这种主键是最简单的分片分布策略。即使用自增ID， 也最好用一个自增ID发生器，否则从数据库不小心被写了一下，那主键专门容易冲突。前面讲到，咱数据库前面还有某些缓存挡着。不把mysql的query cache当缓存，应用稍复杂的时候QUERY CACHE反而会成为累赘。缓存跟数据库和业务结合的专门紧密，正因为跟业务关系紧密，因此这点没有放之四海而皆准的方法。但我们依旧有一些规则可参照。规 则一：越接近前端，缓存的颗粒度越大。例如在WEB最前端缓存整个页面，再往后一层缓存部分页面区域，再往后缓存区域内的单条

26、记录。因为越靠近后端，我们 的可操作性越灵活，同时变化最多的前端代码也比较方便编写。在实践中，因为产品需求变化速度特不快，迭代周期越来越短，有时专门难将Controller和 Model分的那么清晰，Controller层面处理部分缓存必不可免，但要保证假如出现这种情况，Controller所操作的缓存一定不要阻碍其他 数据需求方，也确实是要保证那个缓存数据只有这一个Controller在用。规则二：没有缓存时程序不能出错。在不考虑缓存失效引发的雪崩效应时，你的程 序要有缓存跟没缓存一个样，不能像新浪微博一样，缓存一失效，粉丝微博全空，整个应用都乱套了。在缓存必不可少的情况下，给用户出错信息都

27、比给一个让人误 解的信息强。规则三，缓存更新要保证原子性或称作线程安全，特不是采纳被动缓存的方式时，专门可能两个用户访问时导致同一个缓存被更新，通常情况这不是大问 题，可缓存失效后重建时专门可能是引发连锁反应的缘故之一。规则四：缓存也是有成本的。不只是技术成本，还有人工时刻成本。假如一个功能使用缓存和不使用， 在可预见的访问量情况下区不微小，但使用缓存会使复杂度增加，那就不用，我们能够加个TODO标注，在下次迭代的时候加上缓存处理。前面讲到，文件存储是独立的，那么所有的文件操作就差不多上远程调用。能够在文件服务器上提供一个专门简单的RESTful接口，也能够提供xmlrpc 或json serveice，WEB服务器端所生成和处理的文件，全部通过接口通知文件服务器去处理，WEB服务器本身不要提供任何文件存储。你会发觉专门多大网站的 上传图片跟保存文章是分两步完成的，确实是基于那个缘故。以上几条“前面讲到”，事实上许多人都讲过，我也只是结合前几篇文章用自己的话重复了一遍，真正分析起来精髓专门简单除了良好的功能逻辑分层，我们 还要为数据库存储、缓存、队列、文件服务等程序外层资源调用单独设计接口，你能够把你的程序想象成是运行在 Amazon EC2