（一）网站的可用性
当网站的页面放在用户面前，就将要考虑到，如果用户和网站断开了联系，会造成一些难以挽回的损失。那么，系统的可用性，就是重中之重了。先求生存，然后求发展。
举例：《XX调研系统》，是一个在B/S结构的系统，用户直接在网站上完成系统的采集功能，系统运行持续长达几个月的时间，且可能会有用户集中登录网站的情况，造成服务器运行缓慢或者宕机。考虑现实的情况，也有各种可能致使服务器宕机，尽而使系统停止运行。
在应对硬件故障的问题上，可采用高可用的架构设计，一个典型的网站设计通常遵循一个基本分层架构模型。典型的分层模型是三层：应用层、服务层、数据层。
在《XX调研系统》中，我们将用户填写信息、查询信息等部署在独立的服务器集群中（应用层），用户的登录、权限、个人资料管理等部署在独立的服务器集群中（服务层），而有关用户的资料信息数据、填写资料信息数据等同样如此（数据层）。在应用层和服务层中，采用负载均衡的技术来实现系统功能方面的高可用，当某个服务器失效时，有别的服务器来承担其工作；在数据层中，采用数据备份的方式，网站日常的维护中使用数据冷备，而在网站实时在线业务（多人对内容的审批）中，可采用数据热备。
为了保证数据的高可用，网站通常会牺牲另一个很重要的指标：数据的一致性。
数据一致性：在数据有多份副本的情况下，如果网络、服务器或者软件出现故障，会导致部分副本写入成功，部分副本写入失败。这就会造成各个副本之间的数据不一致，数据内容冲突。
因为另外两个：数据持久性（备份）和数据可访问性（访问服务），更加重要。数据的存活相比于反应更加重要。
数据持久性：保证数据可持久存储，在各种情况下都不会出现数据丢失的问题。问了实现数据的持久性，不但在写入数据时需要写入持久性存储，还需要将数据备份一个或多个副本，存放在不同的物理存储设备上，在某个存储故障或灾害发生时，数据不会丢失。
数据可访问性：在多份数据副本分别存放在不同存储设备的情况下，如果一个数据存储设备损坏，就需要将数据访问切换到另一个数据存储设备上，如果这个过程不能很快完成（终端用户几乎没有感知），或者在完成过程中需要停止终端用户访问数据，那么这段时间数据是不可访问的。
对网站进行更新的过程，也相当于网站的失效过程。所以可以人为对其影响，关闭服务器集群的一小部分，进行更新发布，观察运行稳定没有故障，然后一步一步重复过程来达到所有服务器完成更新发布。
（二）网站的伸缩型架构
所谓网站的伸缩性是指不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力。
将不同功能进行分离部署可以实现一定程度的伸缩性，然后再部署服务器集群，即相同服务部署在多台服务器上构成一个集群整体对外提供服务。当一头牛拉不动车时不要再找一头更强壮的牛，而是用两头牛来拉车。
（三）网站的可扩展架构
一个系统拥有良好的扩展性，可以为系统提高发展的空间。系统应用之间存在着较少的依赖和耦合，对需求变更可以有敏捷的响应。
之前自己做的《XX调研系统》中，我犯的错误就在这上面。在一个网页中，除了有直接面向用户的界面部分，其中运算的逻辑部分也弄在一个页面上了，传送数据直接传送，非常直接。那么问题就来了，要做修改的时候，就是牵一发动全身，往往修改很小的数据，都要牵扯到几个网页的修改，或者跑出一些未知的BUG。当自己打开网页的时候，网页反应偏慢卡顿的感觉也是明显的。
关于解决方法，简单说，就是将系统切分成N个低耦合的子模块，包括横向的业务模块（功能），也包含纵向的基础技术模块（具体实现）。《XX调研系统》，我可以采用Struts2架构的方法，比如登录，对登录正确与否的判断，就可以将面向用户的界面部分和逻辑判断分开。一旦出现问题，也方便设计者找对地方下手。
如果遇到网站访问的高峰，用户提交信息时，可能会等待很久才能收到反馈，这个时候服务器处理量肯定是很大的。可以通过分布式消息队列方式来解决：将提交消息发送至分布式消息队列，而服务器只需要从分布式消息队列获取消息来进行处理，不需要知道消息从何而来。这样在设计方面，减少了两个模块的联系（减少复杂度），也让用户提交信息后，能更快开始进行下一步的工作，提高了系统的易用性。