소개: MCP 서버가 통신하는 방법
함께하는 생태계에서 MCP 서버 22대 활성화되면 서버 간의 협업이 필수적이 됩니다. 단일 서버는 특정 도메인(스크럼, 시간 추적, CI/CD)을 관리하지만 워크플로는 실제 여러 도메인 간: 스프린트가 종료되면 측정항목이 업데이트되어야 하며 비용은 계산해야 하며 회고가 자동으로 생성되어야 합니다.
Tech-MCP 구현하다 서버 간 통신을 위한 두 가지 보완 메커니즘:이벤트버스 (게시판/구독 비동기식 실행 후 잊어버리기) 및 클라이언트매니저 (동기 RPC 호출이라고 함) 함께, 직접 결합 없이 전체 제품군을 통과하는 엔드투엔드 흐름을 구축할 수 있습니다. 서버 간.
이 기사에서 배울 내용
- MCP Suite의 EventBus 아키텍처 및 게시/구독 패턴
- 11개 도메인으로 구성된 29개의 유형 이벤트
- 협업 매트릭스: 누가 게시하고 누가 구독하는지
- 서버 간 동기 RPC 호출을 위한 ClientManager
- 서버 분류: 양방향, 게시자 전용, 구독자 전용, 통과
- 엔드투엔드 흐름: 스프린트 수명주기, 시간 및 비용, DevOps, 품질
- 와일드카드 구독을 위한 마이크로매치를 사용한 패턴 일치
EventBus: 비동기식 협업의 핵심
L'이벤트버스 MCP Suite 서버가 원활하게 협업할 수 있도록 하는 메커니즘 비동기식 및 분리형. 서버가 중요한 작업(스프린트 생성, 로그 시간, 빌드 완료), 다른 서버가 구독할 수 있는 입력된 이벤트를 게시합니다. 자동으로 반응하도록 합니다.
Server A EventBus Server B
| | |
|-- publish(evento) ------->| |
| |-- handler(payload) ------>|
| | |
| (fire-and-forget) | (delivery garantita |
| | in-process) |
이 패턴은 다음과 같이 알려져 있습니다. 게시/구독 근본적인 이점을 제공합니다.
- 디커플링: 게시자는 구독자를 모릅니다.
- 확장성: 새 구독자를 추가해도 게시자를 변경할 필요가 없습니다.
- 선택성: EventBus는 항상 선택 사항입니다. 모든 서버는 서버 없이도 완벽하게 작동합니다.
이벤트버스 인터페이스
인터페이스 EventBus 모든 이벤트 버스 구현에 대한 계약을 정의합니다.
interface EventBus {
publish<E extends EventName>(event: E, payload: EventPayload<E>): Promise<void>;
subscribe<E extends EventName>(event: E, handler: EventHandler<E>): () => void;
subscribePattern(pattern: string, handler: PatternHandler): () => void;
clear(): void;
}
EventBus 메서드
| 방법 | 설명 |
|---|---|
publish |
페이로드와 함께 입력된 이벤트를 게시합니다. |
subscribe |
특정 이벤트를 구독하세요. 구독 취소 함수가 반환됩니다. |
subscribePattern |
glob 패턴과 일치하는 이벤트를 구독합니다(예: scrum:*) |
clear |
모든 구독을 제거합니다. |
LocalEventBus: 프로세스 내 구현
수업 LocalEventBus Node.js를 기반으로 한 기본 구현
EventEmitter 다음을 통해 패턴 지원 micromatch:
import { EventEmitter } from "node:events";
import micromatch from "micromatch";
interface PatternSubscription {
pattern: string;
handler: PatternHandler;
}
export class LocalEventBus implements EventBus {
private emitter = new EventEmitter();
private patternSubs: PatternSubscription[] = [];
constructor() {
this.emitter.setMaxListeners(100);
}
async publish(event: string, payload: unknown): Promise<void> {
// Notifica subscriber esatti
this.emitter.emit(event, payload);
// Notifica subscriber pattern
for (const sub of this.patternSubs) {
if (micromatch.isMatch(event, sub.pattern)) {
try {
await sub.handler(event, payload);
} catch {
// Errori nei subscriber non bloccano la pubblicazione
}
}
}
}
subscribe(event: string, handler: EventHandler): () => void {
this.emitter.on(event, handler);
return () => this.emitter.off(event, handler);
}
subscribePattern(pattern: string, handler: PatternHandler): () => void {
const sub: PatternSubscription = { pattern, handler };
this.patternSubs.push(sub);
return () => {
const index = this.patternSubs.indexOf(sub);
if (index >= 0) this.patternSubs.splice(index, 1);
};
}
clear(): void {
this.emitter.removeAllListeners();
this.patternSubs = [];
}
}
주요 기능: 이벤트당 최대 100개의 리스너, 패턴 일치를 통해
micromatch 와일드카드(scrum:*, *:completed), 오류
게시를 중단하지 않고 종속성이 전혀 없도록 자동으로 캡처된 패턴 핸들러
외부 너머 micromatch.
EventMap으로 입력 완료
지도 덕분에 각 이벤트의 이름과 페이로드가 모두 입력됩니다. EventMap.
TypeScript 컴파일러는 컴파일 타임에 페이로드가 올바른지 확인합니다.
// Il compilatore TypeScript verifica che il payload sia corretto
eventBus.publish('scrum:sprint-started', {
sprintId: '42',
name: 'Sprint 15',
startDate: '2025-01-01',
endDate: '2025-01-14',
});
// Errore di compilazione: manca il campo 'name'
eventBus.publish('scrum:sprint-started', {
sprintId: '42',
});
11개 도메인에 입력된 29개 이벤트
MCP 제품군은 다음을 정의합니다. 29가지 대표적인 사건 에서 조직 도메인 11개. 매
이벤트는 형식을 따릅니다 dominio:azione-in-kebab-case TypeScript 페이로드가 있습니다
강력하게 대표됩니다.
도메인 맵
| 도메인 | 번호 이벤트 | 기능 영역 |
|---|---|---|
code:* |
3 | 코드와 힘내 |
cicd:* |
2 | CI/CD |
scrum:* |
4 | 프로젝트 관리 |
time:* |
2 | 시간 추적 |
db:* |
2 | 데이터베이스 |
test:* |
2 | 테스트 |
docs:* |
2 | 선적 서류 비치 |
perf:* |
2 | 성능 |
retro:* |
2 | 회고전 |
economics:* |
2 | 프로젝트 경제 |
standup:* |
1 | 스탠드업 |
| Totale | 29 |
이벤트 전체 참조
서버 및 트리거가 포함된 29개 이벤트 모두
| 도메인 | 이벤트 | 발행자 | 트리거(도구) |
|---|---|---|---|
| 대기열 | code:commit-analyzed |
코드 검토 | analyze-diff |
code:review-completed |
코드 검토 | suggest-improvements |
|
code:dependency-alert |
종속성 관리자 | check-vulnerabilities |
|
| cicd | cicd:pipeline-completed |
cicd-모니터 | get-pipeline-status |
cicd:build-failed |
cicd-모니터 | get-pipeline-status |
|
| 스크럼 | scrum:sprint-started |
스크럼 보드 | create-sprint |
scrum:sprint-completed |
스크럼 보드 | close-sprint |
|
scrum:task-updated |
스크럼 보드 | update-task-status |
|
scrum:story-completed |
스크럼 보드 | close-sprint |
|
| 시간 | time:entry-logged |
시간 추적 | log-time, stop-timer |
time:timesheet-generated |
시간 추적 | get-timesheet |
|
| db | db:schema-changed |
db-스키마-탐색기 | explore-schema |
db:index-suggestion |
db-스키마-탐색기 | suggest-indexes |
|
| 시험 | test:generated |
테스트 생성기 | generate-unit-tests |
test:coverage-report |
테스트 생성기 | analyze-coverage |
|
| 문서 | docs:api-updated |
API 문서 | extract-endpoints |
docs:stale-detected |
API 문서 | find-undocumented |
|
| 완벽한 | perf:bottleneck-found |
성능 프로파일러 | find-bottlenecks |
perf:profile-completed |
성능 프로파일러 | benchmark-compare |
|
| 뒤쪽에 | retro:action-item-created |
회고 관리자 | generate-action-items |
retro:completed |
회고 관리자 | (소급 폐쇄) | |
| 경제학 | economics:budget-alert |
프로젝트 경제학 | get-budget-status |
economics:cost-updated |
프로젝트 경제학 | log-cost |
|
| 정정 당당한 | standup:report-generated |
스탠드업 노트 | log-standup |
유형화된 페이로드의 예
각 이벤트에는 특정 TypeScript 페이로드가 있습니다. 각각의 대표적인 사례를 소개합니다. 메인 도메인:
// scrum:sprint-completed
{
sprintId: string;
name: string;
velocity: number;
completedStories: number;
incompleteStories: number;
}
// time:entry-logged
{
taskId: string;
userId: string;
minutes: number;
date: string; // ISO 8601
}
// cicd:build-failed
{
pipelineId: string;
error: string;
stage: string;
branch: string;
}
// economics:budget-alert
{
project: string;
percentUsed: number;
threshold: number; // es. 80
remaining: number;
}
// code:dependency-alert
{
package: string;
severity: 'critical' | 'high' | 'medium' | 'low';
advisory: string;
}
서버 통합 패턴
EventBus를 서버에 통합하는 것은 표준화된 4단계 패턴을 따릅니다. 책임 분리 및 완전한 선택성.
1. EventBus(index.ts) 생성
// servers/<nome>/src/index.ts
import { LocalEventBus } from '@mcp-suite/event-bus';
const eventBus = new LocalEventBus();
const suite = createMyServer(eventBus);
2. 서버(server.ts)에 주입
export function createMyServer(eventBus?: EventBus): McpSuiteServer {
const suite = createMcpServer({
name: 'my-server',
version: '0.1.0',
eventBus,
});
const store = new MyStore();
// Tool che pubblica eventi
registerCreateItem(suite.server, store, suite.eventBus);
// Tool read-only: non serve l'eventBus
registerListItems(suite.server, store);
// Collaboration handlers
if (suite.eventBus) {
setupCollaborationHandlers(suite.eventBus, store);
}
return suite;
}
3. 도구 핸들러(tools/*.ts)에 게시
export function registerCreateItem(
server: McpServer,
store: MyStore,
eventBus?: EventBus,
): void {
server.tool('create-item', 'Create a new item', schema, async (args) => {
const item = store.create(args);
// Fire-and-forget: eventBus può essere undefined
eventBus?.publish('domain:item-created', {
itemId: item.id,
// ...payload tipizzato
});
return { content: [{ type: 'text', text: JSON.stringify(item) }] };
});
}
4. 구독(collaboration.ts)
export function setupCollaborationHandlers(
eventBus: EventBus,
store: MyStore,
): void {
eventBus.subscribe('other-domain:event', (payload) => {
// Reagisci all'evento
store.updateSomething(payload);
});
}
EventBus 설계 원칙
- Fire-and-Forget:
eventBus?.publish()선택적 연결을 사용하면 정의되지 않은 경우를 처리합니다. 그것은 사용되지 않습니다await - 돌연변이 도구만 게시: 생성, 업데이트 및 삭제 도구는 이벤트를 게시합니다. 독서 도구 아니요
- 고립된 협업: 사건에 대한 반응의 논리는 항상
collaboration.ts, 도구 핸들러에는 절대 없습니다. - 콘텐츠 오류: 구독자의 실패는 게시자에게 영향을 미치지 않습니다.
마이크로매치를 이용한 패턴 매칭
방법 subscribePattern 다음을 사용하여 이벤트 그룹을 구독할 수 있습니다.
글로브 패턴, 라이브러리 덕분에 micromatch:
// Tutti gli eventi del dominio scrum
eventBus.subscribePattern('scrum:*', (event, payload) => {
console.log(`Scrum event: ${event}`, payload);
});
// Tutti gli eventi di completamento
eventBus.subscribePattern('*:*-completed', (event, payload) => {
console.log(`Completed: ${event}`, payload);
});
// Workflow orchestrator: intercetta TUTTI gli eventi
eventBus.subscribePattern('*', async (event, payload) => {
const workflows = store.getActiveWorkflowsByTrigger(event);
for (const workflow of workflows) {
if (matchesConditions(workflow.triggerConditions, payload)) {
await executeWorkflow(workflow, payload);
}
}
});
협업 매트릭스: 게시자와 구독자
협업 매트릭스는 제품군 내 22개 서버 간의 모든 이벤트 흐름을 문서화합니다. 매 서버이며 이벤트 네트워크에서의 역할에 따라 분류됩니다.
누가 무엇에 서명하나요?
활성 구독
| 구독자 서버 | 구독한 이벤트 | 반응 |
|---|---|---|
| 민첩한 측정항목 | scrum:sprint-completed |
속도 데이터 캐시 |
scrum:task-updated |
사이클 시간별 전환 추적 | |
scrum:story-completed |
처리량 업데이트 | |
| 시간 추적 | scrum:task-updated |
자동 시작/중지 타이머(향후) |
| 프로젝트 경제학 | time:entry-logged |
시간을 비용으로 전환 |
scrum:sprint-completed |
스프린트 비용 스냅샷 | |
| 스크럼 보드 | retro:action-item-created |
자동 생성 작업(향후) |
| 회고 관리자 | scrum:sprint-completed |
셀프크리에이션 백펜던트(미래) |
cicd:build-failed |
토론 항목 추가됨(향후) | |
| 스탠드업 노트 | scrum:task-updated |
스탠드업 진행 상황(미래) |
cicd:build-failed |
잠재적 차단제 추가(향후) |
서버 분류
제품군에 포함된 22개의 서버는 네트워크에서의 역할에 따라 4가지 범주로 분류됩니다. 협업:
양방향 서버(게시 + 구독)
이 5개의 서버는 양방향으로 이벤트 네트워크에 적극적으로 참여합니다.
양방향 서버
| 섬기는 사람 | 게시 | 구독하다 | Collaboration.ts 파일 |
|---|---|---|---|
| 스크럼 보드 | 4개 이벤트 | 이벤트 1개 | Si |
| 시간 추적 | 이벤트 1개 | 이벤트 1개 | Si |
| 프로젝트 경제학 | 이벤트 2개 | 이벤트 2개 | Si |
| 회고 관리자 | 이벤트 1개 | 이벤트 2개 | Si |
| 스탠드업 노트 | 이벤트 1개 | 이벤트 2개 | Si |
게시자 전용 서버(7개 서버)
이벤트를 생성하지만 외부 이벤트에 반응하지 않습니다.
- cicd-모니터 (2개 이벤트): DevOps 이벤트 허브
- 코드 검토 (2개 이벤트): 코드 분석 알림
- 종속성 관리자 (1개 이벤트): 취약점 경고
- db-스키마-탐색기 (1개 이벤트): 인덱스 제안
- 테스트 생성기 (2개 이벤트): 테스트 생성 알림
- API 문서 (2개 이벤트): 문서 업데이트
- 성능 프로파일러 (2개 이벤트) : 실적보고
가입자 전용 서버(서버 1대)
민첩한 측정항목 (3개의 수신 이벤트): 스크럼 이벤트에서 메트릭을 계산합니다. 도구에서 직접 이벤트를 게시하세요.
패스스루 서버(9개 서버)
이러한 서버는 공장에서 EventBus를 허용하지만 현재 게시하거나 구독하지 않습니다. 향후 확장을 위해 준비되었습니다.
- docker-compose, 로그 분석기, 데이터 모의 생성기
- 코드베이스 지식, 정규식 작성기, http-클라이언트
- 조각 관리자, 프로젝트 스캐폴딩, 환경 관리자
ClientManager: 서버 간 동기 RPC 호출
Il 클라이언트매니저 및 제2 서버 간 통신 메커니즘. 달리 EventBus(비동기식 Fire-and-Forget)의 경우 ClientManager를 사용하면 MCP 서버가 다음을 수행할 수 있습니다. 다른 서버의 도구 호출 동기식으로 결과를 얻습니다. (요청/응답).
Server Chiamante Client Manager Server Target
| | |
|-- callTool('target', | |
| 'tool') ------------>| |
| |-- MCP JSON-RPC ------>|
| | |
| |<-- JSON-RPC response--|
|<-- risultato ----------| |
| | |
| (sincrono: il chiamante attende il risultato) |
EventBus 대 ClientManager
| 특성 | 이벤트버스(Pub/Sub) | 클라이언트매니저(RPC) |
|---|---|---|
| 의사소통 | 비동기식, 실행 후 잊어버리기 | 동기식, 요청/응답 |
| 방향 | 일대다(브로드캐스트) | 일대일(직접 통화) |
| 연결 | 없음(게시자가 구독자를 무시함) | 낮음(서버 이름 및 도구를 알고 있음) |
| 일반적인 사용 | 알림, 자동 업데이트 | 데이터 쿼리, 결과 강화 |
| 오류 | 무시됨(게시자에게 영향을 주지 않음) | 우아한 성능 저하로 관리됨 |
| 숨어 있음 | 마이크로초(진행 중) | 밀리초 |
| Esempio | "스프린트 생성됨" -> 측정항목 업데이트 | "스프린트 데이터 제공" -> 속도 계산 |
경험 법칙: 원할 때마다 EventBus를 사용하십시오. 통지하다 다른 서버, ClientManager가 있으면 사용하세요. 데이터가 필요하다 다른 서버에서.
ClientManager를 사용한 서버 간 호출의 예
export function registerForecastBudget(
server: McpServer,
store: EconomicsStore,
clientManager?: McpClientManager,
): void {
server.tool(
'forecast-budget',
'Prevedi quando il budget si esaurira',
{
projectName: z.string(),
includeTimeData: z.boolean().optional().default(false),
},
async ({ projectName, includeTimeData }) => {
const forecast = store.forecastBudget(projectName);
const result: Record<string, unknown> = { ...forecast };
// Cross-server call: recupera dati dal time-tracking
if (includeTimeData && clientManager) {
const timeResult = await clientManager.callTool(
'time-tracking', // Server target
'get-timesheet', // Tool da invocare
{}, // Argomenti
);
const content = (timeResult as {
content: Array<{ type: string; text: string }>;
}).content;
const timesheet = JSON.parse(content[0].text);
result.laborAnalysis = {
trackedHours: timesheet.totalMinutes / 60,
estimatedLaborCost: (timesheet.totalMinutes / 60) * 50,
};
}
return {
content: [{ type: 'text', text: JSON.stringify(result, null, 2) }],
};
},
);
}
구현된 6가지 배선 시나리오
MCP Suite는 5개의 호출 서버와 3개의 호출 서버를 포함하는 6개의 서버 간 통신 시나리오를 구현합니다. 대상 서버:
서버 간 배선 시나리오
| # | 방문객 | 목표 | 도구 대상 | 범위 |
|---|---|---|---|---|
| 1 | 민첩한 측정항목 | 스크럼 보드 | get-sprint |
실제 스프린트 데이터를 이용한 속도 계산 |
| 2 | 민첩한 측정항목 | 시간 추적 | get-timesheet |
추적된 시간으로 주기 시간 강화 |
| 3 | 프로젝트 경제학 | 시간 추적 | get-timesheet |
작업표에서 작업 비용 계산 |
| 4 | 데이터 모의 생성기 | db-스키마-탐색기 | explore-schema |
실제 DB 스키마에서 모의 생성 |
| 5 | 테스트 생성기 | 코드베이스 지식 | explain-module |
양식 분석을 통한 테스트 생성 |
| 6 | 스탠드업 노트 | 스크럼 보드 | sprint-board |
스프린트 데이터가 포함된 상태 보고서 |
우아한 저하
배선의 기본 원리는 우아한 저하: 모든 도구가 작동합니다 ClientManager 없이도 완벽합니다. 연결은 결과를 풍부하게 하지만 필수 사항은 아닙니다.
// Il pattern if (param && clientManager) garantisce:
// 1. Senza clientManager: il tool funziona normalmente
// 2. Senza il parametro trigger: il wiring non viene attivato
// 3. Con entrambi: il risultato viene arricchito con dati esterni
if (enrichFromExternal && clientManager) {
// cross-server call
}
엔드투엔드 흐름
협업의 진정한 힘은 여러 서버를 교차하는 엔드투엔드 흐름에서 나타납니다. 이러한 흐름은 중앙 집중식 조정 없이 이벤트의 자연스러운 구성에서 발생합니다.
흐름 1: 스프린트 수명 주기
[Creazione Sprint]
scrum-board:create-sprint
|
+-- scrum:sprint-started -----> (informativo, espansione futura)
[Lavoro durante lo Sprint]
scrum-board:update-task-status
|
+-- scrum:task-updated -------> agile-metrics (cycle time)
| +-> time-tracking (auto-timer futuro)
| +-> standup-notes (contesto standup)
[Chiusura Sprint]
scrum-board:close-sprint
|
+-- scrum:sprint-completed ---> agile-metrics (velocity)
| +-> project-economics (snapshot costo)
| +-> retrospective-mgr (auto-crea retro)
|
+-- scrum:story-completed ----> agile-metrics (throughput)
흐름 2: 시간 및 비용 추적
[Registrazione Tempo]
time-tracking:log-time / stop-timer
|
+-- time:entry-logged --------> project-economics (conversione costo)
[Registrazione Costo Diretto]
project-economics:log-cost
|
+-- economics:cost-updated ---> (informativo)
[Verifica Budget]
project-economics:get-budget-status
|
+-- economics:budget-alert ---> (notifica se >80%)
흐름 3: DevOps 주기
[Monitoraggio Pipeline]
cicd-monitor:get-pipeline-status
|
+-- cicd:pipeline-completed --> (informativo)
|
+-- cicd:build-failed -------> retrospective-mgr (item discussione)
+-> standup-notes (blocker)
흐름 4: 품질 및 검토
[Analisi Codice]
code-review:analyze-diff
|
+-- code:commit-analyzed -----> (informativo)
code-review:suggest-improvements
|
+-- code:review-completed ----> (informativo, codebase-knowledge futuro)
[Vulnerabilità]
dependency-manager:check-vulnerabilities
|
+-- code:dependency-alert ----> (informativo)
흐름 5: 회고적이고 지속적인 개선
[Sprint Completato]
scrum:sprint-completed -----------> retrospective-mgr (auto-crea retro)
[Generazione Action Items]
retrospective-mgr:generate-action-items
|
+-- retro:action-item-created -> scrum-board (auto-crea task futuro)
완전한 네트워크 다이어그램
전체 흐름은 네트워크를 형성합니다. 스크럼 보드 4개의 이벤트가 있는 중앙 허브
4개의 다른 서버에 도달하는 발신 메시지. 민첩한 측정항목 그리고 가장 큰 구독자
3개의 입력 이벤트가 있습니다. 시간 추적 e 프로젝트 경제학 그들은 형성한다
체인: 기록된 시간은 이벤트를 통해 자동으로 비용이 됩니다.
time:entry-logged.
EventBus 및 배선 테스트
협업을 테스트하기 위해 Tech-MCP는 다음을 제공합니다. MockEventBus 사건을 기록하는 것
부작용 없이 출판됨:
export class MockEventBus implements EventBus {
public published: Array<{ event: string; payload: unknown }> = [];
async publish(event: string, payload: unknown): Promise<void> {
this.published.push({ event, payload });
}
subscribe(): () => void { return () => {}; }
subscribePattern(): () => void { return () => {}; }
clear(): void { this.published = []; }
// Utility per asserzioni
wasPublished(eventName: string): boolean {
return this.published.some((e) => e.event === eventName);
}
}
// Uso nei test
it('should publish time:entry-logged event', async () => {
const eventBus = new MockEventBus();
const { server } = createTimeTrackingServer({
eventBus,
storeOptions: { inMemory: true },
});
const harness = await createTestHarness(server);
await harness.client.callTool({
name: 'log-time',
arguments: { taskId: 'TASK-1', durationMinutes: 60 },
});
expect(eventBus.wasPublished('time:entry-logged')).toBe(true);
});
서버 간 배선의 경우 테스트에서는 다음을 사용합니다. InMemoryTransport 서버를 연결하려면
네트워크 없이 진행 중입니다. 순서가 중요합니다. 대상 서버가 전송 서버에 연결되어야 합니다.
전에 클라이언트가 즉시 메시지를 보내기 때문에 클라이언트의
initialize 연결할 때.
향후 개발
협업 네트워크는 성장하도록 설계되었습니다. 계획된 개발 중:
- Redis 이벤트버스: 다중 프로세스 배포를 위해 별도의 프로세스에 있는 서버 간의 협업이 가능합니다.
- 새로운 이벤트:
scrum:backlog-prioritized,time:timer-started/time:timer-stopped,deploy:release-created - 협업 핸들러의 완전한 구현: 현재 많은 핸들러에는 구현을 기다리는 자리 표시자가 포함되어 있습니다.
- 워크플로 조정자: 다음을 사용하는 서버
subscribePattern('*')복잡한 다단계 흐름을 조정하기 위해
결론
서버 간 협업은 컬렉션을 변환하는 아키텍처 계층입니다. 독립된 서버를 하나로 통합 생태계. EventBus는 디커플링을 제공합니다. 자동 알림 및 반응을 위해 ClientManager를 통해 데이터 강화 가능 동기식 서버 간 쿼리를 통해.
11개의 도메인으로 구성된 29개의 유형 이벤트는 모든 작업이 이루어지는 협업 네트워크를 만듭니다. 심각한 경우 여러 서버에서 자동 반응이 발생할 수 있습니다. 서버 분류 양방향, 게시자 전용, 구독자 전용 및 패스스루 방식으로 아키텍처의 명확성을 제공합니다. 향후 확장을 촉진합니다.
다음 기사에서는 이에 대해 다루겠습니다. 전문적인 테스트 및 프로덕션 배포, 테스트 도구인 InMemoryTransport를 사용하여 MCP 서버를 테스트하는 방법과 이를 준비하는 방법을 분석합니다. 구성, 로깅, 모니터링을 갖춘 프로덕션 환경.
전체 서버 간 협업 코드는 저장소에서 사용할 수 있습니다. GitHub의 Tech-MCP.