架构演变

一、传统架构方式：

最初做项目时，架构一般都会分为3层，即表现层展示系统界面，业务层处理各种业务逻辑，持久层操作来源于数据库中的数据，数据库中则存储我们需要存储的数据。

这种三层架构的方式适用于大多数项目，但这种方法还不能称之为架构，我们做的时候，顶多使用各种框架，如Spring，SpringMvc，Mybatis等等将这三层整合到一块。

这种架构会存在的问题：

当我们的项目并发量比较高时，就会存在问题。

使用这种架构方式，我们一般就只有一个工程，然后将这一个工程放在一个tomcat下，如果用户的访问量比较小，这是可以支撑的，当用户的访问量比较大时，这个服务就直接崩溃了。

一个tomcat服务器理论上可以支持500并发，实际上只有300-400左右。如果我们的并发量达到1000，怎么办？

此时，我们可以很自然得想到，可以新增多个tomcat来解决这个问题，即配置一个tomcat的集群，这种方式理论上也是可行的。

我们此时再增加一个tomcat，由于这两个tomcat需要分担这1000个并发量，所以我们需要使用负载均衡服务器（如nginx）放在前面来实现负载均衡。

但是这个时候就会有一个新的问题产生：

由于此时有多个服务器，当用户登录时，其信息会到其中一台tomcat下，如果他想要访问的某个服务却在另外一个tomcat服务中，那么他就无法访问，这就是因为Session信息在两个服务中不一致导致的问题，为了解决这个问题，我们就需要做Session共享。

什么是Session共享呢？

加入有两个tomcat，分别为A和B,A每隔一段时间就会向B广播自己有的Session，B接收到A广播的Session信息后，如果发现其中有Session是自己没有的，那么就会将其加入到自己的服务当中，同理B也会每隔一段时间向A广播自己的Session信息。这样就实现了Session共享。

这就解决了Session的问题。同时这种方式也理论上解决我们1000个并发所带来的问题。

但是这种方式会有瓶颈，如果我们此时的并发量上升到1万个，我们就需要20台服务器做tomcat集群。

然而当tomcat集群节点的数量增加时，服务器的能力先增加后下降。因为需要处理Session共享的问题，tomcat服务器太多，那么一台tomcat做Session共享的时间就会增加，而我们需要tomcat服务器处理的业务就没有资源来处理，所以就会导致服务器的能力下降。

所以集群中节点的数量不能太多，一般就5个左右。

那么我们如何处理更大数量的高并发问题呢？

从前面的叙述可以得知，部署过多的服务器之所以不行，就是因为会存在Session共享时间太长，导致资源被占用，实际需要被处理的业务逻辑无法获取到资源，所以只要我们解决了Session共享占用资源的问题，就可以处理高并发的问题了。

那么就有了以下架构方式：

我们将登陆系统单独拿出来，单点登录，即用户在一处登录后，整个系统的所有服务只要有权限均可访问，其他部分我们根据实际实现的功能分为不同的模块。

其他部门分成不同的模块是因为不同模块所面临的服务器压力是不一样的，如首页的服务器压力就比购物车所面临的服务器压力要高很多，所以按照不同的功能分为不同的模块，服务器压力比较高的模块就针对这个模块增加服务器集群，这样可以“因地制宜”，而不是一概而论。

这就是分布式，即多个系统相互协作完成功能。

各个系统之间需要进行通信，才能完成整个系统，通信可以使用WebService进行通信，由于WebService使用的基于Http协议传递的xml数据的方式进行通信，传输效率较低，也可以使用基于Http协议传递Json数据的Restful风格的通信方式（现在比较流行的方式），效率较高，效率最高的是基于scoket通信的Dubbo

以下是分布式结构的优缺点：

有了这些确定，我们在分布式架构的基础上再进行扩展，则为基于SOA的架构，面向服务的架构。

基于SOA的架构，也就是把工程拆分成服务层和表现层两个工程。

服务层中包含业务逻辑，只需要对外提供服务即可。每个服务只处理独立的功能。

表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现的。

如果服务层调用数据库的压力比较大，可以统一加缓存，减少服务器压力。这样缓存的利用率也比较高。

表现层和服务层依旧需要相互通信，可以按照不同的考虑选择不同的通信方式。

转载请注明出处。