시스템 구성과 topology — 구조적 연결

Client·Session·Api·Support의 배치와 무방향 구조적 연결 (Location Store는 resource 표에서 설명)

시스템 구성과 topology — 구조적 연결 Client·Session·Api·Support의 배치와 무방향 구조적 연결 (Location Store는 resource 표에서 설명) Customer Client · Clients Customer Client Agent Client · Clients Agent Client Session · client-facing STREAM · Servers Session client-facing STREAM Api · token 검증 · Spot 생성 · Servers Api token 검증 · Spot 생성 Support · Entry·Conversation Spot·actor · Servers Support Entry·Conversation Spot·actor STREAM STREAM supportchat.api RouteMesh supportchat.api Clients Servers

연결 읽는 법

  • • 모든 선은 원문의 `---` 무방향 구조적 연결이다 — 요청 방향이 아니라 peer·ingress 연결 의도만 나타낸다(화살표 머리는 렌더 제약이며 방향 주장이 아니다).
  • • Customer·Agent Client는 각각 STREAM으로 Session에 연결한다. Session만 client-facing STREAM endpoint를 제공한다.
  • • S↔API와 SUP↔API 실선은 supportchat.api ClientServer(API request/reply용 독립 채널). API↔SUP 사이에는 supportchat.api ClientServer와 supportchat RouteMesh 두 연결이 모두 있다 — 그림에서는 한 쌍만 라벨을 달고 두 번째(RouteMesh) 연결은 아래로 우회시켰다. S↔SUP도 supportchat RouteMesh다.

역할과 경계

  • • Session·Api는 object client이고 Support는 object server capability를 제공한다. 두 object client 사이에 별도 peer를 만들지 않는다. Session·Api·Support는 각각 1 이상 인스턴스다.
  • • Support는 SupportEntrySpot, ConversationSpot, customer actor, agent roster actor와 conversation actor를 제공한다. Api는 token 검증과 Conversation Spot 생성 request를 처리한다.
  • • supportchat.api는 API request/reply용 독립 ClientServer다 — object RouteMesh에 channel Server membership을 섞지 않는다. Location Store는 peer discovery·Actor·Spot authority·generation을 관리하고 session binding route는 Session owner가 보관하며, 이 그림이 아니라 resource 표에서 설명한다.