Gerbang API dan Penemuan Layanan
Arahkan, gabungkan, dan temukan layanan secara dinamis.
Gerbang API dan Penemuan Layanan adalah pelajaran PHP Academy gratis di CoddyKit. Ini adalah pelajaran 3 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 PHP Academy, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus PHP Academy mencakup 4 pelajaran total.
Gerbang & Penemuan Layanan
Setelah memiliki selusin layanan, muncul dua masalah. Klien tidak seharusnya perlu mengetahui alamat setiap layanan atau memanggil lima layanan untuk menampilkan satu layar—itulah tugas gerbang API. Layanan yang skalanya naik atau turun dan alamat IP-nya berubah memerlukan cara untuk menemukan satu sama lain—itulah penemuan layanan.
Pelajaran ini membahas keduanya, dengan PHP di sisi gerbang.
Fungsi Gerbang API
Gerbang API adalah satu titik masuk di depan layanan Anda. Tanggung jawab umumnya:
- Perutean permintaan ke layanan belakang yang tepat.
- Aspek lintas fungsi: autentikasi, pembatasan laju, CORS, pengakhiran TLS.
- Agregasi: menggabungkan beberapa panggilan ke layanan belakang menjadi satu respons untuk klien.
- Penerjemahan protokol: REST eksternal masuk, gRPC internal keluar.
Gerbang ini menjaga klien tetap sederhana dan memusatkan kebijakan yang jika tidak akan Anda duplikasi di setiap layanan.
Perutean di Tepi
Pada intinya, gerbang memetakan jalur masuk ke layanan hulu. Gerbang produksi (Kong, Traefik, Nginx, AWS API Gateway) melakukannya secara deklaratif, tetapi logikanya cukup sederhana untuk diilustrasikan dalam PHP.
<?php
$routes = [
'#^/api/orders#' => 'http://orders-svc',
'#^/api/customers#' => 'http://customers-svc',
'#^/api/catalog#' => 'http://catalog-svc',
];
function resolveUpstream(string $path, array $routes): ?string {
foreach ($routes as $pattern => $upstream) {
if (preg_match($pattern, $path)) {
return $upstream . $path;
}
}
return null; // 404 at the gateway
}
echo resolveUpstream('/api/orders/42', $routes), "\n";Memusatkan Autentikasi
Validasi pemanggil sekali di gerbang, lalu teruskan identitas tepercaya ke layanan di belakangnya agar setiap layanan tidak perlu memverifikasi ulang token mentah. Gerbang memeriksa tanda tangan dan kedaluwarsa JWT, lalu menyisipkan tajuk seperti X-User-Id ke dalam permintaan internal (melalui jaringan tepercaya).
<?php
function authenticate(string $authHeader): ?array {
if (!str_starts_with($authHeader, 'Bearer ')) return null;
$jwt = substr($authHeader, 7);
$claims = verifyJwt($jwt); // signature + exp check
if ($claims === null) return null;
// Forward minimal trusted identity to internal services
return ['X-User-Id' => $claims['sub'], 'X-Scopes' => implode(',', $claims['scopes'])];
}
function verifyJwt(string $j): ?array { return ['sub' => 'u-7', 'scopes' => ['orders:read']]; }
print_r(authenticate('Bearer abc.def.ghi'));Agregasi Respons
Layar seluler mungkin memerlukan data pesanan, pelanggan, dan katalog. Alih-alih membuat klien melakukan tiga panggilan, gerbang meneruskan permintaan ke beberapa layanan, menunggu, lalu menggabungkan hasilnya. Agar tetap cepat, lakukan panggilan ke layanan hulu secara bersamaan (janji Guzzle / curl_multi), bukan secara berurutan.
<?php
require 'vendor/autoload.php';
use GuzzleHttp\Client;
use GuzzleHttp\Promise\Utils;
$http = new Client(['timeout' => 2.0]);
$promises = [
'order' => $http->getAsync('http://orders-svc/orders/42'),
'customer' => $http->getAsync('http://customers-svc/customers/7'),
'catalog' => $http->getAsync('http://catalog-svc/items?order=42'),
];
$results = Utils::settle($promises)->wait(); // run in parallel
// merge the fulfilled bodies into one response for the clientLayanan Belakang untuk Antarmuka Depan
Satu gerbang umum sering kali tidak dapat melayani aplikasi web, aplikasi seluler, dan mitra dengan sama baiknya—masing-masing menginginkan agregasi dan bentuk muatan yang berbeda. Pola layanan belakang untuk antarmuka depan (BFF) memberikan setiap jenis klien gerbang tipisnya sendiri, yang disesuaikan dengan kebutuhannya, sementara layanan bersama tetap umum.
Dengan begitu, Anda terhindar dari gerbang serba bisa yang membengkak dan setiap tim klien dapat bekerja secara mandiri.
Masalah Penemuan Layanan
Dalam lingkungan yang dinamis, instans datang dan pergi, dan alamat IP-nya berubah. Menuliskan http://10.0.3.14:8080 secara langsung itu rapuh. Penemuan layanan menyimpan registri aktif tentang "instans sehat mana dari layanan X yang ada saat ini", sehingga pemanggil dapat mengubah nama logis menjadi alamat nyata saat melakukan panggilan.
Penemuan di Sisi Klien vs Sisi Server
Ada dua model:
- Sisi klien — pemanggil menanyakan registri (Consul, etcd) dan memilih instans sendiri, sekaligus melakukan penyeimbangan beban sendiri.
- Sisi server — pemanggil mengakses alamat virtual yang stabil (penyeimbang beban / Layanan Kubernetes) yang melakukan resolusi dan penyeimbangan untuknya.
Di Kubernetes, biasanya Anda mendapatkan penemuan di sisi server secara langsung: panggil http://customers-svc, lalu DNS klaster dan Layanan menangani sisanya. Di luar k8s, registri bergaya Consul umum digunakan.
Membuat Kueri ke Registri
Dengan penemuan di sisi klien, pemanggil PHP meminta instans sehat kepada registri lalu memilih salah satunya. Registri hanya mengembalikan instans yang lolos pemeriksaan kesehatan, sehingga simpul mati otomatis dikecualikan.
<?php
require 'vendor/autoload.php';
use GuzzleHttp\Client;
function discover(Client $http, string $service): string {
// Consul: only passing-health instances
$res = $http->get("http://consul:8500/v1/health/service/$service?passing=true");
$nodes = json_decode((string) $res->getBody(), true);
if (!$nodes) throw new \RuntimeException("No healthy $service");
$pick = $nodes[array_rand($nodes)]['Service']; // simple LB
return "http://{$pick['Address']}:{$pick['Port']}";
}Pemeriksaan Kesehatan & Pendaftaran
Penemuan hanya sebaik data kesehatannya. Setiap layanan menyediakan titik akhir /health yang memeriksa dependensi nyatanya (basis data, tembolok), lalu mendaftarkan dirinya sendiri (atau didaftarkan oleh platform) saat dimulai. Registri memeriksa titik akhir tersebut dan menghapus instans yang gagal.
Pastikan pemeriksaan kesehatan benar-benar bermakna: mengembalikan 200 saat basis data sedang tidak berfungsi lebih buruk daripada tidak berguna—tindakan itu mengarahkan lalu lintas ke simpul yang rusak.
<?php
// GET /health
function health(PDO $db, Redis $cache): array {
$checks = [
'db' => safe(fn() => $db->query('SELECT 1') !== false),
'cache' => safe(fn() => $cache->ping() === '+PONG'),
];
$ok = !in_array(false, $checks, true);
http_response_code($ok ? 200 : 503);
return ['status' => $ok ? 'pass' : 'fail', 'checks' => $checks];
}
function safe(callable $c): bool { try { return (bool) $c(); } catch (\Throwable) { return false; } }Keaktifan vs Kesiapan
Satu titik akhir kesehatan saja tidak cukup—bedakan dua pertanyaan:
- Keaktifan: "apakah prosesnya masih hidup?" Jika gagal, orkestrator memulai ulang kontainer. Buat pemeriksaan ini ringan dan bebas dependensi, atau basis data yang tidak stabil akan memicu mulai ulang yang sia-sia.
- Kesiapan: "apakah proses ini dapat melayani lalu lintas saat ini?" Jika gagal, lalu lintas ditahan, tetapi proses tetap berjalan (misalnya saat memanaskan tembolok atau basis data sementara tidak dapat dijangkau).
Mencampuradukkan keduanya menyebabkan pengulangan mulai ulang atau perutean ke simpul yang belum siap.
<?php
// GET /livez - is the process itself healthy? (no external deps)
function livez(): void { http_response_code(200); echo 'alive'; }
// GET /readyz - should we receive traffic? (checks dependencies)
function readyz(PDO $db): void {
try { $db->query('SELECT 1'); http_response_code(200); echo 'ready'; }
catch (\Throwable) { http_response_code(503); echo 'not ready'; }
}Pemeriksaan Singkat
Mengurangi perjalanan pulang-pergi klien.
Ringkasan
Perutean dan penemuan layanan:
- Gerbang API memusatkan perutean, autentikasi, pembatasan laju, TLS, dan agregasi.
- Agregasikan secara bersamaan; gunakan BFF saat kebutuhan klien berbeda.
- Penemuan layanan mengubah nama logis menjadi instans aktif dan sehat.
- Penemuan di sisi klien (menanyakan registri) vs di sisi server (LB stabil / Layanan k8s).
- Pemeriksaan kesehatan yang bermakna menjaga lalu lintas tetap menjauhi simpul yang rusak.
Berikutnya: menjaga semua panggilan ini tetap tangguh saat sebagian sistem pasti mengalami kegagalan.
Pertanyaan yang Sering Diajukan
Apakah pelajaran “Gerbang API dan Penemuan Layanan” gratis?
Ya — teks lengkap “Gerbang API 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 PHP Academy, upgrade ke CoddyKit PRO. Kursus PHP Academy mencakup 4 pelajaran total.
Apa yang akan aku pelajari di “Gerbang API dan Penemuan Layanan”?
Arahkan, gabungkan, dan temukan layanan secara dinamis. Kamu berlatih PHP Academy 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 PHP Academy?
Tidak diperlukan pengalaman sebelumnya. PHP Academy 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 3 dari 4.
Berapa lama pelajaran “Gerbang API 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 PHP Academy ini?
Ya. Setiap pelajaran PHP Academy 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
- Dari Monolit ke Layanan Mikro
- Komunikasi Layanan: REST dan gRPC
- Gerbang API dan Penemuan Layanan
- Ketahanan: Pemutus Sirkuit dan Percobaan Ulang