汽车SOA（面向服务架构）
SOA（Service-Oriented-Architecture）是目前汽车行业非常热门的话题，在国内各OEM的下一代整车电子架构和智能网联功能开发项目中，更是需要首先明确的新概念和新事物。从理论到实践，汽车电子架构的研发正在经历从传统架构开发方法论到软件SOA开发方法论的转型过程。
这个过程中涉及的问题非常多，如在传统EE架构开发中从来不曾涉及的新需求，而这些新需求的导入并形成有效的交付物和工作流的过程，不是一蹴而就的，而应该是结合开发团队实际情况经过反复实践经验积累总结的，并基于一定的试错成本，在具体的开发项目中最终被参与项目的工程师团队广泛认可的产物。如果这个过程中的各种成果的表述和经验总结，包括组织架构、工作流等，能够获得全行业范围的认同，则更进一步反应出了从概念到方法论再到实践过程的价值。
本文就其中一个分支话题，或者说是子需求，进行一些实践层面的推导和描述，尝试从一个角度切入，分享在具体SOA开发工程实践过程中总结的经验，希望能够和同行们进一步的讨论。
服务架构的微服务化
SOA作为一个软件模块服务化设计的概念和实施原则，在IT行业应用得比较多。实际进行汽车SOA架构设计和开发的过程中，首先可以考虑进一步挖掘IT行业SOA开发的一些具体的实践成果和技术背景。相比早期的企业总线ESB，IT行业的SOA概念在云服务领域得到了更广泛深入的应用实践，且具体的实践方法和架构设计思维经历了多次明确的架构迭代，其中有一个显著的分界点在于SOA架构的微服务化（Microservices）实现的过程。
我们首先来看一下IT云服务架构对SOA中的Microservices实践的定义，由于IT行业开放度比汽车行业高一些，所以不存在IT行业的规范或者标准来定义SOA的各种不同的实现方式，而是在实践和迭代过程中，由IT行业的一些头部公司，一些技术大牛，以及一些被分享、公开的参考项目或者参考架构文档，来推动行业的新共识的形成，进而推动技术进步。
这里引用如下的几份公开文档，介绍了SOA架构的微服务化特点（请复制链接至浏览器中打开）：
https://www.guru99.com/microservices-tutorial.html
https://www.ibm.com/cloud/blog/soa-vs-microservices
IT云服务架构在具体落实中，微服务化过程对软件模块和服务接口在全局架构上的定义、抽象和管理的细节，对比更早期的SOA总线服务架构，有很多具体的区分：
这里只是简单罗列在IT系统中总线服务架构和微服务化架构的一些设计和实现的区别，总线服务架构和微服务化架构在IT云服务的实际应用中也是互有优劣，并不是说微服务化架构就一定比总线服务架构先进，需要在具体的业务需求框架下进行选择。一般来说，一家公司的IT业务在发展初期和反复试错的阶段，直接上微服务化架构的后果很有可能是浪费IT工程师的开发资源，而一旦业务逻辑成型，得到了市场验证，并且规模化以后，将系统进行微服务化的改造是很有必要的。可以进一步细分和抽象系统内的子业务逻辑，增加各业务模块的可重用性，将代码维护工作进一步细分化和轻量化，提高硬件资源利用率，提高IT开发部门和业务部门对接的工作效率。当然，这个原则，也不是一定的。
车内SOA的微服务化
IT的SOA的具体实现服务于IT的系统、IT的业务逻辑和IT公司的利益，现在回到汽车SOA，我们引入了IT行业的SOA概念，显然不可能直接沿用IT系统的需求和逻辑。
我们参考了IT云服务系统的微服务化架构演化的过程，能得出一个什么结论呢？虽然汽车SOA的实践之路是独一无二的，但是IT云服务系统的SOA微服务化的特性，貌似更契合车内分布式系统和汽车工程的设计开发需求。
所以，基于汽车SOA的实践，我们发现，SOA概念在导入汽车架构考虑落地的第一个环节，我们已经原则上跳过了总线服务架构设计这个过程，直接进入了SOA微服务化设计的具体工作中，这是由汽车工程的系统需求和业务实际情况所决定的。
也就是说，车内SOA架构的设计和实现，固然需要重视Adaptive Platform上的服务接口的定义和功能设计方法论的验证落实，同时也需要重视对整个EE系统层面各个子系统（或者子域）的微服务接口的规范化。包括如何定义微服务接口；如何描述微服务接口的需求；如何进行微服务接口（在不同总线上）的分类；如何进行微服务接口的诊断和维护；如何进行集成和测试。
汽车SOA微服务化设计对实施团队的要求
显然，我们在面对具体的架构设计项目，因为微服务化需求的不可回避性，让我们一下进入深水区。在目前一些国外的汽车SOA咨询文档中，很多并不提及Microservices这个概念，而是直接将车内SOA服务接口进行几个层级的定义（Feature、Sub-feature、Service、uService…），并规定了一系列设计方法和原则，避免产生“服务接口风暴”。本文仅是为了说明思考的过程，而引入了IT云服务的Microservice的概念，云服务器和车内系统本质上是两个完全不能等同看待的计算平台，云服务器绝对不可能被看作是一个Edge computing platform，而车内系统也绝对不可能是一个真正意义上的Server。所以，SOA、Microservices这些概念最好是当做一种跨行业的方法借鉴，如果把这些在另一个系统上应用过的概念作为一个实现原则，则容易让工程师产生混淆。
回到本文所谓的“汽车SOA的微服务化”，在实践中我们发现以下几个问题，对传统的EE架构的工作流，存在一些深层次的挑战：
1、有没有可能存在一个对IT SOA项目实战经验非常丰富的软件架构师，同时对车内系统和整车业务逻辑了如指掌，在不需要任何技术交流和沟通的前提下，就可以独立完成微服务定义和设计，且完美耦合到Adaptive Platform的服务接口上，实现整个车内SOA架构设计的落地？
答案是：几乎不可能存在这样的个人。
我们需要的是一个满足SOA架构设计中进行微服务抽象的工作平台，设立这个工作架构的目的就是解决微服务的定义问题，那需要做的就是严格坚守设计工作的需求边界，建立Adaptive Platform软件工程师和车内其他子系统子业务单元的服务接口、微服务接口的技术沟通平台和接口定义及验证的工作流。
2、有没有可能通过技术采购途径，获得一套成熟的汽车SOA服务和微服务的接口定义以及相关的方法论和工作流？
答案是：可以，但是需要对应的团队来消化吸收。
回到IT云服务系统进行微服务抽象的最基本前提，微服务本身是个载体，承载的是整个IT系统针对业务逻辑进行细分管理要求。比如，IT行业里，A公司做电商平台，B公司参考A公司的IT系统微服务架构，实现了一模一样的系统做一样的电商平台，那B公司需要配置的是和A公司一样的业务流量和一样的团队规模，以及一样的IT软件工程师和系统工程师的资源来支撑和维护这套微服务架构。否则，就只有重新消化吸收后，参考这套架构，根据B公司自身的实际情况来梳理自己的微服务架构。
3、有没有成熟的标准化的方法论和配套的一站式工具，实现汽车SOA开发过程中接口微服务化的设计和验证？
答案是：我们希望有。参考传统汽车网络以CAN总线为主的开发配置工具和 Classic AUTOSAR标准化的实际情况。我们可以预见，即便出现了这样的完美解决汽车SOA设计开发要求的一站式解决方案或者一站式工具链，这套工具的复杂程度无法想象。
因为我们不能只定义信号而要定义非常多的软件接口；我们要管理各种不同的API网关而非进行简单的数据路由表管理；我们要管理多条不同的数据交互总线而不仅仅是CAN；这个工具不是仅仅提供微服务接口的系统测试仿真环境，而是要提供给软件工程师日常代码开发过程中对微服务接口的软件集成仿真环境等等。更何况，SDV的核心意义就是通过软件化，来加快对智能汽车功能的创新速度和迭代，而如此复杂的工具则很大程度上会限制软件的迭代速度。这点上，和SDV本身有可能是背道而驰的，所以如果真有这样的SOA架构设计工具，其作用也应该是约束管理软件工程师的行为，而是不管理整个汽车SOA架构本身。需要通过工具验证的不是微服务本身在架构层面的合理性（因为这个合理性很可能不是个技术问题而取决于业务逻辑），而是微服务定义和迭代的过程和软件工程师阶段性的交付物。
回答了几个自己设定的问题，那具体结论是什么呢？目前这个阶段，处在刚刚进入汽车SOA深水区的项目团队来说，挑战是全方位的，更多的是试错和总结的过程，大家都是在通过实践去认识这样一个新生事物，所以实践是验证SOA架构合理性的唯一途径。
当然，也可以适当分享一些面对“微服务”这样一个汽车里的新生概念的一些工程定义（也可以直接称作“服务接口分级”），供大家探讨，也欢迎行业专家对这些定义提出自己的见解甚至是挑战。
基于车内SOA架构实施中的微服务化不可回避的前提，我们定义了一些具体的工作（或条件）：
汽车SOA开发团队必须配置整车系统架构师和Adaptive Platform软件架构师。微服务抽象的一个重要标准，是被抽象的微服务接口和对应的软件模块，可以在独立于整车验证的开发环境中独立开发、验证、维护和迭代，当然，大项目节点上的系统集成是必要的。
一个ECU零部件上的已经成熟定义的CAN信号，理论上可以直接被命名为一个微服务接口。当然，由于这个CAN信号承载的子系统业务逻辑变成了一个“微服务接口”，所以这个CAN信号自然是被Adaptive Platform的另一个服务接口做调用的。既然这个CAN信号现在是服务于上层服务接口，那上层服务接口需要这个CAN信号进行合理的改动的时候，这个CAN信号必须响应改动并配合集成，因为这个ECU和承载子系统业务逻辑的CAN信号，是在提供“服务”。
Adaptive Platform上的POSIX操作系统的基础软件调用接口也可以被定义成“微服务”，比如存储、时钟、网络端口等，前提是SOA的架构师要具备管理这些操作系统微服务接口的能力和对应的工具。不能被管理的微服务接口的定义，是没有意义的。系统诊断和系统安全的问题必须解决，但是，既然通过SOA工作流无法管理，那就放到别的架构话题中去解决。
对于一个承载更复杂的功能逻辑（比如含云端数据、边缘计算、传感器采集、数据交互、跨越多个计算单元和子系统、甚至需要集成供应商算法）的服务接口和微服务接口的抽象设计，目前比较好的方式是基于各模块成熟的（非SOA）的API文档展开讨论。一份完整的子模块API文档包含了这个子模块本身的业务逻辑和技术积累，可能现有的API无法满足目前这个 汽车SOA架构项目的要求，但是由于API本身已经基本描述了这个子模块的业务逻辑和对系统的依赖关系，如果是集中对各子模块的业务和API实现非常了解的该子模块的软件负责人一起沟通，会是定义微服务的一条捷径。当然，纯粹的语言沟通或者临时画草图的方式，可能太理想化太随意，更好的是负责SOA服务接口抽象的软件架构师和系统架构师事先准备好了对于子系统业务逻辑，API接口和系统依赖的调查表，并现场逐一对齐。
作为一篇抛砖引玉的文章，本文旨在探讨一些SOA实践过程中的认识和思考，并试图将这些认识和思考表达出来，这里就不进一步深入了。
怿星科技：聚焦汽车电子领域 ，融合汽车与ICT技术，通过提供创新的产品和服务，加速新技术在汽车上的应用，帮助客户提升研发能力和产品质量。
