简述面向服务的架构SOA开发基础

从去年开始（可能更早），SOA的概念在汽车软件行业逐渐蔓延开来，很多公众号都发过讲汽车SOA的文章，很多车厂都要开始（或者已经在）搞SOA。但我觉得吧，在开搞新技术之前，是不是先花点时间弄明白这个技术到底是什么，它解决的是什么样的问题，然后再谈架构，再谈开发，很多时候我们连问题是什么都没整明白，就急着去做解决方案，最后的结果只能是一地鸡毛。

对个人来说，要搞SOA开发，需要夯实哪些基础知识，看了很多SOA文章，却很少有人梳理这些，这段时间我陆续思考了一些，尽管可能不全面（更偏向SOC开发涉及的技术点），但仍然试图写出来，以期逐步构建出自己的领域知识体系（详见下篇）~

那么，先来理一理关于SOA：

软件定义汽车，E/E架构是关键

汽车电子电气架构（简称E/E架构）是指整车电子电气系统的总布置方案。在智能网联汽车产业大变革背景下，软件定义汽车理念已成为共识。传统汽车采用的分布式E/E架构因计算能力不足、通讯带宽不足、不便于软件升级等瓶颈，已经不能满足现阶段汽车发展的需求，E/E架构的变革已成为智能网联汽车发展的关键，其升级主要体现在硬件架构、软件架构、通信架构三个方面：

硬件架构升级：由分布式ECU向域控制/中央集中架构方向发展，汽车E/E架构的升级路径表现为分布式（模块化→集成化）、域集中（域控制集中→跨域融合）、中央集中式（车载电脑→车-云计算）。好处在于：提升算力利用率，减少算力设计总需求；数据统一交互，实现整车功能协同；缩短线束，降低故障率，减轻质量。

图片来自网络

软件架构升级：通过 AutoSAR 等软件架构提供标准的接口定义，模块化设计，促使软硬件解耦分层，实现软硬件设计分离；Classic AutoSAR架构逐步向Classic AutoSAR+Adaptive AutoSAR混合式架构发展。好处在于：可实现软件/固件 OTA 升级、软件架构的软实时、操作系统可移植；采集数据信息多功能应用，有效减少硬件需求量，真正实现软件定义汽车。

通信架构升级：车载网络骨干由 LIN/CAN 总线向以太网方向发展。好处在于：满足高速传输、高通量、低延迟等性能需求，同时也可减少安装、测试成本。

中央计算单元——E/E架构的核心

中央计算单元是E/E架构中最关键的部分，不管是按区域的架构，还是以后的纯中央计算平台，其硬件构型从根本上决定了软件架构的设计方向。中央计算单元可以分为以下三种形态：

图片来自网络

SOC分离式：将多个不同的芯片集成到一个中央计算单元上去，每个运行不同的操作系统，只是在形态上集中到了一起，各单元依然独立的完成各自任务；

硬件隔离式：在统一的计算平台上采用虚拟化方案，同时运行多个操作系统，但是各个系统依然在硬件上进行隔离，每个系统都有自己的专属硬件资源；

软件虚拟式：在统一的计算平台上采用虚拟化方案，同时运行多个操作系统，每个操作系统所使用的硬件资源，由Hypervisor层动态调配，每个系统并没有专属的硬件资源。

硬件隔离式和软件虚拟式，都采用了虚拟化方案，唯一不同点在于硬件资源是否专属，如果是专属的，就意味着资源无法动态调配，容易产生资源浪费。虚拟化方案最大的好处是，硬件上的可拓展性，如果中央计算单元采用刀片式的设计结构，可以很方便地拓展计算单元的算力，而不用替换整个计算单元。

在中央计算单元中，只需要两个操作系统即可，用于自动驾驶、车控、网关的RTOS，以及用于娱乐的普通OS（如Android、Linux）。用于娱乐的OS完全可以通过虚拟机的方式运行，用于自动驾驶、车控、网关的RTOS，可以直接运行在Hypervisor层，既能兼顾实时计算的要求，也能获得丰富的娱乐系统功能。

SOA——解决软件定义汽车中服务间通信的分布式架构

在软件定义汽车中，应用间跨进程或跨核的通信，必然成为软件架构设计中一个需要去解决的问题。SOA在互联网已经应用了很长时间，但在汽车行业中，算是比较新的概念。鉴于汽车的应用场景和通信需求有其特殊性，很多互联网的SOA技术，并不能照搬过来。

虽然Adaptive AutoSAR采用了SOA作为通信架构（ARA：：COM架构如下图），但是Adaptive AutoSAR的应用可以说还没有普及，应该说整个行业就没什么标准的SOA中间件解决方案，几乎没有专业做中间件研发的公司，可能在国内这种慢工出细活的东西很难有什么成长的空间和土壤吧。所以，对于汽车SOA，还有很多值得我们去做的研究和尝试~

摘自《Introduction of ARA：：COM as common communication middleware》April， 2018 by GENIVI

SOA，Service-Oriented Architecture（面向服务的架构），是一种架构思想，实施者可以根据实际情况设计SOA的技术实现。为什么要面向服务？以前用得好好的面向信号或者面向消息的通信架构怎么就不香了？面向服务的通信架构，它的优势到底在哪里，如果不能很好地理解这点，可能很难从过去面向信号的思维转变过来，也就无法体会引入SOA的价值和意义。

这有点悖论哈，不去用，无法感受其奥义，但又因为没用过，对它保有质疑，过往的再拧巴，也是千锤百炼了，从零开始，谈何容易。因此，我觉得短时间内不太可能全面铺开做整车SOA，可能会在安全等级不高的域比如智能座舱先尝试SOA。

