云端软件|【上汽零束SOA】云管端一体化SOA软件平台系列三：软件架构

上一篇文章Zero Beam主要介绍了电子电气架构的演进方向以及基于SOA架构的一些优势。本文将继续深入，重点关注SOA软件架构的相关内容。

1）了解 SOA 软件架构

2）SOA 软件架构的现状

3）SOA软件架构设计方法

4）目前SOA软件架构面临的问题

5）SOA 软件架构的未来

一、理解 SOA 软件架构

在百度百科的定义中，SOA是一种面向服务的架构，可以根据需求通过网络分发、组合和使用松耦合的应用组件。服务层是SOA的基础，可以直接被应用程序调用，从而有效控制系统中与软件代理交互的人为依赖。

从另一个角度看，服务是SOA的主体，服务之间的关系构成了SOA软件架构。把服务称为钻石，SOA软件架构一定是一座高耸的大楼，大楼的不同楼层代表着服务之间的相互依赖和联系。即SOA软件架构中包含了分层的思想，服务就是分层的服务。下层服务使用上层服务，上层服务为下层提供能力支持。通过对不同下层服务的需求进行分离和聚合，一层一层的生成上层服务，逐步迭代，最终生成SOA软件服务的分层架构。

目前在新五化浪潮下，车联网普及率非常高，所以我们设计的SOA软件架构包括车端SOA软件架构+云软件架构。

↑SOA软件架构层次

如上图所示，SOA服务分为基础服务、扩展服务、应用服务。这三种服务类型对应不同的能力属性，每一种服务都有明确的服务统一性，即每个服务单元只提供一种服务或只提供一种功能。从中也可以看出，服务的产生是由于功能，不同用户对同一功能的需求使服务下沉和聚合。多个下层服务使用同一个上层服务，所以需要服务标准化，简单来说就是服务套接字的标准化。

SOA软件架构还有其他特点：高内聚、低耦合、服务平台独立、动态服务部署/动态发现。因此，基于SOA架构的操作系统分为以下几个层次，实现了完整的SOA软件架构。

1）OSAL层：屏蔽操作系统对SOA框架的影响

2）SOA层：提供基于SOA架构的服务设计所需的所有基础组件

3）SOA层：提供通用的SOA服务，提高功能的复用率。它由 2 个子块组成： a) 基础服务层：可以独立运行而无需外部依赖的服务； b) 扩展服务层：使用基础服务，进行纵向组合扩展，实现复杂功能逻辑的服务

4）外部服务层：根据项目需求，使用其他域控制器或云端提供的服务套接字，实现“云-管-端一体化SOA软件平台”

5）应用服务层：基于SOA和SOA提供的能力支持，根据需求定制逻辑业务功能。

6）应用层适配层：将SOA服务与应用层隔离，将SOA服务转换成不同系统的开发语言，加快应用层开发效率，隔离应用层来自 SOA 服务层。

7）云端层：基于SOA软件架构，通过车云集成软件组件实现车云服务等效和位置独立。

但是在层次化设计的过程中，域内和域间不同层级之间的设计遵循标准C/C++ 规范和标准POSIX 规范，云端采用服务代理的形式，内部封装标准规格插座。这些规则赋予了SOA服务平台无关的属性，从而整个SOA软件架构也实现了平台无关。

二、SOA 软件架构的现状

2007年，IDC发布了《S0A中国路线图》。 SOA概念开始在国外流行。那时，SOA的概念在新加坡已经深入发展并达到普及的程度，而中国才刚刚起步。相差10年左右。

SOA软件架构一开始是IT互联网行业为了解决单服务器架构系统耦合度高、开发效率低的问题而提出的分布式系统架构一、，目前已实现巨大的成功。成功。现在，借鉴以往互联网行业SOA软件架构的成功经验，我们希望将这种架构移植到车载领域，希望能解决车载软件开发中遇到的困难：

1）不同的ECU软件系统差异很大，体现在硬件、系统、资源等方面。

