设计的网站的分布式架构

设计的网站的分布式架构

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

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

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

 

 

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

摘要: 互联网的网站和大部分企业管理软件一样都是使用B/S架构模型，但是大型的公共网站B/S架构会更加复杂，对架构人员的要求更高，今天我想在自己博客里聊聊我设计的网站的B/S技术架构。 不管是B/S架构的企业管理系统还是网站技术架构可以抽象为如下简图： 在传统B/S架构的企业管理系统里，技术架构往往就是一个工程项目，各个逻辑分层都是该工程的业务逻辑模块。但是作为提供公共服务的网站，由于用户群比较庞大，网站并发量高，需求变化大，变更频繁以及网站出于对安全的考虑，以上的逻辑分层在技术架构上的实现也就会复杂的多。本人前不久做一个网站，我设计的技术架构简图如下： 我把网站项目拆分为三个子项目：前端项... 阅读全文

posted @  2013-05-11 15:09 夏天的森林 阅读(993) |  评论 (12)  编辑

 

系统设计以及javascript笔记：用户行为分析研究之数据采集

摘要: 1.1用户行为分析的重要性 用户行为分析的重要性，我想做个网站的人都会用很清晰的认识，本来我想谈谈自己想法，但感觉自己毕竟还是做技术的，很难清晰的从商业价值的角度来分析它的重要性，因此放弃了想阐述自己意见的想法。当我第一次见到百度统计，和谷歌分析网站，就有那种惊鸿一瞥的激动，很想自己也能写出一套这样的网站，这也是我持续研究用户行为分析的初衷。 我估计还是有很多童鞋对“用户行为分析”的概念比较陌生，这里将百度百科里的解释在这里贴出来，抛砖引玉，希望能有更多的志同道合者跟我一起研究这个主题，百度百科的地址如下： http://baike.baidu.com/view/2330219.htm　... 阅读全文

posted @  2012-06-26 12:56 夏天的森林 阅读(1499) |  评论 (2)  编辑

 

系统设计与架构笔记:ETL工具开发和设计的建议

