点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

本文介绍了在基于服务的架构中如何进行SOA服务的设计，指导系统和服务设计人员规范且统一的进行服务设计/变更。主要介绍SOA设计规范，包括服务层级/服务分层的基本原则，服务设计流程等内容。同时还介绍了服务的命名规范，服务接口类型及选取原则、服务的部署原则、仲裁机制和异常处理等内容。

2.1 概念定义

2.1.1  SOA

SOA服务是一种‌面向服务的架构(Service-Oriented Architecture)的设计思想。具体来说，SOA是一种粗粒度、松耦合的服务架构，它将应用程序功能划分为独立的服务，这些服务通过定义明确的接口进行通信，并可以跨不同的平台和技术栈相互协作。

2.1.2 服务

服务是一个独立可执行的软件组件，具有确定的功能范围，通过精确定义的服务接口将服务可实现的功能作为 服务提供给给其他软件组件调用。通过不同的服务组合排序可以实现一个复杂的功能/场景需求。

2.1.3 服务接口

服务接口是定义服务行为、输入输出及通信方式的核心契约，它将业务功能抽象为独立、可复用的单元，实现松散耦合和异构系统互操作。‌服务接口是能够直接对外提供服务的属性和方法，一般一个服务有多个服务接口。

2.1.4 服务端（Server）

服务端是指实现服务的一个软件组件，即该服务的提供端（Provider）。

2.1.5客户端（Client） 

客户端是指调用服务实现一个功能逻辑或者另一个服务的软件实体，即为该服务的消费端（Consumer）。

2.2 服务的分层

服务的层级关系如下图所示：

2.2.1 服务层级定义

应用：通过调用多个组合服务,去实现特定场景下的产品功能,比如实现一种关联了座椅，音响音乐、氛围灯、空调，车窗门锁和遮阳帘等控制的小憩模式；

业务服务层：业务服务是面向具体业务应用的服务，通过调用一个或多个基础服务，负责实现具体的用户需求和业务功能。业务服务的粒度最大，与具体的业务场景和用户需求紧密相关，通通常具有较高的业务复杂性和定制性业务服务通常需要和具体的功能需求进行耦合，根据业务需求选择合适的基础服务进行组合和编排,构建出满足用户需求的服务。

示例: 一键成床服务基于座椅调节基础服务实现一键成床功能。基于多个服务或者其他能力，通过一定的逻辑，组合后形成的一类具有普遍能力的服务接口，该类服务也具备较强的复用性；

基础服务层：基础服务基于平台抽象层的原子能力,提供了对基础能力/原子能力的封装,是对具备相同控制特性的系统能力的抽象。

基础服务基于原子能力,增加了基础服务的状态管理、逻辑判新元、业务仲裁等基础功能逻辑。

基础服务是构建业务服务的重要组件。基础服务具有较高的复用性,能够被多个应用服务调用,基础服务在SOA服务架构层起承上启下的作用，一般具备多场景使用的特点。

示例: 座椅基础服务提供座椅调节接口,该接口被调用后,会根据当前座椅状态或者整车的基础状态,进行判断或者仲裁,确定是否执行操作/如何执行操作。

设备抽象层：设备抽象层提供原子能力，原子能力是SOA架构中最基础能力。原子能力代表了一个不可再分的业务操作,通常只完成单一的、具体的任务，原子能力具有高度的内聚性和独立性,其功能明确、简单,不依赖于其他服务,能够独立执行。

设备抽象层主要对传感器、执行器或传统ECU的能力进行封装,对外提供独立、易用的接口,主要目的是屏蔽不同架构平台下的硬件层或底层ECU的差异,是软硬件层的统一抽象接口。当硬件层或底层ECU发生变化时,对外提供的接口保持不变,有利于实现软硬解耦。

