机械网站建设方案书

编辑推荐阅读此系列文章：

1、百万级访问网站前期的技术准备（上）

2、百万级访问网站前期的技术准备（中）

这一系列的最后一篇写给普通编程人员，如果不感兴趣可直接看本文最后几段。

开始设计代码结构之前，先回顾一下之前准备过的事情：我们有负载均衡的WEB服务器，有主从DB服务器并可能分片，有缓存，有可扩展的存储。在组织代码的各个方面，跟这些准备息息相关，我一二三的列出来分别说，并且每一条都以前面讲到这个经典句式开头，为了方便对照。

别着急看经典句式，我思维跳跃了，插一段。实际开发中，我们总会在性能和代码优雅性上作折中。对于当今的计算机和语言解释器，多几层少几层对象调用、声明变量为Map还是HashMap这种问题是最后才机械网站建设方案书需要考虑的问题，永远要考虑系统最慢的部分，从最慢的部分解决。例如看看你用的ORM是不是做了很多你用不到的事情，是不是有重复的数据调用。我们做的是web应用开发，不是底层框架API，代码易读易懂是保证质量很重要的一方面，你的程序是为了什么而设计，有不同的方法……算了，这个话题另起一篇文章来说，扯远了，想交流可关注我的微博 http://t.sina.com.cn/liuzhiyi，咱继续……

前面讲到，WEB服务器是要做负载均衡的，图片服务器是要分开的。对于这点，代码在处理客户端状态时，不要把状态放到单机上，举例，不要用文件session，嗯，常识。如果有可能，最好在一开始就做好用户单点认证的统一接口，包括跨域如何判断状态、静态页面如何判断状态，需要登录时的跳转和返回参数定义，底层给好接口，应用层直接就用（可参考GAE的user服务）。登录方面的设计要考虑移动设备的特性，比如电脑可以用浮动层窗口，但NOKIA自带的浏览器或UCWEB就无法处理这种表现形式，程序一定既能处理AJAX请求又能直接通过URL来处理请求。图片服务器分开，资源文件最好也布局到图片服务器，也就是WEB服务器只服务动态程序。虽然开发测试时稍微复杂（因为需要绝对URI才能访问），但将来页面前端优化上会轻松许多，并且你的WEB服务器IO优化也轻松许多。程序引用资源文件时，要有一个统一的处理方法，在方法内部可以自动完成很多事情，例如将css/js根据组合，拼成一个文件，或者自动在生成的URI后面加上QUERYSTRING，如果将来前端用了缓存服务，那生成QUERYSTRING是最简单的刷新服务端缓存和客户端缓存的办法。

前面讲到，数据库会有复制，可能会多主多从，可能会分片。我们程序在处理数据的过程中，最好能抽象出来单独放做一层。拿现在流行的MVC模式来说，就是在M层下方再放一个数据层，这个数据层不是通常所说的JDBC/PDO/ActiveRecord等，而是你自己的存取数据层，仅对外暴露方法，隐藏数据存取细节。这个数据层内部不要怕写的难看，但一定要提供所有的数据存储功能，其他任何层次不要看到跟数据库打交道的字眼。之所以这样做，是因为在单关系数据库的情况下，可能会SELECT…JOIN…或直接INSERT…INTO…，可你可能会将一些表放到key-value数据库里存储，企业官网建设或者分片，这么做之后原来的语句和方式要全部改变，如果过于分散，则移植时会耗费很大精力，或得到一个很大的Model。在数据层面的设计上，尽量避免JOIN查询，我们可以多做冗余，多做缓存，每种数据尽量只需要一次查询，然后在你的程序里面进行组合。对于比较复杂的数据组合，在实时性要求不高的情况下，可采用异步处理，用户访问时只取处理后的结果。在对于主键的处理上，避免使用自增ID，可以用一定规则生成的唯一值当做主键，这种主键是最简单的分片分布策略。即使用自增ID，也最好用一个自增ID发生器，否则从数据库不小心被写了一下，那主键很容易冲突。

