大型网站系统架构实践(一)从简单到复杂
前言
写这篇文章的目的是想用来帮助自己思考和理清头绪,以及如何从一个简单的网站架构演进发展成一个大型网站架构,主要侧重在技术方面
简单的网站
由于我没有做过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不需要重新构建和部署,达到最大限度的解耦合,就是说修改系统的部分功能,其他模块可以不受影响,或者受较小影响,而且影响范围是可以控制的。