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

架构好教育学习,攒~~

京东咚咚架构演进 — By
【刹那息之间】

名词解释:

  Apache MINA:
百度宏观

  HAProxy:
百度百科

1.0 架构笔记:

  优点:模型结构简单—了然起来简单;开发起来简单;部署起来也简单。

  缺点:效用和扩展—那个模型实际上是一个高功耗低效用的模型,不活跃的连接在这做高频率的架空轮询,高频有多高啊,基本在
100 ms 以内,

     你无法让轮询太慢,比如跨越 2
秒轮五次,人就会在闲聊过程中感受到明确的对话延迟。
随着在线人数有增无减,轮询的耗时也线性增长,

     因此这么些模型导致了扩充能力和承载能力都不好,一定会随着在线人数的提升碰着性能瓶颈。

2.0 架构笔记:

  革新点:业务职能体验的提高上—针对不可以即时提供劳动的顾客,可以排队或者留言。
针对纯文字交换,提供了文件和图表等更增长的表达模式。

      其余援助了客服转接和飞快回复等措施来提升客服的款待效率。

3.0 架构笔记:

  立异点:业务划分服务,且服务拓展分层—服务化的第一个问题怎么把一个大的施用系统切分成子服务类别。

      按工作首要级别划分了 0、1、2
六个级别不同的子业务服务系统。
此外就是独立了一组接入服务,针对不同渠道和通信格局的接入端。

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

                b.负载均衡层 — TCP长连接,HTTP短连接

                c.路由服务层 — 路由 Tracker

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

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

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

      信息投递模型—不再是轮询了,而是让终端每便建立连接后登记接入点地方,信息投递前一定连接所在接入点地方再推送过去。

NoSQL,             这样投递效能就是一定的了,而且很容易扩大,在线人数越多则连接数越多,只需要增加接入点即可。 

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

4.0 架构笔记:

  拍拍网音信缺陷:a.复制工程,定制业务支付,多套源码维护成本高

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

  系统相连演进:面向平台—始考虑面向平台去架构,在集合平台上跑多套业务,统一源码,统一安排,统一敬服。
把事情服务持续拆分,

         剥离出最基础的 IM 服务,IM
通用服务,客服通用服务,而针对性不同的政工分外要求做最小化的定打败务付出。

         部署形式则以平台形式安排,不同的业务方的劳务跑在同一个阳台上,但多少交互隔离。

         细粒度服务支出—更细粒度的劳动表示每个服务的支出更简约,代码量更小,看重更少,隔离稳定性更高。

  架构VS业务: 技术架构并未断然的好与糟糕,
技术架构总是要放在这儿的背景下来看,要考虑工作的时效价值、团队的层面和能力、

           环境基础设备等等方面。
架构演进的生命周期适时匹配好工作的生命周期,才可能表述最好的效果。

 

 

 

                                         蒙

                                    2017-08-02
09:20 周三

 

网站地图xml地图