网站分布式架构

互联网的网站和大部分企业管理软件一样都是使用B/S架构模型，但是大型的公共网站B/S架构会更加复杂，对架构人员的要求更高，今天我想在自己博客里聊聊我设计的网站的B/S技术架构。

不管是B/S架构的企业管理系统还是网站技术架构可以抽象为如下简图：

在传统B/S架构的企业管理系统里，技术架构往往就是一个工程项目，各个逻辑分层都是该工程的业务逻辑模块。但是作为提供公共服务的网站，由于用户群比较庞大，网站并发量高，需求变化大，变更频繁以及网站出于对安全的考虑，以上的逻辑分层在技术架构上的实现也就会复杂的多。本人前不久做一个网站，我设计的技术架构简图如下：

我把网站项目拆分为三个子项目：前端项目、服务端项目和memcache项目，前端项目包含页面、静态资源和控制层；服务端项目包含业务层和数据库操作层；memcache项目缓存前端项目和服务端项目公用的数据。

在系统部署上，前端项目和服务端项目都采用分布式方式（我们的网站前端是4台服务器，服务端是4台服务器），用户请求进入前先通过负载均衡设备进行请求分发，前端和服务端之间以及服务端和数据库之间有防火墙保证系统的安全性，前端的集群和服务端集群分属到不同网络环境里，前端集群可以访问外网，服务端集群和数据库所在网络不能直接访问外网，但是前端网络环境和服务端网络环境之间可以进行通信。

服务端和客户端用我们自定义的报文进行通讯，传输协议时http，由于本人所在的网站安全性要求比较高，用户传输的请求协议使用https。

为了保证服务端和客户端通讯的效率，客户端和服务端通讯我们使用长连接（我们网站服务端语言选择的是java，通讯层使用netty框架开发的），为了保证长连接，我们写了一个心跳检测服务，该服务在后台线程里运行，每个5分钟检测一次心跳，当然检测的间隔时间是可以配置的。此外，我们事先估计过网站的最大并发量，在网站启动时候，我们构建了一个线程池（我们使用的服务器是8核处理器，每核最大线程数256，所以我们线程池里总共的最大线程总数数是8*256*4=8196），每个线程处理一个用户的请求。

由于客户端项目采取分布式部署，因此存在session共享的问题，我们网站的session共享没有使用web容器自带的session共享机制，而是我们自己研发了一套session机制，原理很简单，具体是我们会对每个用户会话生成一个唯一标示，我们的唯一标示是这么设计：当前用户的session的id值+随机16位数字和字母组合+当前的纳秒值，然后将该值哈希算出一个key，原有保存在session里的值保存在memcache集群里，这些数据的key就是我们算出的用户唯一标示。最终我们网站前端不在使用session对象，而是我们自己设计的session机制，对此我们还封装了一套自定义标签，在页面上操作我们自定义的session。

服务端也有类似的共享机制，但是有所不同，当客户端请求服务端时候，请求会具体落到服务端的某一台服务器，因为本网站有些请求处理时异步的，也就是说客户某些请求不是立即返回给用户，而是现将请求分发给服务端，此时客户端会返回用户一个相应标示，说明该请求已经被受理，正在处理中，而服务端的某个线程此时已经开始处理了该请求，客户端按一定时间间隔发送请求给服务端，问询请求是否处理完成，但是服务端也是分布式，请求时随机发送，客户端的问询可能会分发到别的服务器，因此这样的请求，我会在客户端记录下处理的服务端ip地址和线程id，在问询的时候就会访问指定好的服务器和线程，直到请求处理完毕，最后关闭询问，将结果返回给用户。

由于我们把一个网站项目拆分成了三个独立项目，因此在项目管理和协调上增加了难度，所以我们引入maven框架对工程进行了管理和构建，同时构建一个common工程，专门负责服务端和前端公共程序的开发。

本框架将展示层和业务处理层彻底分开，因此客户端工程师可以专心做客户端，服务端工程师专心做服务端，大家只要学习如何封装通讯协议就行，因此很利于项目组人员的横向扩展。