2、SOA基础概念回顾：服务、接口、契约、服务发现、服务编排
好，咱们进入正题。这一节我打算把SOA的几个核心概念再过一遍。你可能会说：“这些我都懂啊。” 嗯，我理解。但很多人在做信号到服务的迁移时，恰恰是栽在这些“基础概念”上。说白了，概念没吃透，后面设计就容易跑偏。
2.1 服务（Service）—— 到底什么是“服务”？
服务，不是函数，也不是类。它是一种自治的、可复用的业务能力。我个人的习惯是这么定义的：服务是“一个能独立完成某件事的单元”。
举个例子，车窗控制。传统信号里，你发一个“升窗”信号，ECU收到后执行。但在SOA里，我们定义一个“车窗控制服务”。这个服务暴露一个接口叫“SetWindowPosition”，你调用它，传入“左前窗、50%开度”，它自己搞定一切。
这里有个关键点：服务不关心谁在调用它。它只关心自己能不能把事干完。我在项目中遇到过一种情况，有人把服务设计成了“给特定ECU用的”，结果换了个域控制器，服务就废了。这就是没理解“自治”的含义。
- 自治性：服务自己管理自己的状态和逻辑
- 可复用：一个服务可以被多个消费者调用
- 无状态优先：尽量不保存调用者的上下文
- 细粒度：一个服务只做一件事，并做好
2.2 接口（Interface）—— 服务的“门面”
接口是服务对外暴露的“门”。你想想看，你去饭店吃饭，你不需要知道后厨怎么炒菜，你只需要看菜单、点菜。接口就是那个菜单。
在SOA里，接口通常用IDL（接口定义语言）来描述。比如我们常用的Some/IP、DDS、gRPC，都有自己的IDL。我建议你养成一个习惯：先定义接口，再实现服务。这能帮你把“做什么”和“怎么做”彻底分开。
我曾经在一个项目里，团队先写代码，后补接口文档。结果呢？接口和实现耦合得死死的，换个通信协议，代码几乎重写。嗯，这个坑我替你们踩过了。
// 一个典型的服务接口定义（以Some/IP为例）
service VehicleSpeedService {
version { major 1 minor 0 }
// 方法：获取当前车速
method GetCurrentSpeed {
output {
uint32 speed_kph // 单位：km/h
}
}
// 事件：车速变化通知
event SpeedChanged {
uint32 speed_kph
}
}
2.3 契约（Contract）—— 服务的“法律文件”
契约，说白了就是服务提供者和消费者之间的约定。它比接口更严格。接口只定义了“长什么样”，契约还定义了“怎么用”、“什么时候用”、“出错了怎么办”。
我个人的经验是，契约应该包含三部分：
| 契约要素 | 说明 | 举例 |
|---|---|---|
| 语法契约 | 接口的签名、参数类型、返回值 | GetCurrentSpeed() 返回 uint32 |
| 行为契约 | 调用顺序、前置条件、后置条件 | 必须先订阅事件，才能收到通知 |
| 质量契约 | 响应时间、可靠性、安全性 | 99.9% 的调用在10ms内返回 |
2.4 服务发现（Service Discovery）—— 怎么找到服务？
在传统架构里，ECU的地址是写死的。但在SOA里，服务是动态的。它可能启动、停止、迁移。消费者怎么找到它？这就需要服务发现机制。
服务发现有两种主流方式：
- 集中式发现：有一个中心注册表（比如SOME/IP的SD，或者DDS的Discovery Server）。服务启动时去注册，消费者去查询。
- 分布式发现：没有中心节点，服务通过广播或组播宣告自己（比如DDS的默认发现模式）。
我个人更倾向于集中式发现，尤其是在车载领域。为什么呢？因为车载网络相对可控，集中式发现更容易做权限管理和安全控制。我在一个项目中用过分布式发现，结果网络里服务一多，广播风暴差点把总线打爆。嗯，那又是另一个故事了。
2.5 服务编排（Service Orchestration）—— 把服务串起来
单个服务能做的事有限。真正的业务逻辑，往往需要多个服务协同完成。服务编排就是干这个的——定义服务之间的调用顺序和协作逻辑。
举个例子，自动泊车。你需要：
- 调用“环境感知服务”获取周围障碍物信息
- 调用“路径规划服务”计算泊车轨迹
- 调用“底盘控制服务”执行转向和加减速
- 调用“车窗/门锁服务”完成收尾动作
这里有两种实现思路：
- 编排（Orchestration）：有一个中央协调器（比如一个编排引擎或一个编排服务），它负责按顺序调用各个服务。这种方式控制逻辑清晰，但中央节点可能成为瓶颈。
- choreography（舞蹈编排）：没有中央协调器，每个服务知道自己该做什么，通过事件驱动的方式协作。这种方式更去中心化，但调试起来比较头疼。
好了，这一节的内容就这些。服务、接口、契约、服务发现、服务编排——这五个概念，是SOA的基石。你如果能把它们理解透，后面的迁移设计就会顺很多。下一节，我们聊聊具体的迁移策略，到时候我会拿一个真实案例来拆解。