2）预留资源少，主要分配给某些功能，后期更新迭代难以兼容

3）通信契约和网络拓扑是固定的（通过LIN/CAN等硬线连接）

4）对于新缩减的功能，往往需要多处同步变化。

5）车载软件往往作为独立实体存在，难以与云端连接，形成车联网

长期以来，国外整车OEM厂商受制于逆向开发进程，极大地扰乱了整车厂的主动权。 OEM厂商受制于平台化组件，其功能仍未能实现突破性发展。很多OEM厂商想要改革，软件定义汽车(SDV:)的概念最近逐渐升温。目前，国外各大主流OEM厂商和顶级Tier 1都在不同程度地测试SOA架构，希望能够突出。重新包围，找到企业的突破口。

在软件定义车辆概念的疯狂普及中，SOA软件架构起着至关重要的作用。它是这次改革的排头兵，将拉开这场改革的帷幕，使改革显得顺理成章。

三、SOA软件架构设计方法

从上面可以看出，SOA软件架构在巨大的推动力下正在向前运行。一个优秀的 SOA 软件架构的设计必须满足以下特点：

1）屏蔽异构性：SOA 服务之间使用标准中性套接字和契约来屏蔽不同硬件、系统和开发语言之间的差异。

2）服务是可重用的：服务重用可以通过组件之间的组装、编排和重组来实现。

3）数据共享：在SOA服务层面，所有服务都连接到总线上，也就是说每个服务都可以获取连接到总线上的服务提供的数据，打破了传统功能的信息孤岛.

4）灵活调整：基于总线的SOA服务不需要关心服务的位置。总线作为服务之间的桥梁，每个服务都可以根据需要灵活迁移和升级。

5）降低用户成本：用户无需关心各个服务之间的服务，只需要通过现有的标准化套接字调用即可实现服务功能。

6）服务运行状态控制：SOA中的服务注册发现能力可以帮助用户识别异常服务，保证系统正常运行。

7）云管端综合服务平台：构建车载服务与云服务的点对点关系。云服务和车载服务使用标准化的统一套接字进行交互，完成服务功能。

在上述特点中，提到了三个重要的点：

1）一是服务改进能力

2）另一个是总线，这里特指ESB总线（Bus）

3）最后一个就是前面提到的车云一体化软件组件

零梁云管端一体化SOA软件平台通过多样化的SSP()实现以上三点，其中服务修复能力包括以下几部分：

1）服务动态发现：服务支持动态插入、删除和更新。服务提供者管理服务的所有依赖和资源需求，并控制服务提供/停止的时间。

2）服务设计：SSP对服务的实现有详细的设计要求。在服务设计过程中，需要满足相应的需求才能实现SOA。

3）服务实现：根据SSP提供的服务，完成实现的代码开发。

4）服务部署：SSP从设计之初就继承了跨平台属性，服务可以根据实际使用情况在不同的环境、硬件、系统中部署一个或多个实例，实现复用率最大化.

5）服务管控：在服务运行过程中，服务的运行管理，包括服务状态管理，服务执行管理，以及相关的服务运行数据等，都可以被SSP检测到，并通过数据收集。确定服务的运行健康状况，为服务乃至整个系统提供强大的稳定性和性能保障。此外，服务的权限配置也是一个重要的考虑因素。服务发布后，可以控制外部授权管理，保证只有允许/信任的服务才能使用服务。

6）ESB 总线：

SOA软件架构有个明显的特点，就是服务中心化的思想。服务之间的所有连接都需要通过 ESB 总线进行通信。 ESB 总线的名称是通信总线，但我们觉得将其称为 ESB SOA 服务中间件更为合适。 ESB 总线实现了以下特性：

a) 严禁所有服务之间的任何直接连接。唯一允许的通信方法是通过网络调用服务套接字。

b) 对网络调用的具体实现方式没有强制性要求，可以根据不同系统的特点选择最优方案。目前支持Http、ZMQ、VIWI等，但都需要支持以下能力：同步请求、异步请求、订阅、发布。

