详解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实现如下接口：

/**
 * Java Chassis internal management apis.
 */
@Path("/scb/management")
public interface ManagementEndpoint {
  String NAME = "scb-management";

  /**
   * Health of this instance. If the instanceId match this instance, and this service is ready
   * to service return true. Otherwise, return false.
   *
   * This api is for internal instance status usage. Load balancer will call this api to check if
   * the target instance is alive.
   */
  @GET
  @Path("/health")
  boolean health(@QueryParam("instanceId") String instanceId, @QueryParam("registryName") String registryName);

  /**
   * Schemas of this instance.
   *
   * This api is for internal schema loading usage.
   */
  @POST
  @Path("/schema/contents")
  Map<String, String> schemaContents();
}

它包含一个健康检查接口和一个查询契约的接口。 当Spring Cloud应用实现上述接口以后，它就具备了Java Chassis微服务需要的基础特征，这样Java Chassis就可以像访问本框架的微服务一样访问Spring Cloud框架开发的微服务应用。 为了简化，在Spring Cloud简单实现了该接口，该实现接口从 export 目录加载契约信息，只需要将Spring Cloud需要对外暴露的 REST 接口的符合 Open API 3.0规范的契约文件放到这个目录下面 。