探究京东咚咚架构演进史

什么是咚咚？咚咚之于京东，相当于旺旺之于淘宝，它们都服务于买卖双方的沟通。自从JD.COM开始为第三方卖家提供入驻平台服务以来，咚咚诞生了。我们先来看看它诞生之初是什么样子的。1.0诞生(2010-2011)为了快速推出业务，1.0版的技术架构非常直接、简单、粗糙。怎样简单粗暴的方法？请参见架构图，如下。1.0的功能非常简单，实现了IM的基本功能，访问、交换信息和状态。此外，还具有客户服务功能，即客户接入咨询时的客户服务分配，并按轮询将客户分配给在线客户服务接待。TCP的长连接接入采用开源Mina框架实现，HTTTP的长轮查询服务采用TomcatComet机制实现。而信息投递的实现是一端发送的信息临时存储在Redis中，另一端拉出的生产消费模式。这个模型的做法导致需要以高频率的方式轮询Redis，传播自己连接的相关会话信息。这个模型很简单，包括多个层次的含义:理解简单；开发简单；部署也很简单。Tomcat应用程序只需要依靠共享的Redis，就可以简单地实现核心业务功能，并支持业务快速上线。但这种简单的模型也有一些严重的缺陷，主要是效率和扩展。轮询的频率间隔基本上决定了新闻的延迟。轮询越快，延迟越低，但轮询消耗越快。这个模型实际上是一个高功耗、低效率的模型，因为高频率的无意义轮询是不活跃连接的。高频率有多高，基本在100ms以内，你不能让轮询太慢，比如超过2秒轮，人们在聊天过程中会感到明显的会话延迟。随着在线人数的增加，轮询的耗时也线性增加，因此该模型导致扩展能力和承载能力差，随着在线人数的增加，肯定会遇到性能瓶颈。1.0的时代背景是京东技术平台从.在NET向Java转型的时代，我加入了JD.COM，参与了JD.COM主站技术转型架构的升级。之后开始接手JD.COM咚咚，不断完善产品，进行了三次技术架构演进。2.0增长(2012)我们刚接手的时候，1.0已经在网上运营，支持JD.COMPOP(开放平台)业务，然后JD.COM计划在成都成立自营的在线客服团队。无论是自营还是POP客服咨询业务，当时都起步不久，1.0架构中的性能和效率缺陷尚未达到引爆业务量级。自营客户服务仍处于起步阶段，客户服务人数不足，服务能力不足，客户咨询量远远超过客户服务能力。客户咨询超出服务能力，当时我们的系统返回提示客户服务忙，请稍后咨询。这种情况导致大量客户无论如何刷新要求，都很可能无法访问客户服务，体验很差。因此，2.0侧重于业务功能体验的提升，如下图所示。对于不能及时提供服务的客户，可以排队或留言。它为纯文本交流提供了更丰富的表达方式，如文件和图片。此外，还支持客户服务转移和快速回复，以提高客户服务的接待效率。总之，整个2.0是为了提高客户服务效率和用户体验。在2.0快速发展的业务时期，我们担心的效率问题还没有出现，但业务量正在逐渐积累，我们知道它即将爆炸。到2012年底，3.0的重大架构升级将在双十一之后开始。3.0爆发(2013-2014)经历了2.0时代全年业务的快速发展，实际上代码规模迅速扩大。从最初的四个人到近30个人，团队与代码一起膨胀。团队成长后，系统由多人开发，开发人员水平不同，规范难以统一，系统模块耦合重，沟通依赖多，在线风险难以控制。多实例部署模型的单独tomcat应用终于走到了尽头，这个版本架构升级的主题是服务。如何将大型应用系统分为子服务系统是服务化的第一个问题。当时的背景是京东的部署还处于半自动化时代，自动部署系统才刚刚起步。如果子服务系统按业务划分太详细，部署工作量大，难以管理。所以当时我们并没有按照业务功能划分服务，而是按照业务的重要性等级划分了0、1、不同层次的子业务服务系统有23个。此外，对于不同渠道和通信方式的接入端，还有一组独立的接入服务，如下图所示。下图显示了更详细的应用服务和架构分层方法。大型架构升级主要考虑三个方面：稳定性、效率和容量。做以下事情：业务分级、核心、非核心业务隔离多机房部署、流量分流、灾难冗余、高峰处理冗余读数库多源、失败自动转移图书馆主备、短期损坏服务容忍快速切换外部接口、失败转移或快速断路Redis主备、失败转移大表转移、MongoDB取代MySQL存储消息记录改进消息投递模型前6条基本上属于考虑系统稳定性和可用性的改进升级。这一块是连续迭代完成的，上图中由控制中心提供了许多失败转移的配置和控制功能。这一块是迭代完成的，上图中由控制中心提供了许多失败转移的配置和控制功能。第七条随着业务量的增加和单日消息量的增加，MongoDB被用来单独存储最大的聊天记录。第八条改进1.0版新闻轮询效率低。改进后的交付方式如下图所示:不再是轮询，而是让终端每次建立连接后注册接入点位置，然后在新闻交付前定位接入点位置，然后推送到过去。这种交付效率是恒定的，而且很容易扩展，在线人数越多，连接越多，只需要扩展接入点即可。其实这个模型还是有一些小问题的，主要是因为处理离线消息。我们可以先考虑一下，最后再谈。经过两年的迭代升级，3.0可以在业务量方面继续支撑长期增长。但事实上，到2014年底，我们不再面临业务量问题，而是业务模式的变化。这直接导致了一个新时代的到来。2014年，JD.COM的组织结构发生了很大的变化，从一家公司变成了一个集团，下设了多家子公司。原商场已成为其子公司之一，新成立的子公司包括京东金融、京东智能、京东家居、拍卖、海外事业部等。各自的业务范围不同，业务模式也不同，但无论什么业务总是需要客户服务。如何重用原来为商场量身定做的东东客服系统，支持其他子公司业务的快速接入，成为我们的新课题。第一个要求访问的是拍拍网，它是从腾讯收购的，所以它是一个完全不同的账户和订单交易系统。由于时间紧迫，我们剥离了商场定制的部分，并根据3.0架构单独定制了一套，并独立部署，如下所示。虽然在业务要求的时间点之前完成了在线，但这也带来了明显的问题：复制项目、定制业务开发、多源维护成本高独立部署，至少双机房配备加灰度集群，资源浪费我们面对业务架构系统，现在新的业务变化我们开始考虑平台架构，在统一的平台业务、统一的源代码、统一的部署、统一的维护。继续拆分业务服务，剥离最基本的IM服务、IM通用服务和客户服务通用服务，并根据不同业务的特殊需要进行定制服务开发。部署模式以平台的形式部署，不同业务方的服务在同一平台上运行，但数据相互隔离。更微粒化的服务继续被拆分，形成了一组服务矩阵(见下图)。在部署模式下，只需在双机房建立两个平等集群，并建立一个较小的灰度发布集群。所有不同的业务都在统一的平台集群上运行，如下图所示。粒度较小的服务意味着每种服务的开发更简单，代码量更小，依赖性更小，隔离稳定性更高。然而，更细粒度的服务也意味着更繁琐的运维监控和管理。直到今年，公司内部弹性私有云、缓存云、消息队列、部署、监控、日志等基本系统日益完善，可能实施这种细粒度划分的微服务架构，运维成本可控。从最初的1.0应用过程到3.0的6、7个应用程序，再到4.050 不同种类的应用过程具有更细的粒度。根据承载业务流量的不同，每个过程分配不同的实例数，真实的实例数将超过1000。为了更好地监控和管理这些过程，专门定制了一套面向服务的运维管理系统，如下图所示。统一服务运维提供实用的内部工具和库，帮助开发更强大的微服务。包括中心配置管理、流量埋点监控、数据库和缓存访问、运行隔离，如下图所示：细粒度微服务实现过程间隔，严格的开发规范和工具库帮助实现异步信息和异步HTTP，避免多个跨过程同步长调用链。在此过程中，服务增强容器Armor被引入截面，以隔离线程，并支持在此过程中单独的业务降级和同步转异步化的实施。所有这些工具和图书馆服务都是为了两个目标：使服务过程运行状态可见，使服务过程运行状态可以管理和改变。最后，我们回到上面留下的一个悬念是关于信息传输模型的缺陷。一开始，在接入层检测到终端连接断开后，我们无法发送消息，然后缓存消息，然后在终端重新连接后拉出离线消息。由于移动网络的不稳定性，该模型在移动时代表现不佳，导致断链后频繁重连。网络连接断开的准确检测依赖于网络加班，导致检测可能不准确，导致虚假信息交付成功。如下图所示，新模型不再依赖于准确的网络连接检测，需要确认信息ID在交付前被缓存，而信息体被持续存储。直到终端接收确认返回后，消息才算投妥，未确认的消息ID重新登录或重新连接后作为离线消息推送。该模型不会产生假消息投妥造成的损失，但可能会导致消息重复，只需根据消息id由客户终端重复即可。京东咚咚诞生之初，就是京东技术转型为Java的时候，经过多年的发展，取得了很大的进步。从草根到专业，从弱到规模，从分散到统一，从混乱到规范。本文主要关注几年来东东架构演变的过程。我认为没有绝对的好坏。技术架构应始终放在当时的背景下，考虑业务的及时性价值、团队规模和能力、环境基础设施等。架构演变的生命周期只有及时匹配业务的生命周期，才能发挥最佳效果。