SOA？

作为汽车人，如果你还不知道SOA，是不是觉得已经落伍了？最近，整个行业充斥着这样的焦虑，但焦虑本身有啥价值呢？这份焦虑又该如何解决呢？本文将站在汽车人的角度讲讲这些。

现在SOA风头越来越旺，俨然是一头站在风口的猪，虽说事是好事，一个行业想要变革，确实也需要一些推动力，需要整个行业重视起来，但从最近的现象来看，好像有那么一丢丢方向走错了，因为落地过整车SOA，所以对这种现象感触尤为深，也有一些许个人感受，想要分享给大家，如果说的不对，欢迎大家多多留言一起探讨和交流。

01 汽车和互联网区别

首先，作为汽车人，我从来不认可这样一种说法：互联网技术比汽车技术先进，在我看来两者的技术发展方向不同，维度不同，是不能同日而语的，因此我也非常不认可从互联网转行过来的一些朋友对汽车技术水平的那种嗤之以鼻。

互联网追求的是极致客户感官体验，不断创新一些炫酷的应用，在大数据的支撑下，不断改善我们生活的方方面面，实现智能化，在这其中软件是起了极其重要的作用，这就要求软件必须不断的进化，敏捷迭代，但是需要注意的是，互联网提供的这些对于人们的生活，其实更多的是锦上添花，虽极大的提高了效率，但也并不是非它不可。

汽车作为人类出行的必需品，本身因为安全系数要求极高，所以技术发展的侧重点在于打造安全稳定的整车系统，整个汽车设计和开发全过程始终围绕这一点开展，因此要求所有的设计都必须精准定义，而不能有任何遗留开口项或者模棱两可，所以汽车和互联网等技术发展的维度完全不一样，不能通过局部来得出一些全局的结论，比如根据以太网技术水平，来推导出汽车技术水平滞后于互联网、物联网等领域这样的结论。

互联网和汽车行业技术发展维度不一样，因此本身并不冲突，两个行业之间本就可以有机结合，发挥自身的优势，但绝不是一方取代另外一方，从这一点，虽然互联网企业来势汹汹，汽车人也完全不用焦虑，我们有自己的优势，就是我们懂车，这点比什么都要来得重要。

传统通信技术往往因为生命安全系数低，产业链完备，通信节点多而且带宽充足，甚至故障后，直接重启即可，这样就导致好多机制都是动态实现，动态分配，比如以太网IP动态分配，路由表动态查询，而路由器交换机基本类似于黑盒子，使用者甚至都不需要知道里面的具体配置，一般都是直接使用，而不必关注所有细节。

在汽车行业，拿整车以太网架构来说，从硬件物理层，到上层应用，方方面面都要精通，每个参数都要耳熟能详，不仅要知道怎么用这些参数，还得精通这些参数在不同系统的权衡，全面考量，仔细权衡设计，以确保达到一个极安全稳定的系统，设计好之后还要不断去验证，不断去测试，从每个角度确保没问题，才有可能投产，这个过程不仅仅是一个技术的积累，同时还存在着一个经验的积累。从流程角度来说，一些主机厂引进互联网的敏捷概念，想在汽车行业推广敏捷开发，这里不是贬低敏捷开发的作用，但我认为照搬照用敏捷开发，汽车行业并不适用。同理SOA也一样，互联网的SOA有其自己的特点，同样汽车行业的SOA，必然也是不同于互联网，而有自己的特色，需要走出自己的一条创新之路。

互联网对SOA架构的定义是一种架构思想，颇有些只可意会不可言传的味道，也没有公认的定义，从不同的方面来进行描述，有的说SOA是一种应用程序架构，所有功能都定义为独立的服务，这些服务有非常明确的可以被调用的服务接口，能够按约定好的顺序调用这些服务接口来实现业务流程，有的还说服务需要精准定义，非常完善的封装，是服务间非常独立的函数，更有的说SOA是一种基于客户端和服务端模式的架构软件设计方法，应用由服务和它的使用者组合而来，它特别注重服务所对应的组件之间的松耦合性，所有的接口都要标准化，独立化，同理SOA架构下的通信协议也是多元化的，任何基于服务机制的协议均可以被认为是SOA架构通信协议。

因此汽车SOA，确实是互联网SOA的衍生，但必须在互联网SOA基础上发展出符合行业特征的汽车SOA，它更抽象，更全面，更广泛，是在整车开发全过程中，秉承的一套整车电子系统设计方法论，是一套可以被分享，可以被评审，可以被记录，可以被流程化的设计思路，一套如何按服务的形式组织整车功能的决策集合，需要确保这套架构方法论可以指导整车功能的组织和划分，并确保整个功能架构在汽车生命周期中可持续进化，此外架构设计需要关注功能性，复用性，性能，兼容性，经济和技术限制，商业等。