示例：座椅调节的原子能力提供实际控制座椅调节的接口,该接口调用后,无论整车软件状态(VMM/车速等),座椅都会执行调节操作。通常为信号或者直接由信号转换的接口。设备抽象层主要是ECU内部使用，所以不会针对此层定义服务务。

2.2.2 服务分层的基本原则

• 下层服务不能调用上一层的服务;

• 同层级应用服务之间可以相互调用，基础服务之间不建议相互调用；

• 应用层原则上不能直接调用设备抽象(如有需要需要特别说明和审批备案)；

• 基础服务层的API接口应尽可能做到标准化，保证上层业务服务利应用的复用性;

• 设备抽象层的API接口应尽可能够做到标准化，兼容传感执行层的方案多样性,并减少硬件的变更对原子服务产生影响。

• 设备抽象层不做服务化。

2.3 服务的设计方法

服务的设计一般有自上而下（Top-Down）和自下而上（Bottom-Up）两种方法：

2.3.1 自上而下（Top-Down）

自上而下的方法即为正向设计。在基于服务的架构中，多数跨域的复杂功能(如云管端联动的)，新引入的系统功能等在开发过程中，需要按照该方式实现服务设计。其要点如下:

• 从需求出发，进行逻辑拆解，系统及软件架构等正向设计，为了功能实现而设计的服务。

• 服务设计在逻辑架构设计之后，因此该类服务应该在系统设计时同步产生(SRD)。在逻辑设计时FO负责功能需求转化和逻辑架构设计，定义逻辑模块的边界和交面关系，不在进行10部署的时候会产生服务的需求(如数据流usercase的形式)。

• 服务设计人员根据该需求在服务库中检查,如果库中已有服务能够满足则使用该服务，如无则设计新服务。

2.3.2 自下而上（Bottom-Up）

适用于平台架构设计中继承的已有系统，或者功能的部署已有明确的结论。在这种情况下,我们可以按照现有的域ECU,子系统的能力，抽象出一部分服务。主要可以从以下几方面进行:

• 传统的且相对独立的系统,如车窗,座椅,空调等,可有对应的ECU提供接口能力,并由对应的域控制器透出服务;

• 动力和底盘域涉及安全性较高，一般较少设计控制类接口,可以从当前提供的CAN,LIN能力进行梳理,对状态类信号进行代理,适用于自下而上；

• 硬件抽象，传感器执行器等独立硬件能力的模块，一般接口较为简单固定,可以自下而上实现服务接口的抽象；

• 独立的算法模块也和硬件模块一样进行抽象，如疲劳检测模块输出疲劳等级,导航模块输出道路信息等。

因此，在架构设计的前期可以先采用自下而上的方式抽象出基础服务,后面根据功能的需求自上而下的对服务库进行补充。

在SOA架构的开发过程中，一般采用先自下而上抽取原子服务然后再自上而下根据业务关系组合服务的流程。服务开发的一般流程如下：

流程中相关角色定义：

• 产品经理(PO：服务定义和验收车辆功能产品形态,输出产品定义文档及Usecase;

• 功能Owner(FO)：负责承接具体的Usecase需求,制定实现方案案，分解至系统并完成握手,输出功能需求文档；

• SOA架构师：定义设计原则，设计规范，服务的接口，对SOA的实现方案提出建议并进行审核。

• 系统Owner(SO)：负责承接本系统的功能需求和服务需求,，设计软件需求,输出软件需求文档;

服务输出物：

• ARXML文件T包含服务的接口设计，传参设计，通信相关参数等内容；

• 服务需求（SWRS)。

在服务的开发维护过程中，要建立【服务的变更管理流程】和【服务设计偏离管理流程】，保证所有变更受控且关联方也同步体现。

4.1 服务的内容

4.1.1 服务内容的设计

• 服务名称设计:Service Name按照下文服务接口的命名规则，定义服务的名称,名称体现该服务的关键能力；

• 服务接口设计:按照下文接口设计原则，通过不同的Service interface定义出服务的提供方和消费方之间的数据交换方式；

