RPC 与进程间通讯概述

luobo · December 28, 2025, 1:48pm

术语与基础模型

进程间通讯（IPC）：同一主机上不同进程之间的数据交换方式，常见手段包括：
- 管道（匿名/命名管道）
- Unix Domain Socket（UDS）
- 共享内存（MMAP、POSIX shm、Windows 文件映射）
- 消息队列（POSIX、System V、内核对象）
- 信号、事件、信号量
- TCP/UDP 套接字（本地回环）
RPC（Remote Procedure Call）：在进程边界外以调用函数/方法的抽象形式进行通讯，屏蔽序列化、传输与错误处理细节。典型实现：
- gRPC（HTTP/2 + Protobuf，跨语言）
- Apache Thrift
- Cap’n Proto、FlatBuffers（更偏向零拷贝/低延迟的序列化格式与传输）
消息驱动与事件流：通过消息队列或流系统进行松耦合通讯，如 ZeroMQ、NATS、RabbitMQ、Kafka 等。
进程内 vs 进程间：
- 进程内扩展（FFI）：P/Invoke、C++/CLI、Rust C ABI、嵌入 Python。性能更高但安全边界更弱、崩溃风险更集中。
- 进程间扩展（IPC/RPC）：隔离性强、部署灵活、跨语言更自然，但带来序列化与上下文切换成本。

设计空间与取舍

传输层选择：
- 本机低延迟：UDS（Linux/macOS）、命名管道（Windows）
- 通用可跨机：TCP（可回环）、HTTP/2（gRPC）
- 高吞吐流：共享内存 + 自定义协议（复杂度高）
序列化选择：
- 文本：JSON（易调试，开销大）、XML（冗长）
- 二进制：Protobuf（成熟、跨语言、演进友好）、MessagePack（紧凑）、FlatBuffers/Cap’n Proto（零拷贝、适合低延迟）
通讯模式：
- 请求-响应（同步/异步）
- 单向消息（发布-订阅）
- 流式（双向流或服务器流），适合传输长时间数据或结果流
可靠性：
- 超时、重试、断路器、幂等性、退避策略
- 背压与流控（避免无限缓存）
安全：
- 本机 IPC 的 ACL/权限控制（Windows 安全描述符、Unix 文件权限）
- 远程通讯的 TLS/mTLS、鉴权、令牌/证书管理
可观测性：
- 结构化日志、指标（延迟、错误比率、队列长度）
- 分布式追踪（OpenTelemetry）

在 C# 主服务中进行跨语言扩展的常见路线

直接 RPC：
- gRPC（推荐）：跨语言、性能好、生态成熟。适合 C++、Rust、Python 同时接入。
- Thrift：也可用，二选一即可。
低层 IPC（本机高性能）：
- Windows：命名管道 NamedPipe + 自定义协议
- Linux/macOS：Unix Domain Socket + 自定义协议
消息总线：
- ZeroMQ（轻量）、NATS（云原生）、RabbitMQ/Kafka（更重）
进程内 FFI（不分进程）：
- C++：C++/CLI 或 P/Invoke 调用导出 C API
- Rust：生成 C ABI，P/Invoke 调用
- Python：嵌入解释器或使用 pythonnet；通常不建议在服务内长期嵌入，隔离更佳

以下给出可复用的工程模板。

方案一：gRPC（跨语言通用，推荐）

接口定义（Protobuf IDL）

文件 api/math.proto：

syntax = "proto3";
package api;

service Math {
  rpc Mul (MulReq) returns (MulResp);
  rpc SumStream (stream Num) returns (SumResp); // 示例：客户端流
}

message MulReq {
  int64 a = 1;
  int64 b = 2;
}

message MulResp {
  int64 result = 1;
}

message Num {
  int64 value = 1;
}

message SumResp {
  int64 sum = 1;
}

字段编号固定后不可复用，删除字段应保留占位或迁移到 reserved。
兼容演进：新增可选字段不破坏旧客户端；避免改变语义与类型。

C# 主服务（ASP-NET Core gRPC）

目录结构：

--proto/api/math.proto
|-src/Server/Server.csproj
|-src/Server/Program.cs
L-src/Server/Services/MathService.cs