不难发现，SOA的实现是多元化的，不同的架构师设计的SOA应该是大不相同的，但怎么衡量SOA设计是合理的，完善的，最优的？虽然设计者不同，最后呈现的效果也不同，但评判标准肯定是一致的，我后面也有专门的文章来介绍这个。

从上面描述不难看出，互联网SOA是一套很成熟的理论，只需要沿用这套方法论即可，更多的复制粘贴，而汽车SOA，则是没有任何参考，一切从零开始，甚至都无法参考互联网的那一套，所以目前最最关键的是做这些设计的架构师，他的技术水平，技术宽度，直接决定了汽车最后呈现出来的效果，是优化整个产业链，还是四不像，完全取决于整车架构师的水准。

02 行业现状

现阶段，有很多方势力，趁公众对引入的新技术还没有一个很透彻理解的情况下，利用这些信息差，博取大家眼球，传递焦虑，自己还是一知半解的情况下，到处宣传天马行空般的高大上，一直把大家往错误的方向上引导。随着互联网公司不断参与造车，焦虑也在加深，再加上互联网和汽车双方技术人员还互看不顺眼，这摊浑水势必会更加浑浊，如果在这样一个关键时期，老牌主机厂走了弯路，试错了方向，在互联网大风吹过寸草不生的大趋势下，老牌主机厂会是一种什么样的结局，其实我也不敢想象，但我觉得从手机行业的发展其实可以窥视一二。

虽然两个行业融合，难度很大，但两者的有机结合早晚会到来，只是时间和磨合问题而已。作为较早进入这个领域的我来说，可以很负责任的告诉你，SOA确实是其中最好的契机，它可以将互联网介绍给汽车，也可以将汽车一些专业技术分享给互联网，但SOA有那么神乎其神么？这个问题有待大家去思考，也有待时间来验证。

而我的观点就是，SOA充其量充只能作为抛砖引玉的一个角色，而不是全部，我们应该全局考虑，合理利用，把它放在一个最合适的地方，该用的时候用它，不该用的时候，绝不生搬硬套，同时也绝不要说汽车引入SOA，就可以赶超特斯拉这样毫无依据的说法。我更希望有一天看到哪家车企说我们要创新自己的车，不需要对标任何车企，然后脚踏实地的落实，那才是我想见到的。

SOA是一种架构设计思想，甚至汽车内称它为SOA，都是有失偏颇的，汽车需要的是一套可以很好的从全局优化汽车软件和性能，统筹软件和工具链，让开发变得更容易，从而节省成本，但严格意义讲，没有服务本身，汽车也依然可以实现各种前沿的自动驾驶和功能，如果想要超越特斯拉，还是要在自动驾驶领域去硬碰硬。

再者，特斯拉就很牛么？不可否认，它的软件能力确实是顶尖的，自动驾驶做的好不好暂时不评价，时间可以证明，不过毕竟是先吃螃蟹的，敢于尝试的勇气，我充满了敬畏之心，但特斯拉其实一直忽略了一个极其重要的问题，隔行如隔山，每个领域都要有一个长期积累的过程，这点是没有任何捷径可以走的，往往最最宝贵的就是那些经验积累，如果试图利用自己的优势来弥补那些经验积累，甚至鄙视那些传统经验，傲慢的像个小公主，那最后也只能自食其果。

说到这，特斯拉对比华为，其实从技术角度，我很认同华为的做法，且让我站在他们的角度，代入的规划一下：现阶段华为不造车，其实并不代表华为一直不造车，最多3年他们肯定会造车，现在只是通过合作模式，双方共享技术，交换技术甚至经验，现在的目标甚至都不是为了盈利，华为需要先积累相关技术和经验，像个海绵一样，吸收全方位多角度的技术，因此他们肯定也是各种软件，工具链，零部件也是采购了一堆，用来研究，等条件允许了，造车也是水到渠成的事。

到那个时候，我们就有自己民族的平台，对国家对民族是好事一桩，但反过来讲，这样留给传统车企生存空间就更小，所以老牌车企现在真的要加油了，不要迂回，打铁还得自身硬。

03 软件定义汽车

特斯拉的强大优势是其软件能力，但是否做好整车软件联动，这个其实还有待验证。软件定义汽车，这个发展趋势是没错的，也是毋庸置疑，汽车行业势必也会朝着这个方向发展，汽车也势必会有一套自己的最优化的软件平台，最适合的操作系统，最适合的软件框架，这个也是需要不断探索，时间积累，但软件定义汽车绝不仅仅是SOA，也不应该仅仅是SOA，抛开这些方面，来落地SOA，必将是一项KPI，而非真正的事业，而如果作为一项任务，那后果必将是灾难级的。

