从现在纯网站技术来看，因为开源模式的发展，现在搭建一个小网站非常容易，成本也很低，所以很多人把自己的创业方向定位在了互联网应用上。这些人大多不是很懂技术，或者不是很精通，而且网站开发和维护的知识很零散，学习成本太高，所以这篇文章结合了这些知识点。访问量几千的小网站，一天访问量一两百万的小网站，中间可能会出现什么问题，一开始如何做足够的工作，尽可能避免这些问题。

由于您的努力，您网站的访问量逐渐增加。在增加的过程中，问题也可能开始出现。因为带宽增加、硬件扩容、人员膨胀带来的成本增加是显而易见的，而且有相当一部分成本是由代码重构、架构重构，甚至是底层开发语言的更换造成的。最坏的情况是数据丢失，所有的努力都是徒劳的。这种成本支出，大部分在一开始是可以避免的，先打好基础，以后可以省心省力。

对于不同的初始投资成本，技术路线的选择是不同的。这里假设网站只是一个想法，第一年计划在服务器硬件带宽上投入5万左右。对于这笔钱，有很多选择，比如租用虚拟主机，租用单独的服务器，或者现在流行的私有云，或者托管服务器。对于前两种方案，当网站发展到一定规模后，需要进行迁移，然后重新规划，显然影响会更大。由于服务器托管是自行配置和完全可控的，具有一定规模的网站基本都是这种模式。对于使用自己托管服务器的网站，开头要注意以下几点——

一、开发语言

一般来说，技术人员（程序员）会根据自己的技术背景来选择自己最熟悉的语言，但是靠自己写程序是不可能永远的，所以在语言的选择上还是要花点心思的。首先明确一点，不管用什么语言，最终的代码质量还是要靠管理，所以我们从前期的开发成本来分析。目前国内流行的适用于网站的语言大致分为五个阵营：java、php、net、python、ruby。因为python和ruby在国内流行的比较晚，所以招人还是比较困难的。net平台的人比较多，但是后期需要解决性能问题的时候，对人员技能的要求比较高。剩下的java和php雇主可以说是最多的了。 Java和php从语言层面无法比较，但是对于起步阶段，应用几乎都是前端网站支持的，php上手容易，编写速度快，有比较大的优势。至于后端如行为分析、银行接口、异步消息处理等，真正需要的时候，需要根据不同的业务需求选择不同的语言。

二、代码版本管理

稍大的网站需要使用代码版本管理。代码版本管理最大的好处有两个，一是方便协同工作，二是有历史记录可以查询比较。代码版本管理软件有很多，比如vss/cvs/svn/hg等，目前国内比较流行，svn的普及度还是很高的。

假设选择了svn，则有几个注意事项。一是使用什么树结构。前期可能只有一个trunk，后期需要建立分支，比如开发分支，live分支，再后来，可能每个团队都有一个分支。建议一开始人少的时候选择两个分支，development和online。各功能本地测试无误后提交给开发分支。最后统一测试上线的时候可以合并到线上分支。如果每个人都建立自己的分支，合并的时候会浪费很多精力。对于一天修改几次的WEB应用来说，会花费太多的时间。

手动或自动将代码部署到服务器。手动部署相对简单。一般可以在服务器上直接svn update，或者找一个新的目录svn checkout，然后把web根目录给ln -s。应用程序越复杂，部署就越复杂。没有统一的标准。只是不要使用ftp上传。首先，上传时文件引用不一致错误率增加。第二，开发者的版本很容易和线上版本不一致，导致我本来想改个错别字变成回滚。如果有多台服务器，还是建议自动部署。换码机暂时退出当前服务池，更新完成后重新加入。

三、服务器硬件

在每个机房里，光是一台服务器就支持了无数个网站，但是如果资金稍微充足一点，建议至少三个标准配置，分别用于网页处理、数据库、备份。 web服务器至少需要8G内存，double sata raid1，如果经济稍微宽松一点，或者静态文件或者图片比较多，那就15k sas raid10。数据库至少要有16G内存和15k sas raid 10。备份服务器最好和数据库服务器配置在同一级别。硬件可以是品牌整机，也可以是兼容机，也可以是半品牌半组装，看经济能力。当然，这是一个典型的组合。某些类型应用的性能瓶颈最先出现在Web端，需要单独分析。

Web服务器可以运行程序并充当内存缓存，而数据库服务器只运行主数据库（如果是MySQL），备份服务器承担的更多。 Web配置、缓存配置、数据库配置必须和前面两者保持一致，所以如果WEB和数据库哪一个出现问题，很容易切换备份服务器临时替代，直到问题解决。需要注意的是，硬件随时都有可能坏掉，尤其是硬盘，所以最好把WEB服务器和数据库服务器放在一起，备份一定不能省略。备份必须是不同的和异步的，可能会出现断电和误操作。导致机器上的所有数据丢失。有许多开源备份解决方案可供选择。最简单的就是rsync，用crontab写的，定时同步。对于备份和切换，建议多做测试，选择最安全最适合业务的，尽量异地备份。

四、机房

尽量不要选择三种机房：联通访问特别慢的联通机房、电信访问特别慢的联通机房、电信机房

五、架构

