如何统一服务调用框架?
【线上直播】11月21日晚8点贝壳技术总监侯圣文《数据安全之数据库安全黄金法则》
目前Spring Cloud和Dubbo体系发展都比较成熟,不少客户已有一些采用它们开发的系统。好的微服务开发平台需要支持这两种体系。统一开发体验和降低开发复杂度的同时,保留两种体系各自的优势。
现有企业IT架构
服务调用场景 IT企业根据不同系统有不同的现状和技术发展路线。针对新系统,采用优先常用的Spring Coud应用调用Spring Cloud应用或Dubbo应用调用Dubbo应用。 但是针对已有系统进行架构调整改造,即如有系统A是Spring Cloud体系,想新增或者改造一些服务为Dubbo形式,反之亦然,就会出现2、4的混合服务调用场景,这类场景主要是通过兼容来保证平滑升级过度。 基于使用场景推论,原有系统可能是Spring Cloud或者是Dubbo,所以服务注册中心需要支持Eureka和Zookeeper,调用协议需要支持Http(Restful)或RPC协议。 运行逻辑可以拆分以下几段:
定义期决定运行的过程 服务类型是针对具体的服务提供类型为Spring Cloud(Restful)服务还是Dubbo(RPC)服务,提供对应的服务契约(完整的服务描述Swagger)。 注册中心类型就是基于启动依赖和配置项,决定连接的注册中心具体为Eureka还是Zookeeper,提供对应的服务发布格式(注册中心存储的服务格式)。 服务类型决定应用、包、接口类型定义的优先级依次递增,即如果都有配置时,以接口配置为准。服务类型的切换,可以通过配置文件的修改调整,无需调整代码。 服务提供和服务调用的关键逻辑: 1. 根据配置,扫描EOSService接口。 2. 判断服务提供类型,包含多层级优先级判断,确定服务提供类型。 a ) Dubbo类型:仿照Dubbo本身服务发布的形式,注册Dubbo bean实例 b ) Spring Cloud类型:根据约定发布对应Restful服务(因为为方便开发采用声明式调用,所以需要平台约定如url、type等规则) 3. 判断服务调用类型,包含多层级优先级判断,确定服务调用方式。 a ) Dubbo类型:仿照Dubbo本身服务发布的形式,注册Dubbo bean实例 b ) Spring Cloud类型:根据约定注册Feign bean。调用时,通过Feign调用服务。 注册中心根据如上依赖项决定,启动bean加载不同。不同的注册中心保留的服务发布时机和格式有不同。 同体系的注册中心因为需要对接已有系统,所以服务发布格式都延用同体系内容,如Spring Cloud服务发布到Eureka,和Dubbo服务发布到Zookeeper中的服务格式同原有系统其他服务,不做特殊处理。 服务发布和服务获取的关键逻辑: 1. 根据依赖项,启动不同注册中心初始化过程。 2. 判断注册中心类型,替换服务注册实例。 a ) Zookeeper类型:启动Zookeeper注册和监听实例,根据服务提供类型,组织服务发布格式到Zookeeper节点(具体格式后面有示例)。 b ) Eureka类型:Spring Cloud同原有,Dubbo服务通过异步扫描,放置到对应的扩展属性。 3. 判断注册中心类型,替换服务实例获取方式。 a ) Zookeeper类型:启动Zookeeper注册和监听实例,根据服务提供类型,从 Zookeeper节点获取并解析服务格式(具体格式后面有示例)。 b ) Eureka类型:Spring Cloud同原有,Dubbo服务通过监听Eureka 扩展属性。 Spring Cloud服务的发布格式在Zookeeper中存储如上图,在Zookeeper中新增/spring-cloud-service目录,记录Spring Cloud服务访问所需要的要素。 (编辑:ASP站长网) |