文档

能力介绍

更新时间:
一键部署

基于服务总线,提供应用间的服务集成能力。

整体介绍

1.1. 设计目标

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

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

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

1.2. 概念定义

对服务模型的定义,如下几点说明:

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

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

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

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

服务管控流程

流程

服务模型的管理

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

服务模型的声明

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

1

1. 服务的依赖配置

如下图所示:

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

3

2. 服务的提供配置

如下图所示:

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

服务模型的调试

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

1. 服务依赖的调试

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

5

2. 服务提供的调试

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

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

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

7

  • 本页导读 (0)
文档反馈