北京网页设计欢迎光临易企北京网络公司
您当前位置:易企北京网络公司 >> 网页设计 >> 浏览文章

网站的分布式架构

文章标签:网站,分布,分布式,架构 发布时间:2024年03月29日 浏览130

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

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

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

 


上一篇:沃尔玛大数据帮你选好购物单
下一篇:像素级差别iOS 7 App圆角图标细节发现
点击数:  相关搜索:网站 分布 分布式 架构