汽车服务架构(SOA)开发设计
Posted 不懂汽车的胖子
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了汽车服务架构(SOA)开发设计相关的知识，希望对你有一定的参考价值。
目录
1.7.1 AP（Adaptive Platform）的开发
(Service-Component-Architecture)
1.什么是SOA
SOA (服务导向架构，Service Oriented Architecture) 作为一种架构范式，展示了技术中立的最佳实践。其建立在标准之上，可在供应商的广泛支持下在全球范围内实现经济高效的实施。以在企业内部和跨企业创建新业务功能方面重用和重新组合服务，SOA很好的做到了“粗粒度”和“松散耦合”的特点，相较于当前分布式物理架构具有更大的灵活性。SOA 最佳实践创建包含业务流程的设计 —— 并增强将流程外包和扩展给业务合作伙伴的能力。此外，SOA也可以复用已有的系统和流程，与传统的基于孤岛的应用程序开发更具战术性的本质形成对比，可以保留和增强现有投资承建的架构、软件等实现的部分有用性。
1.1 SOA优缺点
优点：
- 扩展方便：可针对单个服务提供资源扩展
- 语言通用：接口通用，服务可以基于任何语言
- 新人友好：单一模块服务理解透彻即可服务此模块，不必理会架构
- 发版方便：可更新单一模块，不影响架构
缺点：
- 问题排查不便：功能调用服务多，很难直接定位问题点
- 沟通不便：模块独立，不确定其他模块状态
- 性能问题：通信时间损耗
- 关系混乱：服务越来越多，调用方越来越多的时候，就会比较混乱
- 运维难度：随着服务的增多，系统架构会越发复杂，这就给运维层面带来了挑战
- 数据一致性问题：单体项目因为数据都在同一个数据库里面，不需要过多的关注分布式事务等问题，SOA就需要关心了
1.2 SOA 应用优势
早期的车内嵌入式软件没有统一标准，基础软件和应用软件强耦合，不具可移植性；AUTOSAR Classic 的应用，对嵌入式基础软件的接口进行标准化，让应用开发者基于统一的基础软件接口进行应用开发。目前采用SOA软件服务架构的应用打通了车内的电子电气架构的壁垒，进一步对嵌入式应用软件的接口(即服务接口)进行了标准化，让APP开发者基于统一基础服务接口进行应用的迭代开发，隐藏了不同车型配置下应用软件的差异，真正做到了整车级软件接口的"标准"和"开放"。
平台架构升级更便于实现，通过服务设计的方式，能够有效降低架构升级带来的复杂度；同时，由于操作系统跨平台的难度大幅度降低，能够大幅提升用户体验，能够实现更为便捷的联网功能，实现不同平台间的各种APP共享等功能；
通过“服务Hub”区域控制器的引入，各种新功能能够灵活地与其他域功能，乃至互联网接口集成，而无需各个控制器各自进行信号到服务的转换；
一些相对独立的域开发能够打破界限，找到新的上限，例如自动驾驶功能不再是电子电气架构“孤岛”，通过区域控制器进行服务互通，可以轻松实现高清地图的创建、更新及路线预测等功能，便于实现车辆信息的上传及云端指令的下达。
1.3 服务的基本结构
独立的服务结构如下图
服务模型的表示层从逻辑层分离出来，增加了服务对外的接口层。通过对服务接口的标准化描述，使得服务可以提供给在任何异构平台和任何用户接口使用。这允许并支持基于服务的系统成为松散耦合、面向构件和跨技术实现，服务请求者很可能根本不知道服务在哪里运行、是由哪种语言编写的，以及消息的传输路径，而是只需要提出服务请求，然后就会得到答案。
1.4 SOA架构的核心要素
要准确全面理解SOA，首先必须理解SOA的核心要素：
SOA的目标就是实现灵活可变的IT系统。要达到灵活性，通过三个途径来解决：标准化封装、复用、松耦合可编排。
互操作(标准化封装)、复用、松耦合等SOA技术的内在机制，也是中间件技术和产品的本质特征。
标准化封装（互操作性）
传统软件架构，因为封装的技术和平台依赖性，一直没有彻底解决互操作问题。互联网前所未有的开放性意味着各节点可能 采用不同的组件、平台技术，对技术细节进 行了私有化的约束，构件模型和架构没有统一标准，从而导致架构平台自身在组件描述、发布、发现、调用、互操作协议及数据传输等方面呈现出巨大的异构性。各种不良技术约束的结果是软件系统跨互 联网进行交互变得困难重重，最终导致了跨企业/部门的业务集成和重组难以灵活快速的进行。
在软件的互操作方面，传统中间件只是实现了访问互操作，即通过标准化的API实现了同类系统之间的调用互操作，而连接互 操作还是依赖于特定的访问协议，如JAVA使用RMI，CORBA使用IIOP等。而SOA通过标准的、支持Internet、与操作系统无 关的SOAP协议实现了连接互操作。而且，服务的封装是采用XML协议，具有自解析和自定义的特性，这样，基于SOA的中间 件还可以实现语义互操作。
SOA要实现互操作，就是通过一系列的标准族，来实现访问、连接和语义等各种层面的互操作。
软件复用
软件复用，即软件的重用，也叫再用，是指同一事物不作修改或稍加改动就多次重复使用。从软件复用技术的发展来看，就 是不断提升抽象级别，扩大复用范围。最早 的复用技术是子程序，人们发明子程序，就可以在不同系统之间进行复用了。但 是，子程序是最原始的复用，因为这种复用范围是一个可执行程序内复用，静态开发 期复用，如果子程序修改，意味着所有 调用这个子程序的系统必须重新编译、测试和发布。
SOA的复用
为了解决这个问题，人们发明了组件（或者叫控件），如MS操作系统下的DLL组件。组件将复用提升了一个层次，因为组件可以在一个系统内复用（同一种操作系统），而且是动态、运行期复用。这样组件可以单独发展，组件与组件调用者之间的耦合度降低。
为解决分布式网络计算之间的组件复用，人们发明了企业对象组件，如（Com+,.NET,EJB等)，或者叫分布式组件。通过远程对象代理，来实现企业网络内复用，不同系统之间复用。
传统架构的核心是组件对象的管理。但分布式组件也是严重依赖其计算环境，由于构件实现和运行支撑技术之间存在着较大的 异构性，不同技术设计和实现的构件之间无法直接组装式复用。
而现代SOA的重要特征就是以服务为核心，如WebService,SCA/SDO等。通过服务，或者服务组件来实现更高层次的复用、 解耦和互操作，即SOA架构中间件。
因为服务是通过标准封装，服务组件之间的组装、编排和重组，来实现服务的复用。而且这种复用，可以在不同企业之间，全球复用，达到复用的最高级别，并且是动态可配置的复用。
耦合关系
SOA架构在松耦合解耦过程也发展到了最后的境界。传统软件将软件之中核心三部分网络连接、数据转换、业务逻辑全部耦 合在一个整体之中，形成“铁板一块”的软件， “牵一发而动全身”，软件就难以适应变化。分布式对象技术将连接逻辑进行分 离，消息中间件将连接逻辑进行异步处理，增加了更大的灵活性。消息代理和一些分 布式对象中间件将数据转换也进行了分 离。而SOA架构，通过服务的封装，实现了业务逻辑与网络连接、数据转换等进行完全的解耦。
SOA不断解耦的过程
总之，从科学哲学的角度来看，SOA是一个不断解构的过程，传统软件强调系统性，耦合度过高，所以需要松耦合（解耦）；SOA也是一个组件粒度的平衡，集成电路趋势是集成度越来越高，软件发展的趋势是相反的过程；SOA是架构，更是 方法，反映了人们对哲学思想的追求的原动力。
按照这个特性，SOA基本上来说与WebService并不是同一个概念，SOA并不一定需要WebService实现，理论上可以在其他技 术体系下，实现SOA。但事实上，到目前为止，能够实现SOA架构风格的技术就是WebService，因为它的特性和厂商的支持 力度，使得WebService成为了实现SOA实现技术的事实标准。也正因为WebService技术的成熟，才使得已经提出10多年了的 SOA思想和概念，得以能够实现落地，成为一种可以使用的技术。这也就是回答了SOA和WebService的关系。
1.5 SOA服务架构开发趋势
传统汽车使用由上百个ECU组成的分布式EE架构，OEM定义对各ECU的功能需求，由不同供应商负责最终功能实现。这种架构导致大量功能控制逻辑在子节点ECU内部完成，传感器、执行器信号被掩埋在分布网络下，仅通过在局部网络的ECU部署基于服务的通讯，无法实现对整车硬件能力的充分暴露。且考虑到基于SOA软件平台，未来SOP后的车型也需具备硬件冗余能力以应对OTA软件升级，上百个ECU的冗余设计将极大增加成本支出，也导致跨域功能OTA的实现将涉及数量众多的ECU。
随着车载芯片算力的提升和高带宽、低时延车载以太网通讯技术的落地，EE架构已从分布式演进至域集中 (Domain Centralized)，并向整车集中＋区域 (Vehicle Computer & Zonal)、整车集中 (Vehicle Centralized)不断进化。在高集成度的EE架构下，域控制器将承担整车主要逻辑，而执行器、传感器将成为纯粹的执行机构，执行控制命令或是提供环境感知数据。
基于整车集中EE架构的“硬地基”， SOA在域控制器上的部署才能够实现整车能力的资源获取，并将其封装为标准的服务和接口向应用层开放。
1.6 SOA与E/E架构
1.6.1 域控制为核心的架构
电子电气架构的概念从总线引入汽车开始就不断更新和演化，如今一套完整的整车数字架构所考虑的内容除了传统的拓扑、网络、线束与电气分配、逻辑功能分配，还需结合整车的功能/信息安全架构、数据架构、计算架构，以及实现通讯架构与软件架构的协同，功能架构与服务架构的协同，车内服务与云端服务的协同。
如图所示：域集中架构在连接上由功能域控制器，分别通过子网与各功能域内ECU相连接，而域控制器之间则修建通讯“高速公路”，通过高带宽的骨干网络相连。拓扑结构只是架构的表象，而表象背后的核心特征是功能逻辑被抽象上移至功能域控制器中。每个域控制器有对应的集成的（Signal to Services）, 在域控制器中进行功能的分配、功能的集成。而某个域控制器作为云端链接的桥梁，将平行的几个域控制器的逻辑运算功能输入到云端。功能逻辑运算服务的重心在域控制器中。
1.6.2 区域控制为核心的SOA架构
如图所示：整车集中和区域架构在连接上是通过分布在车内各物理区域的区域网关/控制器将车内物理I/O分别就近连接和控制，形成整车数字系统的“手”和“脚”，然后通过骨干网络与系统中的“大脑”控制单元进行连接。连接关系同样只是表象，而核心价值在于将车内软件（运算）和硬件解耦，彻底实现软件独立“生长”（或者说算力架构可以迭代，共享算力变成了可能），而硬件同样可以独立“生长”（跨车型平台，或者在车辆生命周期内为用户提供升级服务，而这些在传统架构中实现的成本是不可控的）。
1.7 以服务为核心的SOA开发思路
虽然电子电气架构开发从理论上是正向开发，但实际上一款车型的开发并不是完全从零开始的，很多功能方案会沿用老款车型。这样的后果是，系统和软件模块已经固定，即无法通过正向设计的思路拆解逻辑，设计服务。考虑这种情况，服务设计可以分为以下两种方法。
(1)自下而上的方法
适用于现有平台上已实现的功能或系统。此种方法的基础是，功能的网络分配，通信，ECU软件架构，功能规范和使用场景等都已经有明确定义。我们可以利用现有的这些输入，完成将原有功能对SOA的转换。
适用功能和系统：
- 车身舒适的大部分功能，如车门，车窗，座椅，空调等，功能逻辑没有太大争议，就可以通过现有子系统规范和网络信号清单，进行服务接口设计。
- 动力和底盘系统。这是整车中对安全要求最高的两个系统，因此一般来说，我们在设计第一代SOA架构时。这两个系统更适合自下而上的方法，通过对已有功能的提取，转换为服务接口，接入整车服务系统。
- 传感器和执行器资源。汽车上的每个元件都代表了一种基础能力。基于整车传感器和执行器清单，能够快速形成一份基础服务清单。由此出发，再通过功能梳理，层层往上，可以形成更加丰富多层次的服务列表。
(2)自上而下的方法
自上而下的方法即为正向设计方法。在基于SOA的电子电气架构开发中，对于复杂功能，或者引入到平台中的新功能和新系统，必须遵循这种方法完成服务设计。基于上述所介绍的开发流程，从需求出发，进行逻辑拆解，服务拆解，软件架构搭建，系统设计等。这个方法所依赖的输入一般是功能需求表和用户场景。
不管使用哪种方法，通常服务的设计是在单个功能或系统级别定义的，最后需要架构师综合考虑整车系统，将高度复用性的服务归类为平台级通用服务。通用服务池子是“生态共创”的基础。
服务的分类：
- 硬件抽象服务根据ECU的功能和硬件外围设备（传感器和执行器），定义硬件抽象服务。这些服务同时属于平台级核心服务。示例：Camera interface，Rain sensor interface
- 平台级核心服务在应用程序集群和域之间通用的所有服务。示例：Power mode，Vehicle speed，Key status
- 域级核心服务在域内的应用程序集群内不同应用程序之间通用的服务。示例：Front vehicle distance calculate，Front obstacles
- 应用服务为每个特定的应用程序或系统功能服务的服务。示例：Enable ACC，AEB system status
服务设计的输入要求：
(1)应用级别的服务
- 功能和系统描述，用户场景描述
- 功能和系统需求
- 功能和系统逻辑架构
(2)平台级别的服务
- 跨域的系统设计文档
- 跨域的功能清单
- 网络拓扑
- 传感器和执行器列表（用于提取硬件抽象服务）
因此，服务设计的输出主要为：
(1)服务的定义
- 服务接口的定义
- 服务提供方和消费方信息
- 软件模块信息
对应的输出文档可以分为：
- 服务定义矩阵
- 服务详细设计文档（包含软件实现信息）
- 服务数据库ARXML（涵盖通讯、服务、软件部署等信息）
1.7.1 AP（Adaptive Platform）的开发
a. 定义服务内容
此步骤实际上就是搭建了一个系统功能架构，从整车层面即是按照功能需求定义并划分服务。对于SOA中的服务表示了一种独立的功能单元，一个服务可以包含其他子服务单元，使用标准接口进行通讯，将内部信息封装成一个黑盒子，实现子服务的重用性。上层服务可以通过该标准接口调用下层服务封装的子服务内容。同时，整体的服务内容可以被操控单元远程访问和独立更改或更新。同时，对于SOA来说，需要通过服务编排来定义清楚服务之间的相互关系。
简单地说服务对于智能驾驶汽车而言就是定义产品，对其中产品的能力进行描述，这里的产品能力我们称之为PC（Product Capability）。实现这种产品能力需要从下至上定义硬件抽象服务、平台核心服务、域核心服务、应用程序服务。而每一个服务内容对应着一个或多个实现的软件模块，这里我们称之为SWC（Software Capability）
产品能力 (PC) 描述了系统所需的一些高级功能。区别于系统设计，PC是用来分配职责的，所以很清楚哪个SWC Module软件模块（如摄像头识别模块、雷达识别模块、中央域控制器模块）应该实现什么。它们在功能设计时由功能负责人识别和请求。一些系统相关的PC也可以由系统架构师或模块负责人直接识别，在模块架构工作中映射PC时，模块所有者还可以确定对更多 PC 的需求。
在确定并决定添加 PC 后，对应的软件模块拥有该 PC，模块所有者负责将其实施到正确的版本，并在平台的整个生命周期内维护/发展 PC。
b. 定义服务接口
服务接口是一种通信内容定义，其目的在于将服务从功能架构过渡到软件技术架构，且软件模块之间的关系需要被清晰的定义出来，过程中将服务内容封装成相应的接口被实际调用。这种接口定义是独立于通信协议的抽象实体，这种接口可以建立任何两个服务间的通信能力，而使用合适的工具链可以由此生成基于特定协议的接口。
服务接口可分为方法（Method）、属性（Property）、事件（Event）三种类型。以智能驾驶的一个子功能执行接口服务为例，假设需要获取摄像头传感器探测的环境数据，而需要进行定义的服务接口中方法是要对传感器的参数进行后融合，那么就需要其底层服务提供摄像头处理的基础函数（如ISP、深度学习函数、BEV函数等）。而服务接口的属性则是通过一定的方法操作（如get/set）来获取该服务函数，这种服务属性可以对上层调用的服务部分可见，底层服务有变动上层的调用方式也会随之变动，这种变动所带来的更新会由服务底层决定何时发送给上层调用它的服务单元。
服务接口定义完整后，开发人员可以根据该接口定义对其中的函数进行定义开发了。
c. 配置服务关系
此过程会建立软硬件之间的映射关系，实现从抽象的服务定义到软件层面的推导，从而方便实现软件驱动或调用硬件实现单元，这种结果是实现服务与中间件或底层硬件ECU之间的映射关系。从整个SOA的架构模型中我们知道服务需要从通用服务平台开始进行底层驱动，然后对上层传感器执行器的控制管理进行驱动。由于AP直接支持服务接口，可以直接面向上层应用层，CP仍然是对常用的底层应用服务的驱动映射，因此，两层驱动分别对应着经典的CP Autosar中间件调用和AP Autosar模式。
d. 通讯协议设计
智能网联汽车的SOA架构设计需要强大的环境感知、信息处理、实施决策、控制能力可以把智能交通、地图、定位、通讯、云、大数据等进行系统集成，故车端与云端、车辆与车辆之间、车辆内部的各个ECU之间通信的速率和数据量都比传统汽车高出几个数量级，这些需要由多种复杂的硬件、软件和高速通信总线共同实现，并在很大程度上决定智能汽车的功能实现和扩展的可靠性。车载以太网能够很好的解决大数据量的信息交互，整个通信协议的定义包括虚拟以太网VLAN，以太网交换机Switch，套接字Socket，基于IP的可扩展面向服务的中间件SOME/IP，SD等。而基于AVB的下一代协议TSN（时间敏感网络）可以提供非常优秀的实时性。
以太网通讯设计过程包含对服务实例进行通讯协议相关的信息配置。由于SOA架构中包含多个应用实体之间的多通路通信过程，且这些通信通常是网状通信，因此需要在各个实体节点之间建立中间路由、转化等。区别于传统总线（Can/Lin），在软件架构设计过程中，开发人员需要设计具体的服务类型、服务ID、服务数据类型、服务角色等。
详细内容见下面链接：
汽车服务架构（SOA）开发设计
https://download.csdn.net/download/ChrisKKC/82048291
【积分下载】软件定义汽车服务API-第一部分：原子服务API参考
https://download.csdn.net/download/ChrisKKC/85089142【积分下载】软件定义汽车服务API-第一部分：原子服务API参考 变更说明https://download.csdn.net/download/ChrisKKC/85089150【积分下载】软件定义汽车服务API-第二部分：设备抽象API参考https://download.csdn.net/download/ChrisKKC/85089177【积分下载】软件定义汽车服务API-第二部分：设备抽象API参考变更说明1、软件定义汽车服务2、SOA架构3、API接口参考4、设备抽象API5、变更说明更多下载资源、学习资料请访问CSDN下载频道.
https://download.csdn.net/download/ChrisKKC/85089158
SOA架构设计经验分享—架构职责数据一致性
阅读目录：
- 1.背景介绍
- 2.SOA的架构层次
- 2.1.应用服务（原子服务）
- 2.2.组合服务
- 2.3.业务服务（编排服务）
- 3.SOA化的重构
- 3.1.保留服务空间，为了将来服务的组合
- 4.运用DDD+GRASP进行分析和设计（防止主观的判断导致错误的假设）
- 5.SOA分布式下的数据一致性
- 5.1.分布式事务（基于DTC的分布式事务）
- 5.2.事务补偿（提供正向或反向的操作来让数据在业务上是一致的）
- 5.3.异步EDA（基于异步事件流来实现柔性的分布式事务）
- 6.总结
1.背景介绍
最近一段时间都在做系统分析和设计工作，面对的业务是典型的重量级企业应用方向。突然发现很多以往觉得很简单的问题变得没有想象的那么容易，最大的问题就是职责如何分配。论系统架构设计的最大的问题，其实也就是职责的分配，分配的合理，实现起来就会很柔性，反之就会使架构很混乱。
软件的生命周期大概可以归纳为四个基本的过程，分析、设计、实现、测试，当然这仅仅是一个最为粗略的表示而已。不同的方法论有着不同的使用这几个过程的方式。RUP使用快速迭代的过程，在这个几个子过程中适当的输出一些过程制品，每次迭代都是进行相同的分析、设计、实现、测试。而在Scrum中，不提倡输出任何文档形式的过程制品，也同样有着上述几个过程，强调以人为中心，通过沟通来解决大部分的问题。
不能用好与不好来判断哪一种方法论，只能根据目前的实际情况综合权衡。RUP的每次迭代中有几个关键的制品对系统分析、设计很重要，可以说是非常重要，如：词汇表、业务规则文档、用例、领域草图。这几个制品对分析、设计很重要，需要从这几个制品中提炼出设计模型最终才能落地。这主要用在业务复杂的应用系统中。而Scrum更加的轻量级，可以用在互联网项目中，业务不是太复杂的情况下。
其实我为什么要强调软件工程及开发方法论，是因为我最近发现，做设计其实是建立在分析的基础上的，但是这里面又有很多问题。大型企业级应用，并不能通过一次性分析就可以得出准确和全部的需求，初期阶段建立的需求70%都是不准确的。所以做架构需要有分析的能力才行且是建立在适当的开发方论上的分析，什么时候该用RUP，什么时候该用Scrum，什么时候该用XP都很有讲究。分析与设计都需要有一个执行上下文，不同的上下文对分析、设计的执行有着不同的要求。
有句话我觉得对架构者来说很有启发：分析就是做正确的事，设计就是正确的做事。架构跟语言跟平台关系不大，毕竟架构是设计过程中的子过程，我想如果你的设计不合理，你用任何语言任何平台都解决不了问题。（这里的架构上下文指：企业应用架构不是基础设施的系统架构）
2.SOA的架构层次
进行SOA类型的架构设计就需要搞清楚SOA架构模型才行。并不能想当然的对系统进行简单的拆分就行，需要搞清楚SOA的架构模型是怎样的，每一块是干什么用的，这样设计由分析阶段输出的需求时才能正确的划分职责。
如果把SOA的架构简单的理解为是多个子系统之间的整合其实有点太过于简单，也没有真正搞清楚SOA的架构模型。按照SOA的正确方法论及目标模型，其实SOA在实现架构落地上，需要考虑到对服务的组合，不断的重用现有的服务，让企业应用可以逐步集成，快速实现业务的迭代。其实这就是本节要讲的服务的分层，通过分层将服务按照使用类型进行分配，上层服务对下层服务的包装，下层服务负责原子性的操作，上层服务对下层服务进行业务性的组合。
我们来看具体的每一层的作用及主要职责。
2.1.应用服务（原子服务）
应用服务就是诸如：订单服务、仓库服务、销售服务、客户管理服务，这些服务直接对应不同的应用系统，直接服务这些应用系统的原子操作。订单服务直接原子性的插入订单，没有任何跨其他服务的分支逻辑。仓库服务只管自己的仓库逻辑。同样其他的应用服务只管好自己的职责，杜绝对其他服务的调用。
图1：
应用服务位于UI与后台之间，后台我们可以认为它是一异构的系统或者是数据库之类的。应用服务的位置位于前端与后端之间，起到类似一个服务API的作用，但是SOA中的服务还远远不止这一个应用服务，如果我们的SOA架构中只有一种类型的服务，那么这会增加我们系统的耦合程度，因为你没有对系统的服务进行层次的划分，你的业务功能会直接的落到某一个应用线上的服务，继续往下看。
2.2.组合服务
组合服务是对应用服务的一个组合,根据实际项目的规模大小,不一定非要进行物理的隔离,在代码层面的服务化也是可以的,在将来的某一天有必要的情况下再进行物理的拆分,毕竟物理的拆分有着严重的成本和代价，对系统的稳定性带来很多挑战。所以经验告诉我们必要的时候在进行拆分。”分布式系统设计的第一个原则就是尽量不要分布式“，这是马丁.福勒大师说的，现在理解确实感同身受。
图2：
组合服务对下层的应用服务进行了组合，完成了一个基本的业务动作，应用服务中是最基本的基础性的原子性的操作。但是在复杂的业务需求下大部分业务功能都需要跨越多个应用线来完成一个最外层的企业动作。提交订单可能需要穿过很多应用线，订单管理、仓库、财务等等环节。所以这里我们还需要一个能在最外层对组合服务进行编排的业务服务。这个编排服务可以完全是自动化的，通过工作流引擎进行组合自动化来完成，这对企业应用的自动化流程很有意义。
2.3.业务服务（编排服务）
业务服务是最外层的服务，向下编排了组合服务。业务服务位于最上层，当需要有跨越多个应用线来完成的业务，这个业务就放入业务服务中。比如提交订单，先检查库存、扣减库存（冻结库存），然后下单，再往后通知财务，再往后通知物流等等都是一个复杂的企业服务线。这种最外层的业务逻辑如果你不进行SOA分层然后将其放入最外层的业务服务中，你把它放入任何一个应用线都会使系统调用混乱不堪。所以问题就是需要进行纵向的划分层次。如果进行了SOA的层次划分后就不会出现互相乱用的情况。其实这里可以参考阿里的服务设计方法。（李智慧写的一本大型互联网架构与实践里面也讲到了服务要划分层次）
图3：
当在业务服务中执行的业务逻辑时，需要跨越多个应用线来完成。这部分的逻辑也说是职责，如果不放入这个位置，放在哪个应用线都不合适，放入哪个应用线都会使系统调用出现混乱。其实这里的问题就是我们不能用一个维度来进行SOA系统的设计，本来服务就具有组合特性，所以适当的提升服务的层次是有好处的，但是应用服务和组合服务可以在代码层面上进行构建，而业务服务也叫编排服务是需要进行物理隔离的，毕竟考虑到系统复杂度和稳定性问题这是值得的。在排查问题，系统性能、稳定性等等方面，物理的隔离有一定的作用，毕竟业务服务本来就是来组合多个应用线的，这样做会使整个系统架构很清晰。
3.SOA化的重构
进行SOA化的实施，大部分情况下都是对现有系统进行重构后考虑的，初期企业发展阶段以快速出原形为首要目标，只有当系统出现瓶颈了才会考虑运用SOA来解决。但是在这个时候有很多历史包袱无法解决，进行SOA化的重构其实成本是很高的，而且很危险，对有些复杂的逻辑说的现实点，是无能为力的。如果都可以通过重构这个技术来解决，那我们就太天真了。《重构—马丁.福勒》一书讲的是代码层面的重构，跟做系统级重构两个概念。对系统级别的重构还没有太多成熟的方法论支撑。尤其现在新技术层出不穷的，各有优点，能很好的运用这些技术、方法论、过程来重构大型企业级系统，难度非常大，这需要整个公司投入很多人力、资源成本。回过头来想想，其实在前期适当考虑一下还是有必要的，这样可以减少后期很多技术债务。
这里我只总结我在分析、设计公司某一块业务系统的时候对其进行SOA化的重构思路。重构本来就是一个不断迭代的过程，不可以跨大步。通过很多脚手架支撑，让系统慢慢的过度到新的SOA架构下，既然要实施SOA架构，那么很重要的一点就是对迁移的业务逻辑适当的归类，什么业务逻辑该放入“业务服务”中，什么逻辑该在代码层面上放入“组合服务”中，对基本的操作有如何放入代码层面的“应用服务”中。
3.1.保留服务空间，为了将来服务的组合
在进行系统拆分的时候，对当前后端的调用都进行适当的规划，将其分为两类，一类是应用服务，一类是组合服务，这两个服务是可以在代码层面上进行抽象。重点是那些调用其他系统的地方，需要将其放入业务服务中，这块逻辑比较复杂，难以抽取，需要适当的结合”数据落地“的思路来综合考虑。有时候把一部分数据落入本地可以提升系统的整体简洁度和稳定性，但是要考虑数据的一个生命周期性质。
在迁移的过程中可能还会有一些新的功能并行开发的，既有新的逻辑需要放入新的SOA服务中，也会有迁移过来的逻辑，这两个过程同时进行其实很痛苦，尽量避免这样同时进行，但是现实是根本不可能，正常都是一起并行推进。如果这两个过程是同一组团队负责其实还好，毕竟对这块的代码、业务都比较了解。
这一节目的是想强调对现在系统进行迁移的时候要考虑服务的层次，不要只进行一个简单的搬移代码，这个时候是一个对代码进行重构的好机会，该划分层次的要划分层次，该读写分离的要读写分离，要重点考虑那些“业务服务”，需要跨越多个应用线的逻辑。
顺便说一下，还有一个重点就是迁移的时候还要考虑数据存储方面的迁移，光代码层面的迁移只是第一步，第二步还需要进行数据层面的迁移。当然这两个大的步骤都是要通过很多次迭代完成，并且还是一个对业务、代码进行很好梳理和整理的好机会。
在将系统进行服务化的时候要考虑服务层，如果当前没有业务服务的逻辑那么就保留服务空间，至少要清楚在服务层中有这么一个空间是要预留的，当有其他的应用线需要与你交互的时候可以顺利的进入到你的服务区，而不是直接到达你的应用。
4.运用DDD+GRASP进行分析和设计（防止主观的判断导致错误的假设）
做系统设计时最怕的就是职责搞错了，这会使系统的架构突然就复杂了，而且系统架构都是很难改变的或者压根就无法改变的决定。所以我对这块引起了重视，有时候你对业务在了解在熟悉依然会搞错职责，对于这块光凭主观的判断是不长远的，无发复制、无法传播的，也无法落字成文的。
对DDD我这里就不多做介绍了，这里要强调是GRASP。运用DDD可以很好的帮助我们来战略性的观察企业所坐立的领域，我还是很提倡DDD在公司实施的，不说DDD中的“战术设计”方法论，就光说它的“战略设计”方法论还是有很大作用的，让我们可以在脑海中建立一个战略性的模型。具体要不要进行代码层面的落地这就看实际情况了。而且DDD中的很多不错的思想都可以借鉴过来，包括领域通用语言，有了领域通用语言团队之间的沟通和交流会节省很多成本。对于新人来说，可以很快的了解公司的一些大概的业务，这和“词汇表”其实还是有区别的。
上面说了，在划分职责的时候很多都是通过经验来主观的判断，没有其他的客观证据了。那么有没有一个不错的方法论或模式来指导我们进行这类问题的解决呢，其实还是有的，因为在国外人家这方面已经很成熟。
GRASP就是这样的一套模式，它可以帮助我们进行客观的设计职责。到底该把这块数据放入哪个应用中，到底该把这个逻辑放入哪个服务中，都有指导，包括对对象层面的设计依然可以。我们可能对“信息专家模式”都有了解，但是以往我们可能都只把它用在对象设计上，而没有提升一个系统层面中考虑。那是因为我们以往可能没有碰见很复杂的职责分配场景，只有当出现问题时我们才能真正领会某个东西的好坏。
DDD只有结合GRASP才能客观准确的方配某个领域的职责，不管是战略设计层面还是战术设计层面，都是一个很好的平衡标准，不会由于技术人员主观的兴趣倾向导致一个错误的职责分配决定，而这个错误的决定最终是要开发人员来买单。
5.SOA分布式下的数据一致性
传统分布式系统与当代的面向SOA的分布式系统有一定区别，论概念上来讲SOA是以服务为中心，既然以服务为中心就会有很多面向服务的设计原则。而传统的分布式系统没有服务的概念，也没有所谓的一切皆是服务的原则。而当代SOA则首要原则就要以服务为中心，针对服务的设计又有了很多服务设计原则。
SOA对服务还进行了类型的划分，按照服务的应用层次来分类：业务服务、组合服务、应用服务，包装服务等。再按照管理与运维的层面来分类：控制服务、调度服务、监控服务等等。传统的分布式系统是没有这些的，我们谈论的是当代SOA的分布式系统，所以我们强调的是以服务为中心，以服务设计原则为架构设计的指导要求，当代SOA是对传统分布式系统的一个迭代进化，不是一个时代的产物，SOA更加强调了以服务为首要原则，已经提升到了另外一个更加高级的层面。
本节我们交流一下在当代SOA分布式系统中的数据一致性问题，在SOA中这主要涉及两个层面来考虑，一个是服务层面、一个数据持久化层面。再按照一致性的基本要求，可以分为：读一致性、写一致性、会话一致性、最终一致性、实时一致性等几个维度，当然还有其他几个维度的一致性要求。
我们这里重点讨论在企业应用中实施SOA时遇到的一些比较棘手的数据一致性问题和解决方案，对于刚才提到的几个维度的一致性要求均具有重要的参考价值。
5.1.分布式事务（基于DTC的分布式事务）
以往包括目前很多项目还是倾向于使用DTC来处理分布式事务，这个方案多数适用于一般的企业应用，业务、访问量、数据量要求都不是很高的情况下。用DTC很方便，事务的自动传播、事务的自动感知、事务的自动回滚和提交，这都是中央DTC帮我们管理好了。
由于有中央DTC的统一协调，看似好像帮我们解决了很多我们需要考虑的问题，但是它也是整个平台的致命的瓶颈，一旦DTC由于某个问题出现错误，而且这种错误都是系统层面的错误，很多问题我们是无能为力的。如果出现问题，整个应用平台都无法完成任何一个跨服务的业务流程，这其实很危险，你不无法控制系统的稳定性。
这里总结，DTC用于一般的小型企业应用，不建议用在中等规模的企业应用中，不是说这个东西不好，而是无法控制它。
5.2.事务补偿（提供正向或反向的操作来让数据在业务上是一致的）
世界级SOA专家所编写的书籍里都提到了使用“补偿”操作来完成数据的不一致性，当我们编写了一个服务方法A，就需要一个服务方法A1的补偿接口来完成A服务的补偿操作。但是真实的业务情况下很难实施这种看起来好像很优美很柔性的设计。没有实践就没有发言权，我们公司的技术团队就实施过这种方案，但是很不理想，这跟技术本身及技术团队没关系，只是我们的平台业务太复杂，很难去“补偿”一个已经做过的操作。
这当然也要看你所面对的项目情况，量变引起质变，如果你的各种量都上去了，这个“补偿”方案不实际，而且很难在数据层面进行“补偿“。总之，这不是一个中长期的方案。
5.3.异步EDA（基于异步事件流来实现柔性的分布式事务）
EDA简称”事件驱动架构“。多个系统之间通过传播”事件“来驱动整个业务的运转。系统之间没有紧耦合的同步调用的操作，都是通过发出异步的“事件”来通知下一个业务环节。
可能你会有一个疑问，异步操作，是不是系统之间延迟会很长，其实不是，现在有很多成熟的消息中间件在内网内几乎是毫秒级别的延迟，至于跨机房就看物理上的距离了。
异步操作有很多好处，这里我就不浪费大家时间重复那些好处。使用EDA实现系统之间的一个松散的事务关系，要把控好项目的质量，对系统的非功能需求、BUG数等等可能会影响业务操作中断的地方都要建立起适当的机制，让这些问题尽早的在线下解决。比如可以实施UnitTest、持续集成等一些敏捷的方法论。
6.总结
同样一个工具在于什么人用，真正的工匠都是使用很朴实的工具来雕刻无法超越的艺术品，这就是工匠情怀。最近对工匠情怀感受越来越深，一直以为自己是一个比较喜欢专的人，这是不是偏离了一个大的方向冲进了一个小胡同，直到最近我才领悟，这其实是”软件工匠“的精神。但是这不代表不考虑全局，这只是一种情怀，一种态度，对于架构也是，对于代码也是，不要认为那些看似无关紧要的问题就忽视它，带着工匠精神雕刻它。
参考书籍：《SOA实践指南》、《SOA概念、技术与设计》、《精益软件》、《UML与模式应用》、《软件预构的艺术》
以上是关于汽车服务架构(SOA)开发设计的主要内容，如果未能解决你的问题，请参考以下文章