我设计的网站的分布式架构

互联网的网站和大部分企业管理软件同样都是使用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工程，专门负责服务端和前端公共程序的开发。

　　本框架将展现层和业务处理层完全分开，所以客户端工程师能够专心作客户端，服务端工程师专心作服务端，你们只要学习如何封装通信协议就行，所以很利于项目组人员的横向扩展。

　　以上就是本人为公司网站设计的技术架构，这里和大伙分享下，不知道好很差，但愿各位大牛能给点建设性的意见。