为啥是SoA?（SoA化的挑战）

最新推荐文章于 2024-07-29 16:15:04 发布

coroutines

最新推荐文章于 2024-07-29 16:15:04 发布

阅读量753

点赞数 1

分类专栏： SoA 汽车电子文章标签： SoA 基于服务的架构汽车电子过程

本文链接：https://blog.csdn.net/coroutines/article/details/113767814

版权

汽车电子同时被 2 个专栏收录

7 篇文章 3 订阅

订阅专栏

SoA

2 篇文章 2 订阅

订阅专栏

1 SoA的历史

SoA的概念可以追溯到上世纪90年代银行系统的变革上。柜员提供服务时，针对不同的业务，即使是同一个客户，也要在多个老式的银行终端反复切换，这造成了人力的浪费和客户满意度的下降。于是银行做了2件事：

通过使用CORBA，降低终端数量及统一访问接口 这里需要注意的是，特定技术并不是唯一的选择，也不是解决问题的主要手段，更重要的是思考如何解决问题所需要采用的方法。银行通过抽象一系列分布式的对象，通过这些对象构建了位于终端界面与后台主机之间的一个抽象层，并提供了新的UI画面，用于统一访问不同的后台对象。如下图所示：
重用管理，银行为能够实现正确后台服务，并确保开发人员能够重用这些服务，设立专门的人员，用于协助开发人员设计、实现这些服务，包括定义接口、确保终端应用正确的查找到后台服务，以及后台服务进化的前景及路线图。
组织架构调整，银行将原单一开发团队，划分为后台服务团队与终端开发团队。通过调整，将原基于服务的开发周期缩短到了1/4。

2 从历史中能学到什么

上一节中给出了一个SoA发展的小例子，历史上有很多成功和失败的SoA实践，主要的原因大致有以下2个方面：1. 技术难度太高，2. 没有搞清楚SoA的基本特性。现在实施SoA在成功案例比较多，是因为开发环境和工具的进步，使得基于SoA开发的难度降低，但同时也屏蔽了大量的细节。因此，如果想要在车载领域实施SoA的话，技术平台的技术需求一定要搞清楚。
但另一方面，并不是掌握了技术，就能够成功实施SoA。首先有一点需要搞清楚的是，除了必要的技术方面，还要搞清楚能够使用这些技术做什么。我们需要从整体架构视角去判断都有哪些服务，如何构建和使用这些服务。其次，同等重要的是，从赢利的视角上，要看到哪些数据和过程可以用于支撑这些服务的运行，哪些能力用于支撑这些过程，以及未来对于服务的路线图。最后，架构和过程需要能够结合到一起，形成能够实施的方法论。下图给出历史上SoA实施成功实施的要点：
在这里插入图片描述
有调查指出，实施SoA时，相关人员的期望主要包括：敏捷性、灵活性、重用、数据合理化、集成和降低成本几个方面。详细的说：

对于已有资产的策略性重用
对于商业过程提供更敏捷的支持，来更有效的应对变更的影响
精通数据管理
加速和简化项目的部署，减少重复的工作
支持外部协作
降低开发成本
协调分布式的开发产品线
集成历史系统

3 实施SoA时的挑战

实施SoA的挑战可以归结为以下几个方面：

跨部门合作时的敏捷性、灵活性和资产的策略性重用该如何实施
在引入这些能力时，如何提高交付的效率和降低成本
在分布式开发时，如何有效的集成和利用已有资产或者数据，达成更快的交付
SoA的敏捷性和灵活性如何帮助实现商业上的目的

SoA的挑战可以以下面这张图来概括：
在这里插入图片描述

首先的重用，重用真的发生过么？从我个人的经验上来说，嵌入式系统架构上的重用，或者多媒体中间件的重用是真实存在并且发生过的。但这些更多的是基于经验和技术的一些总结和抽象，应用在一些小型的系统或者某个子系统中，的确能起到比较好的效果。对于服务可否采用同样的思路呢？毕竟，我是把系统中容易发生变化的部分剥离到外部去了。服务的重用，不取决于采用了什么样的技术，主要的障碍在于组织上的、方法论上的和政策上的问题。因此对于重用，在技术平台的架构上，有如下的需求：

服务的使用者能够发布、查找、评估服务及注册为使用者
架构有能力管理及维护服务的生命周期
能够保证服务的质量及指定版本的生命周期
对于使用者，能够解耦其与服务生命周期的关联

高效的开发意味着在尽可能短的时间内，以尽可能少的成本，完成尽可能多的功能。达成这个目标依赖多种因素，包括重用已有的服务以及基于这些服务，快速的构建应用程序。对于一些团队或组织来说，引入不同的开发方法可能更方便达成这个目标。比如通过引入明确定义的过程模型（如，参考ASPICE），方便相关人员查找必要的服务相关的基本信息；或者，使用新的系统设计方法论（如，MBSE），关注构建业务模型，而不是过多的把注意力放到服务本身上。然后，通过层次化分解，在不同的级别和范围，关注如何实现业务模型。MBSE中，还可以提供分析方法，用于明确服务之间的交互、接口及涉及到实现上的一些决策手段。另外，有必要的话，还需要对组织架构进行必要的优化，如前面银行的例子，分为服务的使用者与服务的提供者。对于高效的开发这个挑战，技术架构上至少要满足下面这些需求：

参考架构，用于指导服务设计
定义业务流程，用于发现和定义必要的服务
过程模型，可以有效的管理服务的完整性，包括服务的使用者和提供者

应用和数据的集成是一件特别容易让人迷糊的事儿。老的系统应用和数据之间有可能采用了一些点对点协议，比如DBus，ProtoBuf之类，或者是一些自定义的RPC/IPC协议（通常可维护性、可扩展性渣得一坨）。基于Web Service的SoA给出了数据通信实现的一些参考，但技术只占SoA的一小部分，关键还在于对于业务模型的思考。比如，不能再使用点对点的通信，而是考虑采用将所有独立的应用/服务，连接到整体的业务模型上。另外，对于暴露接口的过程，也得考虑，是否还要基于原先老接口来实现，是不是应该采用最新的技术手段更新接口实现。对于数据的集成来说，需要关注的点也不是数据列表中的数据结构该如何定义，而是哪些数据要通过接口共享出去，内部数据的定义和维护，由应用自己来管理就行了。对于集成来说，如下的架构需求需要考虑在内：