no.10京东咚咚架构演讲读后感

京东之与旺旺相当于淘宝，他们都是服务于买家和卖家的沟通。京东咚咚的功能比较简单，实现了一个 IM 的基本功能，接入、互通消息和状态。 另外还有客服功能，就是顾客接入咨询时的客服分配，按轮询方式把顾客分配给在线的客服接待。

这个模型的做法导致需要以一种高频率的方式来轮询 Redis 遍历属于自己连接的关联会话消息。这个模型很简单，简单包括多个层面的意思：理解起来简单；开发起来简单；部署起来也简单。只需要一个Tomcat 应用依赖一个共享的 Redis，简单的实现核心业务功能，并支持业务快速上线。

但这个简单的模型也有些严重的缺陷，主要是效率和扩展问题。轮询的频率间隔大小基本决定了消息的延时，轮询越快延时越低，但轮询越快消耗也越高。

2012年末，度过双十一开始了3.0的一次重大架构升级。

这次大的架构升级，主要考虑了三个方面：稳定性、效率和容量。 做了下面这些事情：

（1）业务分级、核心、非核心业务隔离

（2）多机房部署，流量分流、容灾冗余、峰值应对冗余

（3）读库多源，失败自动转移

（4）写库主备，短暂有损服务容忍下的快速切换

（5）外部接口，失败转移或快速断路

（6）Redis 主备，失败转移

（7）大表迁移，MongoDB 取代 MySQL 存储消息记录

（8）改进消息投递模型

2014 年京东的组织架构发生了很大变化，从一个公司变成了一个集团，下设多个子公司。原来的商城成为了其中一个子公司，新成立的子公司包括京东金融、京东智能、京东到家、拍拍、海外事业部等。 各自业务范围不同，业务模式也不同，但不管什么业务总是需要客服服务。

以前都是面向业务去架构系统，如今新的业务变化形势下我们开始考虑面向平台去架构，在统一平台上跑多套业务，统一源码，统一部署，统一维护。 把业务服务继续拆分，剥离出最基础的 IM 服务，IM 通用服务，客服通用服务，而针对不同的业务特殊需求做最小化的定制服务开发。部署方式则以平台形式部署，不同的业务方的服务跑在同一个平台上，但数据互相隔离。服务继续被拆分的更微粒化，形成了一组服务矩阵。而部署方式，只需要在双机房建立两套对等集群，并另外建一个较小的灰度发布集群即可，所有不同业务都运行在统一平台集群上。

更细粒度的服务意味着每个服务的开发更简单，代码量更小，依赖更少，隔离稳定性更高。 但更细粒度的服务也意味着更繁琐的运维监控管理，直到今年公司内部弹性私有云、缓存云、消息队列、部署、监控、日志等基础系统日趋完善， 使得实施这类细粒度划分的微服务架构成为可能，运维成本可控。 而从当初 1.0 的 1 种应用进程，到 3.0 的 6、7 种应用进程，再到 4.0 的 50+ 更细粒度的不同种应用进程。 每种进程再根据承载业务流量不同分配不同的实例数，真正的实例进程数会过千。 为了更好的监控和管理这些进程，为此专门定制了一套面向服务的运维管理系统。统一服务运维提供了实用的内部工具和库来帮助开发更健壮的微服务。 包括中心配置管理，流量埋点监控，数据库和缓存访问，运行时隔离。

细粒度的微服务做到了进程间隔离，严格的开发规范和工具库帮助实现了异步消息和异步 HTTP 来避免多个跨进程的同步长调用链。 进程内部通过切面方式引入了服务增强容器Armor 来隔离线程， 并支持进程内的单独业务降级和同步转异步化执行。而所有这些工具和库服务都是为了两个目标：（1）让服务进程运行时状态可见（2）让服务进程运行时状态可被管理和改变