1. SOME/IP 协议基础回顾：服务发现、事件通知、远程过程调用核心机制
各位同学，咱们今天先不急着讲降级和重试。做架构设计，地基得打牢。SOME/IP 这玩意儿，说白了就是车载以太网里的「通用翻译官」——ECU 之间要说话，总得有个大家都懂的规矩。
我个人习惯，每次接手一个新项目，第一件事就是翻协议栈的 Service Discovery 配置。为什么？因为服务发现要是没配好，后面的事件通知和 RPC 全得跟着翻车。好，咱们一个一个来过。
1.1 服务发现（Service Discovery）——谁提供了什么服务？
想象一下，你走进一个黑灯瞎火的停车场，找不到自己的车。这时候你按一下车钥匙，车灯闪了，你才知道它在哪。SOME/IP 的服务发现（SD）干的就是这个活儿。
SD 的核心报文就两种：Find Service 和 Offer Service。
- Find Service：客户端广播「谁有 XX 服务？我需要！」
- Offer Service：服务端单播或组播「我有 XX 服务，这是我的 endpoint 信息」
我在项目中遇到过一个问题：某个 ADAS 域控作为服务端，启动后连续发了三次 Offer，但客户端因为网络拥堵丢掉了前两次，只收到了第三次。结果客户端等了 2 秒才确认服务可用。嗯，这里要注意——Offer 的重复间隔和次数，直接决定了系统上电后的「第一帧延迟」。
核心参数速查表
| 参数 | 默认值 | 我的建议 |
|---|---|---|
| Offer 重复次数 | 3 | 至少 3 次，网络抖动大的场景建议 5 次 |
| Offer 初始延迟 | 0~100ms 随机 | 避免多个服务端同时广播造成风暴 |
| Find 重试间隔 | 1000ms | 我习惯压到 500ms，但别低于 200ms |
| 服务 TTL | 3 倍 Offer 周期 | TTL 太短会导致频繁续约，太长则故障发现慢 |
你想想看，如果 TTL 设成 10 秒，服务端挂了，客户端要等 10 秒才知道——这在自动驾驶里就是事故。所以，TTL 必须和故障检测时间挂钩。
1.2 事件通知（Event Notification）——有变化，我告诉你
事件通知，说白了就是「订阅-发布」模式。客户端先订阅某个事件组，服务端一旦检测到数据变化，就主动推过来。
这里有个坑：事件通知的发送模式。SOME/IP 支持三种：
- 周期性（Cyclic）：不管数据变没变，定时发。适合传感器数据。
- 变化触发（On Change）：数据变了才发。适合状态类信号。
- 周期+变化（Cyclic and On Change）：变化时立即发，同时兜底周期发送。我最常用这种。
我曾经在一个项目中，把车速信号配成了纯 On Change。结果车在匀速行驶时，车速值几乎不变，客户端收不到任何更新。下游的仪表显示模块以为车速传感器挂了，直接报故障。后来改成 Cyclic and On Change，周期设 100ms，问题解决。
避坑指南：事件通知的「初始事件」一定要发。客户端订阅成功后，服务端必须立即发送一次当前值。否则客户端会一直等变化，而初始状态可能永远收不到。
1.3 远程过程调用（RPC）——你让我干啥，我干完告诉你
RPC 就是 SOME/IP 里的「请求-响应」机制。客户端发一个 Method 调用请求，服务端执行后返回结果。听起来简单，但实际落地时，超时和重试是最大的坑。
SOME/IP 的 RPC 分为两种：
- Fire & Forget：只发请求，不关心响应。适合「开个灯」这种不需要回执的操作。
- Request-Response：必须等响应。适合「查询当前车速」这种需要返回值的操作。
我见过最典型的翻车案例：某个团队把「车门解锁」配成了 Request-Response，客户端超时设了 3 秒。结果在信号弱的停车场，客户端收不到响应，连续重试了 5 次。车门执行器被重复触发了 5 次解锁——电机直接烧了。
重要提醒：对于写操作类的 RPC（解锁、开窗、挂挡），必须做幂等性处理。服务端要能识别重复请求，或者客户端只允许重试一次。否则，重试机制会变成「故障放大器」。
1.4 三者关系——一张图说清楚
好，咱们用一张 SVG 图把服务发现、事件通知、RPC 的关系串起来。这是我画架构图时最常用的逻辑分层。
从图上你能看到：SD 是基础，没有服务发现，客户端连服务端在哪都不知道；Event 和 RPC 是上层应用，一个用于推送，一个用于调用。三者共享同一个传输层，但超时和重试策略完全不同。
1.5 小结——地基打牢，后面才好盖楼
这一章咱们把 SOME/IP 的三个核心机制过了一遍。我个人觉得，理解这三者的本质区别，比背协议栈的报文格式重要得多：
- 服务发现解决的是「谁在哪」的问题——动态、有生命周期、需要续约。
- 事件通知解决的是「有变化告诉你」的问题——订阅制、推模式、注意初始事件。
- 远程过程调用解决的是「你帮我干件事」的问题——请求-响应、必须考虑幂等性和超时。