建设中小型企业的高性能linux架构
0 前言
在当今这样高速和大数据的互联网时代，每个企业都希望以最节约成本、最简单的方式来建设企业网站，而合理的规划网站架构是保证网站正常运营的基础，因此我们需要一个高性能、高可用以及高稳定性的网站架构。
通常情况下，公司网站需要提供如下服务，包括：图片上传下载、文件上传下载、Web页面访问、数据库访问、应用服务和日志等，这些服务往往由一台或者多台服务器提供，另外为了保证服务器的稳定运行，还要考虑加入必要的容错机制，如数据库的备份、等，服务器越少，硬件成本越低，但服务器压力增大，性能降低，维护成本会升高。服务器划分的过细，虽能提升网站性能，但服务器间协同工作开发成本提高，硬件成本也会增加。因此，各公司都试图从软架构和硬架构上进行了最大限度的改造，设计能够很好的与自身的业务吻合，最大限度的提供高性能的服务架构。
综合考虑以上问题，本文结合中小型企业网站自身特点，提出一套能满足中小型企业网站业务需求、并且能最大限度的提供高性能、低成本的服务器架构。
1 构建高性能的服务器
中小型企业网站具有以下特点：
（1）应用简单，中小型企业网站通常以Web应用为主，配合独立的数据存储。
（2）访问内容重复性高，每个用户访问的几乎都是一样的数据，而且短时间内变化不大。
（3）访问时间集中，用户访问都集中在某一个时间段，所以需要一定的容错机制和高负载性。
（4）日均访问量都在百万PV以下。
针对中小企业网站所具有的特点，提出以下几点解决方案：
（1）Web服务器与数据库服务器分离，这样做一方面降低磁盘IO，可以减缓Web服务器也可以提高数据库服务器性能，另外，数据库服务器对内网使用，提高安全性能。
（2）提供缓存机制，对网站中包含的静态的公共数据进行缓存，而对需要实时更新的网站内容不进行缓存，减少磁盘IO的次数，同时提高网站性能。
（3）对于一个网站来说，查询静态资源的量显然多与动态页面的量，网站最影响性能的地方就在于静态文件的处理，从提升网站性能的角度考虑，静态资源不应和应用服务器放在一起，可以使用反向代理分离静态资源与动态页面。
（4）为保证Web服务稳定性，采用双应用服务器，并且把session管理放到内存数据库进行管理，分担一部分应用服务器压力，从而提升服务器的处理性能。
（5）后端数据库采用主从双机热备数据库配置，保障两台数据库的数据一致，以保护企业数据结构不受故障、灾难、错误和崩溃的影响，当出现主库数据异常情况时，备库随时可用.
服务器框架设计如图1。
该框架分为三层：负载均衡层、应用服务层、数据存储层。
（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是通过对数据的复制来保证数据的统一性，如图2所示。
整体来说，MySQL的复制分为三个步骤：
（1）Master将改变记录到二进制日志（binary log）中。
（2）Slave将master的binary log events拷贝到它的中继日志（relay log）。
（3）Slave重做中继日志中的事件，将改变反映它自己的数据。
2 总结
针对与中小型企业来说，该套系统能够轻松的应对日均百万的PV访问量，但是也存在着不足的地方，前端过于单薄，需要把静态文件放到单独的文件服务器上去，同时一旦最前端挂掉，会导致整个系统的奔溃。但是基于中小型企业的用户量来说却是足够的，不用担心该问题。
