vlambda博客
学习文章列表

一、Dubbo

Dubbo在前面作为一个RPC框架曾经提过，是阿里2012年开源的分布式服务框架。

经历了从单体到垂直应用架构、分布式服务架构，SOA（弹性计算）的几个重要的阶段的发展，性能出色，稳定性好积累了大量国内用户，经过停更及重新开启，目前已捐献给Apache开源基金会。

1.Dubbo将服务分为提供者和消费者。通过注册中心实现服务发现，它支持ZooKpeer,Redis,Multi和Simple几种类型的注册中心，后面两种由于本身的限制，无法达到生产级别要求。ZooKpeer,Redis相比较来说，ZooKpeer在可靠性上面比 Redis更强， Redis更适合用于缓存的场景。但这里要说的是ZooKpeer,Redis都不是阿里内部的实现方案，是开源的桥接实现方案。

下面是使用ZooKpeer作为注册中心时Dubbo的存储结构，可以看到Dubbo运行时所有信息都统一存入名称为Dubbo的根节点。每个服务会以类全名创建一个节点，下面分别创建providers和consumers子节点，用于存储服务提供者和服务消费者信息，每个提供者和消费者都会在相应节点创建一个临时节点，该临时节点以URL存储服务提供者或消费者的IP，端口，调用方法等原数据，以及传输协议，最大承载连接数，路由策略配置等，另外还有configurators和routers存储全局配置和路由。服务提供者启动时注册完信息后，消费者启动也会注册信息同时监听providers节点的变化。当有新节点加入或服务下线，消费者可以自动感知变化。

Duboo 支持多注册中心同时服务，以分组方式来做隔离。前面讲ZooKpeer时，讲到常用的客户端有zkClient和Curator

2.Dubbo提供负载均衡及灵活的负载均衡策略。主要支持随机，轮询，最少活跃调用数和一致性哈希四种策略。

默认是随机策略，调用量越大随机效果越好；轮询时绝对平均，要求服务节点能力基本持平，否则会导致大量请求阻塞在服务能力弱的节点上；最少活跃数可以让能力强的多干，能力弱的就少干；一致性哈希主要是在分布式缓存方案中，对于有状态的服务使用。

Dubbo为负载均衡提供了可配置的权重。具体配置代码参考

<dubbo:reference interface="…" loadbalance=“roundrobin” />

<duboo:reference interface="…">

<dubbo:method name="…" loadbalance=“roundrobin” />

</ dubbo:reference>

3.Dubbo作为RPC框架，其远程通信在之前分布式系统通信已经详细讲过。

通常口中的Dubbo是框架，而实际上其默认的通信协议也叫dubbo,当然还有RMI,HTTP,WebService,Thrift等。每个协议序列号协议，线程模型，消息派发方式都有很大区别。

dubbo通信协议，采用NIO实现多路复用，对于每个消费者，dubbo协议的服务提供者都会创建固定数量的长连接来处理，Dubbo使用线程池处理请求增强并发效率，不适合传输大文件/视频/高清图等，适合高并发的互联网小请求。其实现并没有使用java原生NIO包，而是采用Netty框架（可以通过配置切换为Mina或Grizzly）

支持多种序列化协议，可以通过配置修改，默认使用Hessian，除此之外还有JSON,Java原生序列化及Dubbo本身序列化协议。

4.Dubbo支持限流 ，可以在服务端配置也可以在通信协议上进行全局配置。

5.Dubbo的治理和监控这块，Dubbo本身有一个Dubbo-admin的治理中心为服务提供了分组查询，配置修改，加权/降权，禁用启用，权限控制等，便于运维工程师查询和调整运行时状态。监控这块的 dubbo-monitor主要是统计和分析调用，倾向于示例程序。

6.DubboX 是当当网对Dubbo的扩展和补充的开源 主要弥补了Dubbo不支持Restful风格的远程调用。

二、Spring Cloud

Spring Cloud是基于Spring Boot的侵入式服务治理框架，使统一的编程模型，为配置管理，服务发现，负载均衡，网关，断路器，控制总线，链路追踪等架构需求提供了完整方便的实现方案。最新版本是Spring Cloud Finchley.

1.开发脚手架Spring.io,

2,服务发现Eureka,Zookpeer,Consul

3.负载均衡 Ribbon

4.熔断 Hystrix

5.远程通信Feign

Feign是NetFlix提供的一个声明式的web服务客户端，支持JAX-RS及Spring MVC两种元注解，它整合了Ribbon和Hystrix让它同时具备负载均衡和熔断的能力，而Ribbon可以自动整合Eureka，因此通过Feign可以非常方便的把上面所列的服务实现一站式整合。

但是我们也可以看到，这种方便的同时给业务系统带来了很大的侵入性，要求全部掌握相关技术组件，开发框架成本还是比较高的。因此在选择时，不可以唯技术论。

三、服务链路追踪

在微服务的可观察性理论中，日志，指标，追踪时是三个紧密相关的概念。

追踪+日志 ------》分布式追踪

日志+指标 ------》 业务日志分析

追踪+指标 ------》应用监控 APM

这里主要关注 分布式追踪，理论支撑来自google 2010发表的论文Dapper,a lagre-scale distributed systems tracing infrastructure.

核心实现方法就是在请求上下文中加入 span id和parent id.

阿里的鹰眼系统是比较早实现方案。

常见的开源方案有

1.Apache ZipKin。

2.OpenTracing 作为接口协议，目前发展来看，还不能成为跟踪领域的API标准。

3.Google开源的OpenCensus 发展正猛。

国内在这一领域的代表是SkyWalking目前也是从个人项目转为Apache 基金项目，功能非常强大，且支持ServiceMesh Istio,有丰富的UI，基本可以实现开箱即用。

由于内容太多不再作讨论。

具体可以到https://github.com/apache/skywalking/tree/master/docs 详解阅读。

- END -

如果有所收获，请您点个“在看”

学习学习再学习

欢迎“留言”