• 参数设计:按照下文服务参数设计原则，通过不同的DataElement定义，满足不同接口的数据传输需求;

• 服务的用例设计:按照下文用例设计基本原则，提取出该服务的基本能力边界和交互颗粒度,形成Service Usecase图；

• 服务的接口时序:通过UML接口时序图定义接口之间的时序关系；

• 服务的Qos设计：服务的可靠性措施，如失败Retry机制等;

• 服务的发布和停止策略设计：定义这个服务何种状态下可以提供,如默认上电就提供或者定义其他条件下提供；

• 服务的失效处理策略设计:如对R-R method机制中response的超时机制等,详见下文服务失效处理策略。

4.1.2 服务通信参数设计

• 服务ID,接口ID,事件组ID等服务自身的参数设计；

• 网络通信相关参数定义，VLAN,IP/PORT等；

• 传输层协议的选择：默认选择UDP。Payload总长度超过1400字节时默认选择TCP，传输payload超过4KB不建议使用SOME/IP;

4.1.3 服务的部署设计

在进行系统设计阶段，每个服务应该部署在一个SC(Service Component)上进行逻辑实现，然后跟随SC一起部署在对应的Machine上并进行软件实现。

4.1.4 服务实现设计

一个服务一般会包含两类接口：一类是控制接口，一类是状态接口,控制接口用于控制底层或非域控件,状态接口是执行的反馈或ECU的信息上报。

4.2 服务的应用原则

不建议使用服务的场景：

• 功能的整体链路有功能安全的要求（比如动力底盘的功能需求)；

• 功能对传输时效性要求高，如从服务端到执行端的传输延迟需要较低；

• 整车唤醒后需要快速(车辆唤醒4s内)完成执行的功能,例如远程解锁;

• 功能需要在<20ms周期性执行task(非触发类型)如:接收数据不管变化与否都需要周期或数据运算;

可以使用服务的场景：

• 功能对传输时效性要求不高，如从服务端到执行端的传输延迟允许≥100ms(不考虑软件task周期和信号周期)；

• 部署在SOC内的功能,除了上述不建议使用服务的场景外，优先使用服务，提高复用性。

4.3 服务的抽取的优先级原则

复用性较强的资源，即同一个资源可能被多处使用，优先考虑使用服务。