Server.csproj（关键段）：

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <Protobuf Include="..\..\proto\api\math.proto" GrpcServices="Server" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="Grpc.AspNetCore" Version="2.63.0" />
    <PackageReference Include="Grpc.Tools" Version="2.63.0" PrivateAssets="All" />
    <PackageReference Include="Google.Protobuf" Version="3.25.3" />
    <PackageReference Include="OpenTelemetry.Exporter.Console" Version="1.8.1" />
    <PackageReference Include="OpenTelemetry.Extensions.Hosting" Version="1.8.1" />
  </ItemGroup>
</Project>

Program.cs：

using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddGrpc();
// 可选：OpenTelemetry
// builder.Services.AddOpenTelemetry().WithTracing(t => t.AddAspNetCoreInstrumentation());

var app = builder.Build();

app.MapGrpcService<MathService>();
app.MapGet("/", () => "gRPC server");

app.Run();

Services/MathService.cs：

using System.Threading.Tasks;
using Grpc.Core;
using api;

public class MathService : Math.MathBase
{
    public override Task<MulResp> Mul(MulReq request, ServerCallContext context)
    {
        checked
        {
            long result = request.A * request.B;
            return Task.FromResult(new MulResp { Result = result });
        }
    }

    public override async Task<SumResp> SumStream(IAsyncStreamReader<Num> requestStream, ServerCallContext context)
    {
        long sum = 0;
        await foreach (var num in requestStream.ReadAllAsync(context.CancellationToken))
        {
            checked { sum += num.Value; }
        }
        return new SumResp { Sum = sum };
    }
}

运行（默认监听 http://localhost:5000 与 https://localhost:5001，注意 gRPC 需 HTTP/2）：

设置 Kestrel 启用 HTTP/2（ASP-NET Core 默认已支持）。如需纯明文 HTTP/2，可使用 h2c 或走 TLS。

C++ 客户端（gRPC C++）

依赖安装：

gRPC C++ 与 protoc（可用 vcpkg、CMake FetchContent 或源码安装）

编译 Proto（示例 CMake 片段）：

find_package(Protobuf CONFIG REQUIRED)
find_package(gRPC CONFIG REQUIRED)

set(PROTO src/math.proto)

protobuf_generate_cpp(PROTO_SRCS PROTO_HDRS ${PROTO})
grpc_generate_cpp(GRPC_SRCS GRPC_HDRS ${PROTO})

add_executable(client src/client.cpp ${PROTO_SRCS} ${PROTO_HDRS} ${GRPC_SRCS} ${GRPC_HDRS})
target_link_libraries(client PRIVATE gRPC::grpc++ protobuf::libprotobuf)

client.cpp：

#include <grpcpp/grpcpp.h>
#include "math.grpc.pb.h"
#include <iostream>

int main() {
    auto channel = grpc::CreateChannel("localhost:5001", grpc::SslCredentials(grpc::SslCredentialsOptions())); // 如果启用 TLS
    // 若使用明文本地端口且服务器允许 h2c，可用 InsecureChannelCredentials
    // auto channel = grpc::CreateChannel("localhost:5000", grpc::InsecureChannelCredentials());

    std::unique_ptr<api::Math::Stub> stub = api::Math::NewStub(channel);

    // Unary 示例
    grpc::ClientContext ctx;
    api::MulReq req;
    req.set_a(6);
    req.set_b(7);
    api::MulResp resp;
    auto status = stub->Mul(&ctx, req, &resp);
    if (!status.ok()) {
        std::cerr << "RPC failed: " << status.error_message() << "\n";
        return 1;
    }
    std::cout << "Mul result: " << resp.result() << "\n";

    // 客户端流示例
    grpc::ClientContext ctx2;
    api::SumResp sumResp;
    auto writer = stub->SumStream(&ctx2, &sumResp);
    for (int i = 1; i <= 5; ++i) {
        api::Num n;
        n.set_value(i);
        if (!writer->Write(n)) break;
    }
    writer->WritesDone();
    status = writer->Finish();
    if (status.ok()) {
        std::cout << "SumStream result: " << sumResp.sum() << "\n";
    } else {
        std::cerr << "Stream failed: " << status.error_message() << "\n";
    }
    return 0;
}