在大方向上，被熟知的架构是web负载均衡+数据库主从+缓存+分布式存储+队列。在一开始，按照可扩展的原则设计和编程就可以。只是要多考虑缓存失效时的雪崩效应、主从同步的数据一致性和时间差、队列的稳定性和失败后的重试策略、文件存储的效率和备份方式等等意外情况。缓存失效、数据库复制中断、队列写入错误、电源损坏，在实际运维中经常发生，如果不注意这些，出现问题时恢复期可能会超出预期很长时间。

六、服务器软件

操作系统Linux很流行。在没有专业运维人员的情况下，应倾向于择使用的人多、社区活跃、配置方便、升级方便的发行版，例如RH系列、debian、ubuntu server等，硬件和操作系统要一起选择，看是否有适合的驱动，如果确定用某种商业软件或解决方案，也要提前知晓其对哪种操作系统支持最佳。web服务器方面，apache、nginx、lighttpd三大系列中，apache占有量还是最大，但是想把性能调教好还是需要很专业的，nginx和lighttpd在不需要太多调整的情况下可以达到一个比较不错的性能。无论选择什么软件，除非改过这些软件或你的程序真的不兼容新版本，否则尽量版本越新越好，版本新，意味着新特性增多、BUG减少、性能增加。一个典型的php网站，基本上大多数人都没改过任何服务器软件源代码，绝大多数情况是能平稳的升级到新版本的。类似于jdk5到 jdk6，python2到python3这类变动比较大的升级还是比较少见的。看看ChangeLog，看看升级说明，结合自己情况评估测试一下，越早升级越好，升级的越晚，所花费的成本越高。对于软件包，尽量使用发行版内置的包管理工具，没有特殊要求时不建议自己编译，那样对将来运维不利。

七、数据库

几乎所有操作最后都要落到数据库身上，它又最难扩展（存储也挺难）。数据库常见的扩展方法有复制、分片，设计时要考虑到每种应用的数据如何复制、分片，当然这种考虑一般会推迟到技术设计时期。在初期进行数据库结构设计时，要根据不同的业务类型和增长量预期来考虑是否要分库、分区，并且尽量不要使用联合查询、不使用自增ID以方便分片。复制延时问题、主从数据库数据一致性问题，可以自己写或者用已有的运维工具进行检测。

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

另外，现在流行一种概念叫NoSQL，可以理解为非传统关系型数据库。实际应用中，网站有着越来越多的密集写操作、上亿的简单关系数据读取、热备等，这都不是传统关系数据库所擅长的，于是就产生了很多非关系型数据库，比如Redis/TC&TT/MongoDB/Memcachedb等，在测试中，这些几乎都达到了每秒至少一万次的写操作，内存型的甚至5万以上。在设计时，可根据业务特点和性能要求来选择是否使用这类数据库。例如MongoDB，几句配置就可以组建一个复制+自动分片+failover的环境，文档化的存储也简化了传统设计库结构再开发的模式。但是当你决定采用一项技术时，一定要真正了解其优劣，例如可能你所选择的技术并不能支持你所需要的事务和数据一致性要求。

八、文件存储

存储的分布几乎跟数据库扩展一样困难，不过只有百万的PV的情况下，磁盘IO方面一般不会成大问题，一两台采用SATA做条带RAID的机器可以应付，反而是自己做异步备份比较复杂，因为小文件多。如果只有一台机器做存储，可以做简单的优化，例如放最小缩略图的分区和放中等缩略图的分区，根据平均大小调整一下块大小。存储要规划好目录结构，否则文件增多后维护起来复杂，也不利于扩展。同时还要考虑将来扩容，例如采用LVM，或者把文件根据不同规则散列到不同机器。磁盘IO繁重的情况下更容易出现故障，所以要做好备份，若发现有盘坏掉，要马上行动更换，很多人的硬盘都是坏了一块之后，接二连三的坏下去。

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

九、程序

一定硬件条件下，应用能承载多少访问量，很大一部分也取决于程序如何写。程序写的不好，可能一万的访问都承载不了，写的好，可能一两台机器就能承担几百万PV。越是复杂、数据实时性要求越高的应用，优化起来越难，但对普通网站有一个统一的思路，就是尽量向前端优化、减少数据库操作、减少磁盘IO。向前端优化指的是，在不影响功能和体验的情况下，能在浏览器执行的不要在服务端执行，能在缓存服务器上直接返回的不要到应用服务器，程序能直接取得的结果不要到外部取得，本机内能取得的数据不要到远程取，内存能取到的不要到磁盘取，缓存中有的不要去数据库查询。减少数据库操作指减少更新次数、缓存结果减少查询次数、将数据库执行的操作尽可能的让你的程序完成（例如join查询），减少磁盘IO指尽量不使用文件系统作为缓存、减少读写文件次数等。程序优化永远要优化慢的部分，换语法是无法“优化”的。

然而编程时不应该把重点放在优化上，应该关注扩展性。当今的WEB应用，需求变化非常之快，适应多种需求的架构是不存在的，我们的扩展性就要把要点放在跟底层交互的架构上，例如持久化数据的存取规则、缓存的存取规则等，还有一些共用服务，例如用户信息等。先把不变的部分做完善，剩下的部分就很容易将精力放在业务逻辑上面了。

关于作者

刘志一，从1999年做个人网站开始一直专注于互联网，目前就职于一家垂直行业C2C网站，做产品和开发方面工作。

我们专注高端建站，小程序开发、软件系统定制开发、BUG修复、物联网开发、各类API接口对接开发等。十余年开发经验，每一个项目承诺做到满意为止，多一次对比，一定让您多一份收获！