Skip to main content

快速开始

安装配置#

本框架推荐使用 Maven 进行开发，目前主流的 Java 开发工具都对 Maven 有较完善的支持，后续会增加对Gradle的支持。本文档是基于你已经熟悉 Maven 的基础上进行编写的。

在项目的 pom.xml 文件里，添加如下 Maven 依赖：

<dependencies>
<dependency>
<groupId>work.ready</groupId>
<artifactId>ready-work-core</artifactId>
<version>0.6.6.rc6</version>
</dependency>
<dependency>
<groupId>work.ready</groupId>
<artifactId>ready-work-cloud</artifactId>
<version>0.6.6.rc6</version>
</dependency>
</dependencies>

本框架推荐设置一个工作目录给应用程序读写数据。如果没有主动设置，框架运行时会自动按当前开发环境的项目根目录、当前用户目录(user.home)的顺序尝试创建一个名为ready.work的工作目录。 如果当前应用在IDE中运行，通常能在当前项目的根目录下创建ready.work工作目录，如果是打包运行则会在当前运行目录下尝试创建ready.work工作目录。如果不希望在以上位置创建工作空间，路径可以通过配置文件或环境变量进行指定。

  1. 通过环境变量设置路径， JVM 参数优先，例如：-D ready.root_path=/workspace，其次是系统环境变量设置，例如：export ready_root_path=/workspace

  2. bootstrap配置文件

---
readyWork:
rootPath: /workspace

快速体验#

和前面介绍的单体应用比较，只需要额外增加一个注解标签即可变成微服务应用。和SpringCloud、Dubbo等流行的微服务架构比较，可谓是超级简单，你不用去写一大堆互相依赖关联的配置文件，也不用去理会注册中心、服务注册、服务发现等问题。 请看下面的实例，该实例实现了2个API微服务，4个节点的集群，基本上零配置：

  1. 第一步，先实现2个API服务
@RequestMapping("/api")
public class ApiController extends Controller {
@RequestMapping
public Result<String> hello() {
return Success.of(ReadyCloud.getInstance().getNodeId() + " says hello to you !");
}
@RequestMapping
public Result<String> hi() {
return Success.of(ReadyCloud.getInstance().getNodeId() + " says hi to you !");
}
}

作为演示，这2个API都很简单，都只是输出一串文字而已。这和前面的单体应用没有任何区别。

  1. 接下来，我们做服务启动器
@EnableCloud // 注意，这里@EnableCloud开启微服务
public class Node1 extends Application {
public static final String name = "test-01"; // 这里定义了微服务的serviceId，就是告诉别的节点提供的服务叫什么名字
public static final String version = "1.0.1.210601"; // 微服务版本号
public static final String apiVersion = "v1.0"; // API版本号，这个内部使用，可以随意设定
@Override
protected void globalConfig(ApplicationConfig config) {
// 设置微服务端口号，默认就是8080，但考虑其他3个节点也在本机运行，不能默认，都指定一下端口号
config.getServer().setHttpPort(8080);
}
public static void main(String[] args) {
Ready.For(Node1.class).Work(args);
}
}

上面就是一个节点，和单体应用差别就是多了个@EnableCloud注解标签，如果启动这个应用，访问8080端口的2个API就可以显示上面的字符串。 但考虑到我们是要演示集群微服务，我们将这个启动器(Node1.java)再复制3份，分别命名为Node2.java、Node3.java、Node4.java，端口号分别改为8081、8082、8083，其他都不变。 如果我们启动这些启动器，就可以分别通过对应端口号访问到对应的API，但他们虽然已经知道彼此的存在，但还只是各自提供服务。

  1. 微服务实例

首先实现一个微服务实例来调用上面实现的API服务：

@Service
public class DemoService extends BusinessService {
// 注意这里的serviceId对应上面启动器设置的name，url对应上面的API地址，method这里可以不用，只是为了演示可以这样指定请求方式。
@Call(serviceId = "test-01", method = RequestMethod.GET, url = "/api/hello")
public String hello() {
return IfFailure.get(null);
}
@Call(serviceId = "test-01", method = RequestMethod.POST, url = "/api/hi")
public String hi() {
return IfFailure.get(null);
}
}

然后，我们实现一个控制器来使用这个DemoService服务。

@RequestMapping("/")
public class DemoController extends Controller {
@Autowired
private DemoService service;
@RequestMapping
public Result<String> hello() {
return Success.of(service.hello());
}
@RequestMapping
public Result<String> hi() {
return Success.of(service.hi());
}
}

如果你了解SpringCloud或Dubbo，那么可以这样理解，前面的API服务实例是provider，这里微服务实例是consumer。 上面的控制器调用我们的DemoService，url映射在/下了。前面的那个API控制器映射在/api下了，所以如果通过/api/hi和/api/hello访问的是节点自己的真实服务，如果通过/hi和/hello访问的会是集群化的微服务。 为了方便演示，上面的例子将API服务实例和微服务集群混合在一起了，实际应用中可以将API服务实例和微服务暴露在不同的节点中。即用户访问暴露的微服务节点，微服务节点再负载均衡到实际的API服务节点，再原路返回结果到用户。 现在可以按顺序启动4个节点，因为端口做了区分，因此可以在单机启动，也可以多机启动，先启动一个节点，再启动其他3个节点。需要注意的是电脑需要有局域网，不能什么网都没有，把电脑联上WIFI，或者手机热点模拟一个局域网也行。

Edit this page