Ответ
При проектировании микросервисов на Go я использую стек технологий, сгруппированный по задачам:
1. Межсервисное взаимодействие (RPC)
-
gRPC + Protocol Buffers (Protobuf): Для быстрой, эффективной и строго типизированной синхронной коммуникации. Protobuf обеспечивает компактную бинарную сериализацию, а gRPC — транспорт и кодогенерацию клиент-серверного кода.
// Пример определения сервиса в .proto файле syntax = "proto3"; package user; option go_package = "gen/user"; service UserService { rpc GetUser (UserRequest) returns (UserResponse); } message UserRequest { int64 id = 1; } message UserResponse { string name = 1; string email = 2; }
2. Асинхронное взаимодействие
- NATS, RabbitMQ или Apache Kafka: Для построения event-driven систем, где сервисы общаются через очереди сообщений. Это позволяет создавать слабосвязанные и отказоустойчивые системы.
3. Контейнеризация и Оркестрация
- Docker: Для упаковки каждого микросервиса и его зависимостей в изолированный контейнер.
- Kubernetes: Для автоматизации развертывания, масштабирования и управления контейнеризированными приложениями.
4. Наблюдаемость (Observability)
- Prometheus + Grafana: Для сбора и визуализации метрик (CPU, память, количество запросов).
- OpenTelemetry + Jaeger/Zipkin: Для распределенной трассировки, чтобы отслеживать путь запроса через несколько сервисов и находить узкие места.
5. Фреймворки и Библиотеки
- Go-kit, Micro: Каркасы для построения микросервисов, предоставляющие готовые компоненты (логирование, трейсинг, service discovery).
- Viper: Для управления конфигурацией из файлов, переменных окружения и удаленных источников.
- Wire: Для автоматического внедрения зависимостей (Dependency Injection).
Ответ 18+ 🔞
Слушай, а вот как у меня обычно стек для микросервисов на Go собирается, прямо как конструктор, только для взрослых дядек, которые не хотят, чтобы всё развалилось нахуй к утру.
1. Чтоб сервисы друг с другом болтали (RPC) Тут без вариантов — gRPC + Protobuf. Ну серьёзно, зачем эти JSON'ы гонять туда-сюда, как дураки, если можно бинарник, быстро и по делу. Protobuf схему описал — и код самогенерируется, красота. Чистая магия, а не хуйня.
// Вот смотри, как просто. Написал в файлике — и всё, пиздец.
syntax = "proto3";
package user;
option go_package = "gen/user";
service UserService {
rpc GetUser (UserRequest) returns (UserResponse);
}
message UserRequest {
int64 id = 1;
}
message UserResponse {
string name = 1;
string email = 2;
}2. Асинхронщина, когда всем похуй и отвечать не надо Тут уже NATS, RabbitMQ или этот ваш Kafka. Кинул событие в очередь — и спи спокойно. Другие сервисы подхватят, когда проснутся. Система получается живучая, как таракан, её не убьёшь.
3. Упаковка и управление этой всей движухой Docker — само собой, каждый сервис в свою коробочку, чтоб не срались. А Kubernetes — это уже такой главный надсмотрщик, который эти коробки раскидывает, масштабирует и следит, чтоб они не подохли. Без него сейчас — вообще никуда, хоть и сложновато сначала, ёпта.
4. Наблюдаемость, чтоб не гадать на кофейной гуще А то поднимешь десять сервисов — и хуй пойми, где тормозит и кто сломался. Поэтому:
- Prometheus метрики собирает, Grafana красивые графики рисует. Видно сразу, если какой-то сервис жрёт память, как не в себя.
- OpenTelemetry + Jaeger — вот это вещь! Позволяет проследить один запрос через всю цепочку сервисов. Находишь узкое место — и сразу ясно, кого бить.
5. Разная полезная хуйня для Go
- Go-kit — как готовый набор инструментов для сервиса. Не надо каждый раз с нуля придумывать.
- Viper — чтобы конфиги не раскидывать по помойкам, а брать из одного места: файл, переменные окружения — не важно.
- Wire — для dependency injection. Чувак, это такая штука, которая сама разберётся, что куда передать. Руками не нужно эти зависимости, как дурак, собирать. Удобно, блядь.
Вот примерно так и живём. Сначала кажется, что овердохуища всего, но потом привыкаешь — и уже без этого как без рук.