单体架构：全部功能集中在一个项目内（All in one）。 打一个war, 一个tomcat
垂直架构：单体架构中的多个模块拆分为多个独立的项目。形成多个独立的单体架构。每个业务模块就是一个war，一个tomcat
分布式架构：在垂直架构的基础上，将公共业务模块抽取出来，作为独立的服务，供其他调用者消费，以实现服务的共享和重用。应用调用服务(ip写死)，服务挂了就不能用了，缺少服务治理。把业务服务(service+dao)拆分成一个war包，一个tomcat里。
SOA架构：Service-Oriented Architecture，面向服务的架构。是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。
服务的提供者（以服务为主 service调用dao->数据库），消费者。dubbo作为调度的工具（RPC协议），服务提供者与消费都注册到中心(一般使用Zookeeper)，由中心统一管理分配，失败重试，负载均衡。。。有服务治理
微服务架构：微服务架构是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
- 将系统服务层完全独立出来，抽取为一个一个的微服务。 以功能为主(controller->service-dao->数据库 独立)
- 采用轻量级框架协议传输。（可以使用spring cloud）（http协议 restful json）
- 每个服务都使用不同的数据库，完全独立和解耦 (分库分表)。
Remote Procedure Call 远程过程调用，并不是一个具体的技术，而是指整个网络远程调用过程。RPC是一个泛化的概念，严格来说一切远程过程调用手段都属于RPC范畴。各种开发语言都有自己的RPC框架。
RPC作为分布式架构的核心，按响应方式分如下两种：
- 同步调用：客户端调用服务方方法，等待直到服务方返回结果或者超时，再继续自己的操作。
- 异步调用：客户端把消息发送给中间件，不再等待服务端返回，直接继续自己的操作。
组件：
- 客户端(Client)：服务调用者
- 客户端存根(Client Stub)：存放服务端地址信息，将客户端的请求参数打包成网络消息，再通过网络发送给服务方
- 服务端存根(Server Stub)：接受客户端发送过来的消息并解包，再调用本地服务
- 服务端(Server)：服务提供者。
调用过程：客户端->客户端存根->服务端存根->服务端->服务端存根->客户端存根->客户端
3. Dubbo概述Apache Dubbo是一款高性能、轻量级的开源Java RPC框架，可以和Spring框架无缝集成。
Dubbo提供了三大核心能力：面向【接口】的远程方法调用，智能容错和负载均衡，以及服务自动注册（dubbo负责注册在zookeeper创建节点数据）和发现(订阅 watch, dubbo)。
架构：
-
虚线都是异步访问，实线都是同步访问；蓝色虚线:在启动时完成的功能；红色虚线(实线)都是程序运行过程中执行的功能
-
节点介绍：
节点 角色名称 Provider 暴露服务的服务提供方 服务方 Consumer 调用远程服务的服务消费方 调用方 Registry 服务注册与发现的注册中心 Monitor 统计服务的调用次数和调用时间的监控中心 Container 服务运行容器
-
调用流程
-
服务容器负责启动，加载，运行服务提供者。
-
服务提供者在启动时，向注册中心注册自己提供的服务。
-
服务消费者在启动时，向注册中心订阅自己所需的服务。
-
注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接(相对于发送完数据及结束的连接)推送通知消费者。
-
服务消费者，从注册中心摘取服务提供者列表，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
-
服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
-
Dubbo作为一个RPC框架，其最核心的功能就是要实现跨网络的远程调用。服务提供者、服务消费者位于不同的模块，每个模块都是一个独立的项目，需要达成war包、发布。通过配置文件对各个模块之间进行配置，实现远程调用。
-
定义公共pojo模块
public class User implements Serializable { private Integer id; private Integer age; private String username; } -
定义接口模块
public interface UserService { User findById(int id); } -
定义服务提供者模块
-
导入依赖
4.0.0 com.itheima dubbo-service 1.0-SNAPSHOT war 5.1.9.RELEASE 2.7.4.1 4.0.0 org.apache.dubbo dubbo ${dubbo.version} org.apache.curator curator-framework ${zookeeper.version} org.apache.curator curator-recipes ${zookeeper.version} com.itheima dubbo-interface 1.0-SNAPSHOT org.apache.tomcat.maven tomcat7-maven-plugin 2.1 9000 / -
要使用Dubbo提供的@Service注解，才能将服务注册到注册重心
import org.apache.dubbo.config.annotation.Service; //@Service//将该类的对象创建出来，放到Spring的IOC容器中 bean定义 @Service//将这个类提供的方法（服务）对外发布。将访问的地址 ip，端口，路径注册到注册中心中 public class UserServiceImpl implements UserService { public String sayHello() { return "hello dubbo hello!~"; } } -
配置Spring文件：配置Dubbo信息
-
配置Web项目：加载Spring配置文件
contextConfigLocation classpath*:spring/applicationContext*.xml org.springframework.web.context.ContextLoaderListener
-
-
定义服务消费者模块
-
导入依赖
-
要使用Dubbo的远程注入，才能RPC调用注册中心的Service
@RestController @RequestMapping("/user") public class UserController { //注入Service //@Autowired//本地注入 @Reference//使用Dubbo的远程注入 private UserService userService; @RequestMapping("/sayHello") public String sayHello(){ return userService.sayHello(); } } -
配置文件：配置Dubbo信息
-
配置Web项目：加载Spring和SpringMVC信息
springmvc org.springframework.web.servlet.DispatcherServlet contextConfigLocation classpath:spring/springmvc.xml springmvc *.do
-
- dubbo服务消费者在第一次调用时，会将服务提供方地址缓存到本地，以后在调用则不会访问注册中心
- 当注册中心挂了，服务依然可以正常访问
- 但当服务提供者地址发生变化时，注册中心会通知服务消费者。
服务消费者在调用服务提供者时发生了阻塞、等待，则会一直等下去，在某个峰值时刻，大量的请求都在同时请求服务消费者，会造成线程的大量堆积，势必会造成雪崩。
-
dubbo 利用超时机制来解决这个问题，设置一个超时时间，在这个时间段内，无法完成服务访问，则自动断开连接。
-
使用timeout属性配置超时时间，默认值1000，单位毫秒。通过 retries 属性来设置重试次数。默认为 2 次。当服务方与消费方都设置了超时时间时，默认优先选择消费方的超时时间，但建议设置服务方的时间。
服务方设置超时时间
@Service(timeout = 3000,retries = 2)//当前服务3秒超时,重试2次，一共3次 public class UserServiceImpl implements UserService { public String sayHello() { return "hello dubbo hello!~"; } }消费方设置超时时间
@RestController @RequestMapping("/user") public class UserController { @Reference(timeout = 1000) private UserService userService; @RequestMapping("/sayHello") public String sayHello(){ return userService.sayHello(); } }
灰度发布：当出现新功能时，会让一部分用户先使用新功能，用户反馈没问题时，再将所有用户迁移到新功能。
dubbo 中使用version 属性来设置和调用同一个接口的不同版本
服务方
-
版本一
@Service(version = "v1.0") //设置版本 public class UserServiceImpl implements UserService { public String sayHello() { return "hello dubbo 1!~"; } } -
版本二
@Service(version = "v2.0") //设置版本 public class UserServiceImpl2 implements UserService { public String sayHello() { return "hello dubbo 2!~"; } }
消费方
@RestController
@RequestMapping("/user")
public class UserController {
@Reference(version = "v2.0") //指定版本
private UserService userService;
}
4. 负载均衡
负载均衡（Load Balance）：其实就是将请求分摊到多个操作单元上进行执行，从而共同完成工作任务。
在集群负载均衡时，Dubbo 提供了多种均衡策略
- 随机random：默认策略，按权重随机，默认值。按权重设置随机概率。
- 轮询roundrobin：按权重轮询。
- 最少活跃调用数leastactive：最少活跃调用数，相同活跃数的随机。
- 一致性哈希consistent hash：相同参数的请求总是发到同一提供者。
配置方式：
-
默认权重：配置负载均衡策略，既可以在服务提供者一方配置（@Service(loadbalance = “roundrobin”)），也可以在服务消费者一方配置（@Reference(loadbalance = “roundrobin”)），两者取一
-
设置权重
-
服务方通过weight属性设置权重
@Service(weight = 100) //设置权重 public class UserServiceImpl implements UserService { public String sayHello() { return "3......"; } } -
消费方
@RestController @RequestMapping("/user") public class UserController { @Reference(loadbalance = "random") //设置负载均衡方式 private UserService userService; @RequestMapping("/sayHello") public String sayHello(){ return userService.sayHello(); } }
- Failover Cluster：失败重试。默认值。当出现失败，重试其它服务器 ，默认重试2次，使用 retries 配置。一般用于读操作。
- Failfast Cluster ：快速失败，只发起一次调用，失败立即报错。通常用于写操作。
- Failback Cluster ：失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
- Forking Cluster ：并行调用多个服务器，只要一个成功即返回
- Broadcast Cluster ：广播调用所有提供者，逐个调用，任意一台报错则报错。
-
