京东通天塔——京东中间件如何支撑起每一场大促

   <p>每次大促都是考验各电商架构的最好时机，然而一般电商大促时，我们可能更关注系统架构如何降级如何限流等经典手段。这次换个视角，中间件在《京东技术解密》一书中被京东喻为大促通天塔，而京东作为中国互联网电商主角之一，我们看看中间件技术如何撑起京东每一场大促的。</p>    <p><strong>InfoQ：您拥有18年的研发经验，能否介绍这段时间自己的程序员经历？是否面临过几次关键选择？</strong></p>    <p>何小锋：18年，一直没有脱离Coding，积累了很多的系统架构经验，在2011年加入京东，被京东面临的技术挑战所吸引。整个coding生涯中有过2次关键选择：</p>    <ol>     <li> <p>从传统的电子政务行业转到互联网行业；</p> </li>     <li> <p>选择了京东，给自己一个挑战发挥的平台。</p> </li>    </ol>    <p>由于自己很喜欢技术，而且喜欢中间件、高并发分布式和弹性计算这三大领域本身带来的技术挑战，目前这些技术已经是公司的核心支撑系统，是京东抗大流量的关键。</p>    <p>另外这几大领域需要掌握软件、操作系统、硬件和网络等多方面的知识才能更上一层楼，并且有很多需要专研的地方，需要长时间的专注才能做好。</p>    <p><strong>InfoQ：中间件技术部门承担了怎样的任务和职责？落地基于Docker的弹性云给部门带来怎样的影响？</strong></p>    <p>何小锋：中间件技术部门承担中间件研发和运维支持工作，确保现有系统稳定，持续优化满足业务需求，跟进业界技术发展，孵化新的中间件产品解决业务问题。</p>    <p>目前京东中间件最核心的3大产品如下：</p>    <ol>     <li> <p>JSF，自主研发高性能分布式的RPC微服务框架，是京东服务化、开放化的技术标准；</p> </li>     <li> <p>JIMDB，自主研发高性能分布式的缓存，基于Docker架构，具有弹性伸缩、快速故障迁移等能力；</p> </li>     <li> <p>JMQ，自主研发的高性能分布式的消息队列</p> </li>    </ol>    <p>弹性云落地对中间件研发架构有很大的促进，JIMDB基于Docker实现弹性伸缩能力。另外中间件还要适应容器的环境，如准确获取CPU数量便于控制线程数，避免频繁的线程切换。流量均匀也是后续要改善的方向，容器的规格小，前后申请不一致，物理机硬件配置不一样，造成每个实例的承载能力不一样，需要中间件能自动负载均匀。</p>    <p><strong>InfoQ：目前京东微服务框架JSF调用规模在日常和大促时分别处于什么量级，JSF的主要核心部件如何实现高可用？</strong></p>    <p>何小锋：JSF日常调用在千亿规模，大促期间会翻2-5倍。</p>    <p><img src="https://simg.open-open.com/show/ad2b866f61f0228e3e6ac255f39579d4.png"></p>    <p>实现高可用方面，以注册中心为例，注册中心以异步持久化到数据库中，通过本地全量缓存来提升性能，节点直接通过事件总线同步，可以做到横向扩容。如果数据库宕机，可以通过缓存继续提供读取服务。</p>    <p>另外每个机房都会部署若干节点，客户端通过目录服务优先拿到本机房的注册中心节点列表，后续通过定时更新注册中心列表。</p>    <p>当服务有变化的时候，注册中心回调客户端，推送变化给客户端，客户端会在内存中缓存一份服务地址，在本地会存储一些备份文件。如果注册中心连接不上，客户端可以依赖本地缓存继续调用。</p>    <p>监控中心提供的是JSF服务，数据直接通过ES存储。</p>    <p>实现高可用过程中为了 <strong>深挖单实例性能</strong> ，我们做了优化序列化协议，传输数据进行压缩，并且通过RingBuffer进行组提交，采用NIO/EPOLL，优化线程模型，提升并发能力。</p>    <p><strong>InfoQ：JSF目前是否还存在瓶颈？</strong></p>    <p>何小锋：JSF到目前已经很成熟，性能、稳定性和易用性都很高。</p>    <p>JSF提供了强大的服务治理功能，包括常见的分组、上下线、黑白名单、路由等，也做到了例如动态分组、同机房优先、配置下发、调用限流、授权调用等等功能，并且开放了部分服务治理API，供开发者自行调用。</p>    <p>JSF未来会持续在治理和监控上进行改进，完善分布式跟踪，便于快速定位问题。另外HTTP网关会通过支持HTTP/2协议来优化性能。</p>    <p><strong>InfoQ：目前京东消息中间件从开源软件的JQ、ActiveMQ发展到自研的JMQ，能否简述这段演进过程？基于怎样的判断和背景会开始对下一代的筹备？</strong></p>    <p>何小锋：JQ严格意义上来说还算不上一个消息中间件，它基于数据库实现，当时的用户也比较少。</p>    <p>随着公司SOA化工作开展，迫切需要成熟的高可用消息中间件来支持，我们采用开源的ActiveMQ来作为第一代分布式消息平台。在其基础上做了一系列的平台化改造，包括应用治理、监控报警、分布式客户端、归档、重试、存储复制，我们对这些功能也进行了优化和更新。</p>    <p>随着业务量的快速增长，它的性能成了很大的瓶颈，存储逻辑复杂，消息积压后对性能影响很大，已经很难进行优化。通过积累的研发和运营经验，我们决定自助研发JMQ。 JMQ在存储、网络通信、消息处理、数据复制等方面进行了很大的优化改进 。另外在升级的过程中，考虑了兼容性，例如JMQ兼容AMQ客户端协议，做到了平滑过渡。</p>    <p>为什么没有一步到位？每一代消息中间件都是基于业务的发展需要的，京东这些年发展之快，业务又有其不确定性，所以我们在这过程中也是不断的探索，不断的重构。</p>    <p>至于何时开始下一代消息中间件的筹备，我们会主要基于高可用、性能和自动化运维瓶颈等方面考量。JMQ我们目前正在做 <strong>兼容Kafka协议</strong> ，大幅提升自动化运维能力，减少备战工作。</p>    <p><strong>InfoQ：以您的判断来看，互联网企业是否会逐渐摆脱开源软件的依赖，走向自主研发以获得彻底的掌控力？</strong></p>    <p>何小锋：这个是根据业务发展的需要的，成熟稳定的开源系统还会持续支撑，满足不了需求的开源软件会逐步被自研替换。我的建议是控制好收益，加强内外交流，最后要回馈开源社区。</p>    <p><strong>InfoQ：JMQ在大促时能处理多少的写入、投递高峰？后端消费不稳定的情况下如何保证消息投放稳定？</strong></p>    <p>何小锋：JMQ在大促时单个分片同步复制和刷到磁盘，能达到写入1K消息，TPS可以超过4万每秒。针对日志等场景，通过 <strong>配置异步复制和刷盘</strong> 还可以大幅度提升性能。我们预计整个平台，双11当天消息投递量会达到千亿规模。</p>    <p>消费者采用拉模型，处理速度完全由消费者控制，如果处理速度慢，消息会保留在服务端，保留时间为2天。由于大促的需要，每个系统都会进行大流量压测军演，不会存在2天都消费不了的消息。</p>    <p>JMQ的存储模型，消息积压在服务端，对写入和消费性能没有影响。积压了会给用户进行报警，如果存储空间不够了，会停用当前实例的写入，进行扩容。</p>    <p><strong>InfoQ：能否谈谈在大促期间中间件团队所做的工作？在接下来的大促会做哪些准备和调整？以前的大促遇到过哪些问题以及应对方案？</strong></p>    <p>何小锋：中间件会成立专门的项目来推荐大促的备战工作，主要包括如下几块工作</p>    <ol>     <li> <p>系统梳理工作：整理现有部署架构，核心客户，每日巡检；</p> </li>     <li> <p>部署扩容：资源评估、核心客户扩容、容灾部署；</p> </li>     <li> <p>应急预案：整理和评估应急预案；</p> </li>     <li> <p>压测演练：模拟故障演练，性能压测；</p> </li>     <li> <p>对发现的问题就改进优化；</p> </li>     <li> <p>24小时值班监控</p> </li>    </ol>    <p>每次大促发现的问题都会作为后续研发改进的需求，例如AMQ性能不好，后续自研JMQ。</p>    <p>面对以后的大促，我们会大幅提升自动化运维来满足大促的需求，包括弹性扩容，更丰富的监控报警，更迅速可控的故障切换、自动化容灾、核心客户物理隔离等等。</p>    <p>另外随着业务的发展，如何更好地支持业务海量数据缓存需求，我们也在规划新版的JIMDB。</p>    <p><strong>InfoQ：能否简单概述自动扩容缩容中数据迁移的技术原理？中间件实现快速故障切换和弹性伸缩能力的难点在哪里，最后如何解决的？</strong></p>    <p>何小锋：JIMDB提供 <strong>基于Docker的弹性伸缩能力</strong> 。目前JIMDB一个分片有2G内存数据，当需要迁移时，节点会先把已有的数据按照一定的规则全量复制一份到新的shard上，在全量复制过程中会有增量的数据产生，这部分数据另外保存一份到指定的缓冲区中，当全量复制完成后马上同步缓冲区中的数据，当缓存区中需要同步的数据比较少时，会阻塞待分裂节点的写入直到增量数据也同步完成。</p>    <p>快速故障切换和弹性伸缩能力的难点主要如下：</p>    <p>1.准确及时的故障定位，包括软件宕机、网络、硬件等方面的故障。我们通过Agent秒级采集监控数据，对新出现的故障通过录入关键词来自动学习，宕机/网络不通则 <strong>采用多个决策者投票</strong> 决定。</p>    <p>2.资源的合理调度，包括容灾，确保资源调度均匀、并发控制，核心业务做到隔离，相关的具体实践有：</p>    <ul>     <li> <p>应用接入的时候要完善信息，能识别是否是核心业务，是否需要隔离，业务的吞吐量需求等等;</p> </li>     <li> <p>通过资源标签来匹配满足业务的资源;</p> </li>     <li> <p>通过识别机房、机架信息来满足容灾的需求;</p> </li>     <li> <p>通过资源乐观锁来实现对相同资源的并发控制;</p> </li>    </ul>    <p> </p>    <p> </p>    <p>来自：http://www.infoq.com/cn/news/2016/11/Jingdong-middleware-support-prom</p>    <p> </p>