Rust 客户端（tonic）

依赖：

tonic、prost、tonic-build

Cargo.toml（关键段）：

[package]
name = "grpc_client"
version = "0.1.0"
edition = "2021"

[dependencies]
tonic = "0.11"
prost = "0.12"
tokio = { version = "1.37", features = ["macros", "rt-multi-thread"] }

[build-dependencies]
tonic-build = "0.11"

build.rs：

fn main() {
    tonic_build::configure()
        .compile(&["../proto/api/math.proto"], &["../proto"])
        .unwrap();
}

src/main.rs：

use tonic::transport::Channel;
use tonic::Request;
pub mod api { tonic::include_proto!("api"); }

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    // 明文 h2c 示例（需服务端允许）
    let channel = Channel::from_static("http://127.0.0.1:5000").connect().await?;
    // 若走 TLS：
    // let channel = Channel::from_static("https://127.0.0.1:5001").connect().await?;

    let mut client = api::math_client::MathClient::new(channel);

    // Unary
    let resp = client.mul(Request::new(api::MulReq { a: 6, b: 7 })).await?;
    println!("Mul result: {}", resp.into_inner().result);

    // 客户端流
    use futures_util::stream;
    let numbers = stream::iter((1..=5).map(|i| api::Num { value: i }));
    let sum = client.sum_stream(numbers).await?.into_inner();
    println!("SumStream result: {}", sum.sum);
    Ok(())
}

Python 客户端（grpcio）

安装：

pip install grpcio grpcio-tools

生成代码：

python -m grpc_tools.protoc -I./proto --python_out=. --grpc_python_out=. ./proto/api/math.proto

client.py：

import grpc
import api.math_pb2 as pb
import api.math_pb2_grpc as stub

def main():
    # 纯明文 h2c 客户端在 Python 中较不直接，通常使用 TLS
    # 如需明文，可配置 gRPC 服务器支持 h2c 并用 insecure_channel
    channel = grpc.insecure_channel('localhost:5000')
    client = stub.MathStub(channel)

    # Unary
    resp = client.Mul(pb.MulReq(a=6, b=7))
    print("Mul result:", resp.result)

    # 客户端流
    def gen():
        for i in range(1, 6):
            yield pb.Num(value=i)
    sum_resp = client.SumStream(gen())
    print("SumStream result:", sum_resp.sum)

if __name__ == '__main__':
    main()

gRPC 关键工程点

HTTP/2 要求、TLS/mTLS 配置、证书轮换。
流式调用的流控与内存边界，避免无界缓存。
超时、重试策略（gRPC 客户端支持 CallOptions/Deadline）。
数据演进：字段 reserved，避免二进制兼容性破坏。
大包传输：max message size、分块上传。
可观测：拦截器/中间件加入 trace id、指标打点。

方案二：本机 IPC（命名管道与 Unix Domain Socket，自定义二进制协议）

适用场景：仅同一主机进程间通讯，要求低延迟与最小依赖。需自行处理协议帧、序列化与错误边界。

协议约定（长度前缀 + Protobuf/MessagePack）

帧结构：
- 4 字节小端整型表示负载长度 L
- L 字节负载（序列化后的消息）
请求/响应模式：请求含方法 id 与参数，响应含状态码与结果。

可以选择：

Protobuf 自行定义消息并序列化到帧
MessagePack/CBOR/自定义 TLV

以下示例用最小化自定义结构（JSON 简化，但生产更推荐 Protobuf/MessagePack）。

Windows：C# 服务端（NamedPipeServerStream）

using System;
using System.IO;
using System.IO.Pipes;
using System.Text;
using System.Threading.Tasks;

class PipeServer
{
    static async Task Main()
    {
        while (true)
        {
            using var server = new NamedPipeServerStream(
                "calc_pipe",
                PipeDirection.InOut,
                maxNumberOfServerInstances: 4,
                PipeTransmissionMode.Byte,
                PipeOptions.Asynchronous);

            await server.WaitForConnectionAsync();

            _ = HandleClient(server); // 异步处理并行客户端
        }
    }

