《京东咚咚架构演进》---阅读

大家对咚咚有什么了解？认识他吗？

咚咚之于京东相当于旺旺之于淘宝。它们都是服务于买家和卖家的沟通。 自从京东开始为第三方卖家提供入驻平台服务后，咚咚也就随之诞生了。

文章总结了咚咚的演进，这里使用简短的话语给出一些总结：

1.0 诞生：1.0 的功能十分简单，实现了一个 IM 的基本功能，接入、互通消息和状态。 另外还有客服功能，就是顾客接入咨询时的客服分配，按轮询方式把顾客分配给在线的客服接待。用开源 Mina 框架实现了 TCP 的长连接接入，用 Tomcat Comet 机制实现了 HTTP 的长轮询服务。 而消息投递的实现是一端发送的消息临时存放在 Redis 中，另一端拉取的生产消费模型。

2.0成长：1.0 架构中的性能和效率缺陷问题还没有达到引爆的业务量级。  超出服务能力的顾客咨询，当时我们的系统统一返回提示客服繁忙，请稍后咨询。 这种状况导致高峰期大量顾客无论怎么刷新请求，都很可能无法接入客服，体验很差。  2.0 重点放在了业务功能体验的提升上。针对无法及时提供服务的顾客，可以排队或者留言。 针对纯文字沟通，提供了文件和图片等更丰富的表达方式。 另外支持了客服转接和快捷回复等方式来提升客服的接待效率。 

3.0爆发：服务化的第一个问题如何把一个大的应用系统切分成子服务系统。这次考虑系统稳定性、可用性方面的改进升级，单独存储量上也做了改进，但之后人数会越来越多，单纯从业务量上来说还可以继续支撑很长时间的增长。之后的考虑就是=业务模式的变化。

4.0 涅槃：面临问题：

1.复制工程，定制业务开发，多套源码维护成本高

2.独立部署，至少双机房主备外加一个灰度集群，资源浪费大

解决：统一服务运维提供了实用的内部工具和库来帮助开发更健壮的微服务；更细粒度的服务意味着每个服务的开发更简单，代码量更小，依赖更少，隔离稳定性更高；

细粒度的微服务做到了进程间隔离，严格的开发规范和工具库帮助实现了异步消息和异步 HTTP 来避免多个跨进程的同步长调用链。 

咚咚是成功的，经历了这么多年，也算是涅槃了。崛起。