当前位置: 首页 » 资讯头条 » 行业 » 正文

京东 B2B 业务架构演进解密

分享到:
放大字体  缩小字体    发布日期:2021-03-26  浏览次数:61
核心提示:  让一部分开发者看到未来  1  京东B2B业务的定位是让各类型的企业都可以在京东的B平台上进行采购、建立采购关系。  京东B2B的用户群体主要分为2类,一类是大B用户、另一类是小B用户。比如联通、移动公司跟京东建立的采购关系,就是B平台的大B用户;如果有一家小超市需要在京东B平台上进行采购,那么它就是B平台的
   让一部分开发者看到未来
 
  1
 
  京东B2B业务的定位是让各类型的企业都可以在京东的B平台上进行采购、建立采购关系。
 
  京东B2B的用户群体主要分为2类,一类是大B用户、另一类是小B用户。比如联通、移动公司跟京东建立的采购关系,就是B平台的大B用户;如果有一家小超市需要在京东B平台上进行采购,那么它就是B平台的小B用户。
 
  京东B平台需要支持各类型的用户群,因此必须要有自己的业务系统做支撑,比如订单、商品、价格、用户、权限、审核等系统
 
  02
 
  从上图可以看出,京东B平台的发展分为3个阶段
 
  1)
 
  第一阶段(2014年)
 
  B2B浪潮开始兴起,京东在2014年与联通公司达成合作,意味着京东正式迈入B2B时代的大B行业。
 
  2)第二阶段(2015-2016年)
 
  农村电商开始兴起,线下门店积极顺应互联网的发展趋势,将传统的零售搬到了线上;在这个阶段,京东成立新通路事业部开展此业务,从此京东正式迈入了小B行业。
 
  3)第三阶段(2017年至今)
 
  在之前大、小B业务的基础上,京东的B2B业务在2017年得到快速发展,完美应对这个阶段产生的种种挑战,并发量、数据量均成几十倍的增长。
 
  1
 
  从上
 
  可以看出,业务架构1.0分为3层
 
  业务层
 
  :主要是B平台的所有业务线
 
  :包含订单、价格、商品、用户等SOA服务系统
 
  :使用mysq l数据库进行存储
 
  在2014年初期,为了响应业务的发展,我们需要快速上线业务系统,采取的是纵向按业务线进行划分,每一条业务线都有自己的业务层、服务层、存储层,当有新的业务线接入的时候,还是以同样的模式进行开发。
 
  当来到第二阶段的时候,这种架构面对了极大的挑战,主要有以下几个表现:
 
  开发周期长,无法快速满足业务要求
 
  相互影响,订单和商品在一个数据库,一个出问题,会影响别的服务
 
  上述的表现反应出业务架构存在以下几点问题:
 
  服务之间零复用性,各个业务线的服务没有抽取共享的服务,其实有80%都是相同的模式,没有抽象。
 
  系统之间
 
  的
 
  相互调用采用的jsf服务,全部是同步调用,调用链路很长,一个环节出问题会导致整个系统都出问题,没有核心服务和非核心服务、没有异步化服务。
 
  由于前期是按业务线进行划分,在一个业务线上,核心服务的数据都存储在一个数据库上面。
 
  ,
 
  将各个业务线的的服务拆分成小服务。
 
  步
 
  ,
 
  合第一步抽取的服务,形成公共服务,以后所有业务线都请求这些公共服务,提高服务的复用性。
 
  采集数据(自动)
 
  数据对比(自动)
 
  条件
 
  :新老服务的对外接口参数不变
 
  系统耦合的问题,通过引入jmq消息中间件进行解决。消息无序的问题,采用乐观锁进行解决,主要是依靠数据的版本对比来解决。
 
  数据公用的问题,解决方案还是进行拆分:
 
  ,
 
  将各个业务系统SOA服务的数据,单独存储在自己的数据库,订单有订单专门的数据库、商品有商品专门的数据库,服务之间互相不受影响。
 
  ,
 
  在第一个步拆分后,有的业务数据量单表数量还是很大,需要对表进行拆分,我们采用jproxy(不支持分表)进行分库,按业务的相关主键id,进行hash(id)%count(分库数量),支持水平扩展。
 
  还有那些分布算法方式:
 
  ID区间算法、时间区间
 
  二次hash
 
  弱化强一致性,采用消息的机制进行交互,实现最终一致性。
 
  垮库查询:分布式查询
 
  分布式查询,采用的是elasticSearch搜索进行支持,简称es。
 
  jmq和binlog
 
  如果es集群有问题,采用的方式是备份集群支持服务(数据有延迟风险)
 
  2
 
  在1.0的基础上,做如下三点调整:
 
  引入基础层的工具
 
  2.0系统在2017年进入第三阶段后,开始面临以下两个问题:
 
  平台化服务业务代码臃肿
 
  个性化需求的重复开发
 
  举一个例子,我们现在有「订单」、「价格」、「商品」服务,
 
  A用户需要订单服务,B用户需要订单、价格服务,C用户需要订单、价格、商品服务。现在的做法是开发3套业务接口服务,底层的服务是通用的,但是业务层的代码有重复开发、业务代码臃肿的问题。
 
  引入配置中心
 
  对页面进行配置
 
  通过以上的思考,我们有了组件的思想,以后对外的服务都是可配置的。就像一个加工厂,对服务加工,就可以对外部业务进行使用。
 
  3.0的版本主要是修改,包含服务层的抽取、业务和SOA分离,同时引入业务和工具组件。
 
  B2B业务架构经过3次变迁与升级,我们总结到以下经验:
 
  点击下方图片即可阅读
 
  选择”
 
  “星标
 
  ,内容一触即达。点击原文更多惊喜!
 
  开发者技术前线
 
  汇集技术前线快讯和关注行业趋势,大厂干货,是开发者经历和成长的优秀指南。
 
  支付宝App架构的原理与实战
 
  淘宝高并发分布式架构演进之路
 
  阿里巴巴微服务架构的四大金刚利器
 
  为什么阿里巴巴不建议boolean类型变量用isXXX?
 
  点个在看,月薪几万!
 
 
打赏
[ 资讯头条搜索 ]  [ 加入收藏 ]  [ 告诉好友 ]  [ 打印本文 ]  [ 违规举报 ]  [ 关闭窗口 ]
免责声明:
本网站部分内容来源于合作媒体、企业机构、网友提供和互联网的公开资料等,仅供参考。本网站对站内所有资讯的内容、观点保持中立,不对内容的准确性、可靠性或完整性提供任何明示或暗示的保证。如果有侵权等问题,请及时联系我们,我们将在收到通知后第一时间妥善处理该部分内容。
 

京东 B2B 业务架构演进解密二维码

扫扫二维码用手机关注本条新闻报道也可关注本站官方微信账号:"xxxxx",每日获得互联网最前沿资讯,热点产品深度分析!
 

 
0相关评论