第3章服务设计原则

第3章：服务设计原则——粒度、接口与版本管理

好，咱们进入第三章。这一章我打算聊聊服务设计里最核心的三个实操问题：服务粒度控制、接口设计（IDL）、版本管理。

说实话，这三个点要是没想清楚，后面整个架构跑起来会非常痛苦。我在项目里见过太多因为粒度太粗导致服务臃肿，或者因为接口设计不规范导致联调崩溃的例子。嗯，咱们一个一个来拆。

3.1 服务粒度控制：别太粗，也别太细

服务粒度，说白了就是一个服务该管多少事。你想想看，如果粒度太粗，一个服务包揽了所有功能，那它就是个“上帝服务”，改一处就得全量回归，部署也慢。如果粒度太细，服务数量爆炸，调用链拉得老长，光网络开销就够你受的。

我个人习惯遵循一个原则：高内聚、低耦合。具体来说，我会问自己三个问题：

这个服务是否围绕一个明确的业务能力？
它的数据是否相对独立？
它的变更频率是否与其他服务不同？

举个例子，在车载场景下，VehicleSpeedService 和 DoorControlService 就应该分开。为什么？因为车速信号每秒更新很多次，而车门状态变化频率低。混在一起，高频信号会干扰低频逻辑的处理。

核心原则：一个服务只做一件事，并且把它做好。

我在项目中遇到过一种情况：有人把“车窗控制”和“天窗控制”合并成一个服务。理由是“都是窗”。结果呢？天窗的逻辑里混入了车窗的防夹算法，导致天窗在特定场景下误触发防夹。这就是粒度没控制好。

3.2 服务接口设计（IDL）：契约先行

接口设计，我建议用 IDL（Interface Definition Language） 来定义。说白了，就是先写接口文档，再写代码。这样前后端、不同团队之间才能对齐。

在车载SOA里，常用的IDL有 Franca IDL（GENIVI标准）或者 Protobuf。我个人更倾向于 Protobuf，因为它轻量、跨语言支持好，而且序列化效率高。

来看一个简单的例子，定义一个车速服务接口：

syntax = "proto3";

package vehicle.speed;

service VehicleSpeedService {
    // 获取当前车速
    rpc GetCurrentSpeed (SpeedRequest) returns (SpeedResponse);

    // 订阅车速变化事件
    rpc SubscribeSpeedChange (SpeedSubscription) returns (stream SpeedEvent);
}

message SpeedRequest {
    // 空请求
}

message SpeedResponse {
    float speed_kph = 1;  // 车速，单位 km/h
    uint64 timestamp = 2; // 时间戳
}

message SpeedSubscription {
    uint32 interval_ms = 1; // 订阅间隔，毫秒
}

message SpeedEvent {
    float speed_kph = 1;
    uint64 timestamp = 2;
}

注意看，这里我用了 stream 关键字来实现事件订阅。这是 gRPC 的特性，非常适合车载场景下的周期性信号推送。

小技巧：接口字段一定要加注释，尤其是单位。我曾经因为没写单位，导致一个车速接口被误认为是 m/s，实际是 km/h，结果测试时差点出事故。

接口设计还有几个避坑点：

不要暴露内部状态：接口只暴露业务能力，不暴露内部实现细节。
接口要幂等：同一个请求多次调用，结果应该一致。
错误码要规范：别用“-1”表示所有错误，要有明确的错误分类。

3.3 服务版本管理：兼容是底线

版本管理，是SOA里最容易翻车的地方。你想想看，一个车上有几十个ECU，每个ECU上的服务版本可能不同。如果版本不兼容，轻则功能异常，重则整个系统崩溃。

我建议采用 语义化版本控制（SemVer）：

版本号	含义	示例
MAJOR	不兼容的API变更	2.0.0
MINOR	向下兼容的功能新增	1.3.0
PATCH	向下兼容的问题修复	1.2.1

在车载环境里，我特别强调一点：接口一旦发布，尽量不要删除字段，只能新增。为什么？因为OTA升级不是同步的，有的模块先升，有的后升。你删了一个字段，老版本的消费者直接崩了。

警告：千万不要在接口里直接删除字段。如果必须废弃，用 deprecated 标记，并保留至少两个大版本周期。

我曾经在一个项目里，因为急着修复一个bug，直接删除了一个接口的某个字段。结果呢？有3个ECU没有及时OTA，第二天路试时，那3个ECU全部因为解析失败而重启。嗯，从那以后，我再也不敢随便删字段了。

另外，版本管理还要考虑 服务发现 的兼容性。我建议在服务注册时，把版本号作为元数据一起注册。消费者在调用时，可以指定需要的版本范围。比如：

// 服务注册时携带版本
ServiceInfo info = new ServiceInfo();
info.setName("VehicleSpeedService");
info.setVersion("1.2.0");
registry.register(info);

// 消费者调用时指定版本范围
ServiceInstance instance = discovery.selectInstance(
    "VehicleSpeedService", 
    ">=1.0.0 <2.0.0"
);

这样，即使版本升级，只要在兼容范围内，系统依然能正常工作。

小结

这一章的内容，其实就三句话：

粒度：一个服务只做一件事，别贪多。
接口：先写IDL，再写代码，契约先行。
版本：兼容是底线，字段只增不减。

下一章，咱们聊聊服务通信的细节，包括同步调用和异步消息的区别。到时候我会分享一个我在实车调试时遇到的“幽灵信号”问题，挺有意思的。

📚 课程目录