10 应的服务数量不一致时，也会触发全量更新。 2)增量更新服务列表：在客户端已有缓存的前提下，通过定期比较得到本地缓存与注册中心缓存的差异 获取某个应用的服务信息。缓存定期更新的过程由后台线程的驻留任务执行（默认周期值为⑥）。 如图8所示，注册中心提供三级缓存机制用于同步服务列表，分别为可读可写表(registry)、读写缓存表 (readWriteCacheMap)、只读缓存表(readOnlyCacheMap),通过参数设置定期同步。可读可写表储存即时的 全部服务列表数据：读写缓存表保存最近被读取或写入的服务列表（默认保存时间为①），服务发现客户端每 读或写一条数据，可读可写表将这条数据即时写入读写缓存中：只读缓存表非即时更新，而是按配置周期从 可读可写缓存表中更新（默认周期值为②）。针对服务发现场景对于及时性和吞吐量的不同需求，客户端可选 择从读写缓存（默认配置③）或只读缓存（配置④）同步数据。 Eureka Server Web UI registry CHAINNODE00 UP (1)-shainNoco00 ⊙ RAILWAYTCKET UP (1)-Kanaxira SERVCE-ORDER UP 11.ocabo WEBSERVER UP (1)-locaf readWriteCacheMap ④ ② 5 ③ readOnlyCacheMap Eureka Cl RestTemplate 5 1 responseCacheAutoExpirationInSe 3)if useReadOnlyResponseCache= 5 registryFetchInterval =30s 6ribbon.serverListRefreshIpterval=30s 图8三级缓存同步机制示意图 Fig.8 Three levels of cache mechanism for replication 4.3 服务接口的请求绑定 请求绑定过程将协商完成的服务合约绑定到具体的传输协议上，与合约订立的“要约-承诺”过程相对应。 由消费方发送服务授权请求，授权结果由服务提供方发布到区块链上进行存证。服务提供方和消费方通过区 块链完成请求绑定后，在条款规定的服务要求内，服务提供方有义务提供按需服务，消费方有权利向服务提 供方发起服务请求。 通常情况下， 一次请求绑定过程由消费方发起，由提供方实现响应。目前的消息传输方式有RESTful、 RPC、消息中间件合种。RPC 传输数据格式通常为二进制格式，需要自定义协议格式：消息中间件虽然对异 步传输支持较好，但要单独部署服务端口，复杂度较高：而RESTful请求可采用封装了JSON格式的HTTP 报文，可读性与可分析性更强。综合考虑，本文将采取RESTful接口传输HTTP数据报文。 如图9所示，智能法律合约中的服务接口声明在请求绑定的过程中采用HTTP报文封装形式。将接口声 明中url字段与path字段映射为报文访问路径，将method字段映射为HTTP方法，将parameters字段映射为 报文中的访问参数，将responses字段映射为接收HTTP报文的返回值等。最终实现将服务消费过程绑定到基 于HTTP的请求响应行为中。10 应的服务数量不一致时，也会触发全量更新。 2）增量更新服务列表：在客户端已有缓存的前提下，通过定期比较得到本地缓存与注册中心缓存的差异 获取某个应用的服务信息。缓存定期更新的过程由后台线程的驻留任务执行（默认周期值为⑥）。 如图 8 所示，注册中心提供三级缓存机制用于同步服务列表，分别为可读可写表（registry）、读写缓存表 （readWriteCacheMap）、只读缓存表（readOnlyCacheMap），通过参数设置定期同步。可读可写表储存即时的 全部服务列表数据；读写缓存表保存最近被读取或写入的服务列表（默认保存时间为①），服务发现客户端每 读或写一条数据，可读可写表将这条数据即时写入读写缓存中；只读缓存表非即时更新，而是按配置周期从 可读可写缓存表中更新（默认周期值为②）。针对服务发现场景对于及时性和吞吐量的不同需求，客户端可选 择从读写缓存（默认配置③）或只读缓存（配置④）同步数据。 图 8 三级缓存同步机制示意图 Fig.8 Three levels of cache mechanism for replication 4.3 服务接口的请求绑定 请求绑定过程将协商完成的服务合约绑定到具体的传输协议上，与合约订立的“要约-承诺”过程相对应。 由消费方发送服务授权请求，授权结果由服务提供方发布到区块链上进行存证。服务提供方和消费方通过区 块链完成请求绑定后，在条款规定的服务要求内，服务提供方有义务提供按需服务，消费方有权利向服务提 供方发起服务请求。 通常情况下，一次请求绑定过程由消费方发起，由提供方实现响应。目前的消息传输方式有 RESTful、 RPC、消息中间件三种。RPC 传输数据格式通常为二进制格式，需要自定义协议格式；消息中间件虽然对异 步传输支持较好，但需要单独部署服务端口，复杂度较高；而 RESTful 请求可采用封装了 JSON 格式的 HTTP 报文，可读性与可分析性更强。综合考虑，本文将采取 RESTful 接口传输 HTTP 数据报文。 如图 9 所示，智能法律合约中的服务接口声明在请求绑定的过程中采用 HTTP 报文封装形式。将接口声 明中 url 字段与 path 字段映射为报文访问路径，将 method 字段映射为 HTTP 方法，将 parameters 字段映射为 报文中的访问参数，将 responses 字段映射为接收 HTTP 报文的返回值等。最终实现将服务消费过程绑定到基 于 HTTP 的请求响应行为中。 Client registry readOnlyCacheMap Web UI Eureka Client Eureka Server RestTemplate responseCacheAutoExpirationInSeconds = 180s responseCacheUpdateInterval = 30s if useReadOnlyResponseCache==true if useReadOnlyResponseCache==false registryFetchInterval = 30s ribbon.serverListRefreshInterval = 30s readWriteCacheMap 录用稿件，非最终出版稿