SOA系列之：小白入门

  SOA可以理解为一个通讯库。但是涉及的交叉领域特别多，所以显得很难。

1.SOA的定义

• SOA不是一种具体的技术，而是一种架构策略层面的指导思想或者范式，以达到组织利用处于不同所有权范围控制下信息的分布式系统。
• SOA作为一种面向服务的架构，是一种软件架构设计的模型和方法论。利用现有的各种软件体系，重新整合并且构建起一套新的软件架构。这套软件架构能够随着业务的变化，随时灵活地结合现有服务，组成新软件，共同服务与整个公司的业务体系。
  备注：SOA并不是新技术，IT行业早就有SOA的概念以及很多应用。目前，重点要探讨的是如何将SOA技术应用于汽车领域，如何在汽车上做好服务化的设计。

2.SOA的主要特点

  SOA的主要特点是松耦合带来的灵活编排。

• 标准化与松耦合
    SOA是一个服务模型，它将程序的不同服务通过定义良好的借口和契约联系起来。接口是采用中立的方式进行定义的，应该独立于实现服务的硬件平台、操作系统和编程语言。构建在这样的系统中的服务可以以统一和通用的方式进行交互。这种中立的接口定义的特征称为服务之间的松耦合。松耦合系统的好处有亮点，一是灵活性，二是当组成系统的某个服务内部结构和实现发生改变的时候不会影响其他服务，系统依然能够保持稳定。
• 服务可编排
    服务是最核心的抽象手段，业务被划分（组件化）为一系列粗粒度的业务服务和业务流程。业务服务相对独立、自包含、可重用，由一个或者多个分布的系统所实现，而业务流程由服务组装而来。一个“服务”定义了一个与业务功能或业务数据相关的接口，以及约束这个借口的契约，如服务质量要求、业务规划、安全性要求、法律法规的遵循、KPI等。契约采用中立、基于标准的方式进行定义。通过服务注册（Service Registry ）加上服务总线（Service Bus）来支持动态查询、定位、路由和治理的能力，使服务之间的交互式是动态的，服务的请求者和提供者之间高度耦合。
• 为什么需要服务松耦合？
    对于松耦合系统的需要来源于业务应用需要，可以根据需求编排不同的服务，提供不同业务功能。业务需要变得更加灵活，以适应不断变化的环境、用户的需求、项目的需求等，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。能够灵活地适应环境变化的业务称为“按需业务”，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要性的更改或者调整（编排）。

3.CAN和以太SOA的对比

  CAN和以太SOA都可以视为一种模块化和标准化，这是共性的。但是两者思考的维度不同。

• CAN希望每个模块都可以实现独立的逻辑功能，而不同模块之间的结合则可以提供更复杂的逻辑功能，实现低成本的功能重构和重组。
• 以太SOA希望每个模块可以实现独立的业务功能，而不同模块之间的结合则可以提供不同的应用，实现低成本的业务重构和重组。

你好！ 这是你第一次使用 Markdown编辑器 所展示的欢迎页。如果你想学习如何使用Markdown编辑器, 可以仔细阅读这篇文章，了解一下Markdown的基本语法知识。

3.1 CAN和以太SOA的对比举例说明

3.1.1 CAN开发

  开发阶段是OK的，在开发冻结后的售出阶段，智能座舱域要更新功能，则需要先更新座舱板块协议，再通过OTA刷写迭代更新。但由于CAN设计固定、整车EE架构高耦合，那么就会联动其他域控被迫跟随修改适配，比如下图中的智能驾驶域以及中央域涉及的协议及EE架构。因此，无法实现高效的整车功能迭代，各个板块无法独善其身。

3.1.2 以太SOA开发

  服务发布出来之后，各个域控根据自己的需求去订阅对应的服务。如下图，如果智能座舱域要更新功能，则调整订阅的服务即可，其他的智能驾驶域以及中央域等域控不受影响。

3.1.3 以太SOA的意义及优缺点

3.1.3.1 意义