• 独立的能力单元(硬件，算法等）优先封装成服务；

• 资源类型相同，有多处提供(如摄像头,门锁等),可以优先做成服务通过多实例化的方式,多处部署;对于同一个控制器部署的，建议采用动态数组的方式；

• 车云一体化架构中，由于云端接restful,Http等也是基于服务的，建议部分跨车云的信息传递优先使用服务，如Fota,账号管理等；

• 如果使用SOME/IP通信，服务接口应以状态和控制接口为主,大的数据(音视频,大文件等)访问地址可以使用服务传输，但大数据本身传输不能使用服务。

4.4 服务颗粒度划分原则

服务颗粒度划分应该遵循以下三个原则:

• 服务的颗粒度应该整体考虑服务的重用性,灵活性和性能这几个维度；

• 基础服务重点在于考虑其重用性,通常体现子系统的基本能力，根据子系统内相近的功能抽象出一个或多个服务；

• 组合服务是不同的基础服务与业务的结合,应该以业务自治为划分原则，提供相应颗粒度的服务;

4.5 服务接口定义原

4.5.1 服务接口类型

SOA（面向服务架构）中的三种核心接口形式（Method、Event、Field）是服务间通信的基础，它们各自承担不同的角色。

• Method 分为RR(Request-Response)和FF(Fire-Forget)两种。

RR Method:客户端按需请求(Request)调用服务，服务端通过过响应(Response)的方式进行回复，,验证通过后执行客户端的请求。

FF Method:客户端按需请求(Request)调用服务，服务端不回复，,验证通过后执行客户端的请求。

• Event: 表示事件，服务端主动通知给客户端，通常具备时效性，不同的事件可以组成事件组，通过订阅/通知完成事件通知。

• Field(Setter/Getter/Notifier)

4.5.2 接口类型的选取原则

4.5.2.1 控制类接口设计

控制类接口通常选择RR-Method类接口进行传输。一般有同步和异步两种形式:

• 同步交互：指发送一个请求需要等待返回，然后才能够发送下一个个请求；通过Method的返回值直接返回参数。

• 异步交互:指发送一个请求，不需要等待返回，随时可以再发送下一个请求，即不需要等待。异步交互的服务提供方可以延迟给调用方提供最终的结果数据,在此期间调用方可以择放占用的线程等资源,避免阻塞,等到结果产生在重新获取线程处理。

• 异步接口可以使用RR+Event/Field的方式，即先通过Response初步判断，待服务端执行完成时，通过Event/Field返回最终结果数据。

• 同步/异步使用建议:同步交互会阻塞当前接口操作，因此一般建议用于非耗时类操作(如获取本地的状态),对于耗时类操作或大运算量操作(如关窗，座椅移到某个位置),如果不能阻塞其他业务操作，则需要使用异步交互。

• 一般不建议选取FF类型的接口。

• Field-Setter用于设置服务端的一种属性，和RR-Method的重要区别是:

RR Method入参可以为多个，Setter入参只能有一个（如果要传入多个，就要设计成一个结构体参数）；

RR Method返回值可以表示服务端执行状态或执行结果，但Setter的返回值和入参一样，仅用于填充SOMEIPpayload,无实际意义，无法通过返回值判断执行状态。

建议： RR Method的使用场景可以覆盖Field-Setter的，控制类的都设计成Method的形式。

4.5.2.2 状态类接口设计

状态类接口可以按需使用Field（Getter/Notifier)和Event两种形式的接口。其特点分别如下:

• Getter接口是用于客户端主动获取服务端的信息。通常用于特定场景时需要客户端主动去获取状态（比如客户端刚启动需要获取下状态做下同步）。可以视为RR Method的一种形式，但不需要入参；

• Notifier接口是服务端主动通知信息,当客户端订阅后即可收到最新状态,具备初始值,例如车速；

• Event接口也是服务端主动通知信息，和Notifier区别是:Even通常表示某一个时刻发生的事件，类似于一个trigger,一般具有时效性,无初始值;

• 对于需要Provider周期型反馈或者事件型播报的、选用Event接口；

• 对于需要Consumer主动获取的状态,则使用Method接口；

• 状态类的接口需要同时支持以上两种能力。

4.5.2.3 Field的使用

为了简化接Some/IP中定义了Field类型的接口，可用于表示具有多重功能的接口类型。

• Field Setter功能等效于RR Method中用于控制类的接口的作用,主要区别在于携带参数的形式不同,field仅能携带一个参数；步接口不适用Field Setter，应使用 Method;

• Field Getter功能等效于RR Method中用于状态类的接口的作用,主要区别在于携带参数的形式不同，field仅能携带一个参数；

• Field Notifier功能等效于Event接口的作用,主要区别在于是否需要设置初始值;

4.5.2.4 EventGroup的组合原则

为了有针对性的使用资源，在一个服务中的若干个Event/Field-Notifier接口中，应该按照功能用途分为若千个EventGroup,EventGroup设计原则如下：

• 服务存在Event或Notify时,需对每个Event味和Notify定义一个EventGroup,通常建议一个服务内功能相似(如位置/移动状态，电池电压/温度)的接口放到一个EventGroupo;

• 通常不建议低频发送接口和高频发送接口(比如连续量，间隔100ms内)放在同一个EventGroup,一般建议拆分,高频数据单独放入一个EventGroup,除非有以下不可拆分的场景；

