项目文件夹

文件
Asim Aslam 081e375f29 Add AI provider integration guide and new providers support (#2900)
* docs: add AI provider integration guide and Supported AI Providers section

Add a step-by-step guide for AI infrastructure companies to implement
ai.Model and contribute a provider to go-micro. Covers the full
lifecycle: skeleton, tool call handling, tests, registration, and PR
checklist.

Add a "Supported AI Providers" section to the project README that lists
current providers (Anthropic, OpenAI) in a table and links to the
integration guide with a call-to-action for new providers and sponsors.

Streamline the "Adding a New Provider" section in ai/README.md to point
to the new guide instead of duplicating a full code listing.

* fix: remove nonexistent Discord link from README

* fix(website): set content container width to 800px on desktop

Move the 800px max-width from .markdown-body up to .content so
the entire content pane (not just the inner body) is sized
correctly. The container now fills up to 800px beside the sidebar.

* feat(ai): wire Atlas Cloud into server and auto-detection

Import atlascloud provider in the micro server so it is available
when running micro run / micro server. Add atlascloud to
AutoDetectProvider so --ai_base_url with an atlascloud domain
selects the right provider automatically.

* feat(ai): add Google Gemini provider

Add ai/gemini implementing ai.Model for Google's Gemini API. Uses
the native generateContent endpoint with system_instruction,
contents/parts, and functionDeclarations — not an OpenAI shim.
Default model gemini-2.5-flash, auth via x-goog-api-key header.

Wire into micro server imports and AutoDetectProvider (matches
googleapis.com and google in base URL).

Update README.md and ai/README.md with provider listing.

* feat(ai): add Groq, Mistral, and Together AI providers

Add three new OpenAI-compatible providers:

- ai/groq: ultra-fast inference, default model llama-3.3-70b-versatile
- ai/mistral: Mistral AI, default model mistral-large-latest
- ai/together: Together AI, default model Llama-3.3-70B-Instruct-Turbo

All three are wired into the micro server imports and
AutoDetectProvider. README and ai/README updated with the full
provider table.

* feat(ai): add ai/tools helper and 'micro chat' interactive agent

Extract the registry-discovery + RPC-execution loop from the web
agent playground into a reusable ai/tools package:

- tools.New(reg) creates a Set bound to a registry
- Set.Discover() walks the registry and returns []ai.Tool with
  LLM-safe (underscored) names, remembering the mapping back to
  the original dotted form
- Set.Handler(client) returns an ai.ToolHandler that resolves
  the safe name and issues the RPC

Add cmd/micro/chat — an interactive 'micro chat' REPL that uses
ai/tools to let users talk to their services through any
registered AI provider. Supports --prompt for single-shot use,
auto-detects the provider from --base_url, and falls back to the
provider's conventional env var (ANTHROPIC_API_KEY, etc).

Update README with the new command and the programmatic example.

* feat(examples): add gRPC interop example

Add examples/grpc-interop showing that any standard gRPC client can
call a go-micro service — no go-micro SDK required on the client
side. Includes:

- proto/greeter.proto with generated Go, gRPC, and micro stubs
- server/ using go-micro gRPC transport
- client/ using stock google.golang.org/grpc (no go-micro imports)
- README with Python example and explanation of how routing works

Addresses the confusion from issue #2818 where users didn't know
that go-micro gRPC services are callable by any gRPC client.

---------

Co-authored-by: Claude <noreply@anthropic.com>
2026-05-24 18:17:04 +01:00

67 行
2.2 KiB
Markdown

# gRPC Interop Example
This example shows that **any standard gRPC client** can call a go-micro service — no go-micro SDK required on the client side.
The server is a normal go-micro service using the gRPC transport. The client is a plain `google.golang.org/grpc` client with no go-micro imports.
## How it works
go-micro's gRPC server uses a [`grpc.UnknownServiceHandler`](https://pkg.go.dev/google.golang.org/grpc#UnknownServiceHandler) that catches all incoming requests and routes them by parsing the standard gRPC method path (`/package.Service/Method`). This means any language with gRPC support (Python, Java, Rust, etc.) can call go-micro services using generated protobuf stubs.
## Running
Start the server:
```bash
cd examples/grpc-interop
go run ./server/
```
In another terminal, call it with the standard gRPC client:
```bash
cd examples/grpc-interop
go run ./client/ --name Alice
# Response: Hello Alice
```
## Calling from other languages
Generate stubs from `proto/greeter.proto` in your language of choice and point them at `localhost:50051`. For example, with Python:
```bash
pip install grpcio-tools
python -m grpc_tools.protoc -Iproto --python_out=. --grpc_python_out=. proto/greeter.proto
```
```python
import grpc
import greeter_pb2
import greeter_pb2_grpc
channel = grpc.insecure_channel("localhost:50051")
stub = greeter_pb2_grpc.GreeterStub(channel)
response = stub.Hello(greeter_pb2.HelloRequest(name="Alice"))
print(response.message) # Hello Alice
```
## Key points
- The go-micro server registers handlers via `pb.RegisterGreeterHandler()`
- The standard gRPC client uses stubs generated by `protoc-gen-go-grpc`
- Both share the same `.proto` file — that's the contract
- The server uses protobuf encoding on the wire, same as any gRPC service
- Service discovery (mDNS, consul, etc.) is only needed for go-micro-to-go-micro calls; direct gRPC clients connect by address
## Regenerating proto stubs
```bash
protoc --go_out=. --go_opt=paths=source_relative \
--go-grpc_out=. --go-grpc_opt=paths=source_relative \
--micro_out=. --micro_opt=paths=source_relative \
proto/greeter.proto
```
Requires `protoc-gen-go`, `protoc-gen-go-grpc`, and `protoc-gen-micro`.