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

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，然后写到日志中，放到消息系统中。记录哪次调用，花的时间，数据的大小，在哪台机器执行。以进行跨系统、跨应用的分析，可以通过一个连接，看后台如何处理，哪个环节出了问题。