架构阅读笔记4 修改密码 | 备份 | 模板 顾北清歌寒。

阅读文章《京东B2B业务架构演变》

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

京东 B2B 的用户群体主要分为 2 类，一类是大 B 用户、另一类是小 B 用户。比如联通、移动公司跟京东建立的采购关系，就是 B 平台的大 B 用户；如果有一家小超市需要在京东 B 平台上进行采购，那么它就是 B 平台的小 B 用户。

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

业务架构1.0

业务架构 1.0 分为 3 层：

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

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

• 存储层：使用 mysq l数据库进行存储

 该架构的表现为：

• 开发周期长，无法快速满足业务要求

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

• 系统之间耦合度大

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

• 服务问题

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

• 系统耦合

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

• 公用数据库问题

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

 （1）服务问题改进

• 第一步拆分，将各个业务线的的服务拆分成小服务。

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

 （2）系统耦合改进

系统耦合的问题，通过引入 jmq 消息中间件进行解决。消息无序的问题，采用乐观锁进行解决，主要是依靠数据的版本对比来解决。

（3）数据库改进

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

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

扩展：

• 还有那些分布算法方式：ID 区间算法、时间区间

• 热点数据：二次 hash

• 事务：弱化强一致性，采用消息的机制进行交互，实现最终一致性。

• 垮库查询：分布式查询

 业务架构2.0

在1.0的基础上，做如下三点调整：

• 服务层抽取公共服务

• 引入基础层的工具

• 存储层分库分表

业务架构3.0

 3.0的版本主要是修改，包含服务层的抽取、业务和 SOA 分离，同时引入业务和工具组件。

B2B业务架构经过3次变迁与升级，我们总结到以下经验：

1. 稳定性原则

2. 抽象化

3. 松耦合

4. 拆分

原文：https://www.cnblogs.com/wang-jx/p/11027312.html