那什么是软件定义汽车，如何定义汽车，谁来定义汽车？首先，软件定义汽车其实并不算新概念，很早就有人提过，而且仔细想想，难道之前的汽车都没有软件？传统CAN，LIN都不是软件实现的？现如今，软件定义汽车这个名词被正式提出来，只能说明以往的汽车软件急需创新和优化，需要整车厂站在整车架构的视觉，运用软件思维，组织和优化整车凌乱的逻辑关系，增强和云端的联动机制，调整业务流以契合不断发展的自动驾驶需求，而这其中就需要架构和软件的共同协作，共同来定义软件，各司其职，实现共赢。

04 软件和架构如何合作

以往的整车开发，架构是架构，是属于整车厂的架构，软件是软件，但却是零部件的软件，两者天然隔着一堵墙，完全不存在合作，架构只是释放规范，都是各做各的，能力强的零部件甚至还要整车架构适配它们，弄的整车逻辑关系混乱，这其中架构只起到协调各个零部件的作用，有的甚至称不上架构设计，而软件都是一个个小团体，形不成系统。

架构和软件的技术维度不一样，架构首先必须要有一个广度，在广度具备的情况下，尽可能深挖，而软件讲求一个深度而非广度，因此架构具备全局观，而软件具备落地能力，软件负责技术点可以直接细化到每个代码级别。

在软件定义汽车的超流下，需要架构和软件需要紧密合作，各自发挥长处，架构领导软件，提供需求，以便软件很好根据架构的设计开发出相应的软件，在有些关键点的软件开发中，架构还要提供详细的策略，指导软件开发，同时架构的有些设计也存在偏差，软件必须站在验证的角度给架构及时的反馈，帮助其细化和修正设计，因此架构和软件如何实现共赢，是我们需要思考的，这其中对架构部分的要求会更严格，需要在架构的基础上增加软件思维。

在这个过程中，切记过犹不及，过分强调软件的重要性，而忽略了架构，在我看来，架构反而是先行者，策略定义者，但往往因为架构输出文档，没有产出软件或者零部件，因此重要程度经常未被识别到，同时传统汽车的架构，能力也确实进步空间很大，因此极容易出现软件来指导或者领导架构的现象。而这种情况，应该在互联网新势力上更为普遍一些。

05 汽车人该怎么做

在焦虑的大潮流下，汽车人该如何做呢，以下为我的一些小看法：

1. 公司角度

   1) 组建强大的软件团队，这个不用多说，大家的共识

   2) 加大对已有架构部门的培养，这里重点强调下，传统架构能力还是比较薄弱，而行业能力强的架构师总共也没几个，毕竟以太网和SOA等也很新，大部分主机厂都在纠结的探索中，所以人以稀为贵，相信大家也看到，行业内已经呈现出一种抢人的现象，那抢不到人怎么办呢，难道老架构的同仁们，就没有发挥的余地了吗？其实不然，主机厂其实更应该注重对内部员工的培养，寻求一些外部资源，帮助其培养，其实是最经济和快速的一种形式。

     3) 建议不要让没有经验的Tier1提供架构方案或者服务设计方案。必须重点考量供应商是否做过整车级别的设计，其实这点很难，但凡落地过或正在落地SOA的主机厂，大概率核心零部件都是自研，其实供应商很难接触得到全局SOA，退一万步讲，即使有部分供应商做过单个零部件的SOA开发，或者测试等，其实他们更多的是作为下游团队，广度远远不够，知识体系相对片面，服务的定义，设计权衡点，关键点层面等都是被动接收，严格来讲他们也属于摸索阶段，云里雾里当中，是不具备架构整体思维，极易带偏方向。另外，服务定义只是方法论中很小的一个点，切记，切记，切记，重要的话，说三遍都不为过！！！当然一段时间后，随着方法论的普及，大家的状态都会拉齐，供应商也会很快具备能力。

2. 最后从个人角度，我也有些小小的建议给到汽车同仁：要做发明者，而不是拿来主义者。当然直接拿来主义这条路最简单，最易走，但你并不能从结论推导出别人设计过程，所以要多思考，多去试着做设计，去创造，而不是等着供应商输入，这样的时代已经过去了，如果不做改变，被淘汰都是极可能的，打铁还要自身硬，走到哪儿都是更古不变的真理！

以上是我最近的所思所想，文字朴实无华，但内容发人深思，希望对大家有所帮助，如果有说的不合适的地方，也欢迎指正，交流会碰撞出更多的好点子，也欢迎找我聊天。

                                            < 原创不易，转载请标明出处！>