 上一篇零小束主要介绍了电子电气架构的演进方向，以及基于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） OS AL层：屏蔽操作系统对SOA架构的影响 2）SOA Framework层：提供基于SOA架构的服务设计所需的所有基础组件 3）SOA Platform层：提供通用化的SOA服务，提高功能的复用率，共包含2个子块：a）基础服务层：可独立运行，无外部依赖的服务；b）扩展服务层：使用基础服务，进行横向组合扩展，实现复杂功能逻辑的服务 4）外部服务层：根据项目需求，使用其他域控制器或云端提供的服务接口，实现“云管端一体化SOA软件平台” 5）应用服务层：基于SOA Framework和SOA Platform提供的能力支撑，根据需求定制的逻辑业务功能。 6）应用层适配接口层：将SOA服务与应用层隔离开，转化SOA服务接口为不同系统的native开发语言，加速应用层开发效率，使应用层与SOA服务层隔离。 7）Cloud Service层：基于SOA软件架构，通过车云一体化软件组件实现车端—云端服务对等且位置无关化。 并且，在层级设计过程中，域内/域间不同层级间的接口设计遵循标准C/C++接口规范和标准POSIX接口规范，与云端采用服务代理的方式，内部封装标准RESTful规范接口。这种规则赋予了SOA服务的平台无关化属性，从而，整个SOA软件架构也就实现了平台无关化。 二、SOA软件架构的现状 2007年，IDC发布了《S0A中国路线图》。SOA概念开始在国内流行。彼时SOA概念已在美国深入发展并达到普及的程度，而中国才刚刚开始。其中差距大约在10年。 最初，SOA软件架构是IT互联网行业为了解决服务器单体架构的系统耦合性高、技术选型单一、开发效率低下等问题而提出的分布式系统架构，并且取得了巨大的成功。如今，借鉴着过去互联网行业SOA软件架构的成功经验，我们希望能将此架构迁移至汽车领域，以期望能解决汽车软件开发遇到的困难： 1）不同ECU软件系统差异大，表现在硬件、系统、资源等方面 2）资源预留少，主要分配给确定的功能，无法兼容后期更新迭代 3）通讯协议及网络拓扑固定（通过LIN/CAN等硬线连接） 4）对于新增加的功能，往往需要很多地方同步变更，可谓是牵一发而动全身，且更改成本高、周期长 5）车载软件往往以独立个体形式存在，无法与云端连通，形成车辆网络 长久以来，国内汽车OEM厂商饱受反向开发流程的压迫，极大的压抑了OEM的主动权，OEM厂商受制于平台化的零部件，功能始终无法得到突破性发展，越来越多的OEM厂商想要变革，恰逢最近软件定义汽车（SDV：Software Design Vehicle）的概念逐渐被炒热，目前国内各大主流OEM厂商跟顶级Tier1都在不同程度上对SOA架构进行试探，以期望能突出重围，找到企业的突破点。 在软件定义汽车概念的疯狂普及中，SOA软件架构发挥着至关重要的作用，它是这次变革的急先锋，将拉开这场变革的序幕，让变革变得水到渠成。 三、SOA软件架构的设计方式 从前面可以看出，SOA软件架构在巨大的推动力下在向前奔跑，设计优越的SOA软件架构，必然要满足以下特征： 1）屏蔽异构性：SOA服务间采用标准中立的接口和契约，屏蔽不同硬件、系统、开发语言间的差异。 2）服务可复用：可通过组件之间的组装、编排和重组，来实现服务的复用。 3）数据共享：SOA服务层级中，所有服务均与总线连接，意味着每一个服务都可以获取到连接到总线上的服务所提供的数据，打破了传统功能的信息孤岛。 4）灵活调整：基于总线的SOA服务，无需关心服务的位置，服务间以总线作为连接的桥梁，每个服务可根据需求灵活迁移、升级等。 5）降低用户成本：用户无需关心各服务间的language binding，仅需通过现有标准化接口调用，实现服务功能即可。 6）服务运行状态管控：SOA中的服务注册发现能力，可帮助用户识别异常服务，保证系统正常运行。 7）云管端一体化服务平台：建立车端服务与云端服务的对等关系，云端服务与车端服务采用标准化的统一接口进行交互，完成服务功能。 以上特征中，提到3个很重要的点： 1）一个是服务治理能力 2）另一个是总线，在这里特指的是ESB总线（Enterprise Service Bus） 3）最后一个是上面提到的车云一体化软件组件 零束云管端一体化SOA软件平台通过定制化SSP（Software Service Platform）实现了以上3点，其中，服务治理能力包含如下部分： 1）服务动态发现：服务支持动态插入、删除、更新，由服务提供方管理服务的所有依赖关系、资源需求等，并控制服务offer/stop的时序。 2） 服务设计：SSP对服务的实现有详细的设计要求，服务设计过程中，需满足相应要求来实现SOA化。 3） 服务实现：根据SSP提供的服务接口，完成接口实现的代码开发。 4）服务部署：SSP在设计之初就继承了跨平台属性，服务可根据实际使用情况，在不同环境、硬件、系统中部署一个或多个实例，以达到最大化的重用率。 5）服务管控：服务运行过程中，服务中的运行管理，包括服务状态管理、服务执行管理、相关的服务运行数据等，都可以被SSP监测到并通过收集到的数据判断服务的运行健康度，给服务乃至整个系统提供强有力的稳定、性能保证。除此之外，服务的权限配置也是很重要的考虑选项，服务发布后，可控制对外的授权管理，保证只有允许/授信的服务才可以使用服务。 6）ESB总线： SOA软件架构有个显著的特征，即服务中心化思想。服务之间的所有连接，均需通过ESB总线通讯。ESB总线名称上是通讯总线，但我们认为，应该把ESB称之为SOA服务中间件更恰当，ESB总线实现了以下几个特征： a）所有服务间禁止任何形式的直接连接，唯一许可的通信方式，就是通过网络调用服务接口。 b）网络调用的具体实现方式不做强制要求，可根据不同系统的特性选择最优解决方案，目前支持Http、Binder、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软件架构打造智能化汽车的伙伴赋能，共同打造智能化汽车软件新生态。 上面提到车云一体化软件组件零小束将在后续章节中详细跟大家分享，敬请期待。 |
|
|
