项目技术一栏表
1.分布式架构
所谓分布式,无非就是将一个系统拆(按功能)拆分成多个子系统并分布到多个服务器上.
分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。逻辑架构设计完后就该做物理架构设计，系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署，生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的，比如集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用。
1.1 了解分布式架构,我们需要了解系统架构的演变
阶段1:集中式架构
一个应用中包含所有的功能,例如订单,用户等
缺陷:
- 扩展不容易,如果要修改应用中某一个功能都会导致把整个应用重新打包
- 协同开发不容易,大家都去改同一个应用,可能会改乱,不利于维护
- 应用规模不大扩大后(功能越来越多),单体压力很大,光靠增加服务器的部署不能提升性能
阶段2:分布式系统
将一个单体的应用,根据功能拆分成多个小应用,将各个应用独立部署到服务器上按功能进行垂直拆分
每一个应用都有三层架构
缺点:
- 页面和业务逻辑的分离,因为在实际开发中,页面可能天天都需要改动,改一下页面就要重新对所有项目打包(服务层)部署,不合理,所以我们需要将页面和业务拆分
- 多个系统间，会有交互,例如在订单模块中可能要使用用户模块的功能查询用户信息(应用不可能完全独立),大量的应用之间需要交互
如何解决这些缺点呢,之后我们会讲到dubbo
2.聚合工程
聚合工程就是把一个工程分为各个部件,这些包括
- 根项目pom可以用来控制依赖的版本号
- 实体类taobao-bean
- 持久层接口taobao-dao
- 业务层service:taobao-service
- web层taobao-web
- 工具类taobao-utils等
可以分为这么多的模块平行开发,这些部件都不可以单独运行,它们之间相互依赖,最后合在一起成为一个完整可运行的web项目;
我们之后可以将各个模块独立打包安装到maven仓库,其他项目就可以依赖这个模块,同时聚合工程还支持继承,消除重复配置。对于继承关系的父POM来说，它不知道有哪些子模块继承于它，但是子模块必须知道自己的父POM是什么
3.dubbo
我们现在使用httpclient来访问远程服务,必须要知道服务器的ip和端口以及要调用哪个服务,当服务越来越多,就会发现调用关系非常复杂.
而dubbo则很好的解决了这个问题,我们不再是A系统直接调用B系统的服务,而是通过注册中心.
B系统将服务注册到注册中心(ip,端口,服务标识等信息),A系统订阅注册中心,于是注册中心就会找到这个服务将服务信息通知到A系统,于是A系统就能很容易的找到B系统
3.1 使用了分布式架构后,服务与服务之间有通信的需求
以往的远程通信方式
(1) Httpclient方式
发起的是Http请求的，使用Http协议。
我们发现，无论是Ajax请求，还是HttpClient都是通过 Http请求来访问服务端，使用的都是Http协议，而http协议是短连接。
RPC的底层协议，大部分都是使用长连接，减少了建立和销毁连接的次数，大大提高了程序的访问效率，但是会导致连接长期被占用。
3.2 承接分布式架构中系统架构的演变
阶段3:分布式架构,共享服务
形成分布式架构，把核心业务抽取成服务，形成服务中心
存在的问题：当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。 此时，用于提高机器利用率的资源调度和治理中心
调用关系太复杂
阶段4:服务治理
Dubbo就是资源调度和治理中心，用来解决这些问题的
3.3 Dubbo的架构
调用关系说明：
- 服务容器负责启动，加载，运行服务提供者。
- 服务提供者在启动时，向注册中心注册自己提供的服务。
- 服务消费者在启动时，向注册中心订阅自己所需的服务。
- 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
- 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
- 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。