    static async Task HandleClient(NamedPipeServerStream server)
    {
        using var br = new BinaryReader(server, Encoding.UTF8, leaveOpen: true);
        using var bw = new BinaryWriter(server, Encoding.UTF8, leaveOpen: true);

        try
        {
            while (true)
            {
                // 读长度
                var lenBuf = br.ReadBytes(4);
                if (lenBuf.Length < 4) break;
                int len = BitConverter.ToInt32(lenBuf, 0);
                var payload = br.ReadBytes(len);
                if (payload.Length < len) break;

                // 简化：payload 为 JSON，如 {"op":"mul","a":6,"b":7}
                var json = Encoding.UTF8.GetString(payload);
                var result = Process(json); // 返回 JSON 字符串，{"ok":true,"result":42}

                var outBytes = Encoding.UTF8.GetBytes(result);
                bw.Write(BitConverter.GetBytes(outBytes.Length));
                bw.Write(outBytes);
                bw.Flush();
            }
        }
        catch (IOException) { /* 客户端断开 */ }
        finally { server.Dispose(); }
    }

    static string Process(string json)
    {
        // 极简解析示例（生产使用 JSON 解析器）
        // 这里假设只支持 mul
        // 解析略...
        // 为示例直接返回固定值
        return "{\"ok\":true,\"result\":42}";
    }
}

安全建议：

使用 NamedPipeServerStream 的构造重载设置 PipeSecurity（ACL）限制访问身份。
服务运行在低特权账户，最小化权限。

Windows：C++ 客户端（WinAPI）

#include <windows.h>
#include <string>
#include <iostream>

int main() {
    HANDLE hPipe = CreateFileA(
        R"(\\.\pipe\calc_pipe)",
        GENERIC_READ | GENERIC_WRITE,
        0, NULL, OPEN_EXISTING,
        FILE_FLAG_OVERLAPPED, NULL);

    if (hPipe == INVALID_HANDLE_VALUE) {
        std::cerr << "Open pipe failed: " << GetLastError() << "\n";
        return 1;
    }

    auto send = [&](const std::string& json) {
        DWORD written = 0;
        int len = (int)json.size();
        WriteFile(hPipe, &len, 4, &written, NULL);
        WriteFile(hPipe, json.data(), len, &written, NULL);
    };

    auto recv = [&]() {
        DWORD read = 0;
        int len = 0;
        ReadFile(hPipe, &len, 4, &read, NULL);
        std::string buf(len, '\0');
        ReadFile(hPipe, buf.data(), len, &read, NULL);
        return buf;
    };

    send(R"({"op":"mul","a":6,"b":7})");
    auto resp = recv();
    std::cout << "resp: " << resp << "\n";

    CloseHandle(hPipe);
    return 0;
}

Linux/macOS：C# 服务端（Unix Domain Socket）

using System;
using System.Net;
using System.Net.Sockets;
using System.Text;
using System.Threading.Tasks;

class UdsServer
{
    static async Task Main()
    {
        string path = "/tmp/calc.sock";
        if (System.IO.File.Exists(path)) System.IO.File.Delete(path);

        var sock = new Socket(AddressFamily.Unix, SocketType.Stream, ProtocolType.Unspecified);
        sock.Bind(new UnixDomainSocketEndPoint(path));
        sock.Listen(128);

        // 设置权限，避免其他用户访问（umask 或 chmod）
        System.IO.File.SetAttributes(path, System.IO.FileAttributes.Normal);

        while (true)
        {
            var client = await sock.AcceptAsync();
            _ = Handle(client);
        }
    }

    static async Task Handle(Socket client)
    {
        try
        {
            var lenBuf = new byte[4];
            while (true)
            {
                int read = await client.ReceiveAsync(lenBuf, SocketFlags.None);
                if (read == 0) break;
                int len = BitConverter.ToInt32(lenBuf, 0);
                var payload = new byte[len];
                int off = 0;
                while (off < len)
                {
                    int r = await client.ReceiveAsync(payload.AsMemory(off), SocketFlags.None);
                    if (r == 0) break;
                    off += r;
                }
                var json = Encoding.UTF8.GetString(payload);
                var result = "{\"ok\":true,\"result\":42}";
                var outBytes = Encoding.UTF8.GetBytes(result);
                await client.SendAsync(BitConverter.GetBytes(outBytes.Length), SocketFlags.None);
                await client.SendAsync(outBytes, SocketFlags.None);
            }
        }
        catch { }
        finally { client.Dispose(); }
    }
}

