整体介绍

1.1. 设计目标

用于规范应用之间行为表达方式和对结果的预期。

• 对于服务提供方来讲，通过服务标准化，能够清晰而简洁的表达本服务提供了哪些接口、定义、以及他们所应实现的具体功能，并且任何对该服务所提供的能力有依赖的应用，都必须按照这套接口来实现服务供应；

• 对于服务依赖方来讲，（即使用该服务的应用）能够清晰而简洁的表达他所依赖的接口有哪些，分别期望这些接口完成什么样的具体功能，并且任何为其提供服务的应用，只要遵循相同的服务模型，即可实现服务提供方的替换。

1.2. 概念定义

对服务模型的定义，如下几点说明：

1. 服务即接口。我们这里定义的服务，从概念上理解，这是一个对应用能力的抽象表达；但是从实际操作层面，服务的实际体现方式，就是RESTful风格的HTTP接口。

2. 接口是分组的。分组的原则是能力原子化，即我们按照接口的能力范围，将一组完成功能闭环的接口标定为一组。并且，我们将这一组接口，定义为“一个服务模型”。

3. 服务模型是受管控的。目前，每一个服务模型都是由行业小二在后台制定并发布。ISV在实践过程中可以根据实际情况，向相关小儿提出调整意见。

4. 服务模型是有版本的。一个基础服务模型，随着不用ISV、不同场景的需求，会有版本迭代。因此，唯一确定一个服务模型提供的接口信息的，是模型ID+版本。

服务管控流程

服务模型的管理

服务模型的定义，是由平台统一管控的。ISV在应用开发和实践中，如果需要修改或者全新定义服务模型，请联系相关人员。

服务模型的声明

模型的声明分两个角度：服务模型的依赖和服务模型的提供。一个应用在正式上架前，需要声明该应用所提供的服务和所依赖的服务。模型的声明入口，见下图：

1. 服务的依赖配置

如下图所示：

上图中显示，服务的依赖，是需要指定到模型下面的某一个或者多个接口的。进入配置页面，如下：

2. 服务的提供配置

如下图所示：

图中，需要用户指定的，除了模型之外，还有指定模型版本和提供该服务能力的节点，如上红色区域。

服务模型的调试

应用开发完成之后，如果应用依赖或者提供服务模型的能力，那势必需经过集成调试，方可上架。应用的调试分成两类：服务依赖的调试、服务提供的调试。

1. 服务依赖的调试

当应用依赖一个服务时，它的调试过程需要有一个虚拟的服务提供者来为该应用提供服务，并且监测每一次应用的服务调用。

2. 服务提供的调试

当应用提供一个服务时，它的调试过程需要有一个虚拟的客户端，来发起对该应用该服务的调用，并且监测每一次应用的服务调用。

首先，进入AppKey-> 查看，指定要调试的服务，并启动客户端，启动之后界面如下：

启动之后，ISV就可以进入每一个接口，模拟该接口像当前应用发起服务调试了。用户可以在调试界面看到服务调用的数据：