进行web开发之前应该考虑的因素

功能实现

　　这个自不必说。

性能与可伸缩性

　　根据预期的访问量，评估机器负载情况。如果在可预期的未来一台服务器可以撑得住，则没必要使用多台服务器。需要对多个环节进行性能评估：web服务器、逻辑服务器、DB等等。同时每个环节都可以考虑是否需要缓存。

　　在web服务器层面，有一个重要的点，即系统的 URL 选择。首先，要尽最大可能避免访问量差别很大的系统共用一个域名。因为随着系统的发展，很有可能需要对访问量大的系统进行扩容。扩容引入分流机制。如果这两个系统共用同一个域名，且 URL 的区分度不高，会对分流机制造成很大的障碍。虽然说有些系统或模块（或页面）的 URL 相对可变，但是对于开放给外部（尤其是公司外部）访问的 URL 来说，变更是不可能的。这种类型的 URL 本质上是 API。这又牵扯到另外一个主题：《API 设计》。这里暂且 pass。

　　在逻辑服务器层面，切记读写分离，如果预计系统不需要多台服务器，也该为读写分离留下后路。还有一点需要关注的是，不同的服务之间互相访问，不要直接以 ip:端口 的形式，而尽量以域名的方式。如果是用前者，后期扩容时，也可以引入虚拟 ip 补救。

　　在 DB 层面，考虑是否需要引入 memcache 或 redis 之类的缓存。考虑是否需要做 M-S。另外，考虑 DB 层是直接对上层暴露 ip 端口，还是引入一个抽象层（如虚拟 ip）。再者，做库表设计时，考虑是否应该分库、分表。

　　在引入了多服务器架构之后，随之而来的是数据同步与合并问题。比如，A 服务器上产生了一张图片，可能需要把它同步到 B 服务器上。或者数据库需要做 M-S 同步。需要合并的，最典型是日志。如果日志分散在许多台机器上，定位问题和分析日志都显得非常麻烦，需要有一种合并机制。还有一个也是很重要的点，即 session 的合并。同一个用户，可能第一次请求到 A 服务器上，下一次请求到 B 服务器上，如何使这两台机器能共享一个 session，是一个需要解决的问题。一个解决方案是使用 redis 存储会话信息。

　　在多服务器架构下，动态脚本和静态文件分离是一个比较好的经验。这里的分离指使用不同的域名，代码文件放在不同的机器上。这是因为动态脚本和静态文件的性能属性差别比较大。将它们分开可以对它们使用不同的部署策略。例如，静态文件可以更有效地利用浏览器缓存。

可用性

　　可用性这个方面，有很多与上一个重叠的地方，因为都涉及到多服务器。他们之间的区别是：可伸缩性考虑的是系统能不能撑得住很大的访问量，以及当访问量意外性的出现暴增时，系统能否快速提升自身的处理能力来进行响应。而可用性关注的问题是：这个服务的重要性如何？如果特别重要，怎么保证它不会挂？

　　提升可用性的常用手段之一是引入冗余灾备措施。同样涵盖上面提到的那几个环节。如果要引入冗余，切记重点关注两个问题：1，单点故障；2，跨机房。

　　单点故障。假设把架构设计成：前端两台 web 服务器，域名通过 dns 解析到这两台机器上，逻辑服务器也两台，但是 DB 只有一台。那么 DB 这个环节就是一个单点。如果 DB 服务器挂掉，整个系统都会挂掉。前面设计了两台 web 服务器和两台逻辑服务器都没有任何意义。

　　然后说一下跨机房。跨机房是一个很大的挑战，除非十分必要，否则尽量不要使用跨机房架构。因为通常情况下，我们几乎不可能把所有的服务都在两个地方部署一份。99.99% 会出现这样的情况：部署了跨机房的系统，需要访问另外一个只在一个机房有部署的服务。这个时候，其中一个机房必须通过通道访问另外一个机房。这样，两个机房就不是完全一样的了。此外，两个机房的数据、日志等都需要同步、合并。这些都会使运维的难度大大提高。

　　除了冗余之外，考虑可用性，还应想到监控措施。监控有多种方法。常用的方法有：

　　1，日志或数据分析。服务器上后台跑进程，不停地对日志或类日志的数据进行分析，一旦发生异常，报警。

　　2，代码中植入对服务或接口的监控。当用代码访问一个服务时，检查其响应。如果响应异常，报警。

　　3，心跳式轮询检测。每隔一段时间向服务发送特殊的请求，检查其响应。如果响应异常，报警。

　　4，服务器负载监控。例如 CPU、内存、硬盘、IO、cgi 进程数等等。有些情况下这些工作有运维工程师去做。

　　5，代码中植入对响应时间的统计，并另起后台进程，对响应时间进行监控。

　　其中，1、2、4、5是系统内部的监控，3是系统外部监控。系统内部监控可以更加细致，能监控到一些外部监控不到的东西。但是，一旦系统本身挂掉（例如服务器挂了），内部监控也会失效。

可扩展性

　　这个方面涉及到软件的逻辑架构，更多的与业务相关。考虑可扩展性的目的是为了应对需求变更。这要求首先对需求有较深入的了解，并且能够大致把握到需求变更的方向。这之后，在代码结构层面，为预期的变更方向留下空间。要求设计者具有非常丰富的编码经验和对设计模式有深刻的理解。

可调试性

　　这个方面容易被忽略，却是非常重要的一环。web 系统的部署环境和交互流程越来越复杂，有时候定位一个线上问题非常困难。通常是开发环境无法重现，同时又获得不到足够的信息进行定位。因此这个因素应该在系统设计时就考虑进去：当出现问题时，如何方便地进行定位和调试？这里分服务端和页面两个部分考虑。

　　日志不必说，是重要的信息来源。服务端写日志，需要对日志进行有效的组织（这里也是一门学问）。

　　另外，服务端需要注意的一点，是统一的错误码处理。错误码管理混乱会影响问题的定位。最好的情况是，错误码分得很细，并且保证绝对无重复。这样，开发一拿到错误码，立刻就能大概判断出问题所在。

　　再者，服务端，可能需要备好调试工具。可以理解为后门，但是只有经过授权才能使用。

　　前端写不了日志是个大问题，需要另寻途径把错误信息拿到手。最差的方法是牺牲部分用户体验，把错误码以某种方式展示出来，然后通过询问用户来获得错误码。这种方式不建议使用。更好的做法是，在前端搜集错误信息，然后通过接口上报到服务器进行存储。

安全

　　安全的重要性再怎么强调都不为过。xss、csrf、sql注入、敏感信息泄露、刷接口、重放等等等等。安全领域涉及到的东西很多。

数据统计与后台

　　考虑系统是否需要后台管理、是否需要收集数据进行统计分析，这些都会影响到系统的设计。后台管理者通常在经过授权之后会得到高权限，因此系统设计上需要区分角色。而数据的收集容易导致所谓的“霰弹式修改”，引起系统的快速腐烂。