文章主要介绍了多绑定相关内容，具体如下：
多绑定概念
某个代理类 / 骨架类不同实例间的技术传输存在差异，多绑定用于解决该情况，其产生可能源于代理类与不同骨架通信采用不同传输 / IPC，或同一骨架实例的不同代理实例使用不同传输 / IPC 与该骨架实例通信。
简单多绑定用例
- 通信情况：服务消费者和服务提供者在同一节点（ECU 内部）通信，服务消费者有同一代理类的两个实例，触发 “FindService” 后为两个不同服务实例各获得一个句柄并实例化相应代理实例，服务实例 1 与代理实例 1 在同一 AP 应用程序中，服务实例 2 与代理实例 2 在不同 AP 应用程序中。代理实例 1 和 2 与各自服务实例通信的传输层颜色不同，意味着使用技术不同，前者在同一进程内可优化为简单方法调用，后者跨进程通信涉及复杂的 IPC 及系统调用。
- 信息传递与优化：从服务消费者开发者角度看，通过 ProxyClass::FindService 获取句柄并创建代理实例，但代理实例连接服务实例方式不同，句柄中包含能让代理类实例知晓选择何种传输技术的信息。在 SkeletonClass::OfferService 过程中，服务实例向注册表（服务发现）传递技术寻址信息，通常 AP 节点内部使用一种 IPC 机制（以 Unix 域套接字为例），骨架实例会将相应套接字连接文件描述符传递给注册表，服务消费者执行 FindService 时获取服务实例的寻址信息（句柄），句柄间区别主要在于文件描述符不同。代理实例 1 可通过检查句柄中是否含自身相同进程的 PID 来确定能否使用优化路径，检测进程本地优化潜力在现有中间件实现中较常见。
- 用例局限性：此简单例子虽描述了同一代理类不同实例使用不同传输层联系服务实例的情况，但只是一种优化，未完全反映多绑定含义，比如在该例中使用代理实例 1 通信的服务消费者也能用 Unix 域套接字传输与服务实例 1 通信，只是性能方面欠佳，不过因该场景真实且易在诸多部署中出现，所以值得提及并需得到良好支持。
