配置中心

配置中心定义

配置中心目的

配置中心选型

开源配置中心

选型对比

配置中心是AP模型？

比如将超时时间从100毫米修改为200毫米1秒后生效还是1分钟生效都没有关系无非是用户体验的问题

1秒之后还是多久之后 这是准实时非实时（没有延迟）

最好方案:携程阿波罗

用阿波罗的公司

基础模型

配置中心首页

添加/修改配置

客户端获取

通过注解方式也可以获取

核心概念

新建集群

添加namespace

获取自定义的namespace

添加配置项

逻辑架构图

Eureka通过ZK进行调度

1、用户访问Web管理页面(Admin Service服务) 修改配置2、Admin Service renew通知ZK(即创建一个文件)3、Config Service监听ZK（即监听这个文件）4、Config Service获取最新配置缓存到本地5、Config Service通知Client 让它获取最新的配置6、Client从ConfigService获取最新配置

实际部署会将Config Service、Eureka、Meta Server放在同一个JVM进程中

JVM进程 无状态 冗余部署很多份

一个机房部署一个JVM进程；不同机房连接同一个数据库

为什么选择Eureka

阿波罗客户端实现原理

伪长连接

不同场景的可用性

自研配置中心思路

• 需求
  

APP粒度即项目粒度

• 参考架构
  

用Redis的服务发布订阅也可以

小提示

1、阿波罗不支持加密可以通过配置中心对配置加密在客户端解密的方式实现2、心跳实现方式：tcp长连接、ping、发包

消息队列

定义

应用场景

消息队列模型

• 订阅主题
  

一对多

• P2P
  

一对一

消息队列组成

1、Producer:MQ ClientConsumer:MQ ClientBroker: MQ Server

2、所有的mq支持的通讯协议都是tcp

传统协议(基本不会用)

1、开源的IM都是基于XMPP协议本质基于XMIO协议 比较大 基本上不太会用

2、自定义协议比如二进制私有协议qq微信都是基于二进制协议（高效、基于tcp socket传输）

消息队列设计考虑点

高级特性设计

1、大部分mq发送方不需要去重2、kafka 分布式事务中会保证去重3、rocketmq、rabitmq 只保证至少发一次4、a、主动去拉: 轮询(Long Polling) 基本所有mq都是这种方式   b、长连接: mq server主动推

开源MQ技术选型

• RabbitMQ
  

• ZeroMQ、ActiveMQ
  

rabbitmq 用的不多zero mq 业界用的也不多

• Redis、Kafka
  

redis 数据量大的时候入队列很慢kafka 高可靠 偶尔丢1、2条没关系 比如日志

• RocketMQ
  

1、原生版本对时序消息的高可用保证不好 一旦其中一台挂了 就不可用了2、基于开源做高可用方案3、在rocketmq中堆积上亿消息没有任何压力

• NSQ
  

不支持有序消息

• beanstalked
  

不足以称为工业级产品 因为有单点故障优势是支持任意时刻延迟消息

RocketMQ架构

1、broker就是server端2、一组broker中有主从节点3、NameNode根据topic名字拿到消费者列表 让消费者监听消费 4、消费者监听的是Master Broker

开源版本仅支持主从模式 不能主从切换

1、一旦主broker挂了 从broker并不会提升为主;主挂了 就没有办法消费了2、slave仅仅做backup 消费方也是从主上消费数据3、对于任何一个topic至少有2个broker

对非时序消息

对消息的写入顺序没有要求的

1、broker1所在服务器是ip1,borker2所在服务器是ip2，ip1和ip2都注册到注册中心2、客户端通过注册中心选择borker1进行写入消息 通过Master Broker写入 比如里面有1000条消息3、如果broker1中的Master Broker挂掉了4、客户端只消费了900条消息 还剩100条没有消费5、注册中心将broker2作为写入节点 在broker2中的Master Broker中继续写1001...6、等broker1中的Master Broker重启了之后 客户端再消费剩下的100条数据

存储模型

1、消息队列服务存的是每个消息对应的偏移量和大小

2、commitlog是磁盘文件

3、类似于commitlog的index（包含offerset）

4、读取队列 拿到索引 通过索引到commitlog找到消息

5、写commitlog完全是顺序写

通过MMap内存映射实现CommitLog和消息队列Consume Queue完全一致

MMap:一块硬盘 完全映射到内存中 写内存即是写磁盘

刷盘策略

• 异步刷盘
  

机器重启 消息可能会丢失

• 同步刷盘
  

