目前SpringCloud和Dubbo系统的开发都比较成熟，很多客户已经采用了他们开发的一些系统。一个好的微服务开发平台需要同时支持这两个系统。在统一开发体验、降低开发复杂度的同时，保留了两个系统各自的优势。现有企业IT架构服务调用场景IT企业根据不同的系统有着不同的现状和技术发展路线。对于新系统，使用常用的SpringCoud应用调用SpringCloud应用或者Dubbo应用调用Dubbo应用。但是，对于现有系统的结构调整和改造，即如果系统A是一个SpringCloud系统，你想增加或改造一些服务到Dubbo的形式，反之，就会有2和4混合服务调用场景。主要是通过兼容性来保证平滑的升级过渡。根据使用场景，原系统可能是SpringCloud或者Dubbo，所以服务注册中心需要支持Eureka和Zookeeper，调用协议需要支持Http（Restful）或者RPC协议。运行逻辑分为以下几个部分：服务提供者可以根据配置项提供SpringCloud（Restful）和Dubbo（RPC）协议的具体服务。服务提供者根据提供的服务协议类型将它们转换成相应的服务。契约，注册到Eureka和Zookeeper服务消费者从Eureka和Zookeeper获取服务注册信息，根据服务契约解析更方便人员开发应用，调用实现以服务类型区分。分别使用Feign，Dubbo使用自己的实现，可以有效支持已有的系统调用，降低学习成本。独立的注解可以统一和规范开发，控制平台调用规则处理需要提供和消费的接口。服务类型控制应用是服务提供者还是服务消费者，可以在同一个应用中支持双服务系统和双消费系统。灵活配置业务系统规则，方便根据需要调整业务系统。比如整体应用是SpringCloud，新增的提供和消费服务都是Dubbo，那么这些新增的服务可以作为Dubbo系统规则在原来的配置中添加。在定义期间，针对具体的服务类型判断运行进程服务类型是SpringCloud（Restful）服务还是Dubbo（RPC）服务，并提供相应的服务契约（完整的服务描述Swagger）。注册中心类型是根据启动依赖和配置项来判断要连接的注册中心是Eureka还是Zookeeper，并提供相应的服务发布格式（注册中心存储的服务格式）。服务类型决定了应用、包、接口类型定义的优先级从小到大的顺序，即如果所有配置都存在，则以接口配置为准。服务类型的切换可以通过修改配置文件来调整，无需调整代码。服务提供和服务调用的关键逻辑：1.根据配置，扫描EOSService接口。2、确定提供服务的类型，包括多级优先级判断，确定提供服务的类型。a)Dubbo类型：遵循Dubbo自身服务发布的形式，注册Dubbobean实例b)SpringCloud类型：根据协议发布对应的Restful服务（因为声明式调用是为了方便开发，平台协议等如需要url,type等规则）3.判断服务调用类型，包括多级优先级判断，判断服务调用方式。a)Dubbo类型：按照Dubbo自身服务发布的形式，注册Dubbobean实例b)SpringCloud类型：按照约定注册Feignbean。调用时，通过Feign调用服务。registry是根据上面的依赖决定的，启动bean的加载是不同的。不同注册管理机构保留的服务的发布时间和格式不同。同一系统的注册中心需要对接已有系统，所以服务发布格式继续使用相同的系统内容，比如SpringCloud服务发布到Eureka，Dubbo服务发布到Zookeeper的服务格式与原系统的其他服务相同。特别待遇。服务发布和服务获取的关键逻辑：1.根据依赖关系启动不同注册中心的初始化过程。2、判断注册中心类型，更换服务注册实例。a)Zookeeper类型：启动Zookeeper注册和监控实例，根据服务提供类型组织服务发布格式到Zookeeper节点（具体格式后面有示例）。b)Eureka类型：SpringCloud和原来一样，异步扫描Dubbo服务，放入对应的扩展属性中。3、判断注册中心类型，更换服务实例获取方式。a)Zookeeper类型：启动Zookeeper注册和监控实例，根据提供的服务类型从Zookeeper节点获取并解析服务格式（具体格式后面有示例）。b)Eureka类型：SpringCloud和原来一样，Dubbo服务监听Eureka扩展属性。SpringCloud服务的发布格式如上图存储在Zookeeper中，在Zookeeper中增加/spring-cloud-service目录，用于记录SpringCloud服务访问所需的元素。<元数据>
