架构反思案例之网站架构案例

项目的背景

公司已有一个桌面版程序,需要开发一个对应的网站程序,这样用户就不用安装桌面程序,也不用再关心升级和更新的问题,所有桌面的操作都可以在网站上完成。

项目的设计

1. Browser

这是没得选的,必须要有。

这里我们主要考虑了两点:

第一点,由于浏览器端和服务端需要频繁的交互数据,所以我们选择了WebSocket作为前后端的通信技术,但是WebSocket并不是每个浏览器都支持的。这个时候我们考虑了socket.io,它比较完好的封装了WebSocket,而且对于不支持WebSocket的浏览器也提供了轮询等替代的方式,这些是socket.io自己处理的,不需要外界强行干预,相当方便,所以我们选择了socket.io作为通信的媒介。

第二点,由于是参照桌面UI开发的程序,我们选择了单页面技术实现用户的界面。为了复用一些相同的UI,我们使用了Google Closure提供的相关的模板技术,动态的根据需求生成元素,然后使用JQuery添加到页面中。JQuery也算是前端无法忽视的一个类库了,我们照样使用。

2. WebServer

这也是没得选的,必须要有。

考虑到前后端有着频繁的交互需求,而且这些交互并非CPU密集计算型的操作,大多是与Browser进行数据交互,于是选择NodeJS创建服务器,对我个人来说,我始终认为NodeJS将异步回调机制演绎到了无人可敌的地步。

WebServer从角色上来说,主要实现了下列功能:

一是,作为连接Browser和BackendServer的媒介,所有程序交互的数据都是通过WebServer转发的。WebServer与Browser的通信采用WebSocket (socket.io)实现,而WebServer与BackendServer通信采用通常的TCP Socket来实现。

二是,WebServer通过BackendServerInspector组件管理BackendServer,这个在下面会提到。

三是,WebServer直接管理用户的Session信息,在这里,所有的用户数据都存储在MongoDB中。

3. BackendServer

因为桌面程序已经存在,所以可以重用程序所有的业务逻辑,于是网站的架构在传统的Browser/Server的基础上,再加上了BackendServer组件。

BackendServer组件是一个命令行执行的exe程序,它包含所有桌面程序的逻辑和数据,只是把UI部分剥离出去了。BackendServer与WebServer的通信采用通常的TCP Socket通信机制。

4. BackendServerInspector

除了这些主要的组件外,由于BackendServer只是把UI剥离的桌面程序,所以每个功能并不是松散的,一个BackendServer一次只能处理一个用户的数据,所以我们需要一个BackendServerInspector这样的管理组件,这个组件负责启动,关闭和检测BackendServer。

当WebServer需要处理一个新用户的时候,BackendServerInspector会检查是否有可用的BackendServer,如果没有可用的BackendServer则启动一个新的BackendServer程序。如果一个BackendServer程序没有响应的话,则会去关闭这个BackendServer程序。

5. MongoDB

为了存储用户的信息,我们使用MongoDB作为数据库。NoSql这年发展的是如火如荼,我们也决定在项目中采用,这里考虑的不仅是MongoDB高效的性能,还有RESTFull API,天生的分布式特性也是我们考虑的因素,虽然大多数有点实际中并没有用到,但是相对于关系数据库来说,免去对数据库抽象的过程(ORM,或者说是Hibernate)还是挺舒服的。

项目的实现

1. 重用桌面程序

这是项目的发起背景,为了在有限的时间内重用桌面程序的功能,使得我们并没有足够的事件将这个桌面程序的功能与界面剥离感觉,打造一个纯粹的SOA服务也只不过是一个响亮的口号而已,甚至很多的人根本就没这个意思。

这个部分最终的结果只是将原来的程序添加上了收发消息的TCP Socket模块,完成与WebServer通信的功能,UI系统几乎是完整的保留了。

2. NodeJS特性

这个部分不用多讲了,NodeJS的也是近来炙手可热的的技术了,采用这个实现WebServer也并无什么大的不同,只是特别要注意不要阻塞主线程。

3. HTML5图形处理

我个人觉得,HTML5中的Canvas是Web上图形处理的首选,普通的2D操作使用Canvas的API就可以搞定,复杂的3D世界则要使用WebGL开发,这也是一个在浏览器中并不通用的技术,所以我们一直推荐客户使用Chrome和Firefox浏览器。

4. NoSQL趋势

MongoDB也是一个新新技术,采用这个实现用户信息的持久化是足够的,实现上并没什么大的难点。

5. AWS - 亚马逊云服务

我们尝试了亚马逊的云服务,这种云服务对传统的服务器绝对是一种巨大的冲击,扩展性能和易用性绝对是传统技术无法比拟的。难怪这个云服务是很多创业公司的首选。

项目的反思

这个项目的开始有点探索性的意味,最终由于服务器成本太高被叫停。

这个项目的优点是使用了很多新型的技术保证高效的交互性能和可扩展性。不足是频繁的交互导致网络流量太大,网络费用太高。

我个人觉得这个设计值得提高的地方就是,应该把桌面程序的UI相关逻辑包括一些概念彻底与底层命令和操作分离,把它们放到页面上去实现,这样可以节省一部分流量。但是剥离这些逻辑,开发一个比较纯净的面向服务的程序,成本无疑也是很高的。

时间: 2024-10-20 22:04:42

架构反思案例之网站架构案例的相关文章

分享JAVA从初级程序员到架构师视频,文档,架构设计,大型网站架构分析,大数据分析资料

