7 图4中完整描述了样例中“服务注册接口”和“提供方服务接口”的合约化声明。服务接口（图4左部） 采用Java语言编写，由SPESC定义的接口声明（图4右部）则由文档生成工具提取并转化为必要属性，转 化关系如图中箭头所示。接口声明中的必要属性包括：提供服务实例的地址与服务名(instances)、服务所接 收的路径(paths)及路径下接口所需参数(parameters)、动作类型(methods)及返回状态码(responses)等。 服务接口的声明格式参照OpenAPI3.0版本标准I8实施。依据对服务接口的实际要求，合约当事人可协商添 加原本服务接口描述中所没有的权属(rights)和必要的计费字段(pice)等。基于上述合约化声明，提供方 将添加接口描述后的合约范本与服务注册信息一并发送给注册中心，进而推广给服务消费方。 3.3服务注册合约条款 在合同层面上，服务提供方（甲方）的注册过程应视为向服务交易平台（丙方）发起委托请求的过程，丙 方的发布过程应视为接受甲方委托请求的过程。甲方与丙方之间这种服务注册发布程的权利与义务关系使 用如图5所的示条款进行规定。条款ol分为2个子条款，分别由甲方和丙方不以美施。子条款ol1规定 服务注册请求由甲方提交，其中所含的服务注册信息应包括：服务域名地址与端口、服务接口路径、生成时 间戳、状态检查接口信息、以及被添加在自定义信息(metadata)中的合约范2 子条款ol2规定丙方实施 注册动作的义务，包括： ©@条款1：甲方作为委托方，向丙方发送服务注册请求，丙方有义务为伊方发布提交注册的服务。 term nol 1:Provider can Commit(Service). term nol 2:Platform must Register(Service) when Provider did Commit(Service) while grant Service::useRight to Platfom where response::code is 204. 图气服务注册条款 Fig.5 Term of service registration 1) when语句：指示前置条件，用于检查甲方服务信息是否已经提交。 2)wile语句：指示伴随动作，用于为丙方添加服务的使用权，以保证平台对服务功能进行测试和提供 消费方试用的权利。 11 3) where语句：指示后置条件，用矛检查注册后的服务状态。 在when语句中，防止重复注册的源理是键-值表中的每个键只对应一条服务实例信息，不允许重复。服务提 供方提交服务的操作过程中如果之尖败，合约引擎会回滚操作，以保证下次条款前置条件检查依旧会判定 动作未执行。在where语句，由丙方调用状态检查(healthCheck)函数访问甲方提供的地址，如果注册成功 则返回成功状态码（即前述定义code:204)。 若服务通过条款01的全部检查过程，则丙方将发布服务，完成服务注册与发布阶段。服务注册过程隐 含的权利义务关系是服务提供方将服务授权给服务平台，平台接收委托则有义务为其推广销售。服务提供方 与注册中心的交互与状态转移过程的技术点在下一节表述。 3.4服务注册交互与状态转移 服务注册中心的任务是通过交互动作维护服务提供方微服务的注册信息，交互动作按发起方的不同可分 为微服务主动发起和注册中心自行发起两大类。微服务能主动发起的动作有四种，分别是注册(Register)、心 跳连接(Renew)、状态更新(StatusUpdate)、取消(Cancel),四种交互动作以HTTP报文格式封装。 注册中心能自行发起的动作有两种，分别是心跳续约超时(Expire)和定期清理(Evict).。在原有的Eureka 模块中，注册中心还记录微服务的四种状态，包括服务启动(Starting)、服务上线(Up)、异常掉线(Out-Of Service)、服务下线(Dowm)。如图6(a)所示，结合上述6种交互动作和4种微服务状态，对服务状态转移流7 图 4 中完整描述了样例中“服务注册接口”和“提供方服务接口”的合约化声明。服务接口（图 4 左部） 采用 Java 语言编写，由 SPESC 定义的接口声明（图 4 右部）则由文档生成工具提取并转化为必要属性，转 化关系如图中箭头所示。接口声明中的必要属性包括：提供服务实例的地址与服务名（instances）、服务所接 收的路径（paths）及路径下接口所需参数（parameters）、动作类型（methods）及返回状态码（responses）等。 服务接口的声明格式参照 OpenAPI 3.0 版本标准[18]实施。依据对服务接口的实际要求，合约当事人可协商添 加原本服务接口描述中所没有的权属（rights）和必要的计费字段（price）等。基于上述合约化声明，提供方 将添加接口描述后的合约范本与服务注册信息一并发送给注册中心，进而推广给服务消费方。 3.3 服务注册合约条款 在合同层面上，服务提供方（甲方）的注册过程应视为向服务交易平台（丙方）发起委托请求的过程，丙 方的发布过程应视为接受甲方委托请求的过程。甲方与丙方之间这种服务注册发布过程的权利与义务关系使 用如图 5 所的示条款进行规定。条款 no1 分为 2 个子条款，分别由甲方和丙方予以实施。子条款 no1_1 规定 服务注册请求由甲方提交，其中所含的服务注册信息应包括：服务域名地址与端口、服务接口路径、生成时 间戳、状态检查接口信息、以及被添加在自定义信息（metadata）中的合约范本。子条款 no1_2 规定丙方实施 注册动作的义务，包括： 图 5 服务注册条款 Fig.5 Term of service registration when 语句：指示前置条件，用于检查甲方服务信息是否已经提交。 while 语句：指示伴随动作，用于为丙方添加服务的使用权，以保证平台对服务功能进行测试和提供 消费方试用的权利。 where 语句：指示后置条件，用于检查注册后的服务状态。 在 when 语句中，防止重复注册的原理是键-值表中的每个键只对应一条服务实例信息，不允许重复。服务提 供方提交服务的操作过程中如果产生失败，合约引擎会回滚操作，以保证下次条款前置条件检查依旧会判定 动作未执行。在 where 语句中，由丙方调用状态检查（healthCheck）函数访问甲方提供的地址，如果注册成功 则返回成功状态码（即前述定义 code: 204）。 若服务通过条款 no1 的全部检查过程，则丙方将发布服务，完成服务注册与发布阶段。服务注册过程隐 含的权利义务关系是服务提供方将服务授权给服务平台，平台接收委托则有义务为其推广销售。服务提供方 与注册中心的交互与状态转移过程的技术点在下一节表述。 3.4 服务注册交互与状态转移 服务注册中心的任务是通过交互动作维护服务提供方微服务的注册信息，交互动作按发起方的不同可分 为微服务主动发起和注册中心自行发起两大类。微服务能主动发起的动作有四种，分别是注册（Register）、心 跳连接（Renew）、状态更新（StatusUpdate）、取消（Cancel），四种交互动作以 HTTP 报文格式封装。 注册中心能自行发起的动作有两种，分别是心跳续约超时（Expire）和定期清理（Evict）。在原有的 Eureka 模块中，注册中心还记录微服务的四种状态，包括服务启动（Starting）、服务上线（Up）、异常掉线（Out-Of￾Service）、服务下线（Down）。如图 6(a)所示，结合上述 6 种交互动作和 4 种微服务状态，对服务状态转移流 @@条款 1：甲方作为委托方，向丙方发送服务注册请求，丙方有义务为甲方发布提交注册的服务。 term no1_1：Provider can Commit(Service). term no1_2：Platform must Register(Service) when Provider did Commit(Service) while grant Service::useRight to Platform where response::code is 204. 录用稿件，非最终出版稿