• 来自同一个信号组；

• 值+有效性(如坐标点+Valid/qf)；

• 其他情况单独分析;

大数据量事件发送的服务接口(如超过1400字节，只能TCP发送),需要单独的EventGroup。

服务接口特性和选取原则概要总结：

4.5.2.5 Instance的使用原则

在整车系统中往往存在不同的资源同时提供一种能力，如相同型号的多个摄像头，多个玻璃升降器等，这样在服务化的时候，为了通用性和节省开发资源，会考虑同一个服务通过多实例化的形式部署多处的情况。

• 实例的ID只跟部署的位置绑定,不受其他因素的影响；

• 相同服务的实例通过实例ID进行区分，多个实例可以部署在同一个ECU上，也可以部署在多个ECU上；

• 部署多个服务实例的ECU应该侦听每个服务实例的不同端口（因为instanceID并没有体现在Some/IP Header中，可以通过服务ID+Socket (IP,TP type,port)的组合来进行区分)；

• 如果服务部署在多核MPU或者多操作系统上，应该按照虚拟的主机进行分配，按照多个ECU考虑。

4.6 接口传输参数的原则

4.6.1基本参数类型

在服务中常见的几种基础数据类型如下:

>Uint/Int

整形考虑范围是否满足需求即可，使用较为简单且普遍，在以太网中无需像CAN信号一样定义精度和偏差值;在考虑扩展性的前提下，尽可能使用较小的数据类型,如Uint8/Int8。

>Float

如果要描述非整型的物理量，如温度，长度等值，可以使用浮点型。主要需要考虑到数据的范围，长度是否足够；直接传输物理值，不需要像CAN信号一样进行转换。

>String

如果需要描述一段文字，数字或者Json格式的文件，一般使用String。因C++中是支持动态长度字符串的定义的，因此无论是否固定长度，默认为可变长度的字符串。

>Structure

结构体是常见的数据类型设计方法,可以将所有的数据类型都自由组合在一个结构体内。这种方式可以解决部分服务接口类型仅支持一个传参的问题。

>Array

当需要表示多个同一类型的数据元素时,可以采用数组的形式,认该数据元素只要是类型完全相同即可,也可以是一组结构体。如果长度固定则可以使用Fix Length Array，如果长度不固定则使用Dynamic Array,Dynamic Array需要定义数组上限，尽可能保证在限制在1400字节内。

>Union

变形体主要用来表示某些情况下想要用一个数据根据场景不同表示不同的涵义。这种数据类型使用场景很小，且在应用层实现上较为繁琐，因此不建议使用。

4.6.2 数据类型选取原则

• 服务接口在携带应用数据类型时，需要考虑接口的特性。AUTOSAR中规定，除Method外,Event和Field均只能携带一个参数,如果需要多个传参，可以设计成Struct/Array的形式；

• 不使用布尔值,使用Uint8替代易于扩展;

• 建议RR Method接口带返回值,通用的返回参数(IdtRetumnCode)如下，如果业务有其他需求(通用返回值无法满足要求)，则需要创建特定的数据类型；

• 枚举定义时，一般建议异常值Error或者Unknown状态定义成最大值或边界值，例如对于Uint8的参数类型,其异常值应从255开始往下设置，即有2种异常值时，取255和254;

• 常用的参数类型应该统一，如时间戳应该定义为Uint64；经纬度坐标的参数类型应定义为Float等；

• 对于定长的数组FixArray类型，应该定义具体的长度；对于动态数组类型DynamicArray,需定义其长度上限；

• 对于列表类的参数，其长度往往会变化，考虑选用动态数组.

4.7 服务接口命名规则

SOA服务设计时，需要遵循如下命名规范：

• 单词尽量采用全称，便于理解，特定的术语属于除外，如ADAS。如果要缩写;

• 名称不包含特殊字符”,””.””/””\””~”等,可以使用”_”做分割(仅EventGroup)

