京东架构专家分享京东架构之路( 二 ) _架构

服务化的第一个问题如何把一个大的应用系统切分成子服务系统。当时的背景是京东的部署还在半自动化年代，自动部署系统刚起步，子服务系统若按业务划分太细太多，部署工作量很大且难管理。所以当时我们不是按业务功能分区服务的，而是按业务重要性级别划分了 0、1、2 三个级别不同的子业务服务系统。另外就是独立了一组接入服务，针对不同渠道和通信方式的接入端，见下图。

文章插图

更细化的应用服务和架构分层方式可见下图。

文章插图

这次大的架构升级，主要考虑了三个方面：稳定性、效率和容量。做了下面这些事情：
1.业务分级、核心、非核心业务隔离
2.多机房部署，流量分流、容灾冗余、峰值应对冗余
3.读库多源，失败自动转移
4.写库主备，短暂有损服务容忍下的快速切换
5.外部接口，失败转移或快速断路
6.Redis 主备，失败转移
7.大表迁移， MongoDB 取代 MySQL 存储消息记录
8.改进消息投递模型
前 6 条基本属于考虑系统稳定性、可用性方面的改进升级。这一块属于陆续迭代完成的，承载很多失败转移的配置和控制功能在上面图中是由管控中心提供的。第 7 条主要是随着业务量的上升，单日消息量越来越大后，使用了 MongoDB 来单独存储量最大的聊天记录。第 8 条是针对 1.0 版本消息轮询效率低的改进，改进后的投递方式如下图所示：

文章插图

不再是轮询了，而是让终端每次建立连接后注册接入点位置，消息投递前定位连接所在接入点位置再推送过去。这样投递效率就是恒定的了，而且很容易扩展，在线人数越多则连接数越多，只需要扩展接入点即可。其实，这个模型依然还有些小问题，主要出在离线消息的处理上，可以先思考下，我们最后再讲。
3.0 经过了两年的迭代式升级，单纯从业务量上来说还可以继续支撑很长时间的增长。但实际上到 2014 年底我们面对的不再是业务量的问题，而是业务模式的变化。这直接导致了一个全新时代的到来。
4.0 涅槃（2015 至今 )
2014 年京东的组织架构发生了很大变化，从一个公司变成了一个集团，下设多个子公司。原来的商城成为了其中一个子公司，新成立的子公司包括京东金融、京东智能、京东到家、拍拍、海外事业部等。各自业务范围不同，业务模式也不同，但不管什么业务总是需要客服服务。如何复用原来为商城量身订做的咚咚客服系统并支持其他子公司业务快速接入成为我们新的课题。
最早要求接入的是拍拍网，它是从腾讯收购的，所以是完全不同的账户和订单交易体系。由于时间紧迫，我们把为商城订做的部分剥离，基于 3.0 架构对接拍拍又单独订做了一套，并独立部署，像下面这样。

文章插图

虽然在业务要求的时间点前完成了上线，但这样做也带来了明显的问题：
1.复制工程，定制业务开发，多套源码维护成本高
2.独立部署，至少双机房主备外加一个灰度集群，资源浪费大
以前我们都是面向业务去架构系统，如今新的业务变化形势下我们开始考虑面向平台去架构，在统一平台上跑多套业务，统一源码，统一部署，统一维护。把业务服务继续拆分，剥离出最基础的 IM 服务， IM 通用服务，客服通用服务，而针对不同的业务特殊需求做最小化的定制服务开发。部署方式则以平台形式部署，不同的业务方的服务跑在同一个平台上，但数据互相隔离。服务继续被拆分的更微粒化，形成了一组服务矩阵（见下图）。