Arthas内部服务异步化，再包装为 gRPC 服务暴露

1. 目前Arthas的功能都是基于 命令行 的 Command 思路实现的，大部分交互都是在 terminal 窗口
2. 这种cli的交互导致Arthas 的功能不能很好的以 API 方式暴露，尽管之前实现过一版 HTTP API 的支持，但并不是很友好 https://arthas.aliyun.com/doc/http-api.html
3. 基于命令行 Command 实现，导致很多功能被限制了，并且实现比较复杂

抛开之前的实现来思考，Arthas本身内部的功能大致可以分为两类：

1. 一次性执行，比如 sysenv, jvm 等，这种是比较简单的。
2. 可交互的长时间执行，比如像 watch/trace

重点是类watch/trace的任务

1. 执行中可能修改任务的配置，比如 watch 监听的 结果表达式， 条件表达式 ，可以支持动态更新。这样子用户不需要重新执行一次 watch
2. 增强的类可以持续增加，比如像 trace，可以更容易实现 动态trace 功能 https://arthas.aliyun.com/doc/trace.html#%E5%8A%A8%E6%80%81-trace
3. 这类任务需要支持 持续接收 输入，也有持续的结果输出。这个和 gRPC 的双向Stream功能很像
4. 为了简化实现，和支持 gRPC Web（gRPC Web目前只支持 server stream） ，尽量只考虑 gRPC server stream ，不考虑 client stream ，client stream 可能考虑通过传入 jobId 的方式解决
5. 为了更好的适配，在arthas内部不会直接使用 gRPC 的API，而是提供类似 io.grpc.stub.StreamObserver 的接口，后面再转接到 gRPC 上

---

下面是一种sysprop 命令的对应 servcie 的定义

• https://arthas.aliyun.com/doc/sysprop.html

message StringKey {
    string key = 1;
}

message StringValue {
    string value = 1;
}

message Properties {
    map<string, string> properties = 1;
}

service SystemProperty {
    rpc get(google.protobuf.Empty) returns (Properties);
    rpc getByKey(StringKey) returns (StringValue);
    rpc update(Properties) returns (Properties);
}

• watch/trace 这种需要持续交互的命令定义还需要实践尝试。

---

关联Issue：

• https://github.com/alibaba/arthas/issues/2349
• https://github.com/alibaba/arthas/issues/1350