大型网站系统架构的演进(一)

前言

写这篇文章的目的是想用来帮助自己思考和理清头绪,以及如何从一个简单的网站架构演进发展成一个大型网站架构,主要侧重在技术方面 

简单的网站

由于我没有做过php,那么就以jsp为例,jsp做网站前端,以电子商务网站为例,描述一个简单的网站架构 

前端 jsp+css+js 

后端 java ssh 

Web容器 tomcat 

数据库 mysql 

开发人员,美工1个,前端一个,java一个 

部署方案为: 

一台服务器,部署tomcat和mysql 

架构图如下: 

技术分享

应用和数据库分布式部署

那么网站运行一段时间,开始盈利了,用户也增多了,这时候数据库的数据量还不是很大 

但是越来越多的用户访问,会占用大量的服务器内存和cpu,应该要将数据库和应用分开部署,架构图如下 

技术分享

这样网站还能运营一段时间 

解耦合开发

那么我们再来看看开发方面的问题,但是开发和运维往往是分不开的,由于网站业务发展较快,我们肯定要在上面添加新的功能,否则没法玩了,功能也越来越多,开发人员 也变多了,互相之间依赖也变多了,以前的开发模式是,java程序员从jsp一直写到dao,全部包揽,那么现在有5个java一起开发了,各负责不同的功能,如用户模块,商品模块,订单模块,交易模块等,那么问题就来了 

1 java程序员经常干些调css,和写大量javascript的活,我们用的是jquery 

2 并不是每次都要等到所有模块都完成开发了才上线,很多时候只需要一个模块完成修改,就可以上线了,然后代码都写在一个项目里面,版本控制变得相当困难,而且每次修改一个模块的功能,可能影响到另一个模块的功能,导致项目变的非常不稳定,正在运营中的项目,出现这种情况将是致命的,无限的加班加点也于事无补,痛苦啊。 

解决方案1(模块化)

这是多年前我想到的一个方案,这么多功能不能混乱的放在一个project里面,这里我指的是java web项目,至少要在开发的时候模块化,将不同的功能独立出去,模块之间通过接口调用,比如分为用户模块,应用模块,商品模块,订单模块,交易模块等,不同的人负责开发,那么模块之间怎么进行通信呢,我当时的方案是,每个后端模块都是一个jar包项目,发布的时候打成jar包给其他模块调用,项目通过maven进行构建,这样开发到部署就比较自动化,基本实现模块化开发了,项目发布也变得稳定多了。 

 

用maven做模块化的缺点

这个思想是从spring那里得来的,他们也是将不同功能进行模块化,然后这种形式却有很多的缺点: 

1 随着时间的推移,各个模块都在不停的更新,版本一直在升级,假如模块A依赖模块B,C 

可以理解为A是web前置模块,B是用户模块,C是订单模块 

如下图: 

技术分享

如果B或者C变更了,那么A有2种选择: 

1 不更新B和C,仍然可以用,带来的后果将是得不到最新的b和c的功能支持 

2 如果选择更新,A需要重新加入新的B或者C的jar包并进行调试和测试工作, 

从接口依赖来看 

由于B和C需要查数据库,因此B和C的jar包暴露了过多的api给A,且没办法很好的控制,对于项目A的开发者来说,接口不明确,几乎所有public的方法都可以调用,这样B和C的变更对上层的A来说,造成的影响是不可控的。 

从系统性能来看 

由于B和C都是要查数据库的,那么以jar的形式在A中,占用A项目所有服务器的内存和cpu等资源,无法分布式部署。 

解决方案2:模块化并分布式部署

那么应该用什么方案呢,最好是分布式部署,A与B,C通过网络通信进行调用 

这样带来的好处 

1 A,B,C实现分布式部署 

2 B,C提供明确的接口给A调用,只要接口不变,B和C修改内部业务逻辑,A不需要重新构建和部署,达到最大限度的解耦合,就是说修改系统的部分功能,其他模块可以不受影响,或者受较小影响,而且影响范围是可以控制的。

http://www.cnblogs.com/tangyanbo/p/4387167.html

 

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。