3. 系统架构解析：整体分层架构、通信层、服务层、应用层、各层职责与交互

分布式软总线，说白了就是一套让设备之间“无感互联”的通信框架。很多初学者一上来就盯着代码看，结果越看越懵。我个人习惯是，先搞懂它长什么样——也就是架构。

今天我们就来拆解软总线的三层架构：通信层、服务层、应用层。每一层干什么、怎么交互，我都会结合项目里的实际经验来讲。

3.1 整体分层架构概览

先看一张整体结构图，我建议你把它记在脑子里。后面所有的开发、调优、排障，都离不开这张图。

这张图我画了很多遍。每次给团队新人讲架构，我都会先让他们盯着看五分钟。你想想看，三层结构其实很清晰：

• 通信层：管“怎么传”。TCP、UDP、蓝牙、Wi-Fi Direct，都是它的事。
• 服务层：管“找谁传”。服务注册、发现、路由，相当于通信录+调度中心。
• 应用层：管“传什么”。业务逻辑、数据格式、权限控制，都在这里。

3.2 通信层：地基中的地基

通信层是整个软总线最底层、也最容易被忽视的部分。我记得刚入行时，总觉得上层业务才是核心，通信层嘛，调调库就行了。结果第一次做跨设备文件传输，就栽了大跟头——Wi-Fi 信号一波动，连接就断了，重连逻辑写得一塌糊涂。

通信层要解决的核心问题有三个：

1. 连接管理：设备怎么建立连接？怎么保持连接？断了怎么重连？
2. 数据传输：数据怎么打包、怎么发送、怎么确认收到？
3. 协议适配：不同通信协议（TCP、UDP、蓝牙、CoAP）怎么统一接入？

实际项目中，通信层通常会封装一个统一的接口，比如 send(data, target) 和 onReceive(callback)。底层用 TCP 还是 UDP，上层不用管。我曾经在一个智能家居项目里，就靠这层抽象，把蓝牙和 Wi-Fi 两种通信方式无缝切换了——用户根本感觉不到。

3.3 服务层：大脑和调度中心

服务层是三层架构里最复杂的一层。说白了，它要回答一个问题：“我需要的服务，在哪个设备上？”

服务层包含几个核心模块：

模块	职责	我踩过的坑
服务注册	设备上线时，把自己能提供的服务登记到注册中心	注册信息过期了没清理，导致调用方拿到的是“僵尸服务”
服务发现	根据服务名称或类型，找到提供该服务的设备列表	广播发现太频繁，Wi-Fi 网络直接瘫痪
服务路由	从多个提供者中选一个最优的，把请求发过去	没做负载均衡，所有请求都打到了同一台设备上
会话管理	维护一次服务调用的完整生命周期	会话超时时间设得太短，大文件传输到一半被断开
安全认证	验证调用方是否有权限访问某个服务	认证放在应用层，结果通信层被绕过，安全漏洞

服务层和通信层的交互，我习惯用一个简单的伪代码来描述：

// 服务层调用通信层发送服务发现请求
service_discovery(service_name) {
    // 1. 构造发现请求包
    request = build_discovery_packet(service_name)
    // 2. 调用通信层发送广播
    transport_layer.broadcast(request)
    // 3. 等待响应（带超时）
    responses = transport_layer.wait_for_responses(timeout=3000)
    // 4. 解析响应，返回可用服务列表
    return parse_responses(responses)
}

你看，服务层只管“发什么”和“怎么处理结果”，至于数据怎么在网络上传输，那是通信层的事。这种分层的好处是，哪天你想把广播发现改成组播发现，只需要改通信层，服务层代码一行都不用动。

3.4 应用层：业务逻辑的舞台

应用层是离用户最近的一层。它直接面向业务场景，比如：

• 手机投屏到电视
• 智能音箱控制灯光
• 平板和手机之间同步剪贴板
• 多设备协同编辑文档

应用层的主要职责包括：

1. API 封装：把服务层的能力封装成简单易用的接口，比如 startDiscovery()、callService()。
2. 数据格式定义：应用层决定传输的数据长什么样——JSON、Protobuf、还是自定义二进制。
3. 权限管理：哪些应用可以调用哪些服务？需要用户授权吗？
4. 状态管理：设备在线/离线、服务可用/不可用，应用层要能感知并做出响应。

3.5 三层之间的交互流程

光讲理论不够，我们来看一个完整的交互流程。假设手机 A 要调用电视 B 的“播放视频”服务：

1. 应用层（手机A）：调用 callService("电视B", "playVideo", videoUrl)
2. 服务层（手机A）：查注册中心，找到电视B的 IP 和端口
3. 通信层（手机A）：建立 TCP 连接，发送序列化后的请求数据
4. 通信层（电视B）：接收数据，反序列化，交给服务层
5. 服务层（电视B）：解析请求，找到对应的服务处理器
6. 应用层（电视B）：执行播放逻辑，返回结果

这个流程看起来简单，但每个环节都可能出问题。我曾经遇到过：服务层找到了设备，但通信层连接超时；应用层发了请求，但服务层路由到了错误的设备。所以，每一层都要做好异常处理和日志记录。

3.6 架构设计的几个原则

最后，分享几个我在实际项目中总结的原则：

• 层间解耦：每一层只依赖下一层的接口，不依赖实现。这样你换协议、换序列化方式，都不会影响上层。
• 接口稳定：层与层之间的接口一旦确定，尽量少改。我见过一个项目，通信层接口改了三次，导致服务层和应用层跟着重构了三次。
• 异常向上传递：通信层的连接断开、服务层的路由失败，都要能传递到应用层，让应用层决定怎么处理——是重试、降级、还是提示用户。
• 可观测性：每一层都要有日志和指标。通信层记录收发字节数，服务层记录调用次数和耗时，应用层记录业务成功率。出了问题，能快速定位到是哪一层。