whyiyhw/chatgpt-wechat

<explanation>

1. Identify the project type and purpose

- This is a Go‑based backend “ChatGPT‑WeChat” microservice suite that safely bridges Enterprise WeChat with LLMs (OpenAI, Azure, Google Gemini, Dify, Stable Diffusion, custom vector search, etc.). It provides both a RESTful API (service/chat/api) and a minimal WebSocket “demo” UI (service/websocket), orchestrated via Docker Compose.

2. Analyze the file structure

- Top‑level “chat” directory holds Dockerfiles, build scripts (ffmpeg, MySQL/PGVector init, Redis config), compose files.

- “common” contains reusable clients/adapters (OpenAI, Dify, Gemini, Milvus, Redis, HTTP2WebSocket, plugin loader, media draw, tiktoken, error handling, request validation, paging, access logging).

- “service/chat/api” is a Go‑Zero microservice following Clean Architecture:

• handler → logic → DAO → model

• internal config, middleware, service context

- “service/websocket” is a separate Go service exposing a WebSocket demo UI, cron tasks, bucket tasks, using the same common libs.

- “plugins” folder contains example plugin containers (search, webhook) that can be launched alongside.

3. Examine the README

- Confirms microservice purpose: bridging WeChat ↔ LLMs, vector store support, plugins, voice/image capabilities.

- Points to a sample system.png, but we will build a detailed, customized diagram.

4. How to draw the system design diagram

a. Main components (use distinct shapes/colors):

• Clients: Enterprise WeChat (incoming messages), Admin/Web UI (optional external front‑end repo)

• API Service: chat‑api (HTTP/REST Go‑Zero service)

• WebSocket Service: chat‑ws (WebSocket demo UI service)

• Datastores:

– SQL DB: MySQL or PostgreSQL (chat, bots, prompts, users)

– Vector Store: Milvus or PostgreSQL+pgvector (knowledge embeddings)

– Cache: Redis (session, streaming buffer)

– File/Media Service: FFmpeg container (audio/video transcode)

• Third‑party LLM/AI services: OpenAI/Azure, Dify, Gemini, Stable Diffusion

• Plugin containers: search, webhook, (others per plugin spec)

• Optional Proxy: HTTP/SOCKS5 or FRP for external API access

b. Relationships & data flows (use directional arrows):

1. Enterprise WeChat → chat‑api (via HTTP webhook)

2. chat‑api handler → logic layer → plugin manager → common adapters

3. common adapters ↔ external LLMs (OpenAI, Dify, Gemini, Stable Diffusion)

4. If knowledge retrieval needed → logic → common/milvus adapter → vector store → return embeddings

5. Persist conversation metadata → DAO → SQL DB

6. Stream responses back → cache stream to Redis (for SSE or WebSocket)

7. Web UI clients → chat‑ws → chat‑api (via internal HTTP) → respond over WebSocket

8. FFmpeg container invoked for voice/text conversions

9. Plugins run in separate containers and communicate via HTTP/gRPC with chat‑api

c. Architectural patterns & design principles:

• Clean Architecture in chat‑api:

– “handler” (transport) → “logic” (use‑case) → “dao/model” (data)

• Adapter/Plugin Pattern: common/plugin loads dynamic plugins via defined interface

• Microservice separation: REST vs WebSocket one‐off services

• Layered containerization: each external service (DBs, vector store, ffmpeg, Redis) as separate Docker containers

d. Key technologies, frameworks, libraries:

• Go‑Zero (API scaffolding)

• Docker & Docker‑Compose (multi‑arch support)

• MySQL / PostgreSQL+pgvector

• Redis (cache, streaming buffer)

• Milvus (vector DB)

• FFmpeg (media processing)

• Common Go clients: openai-go, dify-go, gemini-go, milvus-go, redis-go

• Plugin mechanism via HTTP/gRPC

5. Tailoring guidelines

- Although primarily backend, treat it as a full‑stack microservice:

• Clearly separate “Client” (WeChat, Web UI) and “Backend Services”

• Show API boundary, WebSocket boundary, database & cache boundaries

- For plugin architecture: draw plugin containers at the same “tier” as LLM services, connected to chat‑api

6. Diagram elements to include

- Clear labels on all nodes (e.g., “chat‑api service”, “MySQL DB”, “Redis Cache”, “OpenAI API”)

- Directional arrows for request/response, data flows, dependencies

- Color coding or shapes to distinguish:

• Rectangles for services, cylinders for databases, cloud icons for third‑party APIs, rounded boxes for containers

• Use one color for internal services, another for external dependencies, another for data stores

7. Detail is critical—capture every container, client, and data flow. Group related components in “Docker‑Compose” boundary. Do not over‑simplify; show each microservice, each adapter, each datastore, and their interactions.

</explanation>