📚 课程目录第4章服务接口设计原则

4. 服务接口设计原则：高内聚低耦合、接口粒度控制、服务边界划分

做 SOME/IP 服务设计，最怕什么？我个人觉得，最怕把接口设计成一锅粥。你想想看，一个服务里塞了五十个 method，EventGroup 乱挂，数据类型到处引用——这种项目我接手过两次，每次都是噩梦。改一个接口，牵连七八个模块，版本号都不知道怎么升。

这一章，我们就聊聊服务接口设计的三条核心原则。说白了，就是怎么让你的 SOME/IP 服务既好用又好管。

高内聚，意思是服务内部的 method、event、field 应该围绕同一个业务目标。举个例子，你做一个「车门控制服务」，那它就应该只管车门：锁门、解锁、查询门状态、门状态变化通知。别把车窗、空调、座椅的逻辑也塞进来。

我在项目中遇到过这样一个案例：有人把「车辆诊断」和「娱乐系统控制」放在同一个服务里。理由是「反正都是 CAN 总线出去的」。结果呢？诊断服务升级时，娱乐系统的接口版本也被迫跟着变，下游的 HMI 团队叫苦连天。

  高内聚的判断标准： 如果你需要用一个「服务描述」来解释这个服务是干什么的，而这个描述里出现了「和」「或」「以及」这些词，那大概率内聚性已经出问题了。

具体到 SOME/IP 设计，高内聚体现在：

Method 之间逻辑相关：比如 GetDoorState 和 SetDoorLock，它们操作的是同一个状态机。
Event 只通知本服务的状态变化：不要在一个 EventGroup 里混着发车门状态和空调温度。
Field 的 getter/setter/notifier 语义一致：不要出现 getter 返回 int32，setter 却要求 string 这种奇葩设计。

我的习惯： 设计初期，我会在白板上画一个「服务-数据」矩阵。横轴是服务，纵轴是数据实体。如果某个数据实体被三个以上的服务引用，我就会重新审视边界划分。

低耦合，就是服务之间的依赖关系要尽可能弱。SOME/IP 本身就是分布式通信协议，服务可能运行在不同的 ECU 上，甚至不同的 SoC 上。如果服务 A 调用服务 B 的 method，服务 B 又回调服务 C 的 event，那这个调用链一旦断了，整个系统就瘫了。

我曾经在一个项目中看到这样的设计：

// 服务A：车身控制
method: LockDoor() 
  -> 内部调用服务B的 CheckSecurityStatus()
  -> 服务B返回后，再调用服务C的 LogEvent()
  -> 最后才执行锁门动作

这个设计的问题在哪？锁门这个简单操作，居然依赖了两个外部服务。如果服务B或服务C超时，门就锁不上了。这不是技术问题，是架构问题。

低耦合的设计原则：

减少链式调用：一个 method 的实现，尽量不要同步等待另一个服务的响应。
用 Event 代替轮询：服务 A 需要知道服务 B 的状态变化时，让服务 B 主动发 Event，而不是服务 A 每隔 100ms 去 Get 一次。
接口契约独立：服务 A 的接口定义中，不要直接引用服务 B 的数据类型。用基础类型或者独立定义的复杂类型。

避坑指南： 我曾经见过一个团队，为了让「接口复用」，把两个完全不相关的服务共用一个 Service ID。结果版本管理时，一个服务升级了 major 版本，另一个服务也被迫跟着升。记住：Service ID 是服务身份的标识，不是代码复用的工具。

接口粒度，是新手最容易踩坑的地方。太粗，一个 method 干太多事，调用方用起来别扭；太细，method 数量爆炸，网络开销也上去了。

我举个例子。你设计一个「座椅控制服务」：

粒度	设计方式	问题
过粗	SetSeatAll(int32 seatId, int32 posX, int32 posY, int32 recline, int32 lumbar, int32 heatLevel)	调用方只想调一下 lumbar，却要传全部参数。参数多了容易出错。
过细	SetSeatPosX(), SetSeatPosY(), SetSeatRecline(), SetSeatLumbar(), SetSeatHeat() 各一个 method	调整一个坐姿要发 5 个 SOME/IP 请求，网络延迟叠加，用户体验差。
适中	SetSeatPosition(int32 seatId, SeatPosition pos) + SetSeatComfort(int32 seatId, SeatComfort comfort)	按功能域分组，每个 method 的参数是结构体，调用方只传需要修改的字段。

我个人习惯的粒度控制原则：

我的经验： 设计接口时，我会先写调用方的伪代码。如果调用方用起来很啰嗦，那接口粒度就有问题。比如调用方要写三行代码才能完成一个逻辑操作，那说明 method 太细了。

服务边界划分，是架构设计中最难的部分。它没有标准答案，但有经验法则。

我常用的划分方法：

下面这张图展示了我常用的服务边界划分逻辑：

边界划分的避坑点：

我曾经踩过的坑： 在一个项目中，我把「车辆状态」和「车辆设置」放在同一个服务里。结果发现，状态是高频读取的，设置是低频修改的。高频读取导致服务负载高，低频修改的响应时间也被拖慢了。后来拆成两个服务，各自独立优化，问题才解决。

这些原则不是孤立的。在实际项目中，它们经常需要权衡。我个人习惯的优先级排序：

嗯，这一章的内容就到这里。记住：好的服务接口设计，不是写出来的，是「想」出来的。多花时间在架构设计上，后面版本管理的时候，你会感谢自己的。