浅谈汽车SOA架构开发和实施过程中的微服务化
1
汽车SOA（面向服务架构）
SOA（Service-Oriented-Architecture）是目前汽车行业非常热门的话题，在国内各OEM的下一代整车电子架构和智能网联功能开发项目中，更是需要首先明确的新概念和新事物。从理论到实践，汽车电子架构的研发正在经历从传统架构开发方法论到软件SOA开发方法论的转型过程。
这个过程中涉及的问题非常多，如在传统EE架构开发中从来不曾涉及的新需求，而这些新需求的导入并形成有效的交付物和工作流的过程，不是一蹴而就的，而应该是结合开发团队实际情况经过反复实践经验积累总结的，并基于一定的试错成本，在具体的开发项目中最终被参与项目的工程师团队广泛认可的产物。如果这个过程中的各种成果的表述和经验总结，包括组织架构、工作流等，能够获得全行业范围的认同，则更进一步反应出了从概念到方法论再到实践过程的价值。
本文就其中一个分支话题，或者说是子需求，进行一些实践层面的推导和描述，尝试从一个角度切入，分享在具体SOA开发工程实践过程中总结的经验，希望能够和同行们进一步的讨论。
2
服务架构的微服务化
SOA作为一个软件模块服务化设计的概念和实施原则，在IT行业应用得比较多。实际进行汽车SOA架构设计和开发的过程中，首先可以考虑进一步挖掘IT行业SOA开发的一些具体的实践成果和技术背景。相比早期的企业总线ESB，IT行业的SOA概念在云服务领域得到了更广泛深入的应用实践，且具体的实践方法和架构设计思维经历了多次明确的架构迭代，其中有一个显著的分界点在于SOA架构的微服务化（Microservices）实现的过程。
我们首先来看一下IT云服务架构对SOA中的Microservices实践的定义，由于IT行业开放度比汽车行业高一些，所以不存在IT行业的规范或者标准来定义SOA的各种不同的实现方式，而是在实践和迭代过程中，由IT 行业的一些头部公司，一些技术大牛，以及一些被分享、公开的参考项目或者参考架构文档，来推动行业的新共识的形成，进而推动技术进步。
IT云服务架构在具体落实中，微服务化过程对软件模块和服务接口在全局架构上的定义、抽象和管理的细节，对比更早期的SOA总线服务架构，有很多具体的区分：soa
这里只是简单罗列在IT系统中总线服务架构和微服务化架构的一些设计和实现的区别，总线服务架构和微服务化架构在IT云服务的实际应用中也是互有优劣，并不是说微服务化架构就一定比总线服务架构先进，需要在具体的业务需求框架下进行选择。一般来说，一家公司的IT业务在发展初期和反复试
错的阶段，直接上微服务化架构的后果很有可能是浪费IT工程师的开发资源，而一旦业务逻辑成型，得到了市场验证，并且规模化以后，将系统进行微服务化的改造是很有必要的。可以进一步细分和抽象系统内的子业务逻辑，增加各业务模块的可重用性，将代码维护工作进一步细分化和轻量化，提高硬件资源利用率，提高IT开发部门和业务部门对接的工作效率。当然，这个原则，也不是一定的。
3
车内SOA的微服务化
IT的SOA的具体实现服务于IT的系统、IT的业务逻辑和IT公司的利益，现在回到汽车SOA，我们引入了IT行业的SOA概念，显然不可能直接沿用IT系统的需求和逻辑。
我们参考了IT云服务系统的微服务化架构演化的过程，能得出一个什么结论呢？虽然汽车SOA的实践之路是独一无二的，但是IT云服务系统的SOA微服务化的特性，貌似更契合车内分布式系统和汽车工程的设计开发需求。
所以，基于汽车SOA的实践，我们发现，SOA概念在导入汽车架构考虑落地的第一个环节，我们已经原则上跳过了总线服务架构设计这个过程，直接进入了SOA微服务化设计的具体工作中，这是由汽车工程的系统需求和业务实际情况所决定的。
也就是说，车内SOA架构的设计和实现，固然需要重视Adaptive Platform 上的服务接口的定义和功能设计方法论的验证落实，同时也需要重视对整个EE系统层面各个子系统（或者子域）的微服务接口的规范化。包括如何定义微服务接口；如何描述微服务接口的需求；如何进行微服务接口（在不同总线上）的分类；如何进行微服务接口的诊断和维护；如何进行集成和测试。
4
汽车SOA微服务化设计对实施团队的要求
显然，我们在面对具体的架构设计项目，因为微服务化需求的不可回避性，让我们一下进入深水区。在目前一些国外的汽车SOA咨询文档中，很多并不提及Microservices这个概念，而是直接将车内SOA服务接口进行几个层级的定义（Feature、Sub-feature、Service、uService…），并规定了一系列设计方法和原则，避免产生“服务接口风暴”。本文仅是为了说明思考的过程，而引入了IT云服务的Microservice的概念，云服务器和车内系统本质上是两个完全不能等同看待的计算平台，云服务器绝对不可能被看作是一个Edge computing platform，而车内系统也绝对不可能是一个真正意义上的Server。所以，SOA、Microservices这些概念最好是当做一种跨行业的方法借鉴，如果把这些在另一个系统上应用过的概念作为一个实现原则，则容易让工程师产生混淆。
回到本文所谓的“汽车SOA的微服务化”，在实践中我们发现以下几个问题，对传统的EE架构的工作流，
存在一些深层次的挑战：
01
有没有可能存在一个对IT SOA项目实战经验非常丰富的软件架构师，同时对车内系统和整车业务逻辑了如指掌，在不需要任何技术交流和沟通的前提下，就可以独立完成微服务定义和设计，且完美耦合到Adaptive Platform的服务接口上，实现整个车内SOA架构设计的落地？
答案是：几乎不可能存在这样的个人。
我们需要的是一个满足SOA架构设计中进行微服务抽象的工作平台，设立这个工作架构的目的就是解决微服务的定义问题，那需要做的就是严格坚守设计工作的需求边界，建立Adaptive Platform软件工程师和车内其他子系统子业务单元的服务接口、微服务接口的技术沟通平台和接口定义及验证的工作流。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。