Балансировка нагрузки и обнаружение сервисов
Разберитесь, как серверные части SaaS распределяют трафик между множеством экземпляров с помощью балансировщиков нагрузки, проверок работоспособности и обнаружения сервисов.
«Балансировка нагрузки и обнаружение сервисов» — бесплатный урок SaaS Architecture & Startup Engineering на CoddyKit. Это урок 4 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения SaaS Architecture & Startup Engineering, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс SaaS Architecture & Startup Engineering содержит 4 уроков всего.
Части этого урока еще не переведены и отображаются на английском.
The Need for Load Balancing
When one server cannot handle all traffic, you run many copies. A load balancer sits in front and spreads incoming requests across these instances.
This is the backbone of horizontal scaling for SaaS backends.
How a Load Balancer Works
Clients connect to a single address. The load balancer accepts the request and forwards it to one of the backend servers, then relays the response back.
To the client, the cluster looks like one powerful server.
Round Robin
The simplest algorithm is round robin: requests are handed to servers in rotation. Each server gets an equal share.
const servers = ['s1', 's2', 's3'];
let i = 0;
function next() {
const s = servers[i % servers.length];
i++;
return s;
}
console.log(next(), next(), next(), next());Least Connections
Least connections routes each new request to the server currently handling the fewest active connections.
This adapts better than round robin when requests have uneven durations.
Layer 4 vs Layer 7
Load balancers operate at different network layers:
- Layer 4 (transport) — routes by IP and port, very fast
- Layer 7 (application) — inspects HTTP, can route by URL path or headers
Layer 7 enables smart routing like sending /api to one pool and /static to another.
Health Checks
A load balancer must avoid sending traffic to dead servers. It runs periodic health checks against each instance.
A common pattern is a /health endpoint returning 200 OK when the app is ready.
app.get('/health', (req, res) => {
res.status(200).json({ status: 'ok' });
});Sticky Sessions
Some apps store session state in server memory. Sticky sessions pin a client to the same server so their session persists.
Better practice: keep servers stateless and store sessions in a shared store, so any server can handle any request.
Service Discovery
In dynamic environments, servers come and go constantly. Service discovery keeps an up-to-date registry of which instances exist and are healthy.
Tools like Consul, etcd, or Kubernetes services automate this.
Client-Side vs Server-Side Discovery
Two models:
- Server-side — clients hit a load balancer that consults the registry
- Client-side — clients query the registry directly and pick an instance themselves
Server-side is simpler; client-side reduces a network hop.
Autoscaling Integration
Load balancers pair with autoscaling: when traffic rises, new instances spin up, register with discovery, and the balancer starts routing to them automatically.
When traffic drops, instances are removed gracefully after draining connections.
Graceful Draining
Before shutting down an instance, the balancer should stop sending new requests but let existing ones finish. This is connection draining.
It prevents dropped requests during deployments and scale-down events.
Quick Check
Test your load balancing knowledge.
Recap
You learned how SaaS backends distribute traffic:
- Load balancers with round robin and least connections
- Layer 4 vs Layer 7 routing and health checks
- Stateless design, service discovery, and graceful draining
Together these let a backend scale horizontally and survive failures.
Изучай SaaS Architecture & Startup Engineering с ИИ-репетитором — бесплатно
Пиши и запускай код прямо в браузере, получай мгновенную помощь от ИИ-репетитора 24/7 и продолжи учиться на сайте или в приложении.
- Курсы
- 12
- Уроки
- 48
Часто задаваемые вопросы
Урок «Балансировка нагрузки и обнаружение сервисов» бесплатный?
Да — полный текст урока «Балансировка нагрузки и обнаружение сервисов» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс SaaS Architecture & Startup Engineering, подпишись на CoddyKit PRO. Курс SaaS Architecture & Startup Engineering содержит 4 уроков всего.
Чему я научусь в уроке «Балансировка нагрузки и обнаружение сервисов»?
Разберитесь, как серверные части SaaS распределяют трафик между множеством экземпляров с помощью балансировщиков нагрузки, проверок работоспособности и обнаружения сервисов. Ты практикуешь SaaS Architecture & Startup Engineering с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.
Нужен ли мне опыт, чтобы начать SaaS Architecture & Startup Engineering?
Предыдущий опыт не требуется. SaaS Architecture & Startup Engineering на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 4 из 4.
Сколько времени занимает урок «Балансировка нагрузки и обнаружение сервисов»?
Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.
Можно ли писать и запускать код в этом уроке SaaS Architecture & Startup Engineering?
Да. Каждый урок SaaS Architecture & Startup Engineering включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.
Все уроки этого курса
- Методы горизонтального масштабирования
- Очереди сообщений и событийная архитектура
- Основы бессерверной архитектуры
- Балансировка нагрузки и обнаружение сервисов