商品库存是电商的核心数据，有数十个业务系统调用，大促时每天调用数十亿次，往往在数百台虚拟机/容器上部署，提供水平扩展，具体架构如下：

库存微服务化设计有很多好处：

统一业务规则

库存的计算规则很复杂，不同业务场景看到的库存数量都不一样，库存微服务通过提供唯一的库存访问入口，统一对库存相关规则进行封装，直播，方便各个业务场景使用，如果库存规则有变化，变化也局限于库存微服务内部，外部业务代码保持不变。

一致数据模型

库存微服务只访问库存相关的四张表，它不访问外部库表，也不允许外部应用直接访问这几张表，收敛了对这些表的访问入口，避免各个业务直接往表里加字段，导致数据模型混乱。

此外，这些表独立成库，再加上只有库存服务访问，数据库连接数可以大大减少，避免数据库连接数不够。

各种内部优化

库存微服务汇总所有读写接口，内部可以做各种优化。比如缓存，由于所有写场景都在这里，可以通过写后马上更新方式，保证缓存的实时一致性。所有读场景也在这里，可以通过合理设计，一个缓存满足多个读场景需求，提升缓存使用效率。

库存的变化是非常重要的系统状态变化，库存微服务在各个库存变化点，提供库存变化消息通知，以统一的消息命名方式和消息格式，保证相关方能够方便地接收库存消息。

水平扩展

库存服务每天访问量很大，通过微服务方式可以很方便地水平扩展，服务本身是部署在标准的虚拟机或容器内，通过云的方式可以动态收缩和扩容，1号店在大促的时候，就经常以租用公有云服务器的方式实现服务能力扩展。

大家可以看到，微服务很适用业务高度复杂、业务共享性高、并发量大的场景，在电商，类似的场景还有订单/商品/用户/价格/支付等等，我们可以围绕这些细分概念构造微服务。

　　微服务体系

随着服务的不断构建，一个完整的微服务体系如下图所示：

最底下是基础系统的服务，这些服务实现对底层系统功能的封装，供之上各个业务使用，如短信/消息/存储等服务，上层服务无需关注底层资源的物理位置和内部细节。

之上的共享服务基于细分主题，封装企业各个维度的核心数据资源和业务规则，偏下层产品/用户/订单等都是主数据，共享性更强，偏上层的积分/抵用券/发票等，为某几个业务系统所使用，规则相对也更简单。

系统服务为企业整体系统提供基础技术平台，共享服务提供基础业务平台，两者一起奠定企业信息系统的基础。最上面的业务服务基于两大基础平台，面向具体的业务系统提供服务。

在这里，服务形成了明确的分层，调用规则如下：

上层可以调用下层，比如共享服务调用系统服务，也可以跨层调用，比如业务服务直接调用系统服务。

同层方面，业务服务可以互相调用，组成更粗粒度服务，共享服务和系统服务都是细分服务，相互之间垂直正交，不允许相互调用。

通过服务细分和服务分层，微服务的职责定位明确，依赖关系清晰，总体上，整个系统变成层次化的依赖，而不是网状依赖。

　　微服务系统架构

下图是一个大型B2C电商系统实际的架构，上层是各种业务应用，底层是大量服务，并且服务分为应用服务（面向业务）和基础服务（面向共享主题），一个非常典型的微服务架构。