Linux/macOS：Python 客户端（UDS）

import socket
import struct
import json

path = "/tmp/calc.sock"
s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
s.connect(path)

def send(obj):
    data = json.dumps(obj).encode('utf-8')
    s.sendall(struct.pack("<I", len(data)))
    s.sendall(data)

def recv():
    lenbuf = s.recv(4)
    n = struct.unpack("<I", lenbuf)[0]
    payload = b''
    while len(payload) < n:
        chunk = s.recv(n - len(payload))
        if not chunk:
            break
        payload += chunk
    return json.loads(payload.decode('utf-8'))

send({"op":"mul","a":6,"b":7})
print(recv())
s.close()

安全建议：

限制 socket 文件权限（chmod 600），运行账户隔离。
使用抽象命名空间（Linux）或临时目录策略，避免路径劫持。

方案三：ZeroMQ（REQ/REP 示例）

特点：轻量、跨语言、无需中心服务器。缺点：无内建强 schema，需要自行序列化。

C#：NetMQ
C++：cppzmq
Rust：zmq
Python：pyzmq

模式：

主服务 REP，外部扩展 REQ 或 PUB/SUB（取决于业务）

消息格式：

建议使用 Protobuf/MessagePack 对消息体编码，避免裸文本。

序列化格式比较与实践建议

JSON：
- 优点：人可读，调试简单
- 缺点：开销较大，无强类型，数值精度与二进制字段麻烦
- 建议：管理面、低吞吐控制面可以考虑
Protobuf：
- 优点：跨语言成熟、紧凑、高性能、良好演进（保留字段号）
- 缺点：需要 IDL 与代码生成
- 建议：业务数据面优选
FlatBuffers/Cap’n Proto：
- 优点：零拷贝读取，适合高频低延迟
- 缺点：生态复杂度高、调试不如 Protobuf
- 建议：极端性能场景或嵌入式/游戏引擎
MessagePack/CBOR：
- 折中方案，紧凑且易用，Rust/Go/Python 支持较好

对齐与字节序：

自定义二进制协议时统一小端字节序，明确结构体对齐与字段宽度。
避免直接通过语言 struct 序列化（跨语言/编译器差异大），统一使用库序列化。

性能、延迟与容量

典型延迟（本机）：
- UDS/Named Pipe：几十微秒到数百微秒
- gRPC/HTTP2 本机回环：毫秒级（取决于负载与序列化）
- 共享内存：亚微秒到微秒（取决于协议与同步原语）
吞吐影响因素：
- 序列化开销（Protobuf 通常较低）
- 内存复制与上下文切换
- 小包 Nagle、批处理、流式合并
优化策略：
- 批量请求、流式接口减少握手开销
- 减少大对象与深层嵌套，靠引用/ID 重构
- 调整线程模型与绑定 CPU 亲和性（高频场景）
- 使用零拷贝框架（如 Kestrel 的管线、Span/Memory）

版本演进与兼容性

IDL 管理：
- 每次变更经过评审，字段号不可复用
- 旧字段保留或迁移至 reserved
- 客户端/服务端滚动升级顺序设计，保持双向兼容
自定义协议：
- 帧头包含版本号与能力集（capabilities）
- 支持协商降级与扩展字段忽略
合约测试：
- 使用契约测试框架（如 protobuf-jsonschema 转换校验）或集成测试保证兼容

错误处理、重试与幂等性

超时：
- 客户端设置 deadline；服务端尊重 CancellationToken
重试：
- 幂等操作可以重试（POST 非幂等谨慎）
- 使用指数退避与抖动
断路器与健康检查：
- 避免级联失败；当后端不可用时快速失败
错误编码：
- gRPC Status code 与 details
- 自定义协议用标准化错误码与人类可读消息
Backpressure：
- 控制流速，拒绝超出限额的请求，保护服务稳定性

安全与隔离

