RPC,MQ,数据同步

概述

这个文档的目的是想更清楚的展示RPC、MQ和数据同步的正确使用场景，以及正确的使用方式，最重要的是要用好！！！

在这次分享中，我会介绍几个工具，帮助大家更深入的了解JAVA程序的一些知识！

这里面部分链接使用的是cf.lefu8.com的域名，请自觉增加host配置  192.168.16.38 cf.lefu8.com

RPC服务治理-Dubbo

RPC服务基础

RPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。

RPC服务的变迁

1. 最开始的实现是Hessian
   Hessian 是简单的点对点调用，相互直接暴露端口和地址，底层网络默认基于HTTP协议传输，Hessian的优点是序列化后的数据量小
2. Dubbo服务的引入
   Dubbo是一个比较完成的服务治理体系，涵盖了RPC的大部门区域。 

Dubbo精简的介绍

因为Dubbo提供的特性其实是很多的，但是在一般的应用场景里面有一些特性几乎就不会使用到，所以我这里整理里几个很基础的特性进行介绍。完整的文档点击http://dubbo.io/User+Guide-zh.htm

整理结构

主要角色有：

1. Registry 注册中心，用于记录订阅关系，配置和路由信息等。
2. Provider 服务提供者，接口的实现类，用于提供对外的服务调用。
3. Consumer 服务消费者，接口的代理类，用于调用远程的服务。
4. Monitor 监控相关的服务，非必须。统计调用情况。

服务关系由上面的几个角色来体现，但实际上还有一部分组成是Dubbo的控制台，这个后面展示！

基本用法

现在已经全部使用上Dubbo了，没有概念的参考资料库：

Dubbo使用指南

启动时检查

这个一般是针对消费者而言的，在启动的时候会去检查服务是否已经在注册中心注册。

文档

线程模型

是服务提供方的线程使用模型，这个很重要！

有三种线程模型：fixed,cached,limited，看看具体的线程使用情况，线程使用一定要有度！

文档

多注册中心

多注册中心可以支持服务多地部署

文档

服务分组

服务分组的概念可以在集群环境下提供更小范围的服务定义。

文档

多版本

多版本对于接口升级的平滑迁移是非常好用的。

文档

连接控制

RPC调用使用的网络连接，对性能有很大的影响。

文档

令牌验证

开启令牌验证可以防止错误的配置使用服务。

文档

关于配置需要注意的地方

1. Dubbo的标签有部分是唯一的
2. Dubbo的标签有部分是唯一的
3. Dubbo的标签有部分是唯一的
4. 方法级优先，接口级次之，全局配置再次之。
5. 如果级别一样，则消费方优先，提供方次之。
6. 确定唯一服务的要素是 Group+接口+Version。

关于控制台

见实际操作演示

总结

重点是如何用好Dubbo，为我们的系统提供更好的性能服务。

消息中间件RocketMQ

对于消息中间件，我们的理解基本上是用来发消息的，然后接收消息进行业务处理。消息中间件的一个重要特性是系统无关性，主要用于系统间解藕。

基本用法

参考资料库：

Astrotrain(RocketMQ)基本用法

核心概念

1. RocketMQ是一个分布式的消息中间件，不存在单点
2. 消息堆积能力很强大
3. RocketMQ是基于kafka的设计思想的JAVA版本实现，kafka官方文档说明documentation.html
4. 理解订阅组的关系非常重要

总结

消息适合异步场景，消息发送者并不关心消息处理者的动作。

1. 消息可以在多应用间实现复用，发送者定义的消息可以被多个应用以不同逻辑消费，而对发送者而言什么都不需要进行调整。
2. 分布式的场景不支持顺序消息，顺序消息在分布式的场景里本身就不是准确的。
3. 消息的使用难点是消息体的定义和消费逻辑的处理，确保消息之间不存在复杂的关联关系非常重要。
4. 消息与RPC有一部分区域是重叠的，所以选择使用RPC还是消息去实现功能需要思考清楚。
5. 订阅组和主题的自动创建功能在测试环境和生产都是关闭的，上线前一定要确认订阅组和主题存在。这个BUG一样的存在一定要切记！！！！！！！！！！
6. 消息有很小的几率会出现重复，这个需要在业务上保证去重！

数据同步

数据同步在我们的应用系统里大概有这么三种方式：

1. 数据库自身的同步，主从复制
2. 同步工具
3. Databus

这里会重点介绍即将使用到的Databus。

数据库自身的同步

在这种模式下，一般会存在一个可读可写的主库，称之为Master，然后会使用复制的技术实现1个或多个完全一致的只读备库Slave。

这是应用实现读写分离的基础。

同步工具

同步工具是个简单的异构库之前的数据同步工具，依赖数据的版本信息进行同步。

因为简单，所以功能也很有局限性，适合小数据量的表同步，可以很简单的实现不同库之间的数据同步。

对大表的同步性能影响很严重，因为是全表扫描的方式进行同步，表数据量越大效果越差。

Databus

Databus是linkedIn公司开源的一个产品，是一个分布式的数据库同步产品，说明文档在github上有：

https://github.com/linkedin/databus/wiki

架构图

Relay:

Client:

节点说明

1. Relay        数据抓取的主体，由relay从不同数据源中抓取变更集
2. Client        客户端，由应用实现消费监听，消费relay抓取的数据
3. Bootstrap produce  一种特殊的客户端，也从relay抓取数据，存入Mysql库中，供应用消费很久之前的数据
4. Bootstrap server     消费旧数据的服务提供方

Databus提供的消费能力有点类似消息中间件，可以多重消费，由应用决定数据如何处理。

Databus的特性说明

Databus的角色定位应该是数据库间数据同步的解决方案(包括异构表结构和不同数据库之间同步)，它主要由两部分功能组成：一、从数据库中抓取源变更数据 二、组织化源数据供应用消费。它的主要定位是提供源数据读取能力，并将消费能力提升至应用层面，由应用去选择如何导入数据，这也是它能处理异构库和表的原因，应用去解决这些差异了。

Relay目前开源的版本里只支持Oracle的数据库数据抓取，Mysql的需要自己实现，可以基由开源项目open-replicator读取Mysql日志实现，现在着重说一下Oracle的数据抓取。

Relay并不是读取的Oracle日志实现的数据抓取，这里官方给的说明是Oracle不同版本之间的日志存在差异，基于日志的读取需要维护版本的差异，无法提供稳定的程序版本，Relay是基于数据库的undo(Flashback技术)实现的抓取，默认在源数据库中有相关的存储过程和任务在执行，同时对于源表的数据抓取需要新增一列(TXN存储变更事务号)，并且提供了一个触发器，针对insert/update的语句进行变更集的记录，不影响查询，不记录删除。

也就是说Relay对源表是存在一定入侵的，同时性能也会存在损耗。

操作演示

看操作

最后的部分

这里我想给大家展示一下我对现在系统架构的一个理解：

1. 最上面两层是负载和分发，基本跟开发没多大关系
2. APP层是我们主要的产出，上下层都是为这一层服务的
3. 数据库层是最早会出现性能问题的地方，前期读写分离就很重要了。
4. 缓存是有效提升性能的手段，可以大量减少数据库的访问。
5. RPC和中间件就是应用往分布式发展的统一治理手段了。