【京东咚咚架构演进】-- 好文收藏

索引：

目录索引

架构好文学习，攒~~

京东咚咚架构演进 -- By 【瞬息之间】

名词解释：

　　Apache MINA： 百度百科

　　HAProxy： 百度百科

1.0 架构笔记：

　　优势：模型结构简单---理解起来简单；开发起来简单；部署起来也简单。

　　缺点：效率和扩展---这个模型其实是一个高功耗低效能的模型，不活跃的链接在那作高频率的无心义轮询，高频有多高呢，基本在 100 ms 之内，

　　　　　你不能让轮询太慢，好比超过 2 秒轮一次，人就会在聊天过程当中感觉到明显的会话延迟。 随着在线人数增长，轮询的耗时也线性增加，

　　　　　所以这个模型致使了扩展能力和承载能力都很差，必定会随着在线人数的增加碰到性能瓶颈。

2.0 架构笔记：

　　改进点：业务功能体验的提高上---针对没法及时提供服务的顾客，能够排队或者留言。 针对纯文字沟通，提供了文件和图片等更丰富的表达方式。

　　　　　　另外支持了客服转接和快捷回复等方式来提高客服的接待效率。

3.0 架构笔记：

　　改进点：业务划分服务，且服务进行分层---服务化的第一个问题如何把一个大的应用系统切分红子服务系统。

　　　　　　按业务重要性级别划分了 0、一、2 三个级别不一样的子业务服务系统。 另外就是独立了一组接入服务，针对不一样渠道和通讯方式的接入端。

　　　　　　服务架构&分层---a.UI接入层 --- 客服用(web/app..)系统，员工用(web/app/pc...)

　　　　　　　　　　　　　   b.负载均衡层 --- TCP长链接，HTTP短链接

　　　　　　　　　　　　　   c.路由服务层 --- 路由 Tracker

　　　　　　　　　　　　　   d.业务服务层 --- 业务子系统及API服务

　　　　　　　　　　　　　   e.基础服务层 --- 基础框架服务(安全/风控/资源分配...)

　　　　　　　　　　　　　   f.资源服务层 --- DB/Cache/NoSQL/MQ....

　　　　　　消息投递模型---再也不是轮询了，而是让终端每次创建链接后注册接入点位置，消息投递前定位链接所在接入点位置再推送过去。

　　　　　　　　　　　　　这样投递效率就是恒定的了，并且很容易扩展，在线人数越多则链接数越多，只须要扩展接入点便可。 

　　　　　　　　　　　　　使用了 MongoDB 来单独存储量最大的聊天记录。 

4.0 架构笔记：

　　拍拍网消息缺陷：a.复制工程，定制业务开发，多套源码维护成本高

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

　　系统持续演进：面向平台---始考虑面向平台去架构，在统一平台上跑多套业务，统一源码，统一部署，统一维护。 把业务服务继续拆分，

　　　　　　　　　剥离出最基础的 IM 服务，IM 通用服务，客服通用服务，而针对不一样的业务特殊需求作最小化的定制服务开发。

　　　　　　　　　部署方式则以平台形式部署，不一样的业务方的服务跑在同一个平台上，但数据互相隔离。

　　　　　　　　　细粒度服务开发---更细粒度的服务意味着每一个服务的开发更简单，代码量更小，依赖更少，隔离稳定性更高。

　　架构VS业务： 技术架构没有绝对的好与很差， 技术架构老是要放在彼时的背景下来看，要考虑业务的时效价值、团队的规模和能力、

　　　　　　　　   环境基础设施等等方面。 架构演进的生命周期适时匹配好业务的生命周期，才可能发挥最好的效果。

 

 

 

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　蒙

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　2017-08-02 09:20 周三