• 考虑服务在不同平台复用性,各类命名中尽量不要带有EEEA拓扑节点ECU信息；

• 服务名称不能重复,同一个服务内的接口名称不能重复,不同服务的接口名称允许重复;

• 命名中不能使用如下系统关键字以及C++关键字。

4.7.1 服务名称 Service Name

服务实例即指代其定义的服务实现。后文若单独出现”服务”,均指服务实例。

• 服务名采用驼峰模式，首字母大写，全英文名称；

• 服务名不能有下划线;

• 服务名后缀需要以Srv结尾; eg. WiperSrv

4.7.2  服务接口名称 Service Interface Name

SOA平台上服务之间通信接口有Event,Method和Field三种形式式,ServiceInterface用于定义Event/Method/Field消息类型和具体的命名空间,与具体的通信办议无关。

• 服务接口名采用单词首字母大写(驼峰模式),全英文名称，动名词结构，尽量限制在5个单词内，总长度小于45个字符;

• 服务接口名不能有下划线;

• Event接口，表示实际传输的数据,以数据为操作对象，只要能够清晰的表达数据的含义即可,命名规范遵循基础规范；如果Event与Method相对应,Event表示Method的异步调用反馈，名称应该统一。

• Method接口，需要以一个操作/动作,作为接口的名称,必须为动词，禁止以服务的对象作为接口的名称,禁止以服务的名称作为接口的定语，且在用词上原子服务和其他层级服务需要做区分，因为原子服务直接是执行指令，使用Cmd后缀，其他层级服务提供的控制接口包含仲裁等其他处理逻辑，即有可能导致当前指令不会直接执行，所以使用Req后缀，代表请求。

基础服务和组合服务的Method类型接口的命名：

• 如果Method请求操作的对象,是服务主体对象，则以“指令动作+Req”的形式进行命名；

• 如果Method请求操作的对象，是服务主体对象的子类，则以人“指令对象+指令操作对象+Req”的形式进行命名

eg:如果将座椅通风控制封装在座椅控制的服务中，服务命名为SeatSrv,，控制接口则命名为OpenCloseVentReq;若将座椅通风加热控制单独封装服务，服务命名为SeatVentsrv，控制接口则命名为OpenCloseReq.

• Field接口， 当提供的信息为单个或多个相同数据状态的状态量时，以“信息名+Sts“或者若信息名称足以完整表示时,也可直接用信息名称的形式进行命名。

