举一个电商的例子，这里有两个应用，顾客使用的商品详情页，展示商品的信息、商品库存，商品价格；下单页供顾客下单，涉及商品查询、库存扣减、生成订单等。

页面应用和服务关系如下图所示：

商品详情服务主要面向商品详情页提供数据接口，包括商品基本信息、价格信息、库存信息，接口经常根据页面需要，聚合这几部分信息，提供粗粒度服务，服务底层自由访问所需要的表。

订单服务主要面向下单页，其中商品信息可以通过商品详情服务获取，无需单独访问库表。而对于库存，这里是扣库存场景，需要自己访问库存表，订单信息也是如此。

面向业务系统的服务设计是比较直接的，每个服务针对自己的“主应用”提供粗粒度服务，总体上看应用/服务/库表是多对多的关系，如果服务设计得不好，容易导致整体网状依赖，修改时，往往牵一发动全身。此外对于新业务，需要单独构建对应的服务，不利于业务创新。

2. 面向细分主题服务

面向特定主题/概念/要素构建细分服务，最终服务于该主题相关的所有业务场景，比如围绕用户构建用户服务，对外供所有需要用户信息的业务系统访问，内部只访问用户相关的几张表，结构如下图所示：

面向细分主题的服务对数据是独占式访问，不允许其它服务访问自己的表，也不访问外部的表，更好地实现对该主题相关的业务规则和底层数据的封装。

3. 面向基础系统服务

面向基础系统服务屏蔽底层硬件的访问细节，以更友好更透明地方式对外提供访问，如短信服务、储存服务、缓存服务等。我们一直讲软件即服务，现在更进一步，硬件也是服务。

通常面向基础系统服务通过底层系统的集群或多路由，提供更可靠，更强处理能力的服务。

　　深入微服务

微服务概念是Martin Fowler在2014年抛出，文中给出微服务的一系列特征，但并没有给出准确定义。大家分别有自己的理解，还没有共识，基于本人的服务化实践，我觉得微服务有两大思想。

1. 简单连接

通过传统SOA方式连接客户端和服务端，是非常痛苦的，涉及传统很重的通讯协议(DCOM/RMI/CORBA/WebService等)和复杂的数据格式(二进制/XML等)。在连接通道方面，微服务很轻，一般采用轻量级的通讯协议（如HTTP）和简单数据格式（如JSON）。

微服务无需中心节点提供复杂处理，特别是业务相关的处理，把业务的职责还给服务端，更灵活地响应业务变化。微服务构建好后，应该象水电煤一样到处可用，没有技术障碍，不同语言都可以互相调用。

2. 分散管理

分而治之是处理复杂问题的有效手段，微服务对系统拆分尤为彻底，在多个方面实现对系统的分散管理：

分散业务

微服务聚焦细分业务领域，是对应业务规则的唯一入口，它把整体业务分割成一个个高内聚的小业务，简化业务之间依赖关系。

分散数据

微服务独占式访问对应的数据，服务和数据是一体的。它把整体数据分割成一块块数据，数据块内部的表紧密相关，块间数据相关性弱。在实施层面，每部分数据独立schema，逻辑上分离，或者使用独立数据库，物理上隔离。

分散物理资源

借助虚拟机和容器技术，一台物理机可以切分为多套环境，非常适合微服务部署，对服务器资源更高效地利用，同时有些微服务面向基础硬件封装，提升了对物理资源的管理。

我们可以看到，传统的基于ESB的服务不属于微服务范畴，它既不体现简单连接，也不体现分散管理（ESB甚至通过流程编排对业务集中管理）。相对于传统重的SOA服务，新型SOA，无论是面向业务系统服务，面向细分主题服务，面向基础系统服务都符合简单连接的特性，因此都可以算微服务的范畴。

特别地，面向细分主题服务很好体现业务和数据的分散管理，直播，面向基础系统服务很好体现物理资源的分散管理，因此这两者更好地满足微服务思想，是更纯粹的微服务。

这里是一个电商库存微服务的实例，希望帮助大家深入了解微服务，大型B2C电商的库存概念比较复杂，包括：

物理库存（仓库里的实际库存）

虚拟库存（仓库里没有，但可以假装有，先拿出来卖，比如新版iPhone预售）

活动库存（总库存里拿出一部分做活动，提供优惠价格促销）

共享库存（北京的库存可以共享出来，放到上海卖）

冻结库存（库存暂时被冻结部分，比如已下单但未发货，此时前台不可卖）

对于前台来说，用户可看到的库存计算规则如下：

可售库存=本地库存（实际-冻结）+虚拟库存（虚拟-冻结）+兄弟仓库共享库存(共享-冻结）

对于具体活动场景来说，可售库存的规则不一样，它等于活动库存。