实战day01（四）----系统架构演变

任何网站至少要有前台和后台两部分。前台给客户用的，后台给公司内部员工用的。

前台并发量高，后台并发量低。前台是我们的重点。

一、功能列表

后台管理系统：管理商品、订单、类目、商品规格属性、用户管理以及内容发布等功能。

前台系统：用户可以在前台系统中进行注册、登录、浏览商品、首页、下单等操作。

会员系统：用户可以在该系统中查询已下的订单、收藏的商品、我的优惠券、团购等信息。

订单系统：提供下单、查询订单、修改订单状态、定时处理订单。

搜索系统：提供商品的搜索功能。

单点登录系统：为多个系统之间提供用户登录凭证以及查询登录用户的信息。

二、系统架构

2.1 传统架构

2.2 1000个并发

项目发布了。访问的人多了，比如1000个并发。一个tomcat理论支持500并发。

有两个tomcat，就有两台服务器，两台服务器的ip不一样。用户请求来了，它该访问那台服务器呢？

比如，我们访问百度：https://www.baidu.com/，通过这个域名访问。一个域名对应一个ip地址。这就需要一个负载均衡服务器。所有请求先到这个负载均衡服务器。把负载分配到上面的两个服务器上。

集群，好多台服务器上运行的是同一个工程。

在两个tomcat上部署的工程是一模一样的。登录之后，会有一个session。两个tomcat就会需要两个session。这就要解决session共享的问题。有一种方法是session复制，每个tomcat向集群中的其他tomcat广播session信息。

2.3 10000并发

那么现在就需要20台服务器了。20台服务器都在tomcat广播session（session复制），而我们内网的带宽就那么大，都在做tomcat广播，没有功夫做业务了。随着集群中服务器的数量增多，这个集群的服务能是抛物线的。不是服务器越多，性能越好。

需要20台服务器做tomcat集群。当tomcat集群中节点数量增加，服务能力先增加后下降。就是因为session复制导致的。

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

怎么解决？

如果解决session复制问题，那就不会限制节点数量了。session是登录相关的，那么，可以把登录的功能拆分出来，所有的session放到一个系统里去管理。所有登录，都到登录系统去登录，查看登录状态，也去登录系统去判断。这样，节点之间就不用配置session复制了。节点的数量就不限制了。

系统中，并不是所有的功能点并发量都那么高，首页并发量高，订单的并发量没那么高。那么，我们可以把首页功能单独提出来做成一个独立的系统。订单也做成一个独立的系统。如下面所示，一个功能做成一个独立的系统，一个war包。

需要按照功能点把系统拆分，拆分成独立的功能。单独为某一个节点添加服务器。需要系统之间配合才能完成整个业务逻辑。叫做分布式。哪个部分压力大，就给那个部分添加服务器。每个节点都可以加n台服务器。分布式中，每个节点都可以配置集群。

现在就需要解决系统之间通信的问题了。webservice，socket。

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

集群：同一个工程部署到多台服务器上。

分布式架构：

把系统按照模块拆分成多个子系统。

优点：

1、把模块拆分，使用接口通信，降低模块之间的耦合度。

2、把项目拆分成若干个子项目，不同的团队负责不同的子项目。

3、增加功能时只需要再增加一个子项目，调用其他系统的接口就可以。

4、可以灵活的进行分布式部署。

缺点：

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

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

2.4 基于soa的架构

前台系统需要有查询商品的功能，订单系统也要有查询商品的功能。那么，我们是否可以把查询商品的功能提取出来。

根据上面思路，把工程拆分成不同的子系统。不同的子系统有一些共同的功能，把这些共同功能提取出来。就是SOA的思想。业务层单独抽出来，表现层分成不同的子系统。表现层就没有业务了，只有controller。service和dao提出来，谁都可以用。

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

2.5 商城系统架构

dubbo是基于socket的通信方式，传的是二进制，通信效率高。dubbo不能跨语言，只能是java。