105 lines
8.2 KiB
Markdown
105 lines
8.2 KiB
Markdown
---
|
|
title: spring-petclinic/spring-petclinic-microservices — Spring Cloud microservices reference sample
|
|
source_type: official-doc
|
|
url: https://github.com/spring-petclinic/spring-petclinic-microservices
|
|
archive_url:
|
|
status: raw
|
|
confidence: high
|
|
tags: [ca-tmpl, sample-fixture, microservices, spring-cloud, petclinic-variant, official-doc]
|
|
related_projects: [ca-skeleton-operational-contract]
|
|
related_branches: [feature-sample-domain-contract-fixture]
|
|
created: 2026-05-22
|
|
last_reviewed: 2026-05-27
|
|
---
|
|
|
|
# spring-petclinic-microservices
|
|
|
|
> Layer: `raw/official-docs/` — spring-petclinic org 의 microservices variant README verbatim 발췌. ca-tmpl sample-ticket 결정의 대안 3 (microservices reference variant) 비교 근거.
|
|
|
|
## Parent / 활용 branch (필수)
|
|
|
|
| Branch | 이 자료가 정당화하는 결정 |
|
|
|---|---|
|
|
| [[raw/branch-notes/feature-sample-domain-contract-fixture]] | sample fixture 를 modular monolith 가 아닌 microservices 로 가져갈 때의 거리감 — Spring Cloud Gateway/Config/Eureka/Tracing 같은 distributed 인프라가 fixture 의 일부가 된다는 영향 식별 |
|
|
|
|
## 컨텍스트
|
|
|
|
ca-tmpl sample-ticket 결정에 대한 대안 3. petclinic 도메인을 microservices(Eureka discovery, Config server, API gateway, distributed tracing)로 분해한 reference. ca-tmpl이 modular monolith 기준임을 고려할 때 "sample fixture를 microservices로 가져가는 길은 어떻게 다른가" 비교점.
|
|
|
|
## 출처 / Source
|
|
|
|
- 원본 URL: https://github.com/spring-petclinic/spring-petclinic-microservices
|
|
- 아카이브 URL: (미수집)
|
|
- 저자/조직: spring-petclinic org (Spring 커뮤니티 variant)
|
|
- Star 수: 4,000+
|
|
- 라이선스: Apache-2.0
|
|
- 마지막 확인일: 2026-05-27
|
|
|
|
## 핵심 인용 / Key quotes (verbatim)
|
|
|
|
> [§README — purpose] "This microservices branch was initially derived from [AngularJS version] to demonstrate how to split sample Spring application into [microservices]."
|
|
|
|
> [§README — Spring Cloud stack] "we use Spring Cloud Gateway, Spring Cloud Circuit Breaker, Spring Cloud Config, Micrometer Tracing, Resilience4j, Open Telemetry and the Eureka Service Discovery from the [Spring Cloud Netflix] technology stack."
|
|
|
|
> [§README — tracing] "Tracing Server (Zipkin) - [http://localhost:9411/zipkin/] (we use [openzipkin]"
|
|
|
|
> [§README — service list] "This project consists of several microservices: **Customers Service**: Manages customer data. **Vets Service**: Handles information about veterinarians. **Visits Service**: Manages pet visit records. **GenAI Service**: Provides a chatbot interface to the application."
|
|
|
|
## Claims Extracted / 추출된 주장
|
|
|
|
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|
|
|---|---|---|---|---|---|
|
|
| SMP-PCM-C1 | spring-petclinic-microservices 는 기존 petclinic Spring 앱을 microservices 로 어떻게 분할하는지 시연할 목적으로 derived 된 변형이다 | [§README — purpose] "This microservices branch was initially derived from [AngularJS version] to demonstrate how to split sample Spring application into [microservices]." | `engineering-blog` | Spring Boot → microservices 분할 학습 reference 평가 | "이 분할 방식이 production 의 best practice" 라는 뜻은 아님 — 어디까지나 demo |
|
|
| SMP-PCM-C2 | 본 프로젝트는 Spring Cloud Gateway, Spring Cloud Circuit Breaker, Spring Cloud Config, Micrometer Tracing, Resilience4j, Open Telemetry, Eureka Service Discovery (Spring Cloud Netflix) 를 사용한다 | [§README — Spring Cloud stack] "we use Spring Cloud Gateway, Spring Cloud Circuit Breaker, Spring Cloud Config, Micrometer Tracing, Resilience4j, Open Telemetry and the Eureka Service Discovery from the [Spring Cloud Netflix] technology stack." | `engineering-blog` | 본 reference 가 채택한 Spring Cloud 컴포넌트 목록 확인 | 이 조합이 모든 Spring microservices 프로젝트에 권장된다는 뜻은 아님 — 본 reference 의 선택일 뿐 |
|
|
| SMP-PCM-C3 | distributed tracing 은 Zipkin (openzipkin) 으로 수집되며, Tracing Server 는 `localhost:9411/zipkin/` 에서 노출된다 | [§README — tracing] "Tracing Server (Zipkin) - [http://localhost:9411/zipkin/] (we use [openzipkin]" | `engineering-blog` | 본 reference 의 tracing UI 위치 확인 | Zipkin 이 모든 환경에서 권장 tracer 라는 뜻은 아님 — Tempo/Jaeger 등 대안 존재 |
|
|
| SMP-PCM-C4 | 본 프로젝트의 서비스 구성: Customers Service (고객 데이터), Vets Service (수의사 정보), Visits Service (방문 기록), GenAI Service (챗봇 인터페이스) | [§README — service list] "This project consists of several microservices: **Customers Service**: Manages customer data. **Vets Service**: Handles information about veterinarians. **Visits Service**: Manages pet visit records. **GenAI Service**: Provides a chatbot interface to the application." | `engineering-blog` | 서비스 경계 결정 학습 reference | 본 분할이 "정답" 이라는 뜻은 아님 — 도메인 경계는 비즈니스 의존 |
|
|
|
|
### Strength 허용값 사용
|
|
|
|
- `engineering-blog` — spring-petclinic org 는 Spring 커뮤니티 maintained 이나 단일 벤더의 공식 product documentation 이 아니며, "공식 best practice" 로 취급 금지. ca-tmpl 운영 규칙 §5 의 `company-tech-blog` 와 유사한 제약 적용
|
|
|
|
## Usage Boundaries / 적용 경계
|
|
|
|
- **이 자료가 직접 증명하는 것**:
|
|
- `SMP-PCM-C1`: 본 reference 의 derivation/목적 (split demonstration)
|
|
- `SMP-PCM-C2`: 채택된 Spring Cloud 컴포넌트 목록
|
|
- `SMP-PCM-C3`: Zipkin 기반 tracing 구성과 UI 포트
|
|
- `SMP-PCM-C4`: 서비스 분할 구성 (4개 서비스)
|
|
- **이 자료가 증명하지 않는 것**:
|
|
- 이 분할 방식이 production microservices best practice 라는 권위 (Spring 공식 vendor doc 아님)
|
|
- ca-tmpl 의 "state machine / optimistic lock / idempotency" 12-scenario matrix 에 해당하는 검증이 본 reference 에 존재 — README 에는 명시 없음
|
|
- Spring Cloud Netflix 의 모든 컴포넌트 (Eureka 등) 가 active maintenance 상태인지의 최신 정보 (Netflix OSS 정책 변화 별도 확인)
|
|
- GenAI Service 가 reference architecture 의 필수 부분인지 (최근 추가된 demo 일 가능성)
|
|
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
|
|
- ca-tmpl 의 modular monolith 가정과 본 reference 의 distributed 가정의 차이가 fixture 채택 비용에 어떻게 영향하는지
|
|
- 본 reference 의 commit history 와 maintenance 활성도
|
|
- 본 reference 가 contract test (Pact 등) 를 포함하는지
|
|
|
|
## 메모 / Notes (내 프로젝트 해석)
|
|
|
|
> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.
|
|
|
|
- 구성 서비스: customers-service / vets-service / visits-service / api-gateway / config-server / discovery-server / admin-server / tracing-server.
|
|
- ca-tmpl과의 거리: ca-tmpl은 modular monolith를 기본 가정 → microservices sample은 sample fixture라기보다 별도 architecture 결정. fixture로 채택 시 skeleton 자체가 distributed 인프라를 요구함.
|
|
- 상태 머신/optimistic lock/idempotency 없음. fixture로 차용해도 ca-tmpl이 명시한 12-scenario matrix(state machine, idempotent create, sample removal smoke) 검증 어려움.
|
|
- 장점: distributed tracing, gateway, config server 같은 cross-cutting concern을 sample 안에서 다룸.
|
|
- 단점: skeleton 검증 fixture 수준을 한참 초과. ca-tmpl의 "sample = contract fixture, not feature" 원칙과 충돌.
|
|
- 신뢰도: spring-petclinic org variant. official-doc 분류로 frontmatter 정리되어 있으나 strength = `engineering-blog` 로 표시 (공식 best practice 로 취급 금지).
|
|
|
|
## 관련 ca-tmpl branch / contract
|
|
|
|
- 적용 branch-note:
|
|
- [[raw/branch-notes/feature-sample-domain-contract-fixture]]
|
|
- canonical contract 섹션:
|
|
- [[raw/project-notes/ca-skeleton-operational-contract#17. Sample Domain Fixture]]
|
|
- 대안 그룹: **Group G — Sample domain contract fixture**
|
|
- 본 source의 위치: 대안 3 — microservices reference variant
|
|
|
|
## Related / 관련
|
|
|
|
- 같은 주제 다른 official-doc:
|
|
- [[raw/official-docs/sample-realworld-gothinkster-github]] (대안 2 — cross-stack spec sample)
|
|
- 인용하는 branch:
|
|
- [[raw/branch-notes/feature-sample-domain-contract-fixture]]
|
|
- 인용하는 wiki: (미작성)
|