关于汽车SOA的思考（二 ）

上期聊到在汽车SOA的转型过程中，服务是随着应用的创新不断迭代出来的，那么本期就说说这种服务迭代过程中所面临的问题及解决思路。

首先说说传统的车厂设计习惯：整车设计是自顶向下的，简单点说，就是根据应用，去分解功能，将功能的最小集作为服务抽象的依据。整车应用有很多个，比如100个吧，每个应用能分解出10个“最小集功能”，将分解出的“最小集功能”做“合并同类项”操作，最后就只剩55个，那么这55个理所当然的就是“原子服务”了。

一般来说这种方法适合“一步到位”的产品定位，即一开始就把所有应用都考虑全，这样才能保证分解的“最小集功能”足够全且合理。

比如“座椅加热”是一个独立的服务，还是放在“座椅服务”中的一个参数，取决于整车中有没有类似“冬季模式”的应用。

也许你会觉得“冬季模式”的时候调“座椅服务”中的“加热”参数不就可以了吗，但这种“大颗粒度”服务不仅为应用开发者带来了麻烦（实践中有些车厂的某服务里面参数有好几十个！），同时可能也会影响安全（比如将“座椅服务”开放给第三方开发者，开发“远程备车”的时候，在夏天调用了“加热”参数有可能会着火！）；

但你又会觉得那就干脆把“座椅加热”做成独立服务就好了。但“座椅加热”这个功能通常是跟提升温度相关的场景有关，会与空调一起用，那么对于开发者来说，做“冬季模式”的时候需要分别调用“空调服务”和“座椅加热”两个服务，多麻烦！如果有一个“温度控制”服务，直接根据当前温度去控制空调与座椅加热的开关逻辑，是不是减少了很多麻烦！

其实，即使能把应用一次性想全，抽象出来的服务也仅适合这一个车型。换个车型，因配置不同，应用不同，也没办法保证服务的高复用性。

就算是只对这一个车型，未来的OTA中，也很可能出现已有服务无法满足的应用，所以这种自顶向下的方法有较大的局限性！

其次再聊聊软件供应商的思路：CAN信号是真看不懂啊，干脆把信号转成服务吧，S2S（signal to service），反正只要API文档写得详细，车厂把所有信号都服务化了，我们就可以创造无限可能！这种典型的自底向上的思路，最简单的原则就是“小颗粒度”，在“硬件功能”之上（不能真是信号直接转出来！），越细越好，反正我就在上层组合打包，乐高的1*2砖，可以组合一切！

“服务”是面向应用开发者的，传统的信号让大量的开发者陷入控制一个功能需要去思考很多个信号的组合（比如，空调需要“上电”“开关”“压缩机启停”等不同信号），但应用开发者其实主要精力是考虑什么样的场景去控制空调，需要的是一个简单易用的“空调服务”，通过简单的“温度”“风力”“风向”参数即可实现调用操作。

以上是两种截然相反的服务设计思路，各有各的道理，也各有各的问题，完全是设计者的专业背景导致的思维差异，是否可以求同存异呢？

车厂的优势在于可以判断安全相关以及以业务视角可开放的人群属性，从而判断服务在安全以及权限划分的合理性。且对硬件的了解，从硬件功能上归纳以“设备抽象”为基础的原子服务封装。

以“设备抽象”为基础的原子服务，可以作为车辆基本功能应用的“零部件”，这部分功能应用是由车厂开发，所以开发团队在专业视角下直接调用原子服务不仅可以保证其安全、稳定等要求，同时也减少了原有信号开发的繁琐。也就是说只要把设备抽象做好，形成稳定的原子服务，并做好车辆的基本功能应用，那这个车就可以出厂了，至少不会比传统开发模式下的汽车功能差。

软件供应商的能力在于抽象，从复用性视角判断服务的合理性，尽可能在服务高复用的前提下，确保开发者使用的方便性。

面向车机、云端等的创新应用，是由软件供应商、第三方开发者来实现的。他们懂用户、懂场景、懂创新，需要的是简单易用的功能调用。这就需要在设备抽象的基础上，把一切普通开发者很难理解的“前置动作”（比如空调需要先上电、开关、压缩机启停等）以及一些专业逻辑（比如除雾模式不光是对着窗吹，还要打开外循环），都封装在“业务服务”中，这样开发者只要根据场景去调用“调整温度”，“开启除雾”等业务功能即可。

这种“业务服务”就产生一个中间层，即在“原子服务”之上的“组合服务”，这种组合服务，会随着面向更上层的创新应用不断丰富而增加，就跟互联网中的开放平台一样，不断更新迭代，同时它又是以设备抽象为基础“原子服务”的使用者，充分复用了原有能力，这种以业务为基础的“组合服务”，正是软件tier1的能力范畴，这种能力不仅表现在“创新”“抽象”“实现”的层面上，更是深入到“管理”维度。

上期就讲过，随着服务的不断迭代，数量增加，碎片化是难免的。互联网开放平台为了避免API更新带来的碎片化，通常使用的方法有两种：

一种是版本隔离，即之前的应用就用1.0的API，新应用改用2.0，互不影响，但这种方法就造成了服务器资源需要增加，同时维护成本也随之增加，这种方式放在汽车这种算力及存储都有所限制的环境中，肯定不适合；

还有一种就是强制更新，就是API变化之后，说清影响及需要修改的内容，然后告知开放平台的所有开发者，让他们及时更新，然后两个版本并行，告知完全切换的时间点，不更新的就不再提供服务了，这种方式放在互联网中，只有超级大厂具有霸权地位可以为之。恰恰车厂的这种强供应链管理模式非常合适，毕竟车上的应用，就算是第三方应用，也是要经过严格的审核流程，而且车上应用比互联网开放平台应用的数量要小得多，所以管理成本并不高，当然，由于面向不同车型，同一个“组合服务”在不同车型的实现方法可能还是有差异的，这就需要将这种差异导致的服务管理起来，而这种管理应该算是IT管理范畴，对于软件供应来说易如反掌。

接下来的问题就是原子服务很稳定，不太需要更新；组合服务是随应用创新而不断更新的，那么服务到底应该放在哪儿能确保成本、效率、安全、管理的多维度要求呢？咱们下期再聊聊这个话题。

---

 文章首发于公众号：昊叔说车

原创不易，转载请告知原作者，注明出处。