服务框架dubbo(一):基础篇

学习博文：https://www.imooc.com/t/6300745

dubbo是一个分布式服务框架，致力于提供高性能透明化RPC远程调用方案，提供SOA服务治理解决方案。

• 因为dubbo各个分层都是不少扩展，
  • 注册中心有redis、zookeeper选项，
  • 通讯模块有netty、mina，
  • 序列化有hession、hession二、java序列化等，
  • 本文不能面面俱到，重点阐述主线流程，
    • 注册中心选择zookeeper(client选择curator)，
    • 通讯选择netty，
    • 协议选择dubbo，
    • 序列化选择hession2,
    • 容器选择Spring。
• 将应用拆分，并抽取出核心服务来解决上述问题，
• 还要考虑负载均衡、服务监控、高可用性、服务隔离与降级、路由策略、完善的容错机制、序列化方案的选择、通讯框架的选择、开发人员对底层细节无感知、服务升级兼容性等问题。

分布式服务调用时，每每会用到dubbo的负载均衡，dubbo提供多种可选的负载均衡策略进行配置，

• 但如何在调用的时候动态的指定某台机器直接调用呢，负载均衡策略并不能知足这个需求，解决这个问题，则须要经过动态配置路由策略来实现。

节点角色说明：

• Consumer：服务消费者，即服务调用方；
• Provider：服务提供者，即被调用方；
• Registry：注册中心，服务注册与服务发现，dubbo支持4种注册中心（multicast zookeeper redis simple），dubbo推荐使用zookeeper注册中心；
• Monitor：服务监控中心，提供服务调用次数和调用时间统计；
• Container：服务运行容器；

调用关系说明：

• 0. 服务容器负责启动，加载，运行服务提供者；
• 1. 服务提供者在启动时，向注册中心注册本身提供的服务；
• 2. 服务消费者在启动时，向注册中心订阅本身所需的服务；
• 3. 注册中心返回服务提供者地址列表给消费者，若是有变动，注册中心将基于长链接推送变动数据给消费者；
• 4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，若是调用失败，再选另外一台调用；
• 5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

Dubbo负载均衡

在集群负载均衡时，dubbo提供了4种均衡策略，缺省为random随机调用，具体策略以下：

• Random LoadBalance
  • 随机，按权重设置随机几率。
  • 在一个截面上碰撞的几率高，但调用量越大分布越均匀，并且按几率使用权重后也比较均匀，有利于动态调整提供者权重。

• RoundRobin LoadBalance

  • 轮循，按公约后的权重设置轮循比率。

  • 存在慢的提供者累积请求问题，好比：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，长此以往，全部请求都卡在调到第二台上。

• LeastActive LoadBalance

  • 最少活跃调用数，相同活跃数的随机，活跃数指调用先后计数差。

  • 使慢的提供者收到更少请求，由于越慢的提供者的调用先后计数差会越大。

• ConsistentHash LoadBalance

  • 一致性Hash，相同参数的请求老是发到同一提供者。

  • 当某一台提供者挂时，本来发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引发剧烈变更。

直连提供者

• dubbo自己也会提供直连指定服务提供者的方式，绕过注册中心，点对点链接到提供者。

动态配置路由规则

• dubbo服务的调用都是经过zookeeper注册中心完成，咱们是否能够向注册中心写入必定的路由规则，达到动态调用指定提供者的需求

• 以上代码的规则，归纳就是：
  • 对于全部调用com.foo.BarService接口的消费者，
  • 若是消费者的ip是"10.20.153.10"，那么这个消费者将调用ip为"10.20.153.11"的提供者，
  • 这样，经过动态配置注册中心的路由规则，就实现了动态指定某个提供者的需求。

管理端

监控中心：

dubbo几大核心组件：按照角色来划分分为：

• provider(服务提供方，对应前文的服务方)
• consumer(服务消费方，对应前文的调用方)
• monitor center(监控中心)
• registry center(注册中心，接下来咱们以zookeeper为例子说明)
• admin web console(管理端，用于修改路由、修改配置，最终做用于注册中心)

更细致的组件关系图：按功能来划分：

• directory (负责从zookeeper中心生成的provider列表)
• router (路由)
• fault-tolerantStrategy（容错策略）
• loadBalance(负载均衡)
• monitorFilter(监控拦截)
• zookeeperClient(Zoookeeper客户端，咱们使用zookeeper作例子)
• proxy(代理对象)
• nettyClient(咱们以netty做为通讯框架)
• nettyServer(咱们以netty做为通讯框架)
• Hession2Serialization(咱们选hession2做为序列化方案)

集群容错

• 什么是容错机制？ 容错机制指的是某种系统控制在必定范围内的一种容许或包容犯错状况的发生
• 在分布式架构下，网络、硬件、应用均可能发生故障，因为各个服务之间可能存在依赖关系，若是一条链路中的其中一个节点出现故障，将会致使雪崩效应。

• 为了减小某一个节点故障的影响范围，因此咱们才须要去构建容错服务，来优雅的处理这种中断的响应结果

Dubbo提供了6种容错机制，分别以下：

• failsafe 失败安全，能够认为是把错误吞掉（记录日志）
• failover(默认)   重试其余服务器； retries（2）--重试两次
• failfast 快速失败， 失败之后立马报错
• failback  失败后自动恢复。
• forking  forks. 设置并行数
• broadcast  广播，任意一台报错，则执行的方法报错

  • 配置方式以下，经过cluster方式，配置指定的容错方案：

服务降级

• 降级的目的是为了保证核心服务可用。
• 降级能够有几个层面的分类： 自动降级和人工降级；
  • 按照功能能够分为：读服务降级和写服务降级；
    1. 对一些非核心服务进行人工降级，在大促以前经过降级开关关闭哪些推荐内容、评价等对主流程没有影响的功能
    2. 故障降级，好比调用的远程服务挂了，网络故障、或者RPC服务返回异常。 那么能够直接降级，降级的方案好比设置默认值、采用兜底数据（系统推荐的行为广告挂了，能够提早准备静态页面作返回）等等
    3. 限流降级，在秒杀这种流量比较集中而且流量特别大的状况下，由于突发访问量特别大可能会致使系统支撑不了。这个时候能够采用限流来限制访问量。当达到阀值时，后续的请求被降级，好比进入排队页面，好比跳转到错误页（活动太火爆，稍后重试等）
• dubbo的降级方式： Mock
  • 实现步骤
    1. 在client端建立一个TestMock类，实现对应IGpHello的接口（须要对哪一个接口进行mock，就实现哪一个），名称必须以Mock结尾
    2. 在client端的xml配置文件中，添加以下配置，增长一个mock属性指向建立的TestMock
    3. 模拟错误（设置timeout），模拟超时异常，运行测试代码便可访问到TestMock这个类。当服务端故障解除之后，调用过程将恢复正常

配置的优先级别

• 以timeout为例，显示了配置的查找顺序，其它retries, loadbalance等相似
  • 方法级优先，接口级次之，全局配置再次之。
  • 若是级别同样，则消费方优先，提供方次之。

  • 其中，服务提供方配置，经过URL经由注册中心传递给消费方。

  • 建议由服务提供方设置超时，由于一个方法须要执行多长时间，服务提供方更清楚，

    • 若是一个消费方同时引用多个服务，就不须要关心每一个服务的超时设置