Когда приложение разбито на несколько сервисов, сразу возникают вопросы: как клиент находит нужный сервис? Кто проверяет токен — каждый сервис отдельно или кто-то один? Как постепенно переехать со старого монолита? Структурные паттерны — это готовые ответы на эти вопросы.
Разберём десять самых распространённых: от простых шлюзов до Service Mesh.
API Gateway
Представьте, что у вас в городе десяток ресторанов, но каждый по своему адресу. Вместо того чтобы запоминать все адреса, люди идут в один торговый центр — а там уже понятно, куда идти. API Gateway — это такой торговый центр для ваших сервисов.
Проблема. Клиент (мобильное приложение, браузер) не должен знать адреса всех сервисов внутри системы. Если каждый сервис сам проверяет токен, ставит лимиты на запросы и логирует — это одинаковый код в десяти местах.
Решение. Gateway принимает все входящие запросы и направляет их в нужный сервис. Сквозные задачи — аутентификация, ограничение числа запросов, CORS, логирование — делаются здесь один раз.
Пример конфигурации маршрутов в NestJS-шлюзе с http-proxy-middleware:
import { createProxyMiddleware } from 'http-proxy-middleware';
import rateLimit from 'express-rate-limit';
const app = await NestFactory.create(GatewayModule);
app.use('/api/orders',
rateLimit({ windowMs: 1_000, limit: 20 }),
createProxyMiddleware({
target: 'http://order-service:8080',
pathRewrite: { '^/api': '' }, // аналог StripPrefix
}));
app.use('/api/users',
createProxyMiddleware({
target: 'http://user-service:8080',
pathRewrite: { '^/api': '' },
}));
Gateway проверяет JWT один раз и передаёт идентификатор пользователя в сервисы через заголовок — сервисам не нужно заниматься этим самостоятельно:
@Injectable()
export class GlobalAuthMiddleware implements NestMiddleware {
constructor(private readonly jwtService: JwtService) {}
use(req: Request, res: Response, next: NextFunction): void {
const header = req.headers.authorization;
if (!header?.startsWith('Bearer ')) {
res.status(401).end();
return;
}
try {
const payload = this.jwtService.verify(header.slice(7));
req.headers['x-user-id'] = payload.sub;
req.headers['x-user-roles'] = (payload.roles as string[]).join(',');
next();
} catch {
res.status(401).end();
}
}
}
Когда нужен: много сервисов, нужна единая точка входа, сквозные задачи дублируются в каждом сервисе.
Когда не нужен: монолит или 1–2 сервиса — Gateway добавляет лишний сетевой переход без выгоды.
Gateway Routing
Проблема. Запросы нужно направлять к конкретному сервису в зависимости от URL, HTTP-метода или заголовков. Без явных правил маршрутизации невозможно понять, куда уходит каждый запрос.
Решение. Gateway Routing — это набор правил (предикатов): если URL начинается с /api/orders/, идёт в Order Service; если пришёл заголовок X-API-Version: v2, идёт в новую версию сервиса.
// По пути
app.use('/api/orders',
createProxyMiddleware({ target: 'http://order-service:8080' }));
// По заголовку — версионирование API
const usersV1 = createProxyMiddleware({ target: 'http://user-service-v1:8080' });
const usersV2 = createProxyMiddleware({ target: 'http://user-service-v2:8080' });
app.use('/api/users', (req, res, next) =>
(req.headers['x-api-version'] === 'v2' ? usersV2 : usersV1)(req, res, next));
// Распределение трафика — 20% на новую версию
const catalogV1 = createProxyMiddleware({ target: 'http://catalog-service-v1:8080' });
const catalogV2 = createProxyMiddleware({ target: 'http://catalog-service-v2:8080' });
app.use('/api/catalog', (req, res, next) =>
(Math.random() < 0.2 ? catalogV2 : catalogV1)(req, res, next));
Когда нужен: разные версии API в разных сервисах, постепенное переключение трафика на новую версию (canary).
Gateway Aggregation
Проблема. Страница заказа показывает данные из трёх сервисов: Order Service, User Service, Delivery Service. Если браузер делает три отдельных запроса — это три обращения по сети. На мобильных устройствах с медленным соединением это заметно.
Решение. Gateway принимает один запрос, параллельно опрашивает все нужные сервисы и собирает ответ в единый объект. Клиент получает данные за один круговой обход.
@Controller()
export class OrderDetailsAggregationController {
constructor(private readonly http: HttpService) {}
@Get('api/order-details/:orderId')
async getOrderDetails(
@Param('orderId') orderId: string,
): Promise<OrderDetailsResponse> {
const get = <T>(url: string): Promise<T | null> =>
firstValueFrom(this.http.get<T>(url))
.then((response) => response.data)
.catch(() => null);
const [order, user, delivery] = await Promise.all([
get<OrderDto>(`http://order-service/orders/${orderId}`),
get<UserDto>(`http://user-service/users/${await this.userIdFromOrder(orderId)}`),
get<DeliveryDto>(`http://delivery-service/deliveries?orderId=${orderId}`),
]);
return new OrderDetailsResponse(order, user, delivery);
}
}
Когда нужен: клиенту нужны данные из 2–3 сервисов, агрегация простая, без бизнес-логики.
Когда не нужен: нужна сложная трансформация или фильтрация данных — это задача для BFF.
Backend for Frontend (BFF)
Проблема. У вас мобильное приложение, веб-админка и публичный сайт. Каждому нужен свой набор данных: мобильному — минимум (экономия трафика), админке — полный набор с журналом действий, публичному сайту — только открытые данные. Один общий API не может хорошо обслуживать всех.
Решение. Для каждого типа клиента создаётся отдельный BFF-сервис. Он сам обращается к доменным сервисам и возвращает только то, что нужно конкретному клиенту. Никакой бизнес-логики в BFF нет — только выбор и форматирование данных.
Mobile BFF возвращает только нужные поля:
// Mobile BFF — минимум данных
@Controller('api/orders')
export class MobileOrderController {
constructor(
private readonly orderClient: OrderServiceClient,
private readonly userClient: UserServiceClient,
) {}
@Get(':id')
async getOrder(@Param('id') id: string): Promise<MobileOrderResponse> {
const order = await this.orderClient.getOrder(id);
const user = await this.userClient.getUser(order.userId);
return new MobileOrderResponse(
order.id,
order.status,
order.totalAmount,
user.firstName,
);
}
}
Web BFF для администратора вытягивает данные из большего числа источников и добавляет поля, которых нет в мобильной версии.
Чем BFF отличается от API Gateway: Gateway — инфраструктурный компонент, маршрутизирует запросы. BFF — прикладной сервис, знает про потребности своего клиента и адаптирует данные. Они не конкурируют: Gateway стоит перед BFF.
Когда нужен: больше одного типа клиентов с разными потребностями в данных.
Когда не нужен: один тип клиента — достаточно API Gateway.
Gateway Offloading
Проблема. Каждый сервис самостоятельно настраивает SSL, проверяет токен, отдаёт заголовки безопасности, сжимает ответы. Это одинаковая работа в каждом сервисе.
Решение. Всё это выносится на Gateway. Внутренние сервисы работают по простому HTTP без SSL и без проверки токена — идентификатор пользователя они получают уже готовым из заголовка X-User-Id.
app.use(jwtAuthMiddleware);
app.use(rateLimit({
windowMs: 1_000,
limit: 100,
keyGenerator: (req) => req.ip,
}));
app.use(helmet({
frameguard: { action: 'deny' }, // X-Frame-Options: DENY
hsts: { maxAge: 31_536_000 }, // Strict-Transport-Security
noSniff: true, // X-Content-Type-Options: nosniff
}));
Внутренний сервис просто читает заголовок — он не занимается JWT:
@Controller('orders')
export class OrderController {
@Get(':id')
getOrder(
@Param('id') id: string,
@Headers('x-user-id') userId: string,
): Promise<OrderDto> {
return this.orderService.getOrder(id, userId);
}
}
Что выносить на Gateway: SSL termination, проверка JWT-подписи, ограничение числа запросов, CORS, заголовки безопасности.
Что оставить в сервисе: авторизация (проверка прав на конкретный ресурс) — Gateway не знает бизнес-логику; валидация тела запроса — зависит от доменной модели.
Sidecar
Проблема. Сбор метрик, шифрование трафика, повторные попытки при ошибках — это нужно каждому сервису. Если сервисы написаны на разных языках, одну и ту же логику нужно писать на каждом из них.
Решение. Рядом с каждым сервисом запускается вспомогательный процесс (sidecar). Он берёт на себя инфраструктурные задачи, а основной сервис занимается только бизнес-логикой. В Kubernetes sidecar и основной контейнер живут в одном Pod-е и общаются через localhost.
spec:
containers:
- name: order-service
image: order-service:1.0
ports:
- containerPort: 8080
- name: envoy-sidecar
image: envoyproxy/envoy:v1.28
ports:
- containerPort: 9901
- containerPort: 15001
- containerPort: 15006
Когда нужен: сервисы на разных языках, нужно единообразное шифрование трафика или повторные попытки на уровне сети.
Когда не нужен: все сервисы на одном языке — проще библиотека (opossum для Node.js, tenacity для Python).
Service Mesh
Проблема. Sidecar решает задачу для одного сервиса. Но когда сервисов десятки — кто настраивает все эти прокси? Как управлять тем, кому с кем можно общаться? Как включить шифрование сразу для всей системы?
Решение. Service Mesh — инфраструктурный слой, который управляет всей сетью между сервисами. Он состоит из двух частей:
- Data Plane — прокси (Envoy) в каждом Pod-е, через которые проходит весь трафик.
- Control Plane — управляющий компонент (Istio, Linkerd), который раздаёт конфигурацию всем прокси.
Пример: Istio переключает 20% трафика на новую версию сервиса и настраивает повторные попытки:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: order-service
spec:
hosts:
- order-service
http:
- route:
- destination:
host: order-service
subset: v1
weight: 80
- destination:
host: order-service
subset: v2
weight: 20
retries:
attempts: 3
perTryTimeout: 2s
retryOn: 5xx,reset,connect-failure
API Gateway vs Service Mesh: Gateway обрабатывает трафик «снаружи внутрь» (клиент → система). Service Mesh управляет трафиком внутри системы (сервис → сервис).
Когда нужен: десятки сервисов, строгие требования к безопасности (шифрование между всеми сервисами), тонкое управление трафиком.
Когда не нужен: меньше 10 сервисов — сложность управления перевесит выгоду; достаточно библиотек вроде opossum.
Strangler Fig
Проблема. Есть работающий монолит, который нужно перевести на микросервисы. Переписать всё сразу — рискованно и занимает год. Остановить новые функции на время переезда — невозможно.
Решение. Новая функциональность реализуется в микросервисах. Старая — постепенно переключается: трафик с монолита уходит в новые сервисы по мере их готовности. Монолит продолжает работать для всего, что ещё не переехало.
Название — по аналогии с растением фикус-душитель (Strangler Fig): оно обвивает дерево и со временем замещает его.
// Gateway на этапе переезда
app.use('/api/orders',
createProxyMiddleware({ target: 'http://order-service:8080' }));
app.use('/api/users',
createProxyMiddleware({ target: 'http://user-service:8080' }));
// Старый монолит — всё остальное (регистрируется последним)
app.use('/api',
createProxyMiddleware({ target: 'http://monolith:8080' }));
Переключение через флаг позволяет вернуться назад, если что-то пошло не так:
@Injectable()
export class OrderFacade {
private readonly useNewService: boolean;
constructor(
private readonly legacyService: LegacyOrderService,
private readonly newServiceClient: NewOrderServiceClient,
config: ConfigService,
) {
this.useNewService = config.get('FEATURE_USE_NEW_ORDER_SERVICE', false);
}
getOrder(id: string): Promise<OrderDto> {
if (this.useNewService) {
return this.newServiceClient.getOrder(id);
}
return this.legacyService.getOrder(id);
}
}
Типичный порядок переезда: выбрать наименее связанный модуль → создать микросервис с тем же API → переключить трафик через Gateway → сравнить ответы → убрать код из монолита.
Когда нужен: переезд с монолита без остановки разработки.
Когда не нужен: новый проект — начинайте с нужной архитектуры сразу; монолит, который работает хорошо и не мешает — не трогайте.
Anti-Corruption Layer (ACL)
Проблема. Ваш сервис интегрируется с внешней системой, у которой своя модель данных: поля называются txn_id, amount_cents, sts, статусы передаются кодами "S"/"F"/"P". Если напрямую использовать эти модели в бизнес-логике — весь код начнёт зависеть от чужих условностей. При замене внешней системы придётся переписывать половину сервиса.
Решение. Между сервисом и внешней системой ставится слой-переводчик. Он принимает «чужие» модели и преобразует их в понятные доменные объекты — и обратно при необходимости.
// Модель внешней системы
interface ExternalPaymentResponse {
txn_id: string;
amount_cents: number;
ccy: string;
sts: string; // "S" = success, "F" = failed, "P" = pending
created_ts: number;
}
// Наша доменная модель — понятные имена
interface Payment {
transactionId: string;
amount: Money;
status: PaymentStatus;
createdAt: Date;
}
// Переводчик — изолирует внешнюю модель от домена
@Injectable()
export class PaymentMapper {
toDomain(external: ExternalPaymentResponse): Payment {
return {
transactionId: external.txn_id,
amount: Money.fromMinorUnits(external.amount_cents,
Currency.fromCode(external.ccy)),
status: this.mapStatus(external.sts),
createdAt: new Date(external.created_ts * 1000),
};
}
private mapStatus(externalStatus: string): PaymentStatus {
switch (externalStatus) {
case 'S': return PaymentStatus.SUCCESS;
case 'F': return PaymentStatus.FAILED;
case 'P': return PaymentStatus.PENDING;
default:
throw new Error(`Unknown payment status: ${externalStatus}`);
}
}
}
Когда нужен: интеграция с внешним API или старой системой с чужой моделью данных; когда планируется замена внешней системы.
Когда не нужен: внешний API полностью совпадает с вашей моделью данных и замена не планируется.
Service Registry и Service Discovery
Проблема. Сервисы масштабируются динамически: сегодня 3 экземпляра Order Service, завтра 10. Экземпляры появляются и исчезают при деплоях, автомасштабировании, перезапусках. Прописать адреса вручную невозможно.
Решение. Service Registry — реестр, в котором каждый сервис регистрируется при запуске. Другие сервисы ищут адреса через этот реестр. Есть два подхода:
- Client-Side Discovery — клиент сам спрашивает реестр (Consul, etcd) и выбирает экземпляр.
- Server-Side Discovery — запрос проходит через балансировщик, который знает про реестр (Kubernetes Services).
С Consul клиент запрашивает адреса по имени сервиса — реестр сам возвращает живые экземпляры:
import Consul from 'consul';
const consul = new Consul();
async function paymentServiceUrl(): Promise<string> {
const nodes = await consul.health.service({
service: 'payment-service',
passing: true,
});
const node = nodes[Math.floor(Math.random() * nodes.length)];
return `http://${node.Service.Address}:${node.Service.Port}`;
}
const createPayment = async (request: CreatePaymentRequest): Promise<PaymentDto> =>
(await axios.post(`${await paymentServiceUrl()}/payments`, request)).data;
В Kubernetes service discovery встроен: каждый Service получает DNS-имя, и обращение http://payment-service:8080 автоматически попадает к одному из Pod-ов.
apiVersion: v1
kind: Service
metadata:
name: payment-service
spec:
selector:
app: payment-service
ports:
- port: 8080
Когда что выбирать: Consul/etcd — если не используете Kubernetes или нужны дополнительные возможности реестра. Kubernetes DNS — если вы в Kubernetes, он встроен и ничего настраивать не нужно.
С чего начать
Если вы строите систему из нескольких сервисов:
- API Gateway + Gateway Routing — единая точка входа, маршрутизация по путям.
- Service Discovery — Kubernetes DNS, если вы в K8s; иначе Consul.
- Gateway Offloading — вынесите SSL и проверку токена на Gateway.
По мере роста:
- BFF — когда появится второй тип клиентов.
- Gateway Aggregation — когда клиентам нужны данные из нескольких сервисов за один запрос.
- Anti-Corruption Layer — при интеграции со старой системой с чужой моделью данных.
Для больших систем:
- Service Mesh — когда управление трафиком между десятками сервисов становится сложным.
- Strangler Fig — когда нужно постепенно переехать с монолита.
Коротко
- API Gateway — единая точка входа, которая берёт на себя auth, rate limiting, логирование.
- Gateway Routing — правила маршрутизации: какой запрос идёт в какой сервис.
- Gateway Aggregation — один запрос клиента → несколько параллельных вызовов → один ответ.
- BFF — отдельный сервис-адаптер для каждого типа клиента (мобильный, веб, публичный).
- Gateway Offloading — сквозные задачи (SSL, токены, заголовки) один раз на Gateway, а не в каждом сервисе.
- Sidecar — вспомогательный процесс рядом с сервисом, берёт инфраструктурные задачи независимо от языка.
- Service Mesh — управление всей сетью между сервисами через Control Plane и Envoy-прокси.
- Strangler Fig — постепенный переезд с монолита: трафик переключается по частям, откат всегда возможен.
- Anti-Corruption Layer — слой-переводчик между своей доменной моделью и чужим API.
- Service Registry & Discovery — реестр живых экземпляров сервисов; в Kubernetes встроен.
Что почитать дальше
- Паттерны отказоустойчивости — Circuit Breaker, Retry, Bulkhead.
- Распределённые паттерны — Saga, Outbox, Event Sourcing.
- Apache Kafka — асинхронная коммуникация между сервисами.