《京东B2B业务架构演变》阅读笔记

一、京东 B2B 业务的定位

  让各类型的企业都可以在京东的 B 平台上进行采购、建立采购关系。

  京东 B2B 的用户群体主要分为 2 类:

  一类是大 B 用户、另一类是小 B 用户。京东 B 平台需要支持各类型的用户群,因此必须要有自己的业务系统做支撑,比如订单、商品、价格、用户、权限、审核等系统。

二、京东B平台的发展氛围:

  1、第一阶段(2014年):

    B2B 浪潮开始兴起,京东在2014年与联通公司达成合作,意味着京东正式迈入B2B时代的大 B 行业。

  2、第二阶段(2015-2016年):

    农村电商开始兴起,线下门店积极顺应互联网的发展趋势,将传统的零售搬到了线上;在这个阶段,京东成立新通路事业部开展此业务,从此京东正式迈入了小 B 行业。

  3、第三阶段(2017至今):

  在之前大、小 B 业务的基础上,京东的 B2B 业务在2017年得到快速发展,完美应对这个阶段产生的种种挑战,并发量、数据量均成几十倍的增长。

三、业务架构:

  1、业务层:

    主要是B平台的所有业务线

  2、服务层:

    包含订单、价格、商品、用户等 SOA 服务系统

  3、存储层:

    使用 mysq l数据库进行存储

  第二阶段开发时,这种架构面临了巨大的挑战,主要表现为:

  1、开发周期长,无法快速满足业务要求

  2、服务之间的相互影响,订单和商品在一个数据库,一个出问题,会影响别的服务

  3、系统之间耦合度大

  上述的表现反应出业务架构存在以下问题:

  1、服务问题:

    服务之间零复用性,各个业务线的服务没有抽取共享的服务,其实有80%都是相同的模式,没有抽象。

  2、系统耦合:

    系统之间的相互调用采用的 jsf 服务,全部是同步调用,调用链路很长,一个环节出问题会导致整个系统都出问题,没有核心服务和非核心服务、没有异步化服务。

  3、公用数据库问题:

    由于前期是按业务线进行划分,在一个业务线上,核心服务的数据都存储在一个数据库上面。

  真武服务问题的改进:可以进行两部拆分:

  1、第一步拆分:

    将各个业务线的服务拆分成小服务。

  2、第二步拆分:

    组合第一步抽取的服务,形成公共服务,以后所有业务线都请求这些公共服务,提高服务的复用性。

  系统耦合的问题:通过引入 jmq 消息中间件进行解决。

  消息无序的问题:采用乐观锁进行解决,主要是依靠数据的版本对比来解决。

  数据库的改进:解决方案还是进行拆分:

  1、第一步:

    将各个业务系统 SOA 服务的数据,单独存储在自己的数据库,订单有订单专门的数据库、商品有商品专门的数据库,服务之间互相不受影响。

  2、第二步:

    在第一个步拆分后,有的业务数据量单表数量还是很大,需要对表进行拆分,我们采用 jproxy(不支持分表)进行分库,按业务的相关主键 id,进行 hash(id)%count(分库数量),支持水平扩展。

四、扩展:

  1、分布算法方式:

    ID 区间算法、时间区间

  2、热点数据:

    二次 hash

  3、事务:

    弱化强一致性,采用消息的机制进行交互,实现最终一致性

  4、垮库查询:

    分布式查询

  分布式查询,采用的是 elasticSearch 搜索进行支持,简称es,消息同步才用 jmq 和 binlog。如果 es 集群有问题,采用的方式是备份集群支持服务。

五、B2B业务架构经过3次变迁与升级,总结到以下经验:

  1、稳定性原则:

    以稳定为中心,架构尽可能简单、清晰,不过度设计。

  2、抽象化:

    应用抽象,数据库抽象,服务抽象。

  3、松耦合:

    跨域调用异步化,超时时间

  4、拆分:

    稳定性与非稳定性系统分离,应用和数据的分离。

 

  原文链接:

  https://mp.weixin.qq.com/s?__biz=MzU1MzE2NzIzMg==&mid=2247486624&idx=1&sn=1601d21c8a77dca44936f4c7a5be4b32&chksm=fbf7bc4fcc8035591ed2382f0b4ffc3e86e39aa585dcd790baeb16504699e00fb656e4ee0c22&scene=21#wechat_redirect

posted @ 2019-04-05 17:53  我命倾尘  阅读(556)  评论(0编辑  收藏  举报