4. SOME/IP服务发现（SD）：让ECU学会“打招呼”
好，咱们进入SOME/IP里最有趣的部分——服务发现。说实话，我第一次接触车载以太网时，最困惑的就是：这么多ECU，它们怎么知道谁提供了什么服务？总不能靠人工配置吧？
Service Discovery，简称SD，就是解决这个问题的。它让ECU能自动发现网络上的服务，说白了就是一套“打招呼”的协议。
4.1 Service Discovery协议概述
SOME/IP SD定义在AUTOSAR标准里，它运行在SOME/IP之上。你想想看，如果没有SD，每个ECU都得硬编码对方的IP和端口，那维护成本得多高？
SD的核心功能就两个：
- 服务发现：找到谁提供了什么服务
- 事件订阅：告诉服务提供者“我想收你的数据”
SD报文本身也是SOME/IP报文，它的Service ID是0xFFFF，Method ID是0x8100。嗯，这里要注意，SD报文不使用普通的Request/Response模式，它有自己的消息结构。
SD报文结构（简化版）
// SOME/IP SD Header
- Message ID: 0xFFFF8100
- Length: 可变
- Request ID: 0x00000000
- Protocol Version: 0x01
- Interface Version: 0x01
- Message Type: 0x02 (Notification)
- Return Code: 0x00
// SD Payload
- Flags: 1 byte
- Reserved: 3 bytes
- Length of Entries Array: 4 bytes
- Entries Array: 可变
- Length of Options Array: 4 bytes
- Options Array: 可变我个人习惯把SD报文分成三部分：头部、Entry列表、Option列表。Entry描述服务或事件，Option提供额外信息（比如IP地址、端口号）。
4.2 Find Service / Offer Service 流程
这是SD最基础的交互。我拿一个实际项目场景来说：
假设车上有个“车门控制服务”，由左前门ECU提供。其他ECU（比如中控屏）想用这个服务，怎么办？
流程是这样的：
- Find Service：客户端（中控屏）发一个Find报文，问“谁提供车门控制服务？”
- Offer Service：服务端（左前门ECU）收到后，回复一个Offer报文，说“我提供，我的IP是192.168.1.10，端口是5001”
等等，这里有个细节——Offer Service不一定非要等Find才发。服务端可以主动广播Offer，告诉全网“我上线了”。
我的经验：在项目中，我建议服务端启动后先主动发2-3次Offer，间隔100ms。这样客户端能快速发现服务，不用等Find超时。我曾经在一个项目中没做主动Offer，结果客户端等了3秒才发现服务，被客户投诉了。
报文示例：
// Find Service 报文（客户端 -> 多播）
Entry Type: 0x00 (FindService)
Service ID: 0x1234 (车门控制服务)
Instance ID: 0x0001
Major Version: 0x01
TTL: 3 (秒)
// Offer Service 报文（服务端 -> 多播）
Entry Type: 0x01 (OfferService)
Service ID: 0x1234
Instance ID: 0x0001
Major Version: 0x01
TTL: 60 (秒)
// Options
- IPv4 Endpoint Option: 192.168.1.10:5001TTL字段很关键。它告诉接收方“这个信息有效多久”。如果TTL过期了还没收到新的Offer，客户端就知道服务下线了。
避坑指南：我曾经遇到过一个问题——服务端崩溃重启后，IP变了，但客户端还缓存着旧的Offer。结果客户端一直连不上。解决方案是：客户端收到新Offer时，必须用新信息覆盖旧的。另外，TTL不要设太长，我一般设30-60秒。
4.3 Subscribe / Subscribe ACK 流程
找到服务只是第一步。很多时候，客户端需要订阅服务端的事件（比如车门状态变化）。这就用到Subscribe流程了。
为什么需要订阅？你想想看，如果服务端每次状态变化都广播给所有人，网络带宽肯定扛不住。所以SD设计了订阅机制——只有订阅了的客户端才能收到事件。
订阅流程：
- Subscribe：客户端发Subscribe报文，说“我要订阅车门状态事件”
- Subscribe ACK：服务端同意后，回复Subscribe ACK
- 事件推送：之后每次车门状态变化，服务端就发Event报文给客户端
如果服务端不同意订阅，会回复Subscribe NACK。为什么不同意？可能是版本不匹配，或者客户端没有权限。
Subscribe报文结构：
Entry Type: 0x06 (SubscribeEventgroup)
Service ID: 0x1234
Instance ID: 0x0001
Eventgroup ID: 0x0001 (车门状态事件组)
Major Version: 0x01
TTL: 0 (表示订阅永久有效，直到客户端取消)
// Options
- IPv4 Endpoint Option: 客户端IP和端口（服务端用这个回推事件）嗯，这里要注意Eventgroup ID。一个服务可以有多个事件组，比如“车门状态组”和“车窗状态组”。客户端可以只订阅自己关心的组。
Subscribe ACK报文：
Entry Type: 0x07 (SubscribeEventgroupACK)
Service ID: 0x1234
Instance ID: 0x0001
Eventgroup ID: 0x0001
Major Version: 0x01
TTL: 60 (秒)
// Options
- IPv4 Endpoint Option: 服务端IP和端口（客户端用这个收事件）看到没？Subscribe ACK里也带了Endpoint Option。这是因为服务端可能用不同的端口推事件，客户端得知道往哪个端口收数据。
我的建议：订阅成功后，客户端要定期检查TTL。如果TTL快过期了，需要重新订阅。我曾经见过一个bug——客户端订阅后就不管了，结果TTL过期后事件收不到了，排查了半天才发现是订阅过期了。
4.4 状态机与超时处理
SD协议里，每个服务都有状态机。我简单画一下核心状态：
| 状态 | 说明 | 触发条件 |
|---|---|---|
| Available | 服务可用 | 收到Offer或Find成功 |
| Subscribed | 已订阅事件 | 收到Subscribe ACK |
| Unavailable | 服务不可用 | TTL过期或收到Stop Offer |
超时处理策略：
- Find超时：客户端发Find后，如果1秒内没收到Offer，重试2次。3次都失败，报错。
- Subscribe超时：发Subscribe后，如果500ms内没收到ACK，重试2次。
- Offer过期：服务端必须在TTL过期前重新发Offer，否则客户端认为服务下线。
我曾经踩过的坑：有一次测试，服务端因为CPU负载高，Offer报文发送延迟了200ms。结果客户端认为服务下线，触发了故障处理。后来我把Offer的发送间隔从1秒改成500ms，并且加了发送队列优先级，问题解决了。
4.5 实战建议总结
最后，我总结几个SD开发的关键点：
- 多播地址别搞错：SD默认用224.0.0.1:30490，但有些项目会改。确认好再开发。
- TTL是生命线：设太短增加网络负载，设太长影响故障检测速度。我一般Offer设60秒，Subscribe设300秒。
- 版本号要一致：Major Version不匹配会导致订阅失败。我习惯在服务设计阶段就定好版本号。
- 日志要打全：SD调试时，把每个报文的Entry Type、Service ID、TTL都打出来。我曾经靠日志定位了一个“服务端发了Offer但客户端没收到”的问题，结果是防火墙把多播包过滤了。
好了，SD的核心内容就这些。下一章咱们会深入SD的Option解析和高级用法，包括负载均衡和冗余设计。到时候我会分享一个实际项目中怎么用SD做服务热备的案例。