探究京东咚咚架构演进史

什么是咚咚？咚咚之于京东，相当于旺旺之于淘宝，它们都服务于买卖双方的沟通。自从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的时候，经过多年的发展，取得了很大的进步。从草根到专业，从弱到规模，从分散到统一，从混乱到规范。本文主要关注几年来东东架构演变的过程。我认为没有绝对的好坏。技术架构应始终放在当时的背景下，考虑业务的及时性价值、团队规模和能力、环境基础设施等。架构演变的生命周期只有及时匹配业务的生命周期，才能发挥最佳效果。

以上就是关于探究京东咚咚架构演进史的相关介绍，更多探究京东咚咚架构演进史相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对探究京东咚咚架构演进史有更深的了解和认识。