当前位置: 首页 > >

京东核心中间件如何支撑业务快速发展---笔记

发布时间:



JSF ?分布式RPC微服务框架,服务化的标准使用jsf做的,有 14000接口,接口文件统计的,接入的应用实例有11万,调用达到3000亿






架构

服务提供方,先注册中心进行注册。怎么知道注册中心?有目录服务,index服务,它查找最*的注册中心,把注册中心同步上去。注册中心之间的注册信息会同步。消费者先注册index服务,index服务拿到注册中心,然后连上,取到服务体系的地址。将埋点数据发送监控服务,监控服务将所有数据存储在es中。最外端提供了http网关,注册信息、元数据、配置数据的数据持久化到mysql中。另外,还提供了web console





分布式缓存JIMDB ,自主研发高性能分布式缓存*台。基于docker,有弹性伸缩的能力,能快速的进行故障切换,自动化运维的程度也非常高。

实例数10万+,内存量260T+,双11凌晨,每秒ops峰值达到5亿


应用场景:对性能要求很高的场景,如秒杀、搜索推荐等面向用户的。



架构:

数据是进行分片的,集群中有很多分片,每个分片有主从 ?。有一主一从,也有一主多从。

拿到集群信息方法:通过配置中心取到集群的地址,然后访问集群。集群可以自动化运维,恢复集群故障、弹性收缩、数据采集应用。集群检测到故障,就触发failover,开始恢复集群。集群可以自动进行采集指标的报警。目前整个部署在docker上的,可以做到秒级的弹性收缩





消息中间件jmq,分布式消息队列

主要目的:系统解耦,异步化操作。接入量很大,包括订单,下单,支付,订单生产和配送。等2500+个应用。双11的吞吐量达750亿,队列数量有9000.






架构:

最基本的是Docker服务,分片的,主从模式。前面也是通过SDK,来进行访问,有生产者和消费者。首先通过NameServer拿到集群地址。SDK,负责负载均衡、故障切换,控制权重,权重是NameServer告诉他的。每个实例上部署一个agent,agent定时将指标数据上传到采集器中。采集器首先发给Mq.为什么不能直接发到mq?mq的协议比较重,我们使用比较轻的协议,发送给采集器。Mq,进行实时计算,汇总指标。一个集群不仅关注一个实例的指标,也关注整个集群的指标。如果集群的性能指标比较低,则需要扩容。如果一个实例吞吐量比较低,可能机器故障了。做实时计算,将结果回传给Mq,进行报警。集群吞吐量比较低,触发分布式任务,目标实现自动化运维。集群创建扩容、缩容。如果集群出现问题,则可以快速触发任务,进行自动化运维操作。

消息类审计:

将历史数据归档,放入jss文件系统中,然后mq的记录信息放入hbase中进行检索。用户可以通过关键业务,如订单号,可以在hbase里面可以查到原始消息,如谁收到,什么时候发送的。如果数据有问题,可以通过归档数据恢复到消息队列中。

Rebalance, 实现均等数据。docker弹性计算,实例会很多,连接数据就会很多,一个实例可能支持很多应用。如何保证应用连接分在不同实例上,并保证应用就*机房访问?rebanlance根据应用连接情况进行优化,如果发现某个实例性能低、比较慢或某个实例连接数多了,通过rebanlance告诉客户端不要去连该实例了。










Redis 分布式,其注册配置,通过zk下发的。SDK实现负载均衡、failover,都是点对点的长连接,提高性能;redis提供一致性hash算法。





大促过程中,流量抗不住了。

B-Tree,消息积压时性能会低,

兼容JMS1.1规范,每个实例topic,一个应用多个实例消费,只要每个实例消费都会发送一份topic.





实例多了就降低Io性能

性能优化:

网络传输高效些,减少些数据量,优化协议,消息大部分是文本消息,进行文本压缩,批量传输,来减少网络流量。异步处理,以减少吞吐量。

存储模型:顺序追加,组提交技术,减少拷贝。一个定量消息,几十个消费者,写入时,只有一份消息数据,其他的只是记录消费的位置,而不是重新拷贝数据,可以减少IO的操作。做内存的映像文件,包括减少内存的数据拷贝








日志文件优化:


不管实例有多少消息队列,消息都是顺序追加到文件中,文件到一定长度进行切分,不是每个队列一个数组文件,减少刷盘的次数,减少IO数 ? ??




消息队列,先存在内存中,记录每个消费者他所对应的队列在日志文件的索引位置,文件大了,就切分,加到内存中。消费者来了,从队列中取,队列中全记录的是位置。消费的位置,记录消费到哪个位置。当下次断了,重新连上,会从原来的位置继续消费。减少了Io的存储,因为顺序文件的追加,性能比较高





我们对消息的id做了一些处理,id能知道在哪个文件的某个偏移量,能快速的读出消息









如何确保消息不丢:mq是应答模式,收到的消息是docker宕机了。恢复:强制刷盘,同步的复制到其他的slave上,确保数据不丢失。通过ACK机制,确保至少投递一次









新*姹竟泊妫×孔黾嫒

如何做兼容?

客户端做的很轻量级,只负责failover/load banlance和权重,很多参数通过服务端传递,减少*簟⑿薷


Mq消息来了,使用原始mq协议解析,进行转换成标准的协议,转换成active应答,再发送出去。



如何跟踪应用问题:


在核心应用中采集数据,如SDK,RPC,MQ,然后写到日志中,放到消息系统中。记录哪次调用,花的时间,数据的大小,在哪台机器执行。以进行跨系统、跨应用的分析,可以通过一个连接,看后台如何处理,哪个环节出了问题。







友情链接: