SOA这个词出现在汽车行业具体是什么时间已经不记得了,大概在2018年初,因为做某日系品牌的车联网项目,我第一次编了个关于SOA的故事讲给车厂听。
因为在进入汽车软件领域工作前,做过很多年企业级软件项目,所以对ESB(企业服务总线)有一些经验与思考,恰逢刚刚入行汽车软件不久,本着无知者无畏的精神,很讨巧的将汽车软件与企业级软件进行了对比,发现两者具有极高的相似性:
财务系统是金蝶的,ERP系统是用友的,MIS是定制开发的……
动力系统是三菱的、变速系统是爱信的、制动系统是博世的……
多供应商、功能单元独立,但以业务视角来看还必须多系统协同,各系统之间有业务相关性时,面对的问题几乎是一样的:
点对点的方式让每个系统都不得不面对各种业务需求去改来改去;
每个业务流程都必须让多个供应商共同参与,沟通成本极高;
在传统的企业级应用领域,面对这种困境,就诞生了以SOA为理论基础的ESB(企业服务总线)技术,简单点儿说,就是各业务系统本身都是独立业务(功能)单元,对外只提供有限的、标准化的服务接口,而这种服务接口统一在一个“服务总线”内进行管理,任何业务流程中,如果需要什么功能,就在这个“服务总线”内去调用相关的服务接口。
比如财务系统,为了记录其它系统产生的“付款”或“收款”业务中的实际财务变化,则提供标准化的“付款”与“收款”服务即可,无论哪个系统中产生了财务数据变动,只需要调用这两个服务接口,即可实现财务系统的自动同步,无需财务系统再去配合开发。
同理,在汽车软件中的各功能单元也可以将其本身的能力以服务接口的方式开放出来,那么应用层的开发效率也将得到极大的提高。
当年在面对车联网项目时,因为业务本身基于云端,且对车内软件了解不多,而T-BOX可以提供有限车辆功能的服务接口,正好把这套概念拿出来应对,更自作聪明的放大了这个“云端汽车服务总线”的作用,想让T-BOX可以提供更多的车辆功能服务接口,然后车联网就可以从云端去“软件定义汽车”了……也就有了上面那页PPT。且不论以现在的眼光这种“汽车服务总线”放在云端是否适合,但这个故事在2018年还是听起来不错的。
恰巧2017年的时候AUTOSAR发布了AP,区别于CP的面向信号通信,面向服务的通信使得车端软件设计发生了巨大变革,而“汽车服务总线”的概念也随着AP的推广与普及,逐渐进入到车端软件开发者的眼中。
近2年,“SOA”、“服务化”、“服务组合”等已经在汽车软件领域变成了常用词汇,以企业、协会为单位也不断发布了不少“汽车原子服务”之类的白皮书或标准,这些文档中可以看到以软件为核心能力的供应商们,对车的“抽象”能力,但却不断有车厂在问:“原子服务是咋抽象的?”、“这种抽象合理吗?”、“设计万一不对咋办?”……
这一切问题仿佛是15年前,某国有大型保险公司,服务总线上跑着3000多个服务;某大型旅游公司,服务总线上跑着的服务名字叫:“酒店退订服务1”、“酒店退订服务2”、“酒店退订服务3”……,甚至出现了专门的“服务管理”岗位,因为没有人能说清哪个服务对应哪个业务!
这就是汽车软件马上要面对的问题:服务不是设计出来的,而是迭代出来的!没有人能去完美预测未来应用,所以很难设计出颗粒度、复用性都完全合适的原子服务。之所以会出现上面的问题,就是因为当新业务产生时,就会发现原来设计好的服务可能并不能完全满足新业务的需要,但原有服务又已被其它业务调用了,如果修改,可能会影响原有业务,所以只能又增加一个几乎一样的服务来,这样服务碎片化就越来越严重,管理难度也越来越高,最后出现一个恶性循环:服务越来越多,但复用性越来越低!
服务重构是解决问题的方法之一,但面对历史积累出来的,庞大且复杂的多系统业务平台,其成本是巨大的,风险也无法估量!企业级应用中,如果不是严重影响到核心业务,几乎没有见过全面的服务重构案例,即使有,也会经历一个漫长的双系统并行过程,IT部门不仅要增加巨大的成本,也要面临着巨大的压力。
因为汽车的功能绝大多数都是由硬件作为支撑的,在传统汽车软件开发中,也是针对硬件功能去做软件,那么抛开应用层来看,硬件所支持的最小功能范围就是构成服务的最小颗粒,比如座椅调节,可以更进一步细分为头枕调节、椅背调节、前后调节、上下调节等。
从理论上来讲,到了这个颗粒度,对于应用来说已经可以算是真正的“原子”了,但在应用层的实际开发中,如果一个座椅调整需要调用这么多个原子服务,作为开发者一定会觉得厌烦,所以合理的设计可能是把座椅中各项调节能力都放在一个服务中,通过多个参数去一次性调用完成。
那么又有新的问题,座椅加热算是座椅服务中的一个参数吗?四个座椅是放在一个服务中吗?高中低配车型的座椅可调节功能不一致咋办?
历史总是惊人的相似,面对SOA,车厂应该提前准备如何面对这些问题……
下一期我们来聊一聊如何解决问题,敬请期待!
文章首发于公众号:昊叔说车
原创不易,转载请告知原作者,注明出处。