Service Mesh в Go: как подружить микросервисы без боли

Ваши Go-микросервисы кричат, но вы их не слышите?

Представьте: у вас есть десяток Go-микросервисов. Они общаются по gRPC, передают данные через очереди, ходят в базы. Всё работает... пока не начинается ад. Сервис A не может достучаться до сервиса B — таймауты. Сервис C падает, и вся цепочка летит в тартарары. А когда вы наконец разбираетесь, оказывается, что проблема в сетевых задержках и отсутствии ретраев.

Знакомо? Добро пожаловать в мир микросервисной архитектуры на Go. Здесь каждый сервис — это отдельный остров, и связь между ними — это океан с айсбергами. Но есть спасательный круг — Service Mesh.

В этой статье мы не будем читать скучные лекции. Мы разберём, как service mesh превращает хаос в стройную систему, и покажем это на реальном коде на Go. Поехали!

Что такое Service Mesh и зачем он Go-разработчику?

Если коротко: Service Mesh — это выделенный инфраструктурный слой для управления взаимодействием между микросервисами. Он берёт на себя всю "грязную работу": маршрутизацию, балансировку, шифрование, observability (метрики, трейсинг, логи).

Для Go микросервисов это особенно актуально. Go — язык для высоконагруженных систем, но его стандартная библиотека не решает проблемы сетевого взаимодействия в распределённой среде. Вы можете написать свой ретрай-механизм, но зачем, если есть готовое решение?

Как это работает?

Представьте, что каждый ваш Go-микросервис получает "телохранителя" — sidecar-прокси (обычно на базе Envoy). Все входящие и исходящие запросы проходят через этот прокси. Прокси общаются между собой и с центральной панелью управления. Вы получаете:

• Автоматические ретраи и таймауты — больше не нужно писать свой retry-код.
• Circuit breaker — защита от каскадных отказов.
• Mutual TLS (mTLS) — шифрование трафика между сервисами без изменения кода.
• Трассировка запросов — видите, где тормозит ваша система.

Популярные Service Mesh для Go: Istio vs Linkerd

На рынке два главных игрока: Istio и Linkerd. Оба поддерживают Go-приложения, но подходы разные.

Совет: Если вы новичок, начните с Linkerd — он проще и быстрее. Если вам нужна максимальная гибкость и кастомизация (например, сложные правила маршрутизации), выбирайте Istio.

Практика: поднимаем Service Mesh для Go-микросервисов

Давайте перейдём от теории к коду. Мы напишем два простых Go-микросервиса и "обернём" их в Linkerd (как более лёгкий вариант).

Шаг 1. Два Go-сервиса: "order" и "payment"

Создадим простой HTTP-сервер на Go, который симулирует обработку заказа:

// order-service/main.go
package main

import (
    "fmt"
    "log"
    "net/http"
    "time"
)

func main() {
    http.HandleFunc("/order", func(w http.ResponseWriter, r *http.Request) {
        // Симулируем задержку
        time.Sleep(100 * time.Millisecond)
        // Вызываем payment сервис
        resp, err := http.Get("http://payment-service:8081/pay")
        if err != nil {
            http.Error(w, "payment failed", http.StatusInternalServerError)
            return
        }
        defer resp.Body.Close()
        fmt.Fprintf(w, "Order processed, payment status: %s", resp.Status)
    })

    log.Println("Order service starting on :8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

И второй сервис — "payment":

// payment-service/main.go
package main

import (
    "fmt"
    "log"
    "net/http"
)

func main() {
    http.HandleFunc("/pay", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "Payment successful")
    })

    log.Println("Payment service starting on :8081")
    log.Fatal(http.ListenAndServe(":8081", nil))
}

Обратите внимание: в коде нет никакой логики ретраев, таймаутов или шифрования. Это сделано специально — мы увидим, как service mesh добавит это без изменения кода.

Шаг 2. Деплоим в Kubernetes (kind или minikube)

Создадим простые Dockerfile и deployment для каждого сервиса. Для краткости покажу только deployment для order-service:

# order-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 1
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
      - name: order-service
        image: myregistry/order-service:latest
        ports:
        - containerPort: 8080
---
apiVersion: