서비스 아키텍처는 서비스가 구성되는 방식과 시스템의 다른 구성요소와 통신하는 방식을 나타냅니다.
서비스 번들 만들기
서비스 번들은 함께 배포할 수 있는 관련 서비스 단위를 그룹화합니다. 서비스 번들에 필요한 유일한 속성은 이름입니다. 패키지 이름과 함께 이름은 서비스 번들의 정규화된 이름을 형성합니다.
서비스 번들은 차량 서비스 인터페이스 정의 언어(VSIDL) 파일 (확장자가 .vsidl인 파일)로 정의됩니다.
다음 예에서는 TirePressureMonitoring 서비스 번들과 BodyControl 서비스 번들 등 두 개의 서비스 번들을 보여줍니다.
package: "com.android.sdv.sample.vsidl"
service_bundle {
name: "TirePressureMonitoring"
}
service_bundle {
name: "BodyControl"
}
각 항목의 의미는 다음과 같습니다.
service_bundle는 구조를 서비스 번들로 식별합니다.name은 서비스 번들의 이름입니다.
메시지 패턴: Pub/Sub 및 RPC
SDV 프레임워크는 게시-구독(Pub/Sub)과 리모트 프러시저 콜 (RPC)이라는 두 가지 기본 메시지 패턴을 사용합니다.
Pub/Sub에서 시스템은 관심 있는 구성요소에 데이터를 스트리밍하여 차량의 진화하는 상태에 반응합니다. 데이터는 주제로 구성됩니다. 게시자는 주제에 메시지를 전송합니다. 게시자는 어떤 (또는 몇 명의) 구독자가 수신 대기 중인지 알지 않아도 주제에 메시지를 전송합니다. 구독자는 어떤 게시자가 메시지를 전송했는지 정확히 알지 않아도 주제에 메시지를 수신합니다.
반면 RPC는 작업과 결과에 맞게 설계되었습니다. 호출자가 특정 결과 또는 작업 확인에 관심이 있어 요청을 시작할 때 사용됩니다. 호출자가 채널에서 특정 메서드를 호출합니다.
이러한 패턴은 서로 다른 운영 요구사항을 충족하지만 공통된 구조적 속성을 공유합니다. 둘 다 발신자의 ID를 수신자로부터 분리하기 위해 명명된 통신 경로(Pub/Sub의 주제, RPC의 채널)를 사용합니다.
게시자 및 구독자 선언
게시-구독은 메시지 전송자(게시자)가 메시지를 특정 수신자(구독자)에게 직접 전송하지 않는 메시지 패턴입니다. 대신 게시자는 메시지를 주제로 분류하고 구독자는 하나 이상의 커뮤니케이션 주제를 구독하여 해당 주제에 게시된 메시지만 수신합니다. 게시-구독에 관한 자세한 내용은 게시-구독 패턴을 참고하세요.
서비스 번들에 게시자 추가
다음 예는 TirePressureMonitoring 서비스 번들에 추가된 게시자를 보여줍니다.
package: "com.android.sdv.sample.vsidl"
service_bundle {
name: "TirePressureMonitoring"
publisher {
message: "TirePressure"
topic: "front-left"
capacity: 10
}
}
service_bundle {
name: "BodyControl"
...
}
각 항목의 의미는 다음과 같습니다.
publisher서비스 메시지는 메시지 큐에 메시지를 게시합니다.message프로토콜 버퍼에 정의된 데이터 구조 또는 메시지 유형 (.protobuf확장자가 있는 파일)입니다.topic게시 주제의 고유 식별자입니다. 소문자 대시 케이스여야 합니다.capacity게시 대기열이 보유할 수 있는 메시지 수입니다. 2 이상의 짝수여야 합니다.
서비스 번들 구독 추가
다음 예는 BodyControl 서비스 번들에 추가된 게시자를 보여줍니다.
package: "com.android.sdv.sample.vsidl"
service_bundle {
name: "TirePressureMonitoring"
publisher {
message: "TirePressure"
topic: "front-left"
capacity: 10
}
}
service_bundle {
name: "BodyControl"
subscriber {
message: "com.android.sdv.sample.vsidl.TirePressure"
topic: "front-left"
}
}
각 항목의 의미는 다음과 같습니다.
subscriber서비스 번들이 주제를 구독합니다.message프로토콜 버퍼에 정의된 데이터 구조 또는 메시지 유형 (.protobuf확장자가 있는 파일)입니다.topic게시 주제의 고유 식별자입니다. 게시자의 주제와 일치해야 하며 소문자 대시 케이스여야 합니다.
RPC 클라이언트 및 서버 정의
리모트 프로시져 콜 (RPC)은 함수 호출의 위치 독립성을 제공합니다. 이 패턴에서 채널은 클라이언트와 제공자가 만나는 명명된 랑데부 지점 역할을 합니다. 특정 서비스 인스턴스 대신 채널을 타겟팅하면 프레임워크가 명령어의 의도를 구현의 실제 위치에서 분리합니다.
다음 예에서는 ClimateControl 서비스 번들을 서버로, BodyControl 서비스 번들을 클라이언트로 지정합니다.
package: "com.sdv.cc"
service_bundle {
name: "ClimateControl"
server {
service: "SetTemperature"
channel: "climate-control"
}
}
service_bundle {
name: "BodyControl"
client {
service: "SetTemperature"
channel: "climate-control"
}
}
각 항목의 의미는 다음과 같습니다.
server는 서비스 번들이 일부 RPC 서비스 (service에 의해SetTemperature로 식별됨)를 제공하는 서버임을 나타냅니다.client은 서비스 번들이SetTemperature서비스를 호출하는 클라이언트임을 나타냅니다.channel은 RPC 채널의 이름입니다. 소문자 대시 케이스여야 하며 서비스별로 고유해야 합니다.
이 예시에서는 BodyControl 서비스 번들이 ClimateControl 서비스 번들에 원격 프로시저 호출을 실행하여 온도를 설정할 수 있습니다.
다음 단계
아키텍처를 정의한 후 미들웨어 코드를 생성합니다.