前言
在当今这样高速和大数据的互联网时代，每个企业都希望以最节约成本、最简单的方式来建设企业网站，而合理的规划网站架构是保证网站正常运营的基础，因此我们需要一个高性能、高可用以及高稳定性的网站架构。
通常情况下，公司网站需要提供如下服务，包括：图片上传下载、文件上传下载、Web 页面访问、数据库访问、应用服务和日志等，这些服务往往由一台或者多台服务器提供，另外为了保证服务器的稳定运行，还要考虑加入必要的容错机制，如数据库的备份、等，服务器越少，硬件成本越低，但服务器压力增大，性能降低，维护成本会升高。服务器划分的过细，虽能提升网站性能，但服务器间协同工作开发成本提高，硬件成本也会增加。因此，各公司都试图从软架构和硬架构上进行了最大限度的改造，设计能够很好的与自身的业务吻合，最大限度的提供高性能的服务架构。
综合考虑以上问题，本文结合中小型企业网站自身特点，提出一套能满足中小型企业网站业务需求、并且能最大限度的提供高性能、低成本的服务器架构。
1 构建高性能的服务器
中小型企业网站具有以下特点：
(1)应用简单，中小型企业网站通常以Web 应用为主，配合独立的数据存储。
(2)访问内容重复性高，每个用户访问的几乎都是一样的数据，而且短时间内变化不大。
(3)访问时间集中，用户访问都集中在某一个时间段，所以需要一定的容错机制和高负载性。
(4)日均访问量都在百万PV 以下。针对中小企业网站所具有的特点，提出以下几点解决方案：
(1)Web 服务器与数据库服务器分离， 这样做一方面降低磁盘IO，可以减缓Web 服务器也可以提高数据库服务器性能，另外，数据库服务器对内网使用，提高安全性能。
(2)提供缓存机制，对网站中包含的静态的公共数据进行缓存，而对需要实时更新的网站内容不进行缓存，减少磁盘IO 的次数，同时提高网站性能。
(3)对于一个网站来说，查询静态资源的量显然多与动态页面的量，网站最影响性能的地方就在于静态文件的处理，从提升网站性能的角度考虑，静态资源不应和应用服务器放在一起，可以使用反向代理分离静态资源与动态页面。
(4)为保证Web 服务稳定性，采用双应用服务器，并且把session管理放到内存数据库进行管理，分担一部分应用服务器压力，从而提升服务器的处理性能。
(5)后端数据库采用主从双机热备数据库配置，保障两台数据库的数据一致，以保护企业数据结构不受故障、灾难、错误和崩溃的影响，当出现主库数据异常情况时，备库随时可用.服务器框架设计。
该框架分为三层：负载均衡层、应用服务层、数据存储层。
(1) 负载均衡层由两部分组成，Squid 作为负载均衡的第一层，Web 程序本身访问量最大的是一些静态文件(JS、CSS、图片文件等)，几乎占了半数以上的访问请求，因此最前端使用Squid 完成静态资源缓存，Squid 自身支持多重缓存策略：最少近来使用(LRU)，贪婪对偶大小次数(GDSF)和动态衰老最少经常使用(LFUDA)，使用Squid 可以有效降低磁盘I/O 次数，缩短响应时间，提升Web 服务性能。Nginx 作为负载均衡的第二层，用来处理一些静态文件，能够大量减少应用服务器的压力，让应用服务器仅仅只作为一个处理业务的容器，职责单一化。通过负载均衡这两层的过滤，大量请求都被Squid 和Nginx 拦截下，使得后面的业务层可以专注完成实际业务处理，从而有效提高服务器性能。另外，Squid 和Nginx 谁作为负载均衡第一层都可以，用户可根据实际情况作为调整。
(2)应用服务层，用来处理一些动态的业务逻辑，这里以Tomcat服务器为例，一个Tomcat 已经足够应对中小型企业的用户访问量，经过一些尝试，在每分钟访问量在4000 左右PV 的情况下，到达Tomcat的请求量最多也就上百左右。
从实践经验来说， 应用服务器常常因为一些升级和不稳定功能，导致Tomcat 在运行一段时间后服务挂掉的情况， 应用服务器在进行大量计算的时候需要占有更多的CPU， 导致响应慢和内存不足的多种情况，同时多个用户的登录也会给应用服务器内存产生一部分的内存压力。针对这一情况，可以采用多个应用服务器去处理业务，并且把Session 的管理从应用服务器中分离出来，让多个应用服务器去处理业务，并且采用单独的Redis 内存数据库去进行管理和连接多个应用服务器。
(3)数据存储层，为保证数据的完整性、防止数据丢失，采用主、从数据库服务器的设计方式， 双机热备的这种方式主要是通过主机，把数据复制到相应的其他从服务器上去(Slaves)。主服务器将更新写进二进制日志文件中， 并且维护文件的一个索引，Slaves 连接上主服务器(Master)从服务器在日志中读取最后一次更新的位置，当主服务器挂掉的时候能够进行切换。
MySQL 是通过对数据的复制来保证数据的统一性。整体来说，MySQL 的复制分为三个步骤：
(1)Master 将改变记录到二进制日志(binary log)中。
(2)Slave 将master 的binary log events 拷贝到它的中继日志(relaylog)。
(3)Slave 重做中继日志中的事件，将改变反映它自己的数据。
2 总结
针对与中小型企业来说， 该套系统能够轻松的应对日均百万的PV 访问量，但是也存在着不足的地方，前端过于单薄，需要把静态文件放到单独的文件服务器上去，同时一旦最前端挂掉，会导致整个系统的奔溃。但是基于中小型企业的用户量来说却是足够的，不用担心该问题。
