从分散到统一，京东从分散到统一，京东IM工具工具“咚咚咚咚”的架构演进的架构演进
咚咚是什么？咚咚之于京东相当于旺旺之于淘宝，它们都是服务于买家和卖家的沟通工具.自从京东开始为第三方卖家提供入
驻平台服务后，咚咚也就随之诞生了。我们首先看看它诞生之初是什么样的。
1.0 诞生（2010 - 2011）
为了业务的快速上线，1.0 版本的技术架构实现是非常直接且简单粗暴的。 如何简单粗暴法？请看架构图，如下。
图 1 - 1.0 功能模块交互图
1.0 的功能十分简单，实现了一个 IM 的基本功能，接入、互通消息和状态。 另外还有客服功能，就是顾客接入咨询时的客服
分配，按轮询方式把顾客分配给在线的客服接待。 用开源 Mina 框架实现了 TCP 的长连接接入，用 Tomcat Comet 机制实现
了 HTTP 的长轮询服务。 而消息投递的实现是一端发送的消息临时存放在 Redis 中，另一端拉取的生产消费模型。
这个模型的做法导致需要以一种高频率的方式来轮询 Redis 遍历属于自己连接的关联会话消息。 这个模型很简单，简单包括
多个层面的意思：理解起来简单；开发起来简单；部署起来也简单。 只需要一个 Tomcat 应用依赖一个共享的 Redis，简单的
实现核心业务功能，并支持业务快速上线。
但这个简单的模型也有些严重的缺陷，主要是效率和扩展问题。 轮询的频率间隔大小基本决定了消息的延时，轮询越快延时
越低，但轮询越快消耗也越高。 这个模型实际上是一个高功耗低效能的模型，因为不活跃的连接在那做高频率的无意义轮
询。 高频有多高呢，基本在 100 ms 以内，你不能让轮询太慢，比如超过 2 秒轮一次，人就会在聊天过程中感受到明显的会
话延迟。 随着在线人数增加，轮询的耗时也线性增长，因此这个模型导致了扩展能力和承载能力都不好，一定会随着在线人
数的增长碰到性能瓶颈。
咚咚1.0 的时代背景正是京东技术平台从 .NET 向 Java 转型的年代，我也正是在这期间加入京东并参与了京东主站技术转型
架构升级的过程。 之后开始接手了京东咚咚，并持续完善这个产品，进行了三次技术架构演进。
2.0 成长（2012）
我们刚接手时 1.0 已在线上运行并支持京东 POP（开放平台）业务，之后京东打算组建自营在线客服团队并落地在成都。 不
管是自营还是 POP 客服咨询业务当时都起步不久，1.0 架构中的性能和效率缺陷问题还没有达到引爆的业务量级。 而自营客
服当时还处于起步阶段，客服人数不足，服务能力不够，顾客咨询量远远超过客服的服务能力。 对于超出服务能力的顾客咨
询，当时我们的系统统一返回提示客服繁忙，请稍后咨询。 这种状况导致高峰期大量顾客无论怎么刷新请求，都很可能无法
接入客服，体验很差。 所以 2.0 重点放在了业务功能体验的提升上，如下图所示。
剩余7页未读，继续阅读
资源评论
