Java Chassis 3 技术解密:与 Spring Cloud 的互操作
作者:刘宝
原文链接:Java Chassis 3技术解密:与Spring Cloud的互操作-云社区-华为云
Java Chassis 3 一个很重要的设计原则:利用架构的韧性设计来解决兼容性问题。
比如通过引入微服务网关,来解决不同语言、不同框架、遗留系统之间的互操作问题。 本文在这个架构原则基础上,讨论一个更加细粒度的互操作问题,并借此解密 Java Chassis3 在运行时设计依赖上的技术细节。
首先,我们描述一个互操作的场景和假设。
Spring Cloud 和 Java Chassis 应用同时注册到注册中心。引入了 Spring Cloud Gateway 作为网关,网关也注册到注册中心。
Spring Cloud 微服务和 Java Chassis 微服务相互调用。它们彼此作为消费者的时候,不需要感知对方是不同的框架,做到透明调用。
从技术原理上梳理下上述互操作需要满足的条件:
Spring Cloud 和 Java Chassis 需要有相互认识的注册信息。核心包括:应用名称、服务名称、地址信息和格式等。 需要的共同注册中心越少,越容易对注册中心和客户端进行选型。 在本例子中,我们选择
Service Center
或者Nacos
作为注册中心,并选择 Spring Cloud Huawei 实现 Spring Cloud 注册。Spring Cloud 访问 Java Chassis,只需要一个地址信息,依赖较少。 Java Chassis 访问 Spring Cloud,需要知道 Spring Cloud 应用提供的契约信息。
Java Chassis 区别于 Spring Cloud 的 REST 调用的部分,就是契约依赖。 Spring Cloud 通过 FeignClient 来声明客户端契约,客户端都需要在 FeignClient 中重复书写 REST 标签;Java Chassis 有两种模式发现契约:从注册中心发现和从 Provider 实例发现。 Java Chassis3 默认采用从 Provider 实例发现, Java Chassis2 采用从注册中心发现。 从 Provider 发现的好处是可以降低对于注册中心元数据管理能力的要求,本例既可以采用 Service Center
作为注册中心,也可以选择 Nacos
作为注册中心。
从 Provider 发现,要求 Provider 实现如下接口:
它包含一个健康检查接口和一个查询契约的接口。 当 Spring Cloud 应用实现上述接口以后,它就具备了 Java Chassis 微服务需要的基础特征,这样 Java Chassis 就可以像访问本框架的微服务一样访问 Spring Cloud 框架开发的微服务应用。 为了简化,在 Spring Cloud 简单实现了该接口,该实现接口从 export
目录加载契约信息,只需要将 Spring Cloud 需要对外暴露的 REST 接口的符合 Open API 3.0 规范的契约文件放到这个目录下面 。
Java Chassis 与 Spring Cloud 互操作的例子放到了ServiceComb Samples , 这个例子也提供了使用 Nacos 作为注册中心和配置中心的实现, 只需要将 Profile 设置为 Nacos 即可。
客户故事:在架构选型变化的时候,解决功能迁移和兼容性问题是最大的挑战。一些客户将 Spring Cloud 应用改造为 Java Chassis 的过程中,发现一些功能不支持,比如 SseEmitter、WebSocket 等。 如果选择支持这些能力,Java Chassis 需要实现很多 Servlet 能力,这些能力规划会和微服务技术架构存在冲突。 对于这些场景,我们选择通过架构韧性来保留这些功能,比如将提供 SseEmitter、WebSocket 功能的独立出微服务,采用 Spring Boot 开发,这些应用可以通过调用 Java Chassis 微服务的 REST 接口来实现其特殊功能。通过这种架构韧性的理念,降低了技术持续演进的包袱,为敏捷迭代,持续创新奠定了方向,减少了兼容性问题的争论。
评论