大型网站系统架构实践（一）从简单到复杂

前言

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

简单的网站

由于我没有做过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不需要重新构建和部署，达到最大限度的解耦合，就是说修改系统的部分功能，其他模块可以不受影响，或者受较小影响，而且影响范围是可以控制的。

 

下一篇  大型网站系统架构的演进（二）分布式模块之间的通信

目录 大型网站系统架构的演进目录