咚咚是什么？咚咚之于京东相当于旺旺之于淘宝，它们都是服务于买家和卖家的沟通。 自从京东开始为第三方卖家提供入驻平台服务后，咚咚也就随之诞生了。
京东咚咚的架构历程有四个阶段，1.0版的诞生，2.0版的成长，3.0版的爆发，到4.0版的涅槃，以下是京东咚咚2015年至今的4.0版架构模式：
2014 年京东的组织架构发生了很大变化，从一个公司变成了一个集团，下设多个子公司。 原来的商城成为了其中一个子公司，新成立的子公司包括京东金融、京东智能、京东到家、拍拍、海外事业部等。 各自业务范围不同，业务模式也不同，但不管什么业务总是需要客服服务。 如何复用原来为商城量身订做的咚咚客服系统并支持其他子公司业务快速接入成为我们新的课题。
最早要求接入的是拍拍网，它是从腾讯收购的，所以是完全不同的账户和订单交易体系。 由于时间紧迫，我们把为商城订做的部分剥离，基于 3.0 架构对接拍拍又单独订做了一套，并独立部署，像下面这样。
虽然在业务要求的时间点前完成了上线，但这样做也带来了明显的问题：
-
复制工程，定制业务开发，多套源码维护成本高
-
独立部署，至少双机房主备外加一个灰度集群，资源浪费大
以前我们都是面向业务去架构系统，如今新的业务变化形势下我们开始考虑面向平台去架构，在统一平台上跑多套业务，统一源码，统一部署，统一维护。 把业务服务继续拆分，剥离出最基础的 IM 服务，IM 通用服务，客服通用服务，而针对不同的业务特殊需求做最小化的定制服务开发。 部署方式则以平台形式部署，不同的业务方的服务跑在同一个平台上，但数据互相隔离。 服务继续被拆分的更微粒化，形成了一组服务矩阵（见下图）。
而部署方式，只需要在双机房建立两套对等集群，并另外建一个较小的灰度发布集群即可，所有不同业务都运行在统一平台集群上，如下图。
更细粒度的服务意味着每个服务的开发更简单，代码量更小，依赖更少，隔离稳定性更高。 但更细粒度的服务也意味着更繁琐的运维监控管理，直到今年公司内部弹性私有云、缓存云、消息队列、部署、监控、日志等基础系统日趋完善， 使得实施这类细粒度划分的微服务架构成为可能，运维成本可控。 而从当初 1.0 的 1 种应用进程，到 3.0 的 6、7 种应用进程，再到 4.0 的 50+ 更细粒度的不同种应用进程。 每种进程再根据承载业务流量不同分配不同的实例数，真正的实例进程数会过千。 为了更好的监控和管理这些进程，为此专门定制了一套面向服务的运维管理系统，见下图。
统一服务运维提供了实用的内部工具和库来帮助开发更健壮的微服务。 包括中心配置管理，流量埋点监控，数据库和缓存访问，运行时隔离，如下图所示是一个运行隔离的图示：
细粒度的微服务做到了进程间隔离，严格的开发规范和工具库帮助实现了异步消息和异步 HTTP 来避免多个跨进程的同步长调用链。 进程内部通过切面方式引入了服务增强容器 Armor 来隔离线程， 并支持进程内的单独业务降级和同步转异步化执行。而所有这些工具和库服务都是为了两个目标：
-
让服务进程运行时状态可见
-
让服务进程运行时状态可被管理和改变
京东咚咚架构的变化过程，经过了很大的变化，随着公司规模的壮大，架构模式也在随之变化，因此，每个架构都不是最完美的，都需要与时俱进才能持续发展。
文章引用原文地址：https://mp.weixin.qq.com/s?__biz=MzAxMTEyOTQ5OQ==&mid=401186254&idx=1&sn=1b3c81386973c99cad99079fcd6be6e3&scene=21#wechat_redirect