概述
这个文档的目的是想更清楚的展示RPC、MQ和数据同步的正确使用场景，以及正确的使用方式，最重要的是要用好！！！
在这次分享中，我会介绍几个工具，帮助大家更深入的了解JAVA程序的一些知识！
这里面部分链接使用的是cf.lefu8.com的域名，请自觉增加host配置 192.168.16.38 cf.lefu8.com
RPC服务治理-Dubbo
RPC服务基础
RPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。
RPC服务的变迁
- 最开始的实现是Hessian
Hessian 是简单的点对点调用，相互直接暴露端口和地址，底层网络默认基于HTTP协议传输，Hessian的优点是序列化后的数据量小 - Dubbo服务的引入
Dubbo是一个比较完成的服务治理体系，涵盖了RPC的大部门区域。
Dubbo精简的介绍
因为Dubbo提供的特性其实是很多的，但是在一般的应用场景里面有一些特性几乎就不会使用到，所以我这里整理里几个很基础的特性进行介绍。完整的文档点击http://dubbo.io/User+Guide-zh.htm
整理结构
主要角色有：
- Registry 注册中心，用于记录订阅关系，配置和路由信息等。
- Provider 服务提供者，接口的实现类，用于提供对外的服务调用。
- Consumer 服务消费者，接口的代理类，用于调用远程的服务。
- Monitor 监控相关的服务，非必须。统计调用情况。
服务关系由上面的几个角色来体现，但实际上还有一部分组成是Dubbo的控制台，这个后面展示！
基本用法
现在已经全部使用上Dubbo了，没有概念的参考资料库：
启动时检查
这个一般是针对消费者而言的，在启动的时候会去检查服务是否已经在注册中心注册。
线程模型
是服务提供方的线程使用模型，这个很重要！
有三种线程模型：fixed,cached,limited，看看具体的线程使用情况，线程使用一定要有度！
多注册中心
多注册中心可以支持服务多地部署
服务分组
服务分组的概念可以在集群环境下提供更小范围的服务定义。
多版本
多版本对于接口升级的平滑迁移是非常好用的。
连接控制
RPC调用使用的网络连接，对性能有很大的影响。
令牌验证
开启令牌验证可以防止错误的配置使用服务。
关于配置需要注意的地方
- Dubbo的标签有部分是唯一的
- Dubbo的标签有部分是唯一的
- Dubbo的标签有部分是唯一的
- 方法级优先，接口级次之，全局配置再次之。
- 如果级别一样，则消费方优先，提供方次之。
- 确定唯一服务的要素是 Group+接口+Version。
关于控制台
见实际操作演示
总结
重点是如何用好Dubbo，为我们的系统提供更好的性能服务。
消息中间件RocketMQ
对于消息中间件，我们的理解基本上是用来发消息的，然后接收消息进行业务处理。消息中间件的一个重要特性是系统无关性，主要用于系统间解藕。
基本用法
参考资料库：
核心概念
- RocketMQ是一个分布式的消息中间件，不存在单点
- 消息堆积能力很强大
- RocketMQ是基于kafka的设计思想的JAVA版本实现，kafka官方文档说明documentation.html
- 理解订阅组的关系非常重要
总结
消息适合异步场景，消息发送者并不关心消息处理者的动作。
- 消息可以在多应用间实现复用，发送者定义的消息可以被多个应用以不同逻辑消费，而对发送者而言什么都不需要进行调整。
- 分布式的场景不支持顺序消息，顺序消息在分布式的场景里本身就不是准确的。
- 消息的使用难点是消息体的定义和消费逻辑的处理，确保消息之间不存在复杂的关联关系非常重要。
- 消息与RPC有一部分区域是重叠的，所以选择使用RPC还是消息去实现功能需要思考清楚。
- 订阅组和主题的自动创建功能在测试环境和生产都是关闭的，上线前一定要确认订阅组和主题存在。这个BUG一样的存在一定要切记！！！！！！！！！！
- 消息有很小的几率会出现重复，这个需要在业务上保证去重！
数据同步
数据同步在我们的应用系统里大概有这么三种方式：
- 数据库自身的同步，主从复制
- 同步工具
- Databus
这里会重点介绍即将使用到的Databus。
数据库自身的同步
在这种模式下，一般会存在一个可读可写的主库，称之为Master，然后会使用复制的技术实现1个或多个完全一致的只读备库Slave。
这是应用实现读写分离的基础。
同步工具
同步工具是个简单的异构库之前的数据同步工具，依赖数据的版本信息进行同步。
因为简单，所以功能也很有局限性，适合小数据量的表同步，可以很简单的实现不同库之间的数据同步。
对大表的同步性能影响很严重，因为是全表扫描的方式进行同步，表数据量越大效果越差。
Databus
Databus是linkedIn公司开源的一个产品，是一个分布式的数据库同步产品，说明文档在github上有：
https://github.com/linkedin/databus/wiki
架构图
Relay:
Client:
节点说明
- Relay 数据抓取的主体，由relay从不同数据源中抓取变更集
- Client 客户端，由应用实现消费监听，消费relay抓取的数据
- Bootstrap produce 一种特殊的客户端，也从relay抓取数据，存入Mysql库中，供应用消费很久之前的数据
- Bootstrap server 消费旧数据的服务提供方
Databus提供的消费能力有点类似消息中间件，可以多重消费，由应用决定数据如何处理。
Databus的特性说明
Databus的角色定位应该是数据库间数据同步的解决方案(包括异构表结构和不同数据库之间同步)，它主要由两部分功能组成：一、从数据库中抓取源变更数据 二、组织化源数据供应用消费。它的主要定位是提供源数据读取能力，并将消费能力提升至应用层面，由应用去选择如何导入数据，这也是它能处理异构库和表的原因，应用去解决这些差异了。
Relay目前开源的版本里只支持Oracle的数据库数据抓取，Mysql的需要自己实现，可以基由开源项目open-replicator读取Mysql日志实现，现在着重说一下Oracle的数据抓取。
Relay并不是读取的Oracle日志实现的数据抓取，这里官方给的说明是Oracle不同版本之间的日志存在差异，基于日志的读取需要维护版本的差异，无法提供稳定的程序版本，Relay是基于数据库的undo(Flashback技术)实现的抓取，默认在源数据库中有相关的存储过程和任务在执行，同时对于源表的数据抓取需要新增一列(TXN存储变更事务号)，并且提供了一个触发器，针对insert/update的语句进行变更集的记录，不影响查询，不记录删除。
也就是说Relay对源表是存在一定入侵的，同时性能也会存在损耗。
操作演示
看操作
最后的部分
这里我想给大家展示一下我对现在系统架构的一个理解：
- 最上面两层是负载和分发，基本跟开发没多大关系
- APP层是我们主要的产出，上下层都是为这一层服务的
- 数据库层是最早会出现性能问题的地方，前期读写分离就很重要了。
- 缓存是有效提升性能的手段，可以大量减少数据库的访问。
- RPC和中间件就是应用往分布式发展的统一治理手段了。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
