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

前言

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

简单的网站

因为我没有作过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不须要从新构建和部署，达到最大限度的解耦合，就是说修改系统的部分功能，其余模块能够不受影响，或者受较小影响，并且影响范围是能够控制的。

 

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

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