服务器系统架构的演变

忘是亡心i 2022-05-17 00:17 212阅读 0赞

## 以对并发量要求比较高的电商项目为例。 ##

![70][]

### 1. 单服务架构——最多能应付400-500的并发量，打成一个war包，运行在一台服务器下。 ###

![70 1][]

存在的问题：

1、功能耦合度高。

比如说：搜索模块其中某个小功能出现了BUG,这时候修复了该BUG，重新打成WAR需要重新部署到服务器，重新部署期间，就会影响其他正常运行的其他功能模块。

2、系统维护成本高

3、如果并发量大，无法解决高并发的问题

### 2. 集群架构——引入负载均衡，同一个工程代码拷贝多份部署到多台服务器，每台服务器单独独立部署运行。引入负载均衡（Nginx），以2台Tomcat为例，能应付800-1000的并发量，打成多个相同的war包，运行在多台服务器下。 ###

![70 2][]

存在的问题：

1、系统无法有效进行水平扩展（集群不能针对功能模块）

2、用户存在重复登录的问题

针对第二点：需要session共享，是以session广播的形式，比较消耗资源，宽带。

如果要达到10000并发，需要20台服务器做tomcat集群。当tomcat集群中节点数量增加，服务能力先增加后下降。所以集群中节点数量不能太多，一般也就5个左右。

### 3.分布式架构，10000的并发量为例 ###

**需要按照功能点把系统拆分，拆分成独立的功能工程，可以单独为某一个节点添加服务器，需要系统之间配合才能完成整个业务逻辑这就叫做分布式。**

![70 3][]

**分布式架构：把系统按照模块拆分成多个子系统；多个子系统相互协作才能完成业务流程系统之间需要进行通信。**

优点：

1.  把模块拆分，使用接口通信，降低模块之间的耦合度。
2.  把项目拆分成若干个子项目，不同的团队负责不同的子项目。
3.  增加功能时只需要再增加一个子项目，调用其他系统的接口就可以。
4.  可以灵活的进行分布式部署。

缺点：

1、系统之间交互需要使用远程通信，需要开发接口，增加工作量。

2、各个模块有一些通用的业务逻辑无法公用。

### 4.基于SOA面向服务的架构 ###

**SOA：Service Oriented Architecture面向服务的架构。也就是把工程都拆分成服务层工程、表现层工程。服务层中包含业务逻辑，只需要对外提供服务即可。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。工程都可以独立部署。**

![70 4][]

### 以一般的电商系统的技术选型为例： ###

技术选型：分布式架构

*  Spring、SpringMVC、Mybatis（SSM）
 *  JSP、JSTL、jQuery、EasyUI、KindEditor（富文本编辑器）
 *  Redis（缓存服务器，单点登录，购物车）
 *  Solr（搜索），Elassticsearch
 *  dubbo（分布式服务框架）
 *  HttpClient（HTTP 协议访问客户端）
 *  ActiveMQ（消息队列）
 *  Quartz（定时任务）
 *  FastDFS（图片服务器）
 *  FreeMarker（网页静态化）
 *  Nginx（反向代理服务器）
 *  MyCat（数据库中间件），读写分离，分表分库

[70]: /images/20220517/a38730672d7343daaaf4da866cefa017.png
[70 1]: /images/20220517/4a55db1e213a4d4cb9ff71002ce82dad.png
[70 2]: /images/20220517/45109bf0f3ac4b528a6717208064c885.png
[70 3]: /images/20220517/923bd5e17b4043ddbccc8432e8d19236.png
[70 4]: /images/20220517/2c319582307e4941a5ccdac119c347cc.png