dubbo初认知（dubbo和springCloud关系，在微服务架构中的作用等）（持续更新中）

一：dubbo是什么？

dobbuo是阿里开源的一个高性能优秀的服务框架，

可通过高性能的 RPC 实现服务的输出和输入功能，使得应用可以和高性能的rpc实现输入和输出的功能，可以了 Spring框架无缝集成。

Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

二：出现dubbo的原因：

1、之前是单机的服务，后来因为业务量的增加，服务器的数量也增加，由单机增加到集群，需要人工手动维护，增加代理。

这样不够高效，不够便捷，为了更加易于维护，所以出现了dubbo。

2、当我们在多个Tomcat部署不同的系统时, 例如A系统(TomcatA)想调用B系统(TomcatB)中的服务, 这时Dubbo就有了用武之地. 首先我们需要B系统在注册中心将自己的Url注册进去, 然后注册中心将Url返还给系统A, 那么系统A就可以调用了. 当然了我这里说的只是Dubbo的一种用法, 项目中使用的也是Dubbo的远程调用功能. (感觉真的和webservice有点像)

三：负载均衡：

1：服务器的负载均衡：可以是nginx，多个流量点聚集在nginx上面，由nginx负责选择合适的服务器去处理请求。

2：客户端的负载均衡：

1）、内网直接连用，可控制接口调用者。

2)、客户端自行选择连接的服务器。

四：dubbo架构图

节点角色说明：

Provider: 暴露服务的服务提供方。

Consumer: 调用远程服务的服务消费方。

Registry: 服务注册与发现的注册中心。

Monitor: 统计服务的调用次调和调用时间的监控中心。

Container: 服务运行容器。

这点我觉得非常好，角色分明，可以根据每个节点角色的状态来确定该服务是否正常。

0 服务容器负责启动，加载，运行服务提供者。

1. 服务提供者在启动时，向注册中心注册自己提供的服务。

主要介绍：

从服务提供者的角度看：当提供者服务启动时，需要自动向注册中心注册服务；
当提供者服务停止时，需要向注册中心注销服务；
提供者需要定时向注册中心发送心跳，一段时间未收到来自提供者的心跳后，认为提供者已经停止服务，从注册中心上摘取掉对应的服务。

2. 服务消费者在启动时，向注册中心订阅自己所需的服务。

主要介绍：

从调用者的角度看：调用者启动时订阅注册中心的消息并从注册中心获取提供者的地址；
当有提供者上线或者下线时，注册中心会告知到调用者；
调用者下线时，取消订阅。

3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

A服务要像调用b服务的方法，就是远程过程调用，也就是使用的java对象要在分布式中使用或者在rmi远程调用的网络中使用的话，那么相关的对象必须实现java序列化接口。

Java对象的序列化有两种方式：（摘自优知学院）

a.是相应的对象实现了序列化接口Serializable，这个使用的比较多，对于序列化接口Serializable接口是一个空的接口，它的主要作用就是标识这个对象时可序列化的，jre对象在传输对象的时候会进行相关的封装。

b.实现序列化的第二种方式为实现接口Externalizable。

补充：序列化是什么：

当A机器上的应用发起一个RPC调用时，调用方法和其入参等信息需要通过底层的网络协议如TCP传输到B机器，由于网络协议是基于二进制的，所有我们传输的参数数据都需要先进行序列化（Serialize）或者编组（marshal）成二进制的形式才能在网络中进行传输。然后通过寻址操作和网络传输将序列化或者编组之后的二进制数据发送给B机器。

反序列化是什么：

当B机器接收到A机器的应用发来的请求之后，又需要对接收到的参数等信息进行反序列化操作（序列化的逆操作），即将二进制信息恢复为内存中的表达方式，然后再找到对应的方法（寻址的一部分）进行本地调用（一般是通过生成代理Proxy去调用,
通常会有JDK动态代理、CGLIB动态代理、Javassist生成字节码技术等），之后得到调用的返回值。

dubbo与Spring的关系，spring集成的优点

Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。

五、微服务的架构图（一张互联网通用的架构图,其中每个环节都是微服务的核心部分。）

架构分解（摘自茶轴的青春）

网关集群：数据的聚合、实现对接入客户端的身份认证、防报文重放与防数据篡改、功能调用的业务鉴权、响应数据的脱敏、流量与并发控制等

业务集群：一般情况下移动端访问和浏览器访问的网关需要隔离，防止业务耦合

Local Cache：由于客户端访问业务可能需要调用多个服务聚合，所以本地缓存有效的降低了服务调用的频次，同时也提示了访问速度。本地缓存一般使用自动过期方式，业务场景中允许有一定的数据延时。

服务层：原子服务层，实现基础的增删改查功能，如果需要依赖其他服务需要在Service层主动调用

Remote Cache：访问DB前置一层分布式缓存，减少DB交互次数，提升系统的TPS

DAL：数据访问层，如果单表数据量过大则需要通过DAL层做数据的分库分表处理。

MQ：消息队列用来解耦服务之间的依赖，异步调用可以通过MQ的方式来执行

数据库主从：服务化过程中毕竟的阶段，用来提升系统的TPS。

六：dubbo和springCloud之间的关系

Spring Cloud：服务提供方和服务消费方通过json方式交互，因此只需要定义好相关json字段即可，消费方和提供方无接口依赖。通过注解方式来实现服务配置，对于程序有一定入侵。

dubbo的接口依赖：通过xml配置方式即可方面接入dubbo，对程序无入侵。

七：Dubbo组件运行流程

gateWay:前置网关，具体业务操作，gateWay通过dubbo提供的负载均衡机制自动完成。

Service：原子服务，只提供该业务相关的原子服务。

Zookeeper：原子服务注册到zk上。

Spring Cloud 组件运行

Spring Cloud

所有请求都统一通过 API 网关（Zuul）来访问内部服务。

网关接收到请求后，从注册中心（Eureka）获取可用服务。

由 Ribbon 进行均衡负载后，分发到后端的具体实例。

微服务之间通过 Feign 进行通信处理业务。

两者之间的比较：

业务部署方式相同，都需要前置一个网关来隔绝外部直接调用原子服务的风险。

Dubbo需要自己开发一套API 网关，而Spring Cloud则可以通过Zuul配置即可完成网关定制。

使用方式上Spring Cloud略胜一筹。

服务启动方式建议使用jar方式启动，启动速度快，更容易监控

缓存、缓存、缓存，系统中能使用缓存的地方尽量使用缓存，通过合理的使用缓存可以有效的提高系统的TPS

服务拆分要合理，尽量避免因服务拆分而导致的服务循环依赖

合理的设置线程池，避免设置过大或者过小导致系统异常

根据自身的研发水平和所处阶段选择合适的架构来解决业务问题，不管是Dubbo还是Spring Cloud都是实现微服务有效的工具。

（部分内容参考了来自百家号的茶轴的青春）