JAVA从初级程序员到架构师视频,文档,架构设计,大型网站架构分析,大数据分析资料, 搭建高并发.高可用电商架构设计资料需要的联系我.很多目录都没列出来(QQ空间相册里有很多目录的截图)加QQ:1927360914

大型网站架构之百万PV网站架构案例

一.案例概述 本案例采用四层模式实现,主要分为前端反向代理.web层.数据库缓存层和数据库层. 前端反向代理采用主备模式 web层采用群集模式 数据库缓存层采用主备模式 数据库层采用主从模式 由于实验条件限制,本次实验共打开四台虚拟机,此处实验将前端代理层.数据库缓存层.数据库层服务搭建在前两台虚拟服务器上,web层采用群集模式,用于单独放置两台虚拟机.故本次实验实际模型为了模拟实际环境,服务搭建按照如下拓扑搭建. 二.实验环境 主机名 操作系统 IP地址 用途 server1 centosx8

(转)大型网站架构系列:电商网站架构案例(1)

大型网站架构是一个系列文档,欢迎大家关注.本次分享主题:电商网站架构案例.从电商网站的需求,到单机架构,逐步演变为常用的,可供参考的分布式架构的原型.除具备功能需求外,还具备一定的高性能,高可用,可伸缩,可扩展等非功能质量需求(架构目标). 根据实际需要,进行改造,扩展,支持千万PV,是没问题的. 本次分享大纲 电商案例的原因 电商网站需求 网站初级架构 系统容量估算 网站架构分析 网站架构优化 架构总结 电商网站案例,一共有三篇本篇主要说明网站的需求,网站初始架构,系统容量估算方法. 一.电商

大型网站架构系列:电商网站架构案例(1)

大型网站架构是一个系列文档,欢迎大家关注.本次分享主题:电商网站架构案例.从电商网站的需求,到单机架构,逐步演变为常用的,可供参考的分布式架构的原型.除具备功能需求外,还具备一定的高性能,高可用,可伸缩,可扩展等非功能质量需求(架构目标). 根据实际需要,进行改造,扩展,支持千万PV,是没问题的. 本次分享大纲 电商案例的原因 电商网站需求 网站初级架构 系统容量估算 网站架构分析 网站架构优化 架构总结 电商网站案例,一共有三篇本篇主要说明网站的需求,网站初始架构,系统容量估算方法. 一.电商

大型网站架构系列:电商网站架构案例

大型网站架构是一个系列文档,欢迎大家关注.本次分享主题:电商网站架构案例.从电商网站的需求,到单机架构,逐步演变为常用的,可供参考的分布式架构的原型.除具备功能需求外,还具备一定的高性能,高可用,可伸缩,可扩展等非功能质量需求(架构目标). 根据实际需要,进行改造,扩展,支持千万PV,是没问题的. 本次分享大纲 电商案例的原因 电商网站需求 网站初级架构 系统容量估算 网站架构分析 网站架构优化 架构总结 电商网站案例,一共有三篇本篇主要说明网站的需求,网站初始架构,系统容量估算方法. 一.电商

电商网站架构案例(1)

大型网站架构是一个系列文档,欢迎大家关注.本次分享主题:电商网站架构案例.从电商网站的需求,到单机架构,逐步演变为常用的,可供参考的分布式架构的原型.除具备功能需求外,还具备一定的高性能,高可用,可伸缩,可扩展等非功能质量需求(架构目标). 根据实际需要,进行改造,扩展,支持千万PV,是没问题的. 本次分享大纲 电商案例的原因 电商网站需求 网站初级架构 系统容量估算 网站架构分析 网站架构优化 架构总结 电商网站案例,一共有三篇本篇主要说明网站的需求,网站初始架构,系统容量估算方法. 一.电商

网站架构资料集(转)

add by zhj:很多文章是转自www.itivy.com,很可惜,这个网站已经无法访问,不过,你可以用Google搜索一下这些文章,另外 各大网站架构总结笔记 也能看到部分转载的原文. 原文:http://www.diguage.com/archives/41.html 扯扯蛋 以前见过零零散散地介绍一些知名网站架构的分析文章.最近D瓜哥也想研究一下各大知名网站的架构.所以,就搜集了一下这方面资料.限于时间问题,这篇文章分享的文章并没有都看完,所以不保证所有文章的质量.另外,如果有朋友发现

大型网站架构演化过程

一:大型网站架构演化 1.初级阶段网站架构 应用服务器,数据库,文件等所有的资源都在一台服务器上,采用LAMP架构,一般我们学生开发就是采用这种架构 2.应用服务与数据服务分离(应用与数据分离) 随着网站业务的发展,一台服务器已经不能满足性能的需求,这时我们把业务服务和数据服务分开,此时网站就变成了三个服务器:应用服务器,数据库服务器,文件服务器,一般小型项目就是这种开发模式,比如我    在360我们组的项目初期没有用缓存,就是这种架构,数据库有专门的服务器 应用服务器    -> 需要处理业

高并发大型网站架构设计

一个大型的网站网站应该由如下6个子系统组成 负载均衡系统 反向代理系统 Web服务器系统 分布式存储系统 底层服务系统 数据库集群系统 为什么要做高并发系统设计? 事实上,针对于任何单一的网络服务器程序,其可承受的同时连接数目是有理论峰值的,通过C++中对TSocket的定义类型:word,我们可以判 定这个连接理论峰值是65535,也就是说,你的单个服务器程序,最多可以承受6万多的用户同时连接.但是,在实际应用中,能达到一万人的同时连接并能保 证正常的数据交换已经是很不容易了,通常这个值都在2