前面讲到，咱数据库前面还有某些缓存挡着。别把mysql的query cache当缓存，应用稍复杂的时候QUERY CACHE反而会成为累赘。缓存跟数据库和业务结合的很紧密，正因为跟业务关系紧密，所以这点没有放之四海而皆准的方法。但我们还是有一些规则可参照。规则一：越接近前端，缓存的颗粒度越大。例如在WEB最前端缓存整个页面，再往后一层缓存部分页面区域，再往后缓存区域内的单条记录。因为越靠近后端，我们的可操作性越灵活，并且变化最多的前端代码也比较方便编写。在实践中，因为产品需求变化速度非常快，迭代周期越来越短，有时很难将Controller和Model分的那么清楚，Controller层面处理部分缓存必不可免，但要保证如果出现这种情况，Controller所操作的缓存一定不要影响其他数据需求方，也就是要保证这个缓存数据只有这一个Controller在用。规则二：没有缓存时程序不能出错。在不考虑缓存失效引发的雪崩效应时，你的程序要有缓存跟没缓存一个样，不能像新浪微博一样，缓存一失效，粉丝微博全空，整个应用都乱套了。在缓存必不可少的情况下，给用户出错信息都比给一个让人误解的信息强。规则三，缓存更新要保证原子性或称作线程安全，特别是采用被动缓存的方式时，很可能两个用户访问时导致同一昭通网站建设公司个缓存被更新，通常情况这不是大问题，可缓存失效后重建时很可能是引发连锁反应的原因之一。规则四：缓存也是有成本的。不只是技术成本，还有人工时间成本。如果一个功能使用缓存和不使用，在可预见的访问量情况下区别微小，但使用缓存会使复杂度增加，那就不用，我们可以加个TODO标注，在下次迭代的时候加上缓存处理。

前面讲到，文件存储是独立的，那么所有的文件操作就都是远程调用。可以在文件服务器上提供一个很简单的RESTful接口，也可以提供xmlrpc或json serveice，WEB服务器端所生成和处理的文件，全部通过接口通知文件服务器去处理，WEB服务器本身不要提供任何文件存储。你会发现很多大网站的上传图片跟保存文章是分两步完成的，就是基于这个原因。

以上几条前面讲到，其实无数人都讲过，我也只是结合前几篇文章用自己的话重复了一遍，真正分析起来精髓很简单除了良好的功能逻辑分层，我们还要为数据库存储、缓存、队列、文件服务等程序外层资源调用单独设计接口，你可以把你的程序想象成是运行在 Amazon EC2 上并用他的所有web service服务，你的数据库就是它的SimpleDB，你的队列就是他的SQS，你的存储就是他的S3，唯一不同是amazon的接口是远程调用，你的是内部调用。

将支撑服务接口化，意味着将MySQL更换到PostgreSQL不需要更改业务处理程序，移植团队甚至不需要跟业务开发团队过多沟通；意味着业务开发团队是对接口编程而不是对数据库编程；意味着不会因为某个业务开发人员的失误而拖垮性能。

对程序扫盲不感兴趣的直接看这里

产品设计完了，程序框架搭完了，可能有矛盾在这个节骨眼儿产生了。不断有产品设计抱怨说他的创意没实现到预期效果，有程序员抱怨说产品设计不切实际。这种抱怨多缘于产品人员不懂技术，技术人员不理解产品。从广义上来讲，产品包含市场策略、营销手段、功能设计，产品和技术在争论时往往把焦点放在功能上，而实际重点是，实现这个功能所消耗的成海南网站建设公司本跟能这个功能带来的利益能否换算，能否取其轻重。若可以，争议解决。若不能，则抛硬币看运气。因为一个功能的加强而引发指标井喷，或因项目拖延而导致贻误战机的例子比比皆是。激进的决策者注重利益，保守的决策者注重损失，聪明的决策者会考虑这个问题是否真的那么严重。

关系到未来的事情谁都说不准，要不怎么说创业一半靠运气呢。不过总有能说的准的事情，那就得靠数据说话。

没有100%也有99.9%的网站安装了访问统计代码，连我的 http://zhiyi.us 也不例外，新闻联播也总说科学决策科学发展的。有了统计，能确定的事情就很多了。例如，可以根据来源-目标转化率来分析哪类渠道的人均获取成本低，根据来源-内容访问猜测用户跳出率原因，根据用户点击行为判断链接位置是否合理等。将数据以不同方式组合起来，找到内在联系，分析内因外因，制定对应策略，减少拍脑门决策。靠数据支撑运营是个非常专业的事情，虽然不懂深奥的数学模型不会复杂的公式计算，渐渐学会因为A所以B，因为A和B所以C还是相对简单的。

文章作者：刘志一 （转载请注明出处链接及作者）

文章来源：http://zhiyi.us/