SOA（Service-oriented architecture）是面向服务的架构，是IT行业在2000年左右的时候提出来的一个概念，其本质是一种架构的风格。而不是具体的技术，更不是具体的标准。

　　目前，在IT行业，SOA俨然已经成为了过时的东西，很少有人再去言必称SOA了，取而代之的是微服务、中台、去中台化，乃至云原生等一系列新的概念。究其原因，IT行业的业务在不断更新，技术也在不断升级，原有的架构概念已经不再适合当前的行业现状了。

　　任何架构都只能解决某一时刻的某一个企业的某一类问题，没有绝对的仙丹妙药。企图毕其功于一役的想法是幼稚的。因此，软件开发业内才有这样一句名言“软件开发没有银弹”（看过吸血鬼系列电影的朋友一定懂得银弹的含义）。

　　让我们回到汽车行业，当前中国汽车界在风风火火的进行着SOA“革命”，甚至成立了几个专门的行业组织来试图规范大家的SOA架构及其中的各种细节定义。回想当初AUTOSAR组织成立的时候，几个大的OEM和Tier 1在已有的基础上共同的定义了AUTOSAR的标准。而现在却有人在根本没有任何实践基础支撑的情况下就定义一个如此宏大的标准，有点令人匪夷所思。

　　正如我在《智能汽车：电子电气架构详解》一书中所说的：“所有的流程都是最佳实践的总结”。技术标准更是如此，如果没有最佳实践，怎么能够有总结呢？在PPT上总结的、未经实践考验的东西，怎么可能知道是不是最佳的呢？也许某些人真的有未卜先知的能力，但我始终相信“实践是检验真理的唯一标准”。而且我也担心中国汽车行业这几年通过电动化“弯道超车”好不容易获得的一点点优势被人整体带偏了。

　　IT行业的核心是数据和流程 

　　因为SOA起源于IT行业，那么我们就先看看SOA在IT行业是如何被提出和发展的。各位看官应该大都有以下这样的经历：

　　在你所经历的某些企业中有着众多的IT系统：比如，绩效管理系统、考勤系统、工资系统、报销系统等……这些系统最初大都是孤立的，办理不同的业务需要登录不同的系统，它们之间互不相连，账号也互不相通；以至于每天可能要打开N个系统才能正常工作。怎么解决这些系统壁垒呢？由于以上这些系统的底层数据都和员工信息之间相关的，因此，可以以员工信息为基础，在上述的业务之间进行打通，应用端形成统一的用户界面；在此界面背后，以往孤立的各个系统作为服务提供方仍然可以被持续使用——为了打通各个系统，就需要在应用端与服务提供端之间建立一条统一的服务总线，这条总线被称为ESB（Enterprise Service Bus，企业服务总线）。

　　有了ESB之后，就可以在这个框架下不断地拓展服务和应用，而且可以近似随意的在这个架构之上进行业务流程编排。原来的各个业务实体转变为服务，每个服务都是一个相对独立的实体，可以提供对某些数据所对应的业务活动的处理。这就是SOA。

（单个服务的内部结构）

　　然而，随着SOA解决方案复杂性的增加，潜在服务组合配置的复杂性也随之增长。提出SOA的目的是为了将应用与服务进行解耦，解耦的本质是为了去中心化。但是做好一个SOA解决方案的前提就是要将各个可能涉及的应用进行集中规划与考量，通过BPEL（Business Process Execution Language）来组装，同步对各个服务进行集中管理——这样的环节又会催生一队专职流程编排的Team来掌握所有业务行为，这群人需要具备架构设计、流程分析、系统分析的能力，因为所有业务变化都跟他们有关系，所以他们就很容易变成最大的组织瓶颈。

　　于是IT行业在十几年前便开始了新的探索与实践，提出了微服务（去中心化的SOA）和中台等一系列概念。

　　SOA的基本原则 

　　根据《SOA架构：服务和微服务分析及设计》一书的定义，SOA的设计应该遵守如下的基本原则：

　　标准化服务契约——同一服务目录中的服务符合相同的契约设计标准。

　　服务松耦合——服务契约降低消费者祸合需求，并且它们自身与它所在的周围环境解耦。

　　服务抽象——服务契约只包含基本信息，以及那些仅限于服务契约中发布的信息。

　　服务可重用性——服务包含并显示不可知的逻辑，可以定位为可重用的企业资源每当构建一个服务时，我们会寻找方法使其潜在能力得到最佳发挥而非仅仅针对一个目的。面向服务极大地强调了重用，因此它成为设计过程的核心部分，并且也是关键服务模型的基础。

　　服务自治——服务对其内部的运行时执行环境进行高度的把控。

　　服务无状态——服务通过必要时推迟状态信息的管理来最小化资源消耗。过度的状态信息管理可能会损害服务的可用性以及其行为的可预测性。

　　服务可发现性——服务补充了交互元数据，通过它们可以有效地发现和诠释服务。

　　服务可组合性——服务是有效的组合参与者，无须考虑组合物的大小和复杂性。

　　以上的基本原则，在IT行业都是基本适用的。因为一个企业内部的各个IT系统之间虽然有一定的关联性，但是基本上都可以独立运行，新增的服务也可以随时上线。因为各个服务之间的依赖性相对比较低。比如某宝上的商品货架管理服务与公益服务之间的关联性就很低。因为他们面向不同的数据源，而且业务相关性也不大。

　　汽车与IT的异同点 

　　近年来SOA的理念被引入了汽车行业，众多的参与者趋之若鹜。但如果从行业的特点来看，IT行业与汽车行业有着众多的本质差异：