进程边界：
- 外部扩展程序崩溃不影响主服务；资源限制（cgroups/Job Object）
本机 IPC：
- Windows：PipeSecurity、令牌、服务账户
- Unix：UDS 文件权限、运行用户隔离、chroot/namespace（容器化）
远程 RPC：
- TLS/mTLS；证书自动轮换；最小权限策略
- 鉴权：JWT、API Key、MAC 算法
输入校验与防护：
- 帧长限制、类型校验、防止反序列化炸弹
- 模糊测试（fuzz），避免解析器缺陷

可观测性

指标：
- 请求速率、P50/P95/P99 延迟、错误率、队列长度、重试次数
日志：
- 结构化日志，包含 trace_id/span_id
追踪：
- OpenTelemetry（C#、Rust、Python、C++ 均有实现）
- gRPC 拦截器注入 trace 上下文

架构与部署建议

进程生命周期：
- 外部扩展作为独立进程，主服务管理其启动/重启或由系统服务管理（systemd、Windows Service）
通讯拓扑：
- 单主服务多工作进程（池化），负载均衡（本机调度）
接口治理：
- 明确领域边界，RPC 合约稳定，避免将内部对象直接暴露
CI/CD：
- IDL 在独立仓库或子模块；协议变更触发代码生成与测试
- 多语言代码生成统一版本，避免漂移
资源限制：
- 外部进程内存/CPU 限额，避免抢占主服务资源

何时选择 FFI 而非 IPC

对性能极致要求且逻辑可信、崩溃风险可控
维护难度：
- C++/CLI：仅 Windows；与 .NET 交互紧密
- P/Invoke：C 风格 API；内存所有权与生命周期管理严格
- Rust：通过 cbindgen 生成 C 头；注意 panic 边界与 unwind 禁止
- Python：嵌入解释器或调用 CPython 扩展；GIL 与多线程复杂性
可靠性考量：
- 崩溃会直接拖垮主服务；与 IPC 比隔离性差

最小可运行示例的构建要点

gRPC：
- 统一 proto，使用语言各自的插件生成代码
- C# 服务端以 ASP-NET Core 运行
- 客户端以各语言 gRPC 库连接，遵守 HTTP/2 与 TLS/h2c 配置
命名管道/UDS：
- 确保双方字节序一致（小端），长度前缀协议实现正确
- 控制权限与路径安全，避免被非预期进程连接
调试：
- 使用网络抓包（本机回环用工具支持有限）、gRPC 调试器、日志与指标
- 压测工具：自制脚本或使用 ghz（gRPC 压测），对比不同序列化与传输策略

常见陷阱与对策

gRPC 明文 h2c 在某些语言/平台默认不启用，需明确配置；生产建议统一 TLS。
大报文导致内存峰值与 GC 压力，需拆分与流式传输。
双向流中未消费的消息造成背压失效与积压，应确保消费者速率或应用级队列。
自定义协议未设上限会导致拒绝服务风险，必须限制帧长与频率。
代码生成版本不一致导致兼容性问题，需在 CI 统一工具链版本。
Windows 命名管道默认安全性较松，必须设置 ACL；Linux UDS 注意目录与文件权限。
Python 客户端在高并发场景需考虑 GIL 与线程模型，改用异步或多进程策略。

参考工具与库清单

C#：
- Grpc.AspNetCore、Grpc.Net.Client、Google.Protobuf
- System.IO.Pipes（NamedPipeServerStream）
- System.Net.Sockets（UnixDomainSocketEndPoint）
- NetMQ（ZeroMQ）
C++：
- gRPC C++、Protobuf、cppzmq
- WinAPI 管道、POSIX 套接字
Rust：
- tonic/prost、zmq、tokio、serde + messagepack/cbor
Python：
- grpcio/grpcio-tools、pyzmq、socket（AF_UNIX）
构建与测试：
- protoc、tonic-build、CMake、vcpkg
- ghz（gRPC 压测）、wrk/ab（HTTP 压测）

实战建议

优先选用 gRPC + Protobuf 作为跨语言主方案，统一 IDL 与代码生成。
本机高性能场景可以辅以 Named Pipe/UDS + 二进制协议，对关键路径优化。
对所有通道实现统一的错误处理与超时策略，并加入指标与追踪。
明确安全边界与权限控制，避免 IPC 被非预期进程使用。
建立协议演进流程与合约测试，降低跨语言协作成本。