Java sdk design

[seeflood]

Java sdk design

1. Java API spec

Layotto API是想设计一套中立的grpc/http API spec，如果搞一层自己的sdk API，那用户其实还是被Layotto绑定了。
如果能有一套中立的java API，更利于用户使用、移植，更便于推广。 见讨论#188

1.1. 调研：能否复用业界已有的事实标准

如果我们自己定义一套类似于slf4j的java api spec，最大的问题是：java微服务生态已经被spring 垄断了，spring的编程界面（各种注解）已经是事实意义上的java api spec了，这意味着我们其实是在另起炉灶做同样的事情。
比如spring cloud有一个注解，spring-cloud-alibaba、spring-cloud-netflix纷纷来实现它，那么这个注解已经是事实意义上的java api spec。

所以希望尽量复用事实标准API，而不是自己定

1.1.1. 依赖Spring Cloud还是Spring Boot？

调研发现，很多微服务相关的Java API spec都是Spring Cloud生态的，比如用于pubsub的Spring Cloud Stream项目，其设计目标是作为MQ的中立API，让用户用同一套API和注解对接不同MQ。

可现实世界中，很多用户的项目只依赖了SpringBoot、没有依赖Cloud（比如SOFAStack的项目），所以Layotto sdk依赖Spring Cloud的东西不合适。

1.1.2. Spring Boot生态有没有Java API spec

只有配置相关的注解和API，别的没有

1.2. 方案

可以起多个模块：

• Layotto-sdk
  • API尽量和Dapr SDK一样，可以把https://github.com/reactivegroup/cloud-runtimes-jvm 的API粘贴过来
• Spring-boot-layotto
  • 注解定义尽量和Dapr SDK一样
• Spring-cloud-layotto （优先级不高)
  • 基于Spring cloud生态的各种注解

功能	Layotto-sdk	Spring-boot-layotto	Spring-cloud-layotto
pubsub	同Dapr	Dapr设计的比较奇怪，见下	复用Spring Cloud Stream。该项目定义了一套抽象，比较复杂
configuration		@value等注解

解释：

1.2.1. pubsub

1.2.1.1. Layotto-sdk

Dapr的sdk全是reactor编程模型：

我们可以支持这种API，同时扩展非reactor的模型

1.2.1.2. Spring-boot-layotto

订阅

Dapr的订阅注解是@Topic

这个注解的一些问题：

• Dapr实现的时候限制该注解只能加在controller方法上
• 看名字看不出来是发布还是订阅

我们可以也叫@Topic，但是实现时候支持加在任何方法上,不一定非得加在controller的方法上。

发布

Dapr的发布是命令式的：

其实发布也可以加个注解，我们可以先搞命令式，后续加上注解

2. 用户如何扩展

现实世界中大部分Legacy system都有自己的编程模型、自己的API、自己的注解，我们的sdk要支持用户扩展，让用户能够把Legacy system迁移到Layotto sdk上来。

2.1. 依赖关系

• 启动时的初始化顺序是用户自定义包先初始化，然后再初始化开源包；
  开源的bean都允许覆盖：
  

• Spring-boot-layotto包在启动初始化的时候预留扩展点，让用户可以扩展、可以加上自己的注解等

比如某公司内部原先的编程模型是订阅加 @XXXSubscriber,而Layotto的订阅注解是@Topic,我们不可能让人家把原先的代码全改掉，允许用户做适配，把@XXXSubscriber作为@Topic的别名

[kevinten10]

在client端我们是否只提供gRPC的实现呢，还需要考虑HTTP/1.1吗？

dapr-java-sdk提供了gRPC和HTTP两种实现

[seeflood]

在client端我们是否只提供gRPC的实现呢，还需要考虑HTTP/1.1吗？

dapr-java-sdk提供了gRPC和HTTP两种实现

Layotto现在只支持grpc，但是有位同事在开发支持http的功能（通过网关，把http请求转成grpc协议，类似etcd的实现），还没提pr
所以现在sdk只支持grpc，得等Layotto支持了http，sdk才能支持http。
不过个人觉得java/go sdk支持http的优先级不高，因为感觉想不到用了sdk还用http的场景，应该只有iot、边缘计算等场景？这些场景是不是用go和java语言的比较少，适合在c sdk里支持http?

[kevinten10]

@seeflood 你在写java-sdk的grpc实现吗，我会基于你的提交并参考dapr-java-sdk中的grpc实现，进行提交

[seeflood]

@seeflood 你在写java-sdk的grpc实现吗，我会基于你的提交并参考dapr-java-sdk中的grpc实现，进行提交

@kevinten10 对，我在写java sdk里（非reactor部分的）代码，用来给Alipay的用户用，这部分interface和你pr里的不太一样

所以我们协作的话，可以我先搞命令式编程的部分，你不用等我、先写reactor API编程的部分（我不太懂reactor API哈哈）你看可以不
但是有个问题，我们想支持java8用户，像Dapr那样要求很高的Jdk很难在国内推广

[kevinten10]

好的啊

使用reactor编程主要为了支持异步非阻塞模式的调用，命令式编程部分是先只考虑同步阻塞的调用模式吗？

其实也可以在sdk内部使用reactor编程模型，在暴露给用户时，可以提供reactor的API和命令式的API

将reactor转换为同步命令式：使用Mono.block()或者Flux.block()方法，可以将Future阻塞直到完成

[seeflood]

命令式编程部分是先只考虑同步阻塞的调用模式吗？

是的

其实也可以在sdk内部使用reactor编程模型，在暴露给用户时，可以提供reactor的API和命令式的API

是的，但现在没有这么做是因为：

1. 有用户急着用命令式API,我们之前没用过Reactor API，时间太急了怕踩坑，而且不确定有没有java7及以下用户（我看Reactor core包要求java 8+)
2. 未来不确定要不要支持java 7-,如果需要的话可能得起两个包

[kevinten10]

了解

那我参考你们的命令式API和dapr，先做reactor的实现吧

[seeflood]

@kevinten10 好呀好呀 欢迎！

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue or help wanted) or other activity occurs. Thank you for your contributions.