一、京东 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、拆分：
稳定性与非稳定性系统分离，应用和数据的分离。
原文链接：