• 建议故障和执行反馈和功能状态类型的Field加Sts后缀,示例:GearSts(车辆挡位状态》;

• 建议数值类的Field,直接用数值代表的信息名称来命名，示例:HHvBattT(高压电池温度);HVBattCelUs(高压电池电芯电压值数组)；

• 特殊Case:车窗ID+车窗位置,属于数值类,直接用信息名称复数来命名即可。

• 当提供的信息为多个不同信息的组合时,以“信息名称+info”、或以“信息息名称”本身的形式进行命名,示例:DCDCSrv的HVSideInfo(12VDCDC服务的高压侧信息接口，包括高压侧实时电流，实时电压); HVBatteryChrgnSrv的ChrgnLimit(高压电服务的充电限制制参数，包括高压电池限制电流，高压电池限制电压，电芯最大限制电压）。

• 事件组接口EventGroup， 为了清晰的表达该事件组所要表达的含义，EventGroup应该按照该事件组的功能特性命名，以EG_为前缀。如EG_Wiper。

4.8 服务的部署原则

服务的部署主要指的是服务在应用层SWC上的实现，服务部署与应用层软件架构密切相关，因此需要服务设计人员和对应控制器的软件架构设计人员共同完成。以下仅做一般性要求:

• 一般情况下，服务应该部署在在AdaptiveAUTOSAR等松耦合的系统中，不同的服务根据其Provider和consumer的定义，部署到对应的APP中，以实现应用层之间的解耦；

• 原子服务也可以部署在Classic AUTOSAR等应用层强耦合的系统中，可以选取专用SWC集中处理服务的提供和消费,可以依赖Sender-Receiver Port的形式来实现；

• 若同一服务部署到不同的硬件或APP中实现,需要使用instance进行区分。

4.9 服务仲裁机制

通用的服务的优先级控制应该由中间件中的对应模块来完成,在协议栈中未实现优先级控制,或者业务的特殊需求,也可以使用应用处理的方式来进行，方案如下：

仲裁的基本原则:

• 仲裁由服务的提供端来进行；

• 只有部分服务的控制类接口需要做仲裁处理(持续性动作或者动作需要保持的)

• 仲裁以被控对象的一类属性为单位。

仲栽的实现方式(供参考):

方式一：等级划分

• 服务端将服务接口能力按照需求业务的重要性分成若干等级(如安全类,舒适类，娱乐类等，每一类中还可以设置若干小类),可以设定等级PriorityID越小,优先级越高；

• 同一优先级的不同消费方，后来者优先，打断前者；

• 高优先级打断低优先级,低优先级等待高优先级,并回传状态；

• 优先级的等级ID可以由优先级等级表中获取，由消费端传入给到提供端；

• 优先级等级表由对应的子系统维护。

方式二: 资源占用与释放

• 如果要显示的请求占用资源和释放资源，可传入参数OccupyFlag=1(true)，表示对资源进行占用;OccupyFlag=0(false)，表示释放该资源；

• 有OccupyFlag或者“动作持续执行期间“均视为有占用，占用期可可以考虑使用PriorityID,无占用不需要考虑PriorityID;

4.10服务的异常处理

消费端

• 比如R-Rmethod类型的接口,当Req信息发出后，一段时间内(如无业务特殊需求，,默认为2S)未收到Resp反馈，则定义为通信超时，消费端应该启动下一步时序(重发或者报错)。单次上电循环内连续N次(业务诊断策略定义)出现该现象,记录超时故障;

• 对于Event接口,若为周期型发送,可按照CAN信号类似进行通信言丢失判断,即连续N个周期未收到该Event报文，记录通信丢失的故障;

• 消费端感知到服务不可用或通信异常时,需要考虑一定的处理机制,常见的处理机制供参考:

维持当前状态；

记录异常场景的日志;

异常提醒或功能降级;

功能完全退出。

服务端

Server无法直接根据服务通信的相关信息进行服务异常的诊断,应该在服务实现的关键点上进行埋点记录。具体方案应该由具体服务的业务链路和服务端软件日志方案决定。

服务设计验收包括服务架构原则，服务接口定义原则和服务需求定义原则。另外，软件接收SOA服务的标准作为服务设计验收标准的子项，会形成单独的软件接收checklist。

在SOA工程师和系统工程师完成服务接口和服务需求设计后进行设计评审时，需根据具体版本的Checklist进行服务设计评审，checklist中需注明被check的对象名称、版本信息、作者、日期、适用的checklist版本，同时记录的comments也需包含在checklist中。

同时在设计评审过程中，出现设计偏离或者软件的实现偏离，据需要按照【服务设计偏离管理流程】进行评审，记录备案以便追溯可查。

同样,对于服务需求变更及软件接收标准变更，均需在相应的系统CCB和软件CCB通过的情况下，流转其它两方进行Review和分析，最终由架构师审批通过。在服务的开发维护过程中，要建立【服务的变更管理流程】，保证所有变更受控且关联方也同步体现。

Checklist的内容和流程根据各个公司的实际情况和实际开发过程中总结复盘，动态更新。

服务接口实例1（基础服务层：雨刮洗涤服务）

服务接口实例2（业务服务层：一键成床服务）

前排一键成床场服务定义：

前排一键成床应用场景的服务组合：

来源：快乐的宸姐昕妹