dubbo

.

1. 项目架构演进：单体架构，垂直架构（各个机器之间不进行交互.模块A、B放在一台机器上，模块C、D放在一台机器上），分布式架构（出现公共模块，隔离出来，通过rpc来进行调用）、soa架构（dubbo就是这种架构下的产物，通过ESB企业服务总线来进行中转调用），微服务架构（springCloud这是这种架构下的产物，彻底分割，独立部署，彻底组件化）。
2. dubbo有两个重要功能：远程调用和服务治理。注册中心官方推荐使用zookeeper实现，也可以使用redis等实现，源阿里产品转移到apache顶级项目下，对国人友好。
3. 快速入门案例总结：代码+配置+引入依赖
   代码：消费方使用@Reference注解来进行服务发现并生成代理对象复制到某一个类的成员变量中，服务提供方使用dubbo提供的@Service注解来进行标识将其注册到注册中心中。
   配置主要配置三项：项目的名称（盲猜应该是在zk中标识每个项目），注册中心的地址，dubbo包扫描（扫描需要远程注入类所在的包或者服务提供方接口所在的包）。
   引入依赖：主要有dubbo的依赖和zk的依赖。 4.dubbo admin可以替代dubbo monitor（官方不推荐，不是很完善）。dubbo admin是一个项目，技术架构为vue + springboot，所以只需要下载部署前后端项目，前端使用node.js,使用npm启动，后端部署只需下载jdk，修改项目中注册中心地址（在application.properties文件中修改），使用mvn命令打包，运行即可。就可以通过浏览器访问dubbo admin的前端项目获取到注册中心中注册的服务信息。
   5.dubbo高级特性：

• 序列化。首先服务提供方和消费方都需要依赖暴露的接口项目（只有interface，不进行实现，由服务提供方进行实现）。当提供方和消费方之间传输对象时。比如要传输一个User对象，那么这个类必须实现serializable接口。
• 地址缓存。一个面试题：注册中心挂了，服务能不能正常被访问。答案是以前的服务有可能被正常访问。因为消费方有地址缓存，当消费放第一次请求注册中心时，就会把服务提供方的地址缓存下来，接下来在进行远程调用的时候都会读取自己本地的缓存，不需要每次访问都经过注册中心，所以以前的服务一段时间内可以被访问。服务消费方和注册中心之间的通信是一种subscribe（订阅）/notify（通知）的通信方式，当服务提供方的IP地址发生变化之后，注册中心会通过notify机制向消费方进行提醒，更改缓存的地址，以便可以被正常访问到。
• 超时机制：可以在@Service注解上或者@Reference注解上设置timeout属性，默认为1000ms，建议设置在服务提供方也就是@Service注解上，因为只有服务提供方才清楚服务提供方当前接口服务大约需要花费多长时间。在消费方的@Service注解上设置timeout属性会覆盖服务提供方设置的超时属性。当花费时间超过设置的超时属性值就会返回给服务消费方一个超时异常错误。
• 重试机制：可以在@Service注解上设置retries属性，默认为两次。也就是总共会调用三次，才会返回超时错误。当网络链接中断，超过超时所设置的超时时间，就会进行重试，直到执行重试次数达到所设置的次数时，才会向服务消费方返回错误。
• 多版本和灰度发布：先看张图：

服务提供者进行版本升级后，可以先让一部分服务消费者尝试新功能，其他服务还是尝试以前的服务，等到新功能没有出现毛病，才会让所有的消费者使用升级后的版本。具体实现步骤：可以在@Service注解上使用Version属性表明当前服务的版本号，然后在消费者者一段的@Reference中使用Version属性调用哪个版本的服务。

• 负载均衡：服务提供方可以搭建集群，可以在服务消费方的@Reference注解上使用loadBalance属性（负载均衡策略）设置不同的策略。在@Reference注解上的cluster属性来设置。有四种：
  
  权重越大，被调用的几率越高。
• 集群容错：服务调用出现错误之后，应该做何种处理：

1. 是继续调用直到成功（failback），非常重要的操作
2. 还是直接返回一个空的结果，忽略报错（failsafe），通常用于日志操作
3. 还是调用一台提供者的服务立即返回错误信息（failfast），通常用于写操作
4. 重试机制retries（failover），默认就是这种机制，重试两次
5. 并行调用多个服务提供者提供的服务，只要有一个返回成功就行（forking）
6. 广播调用所有的服务提供者集群，挨个调用，要是有一台报错，就返回消费调用错误信息。
   

• 服务降级
  通过服务消费者的@Reference注解的mock属性来进行配置。
  B机器的三个服务中支付服务是最重要的，其他两个服务不是特别重要，当B机器的服务器cpu等系统资源压力过大，就应该手动的关闭日志服务或者广告服务（force:return null），以腾出更多的系统资源来运行支付服务，或者调用这两个服务，但是失败了不会向消费者报错（fail:return null）。