防止数据丢失 性能会受影响磁盘SSD 性能还可以的

严格时序消息如何保证高可用

单机单线程 Master-Slave模式 如果Master挂了 会发送失败，同时也不能消费

RocketMQ自身高可用方案

自研方案

开源版本不支持主从切换，基于开源版本，如何让其支持高可用？

1、三个nameserver调用zk的create创建文件接口 谁创建成功谁就是主 将该文件放到主节点的namespace下面 2个从节点监听该文件2、broker监听zk就知道了哪个nameserver是主节点3、broker主从心跳上报给nameserver主节点4、nameserver主节点数据同步给其他2个从节点5、broker主从是在配置中配的6、broker主挂了broker和ns心跳就没了 就知道它挂了ns下发命令 将broker从变成主7、ns主将新的broker主同步给其他的ns从客户端就会获取到新的broker主客户端直接写到新的broker主8、如果ns主挂了它的ha是由zk保证9、3个ns 创建文件 其中一个创建成功另外2个从ns watch这个文件如果主挂了 文件也会消失另外2个从会再创建文件竞选主节点10、每一个ns 都会注册到zk上ns主从zk上获取还有几个从节点然后再定期推送给从节点11、ns主从是通过zk写文件方式实现broker主从通过ns主选择12、ns之间没有强一致性协议broker主从切换了之后 心跳给nsns主通知ns从 tcp接口通知可能会出现路由信息短暂不一致ns主同步其他2个从 最终一致性

RocketMQ物理部署

很多rocketmq集群共用一套nameserver

消息可靠性

1、发送失败 写错误日志 报警2、消费失败 可以基于某一个id进行回溯 因为消费offset保存在本地或保存到broker中3、rocketmq 用的是netty nio模式4、rocketmq是long pulling拉模式做的5、topic 模式 下游全量消费队列模式 下游是随机的 连上来消费一个 6、如果主从网络挂了刷盘策略 可以同步或异步异步也没关系 网络挂了 从同步数据有延迟若开启同步强一致性主刷到盘上 再同步到从上7、一主一从tps可达到上万8、客户端消费 不需要关注负载均衡客户端只要去连server ，server就会顺序分发9、topic下面有group群组概念一个topic允许多个服务监听比如a服务有5个节点 能保证a服务的其中一个节点能消费到

分布式请求跟踪系统

微服务现状

微服务请求调用路径

解决方法

开源产品

1、cat更多是监控 不能算分布式请求跟踪系统2、SkyWalking（APM） 应用程序管理 不仅仅是分布式请求跟踪系统3、pinpoint 是韩国搜索门户开源

设计需求

1、通过javaagent拦截器start(事前拦截器) end(事后拦截器)方法(AOP)收集metrics 对业务无感知

2、日志生成好之后 放在hadoop中 再进行并行的海量日志的分析

3、每次请求都生成全局唯一的 请求层次和深度

设计目标

使用场景

调用链跟踪

• 一次调用耗时
  

• 多次调用链路分析
  

• 日/月维度统计分析
  

调用链路分析

在回归测试的时候不需要测试全部链路 只需要测它依赖链路就好了

调用来源分析

调用链路统计

监控请求调用量

可以通过正则表达式来指定要监控的接口路径

架构设计

1、应用节点要引入jar包进行收集对应用程序本身极小侵入为好2、metrics 本地socket即UDP进行通讯3、trace日志收集agent实际上是一个golang程序4、先收集到本地 1分钟再发往集群减少应用程序节点和集群节点之间通讯次数5、trace服务器只需要对数据流做格式化处理分三个工作流进行处理（汇总、重组调用链、es实时请求耗时（不需要分析））6、hadoop通过mapreduce进行日志分析7、页面数据分析 一天总体耗时 通过离线方式计算出来8、trace数据实时分析 spark streaming、flink（推荐）来做的

最关键id如何生成

1、请求链唯一标识 (TraceID)2、时序标识（SequenceID）3、深度标识(DepthID)

1、进程内传递 在request请求包中

2、定长header + 变长body请求的唯一标示放在定长header中

2、时序id只和当前节点有关系和其他节点没有关系 可以放在本地threadlocal中

ID体系设计

在网关调用的时候 时序id记录在threadlocal中深度id会继承上面一个继续往下调用点的个数其实就是深度比如第一开始调用是0.1 接着是0.1.1 首先是继承上层的0.1然后加.时序从1开始

技术选型

链路采集一定会有丢失 UDP协议传输对数据可靠性要求不高