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生态的各种注解

解释：

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的别名