Incloud-go-starter

平台部分功能使用了go底层依赖，incloud-go-starter就是java跟go通信的介质，基于google的开源框架gRPC实现，性能和安全性有保证。

incloud-go-starter版本与平台的版本一一对应，对应pom如下：

<dependency>
<groupId>com.netwisd</groupId>
<artifactId>incloud-go-starter</artifactId>
<version>5.1.0-SNAPSHOT</version>
</dependency>

异常处理

由于是两个完全独立的程序，对于异常的处理，需要引入方做异常try catch处理，go端程序如果发生异常后，会通过gRPC框架返回，客户端只需要捕获异常即可。

大多数情况下，在incloud-go-starter中已经对运行时异常做了处理，对于业务引入时，只需要捕获异常即可。

需要的配置文件

incloud-go-starter需要的配置文件分两种情况：

go:
  client:
    connect: false # 是否连接go端程序，设置为false，代表不对go端程序进行长连接
    start: false # 是否启动go端程序，设置为false，代表不启动go-serve端程序
  server:
    level: debug
    path: logs/incloud-go-code

go:
  client:
    connect: true # 是否连接go端程序，设置为true，代表对go端程序进行长连接
    start: true # 是否启动go端程序，设置为true，代表启动go-serve端程序
  server:
    level: debug
    path: logs/incloud-go-code

如果使用单次调用，如：incloud-go-code这种main方法直接运行，运行完即结束的情况，go.client.connect和go.client.start都可以设置为false，不需要启动go端程序。

反之，如果是incloud-go-serve这种长期运行的程序，go.client.connect和go.client.start都需要设置为true，需要启动go端程序。

心跳检测

incloud-go-starter会定时检测go端程序是否正常运行，如果go端程序异常退出，incloud-go-starter会自动重启go端程序。并且会重试三次，如果三次都失败，则会抛出异常，需要引入方查看incloud-go-serve打印的日志来查看具体原因。

同时，如果incloud-go-starter不往go serve端程序发送心跳，go serve端程序在120秒内也会自动退出，这样可以保证go serve端程序不会一直运行。

对于服务型应用来讲，这是至关重要的，即可以保证incloud-go-starter端不用每次调用时都要启动go serve端。同时，在incloud-go-starter的引用服务退出时，也会自动关闭go serve端程序。

API接口

虽然gRPC支持丰富的类型定义，但由于接口开发的复杂性，参数变动后，需要重新生成gRPC的相关代码，这会导致开发效率低下，

为了解决这一问题，接口定义的参数类型我们只支持一种：string类型，实际上他是json转换后的字符串，在go serve端再进行 json的反向转换即可；

.proto文件定义如下

syntax = "proto3";

option go_package = "netwisd.com/incloud/rpc/incloud/serve";
package incloud.rpc;

service IncloudServe{
  rpc generatorCode(Request) returns (Empty) {}
  rpc generatorCodeChat(stream Request) returns (stream BytesData) {}
  rpc heartbeat(stream HearBeat) returns (Empty);
}

message BytesData {
  bytes Data = 1;
}

message Request {
  string Req = 1;
}

message Empty {}

message HearBeat {
  string ClientId = 1;
  string Extra = 2;
}

java接口定义

目前为内部使用，暂不开放。

Last modified: 20 一月 2025