　　1. 业务的控制对象不同。IT行业主要是面向数据（Data Oriented）。但汽车行业面向的却是硬件（Device Oriented）。

　　IT所处理的业务绝大多数是基于数据或数据库的，单一的数据记录可能是有状态的，但不同的数据条目却可以完全独立，从而形成一种无状态的情况。而且数据的访问是可以并发的。同时，IT的服务建立在一个基于互联网的开放生态系统之上的。其所使用的硬件主要是服务器和网络，具有标准化的特点，也就是可以随时进行扩展和迁移。

　　汽车行业上中软件控制的对象是各种非标准化的I/O设备，比如各种电机、电磁阀、传感器、按键等等。这些硬件是有状态的，而且是非标的，更加无法实现并发的访问与控制，天然的就无法满足服务无状态的要求。数据可以并发，硬件的状态却不可以并发，在某一个确定的时间只能有唯一的一个状态。同时，汽车生产之后再想加装硬件就基本没有办法了，即使可以增加内存和算力，但传感器和执行器却没有办法再增加了。（如果你非要说增加一个手机支架也算数的话，咱们就不需要再聊了）

　　2. 业务量变化速度不同。IT行业的业务量变化可能非常大：比如双11的时候比平时的业务量可能要高一个数量级。对于汽车而言，每台车上的业务量在设计之时便可以进行精确的估计，对拓展性的要求并不高。因为业务能力已经由其所匹配的硬件及其相应的功能限制了。目前看到对功能扩展要求比较高的只有多媒体主机。即使是智能驾驶的功能，也不是随意可以扩展的，更多的是对性能提升的要求，改变的是软件算法本身的能力。

　　3. 成本敏感度不同。IT行业软硬件都是被完全复用的、是集中化部署的，对于那些大企业而言部署几台服务器不重要，客户的满意度才是最重要的，客户使用服务的时候也不会关心后面的服务器硬件成本是多少。而汽车是单台售卖的，对于其中每个部件都是要计算成本的，客户买车的时候不可能不去关心成本。无论你部署一个控制器和两个控制器，只要功能不增加，就没人愿意为多出来的成本买单。

　　PS：采用SOA就必然要使用以太网等，大幅度增加了软硬件的成本。而且由于服务要耗费更多的算力资源，也必然要求SOC或MCU的性能更高，从而让成本进一步增加。

　　4. 实时性要求不同。大多数IT业务对实时性都没有什么要求，浏览网页或下单的时候等待一秒还是5秒的差异并不那么明显。但汽车上的大部分控制功能却是以毫秒来计算的，一个信息晚了半秒都可能会带来安全问题。

　　PS：在实时性方面，可能某些人要说以太网的速度远比CAN总线快，应该有更好地实时性。实际上，由于以太网本身的机制和需要多层复杂的软件处理，导致处理以太网的消息在很多时候比CAN总线等要慢的多，而且时间上也有一定的不确定性。

　　5. 业务重用度与功能迭代速度不同。IT行业的各个业务模块是随时可能被重用的，这一点只要看看微信等APP在不停增加的新功能就知道了。而在汽车上，尤其对于传统的车身控制、底盘和动力等板块，想创造出一个新功能难上加难，更加离不开新硬件的加入。大家可以看看众多来自IT行业的新势力在过去的这么多年里面究竟搞出了多少有价值的创新功能就清楚了。而且，这些新功能没有一个是只有通过SOA才能实现的。在这些领域搞那么多SOA就如同把一个人扔到一座荒岛之上，然后给他一百万美元，并且对他说：你随便花吧！

　　PS：功能迭代速度与业务量的差异也造成了IT行业的通信与汽车内网络通信的确定性不同。IT行业的网络通信是非确定性通信的：内容与数量随时都可能发生变化，在设计之初难以预测。而汽车上的通信都是设计好的，不会有那么多的非预期的业务发生，带宽也是可以准确估算的。

　　总结 

　　从以上的分析中可以看出：

　　汽车行业与IT行业有着诸多本质的不同点，如果非要生搬硬套IT行业的东西，不免有削足适履之嫌，必然会引起诸多的问题。

　　SOA在IT行业已经不是最新的东西了。如果想从IT行业借鉴一些经验，也许可以从微服务或者中台等技术入手，这两种技术也许更加适合汽车上的分布式、非标准、迭代速度慢的硬件系统，对于未来的集中式计算架构也许更加适合。

　　消费者绝对不会因为你是SOA架构就会更加青睐某个车，更加不会多掏钱。汽车行业内的自嗨和和自我感动与崇拜如果不能转换为商业上的成功，就必然沦为一场闹剧。

　　 在没有确定的把握时就把身家性命都压在某个尚未被证实的概念上，无疑是在赌博。万一这个概念只是对手的烟幕弹怎么办？将全车的几十个控制器全部重构的代价与投入是绝大多数OEM都承担不起的，如果你不是家里有矿，还是谨慎一些为好。

　　对于新技术，既不要盲目追逐，也不要完全排斥，适度投入跟随也许最合适。万一SOA变成了第二个元宇宙就不好玩了。

　　踏踏实实的把车做好比什么都强，每天都想着换道超车的结果往往是掉进沟里。

　　既然SOA最初的发展是面向数据的，那么就应该仔细想想汽车上的哪些功能数据强相关的，先尝试把这些东西SOA化，可能更加靠谱一些。

作者：红豆沙冰    

来源：http://www.51testing.com/html/61/n-7797561.html