引言：
我是车载以太网小L，深耕于整车以太网架构系统设计和软件开发，入过很多坑，尤其是SOA架构，没有经验可以借鉴，一路过关斩将，摸着石头过河，可谓经历九九八十一难，有一堆的经验和心得，想和行业内同仁分享和探讨，如果能够帮助大家解决一些实际问题，那将是我分享的意义所在。也欢迎大家关注我自己的公众号“车载以太网小L”
《浅谈整车SOA架构》系列分为四大部分，层层递进，干货满满，千万不要错过哦：
3.我眼中的SOA（本篇内容）
4.整车SOA系统设计分享
我眼中的SOA
前两篇发布后，大家的反响非常强烈，这里要感谢大家的支持，大家的认可是我不断前行的最大动力。如果说前几篇是开胃小菜，那么接下来，让我们正式进入主题，来说说《我眼中的SOA》。
在过去很长一段时间里，我们都在低调并有序的做着研发工作，并没有想过跟业内分享我们的经验，但随着设计的SOA架构日趋成熟，再加上业内同仁们貌似都在焦虑，就想着是不是可以跟业内其他同仁分享一些经验，说说自己的想法，安抚一下大家焦虑的心，当然如果我的文章有一定的指导作用，那自然是极好的。另外，我们既然已经做好要分享的打算，肯定也会虚心接受业内人士的审视，有不足的地方，欢迎大家一起探讨，如果有的内容引发激烈的讨论，那也是我喜闻乐见的。不管怎样我们会始终保持初心，砥砺前行，不断从实践中总结经验，不断推陈出新！
01
SOA概念
什么是SOA：一种粗粒度小、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。
SOA是一种架构理念，不单单指某一种基于SOA理念的协议，所以千万别把SOA等同于SOME/IP协议，SOME/IP只是SOA的众多选择之一，而SOA本身的协议选择有很多，我相信未来车内能够支持的SOA协议，会越来越多，主机厂可以发挥的空间会越来越大。
SOA和AUTOSAR：正如上面所说，SOME/IP是SOA协议之一，而SOME/IP是专门用于汽车行业，SOME/IP通过AUTOSAR规范来具体定义SOME/IP协议细节，Classic Platform AUTOSAR(CP)和Adaptive Platform AUTOSAR(AP)都可以运用SOME/IP协议来通信，而AUTOSAR Foundation规范则定义了CP和AP必须同时遵循的SOME/IP需求。虽然SOME/IP定义于AUTOSAR，但SOME/IP并不仅仅用于AUTOSAR，目前GENIVI提供的一种SOME/IP实现，称为vSOME/IP，是开源代码，可以做到很好的适配AUTOSAR需求。
对于SOME/IP协议，想要AUTOSAR系统和GENIVI系统能够正常通信，必须遵循同一套规范，所以在整车SOME/IP通信中，不管是不是AUTOSAR系统，SOME/IP相关实现必须依据AUTOSAR规范开发，这才是AUTOSAR的意义所在，而不是强制ECU必须所有软件模块都遵循AUTOSAR，这样反而被局限。
对于AUTOSAR规范，大家要理性的看待，合理的利用，适当的发挥：《AUTOSAR的生与死》一文中，指出了一堆AUTOSAR弊端，但却恰恰忽视了最现实的问题，没有AUTOSAR，不同系统如何协作通信，当前并没有一种规范可以取代AUTOSAR，哪怕有了可以和AUTOSAR相媲美的规范，谁又能保证不会出现第二个AUTOSAR呢，所以规范就只是一个参考，说到底还是取决于你怎么用。你如果只把它当做参考，那它只是你的一个工具而已，但如果你完全指着AUTOSAR，而没有自己的思考，自己的见解，那只能被AUTOSAR拖着走，早晚有崩的时候。
02
SOA对EEA的影响
1).过去
对于汽车行业从业人员来说，电子电器开发V模型并不陌生，但理想很丰满，现实非常骨感，我们常常阻碍重重，常常折服于现实：
（1）Tier1提供ECU，往往是平台件居多，功能已定，ECU需要哪些信号，其实已经确认；
（2）OEM更侧重于提炼这些确定的信号，进行网络信号排布设计；
（3）OEM高度依赖供应商，也造成了技术强势的Tier1几乎垄断了相关ECU，导致这方面OEM话语权极低；
（4）基于目前现状，ECU的功能极为固定，行业变革也举步维艰。
在我有限的工作经验中，对Tier1做妥协那是时有发生，已经足够习惯和麻木，常常一个供应商的零部件无法满足系统设计需求，而需要整网跟着调整参数来实现，做好新的策略之后，还得跟其他零部件系统工程师，架构工程师、供应商等一系列人去协调解决方案的落地，如果遇到另外一个强势的Tier1不愿意配合，那这个时候就又得发挥我“强大”的设计能力，重新给这个不配合的Tier1做另一个解决方案，就这样解决方案叠加解决方案，到最后我自己都不知道设计了一个什么出来。
2).现在
长久以来的反向开发流程，极大的压抑了主机厂的主动权，主机厂受控于平台化的零部件，功能无法突破，话语权不大，使得越来越多的主机厂开始想要变革，从最近的软件中心如雨后春笋就可以窥探一二，另一方面，软件定义汽车这个概念也越来越热门，大家的需求都非常迫切，都在寻求突破，我觉得这些都是极好的现象。
软件定义汽车变迁中，SOA理念将会发挥极为重要作用，它是这次变革的马前卒，可以让这场变革变得水到渠成。但如何引入SOA理念呢，大家是不是一头雾水？首当其冲的就是，在整车功能定义初期，SOA团队就必须要参与功能定义和梳理，协助并主导将整车功能划分为不同的子系统，在子系统的基础上，将所有功能划分为最小单元的功能模块，每个功能模块都必须做到独立不重叠，这样的功能模块才能是一个基础服务。有了基础服务之后，还要反向将子系统重新通过基础服务组合起来，这样子系统才会以组合服务而存在，这一系列操作下来，我们的服务API就基本定型，而服务的组合是一个可持续的过程，会让数据源源不断的产生价值。
3).未来
SOA服务的定义是高度依赖于整车功能定义，只有整车划分好子系统，SOA服务设计才会启动，服务设计好后，才能解析出软硬件需求，整车拓扑才能真正意义上的软硬件解耦。
在整车架构和SOA服务设计上，我们已经做的很超前，可以说SOA几乎规划了整车所有功能，但仍然有一些挑战要留给未来解决，目前我们完全没有办法要求供应商将各个ECU的功能逻辑上移到域控制器中，这个问题，我们势单力薄，是需要整个行业的共同努力推进，主机厂和供应商缺一不可，未来行业格局会重新洗牌。
未来，各大主机厂的软件中心将发挥极其重要的作用。
03
SOA优势
关于SOA优势，首先得益于以太网的快速发展，使得SOA通信(SOC)优势明显，另外SOA运用发布-订阅等机制，也促进了SOA发展。
1）以太网的带宽占据绝对优势，是直接碾压CAN等传统网络的，同时以太网的带宽会随着技术的不断发展，一直是持续精进的，这点传统网络已经不具备可比性；
2）从信息安全角度，CAN大部分采用MAC和SecOC等明文传输，加密等级并不高，而SOA通信可以借助强大的以太网加密方案，甚至可以不断扩展，安全方案是不断迭代的，目前也有很多主机厂专门成立信息安全团队，加固安全策略，而CAN信息安全很难扩展；
3）SOA服务通信模式不仅支持发送者-接收者模式，同时还支持客户端-服务器模式，而CAN通信，仅支持发送者-接收者模式，单纯的发送和接收，接收端均是被动接收，而SOC可以让Client主动请求控制或者状态数据，同时也支持订阅相关数据的发送。对于CAN来说，不同的通信对，对于同一个功能，是需要定义不同的报文和信号，而这几个相同功能的信号对应的值有时还不一致，运用SOA之后，就完全可以避免这种现场，不管有多少个Client，Server可以只有一个，同时不同的Client可以调用同一个服务接口；
4）SOA的发布-订阅机制以及服务功能独立不重叠，是和互联网SOA及微服务高度契合的，使得整车SOA服务通信和后端互联，为后续开发更多的运用提供无限可能，促进汽车智能化的发展；
5）SOA架构服务通信的最核心关键词就是动态，服务可以通过OTA动态的安装，服务间调用可以动态的创建连接。
如图所示，驾驶员意图分析服务作为一个新的服务，可在车主拿到车后，购买升级包，通过OTA推送该服务相关的APP，从云端将安装APP相关的Manifest发送到对应的控制器，仅升级该服务相关功能逻辑，而不需要改变任何其他的代码。另外，从图中可以看到，驾驶员意图分析服务会调用车内很多已有服务，进行数据融合分析，这种将分析结果反馈给云端，做边缘计算等算法，这里其他已有的服务不需要更改任何内容，因为服务在开发阶段就已经确定好哪些是可以动态被访问。
这时候，有人肯定会问，说了SOA服务可以动态，但真正有几个主机厂做到了动态，哈哈，目前在我们的SOA架构中，服务已经做到了动态创建连接，也就是说，服务可以被任意一个有访问权限的节点访问，而服务动态安装，我们也有借助OTA技术实现，进一步落地。
04
我们的SOA
在上一篇<大家眼中的SOA>，我分析了国内外的主机厂SOA架构落地情况，这里也简单说下我们自己的。
我们在决策电子电器架构的时候，架构专家们更多的是敢为人先，没有任何的犹豫和惆怅，直接采用了Domain架构（一群有魄力的人）。当然采用Domain架构还是Zonal架构，其实对SOA并没有本质的区别，因此物理架构的决策，更多的是考虑整车硬件环境和车辆实际情况，对于SOA，理论其实是一致的，SOA的设计经验完全可以平移。
我们在实现SOA架构设计的时候，具备两个前提条件：
1）从SOA架构落地角度，如果一个主机厂想要实现SOA架构，那整车SOA架构团队，必须对整个实现链路具备绝对的话语权。在我们SOA架构实现的过程中，我们具备对车内外系统规划权力的，我们可以综合决策车端SOA节点的软件系统、架构及中间件，同时也能推动娱乐系统，尤其是SOA Gateway节点实现我们的策略，另外，如何和云端进行SOA交互，我们提供解决方案，我们甚至能够支配第三方交互系统，在整个链路中，我们能够整体去把控，而不单单是车内以太网系统设计，大家别看上面看似寥寥几句，其实我们经历了好多，搞定其中一种就已经极不易，要同时做到这几点，更是难上加难，所以我们的整车SOA架构，是大家共同努力的成果。
2）整车SOA架构师必须具备十项全能，要想做到软硬件解耦，就必须从整车功能定义初期就参与其中，辅助整车功能部署，不仅要整车功能了然于心，同时具备SOA架构设计能力，还要精通整车网络系统设计和整个工具链的开发，还要精通软件架构，写得了代码，调得了板子，深入到软件实现，另外架构出身，必须熟知整车开发流程，还得做得了项目管理，因此对SOA架构师的要求是极高的。
至于我们如何运用SOA，如何实现，因为涉及公司机密，这里就不深入探讨了，但我相信时间会给出答案！
请大家继续关注下一期：《浅谈整车SOA架构》第四篇 整车SOA系统设计
