阅读笔记（七）

京东咚咚架构的经历：诞生（2010 - 2011) 成长（2012）爆发（2013 - 2014）涅槃（2015 至今 )

1.0 的时代背景正是京东技术平台从 .NET 向 Java 转型的年代不管是自营还是 POP 客服咨询业务当时都起步不久，1.0 架构中的性能和效率缺陷问题还没有达到引爆的业务量级。 而自营客服当时还处于起步阶段，客服人数不足，服务能力不够，顾客咨询量远远超过客服的服务能力。 超出服务能力的顾客咨询，当时我们的系统统一返回提示客服繁忙，请稍后咨询。 这种状况导致高峰期大量顾客无论怎么刷新请求，都很可能无法接入客服，体验很差。 所以 2.0 重点放在了业务功能体验的提升。

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

 

1. 业务分级、核心、非核心业务隔离

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

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

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

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

6. Redis 主备，失败转移

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

8. 改进消息投递模型

明显的问题：

 

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

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

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

 

1. 让服务进程运行时状态可见

2. 让服务进程运行时状态可被管理和改变

 从草根走向专业，从弱小走向规模，从分散走向统一，从杂乱走向规范。

原文部分转载：

京东咚咚架构演进