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

前言

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

简单的网站

由于我没有做过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

时间: 2025-01-14 16:34:57

大型网站系统架构的演进(一)(转)的相关文章

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

大型网站系统架构的演进(一) 大型网站系统架构的演进(二)分布式模块之间的通信 大型网站系统架构的演进(三)如何提高网站的高可用和高性能

大型网站系统架构的演进(四)http层负载均衡之haproxy实践篇(一)

方案 上篇文章讲到了负载均衡的相关理论知识,这篇文章我打算讲讲实践方法以及实践中遇到的问题 方案:haproxy http层负载均衡 安装一个haproxy服务,两个web服务 haproxy:192.168.1.227:80 web1 http://192.168.1.226:8081/login web2 http://192.168.1.246:8888/login web服务自行准备,文章中就不说了 负载均衡算法为轮询调度 会话保持实现方式为cookie识别,插入cookie 优点: 1

阿里P9架构师讲解从单机至亿级流量大型网站系统架构的演进过程

阶段一.单机构建网站 网站的初期,我们经常会在单机上跑我们所有的程序和软件.此时我们使用一个容器,如tomcat.jetty.jboos,然后直接使用JSP/servlet技术,或者使用一些开源的框架如maven+spring+struct+hibernate.maven+spring+springmvc+mybatis:最后再选择一个数据库管理系统来存储数据,如mysql.sqlserver.oracle,然后通过JDBC进行数据库的连接和操作. 把以上的所有软件都装载同一台机器上,应用跑起来

P9架构师讲解从单机至亿级流量大型网站系统架构的演进过程

阶段一.单机构建网站 网站的初期,我们经常会在单机上跑我们所有的程序和软件.此时我们使用一个容器,如tomcat.jetty.jboos,然后直接使用JSP/servlet技术,或者使用一些开源的框架如maven+spring+struct+hibernate.maven+spring+springmvc+mybatis:最后再选择一个数据库管理系统来存储数据,如mysql.sqlserver.oracle,然后通过JDBC进行数据库的连接和操作. 把以上的所有软件都装载同一台机器上,应用跑起来

大型网站系统架构的演进(二)分布式模块之间的通信

上一篇文章中讲到了分布式部署之后,各个模块要通过网络进行通信,那么如何通信,用什么协议呢? 可选的方案有http tcp/ip(socket)等 http短连接通信方案 基于http协议,xml报文传输 客户端具体框架为httpclient,服务端为struts2 客户端和服务端的通信在内网 该方案我们实行过一段时间,发现存在性能问题,首先是短连接,在并发量较大的时候,开启大量的tcp连接,这样连接资源容易耗尽,客户端首先成为瓶颈,tps上不去. 我总结的几点原因: 1.每次通信都重新开启新的t

大型网站系统架构的演进(三)如何提高网站的高可用和高性能

随着网站的业务越来越多,网站的服务就变的很重要,假设某天你的服务器挂了,会不会是一个天大的灾难呢?而且这种事情发生的概率还不小,断电了,服务器硬盘坏了,内存坏了等等,都会使你的系统挂掉,而且高并发的访问有时候也会使系统资源耗尽,然后导致服务器宕机,那么解决方案呢,那就是集群,将相同的系统分别放到不同的web服务器或者硬件服务器,这样其中一个挂掉了,网站还可以正常运营. Web应用集群 首先我们应该对web前置做集群,我们的方案是用Haproxy做http协议层的负载均衡,后端部署多个web前置,

大型网站系统架构实践(六)深入探讨web应用集群Session保持

原理 在第三,四篇文章中讲到了会话保持的问题,而且还遗留了一个问题,就是会话保持存在单点故障, 当时的方案是cookie插入后缀,即haproxy指负责分发请求,应用服务自行保持用户会话,如果应 用服务器宕机,则session会丢失. 现在来温习下解决方案 方案1:session复制 原理 就是将1台服务器的session复制到其它所有的服务器上,这样无论访问哪台服务器,都会得到用户 的session 优点 不存在单点故障问题 缺点 当服务器的数量比较大时,session同步将会变得相当耗时 方

大型网站系统架构

大型网站系统架构 dubbo+ssh+nginx负载均衡/动静分离+数据库主从+缓存+分布式存储+队列 1.缓存--利用缓存改善网站性能a.缓存包含本地缓存和分布式缓存:本地缓存如OSCache,分布式缓存如Memcached.Redis. b.本地缓存和分布式缓存的特点本地缓存的特点是速度快,但是本地空间有限所以缓存数据量也有限.分布式缓存的特点是,可以缓存海量的数据,并且扩展非常容易,响应速度没有本地缓存快. 2.服务器集群--使用服务器集群改善应用服务器性能应用服务器作为网站的入口,会承担

大型网站系统架构演化和关键技术普及课程

大型网站系统架构演化和关键技术普及 课程观看地址:http://www.xuetuwuyou.com/course/40 课程出自学途无忧网:http://www.xuetuwuyou.com/ 了解大型网站的架构是如何一步步进行演变和改进的,并对其中的一些关键技术知识做普及. 课时1:原始架构的诞生 课时2:缓存的介绍 课时3:集群&负载均衡 课时4:数据库分库分表演变 课时5:CDN&反向代理等技术手段 课时6:分布式服务&空节点等技术手段