• 层次化： 可以设计不同层级的服务，比如从底向上有原子服务、增强服务、场景服务。
• 差异化： 根据应用层需求去调用合适的服务，定制化的千人千面服务。是一个核心价值点。
  

3.1.3.2 优点

  能够更好更快地提供业务价值、快速应变能力、重用。
（1）对于业务应用的优点：

• 服务化给业务流程带来的灵活性，可以迅速创建新的业务流程和复杂的应用程序，以适应市场变化；
• 使用服务来应对客户需求，而不必担心底层复杂的基础架构；
• 借助安全、易管理的集成环境，称为响应能力更强的应用组织；
• 通过使用已有的、可复用的服务架构系统，所读啊开发和部署周期；
• 通过服务化来降低模块交互复杂性和维护成本；
• 增强和重组现有系统而不是替换现有的系统。
  （2）对于架构的优点：
• 服务之间的接口，无关底层编程接口和通信模型；
• 松耦合性，不同服务之间应保持一种松耦合的关系，也就是应该保持一种相对独立无依赖的关系；
• 位置透明性，所有服务对于其调用者来说都是位置透明的，也就是说每个服务的调用者只需要知道想要调用的是哪一个服务，但并不需要指导所调用服务的物理位置所在；
• 协议无关性要求每一个服务都可以通过不同的协议来调用。

3.1.3.3 缺点

• 对于服务治理提出了较高的要求；
• 有一定的额外资源消耗，对于系统的性能有一定的影响；
• 服务的粒度划分会影响整体系统的复杂度，需要平衡灵活度和复杂度的需求；
• 核心是对于处理SOA的人提出了很高的要求。

4.从技术上看SOA是什么？

  理解SOA的通讯属性，首先还是要先理解OSI参考模型。

  SOMEIP/DDS位于模型中的5-7层，应用层、表示层、会话层。由于，SOMEIP是位于AUTOSAR体系下的一个库，因此用得比较多。车载以太网在传输层和网络层的结构与IT领域几乎一样，但是为了满足一些汽车车规的要求，在链路层和物理层中与传统结构有一些区别，也有重新设计的TSN。

5. SOA需要思考的问题

• SOA这么好我们为什么不早点用？
• SOA这么好我们为什么不早点用？
• SOA是一种很复杂的技术吗？
• SOA可以作为一个独立技术被使用吗？
• SOA是最先进的通信手段吗？
• 项目一定要使用SOA吗？
• 域控架构这么好用，为什么不早点用？
• 敏捷开发这么好，为什么不早点这么做？
• OTA这么香，为什么不早点用？

    SOA被需要并不是一个单独事件，讨论为什么SOA被需要，我们必须理解整车汽车架构变化的背后成因，SOA只是连锁反应链条中的一环而已。

5.1 SOA与整车层次架构演进的关系

软件定义汽车具体涉及的方面如下，需要并行的进行升级改造：

5.2 核心的共性方法论

5.3 汽车SOA引起的变化

• 车联网级别案例-云端是SOA的发源地
  
  
• 汽车整车EEA架构变化-集中式架构、软硬弱耦合架构
  
  
• 平台化架构-提高复用可能性
  

5.4 SOA与EEA架构

5.4.1 域控制器EEA架构

    SOA服务主要是在域控制器和云端，微控制器不是SOA的主战场，域控制器与微控制器之间主要是一些信息的交互。

    以下是域控制器的一个内部结构，左边是安全计算芯片和服务调用逻辑相关度低，但是SOA往往和功能安全会冲突，这一块在设计中需要去考虑。右边是高性能计算芯片，SOA的计算主要在这块SOC上。

5.4.2 通讯架构

    SOA多基于SOMEIP实现，在大数据传输方面弊端较为明显。

    总结，我们介绍了控制器架构和通信架构，CAN其实可以理解为一个通信概念。但是SOA不是，它是通讯和域控制器交接面上的一个中间部分，即和计算有关，也和通讯有关。

5.4.3 软件架构

    每个服务订阅的人数不同，所以对芯片的算力及通讯负载要求不同。

总结：

5.4.4 研发架构

以上为本章节所有内容。
敬请期待～