1. 分布式
- 什么是分布式：
分布式或者说SOA分布式重要的就是面向服务，简单地说分布式就是把整个系统拆分成不同的服务，然后将这些服务放在不同的服务器上，以减轻单体服务的压力提高并发量和性能。如果某一个服务的访问量较大的话也可以将这个服务同时部署在多台机器上。 - 为什么使用分布式：
- 从开发者角度来讲单体应用的代码都集中在一起，而分布式系统的代码根据业务被拆分。所以，每个团队可以负责一个服务的开发，这样提升了开发效率。另外，代码根据不同业务被拆分以后更加便于维护和扩展。
- 把整个系统拆分成不同的服务/系统，然后每个服务/系统部署在不同的机器上，将会很大程度提升服务性能。
- 不同的服务/系统之间的协同工作就要用到高性能的RPC框架 dubbo。dubbo作为分布式系统的桥梁。
2. RPC框架
2.1 什么是RPC框架
- RPC（Remote Procedure Call）——远程过程调用，它是一种通过网络，从远程计算机上请求服务，而不需要了解低层网络技术的协议。
- RPC 协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发分布式程序就像开发本地程序一样简单。
- RPC采用客户端（服务调用方）/服务器端（服务提供方）模式，都运行在自己的JVM中。客户端只需要引入要使用的接口，接口的实现和运行都在服务器端。RPC主要依赖的技术包括序列化、反序列化、数据传输协议，这是一种定义与实现相分离的设计。
- 比如两个不同的服务A、B部署在两台不同的机器上，那么服务A想要调用服务B中的某个方法怎么办呢？使用HTTP请求可以，但是可能会比较慢而且一些优化做得不好。RPC的出现就是为了解决这个问题。
- 目前Java使用较多的RPC方案主要有RMI（JDK自带）、Hessian、Dubbo、Thrift等。
注意：RPC主要指内部服务之间的调用，RESTful也可以用于内部服务之间的调用，但其主要用途还在于外部系统提供服务。
2.2 RPC的原理
- 服务消费方（client）以本地调用方式调用服务；
- client stub 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；（序列化用于传输的数据结构、对象）
- client stub 找到服务地址，并将消息发送到服务端；
- server stub 接到消息后进行解码；（反序列化）
- server stub 根据解码结果调用本地的服务；
- 本地服务执行并将结果返回给server stub；
- server stub 将返回结果打包成消息并发送至消费方；（序列化）
- client stub 接收到消息，并进行解码；（反序列化）
-
服务消费方得到最终结果；
1570506169241.png
2.3 常见RPC框架
RMI（JDK自带）
-
Dubbo
基于TCP协议
-
Hessian
基于HTTP协议
Hessian是一个轻量级的remotingohttp工具，使用最简单的方法提供了RMI的功能。相比WebService，Hessian更简单、快捷。采用的是二进制RPC协议，因为采用的是二进制协议，所以它很适合发送二进制数据。
-
Thrift
基于TCP协议
Apache Thrift是facebook开源的跨语言的RPC通信框架。由于其跨语言特性和出色的性能，在很多互联网公司得到应用。有能力的公司甚至会基于thrift研发一套分布式服务框架，增加诸如服务注册、服务发现等功能。
如何进行选择：
- 是否允许代码侵入：即需要响应的代码生成器生成相应的代码，比如Thrift；
- 是否需要长连接获取高性能：如果对于性能需求较高的haul，那么可以果断选择基于TCP的Thrift、Dubbo；
- 是否需要跨越网段、跨越防火墙：这种情况一般选择基于HTTP协议的Hessian和Thrift的HTTP Transport。
3. dubbo
3.1 Dubbo简介
Apache Dubbo 是一款高性能、轻量级的开源java RPC框架，它提供了三大核心能力：
- 面向接口的远程方法调用；
- 智能容错和负载均衡；
- 服务自动注册和发现。
简单来说Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。
3.2 why dubbo
Dubbo的诞生和SOA分布式架构的流行有着莫大的关系。
SOA（Service Oriented Architecture）面向服务架构：也就是把工程按照业务逻辑拆分成服务层、表现层两个工程。服务层中包含业务逻辑，只需要对外提供服务即可。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。SOA架构中有两个主要的角色：服务提供者（provider）和服务消费者（consumer）。
如果要开发分布式程序，也可以直接基于HTTP接口进行通信，但是为什么要用dubbo呢？ 因为dubbo提供以下四种特性：
- 负载均衡——同一个服务部署在不同的机器时该调用哪一台机器上的服务；
- 服务调用链路生成——随着系统的发展，服务越来越多，服务间依赖关系变得错综复杂，甚至分不清哪个应用要在哪个应用之前启动。Dubbo可以为我们解决服务之间互相是如何调用的；
- 服务访问压力以及时长统计、资源调度和治理——基于访问压力实时管理集群容量，提供集群利用率；
- 服务降级——某个服务挂掉后调用备用服务；
良好的RPC调用是面向服务的封装，针对服务的可用性和效率等都做了优化，单纯的使用http调用则缺少了这些特性。
3.3 dubbo框架
节点说明：
- Provider：暴露服务的服务提供方
- Consumer：调用远程服务的服务消费方
- Registry：服务注册与发现的注册中心
- Monitor：统计服务的调用次数和调用时间的监控中心
- Container：服务运行容器
注册中心Registry：
一个完整的dubbo应该是包括注册中心的。
注册中心用来注册服务和进行负载均衡，哪一个服务由哪一个机器来提供必需让调用者知道，简单来说就是IP地址和服务名称的对应关系。
dubbo官方提供了几种实现注册中心的方式：
- Multicast 注册中心；
- Zookeeper 注册中心；
- Redis 注册中心；
- Simple 注册中心；
调用关系说明：
- 服务容器负责启动、加载，运行服务提供者；
- 服务提供者在启动时，向注册中心注册自己提供的服务；
- 服务消费者在启动时，向注册中心订阅自己所需要的服务；
- 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给服务消费者；
- 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台进行调用；
- 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心；
重要知识点总结：
- 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小；
- 监控中心负责统计各服务调用次数、调用时间等，统计现在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示；
- 注册中心、服务提供者、服务消费者三者之间均为长连接，监控中心除外；
- 注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者；
- 注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了服务提供者列表；
- 注册中心和监控中心都是可选的，服务消费者可以直连服务提供者；
- 服务提供者无状态，任意一台宕掉后，不影响使用；
- 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复；
3.4 Dubbo工作原理
各层说明：
- service层：接口层，给服务提供者和消费者来实现的；
- config层：配置层，主要是对dubbo进行各种配置的；
- proxy层：服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton；
- registry层：服务注册层，负责服务的注册与发现；
- cluster层：集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务；
- monitor层：监控层，对RPC接口的调用次数和调用时间进行监控；
- protocol层：远程调用层，封装RPC调用；
- exchange层：信息交换层，封装请求响应模式，同步转异步；
- transport层：网络传输层，抽象mina和netty为统一接口；
- serialize层：数据序列化层，网络传输需要；
从下至上分为十层，各层均为单向依赖，每一层都可以剥离上一层被复用，其中，Service 和 Config 层为API，其它各层均为API。
3.5 Dubbo负载均衡策略
负载均衡通俗解释：
比如我们系统中某个服务的访问量特别大，我们将这个服务部署在多台机器上，当客户端发起请求的时候，多台服务器都可以处理这个请求，那么，如何正确选择处理该请求的服务器就很关键。假如只需要一台服务器来处理全部请求，那该服务部署在多台服务器的意义就不复存在了。
负载均衡就是为了避免单个服务器响应同一请求，容易造成服务器宕机，崩溃等问题。
Dubbo 的负责均衡策略：
在集群负载均衡时，Dubbo提供了多种均衡策略，默认为random随机调用。可以自行扩展负载均衡策略。
3.5.1 Random LoadBalance
默认的负载均衡策略，基于权重的随机负载均衡机制；
-
在一个界面上碰撞概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
1570591465252.png
3.5.2 RoundRobin LoadBalance
- 轮询，按公约后的权重设置轮询比率（不推荐，基于权重的轮询负载均衡机制）
- 算法原理：生成一个服务器序列，每当有请求到来时，就依次从该序列中取出下一个服务器用于处理该请求。比如上面的例子，基于权重的轮询算法会生成序列{1，2，3，1，2，2，2}，这样，每收到7个请求，会把其中的2个转发给service 1，把其中的4个转发给service 2，把其中的1个转发给service 3，收到第8个请求，重新从该序列的头部开始轮询。
- 存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那儿，久而久之，所有请求都卡在第二台上。
3.5.3 LeastActive LoadBalance
- 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
- 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
3.5.4 ConsistenHash LoadBalance
- 一致性Hash，相同参数的请求总是发到同一服务提供者。（如果你需要的不是随机负载均衡，是要一类请求都到一个节点，那就走这个一致性hash策略）
- 当某一台服务提供者挂掉时，原本发往该提供者的请求，基于虚拟节点，平摊到其他提供者，不会引起剧烈变动。
3.6 zookeeper宕机与dubbo直连的情况
在实际生产中，假如zookeeper注册中心宕掉，一段时间内服务消费方还是能够调用服务提供方的服务的，实际上它使用的是本地缓存进行通讯，这只是dubbo健壮性的一种体现。
dubbo健壮性表现：
- 监控中心宕掉不影响使用，只是丢失部分采样数据；
- 数据库宕掉后，注册中心仍然能通过缓存提供服务列表查询，但不能注册新服务；
- 注册中心对等集群，任意一台宕掉后，将自动切换到另一台；
- 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯；
- 服务提供者无状态，任意一台宕掉后，不影响使用；
- 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复。
前面提到：注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动的时候与注册中心交互，注册中心不转发请求，压力较小。所以，我们可以完全绕过注册中心——采用dubbo直连，即在服务消费方配置服务提供方的位置信息。
<dubbo:reference id="userService" interface="com.zang.gmall.service.UserService" url="dubbo://localhost:20880" />