c) 服务套接字的设计基于设计的开放性，即所有服务套接字都必须由外人开发，无一例外。

d) 车云集成软件组件

e) 实现车端云服务对等和位置独立

f) 并根据不同车型的配置，实现个性化的配置管理和相应的服务管理

↑SOA 软件架构

虽然，SOA软件架构中有一个特别重要的功能，服务管理。如前所述，所有基于 SOA 软件架构的服务开发，其套接字必须完全暴露，任何人都可以使用，这实际上带来了极大的便利性和可扩展性。此外，我们不能同时忽视车辆的安全性。因此，在满足了我们所需要的所有属性之后，我们仍然需要对 SOA 软件架构做相应的安全防护，以防止黑客和第三方应用程序/服务的恶意攻击。保护整个系统的稳定性和效率。

在SSP中，通过服务管理，可以根据不同的模型进行适配，并且可以动态更新权限配置信息，保证多平台通配符。甚至，SSP还支持与账号等绑定权限，实现同车上千种功能。

四、目前SOA软件架构面临的问题

软件开发行业有句谚语“软件开发没有手枪”。以上介绍了很多SOA软件架构的设计和优势，但是SOA软件架构并不能解决所有的问题。让我们分析一下 SOA 软件架构可能面临的一些挑战：

1）性能：SOA 软件架构将通用的功能逻辑封装到服务中云端软件，这意味着将之前的功能体拆分为不同的服务，然后将它们编排组合在一起以生成业务功能。服务之间通过网络进行通信，降低了系统的复杂度，对性能影响不大。

2）基于SOA软件架构开发的服务都是独立部署的。与传统的功能块部署相比，降低了复杂度。每个服务都需要独立的配置、部署、监控、日志收集等，运维成本会增加。

3）一个完整的功能一般需要多个服务协同工作。这涉及到服务之间的依赖测试和服务异常的容错处理机制，对服务开发过程的要求比较高。

4）目前的SOA多基于SOME/IP实现云端软件，在大数据传输方面劣势明显。

5）SOA架构在设计和实现的初期会花费更多，投资回报暂时没有量化。

6）SOA服务定义粒度定义标准尚不明确，就像一百个人心中有一百个哈姆雷特一样。

7）云-管-端一体化SOA软件框架下，云端与车载终端的通信延迟也是目前的一大痛点。

五、SOA 软件架构的未来

我们认为SOA软件架构的升华是微服务架构。两者最大的区别在于SOA软件架构是中心化的，而微服务架构是去中心化的。

为什么说两者有升华关系？原因是本质是一样的，只是服务的丰满度不同，如下：

1）微服务专注于SOA服务的连续细粒度分离，不同的功能相互独立，每个微服务只关注一件事。

2）在SOA软件架构中，服务的失败会导致服务整体的失败，而微服务可能只会导致服务的降级。

3）在可扩展性方面，SOA软件架构是指服务级别的扩展，而微服务架构可以对单个服务进行功能扩展。

4）在通信方面，采用轻量级的通信架构，减少/消除微服务拆分带来的服务数量增加对性能的影响。

微服务架构在云端已经相当成熟。车端微服务化后，再加上我们集成的车云设计，可以完美对接云服务，支持向上兼容。

随着时代的发展和科技的进步，恐怕会激发出越来越多优秀的软件架构或指导思想来指导车载软件的发展。

六、结论

零光云管端一体化SOA软件平台的SOA系统解决方案，正是基于对SOA软件架构的思考，为车载SOA软件架构提供了灵活、可配置、可扩展的解决方案。同时，零束云、管、端一体化SOA软件平台是高可靠性、量产的整车SOA软件平台。致力于赋能基于SOA软件架构打造智能汽车的合作伙伴，共同构建智能汽车软件新生态。

其中提到车云一体化软件组件零捆绑会在后续章节中详细分享给大家，敬请期待。