Jingdong Dongdong Architecture Evolution
What is dong dong? Dongdong is to JD.com as Wangwang is to Taobao. They both serve the communication between buyers and sellers. Since JD.com began to provide platform services for third-party sellers, Dongdong was born. Let's first look at what it was like when it was born.
1.0 Birth (2010 - 2011)
In order to quickly launch the business, the implementation of the technical architecture of version 1.0 is very direct and simple. How to be simple and rude? Please see the architecture diagram below.
The function of 1.0 is very simple, and realizes the basic functions of an IM, such as access, exchange of messages and status. In addition, there is a customer service function, that is, the customer service allocation when the customer accesses the consultation, and the customer is allocated to the online customer service reception according to the polling method. The open source Mina framework is used to realize the long connection access of TCP, and the mechanism of Tomcat Comet is used to realize the long polling service of HTTP. The implementation of message delivery is a production and consumption model in which messages sent by one end are temporarily stored in Redis and pulled by the other end.
The approach to this model results in the need to poll Redis to traverse the associated session messages belonging to its own connection in a high frequency fashion. This model is very simple, and it simply includes multiple levels of meaning: easy to understand; easy to develop; easy to deploy. Only one Tomcat application needs to rely on a shared Redis, which can simply implement the core business functions and support the rapid launch of the business.
But this simple model also has some serious flaws, mainly efficiency and scaling issues. The frequency interval of polling basically determines the delay of the message. The faster the polling, the lower the delay, but the faster the polling, the higher the consumption. This model is actually a high-power low-performance model, because inactive connections do high-frequency pointless polling there. How high is the high frequency, basically within 100 ms, you can't make the polling too slow, for example, if the polling is more than 2 seconds, people will experience a significant conversation delay during the chat. As the number of online users increases, the polling time also increases linearly. Therefore, this model leads to poor scalability and carrying capacity, and will inevitably encounter performance bottlenecks as the number of online users increases.
The background of the era of 1.0 is the era of the transformation of JD.com's technology platform from .NET to Java. It was during this period that I joined JD.com and participated in the process of upgrading the technology transformation architecture of JD.com's main station. After that, he took over Jingdong Dongdong, and continued to improve this product, and carried out three technical architecture evolutions.
2.0 Growth (2012)
When we first took over, 1.0 was already running online and supported JD.com's POP (open platform) business. After that, JD.com plans to set up a self-operated online customer service team and land in Chengdu. Whether it was self-operated or POP customer service consulting business, it was not long ago, and the performance and efficiency defects in the 1.0 architecture had not yet reached the level of detonation. The self-operated customer service was still in its infancy at that time, the number of customer service personnel was insufficient, the service capacity was insufficient, and the volume of customer inquiries far exceeded the service capacity of customer service. For customer consultation beyond the service capacity, our system uniformly returned to remind the customer service to be busy at that time, please consult later. This situation leads to a large number of customers during peak hours, no matter how they refresh their requests, they are likely to be unable to access the customer service, and the experience is very poor. Therefore, 2.0 focuses on the improvement of business function experience, as shown in the following figure.
For customers who cannot provide services in time, they can queue up or leave a message. For text-only communication, richer expressions such as documents and pictures are provided. In addition, it supports customer service transfer and quick reply to improve the reception efficiency of customer service. In short, the entire 2.0 is about improving customer service efficiency and user experience. And the efficiency problem we are worried about has not yet appeared in the period of rapid business development in 2.0, but the business volume is gradually accumulating, and we know that it is about to explode. By the end of 2012, a major architecture upgrade of 3.0 began after the Double Eleven.
3.0 Outbreak (2013 - 2014)
After a whole year of rapid business development in the 2.0 era, in fact, the size of the code has expanded rapidly. Along with the code was the team that swelled from the initial 4 people to nearly 30 people. After the team grows, a system will be developed by multiple people, the level of developers will be different, the specifications will be difficult to unify, the system modules will be heavily coupled, there will be many changes, communication and dependencies, and the online risk will be difficult to control. A single tomcat application multi-instance deployment model has finally come to an end, and the theme of this version's architecture upgrade is service. If you want to learn Java engineering, high performance and distributed, explain the profound things in simple language. Friends of microservices, Spring, MyBatis, and Netty source code analysis can join the Java advanced group: 726610841. In the group, there are Alibaba Daniel's live broadcast explanation technology, and the video of Java large-scale Internet technology is shared with you for free.
The first problem of servitization is how to divide a large application system into sub-service systems. The background at that time was that the deployment of JD.com was still in the semi-automated era, and the automatic deployment system had just started. If the sub-service system was divided into too many sub-services, the deployment workload would be heavy and difficult to manage. So at that time, we did not divide the service by business function, but divided the sub-business service system into three different levels: 0, 1, and 2 according to the business importance level. In addition, there is an independent set of access services for access terminals of different channels and communication methods, as shown in the figure below.
A more detailed application service and architecture layering method can be seen in the following figure.
This major architectural upgrade mainly considers three aspects: stability, efficiency and capacity. Did the following things:
Business classification, core and non-core business isolation
Multi-machine room deployment, traffic distribution, disaster recovery redundancy, peak response redundancy
Read the library from multiple sources, fail to automatically transfer
Write database master and backup, fast switching under short-term loss of service tolerance
External interface, failover or quick disconnect
Redis master and backup, failover
Large table migration, MongoDB replaces MySQL to store message records
Improved message delivery model
The first 6 items are basically considered improvements and upgrades in terms of system stability and usability. This part is completed iteratively, and the configuration and control functions that carry many failovers are provided by the control center in the above figure. Item 7 is mainly because with the increase of business volume and the increasing amount of messages per day, MongoDB is used to store the largest chat record separately. Item 8 is an improvement for the low efficiency of message polling in version 1.0. The improved delivery method is shown in the following figure:
It is no longer polling, but allows the terminal to register the location of the access point after each connection is established, and the location of the access point where the connection is located before message delivery is pushed to the past. In this way, the delivery efficiency is constant, and it is easy to expand. The more people online, the more connections, just need to expand the access point. In fact, there are still some small problems in this model, mainly in the processing of offline messages. You can think about it first, and then we will talk about it at the end.
3.0 After two years of iterative upgrades, it can continue to support growth for a long time purely in terms of business volume. But in fact, by the end of 2014, what we are facing is no longer the problem of business volume, but the change of business model. This led directly to a whole new era.
4.0 Nirvana (2015 to present)
2014 年京东的组织架构发生了很大变化，从一个公司变成了一个集团，下设多个子公司。 原来的商城成为了其中一个子公司，新成立的子公司包括京东金融、京东智能、京东到家、拍拍、海外事业部等。 各自业务范围不同，业务模式也不同，但不管什么业务总是需要客服服务。 如何复用原来为商城量身订做的咚咚客服系统并支持其他子公司业务快速接入成为我们新的课题。
最早要求接入的是拍拍网，它是从腾讯收购的，所以是完全不同的账户和订单交易体系。 由于时间紧迫，我们把为商城订做的部分剥离，基于 3.0 架构对接拍拍又单独订做了一套，并独立部署，像下面这样。
虽然在业务要求的时间点前完成了上线，但这样做也带来了明显的问题：
复制工程，定制业务开发，多套源码维护成本高
独立部署，至少双机房主备外加一个灰度集群，资源浪费大
以前我们都是面向业务去架构系统，如今新的业务变化形势下我们开始考虑面向平台去架构，在统一平台上跑多套业务，统一源码，统一部署，统一维护。 把业务服务继续拆分，剥离出最基础的 IM 服务，IM 通用服务，客服通用服务，而针对不同的业务特殊需求做最小化的定制服务开发。 部署方式则以平台形式部署，不同的业务方的服务跑在同一个平台上，但数据互相隔离。 服务继续被拆分的更微粒化，形成了一组服务矩阵（见下图）。
而部署方式，只需要在双机房建立两套对等集群，并另外建一个较小的灰度发布集群即可，所有不同业务都运行在统一平台集群上，如下图。
更细粒度的服务意味着每个服务的开发更简单，代码量更小，依赖更少，隔离稳定性更高。 但更细粒度的服务也意味着更繁琐的运维监控管理，直到今年公司内部弹性私有云、缓存云、消息队列、部署、监控、日志等基础系统日趋完善， 使得实施这类细粒度划分的微服务架构成为可能，运维成本可控。 而从当初 1.0 的 1 种应用进程，到 3.0 的 6、7 种应用进程，再到 4.0 的 50+ 更细粒度的不同种应用进程。 每种进程再根据承载业务流量不同分配不同的实例数，真正的实例进程数会过千。 为了更好的监控和管理这些进程，为此专门定制了一套面向服务的运维管理系统，见下图。
统一服务运维提供了实用的内部工具和库来帮助开发更健壮的微服务。 包括中心配置管理，流量埋点监控，数据库和缓存访问，运行时隔离，如下图所示是一个运行隔离的图示：
细粒度的微服务做到了进程间隔离，严格的开发规范和工具库帮助实现了异步消息和异步 HTTP 来避免多个跨进程的同步长调用链。 进程内部通过切面方式引入了服务增强容器 Armor 来隔离线程， 并支持进程内的单独业务降级和同步转异步化执行。而所有这些工具和库服务都是为了两个目标：
让服务进程运行时状态可见
让服务进程运行时状态可被管理和改变
最后我们回到前文留下的一个悬念，就是关于消息投递模型的缺陷。 一开始我们在接入层检测到终端连接断开后，消息无法投递，再将消息缓存下来，等终端重连接上来再拉取离线消息。 这个模型在移动时代表现的很不好，因为移动网络的不稳定性，导致经常断链后重连。 而准确的检测网络连接断开是依赖一个网络超时的，导致检测可能不准确，引发消息假投递成功。 新的模型如下图所示，它不再依赖准确的网络连接检测，投递前待确认消息 id 被缓存，而消息体被持久存储。 等到终端接收确认返回后，该消息才算投妥，未确认的消息 id 再重新登陆后或重连接后作为离线消息推送。 这个模型不会产生消息假投妥导致的丢失，但可能导致消息重复，只需由客户终端按消息 id 去重即可。
京东咚咚诞生之初正是京东技术转型到 Java 之时，经历这些年的发展，取得了很大的进步。 从草根走向专业，从弱小走向规模，从分散走向统一，从杂乱走向规范。 本文主要重心放在了几年来咚咚架构演进的过程，技术架构单独拿出来看我认为没有绝对的好与不好， 技术架构总是要放在彼时的背景下来看，要考虑业务的时效价值、团队的规模和能力、环境基础设施等等方面。 架构演进的生命周期适时匹配好业务的生命周期，才可能发挥最好的效果。
京东峰值系统设计
有别于社交网络、搜索和游戏等网站，电商网站的用户流量具有操作性强、随时令变化等特点。在欧美国家，Black Friday和Cyber Monday标志着节假日消费的高峰。影响电商流量峰值的主要因素是抢购、促销和恶意攻击，尤其是京东618店庆和双11等大规模的促销活动。高流量、高并发情况下，如何保证整个系统的可靠性和稳定性，是众多电商企业研发团队都在思考的问题。
京东电商系统的设计是围绕系统稳定性、可靠性、高并发和可扩展性为核心开展的。如何在峰值来临时，保证用户有平滑流畅的体验，且系统不会出现异常呢？我们先来看看京东系统的一些特点（图1）。
图1 系统架构庞大复杂
京东的业务种类繁多，涉及SKU几千万种，这使得系统庞大，外部需要对接供应商、消费者和第三方商家三大板块。内部系统包括了商品供应链中除商品设计和生产外的几乎所有环节，包括登录、交易、后台、供应链、仓配、客服等。所有这些涉及大小系统几千个，造就了一个极其复杂庞大的体系。除此之外，京东系统交互强，各个功能模块之间关联性强，牵一发而动全身，做任何修改都需要慎之又慎。因此，一切优化方案都以保持系统稳定为前提。
为了在复杂的系统基础之上，尽量缓解峰值带来的压力，京东峰值系统的设计主要从性能提升、流量控制、灾备降级、压测预案四个角度来进行。
性能提升
切分业务系统
我们先将整个业务体系拆分为几个相对独立的子系统如SSO、交易平台、POP平台、订单下传系统、WMS和仓储配送（图2）。每个子系统又可细分为若干部分，逐级简化，直至可操作可优化的层级。例如，交易平台包括价格、购物车、结算、支付和订单中心等；网站系统包括首页、登录、列表频道、单品和搜索等。接下来，针对每个功能模块的关键部分进行切分，有针对性地做性能优化。
图2 业务切分方案
例如，交易的秒杀系统，原来是根植于普通交易系统之内的，缺点非常明显。当流量突然增大时，不仅会导致秒杀系统反应迟钝，而且会影响普通交易系统的正常运作。于是我们将其与其他业务系统物理分开，成为相对独立的子系统。并且针对秒杀的特性，减少对后台存储的依赖。同时优化中间层存储机制，使得相对热点分散部署。甚至支持单一SKU多点部署，从而大大提升了秒杀系统的吞吐量和可靠性。
分布式
分布式的交易系统是电商的未来。分布式系统解决两大难题：提高用户体验和增强容错能力。由于分布式系统设计时就会留有相当的流量增长空间，所以当一处数据中心饱和时，可以将其余的流量切入其他相对宽松的数据中心去，从而达到互为备份、互相支持的目的。与此同时，由于为提供用户就近服务，所以减少了网络延时，页面反应速度加快了。举一个例子，Google搜索是全球服务，欧亚美各地都有不同的IP提供服务。当其中的某一个IP出现故障时，Google能够从容地将其服务切换至最近的IP，继续搜索服务。对于电商来说，情况更复杂一些，需要同步的数据要求更精确，数据量较大，对延时的容忍度更低，建设周期也就更长。京东正在此方面着力改进，从只读的系统入手，一步一步实现系统的分布式。
API服务化
In each system, there are always many of the same components. Needless to say, front-end load balancing, middleware processing is a very typical example. How to manage these components efficiently and uniformly, API service is our answer. It is best for a well-trained team to centrally manage these components and provide interface services to the outside world, hiding the complexity of software use and calling simple and neat APIs. Let professionals handle complex logic and ensure the availability and scalability of the system, which can greatly reduce the probability of errors and achieve economies of scale.
Redis is our commonly used cache component. In the past, it was maintained by each business implementation team separately, which was not very professional and used inappropriately. Later, we carried out centralized management, unified customized development of new functions and upgrades, and provided them to users at all levels through API service. This not only enriches application scenarios, but also improves performance and reliability.
Architecture, code optimization
A reasonable e-commerce system architecture is inseparable from a company's R&D level and technical management level, which directly determines the amount of peak traffic that can be supported and the height it can reach in the future. Choosing a framework suitable for your own development can not only give full play to its effectiveness, but also save resources. Code optimization can also improve performance. For example, the optimization of SQL statements can make better use of indexes; the optimization of Java/C++ logic reduces unnecessary cycles and complex operations; algorithm optimization makes it more efficient; function implementation logic optimizations, become more concise and clear; and so on. However, code optimization cannot break through the limit after all, it is difficult to pursue the ultimate, and it is appropriate to do so.
System Virtualization Elasticity
When disk I/O is not the bottleneck, it becomes much easier to solve horizontal scaling of the system. Software stacks can be organically connected by ZooKeeper or ZooKeeper-like, with effective performance monitoring. When transaction processing becomes the bottleneck, using today's popular virtualization technologies such as LXC or VM allows for automatic elastic scaling without human intervention.
The article is transferred from: https://blog.csdn.net/qq_41534566/article/details/79898206