从零到卓越:京东客服即时通讯系统技术架构的演进
从零到卓越:京东客服即时通讯系统技术架构的演进
京东的客服即时通讯系统叫东东是的。东东对京东就像旺旺对淘宝一样。它们服务于买方和卖方之间的交流。自从京东开始为第三方卖家提供平台服务，董东就诞生了。让我们先看看它诞生之初是什么样子。
版本1.0:出生(时间:2010-2011)
为了快速启动业务，1.0版技术架构的实现非常直接、简单和粗鲁。如何变得简单和粗鲁？请参见如下架构图:
从零到卓越:京东客服即时通讯系统技术架构的演进
1.0的功能非常简单，它实现了即时消息的基本功能，例如访问和交换消息和状态。此外，还有一个客户服务功能，即客户访问咨询时的客户服务分配，通过轮询将客户分配到在线客户服务接收。利用开源的Mina框架实现了TCP的长连接访问，利用Tomcat Comet机制实现了HTTP的长轮询服务。消息传递的实现是一种生产和消费模式，其中一端发送的消息暂时存储在Redis中，由另一端提取。
该模型的实践导致需要以高频率的方式轮询Redis，以遍历属于其自身连接的相关对话消息。这个模型非常简单，它包含许多含义:简单易懂；它易于开发；它也易于部署。只有一个Tomcat应用程序依赖于一个共享的Redis，它可以简单地实现核心业务功能并支持业务快速上线。
然而，这种简单的模型也有一些严重的缺陷，主要是效率和扩展性问题。轮询的频率间隔基本上决定了消息延迟。轮询越快，延迟越小，但是轮询越快，消耗越大。该模型实际上是一个高功耗、低效率的模型，因为非活动连接会以高频率进行无意义的轮询。频率有多高，基本上在100毫秒以内。你不能让轮询太慢。例如，每2秒钟一次，人们在聊天时会感觉到明显的谈话延迟。随着在线人数的增加，轮询时间也呈线性增加，因此该模型的可扩展性和承载能力较差，并且随着在线人数的增加，一定会遇到性能瓶颈。
1.0是京东科技平台转型的时代。NET到Java。正是在此期间，我加入了京东，并参与了京东主站技术改造架构的升级过程。此后，他开始接手京东东东，并不断改进该产品，进行了三次技术架构演进。
版本2.0:成长阶段(时间:2012)
当我们第一次接手时，1.0正在网上运行，支持京东流行(开放平台)业务。之后，京东计划成立一个自主经营的在线客服团队，并登陆成都。当时自营和POP客户服务咨询服务都刚刚起步，1.0架构的性能和效率缺陷没有达到爆炸性的业务量水平。当时，自营客户服务尚处于起步阶段，客户数量不足，服务能力不足，客户咨询量远远超过客户服务的服务能力。对于超出服务能力的客户咨询，我们的系统会返回一个统一的提示，提示客户服务忙，请稍后咨询。这种情况导致大量客户处于高峰期，无论如何刷新他们的请求，他们都可能无法获得客户服务，而且他们的体验非常差。因此，2.0侧重于业务功能体验的改善，如下图所示。
从零到卓越:京东客服即时通讯系统技术架构的演进
无法及时提供服务的客户可以排队或留言。对于纯文本交流，它提供了更丰富的表达方式，如文档和图片。此外，它还支持客户服务转移和快速回复，以提高客户服务的接收效率。总之，整个2.0关注于提高客户服务效率和用户体验。但是，我们担心的效率问题并没有在2.0的高速业务发展时期出现，而是业务量在逐渐积累，我们知道它即将爆发。到2012年底，双十一之后开始了3.0的主要架构升级。
版本3.0:爆发阶段(时间:2013-2014)
事实上，在2.0时代经历了整整一年的高速业务发展后，代码规模迅速扩大。随着代码的扩展，有了团队，从最初的4人到近30人。经过一个大团队，一个系统是由许多人开发的，开发人员层次不同，标准化难度大，系统模块耦合性强，变化多，沟通依赖多，在线风险控制难度大。一个单一的tomcat应用程序多实例部署模型终于结束了，这个版本的架构升级的主题是服务。
服务的第一个问题是如何将一个大的应用系统分成子服务系统。当时的背景是京东的部署仍处于半自动时代，自动部署系统刚刚起步。如果将子服务系统划分为太多的业务，部署工作量将会很大并且难以管理。因此，当时我们没有按照业务功能划分服务，而是按照业务重要程度划分了不同级别的子业务服务系统0、1、2。此外，为具有不同信道和通信方式的接入终端提供一组独立的接入服务，如下图所示。
从零到卓越:京东客服即时通讯系统技术架构的演进
有关更详细的应用程序服务和体系结构分层，请参见下图。
从零到卓越:京东客服即时通讯系统技术架构的演进
此次大规模架构升级主要考虑三个方面:稳定性、效率和容量。做了以下事情:
业务分类、核心和非核心业务隔离
多机房部署、流量分流、容灾冗余和峰值响应冗余
多源读取，故障时自动传输
将库作为主备，在短期有损服务的容忍下快速切换
外部接口、故障转移或快速开路
Redis主/备用，故障转移
大型表迁移，MongoDB取代MySQL来存储消息记录
改进消息传递模型
考虑到系统的稳定性和可用性，前六项基本上属于改进和升级。该块一个接一个地迭代完成，并且承载大量故障转移的配置和控制功能由上图中的管理和控制中心提供。第7条主要是关于使用MongoDB来分离存储容量最大的聊天记录，这是随着业务量的增加和一天内消息数量的增加而实现的。
第8条旨在改善1.0版消息的低轮询效率。下图显示了改进的交付方法:
从零到卓越:京东客服即时通讯系统技术架构的演进
不进行轮询，而是让终端在每次建立连接时注册接入点的位置，并在消息传递之前定位该连接所在的接入点的位置，然后将它推过去。这样，传送效率是恒定的，并且易于扩展。在线人数越多，连接就越多，只有接入点需要扩展。事实上，在这个模型中仍然存在一些小问题，主要是在离线消息的处理上。我们可以先考虑一下，然后再讨论。
3.0经过两年的迭代升级，它可以继续支持业务量的长期增长。但事实上，到2014年底，我们不再面临业务量的问题，而是业务模式的变化。这直接导致了新时代的到来。
版本4.0:涅盘(时间:2015年至今)
2014年，JD.com的组织结构发生了巨大变化，从一家公司变成了一个拥有多个子公司的集团。原商城已成为子公司之一，新成立的子公司包括京东金融、京东智能、京东家园、排牌、海外业务部等。他们有不同的业务范围和业务模式，但无论什么业务，他们总是需要客户服务。如何重用为商城量身定制的客户服务系统，支持其他子公司业务的快速接入，已经成为我们的新课题。
派派。这是一个完全不同的账户和订单交易系统。由于时间限制，我们剥离了为商城制作的部分，基于3.0架构单独制作了一套对接pat，并独立部署，如下图所示。
从零到卓越:京东客服即时通讯系统技术架构的演进
尽管发布在业务所需的时间之前完成，但它也带来了明显的问题:
复制工程、定制业务开发和多组源代码的高维护成本
独立部署，至少有两个房主配备了灰色集群，浪费资源
过去，我们都是面向业务的去架构系统。现在，在新的业务变化情况下，我们开始考虑面向平台的架构设计，在统一的平台上运行多组服务，统一源代码，统一部署和统一维护。继续拆分业务服务，剥离最基本的即时通讯服务、即时通讯综合服务和客户服务综合服务，针对不同业务的特殊需求进行最小化定制服务开发。部署模式是平台的形式。不同业务方的服务运行在同一个平台上，但是数据是相互隔离的。服务继续被分成更细的服务，形成一组服务矩阵(见下图)。
从零到卓越:京东客服即时通讯系统技术架构的演进
在部署模式下，双机房只需要建立两组对等集群，可以建立一个较小的灰度分布集群。所有不同的服务都在统一平台集群上运行，如下图所示。
从零到卓越:京东客服即时通讯系统技术架构的演进
更细粒度的服务意味着每个服务更容易开发，代码更少，依赖性更小，隔离稳定性更高。然而，更细粒度的服务也意味着更麻烦的操作和维护监控管理。直到今年，公司的灵活私有云、缓存云、消息队列、部署、监控和登录等基础系统越来越完善，这使得实施这种细粒度的微服务架构成为可能，运营和维护成本也可以得到控制。从最初的1.0应用程序流程，到3.0 6、7个应用程序流程，再到4.0 50多个粒度更细的不同应用程序流程。根据不同的承载流量，为每种进程分配不同的实例数，实际实例数将超过千。为了更好地监控和管理这些过程，专门为此定制了一个面向服务的操作和维护管理系统，如下图所示。
从零到卓越:京东客服即时通讯系统技术架构的演进
统一的服务操作和维护提供了实用的内部工具和库来帮助开发更健壮的微服务。包括中央配置管理、流量隐藏点监控、数据库和缓存访问以及运行时隔离。
下图显示了运行隔离图:
从零到卓越:京东客服即时通讯系统技术架构的演进
细粒度的微服务被隔离在进程之间，严格的开发规范和工具库有助于实现异步消息和异步HTTP，以避免跨进程的多个长同步调用链。服务增强容器装甲被引入到进程中以隔离线程，并支持进程中各个服务的降级以及同步到异步的执行。所有这些工具和图书馆服务有两个目的:
使服务流程运行时状态可见
让服务流程的运行状态得到管理和改变
最后，我们回到上一篇文章留下的悬念，那就是消息传递模型的缺陷。首先，在我们检测到终端连接在接入层断开后，消息不能被传递，然后消息被缓存，然后在终端重新连接后，离线消息被提取。这种模式在移动时代表现不佳，因为移动网络的不稳定性，它经常断开链路并重新连接。然而，网络断开的准确检测依赖于网络超时，这导致不准确的检测和错误的消息传递。新模型如下图所示，不再依赖于准确的网络连接检测。在传递之前，要确认的消息id被缓存，而消息正文被持久存储。在终端收到确认并返回之前，消息不会被传递，并且在重新登录或重新连接之后，未确认的消息id将作为离线消息被推送。该模型不会产生虚假消息传递造成的损失，但可能导致消息重复，只需要客户端根据消息id进行复制。
从零到卓越:京东客服即时通讯系统技术架构的演进
结论
在JD.com诞生之初，正是JD.com技术转化为Java的时候。经过多年的发展，已经取得了很大的进步。从基层到专业，从薄弱到规模，从分散到统一，从无序到标准化。本文主要关注近年来鼓乐建筑的演变过程。我不认为仅仅在技术架构中有任何绝对的好或坏。技术架构应该始终放在那个时代的背景下来看待，并且应该考虑业务的时效性价值、团队的规模和能力、环境基础设施等等。只有当架构演化的生命周期与业务的生命周期及时匹配时，才能达到最佳效果。
----------------------------------------------------------------------------------
哇谷im_im即时通讯_私有云_公有云-哇谷云科技官网-JM沟通
IM下载体验 - 哇谷IM-企业云办公IM即时聊天社交系统-JM 沟通下载
IM功能与价格 - 哇谷IM-提供即时通讯IM开发-APP搭建私有化-公有云-私有化云-海外云搭建
新闻动态 - 哇谷IM-即时通讯热门动态博客聊天JM沟通APP
关于哇谷-哇谷IM-提供企业即时通讯IM开发-语音通话-APP搭建私有化-公有云-私有化云-海外云搭建
联系我们 - 哇谷IM-即时通讯IM私有化搭建提供接口与SDK及哇谷云服务
公有云和私有云之间有什么区别？类似融云、环信云、网易云、哇谷云？