摘要: 好久没写博客了，不是自己偷懒，的确是没有时间哦。 最近项目组里想做一个ETL数据抽取工具，这是一个研发项目，但是感觉公司并不是特别重视,不重视不是代表它不重要，而是可能不会对这个项目要求太高，能满足我们公司的小需求就行，想从这个项目里衍生出更多的东西估计难。昨天领导让我写写自己的见解，今天写了点，不过说见解还真不敢，所以取了个名字叫建议了，今天把这个文档贴到自己博客里和大伙分享分享。 贴文档之前，我想很多朋友估计并不熟悉ETL，如果接粗过数据挖掘一定对ETL很熟悉了，ETL是数据挖掘里非常重要的一环，具体什么是ETL，大家看下面这段文字： ETL(Extract-Transfo... 阅读全文

posted @  2012-03-20 21:09 夏天的森林 阅读(1996) |  评论 (3)  编辑

 

系统设计与架构笔记:审计日志系统的设计

摘要: 公司要为一些系统做一个记录审计日志的功能。这些日志不是我们开发人员常用的系统日志功能（用来记录我们程序运行情况的，比如用log4j记录下来的日志），而是为了今后对审计部门所使用，具有很强的业务要求的日志功能。架构已经被公司里的其他同事设计好了，虽然我现在只是做些边角料的辅助工作，不过这个命题我很感兴趣，我今天仔细琢磨了一下这样的一个业务需求，觉得还是很有意思，真正把这个做起来是会有一定技术含量。下面就是我的思考，这些思考不全是我自己独立想出来的，也借鉴了些同事的设计。 首先我要设定一个业务场景：我们是为一个重要的商业支付网站做一套审计系统。最重要的技术要求是审计系统不能影响到业务系统... 阅读全文

posted @  2012-01-19 15:01 夏天的森林 阅读(2496) |  评论 (1)  编辑

 

系统设计与架构笔记:对我新公司网站的技术架构初解

摘要: 刚刚进入了一家新公司，哎在上海混了这么多年，终于到了一家像样的公司，想想这个过程还真不容易啊，一定得要好好珍惜了，不废话了，开始我的内容了。 我现在的项目组的确是做纯正大网站的项目组，虽然现在还没做开发，对公司框架还没完全熟悉，但是对公司的架构的初步了解（初解）觉得还真有价值，都说大型网站应用的开发和普通的web项目不一样，但是你没有做过大型网站终究还是不能理解它的技术结构和我们常用的技术框架结构有何不同。在讲之前我要申明：我是一名java工程师，所以我讲的技术都是以java技术为基础，或许其他技术实现同样的功能会有所不同，但我相信主要思想一定是相似的。 普通的javaweb项目就是按... 阅读全文

posted @  2012-01-15 00:04 夏天的森林 阅读(3116) |  评论 (5)  编辑

 

用户行为分析笔记（二）：系统的整体架构

摘要: 昨晚写的博文得到大家积极的反馈，非常喜欢这样一种交流的过程，也发现自己还有很多知识掌握的不够好，javascript是我主攻方向，对它的学习要求一定要高，其实对象创建的中篇写的不是太好，太仓促了，很多问题思考不到位，有点浅尝辄止，因此最后一篇我想要好好准备下，就算写不出什么有新意的观点，但一定要写出一篇经过自己仔细思考的文章。 最近噼里啪啦的起了三个系列，今天有人跟我说我贪多，最后啥都学不好，哎，不管了，人生就是要享受当下的快乐，只要学的开心就能坚持下去。 今天也有朋友说我的java框架那个系列其实可以不用写，因为这些只要做了一段时间java的人都会，如果我想写就应该加入算法，设计模... 阅读全文

posted @  2011-11-01 22:11 夏天的森林 阅读(2351) |  评论 (5)  编辑

 

用户行为分析笔记（一）：概述

摘要: 今天有人问我会不会推荐算法，回到家里反复思考了下（其实就是一个会与不会的回答，为啥我还要反复思量下了？），我发现自己从事软件开发工作这么多年，大小项目无数，但是如果从做应用角度换句话说我做了哪些提高人们工作效率或者改变了哪些人的生活方式的东西呢？项目做的再多，技术再精通也就是一个单兵实力很强的士兵，没有一个层次的提升最终都是一个兵，技术是手段是工具，我用对了地方才能发挥重大的价值，这个地方到底在哪里对现在我而言是一个不得不思考的问题，因为我现在太想提升自己的能力了。这个所谓的地方就是我们所说的业务，我必须要找到一个业务方向精深下去了，而今天所说的推荐算法就是一个很好的引子。 推荐对于互联... 阅读全文

posted @  2011-10-29 19:38 夏天的森林 阅读(1875) |  评论 (1)  编辑

 

系统设计与架构笔记：键值对在架构设计里的应用

摘要: 谈谈我对程序的理解 作为程序员你对程序是如何理解的？写这篇文章的时候，我认真思考了下，发现我对程序的理解不是和教科书一样的，我每次听到程序二字我想到的只有两个东西：代码和数据，而每次写程序的时候也就是写代码操作数据的过程。 做程序开发和做菜很像，数据就是食材，代码就是厨艺，做出的软件就是一道菜了，至于这个菜好不好吃，到底是看食材还是看厨艺了？呵呵，当我抛出这个问题的时候，我的第一反应是菜不好吃当然是手艺不好了，不知道其他童鞋是不是这么想的。认真想下，一道好菜一般都是二者必须兼备，当然不排除某一项突出也可以达到同样的效果，但这种情况毕竟不是大众化，而是属于少数精英的，做软件也是如此，代码与数.. 阅读全文

posted @  2011-09-28 00:01 夏天的森林 阅读(2031) |  评论 (9)  编辑

分类:  系统设计与架构,  项目经验