Files

T

DongHyeonka d71669eb59 fix: 하네스 제거 및 keycloak 문서 보강

2026-07-25 12:53:13 +09:00

8.2 KiB

Raw Permalink Blame History

title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed

title

source_type

url

archive_url

status

confidence

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 로 취급 금지).

8.2 KiB Raw Permalink Blame History