SOA的应用开发基础

怿星科技

于 2021-09-17 16:50:52 发布

阅读量1.2k

点赞数 3

分类专栏：新架构文章标签： java 数据库

本文链接：https://blog.csdn.net/m0_47334080/article/details/120352382

版权

新架构专栏收录该内容

13 篇文章 34 订阅

订阅专栏

概述

SOA(Service-Oriented Architecture)即面向服务的架构模型，以其独特的优势越来越受到汽车行业的重视，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被业务应用调用，从而有效控制系统中与软件代理交互的人为依赖性。所以今天这篇推文主要介绍座舱中的一些业务场景应用进行SOA服务开发。

开发基础

整个SOA面向需求转变的是松散耦合的粗粒度应用组件，也就是我们常说的服务。

2.1 如何理解服务?

汽车行业在没有SOA的模型情况下，在SoC车载应用端，我们更多的是采用OOD(Object-Oriented Design面向对象设计)的设计模型，面向具体的业务需求抽象成业务对象(类)的设计方式，那么我们如今调整为面向服务的架构模式，则对应的业务需求抽象则必须转变为提供该业务需求所抽象的一系列服务接口，最终形成一个提供多种基础服务的服务应用。

原有的OOD的架构层级示例：

现有的SOA的架构层级示例：

那么，我们会有两个疑问点：

1. 能直接就把原来的设计方式直接切换为服务吗？

2. 我们可以把任何一个服务独立成一个服务应用吗？

接下来我们带着疑问来看看下面的内容是否能解决这两点疑问呢？

示例：座舱中有空调的功能。

对于空调的业务需求来说，会有开关、A/C控制、出风模式、温度调节、风量调节、内外循环控制等等Feature。那么对于空调这个功能来说，空调是否就是那个服务呢?小怿理解的是服务实际包括以下内容：

为什么服务需要拆分至此颗粒度呢？因为终端用户使用的是业务场景需求是各个大型服务的基础服务。比如综合场景：度假模式, 该模式下将会对空调有自动控制，而在此场景下对于四季的夏天和冬天，对于空调这个服务应用来说，场景下用的服务是相同的，仅服务参数有所差异。

PS：以上场景数据纯属假设。

上面所讲的内容，对于之前使用OOD设计思想的同学们不禁要问了，这不就是空调控制类里面的接口方法么？根据业务需求，拟定一个对象，该对象提供相关的接口方法，属性，最终提供相关的接口给到应用方使用。

是的，SOA与OOD的接口实现方式基本上大同小异，但重要的是概念及使用的方式。概念我们今天就不赘述了，各位小伙伴可以自行搜索。那么使用方式会有啥区别呢？

按以往的OOD设计方式的接口实现方式：

调用的接口顺序是：

enableAirCondition ();

setAirConditionAC(on);

setAirConditionTemperation(all, 23.5);

或者提供一个度假模式的统一空调控制的接口来实现具体的行为, 里面包含的仍然是上面的这些接口。但是问题是：该模块/类是真正的执行ECU吗？不一定，比如车机的空调接口就大致这样的，它最终需要经过MCU的自定义协议传输控制字节到MCU，并经MCU把控制字节发送到CAN上，进而最终空调ECU才是最终执行方。

大致的数据流向如下图：

如上面流程所知，车机ECU对于空调服务是消费方、空调ECU才是该服务提供方。而在SOA模型中的实现方式则是另外一个样子，在场景业务（旅游模式）的数据模型里面将会增加多个method, 因为一个综合模式可能会消费多种服务，其中针对消费空调服务的method的payload中必含有空调的相关控制数据内容，如下：

那么当SOA的消费方(此处为场景服务)发送通过类似service id + method id + payload将会通过网络一直传输至真正执行的ECU（服务提供方）去执行，没有中间方了。

也许对于执行方来说，接口是近似的。但是对于SOA来说，如对于车机的接口，原来的空调控制接口都不再需要了（ps: 需要的也许仅是空调的状态服务接口）。

大致的数据流向如下图：

除了上述的服务示例外，我们也可从OOD&SOA层级中可知，OOD&SOA的差异除了服务层本身拆分得更多元外，重点的变更是通讯中心转变为服务中心。以往的OOD更多的是对象之间的交互，所以针对的多是对象（类/结构/数据等），而更换至SOA后，我们更多的是面对服务的一些基础概念：服务发现、服务订阅、服务发布、以及服务调用等等。

在汽车行业，我们可选的、常见的服务中心有哪些呢？它们又存在哪些区别？

因为考虑到整车的网络上的AP/CP AUTOSAR的接口，所以目前各家OEM常选用的服务中心（其实就是一套针对数据的标准协议簇）有如下两种：

2.2服务的分析与设计

说白了，SOA就是设计出一堆服务的集合体，通过各种服务的组合及相关的服务策略来实现具体的业务需求。那如何去划分这个服务才是SOA开发的开始。但是当前对于汽车行业而言，SOA是一套新引入的技术，需要一套有效的流程、方法和工具，用以解决如下三个问题：

1) 服务的分析与设计

2) 服务的建模

3) 服务的实现与部署

常用服务设计方法为 “用例驱动的开发方法”+“面向服务架构的设计方法”。

用例（Use Case）驱动的开发方法指从用户的角度而非开发人员的角度考虑功能需求和系统实现，重视从系统外部观察对系统的使用。由用例驱动的开发活动，可以建立需求和系统功能之间清晰的追溯关系，更好的应对智能网联产品需求的快速迭代更新。此开发方法基本适用于所有软件应用开发。

如上例中的空调的用例(这里就不用UML用例图说明了)，简单表述下：

面向服务的分析方法则是以业务为中心，在由用例分析得到系统功能需求的基础上，对业务逻辑进行抽象和封装，从业务角度寻找业务服务, 从业务服务抽取基础服务，从架构角度强调服务的重用性（reusable）、自主性（autonomous）以及组合扩展性（composable）特点，最终定稿各服务层级模型，充分发挥SOA设计理念的优势，而不是仅仅作为技术实现方式。

之前的例子也简要的说明了如何去根据业务需求分析设计基础服务, 尽可能的抽取出原子服务，但并不代表每个服务都属于服务层的组件。服务组件需要根据内聚/颗粒度进行提取。

2.2.1 服务的建模

小怿之前有发过一篇推文《如何在PREEvision中进行SOA建模》可作为参考。

此处就不再赘述了。

2.2.2 服务的实现与部署

其主要工作内容有：

1) 对服务接口行为的开发和实现，完成服务接口与服务主体逻辑的绑定；

2) 针对目标运行环境，完成对服务接口参数，服务主体运行参数的配置；

3) 服务接口与应用程序策略逻辑的集成编译并最终部署在目标机;

总结

在SOA架构中，服务是最核心的抽象手段和系统最基础的描述单元。每个服务组件具备独立的功能，且可被复用；服务组件之间的接口遵循统一标准，可互相访问，可组合扩展。业务过程则是带有状态和服务调度策略的服务组件的组合与扩展。通过SOA架构，可整合规划OEM在不同操作系统，硬件平台上(控制器)上的业务功能，实现对功能的快速迭代和重组，应对灵活多变的智能网联趋势下的业务需求。

那么今天的内容就介绍到这里了，大家有任何疑问可以在下方评论区留言哦，我们下期见啦～