Penyeimbangan Beban dan Penemuan Layanan
Pahami cara backend SaaS mendistribusikan lalu lintas ke banyak instans menggunakan penyeimbang beban, pemeriksaan kesehatan, dan penemuan layanan.
Penyeimbangan Beban dan Penemuan Layanan adalah pelajaran SaaS Architecture & Startup Engineering gratis di CoddyKit. Ini adalah pelajaran 4 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar SaaS Architecture & Startup Engineering, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus SaaS Architecture & Startup Engineering mencakup 4 pelajaran total.
Bagian dari pelajaran ini belum diterjemahkan dan ditampilkan dalam bahasa Inggris.
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.
Pertanyaan yang Sering Diajukan
Apakah pelajaran “Penyeimbangan Beban dan Penemuan Layanan” gratis?
Ya — teks lengkap “Penyeimbangan Beban dan Penemuan Layanan” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus SaaS Architecture & Startup Engineering, upgrade ke CoddyKit PRO. Kursus SaaS Architecture & Startup Engineering mencakup 4 pelajaran total.
Apa yang akan aku pelajari di “Penyeimbangan Beban dan Penemuan Layanan”?
Pahami cara backend SaaS mendistribusikan lalu lintas ke banyak instans menggunakan penyeimbang beban, pemeriksaan kesehatan, dan penemuan layanan. Kamu berlatih SaaS Architecture & Startup Engineering dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.
Apakah aku perlu pengalaman untuk memulai SaaS Architecture & Startup Engineering?
Tidak diperlukan pengalaman sebelumnya. SaaS Architecture & Startup Engineering di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 4 dari 4.
Berapa lama pelajaran “Penyeimbangan Beban dan Penemuan Layanan” memakan waktu?
Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.
Bisakah aku menulis dan menjalankan kode dalam pelajaran SaaS Architecture & Startup Engineering ini?
Ya. Setiap pelajaran SaaS Architecture & Startup Engineering menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.
Semua pelajaran dalam kursus ini
- Teknik Penskalaan Horizontal
- Antrean Pesan dan Berbasis Peristiwa
- Dasar-Dasar Arsitektur Tanpa Server
- Penyeimbangan Beban dan Penemuan Layanan