本质上SOA就是服务的集合。在SOME/IP 协议介绍一文中，我写过对于“服务”的理解。以智能座舱域为例（如下图），可以把“服务”分为两类：

基础服务和应用服务，基础服务的功能可能包括：总线消息的解析和路由（如车身数据服务）、直接与硬件相关的逻辑处理（如音频服务）、上层应用有共同需求的一些基础设施（如日志服务）；

应用服务的功能相对复杂些，可能需要由多个基础服务提供数据支撑，也可能需要应用服务之间相互协同，实现业务逻辑（如导航服务）。

SOA分层架构视图（仅作举例）

这只是一个很简单的例子，想表达的是，每个服务将自己的功能，以接口的方式提供，基于这些服务和接口，便可以设计出应用场景，以满足各种用户需求，提升驾车体验。可以想象，应用场景的需求一定是丰富且变化的，面向信号的话，新增一个需求，可能要等上一年，但如果服务也能够方便地进行开发、扩展和更新，是不是好多了，是不是挺有价值呢~

个人觉得，汽车SOA的设计难点，主要在于以下几点：

服务的定义和划分，要把业务需求分析透彻，从中提炼出服务的功能，数据流向理清，定义服务的边界，把握服务的粒度，怎么做到“低耦合，高内聚”，我以前很讨厌研究需求，觉得那些不过就是些业务，没啥技术含量，后来才慢慢认识到，这种想法很危险啊，脱离需求的软件设计不可能很好地满足需求，如果不能很好地服务于产品功能，那么再牛逼的技术都没有机会实现它应有的价值，事实上，能够把需求文档转化为可实施的软件设计，也是一种能力；

不同系统中，要实现中间件框架或者底层通信基础设施，Adaptive AutoSAR有ARA：：COM组件，Android有Framework，但不能跨域，QNX/Linux就不用说了。要实现一个中间件框架，本身并不是件容易的事，需要比较强的技术实力，一旦出了问题一般都是重大问题；

服务接口标准化，接口描述语言化（IDL），能够通过工具自动生成RPC桩的代码（最好能够关联整车通信矩阵，e.g. ARXML-》C++ API），能够跨平台，支持多语言，毕竟UI层可能不是C++写的，时至今日，没几个应用愿意去解析原始消息，远程调用接口不香嘛~；

如何兼容一些没有与时俱进的设备和模块，如何兼容旧的传输通道，如何尽可能复用以前的业务逻辑，理论上任何兼容都是可以实现的，抽象一层不够，那就再来一层，但兼容得越多，系统就越复杂，出问题的概率就越大，维护起来就越费劲，这意味着成本的升高，质量却不见得变好；

评估性能影响，怎么保证安全性，……，如果是基于开源项目，可能还要做二次开发，来满足这些非功能性质的需求~；

所以，汽车SOA真不是SOME/IP，也不是DDS，更不是Adaptive AutoSAR，这些都是汽车SOA技术栈中的一环，并不是全部。

很多时候，纯技术的部分并不是最难的，新的架构方案要达成共识，要真正落地，需要博弈和取舍，需要天时地利人和。作为一名工程师，心态是极为重要的，要分清理想与现实，技术与工作，所以在这里我只想谈技术，本来打算梳理一下做汽车SOA开发的基础知识体系，以后公众号的内容大致也会围绕着这个体系去写，没想到写着写着这么长了，于是分成上下篇了，下面先开个头吧。

SOA是架构，做SOA的设计和开发，其实也是做架构的设计和开发，在这里我想引用陈皓老师为《架构整洁之道》作的推荐序里的一段话，我常想起这段话，挺有鞭策的功效，分享给每个不想成为PPT架构师的工程师，以共勉：

问题：如果你要成为一名架构师，你需要明确地区分几组词语，否则你不可能成为一名合格的工程师或架构师。这几组词语是简单vs.简陋、平衡vs.妥协、迭代vs.半成品。如果你不能很清楚地定义出其中的区别，那么你将很难做出正确的决定，也就不可能成为一名优秀的工程师或架构师。

陈皓，《架构整洁之道》推荐序一

之前很长一段时间，我经常感到焦虑，一方面不想成为PPT党，开会党，另一方面，除了工作还要生（带）活（娃），留给学习的时间并不多，而想学的知识又如同汪洋大海，今天想好好梳理一下某个技术点，明天搜到某个开源项目蛮感兴趣想写个Demo跑跑看，年轻的时候觉得日子一天天刷刷地过去，也不是什么事儿，现在愈发有种紧迫感。在做了一些架构方面的设计和开发工作以后，更是深刻体会到构建个人的领域知识体系，尤其是一些基础技术，真的非常重要。

今年伊始，听了李运华老师关于“如何打好基础”的讲座，核心观点是：“基础≠底层，基础≠源码，基础≠不变”，很是醍醐灌顶~结合个人实际情况，我觉得可以这么去构建我的领域知识体系：首先，定义出哪些是与我工作相关的领域知识（比如现阶段是SOA）；其次，进一步细化要学习的知识范围，也就是下篇要梳理的SOA相关知识；

最后，分别从广度和深度（根据工作内容去判别学习的深度），有针对性地学习，并在实际工作和项目中把知识和技术串起来，从而系统性地提升技术能力。就像前面说的，要分清理想与现实，因为这个世界从来都不是我所能想象的，很多PPT党开会党，基础不扎实甚至很水，设计出焦油坑一样的架构，坑自己，坑别人，坑项目，也不耽误他们升职加薪跳槽。但是“世界上只有一种英雄主义，那就是认清生活的真相后依然热爱它”，不是么，于是才有了写公众号的初心和决心。

编辑：jq