SOA是什么？更专业的说法，SOA是一种软件架构风格。车载中间件产品也会有其软件架构及架构风格，SOA目前看来会是一个主流的趋势。
什么是软件架构，什么是架构风格，需要一个清晰的定义，这一章先从这里开始。
1.1软件架构组成与架构风格
在这里，我先引用两篇论文，
1、软件架构研究基础(FoundationsfortheStudyofSoftwareArchitecture[24])
2、架构风格与基于网络的软件架构设计ArchitecturalStylesandtheDesignofNetwork-basedSoftwareArchitectures[23]
1.1.1软件架构研究方法论
图1.1以UML类图的表示了组成软件架构的基本概念。注:简单的UML符号语意。
图1.1软件架构组成
软件架构由三个方面组成，架构元素，架构的组成形式，和一些形成架构的基本原则。
架构元素有三种:
处理元素：执行实际的功能性运算与数据转换；是“计算和状态的所在地”；是在运行时执行某种功能的软件单元。
数据元素：承载着被使用和转换的信息。
连接元素：将架构的不同部分结合在一起的粘合剂。我们用四个不同的领域概念类比来理解这些架构元素的含义。
架构的组成形式中包括“配置关系”与“约束属性”。“配置关系”是在系统的运行期间处理元素、连接元素和数据元素之间的关系结构。“约束属性”用于约束架构元素的选择。它于将架构元素约束到系统需求所需的程度。对应的实例如下表。
架构的一个潜在但不可或缺的部分是在定义架构时做出的各种选择的一些基本原则。在软件架构中，基本原则解释了如何满足系统约束。这些约束是由从基本功能方面到各种非功能方面的考虑因素决定的，例如经济性、性能、和可靠性等。
结合上面所述，我们可以把设计一个软件架构描述为：
根据我们需要构建的软件系统的约束需求，我们选择一组基本的原则，在这组原则的指导下，选择合适(约束符合)的架构元素（处理元素、数据元素连接元素）组成一个集合，并设计各种架构元素的关系结构。
不同的基本原则选择方式，会让软件架构呈现出不同的风格(Style)，我们称之为架构风格。一种架构风格是一组协作的架构约束，这些约束限制了架构元素的角色和功能，以及架构元素之间的关系。
当我们谈及某种形式的软件架构时，实际上往往讨论的是架构风格，比如说SOA。
每个架构设计决策可以被看作是对一种风格的应用，而一个软件架构往往会混用多种风格。
1.1.2软件架构的评估方法
一种架构风格是一组协作的架构约束，但是经常会出现一种情况，一种约束的效果可能会抵消一些其它的约束所带来的好处。没有完美的设计，获得某种优势的同时，可能需要在另一方面付出代价。所以我们需要一种评估机制去从多个方面去评估一个软件架构的特性，以便我们在不同的可能性之间进行权衡。
性能
性能往往是软件架构首先要考虑的方面，软件架构需要满足应用的性能需求。
这两者有时是有冲突的。好的架构风格要能在满足响应性要求的情况下，尽可能支持系统能够达到的较高的总效率。
性能也受成本的约束，在移动平台或车载平台，性能还受功耗的约束。
可伸缩性
可伸缩性要求架构能支持从小规模到大规模的平滑扩展。架构需要能够支持大量的组件以及这些组件之间交互的能力。可伸缩性能够通过以下方法来改善：
简化组件
将服务分布到很多组件（分散交互）
根据监视的结果对组件之间的交互进行动态控制
风格可以通过确定应用状态的位置、分布的范围以及组件之间的耦合度，来影响这些因素。
简单性
如果分配给单独组件的功能足够简单，那么它们就更容易被理解和实现，也方便进行测试。越简单的组件也越能够被重复使用。架构要能够支持将复杂的功能分解为很多简单的组件，同时还要能够交互协同以完成预期的功能。就是要拆得开，还能合得起来。
可修改性
可进化性：
一个组件实现能够被改变而不会对其它组件产生负面影响的程度。
可扩展性：
将功能添加到一个系统中的能力。动态可扩展性意味着功能能够被添加到一个已部署的系统中，而不会影响到系统的其它部分。提高可扩展性的方法是在一个架构中减少组件之间的耦合，比如基于事件或消息进行交互。
可定制性：
指组件可以为一个客户进行定制化扩展，而不会对该组件的其它客户产生影响。支持可定制性的风格也可能会提高简单性和可扩展性，这是因为通过仅仅直接实现最常用的服务，允许客户端来定义不常用的服务，服务组件的尺寸和复杂性将会降低。
可配置性
指在部署后对于组件，或者对于组件配置的修改，这样组件能够使用新的服务或者新的数据元素类型。管道/过滤器风格和按需代码风格就是典型的例子。
可重用性
一个应用的架构中的处理元素、连接元素或数据元素能够在不做修改的情况下在其它应用中重用。在架构风格中提高可重用性的主要方法就是是降低组件之间的耦合（对于其它组件的标识的了解）和强制使用通用的组件接口。
可见性
指对组件之间的交互进行监视或仲裁的能力。可以通过以下方式提高可见性：交互的共享缓存、通过分层服务提供可伸缩性、通过反射式监视（reflectivemonitoring）提供可靠性、以及通过允许中间组件（例如，网络防火墙）对交互做检查提供安全性。风格能够通过限制必须使用通用性的接口，或者提供访问监视功能的方法，来影响基于网络的应用中交互的可见性。比如在自动驾驶应用中，我们强制每个算法组件报告它接收数据、处理数据、发送数据的帧率。
可移植性
如果软件能够在不同的环境下运行，软件就是可移植的。标准的通讯协议，标准化的API接口都可以提高软件的可移植性。SOME/IP协议只管通讯的数据交换格式，可以兼容不同的通讯库的实现。AdaptiveAutoSAR标准将应用程序可以使用的系统调用限制为POSIXPSE51标准(参见4.3.1.1)，方便移植到不同的OS(Linux/QNX/VxWorks)；同时提供标准的应用API接口，支持基于AdaptiveAutoSAR的应用在不同的AdaptiveAutoSAR实现之间移植。
可靠性
从应用的架构角度来说，可靠性可以被看作当在处理元素、连接元素或数据之中出现部分故障时，一个架构容易受到系统层面故障影响的程度。架构风格能够通过以下方法提高可靠性：避免单点故障、增加冗余、允许监视、以及用可恢复的动作来缩小故障的范围。车载应用还有更高的功能安全要求。
1.2常见基于网络应用的架构风格
图1.2常见的软件架构风格之间的关系
图中偏左侧黑色粗框标识的是几个基础风格，包括“客户-服务器，管道和过滤器、多副本，分层系统，虚拟机/解释器；基于事件的集成”等。其它风格是对这些基础风格的继承（或称为扩展），有的风格是继承自多个基础风格。
每个风格上部以淡粉色标注的标签表示正面的评估结果，如改进“网络性能、可伸缩性、可靠性等”，下部以淡青色标注的标签表示负面的评估结果。这里我们不会逐一介绍每个风格，而是在下文对SOA风格的推导中叙述涉及到的风格。
1.3面向服务(SOA)的架构风格推导
汽车软件最近开始了向SOA转型的趋势。从软件架构角度看，SOA是一组软件架构风格的统称。严格来说，SOA并不是一个单一的软件架构风格，而是一系列各具特点的软件架构风格的综合运用，其中每一种架构风格都推崇架构元素之间的一种特定的交互类型。
我们从一个空的架构风格开始，逐步增加新的约束，从而推导出SOA的架构风格，并结合车载软件和自动驾驶软件的特点来做进一步的说明。
图1.3空风格
1.3.1“客户-服务器”风格
现代车载软件以及自动驾驶系统极为复杂，需要很多家不同供应商开发不同的软件组件。客户-服务器风格以服务界定功能边界，不同供应商开发按照预定义的接口实现特定的服务，为其它组件提供服务的同时也使用其它供应商开发的服务组件，只要接口定义好，多个不同的供应商的软件组件就可以协同工作。
图1.4SOA：客户-服务器
1.3.2状态分离与局部化
1.3.2.1程序“状态”的含义
“状态”这个词被用在很多地方，其含义往往有很多细微差别，容易被混淆。这里所谓的状态是指“某个软件组件内部包含的数据信息，这个数据信息会影响外部对这个软件组件发出请求的响应结果”。
假设有一个加法器A，提供了两个接口：1、设置初始值2、增加n并返回结果我们给加法器A设置初始值0，然后每次加1，返回的结果是不一样的。
对另一加法器B，提供如下接口：输入两个操作数，返回其加法结果对加法器B而言，只要每次给出相同的输入数据，返回的结果是一样的，不依赖于加法器B的内部数据。
加法器A内部就保存了程序状态，假如多个客户端并发进行访问，取得的结果就会互相干扰。加法器B就是我们常说的无状态服务器，所有状态数据保存在客户端的请求中，多个客户端并发调用互不影响。这样就允许我们复制部署多个加法器B，分担承接大量并发请求。
图1.5不同架构风格的状态与交互耦合程度的分布
状态偏向服务端的极端案例是“远程会话”风格，每个客户端在服务器上启动一个会话，然后调用服务器的一系列服务接口，最后退出会话。应用状态被完全保存在服务器上。如:FTP服务,Telnet服务等。
状态偏向客户端的极端案例是“客户-无状态-服务器”风格，从客户端发到服务器的每个请求必须包含用于理解请求所必需的全部信息，不能利用任何保存在服务器上的上下文(context)，会话状态全部保存在客户端。
其它设计风格的“状态分布”模式处于两个极端中间。加入缓存机制的设计风格部分状态保存在客户与服务器之间的缓存机制上。分布式对象为基础的设计风格，状态主要保存在远程对象中，偏向服务器。“管道和过滤器”风格和“基于事件集成”风格没有明显的客户和服务器端，状态保存在各自组件中。
1.3.2.2SOA服务的状态分布选择
前面说的是程序状态分布的通用概念。现在回到车载软件SOA风格。我们新增一条约束，“分离强状态服务与无状态服务，并控制状态在局部范围”。
这个约束的核心含义有两点：
1、一个是无状态服务与强状态服务要分离在不同的服务中
2、每一个服务要么是无状态，要么是强状态，避免中间路线。
无状态服务会显著改善服务的可见性、可靠性和可伸缩性。改善了可见性是因为监视系统仅仅只需要对单个请求进行分析就能得到其全部特质，不需要关心其它请求。改善了可靠性是因为它让从局部故障中恢复所需要做的工作减少了。改善了可伸缩性是因为服务器不必在多个请求之间保存状态，请求结束就可以迅速释放资源。服务器的实现得到简化，负载均衡也容易实现[23]5.1.3。
虽然无状态带来了诸多好处，但是在应用中状态依然是存在的。某些自动驾驶功能其状态往往需要用复杂的“有限状态机(FSM)”来定义。那如何来设计这些对状态强依赖的服务。解决的办法是：
1、在服务划分上分离无状态服务与有状态服务
2、将状态限制在服务的局部范围，即少量特定的SOA服务
在服务划分上，我们应该尽量把能够进行的无状态化处理的服务识别出来，并按照无状态的方式去定义其服务接口并实现。而把涉及到复杂状态转换的部分集中在一个独立的服务中。不同的有状态服务之间，其各自涉及的状态范围应该是正交的，即不同服务的状态相互无关。各自服务将状态限制在自己服务本地，甚至还可以对外呈现出一定的无状态特征。
例如，对于一个ACC应用，涉及的服务可以简化的分解为如图1.6所示的多个服务(只是简化表示)。我们可以把ACC状态机集中在一个ACC会话服务中。它所依赖的其它服务是无状态的，只是根据输入产生对应的输出。
SOA服务划分的无状态和有状态的分离，在形式上与函数式编程范式中的纯函数与副作用的分离相对应，只是描述的是不同粒度上的架构问题。所以也可以在前视算法服务内部再做更细粒度的状态分离。
也就是说，向“前视算法服务”这样的轻量级状态可以通过内部或外部的进一步分解来做到真正的无状态。服务划分得过于零碎，会导致服务部署配置的难度和额外的通讯开销，但这可以通过其它的技术优化手段来解决，后文会详述。
图1.6参与ACC功能的服务(简化图)
设计某一个具体的车载SOA服务时，对服务状态分布的选择最好在强状态的“远程会话”和“无状态”两个极端风格中二选一。应该避免在客户端和服务端都维护状态数据。
图1.7SOA：客户-服务器-状态分布
1.3.3服务发现
复杂的软件系统被分解为大量小规模的服务后，服务之间也会有很多依赖关系，某个服务同时也会作为客户端访问其它服务。一个客户端访问另一个服务，需要知道该服务的访问点，对于TCP/IP协议栈来说，至少包含IP和Port信息。同时，还需要知道该服务是否可用。因为服务可能还未启动，或者在启动中，或者因为某种原因停止了服务。
服务的访问点是可以通过配置文件静态配置的，如果系统中只有几个服务静态配置难度还不大，如果服务数量上升到几十个甚至更多，静态配置的维护难度就非常大。
某个服务启动时，为了它所依赖的服务已经就绪，就需要对服务的启动顺序进行管理。这对大量服务并存的系统也是很难做到的。
因此，我们给SOA架构风格增加一条约束“每个服务具备能被其它服务发现的能力，也能查找需要使用的其它服务”。
所谓实现被其它服务发现的能力，意味着该服务应该至少具备一下两个能力：
1、服务可用性状态发生变化时能通知其它服务
2、响应对服务可用性的查询
第1条是事件发生时的主动通知，不关心谁接收。第2条是主动响应对本服务可用状态的查询。这也意味着每个服务需要维护自己的可用性状态。
图1.8SOA：客户-服务器-状态分布-服务发现
除了事件性的通知机制，“服务发现”也需要包括主动查询服务可用性的能力。上图显示了在SOA架构风格上增加“服务发现”后的图示和约束。
相对于静态配置，“服务发现”实际上提供了动态配置的能力，提高了系统的可维护性和可配置性。因为服务不是静态配置的，当一个服务失效时，可以很快的用另一个相同功能的服务替换掉它，新服务的访问点信息会很快在系统中被其它服务获取，系统可以很快能从服务失效引起的错误中恢复，提高了系统的可靠性。当某个服务需要被升级时，也可以采用类似的方式进行，对系统的可进化性也有显著帮助。
1.3.4基于“事件/消息”发布订阅
我们再增加一条约束，“服务之间支持基于‘事件/消息’的发布订阅机制，以降低服务之间的耦合性。”
关于这个约束有很多称呼方式，含义接近但又各有侧重点，如：事件总线(EventBus),消息通讯，发布订阅模式等。
“事件总线”和“消息通讯”都可以实现“发布/订阅”模式。这里发布者和订阅者之间只共享“事件名称”，或称作“消息主题”。发布者按主题发布消息，不关心谁会收到；订阅者按主题接收消息，不关心消息从哪里来。
这种特性让软件模块的测试也变得非常方便，我们可以在非生产环境中发送模拟的消息来测试软件的功能。可以录制生产环境的消息然后线下回放来做仿真测试。
图1.9SOA：客户-服务器-服务发现-发布订阅
“发布/订阅”风格显著降低了系统各组件之间的耦合度。添加订阅某个主题消息件的新组件变得非常容易（可扩展性）、只要组件接收或发送消息格式（接口）确定，该组件就可以被用在任何支持这个消息格式的场合（可重用性）；允许组件被替换而不会影响其它组件的接口（可进化性）。发布订阅风格为可扩展性、可重用性和可进化性提供了强有力的支持。
发布/订阅的一个缺点是：难以预料一个事件将会产生什么样的响应（缺乏可理解性），事件通知并不适合交换大粒度的数据，而且也不支持从局部故障中恢复。
上图为我们的SOA架构增加了基于“事件/消息”发布订阅风格。多个服务之间有相互交互的方式，交互方式有基于RPC的“请求/响应”，也有基于“事件/消息”的发布订阅方式。
1.3.5服务代理
车载软件发展了几十年，有大量的稳定成熟的既有代码。车内广泛使用的网络总线也有Can、Lin、FlexRay等很多种，连接在这些网络上的ECU很难去支持服务发现、发布订阅等机制。对于这些成熟的既有系统，可以为它们增加一个代理服务。代理服务仍然按照原有的方式(如:Can总线)跟既有系统进行通讯。但是代理服务对外可以以独立SOA服务的方式呈现，提供标准的访问接口，接口暴露既有系统可以开放的部分能力。下图在SOA架构风格上增加了服务代理风格。
图1.10客户-服务器-状态分布-服务发现-发布订阅-代理
服务代理还带来另一个好处。被代理的软件模块被隐藏在代理服务后面，可以单独进化。比如采用不同的技术路线网络总线重新实现。
但是服务代理作为额外的间接层会降低效率和用户可察觉的性能。所以服务代理暴露出哪些原有软件模块的功能需要仔细选择。比如，被代理的模块是一个实时性要求很高动力系统ECU，那就没必要把该ECU的高实时要求的控制信号暴露出来，只应该暴露出实时性要求不高的状态发布的等信息接口。
1.3.6服务装配
在进行服务划分的时候，我们希望把每个服务设计得尽可能功能单一，这样服务简单，方便开发、测试和复用。但是会造成服务数量变大。
在服务可以执行之前，它必须被加载到应用程序（操作系统进程）的地址空间中。如果每个服务一个进程，如果有上百个服务，就会造成操作系统中运行着上百个进程，争抢系统资源。相当与把服务调度的工作交给了操作系统，让操作系统的进程调度代为执行服务的调度。我们知道，操作系统的进程切换是开销非常大的操作，也无法保证调度的精确性。比如，我们希望一个服务每秒钟执行30次（软实时），当有上百个繁忙的进程在系统中执行时，操作系统的进程调度策略是无法保证这个服务的调度要求的。
解决问题较好的办法是动态服务装配机制。每个服务开发时并不是被预设为单独的进程，而是一个可以被动态加载的模块。(如：动态链接库Windows上的DLL或Linux上的SO文件）。在服务部署时才决定哪些服务被装配到同一个进程中。也可以在运行时才根据需要的加载服务，并在利用完成后卸载。甚至可以让服务在不同进程、不同操作系统中迁移(从一个进程中卸载，在另一个进程中装载)。
图1.11客户-服务器-状态分布-服务发现-发布订阅-代理-装配
“服务容器”本身也可以被设计成SOA服务，提供服务管理接口，用于加载、管理其它服务。所以图中“服务容器”继承自“服务器”，多个“服务器”又可以装配到“服务容器”。
服务装配还带来另一个优点，就是为服务之间的数据交互提供了优化的空间。虽然我们默认采用通过网络进行数据交换。但是当两个服务部署在一个进程内时，显然有更合适的数据交换通道。后文会进一步讨论这个问题。
1.3.7服务监督
对SOA服务而言，我们需要对服务的“生命周期”、服务的“健康状态”还有“服务质量”进行监督管理。
图1.12SOA：客户-服务器-状态分布-服务发现-发布订阅-代理-装配-监督
管理服务的“生命周期”是指要决定什么时候加载、启动服务，什么时候关闭、卸载服务。当系统中只有少数服务的时候这个问题可能不是很严重，简单的系统就是启动时所有服务都起来。但是当部署了几十上百个互相依赖的服务后，服务的“生命周期”问题就很重要了。
尤其车载ECU需要对功耗进行控制，当前场景不需要的服务应该尽可能不启用。比如，泊车场景需要使用环视摄像头的图像识别车位线，当判断车辆行驶在高速公路上是，车位线识别的算法服务显然没必要加载。当车辆到达导航的目的地附近时，车位线识别服务可以被预先加载，但是不激活(执行算法识别)，当用户启用泊车功能时，算法服务开始工作，泊车过程结束，算法服务停止计算。
图1.12是在我们的SOA架构风格中增加的“服务监督”风格。监督服务本身也是一个SOA服务，只是有自己定义的标准化服务监督接口。所以图中“监督服务”继承自“服务器”。监督服务与服务容器和其它SOA服务通过监督接口进行交互。
1.3.8RESTfulAPI
对于互联网行业的开发人员来说，REST以及RESTfulAPI是司空见惯的事情。REST设计风格以及基于REST的HTTP协议是互联网软件架构基础。REST是一个庞大话题，参考资料[23]中有详述，这里不多介绍。RESTfulAPI是基于REST的原理，基于Http协议实现的API设计原则，遵循这些原则，可以设计出清晰简洁易于维护的API接口。
更为重要的是，各种异构系统，如果能够对外提供基于HTTP实现的RESTfulAPI，就可以在更大范围内做应用系统的集成。比如各大云服务提供商(AWS,阿里,百度等)，都为它们的各种云基础设施提供了RESTfulAPI接口，我们就可以很方便的使用程序去管理我们的云端资源（如创建一台云主机，读取或更新数据库）。
图1.13SOA：客户-服务器-状态分布-服务发现-发布订阅-代理-装配-监督-Restful
现代智能网联汽车会与互联网有非常多的数据交互，这些交互不像车内通讯要求有很高的实时性，但是外部系统确有复杂的多样性，我们可以为某些服务提供RESTfulAPI，以便能更好的与外部系统集成。图1.12在SOA架构风格中增加了RESTfulAPI约束。
RESTfulAPI设计有一些指导原则，可以参见MicrosoftRESTAPIGuidelines。这里做一些简要的说明。设计RESTfulAPI首先要做好URI的规划，需要把服务中的概念映射成合适的URI。比如我们给娱乐系统的音量设计一个URI来表示，那就可以对这个URI使用HTTP的GET和PUT方法来读取和设置音量值。
HTTP协议的操作方法很少，只有9个。RESTfulAPI最常用的方法主要是GET、PUT、POST、DELETE，使用这几个方法就可以完成常见的CURD操作(create，update,read,delete)。这些操作方法如何映射到SOA服务的方法有一些基本的原则，这里结合SOME/IP来做一些说明。
HTTP的GET方法有一个要求，就是它不应该改变被调用的服务的状态，它只是读取一个URI的值，而不会改变它。PUT方法有一个特点，其任意多次执行所产生的影响均与一次执行的影响相同，数学上管这个叫“幂等”(GET/PUT/DELETE方法都是“幂等”的,但只有GET不改变状态)。SOME/IP协议中与之对应有同样特性的是Field。所以对于服务中的Field字段应该映射为RESTful的GET/PUT方法进行操作。
SOME/IP中的Method应该映射为对某个URI的POST操作。RESTful推荐用良好的URI规划来更准确的表达领域的语义。所以比较合适的方式是每个Method有其URI，Method的参数和返回值体现在POST方法的提交数据和响应结果上。
SOME/IP的Event映射为RESTfulAPI时比较麻烦，因为HTTP1.1协议是不支持向客户端主动通知的，不过有变通的WebSocket方案，HTTP/2是可以支持的，都需要由客户端向服务器发起GET请求，服务器有需要向下通知的数据时就返回数据内容。
这些就是SOA服务转换为RESTfulAPI的基本映射方式。一般来说并不需要为所有服务设计RESTfulAPI，只为需要与外部系统集成的服务提供RESTfulAPI即可。
1.3.9可选的其它风格
“虚拟机/解释器”风格
这里的“虚拟机”指的是受控的代码执行环境，比如JavaScript虚拟机，Lua脚本解释器等。服务器向客户端下发一段代码，客户端在严格受控的执行环境中执行代码。这个受控的环境只能访问指定的资源，对资源的访问权限被限制在预定义的范围内。
对车载应用来说，对这种方式的需求往往出现在与云端有交互的场景。因为“虚拟器/解释器”可以先部署到车上，易变的需求可以后续由云端下发代码来满足，这在车载娱乐系统中会很常见。我们举一个为自动驾驶服务的数据采集场景来说明。
自动驾驶的很多算法以及测试场景非常依赖对数据的收集，相对于专业的采集车，量产汽车可以提供更为真实的数据案例，更广的覆盖范围。采集并上传哪些数据需要一些规则进行控制，否则没有针对性的大量数据上传会对带宽占用、数据存储、数据分析带来不利的影响。
可以在车辆量产时内置数据采集和上传的能力，以及检查采集规则的规则引擎。具体的采集规则由云端根据需要下发。比如视觉算法需要改进对雨雾天气的识别效果，就对出现雨雾天气的区域车辆下发采集规则的更新。车辆数据采集服务接收规则本地执行，触发数据采集事件。这样采集的数据内容可以根据需要随时调整，带来了较好的灵活性。这时规则引擎就相当与一个受限的解释器，下发的规则内容就是被执行的代码。
“远程求值”风格
“远程求值”风格跟“虚拟机/解释器”风格正好相反，是客户端把代码送到服务端执行。同样，这种方式的需求也出现在与云端有交互的场景。之所以把代码送到服务端执行，是因为执行所需要的数据在服务端。这些数据或者是因为数据量大不便传输，或者是因为数据安全或数据隐私的原因，不能被下发给客户端。客户端可以将代码发送到服务端执行，利用数据，取回结果。
这种方式在智能网联汽车的“车路云协同”上是有应用场景的。根据需要，联网的路侧单元至少可以保存道路沿线一定距离内的道路、车辆等信息，云端的服务器可以保存更大范围内的交通状况数据。这些数据都不方便直接发送给行驶中的车辆。当然路侧单元和云端服务器都可以根据自己保存的数据提供一些预定义的服务，供车端调用。但是更灵活的方式，是开放执行环境，由车端上传代码来决定如何利用数据。当然被执行代码的权限也会被限制，执行环境也会是一个受限的沙箱。
这种方式优点是能够定制服务器组件的服务，这改善了可扩展性和可定制性；代码直接在服务端执行，减少了服务器与客户端的交互能够得到更好的效率。由于客户端发送代码而不是标准化的查询，因此缺乏可见性。服务器如何信任客户端，如何控制执行环境的安全性也需要考虑。这会对服务的部署带来难度。
1.3.10小结
这一节通过对SOA架构风格的推导，阐述了车载软件的SOA风格并不是一个单一的架构风格，是一系列软件架构风格的组合。
对于车载软件，我们首先考虑的是如何降低其复杂性，划分为依赖性尽可能小的多个服务，是一种化整为零的方法。为了让服务尽可能简单，需要考虑服务的状态分布，强状态依赖的功能集中在特定服务，让其它服务以尽量以无状态的方式设计，以利于整体系统的开发、测试、复用。服务发现用来简化大量服务的配置，基于事件的发布订阅让服务之间的通讯偶合性降低。服务装配用于更好管理服务的部署，服务监督让服务的可靠性得到保障。
RESRfulAPI增强车内服务与外部系统的互操作性。这些软件架构风格很多都是在各个领域得到了广泛应用，以各种不同的形式存在。针对特定的应用场景，选择不同风格的组合，发挥各自的优势，往往能产生1+1>2的效果。
1.4SOA的架构元素
前文3.1.1节提到，软件架构由三个方面组成，架构元素，架构的组成形式，和一些形成架构的基本原则。前文SOA推导时每一步都对此三个方面有一些体现。这里我们再从整体上来对架构元素的区分以及其组成形式做一些分析。架构元素分为“处理元素”、“数据元素”、“连接元素”。
尤其在无状态服务中，多个RPC请求之前没有状态上的关联性，SOA服务的数据处理能力就更为“纯粹”(函数式编程的中的概念，也称作无副作用)。大型系统在设计时，考虑问题的视角就是如何寻找合适的数据边界以界定服务边界，而不是对领域进行对象建模，这与分布式对象系统是完全不同的设计理念。与分布式对象的对比，在1.5.1节中还有进一步的讨论。
开发SOA架构中的“处理元素”是某个具体SOA服务的开发人员的职责，我们希望开发人员专注于这个具体数据处理的实现，比如某个AI算法，某个数据集的MapReduce过程。而数据从哪来，到哪去，开发人员不需要关心，这由SOA的“连接元素”来负责。
在实际工程实践中，SOA服务的开发者并不会完成全部的从数据处理到数据通讯的全部工作，而是要借助分布式中间件系统来实现。中间件提供Runtime库，IDL规范，程序语言特定的代码生成工具。使用IDL定义出数据通讯协议后，再用工具根据IDL生成代码。用户编写“处理元素”，使用IDL生成的代码与外部通讯。这时候，IDL生成的代码和中间件Runtime就扮演了“连接元素”的角色。它从通讯通道接收数据传递给“处理元素”，将处理的结果发送给需求者。
也就是说数据的处理不应该依赖于特定的连接方式。架构师甚至希望只需要提供给开发团队模拟的连接方式并回放预先录制的数据，开发团队基于这些来实现其数据“处理元素”。“处理元素”的完成品可以被架构师集成到真实的应用环境中，那时使用的可能是不同的连接元素。
中间件Runtime能够使用SOME/IP、DDS、共享内存等各种不同连接通道；工具根据IDL生成的代码完成用户代码和中间件Runtime的连接；服务发现让服务的位置不是固定的而是可以被配置、可动态发现的，这些都是在发挥“连接元素”的作用。
1.5.1SOAvs分布式对象
分析SOA，如果跟分布式对象做一些比较，可以更好的理解SOA的意义。我们在1.2节提到的架构风格中有“分布式对象”风格。前文也提到CORBA和ZeroCICE都是分布对象的实现。
SOA和分布式对象都是分布式网络架构的实现形式。只不过一个是ServiceOriented，一个是Object-Oriented。我们来看看他们有什么异同，为什么车载软件选择Service-Oriented而不是Object-Oriented。
面向对象（Object-Oriented）是非常重要的软件设计思想。当软件规模进一步复杂后，“结构化编程”方法也体现出一定的不足。面向对象的设计思想是解决这些问题的方法论之一。
从C++开始，大多数程序设计语言都支持面向对象的方法论。它把数据和处理数据的方法封装在一个对象中，可以用来与具体的现实事物或抽象的语义概念进行对应。提供了对现实问题或语义概念进行建模的可能，用来描述复杂的软件语义。
程序语言创建的对象是本地对象，即访问对象的内部数据和接口方法都是当前进程内的行为，不涉及网络通讯。当面向对象的设计理念在本地编程获得成功后，人们很自然的会想到，在分布式领域中是不是可以使用类似的方法。一个对象封装了数据和操作方法，部署在某个服务器上，客户程序通过网络进行访问。
在客户端也提供本地化的API接口，使用这些API时跟访问本地接口一样，但是请求会被自动代理到服务器上的某个对象。这就是分布式对象的由来。CORBA标准建立之初，人们曾经认为这将是未来主流的分布式技术。但实际上世界上最大的分布式系统万维网(WWW)，并没有采用分布式对象。车载软件的分布式化选择了SOA，也没有选择分布式对象。我们从几个角度来探究其背后的原因。
1.3.2节讨论了程序状态在客户端和服务器端的分布情况对软件架构的影响。我们倾向于将服务设计成无状态的。这在WWW的架构中尤为重要，这是WWW世界能成为超大规模系统的关键原因之一。
分布式对象将数据与操作接口封装在一起，也意味着它将状态留在了服务器端。从这种意义上看分布式对象架构风格与远程会话风格有点接近，每一个远程的分布式对象自身就是一个小的会话。对于同一个远程对象的多次方法调用，都要精准的找到这个对象所在的位置。
对于WWW来说，这种方式会严重影响其可伸缩性。WWW中，每一次请求的无状态特性可以让一个负载集群系统中的任何一个空闲的服务器都可以处理任何请求，而不需要一定让多个请求必须绑定到同一个服务器。
对于车载软件来说，虽然整体系统很复杂，但是到单个具体的服务点，其功能往往是很单一的，处理逻辑的复杂度远远小于电子商务等系统。很多时候就是接收数据，做简单处理，然后发送数据。面向对象的建模对这些简单功能来说带来了不必要的复杂度。无状态的服务设计方式能让系统大大简化。
不同对象的接口差异大
面向对象的设计方法很重要一点是对行业领域进行建模，分析出各种对象类型以及它们之间的关系。不同类型的对象就包含不同的状态数据以及不同的操作接口。
对象类型多、接口各不相同对于开发本地应用来说不是大问题，因为一般应用程序也就几十的对象类型，即便几百个也是在可以处理的数量级内。但是对于WWW系统，可能会面临几千万甚至更高数量级的对象类型，没人能处理这么复杂的系统互操作。
WWW采用的REST架构的一个关键设计约束是统一接口，实际只有GET,PUT,POST,DELETE等有限几个操作方法。仅仅这几个操作方法就能完成WWW上各种复杂的功能，非常的神奇。奥妙在于WWW使用URI（统一资源标识）重新定义世界。
WWW上的每一个事物(简单的文件、图片；或者订单、人等各种语义概念)都可以使用一个URI去表示。世界的复杂性从对象模型的关系，转换到了树形的URI表示，从而采用简单的操作方法完成所有可能的操作需求，如果不能满足，就再拆解出一个合适的URI形式。
对于车载软件来说，服务的类型数量也是在一个可控的数量级，并不需要URI机制去简化接口形式。但是如前文所说，当汽车软件需要与云端或者互联网体系进行数据交换时，可以把车载软件的部分服务包装成RESTful接口遵循WWW系统的架构风格。
对象生命周期管理复杂
无论是本地对象还是分布式远程对象，都会有一创建、初始化、工作、失效、销毁的完整生命周期。对于分布式对象来说，其生命周期管理非常复杂。比如，当一个客户端请求某个对象的服务是，这个对象可能不存在，那么这种情况下如何处理也需要被考虑。
一般来说这种对象生命周期管理能力是由中间件系统来提供，CORBA，J2EE规范中都有对应的内容。会导致中间件实现的复杂度。
比如某个服务内部确实需要保存多个不同对象(或会话)的实例，那么可以提供类似“createXXX”的接口并返回对象的句柄，然后在其它的接口方法参数中带上这个句柄。服务实现时根据这个传入的句柄去找到对应的对象进行操作。至于对象的生命周期，服务开发者自己想办法维护。而不需要在中间件这一层提供架构级别的解决方案，因为投入与收获不匹配，并且带来不必要的复杂度。
1.5.2RPC消息通讯管道的技术关联
RPC是“客户-服务器”架构风格实现请求响应的典型方式。“基于消息的通讯”(或者叫基于事件的集成、发布订阅模式)及“管道和过滤器”本身也是常用的架构风格。这三者是架构组件之间数据通讯的方式。从架构风格的组件耦合程度看，RPC耦合度最高，管道模式次之，发布订阅耦合度最低。但在具体实现上，这三者之间很大程度上可以互为实现。
基于RPC实现发布/订阅
如果我们实现了“客户-服务器”之间的RPC机制，我们可以利用它来构建发布订阅系统。ZeroCICE支持的发布订阅服务IceStorm就是这么实现的。但是这个发布订阅是通过中心节点进行中转的。
如图1.14所示，“接口A”定义了一个RPC接口，在普通的基于RPC的“客户-服务器”系统中，客户端直接调用接口A，服务器获取数据进行处理。当转换成“发布/订阅”模式时，引入中转服务：
1、中转服务提供基于主题(Topic,可以是一个字符串名称)的Publish和Subscribe接口。中转服务对每一个主题维护订阅者列表。
2、订阅者通过调用中转服务的Subscribe接口将自己注册到中转服务中，以订阅特定主题。实质上就是告诉中转服务自己对哪个主题感兴趣，告诉它回调自己的访问点(IP，端口等)。
3、发布者按主题发布数据，实际是对接口A的一次RPC调用，但是带上了主题名称，方便中转服务识别。
4、中转服务并不识别并执行发布者的请求，只是根据主题名称将请求转发给订阅者。接口的适配（参数定义，版本匹配）由发布者和订阅者自己保证。
以上实现“发布/定义”方式的缺点是有中转服务，一方面存在单点失败的可能，一方面两次数据传输有额外的网络性能开销。另外只适合没有返回值的RPC调用。优点也很明显，可以方便的把RPC服务转换成“发布/订阅”模式，能够方便的达到解耦和发布者和订阅者的目的。中转服务是与特定接口无关的，也就是说任何RPC接口都可以这么转换。因为中转服务不需要识别接口内容，只是单纯的做数据报文的转发，不做序列化和反序列化动作，所以可以适用于任何单向RPC接口。
基于发布订阅实现RPC
反过来，我们也可以基于“发布/订阅”的消息通讯实现RPC机制。“发布/订阅”逻辑上是实现一个“多播”机制。多个软件组件可以订阅某一个主题的消息，不关心谁发送；多个组件也可以发出某个主题的消息而不关心谁会接收。既然可以“多播”，当然也可以“单播”，我们完全可以给用户层一个RPC的API，而在实现的时候把RPC调用转化成单播的消息通讯，比如利用DDS来实现。
基于“发布/订阅”来实现管道
如果我们把管道中每一个过滤器的输入和输出数据流定义成“发布/订阅”的消息，那么也可以实现管道和过滤器的风格形式。实际很多基于ROS/ROS2实现的系统就是这么用的。
----以上几个是架构风格在实现层面是交叉支持的具体形式，其实还可以有更多。如前文所述，架构风格定义的是软件组件之间结构关系的约束形式。每一个架构风格当然有其最优的原生实现形式，但是也不排除在具体实现技术上基于其它风格实现。
1.5.3车载以太网助力SOA架构
先明确讨论中“以太网”的概念。当我们谈及“以太网”的时候，根据上下文其实往往有“狭义”和“广义”两种含义。
广义的“以太网”包含了常用的通讯协议，最核心的是对IP层协议的支持。ISO/OSI定义的七层网络模型中，物理层和链路层之上是IP层（网络层）。传输层协议(TCP,UDP)也都是基于IP层。IP成定义了数据报文进行地址和传输的协议，无论下面两层如何实现，只要有IP层的支持，不同网络就是互通的。在这个语义下，WiFi也是以太网，因为它也支持IP协议。我们还可以实现IPoverUSB,那就是基于USB的以太网。
下面讨论中的“以太网”指的是广义的以太网，即具有IP协议支持的网络。
Can总线在汽车中的到广泛的运用，Can总线只有物理层和数据链路层（[27]3.3）。使用Can总线的应用需要在这个基础的数据链路层协议上去定义自己的数据格式，一般以一个DBC格式文件描述。Lin总线成本更低，FlexRay总线提供了比Can高得多的数据传输带宽，但是他们也跟Can总线一样，只有物理层和数据链路层，应用层协议各自为政。
这意味着这几个网络是无法互通的。汽车电子电器架构设计的时候，解决互通问题的办法就是两个网络中间加网关。网关同时支持两个以上网络并来回搬运数据。即使是两条Can总线想要互通也需要加网关，而且网关的数据搬运代码都需要单独定制，因为每条Can的应用层协议都不一样。
设想一下，在这种网络环境下做SOA服务是什么效果。假如我们基于Can协议实现了一个SOA服务，我们没法进行RPC请求，因为Can协议没有寻址的概念，请求不知道发给谁。不过好消息是Can本质上也是发布订阅的机制，我们可以放弃单播通讯，只做事件广播。但Can一个消息只有8个字节，没有地方放更多的头信息，我们在设计服务发现机制的时候会遇到巨大挑战。
就算我们设计出了服务发现，对不起，这个服务在别的网段中不会被发现，因为各个网段的服务是不能互通的。我们就需要开发网关程序跨网段搬运数据。但是每增加一个服务，或者对服务的数据格式做些修改，网关程序都要重新修改适配。
就算这些都完成了，我们想让一个开发好的服务在另一个项目中复用几乎不可能，因为对应的Can协议，网关程序全部都要重新适配。
引入以太网技术带来的IP层是解决这些问题的关键。不管各段网络的物理层和链路层是什么样的，只要支持IP层协议，IP报文就可以在不同网段之间传输。IP协议是可以支持广播和多播（一次数据发送，多个目标接收）的。而且广播和多播是可以跨网段的，有成熟的协议支持。广播和多播可被用于SOA的“服务发现”和服务之间的数据发布订阅。
以太网比大多数其它车载网络提供了更高的带宽，目前常用的车载以太网系统基本都可以达到1000Mbps。将来升级到万兆甚至更高的光纤以太网也是指日可待。而这种升级在软件架构上几乎不需要做太多变化就可以利用网速提高带来的好处。这样在数据报文设计上就不用像设计Can报文一样精打细算的利用好每一个bit。必要的情况下可以增加更多的头信息支持更多的功能。也可以用来传输图像等多媒体数据。扩大了SOA的服务能力范围。
总而言之，在车载软件中，以太网技术是支持车载SOA架构风格的关键技术基础。
1.5.4SOA与微服务
在汽车软件开始向SOA架构转型时，大型互联网服务基本上都已经转向了微服务架构风格。那么，SOA与微服务的异同点是什么？汽车软件也会走向微服务架构吗？
规模引起的量变到质变
首先SOA与微服务在架构风格的逻辑上是一脉相承的，前文对SOA的论述对微服务同样有效。但是微服务在架构风格上更进一步，可以理解为至少增加了以下几个约束：
1、服务粒度尽可能小
2、服务之间的依赖性更小
3、更彻底的去中心化
服务粒度尽可能小可以理解为比SOA更小的服务拆分，强调的重点是业务系统彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间通过服务完成交互和集成。每个服务完全不依赖中心化的资源，比如不依赖中心化的数据库，每个服务有自己的数据存储机制。粒度越小、相互之间依赖越小，无中心化，让开发、测试、部署的独立性越强，越容易使用负载均衡技术支持高度的并发访问。
相对于SOA，微服务是一个量变引起质变的过程。目的是为了支持更大型的互联网服务体系，应对高并发、高可用要求、高业务复杂性的挑战，同时要求开发迭代更为敏捷迅速，部署简单并高度自动化。像电商的秒杀系统，12306购票系统，都是极限并发的典型案例，微服务架构在应对这些场景的时候有很好的表现。
微服务可以认为是SOA架构向更深度的发展进化。但是互联网的微服务架构和车载的SOA架构，应用场景有很大的差别。虽然汽车软件也是分布式架构，而且车载以太网技术得到应用后，很多车载分布式技术与互联网的分布式技术有非常多的共通之处。但是车载软件的分布式规模与互联网服务完全不在一个量级。
“分布”与“集中”
大型互联网服务部署规模可能涉及上百台服务器，每秒百万级的并发。车载的分布式服务只在一台车的局部系统中，并发要求低但实时性要求高。与互联网的极度分布式趋势不同，车载系统是反过来，目前是向集中式发展。原来电子电气架构中大量小控制器实现的功能，逐步向几个主要的高性能域控制器集中。
车载SOA架构在功能划分上尽量切分成多个服务，但是部署的时候实际是集中化的，同时通过一系列技术手段优化通讯延迟。有意思的是，这个“集中”其实是与“分布式”并存的。
图1.15物理的集中与逻辑的分布
图1.15是一个理想的域控制器内的服务部署。高性能的多核心SoC被虚拟化成了多个虚拟机，VM1和VM2分别是Linux和QNX系统，而且都支持容器化(DockerEnable)。每个虚拟机内又有多个容器(DockerContainer,不是前文服务装配中的服务容器)。每个容器是一个独立的OS系统，里面再部署SOA服务进程，进程内有多个SOA服务。不同虚拟机内、不同容器内的服务通过网络进行通讯。
我们可以看到，整体的域控制器中的软件在物理上是“集中”部署到了同一个域控制器主机，但是逻辑上又“分布”到了不同的操作系统实例。这样的好处是可以使用虚拟机或Docker容器作为供应商的边界。一个供应商提供一个虚拟机或容器内的全部服务，与其它供应商互不影响，责任边界也容易确定。为了优化通讯我们可以在虚拟化这一层提供PCIe总线的虚拟化来支持跨虚拟机的共享内存通讯。
虚拟化技术和容器技术在云端计算中心已经被大规模使用，车载系统只是在复刻这个过程。差别仍然在于规模，现实应用中微服务架构基于的虚拟机和容器数量比车载系统至少高出两个数量级。而且虚拟化对微服务架构是完全透明的，微服务架构中的服务认为自己运行在独立的OS中，在微服务架构中，只有极度的“分布式”，没有“集中”部署的含义。
技术实现上的侧重点不同
两者的应用场景不同决定了分布式规模不同，导致在具体的设计和实现上的侧重点也有很大差别。
以目前最先进的微服务架构ServiceMesh来说，2017年1月发布的ServiceMesh产品Linkerd，所有的请求都通过ServiceMesh转发，不提供直连方式，它掌控所有的流量。2017年5月,Google、IBM、Lyft联手发布了Istio，它与第一代ServiceMesh相比，增加了控制平面，它具备远超第一代的控制能力。
车载软件架构会走向“微服务”吗
车载SOA架构是实际上跟互联网技术上的SOA架构也是有很大差别的，加入了很多为车载场景定制的协议和优化机制。微服务架构作为SOA的进一步演进，已经在互联网领域体现了其价值所在。车载的SOA架构也不会一成不变，也会进一步的演化，很自然的也会从微服务架构中吸取优秀思想。但不会是直接使用互联网微服务的产品。
目前来说车载软件的当务之急还是先实现在业务功能层面SOA化，然后在服务部署上应用虚拟化和容器化，以支持不同粒度上的服务部署，并建立供应商的责任边界。进一步的改进可以根据现实问题来做响应。有一个现成微服务架构作为参照，也为后续架构改进的思路提供了技术储备。