We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
支持配置基于 RPC 请求的数据源容器。具体来说,我们可以通过 SpringMVC 暴露一个 Controller 接口,比如:
@RestController @RequestMapping("/${path}") public Crane4jRpcController { @PostMapping public Result<Map<Object, Object>> queryFromContainer(@RequestBody Crane4jRequest req) { // return datas } } @Data public class Crane4jRequest { private String provider; // 数据源容器的 provider private String container; // 数据源容器的 namespace private Collection<Object> keys; // 键值 private Class<?> keyType; // 键值类型 }
然后,我们可以在 A 服务中直接跨服务从 B 服务中的容器获取数据:
@Data public class Example { @AssembleRpc( service = "example-service", // 服务名,或者固定的 IP containerProvider = "xxx", // 要引用的容器的 provider container = "foo", // 要引用的容器的 namespace props = { "a:b", "c:d" } ) private Collection<Object> keys; }
对应此类请求,我们需要考虑如何最大程度的复用用户项目已有的服务发现或者负载均衡组件,如果可以的话,考虑直接基于常用的 RPC 框架(比如 Dubbo 或 OpenFeign)实现此功能。
此外,我们可以为此提供一个特殊的 ContainerProvider,它应当根据服务名或 URL 提供一个数据源容器,该容器基于动态代理生成,调用它的时候它会在底层发起 RPC 请求获取数据。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
支持配置基于 RPC 请求的数据源容器。具体来说,我们可以通过 SpringMVC 暴露一个 Controller 接口,比如:
然后,我们可以在 A 服务中直接跨服务从 B 服务中的容器获取数据:
对应此类请求,我们需要考虑如何最大程度的复用用户项目已有的服务发现或者负载均衡组件,如果可以的话,考虑直接基于常用的 RPC 框架(比如 Dubbo 或 OpenFeign)实现此功能。
此外,我们可以为此提供一个特殊的 ContainerProvider,它应当根据服务名或 URL 提供一个数据源容器,该容器基于动态代理生成,调用它的时候它会在底层发起 RPC 请求获取数据。
The text was updated successfully, but these errors were encountered: