API Ağ Geçitleri ve Hizmet Keşfi
Hizmetleri dinamik olarak yönlendirin, birleştirin ve bulun.
API Ağ Geçitleri ve Hizmet Keşfi, CoddyKit'te ücretsiz bir PHP Academy dersidir. Bu, 4 dersinin 3. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, PHP Academy öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. PHP Academy kursu toplamda 4 dersten oluşur.
Ağ Geçitleri ve Keşif
Bir düzine hizmete ulaştığınızda iki sorun ortaya çıkar. İstemcilerin her hizmetin adresini bilmesi veya tek bir ekranı oluşturmak için beş hizmeti çağırması gerekmemelidir; bu, API ağ geçidinin işidir. Ölçeği artıp azalan ve IP adresleri değişen hizmetlerin de birbirlerini bulabilmesi gerekir; bu da hizmet keşfi ile sağlanır.
Bu derste her iki konuyu da ağ geçidi katmanında PHP kullanarak ele alacağız.
API Ağ Geçidi Ne Yapar
API ağ geçidi, hizmetlerinizin önünde bulunan tek bir giriş noktasıdır. Tipik sorumlulukları şunlardır:
- İstekleri doğru arka uca yönlendirme.
- Ortak konular: kimlik doğrulama, hız sınırlama, CORS, TLS sonlandırma.
- Birleştirme: birkaç arka uç çağrısını tek bir istemci yanıtında birleştirme.
- Protokol dönüşümü: dışarıdan REST, içeride gRPC.
İstemcileri basit tutar ve aksi hâlde her hizmette tekrarlayacağınız politikaları merkezileştirir.
Uçta Yönlendirme
Temelde bir ağ geçidi, gelen bir yolu bir üst akış hizmetiyle eşleştirir. Üretim ağ geçitleri (Kong, Traefik, Nginx, AWS API Gateway) bunu bildirimsel olarak yapar; ancak mantık PHP ile açıklanabilecek kadar basittir.
<?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";Kimlik Doğrulamayı Merkezileştirme
Çağrıyı yapanı ağ geçidinde bir kez doğrulayın, ardından her hizmetin ham belirteci yeniden doğrulamasını önlemek için güvenilir kimliği alt hizmetlere iletin. Ağ geçidi JWT imzasını ve sona erme süresini denetler, ardından güvenilir bir ağ üzerinden gerçekleştirilen iç isteğe X-User-Id gibi üst bilgiler ekler.
<?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'));Yanıtları Birleştirme
Bir mobil ekranın sipariş, müşteri ve katalog verilerine ihtiyacı olabilir. İstemcinin üç çağrı yapmasını beklemek yerine ağ geçidi çağrıları farklı hizmetlere dağıtır, bekler ve sonuçları birleştirir. Bunu hızlı tutmak için üst akış çağrılarını ardışık olarak değil, eş zamanlı olarak yapın (Guzzle vaatleri / curl_multi).
<?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 clientÖn Uçlar için Arka Uçlar
Tek bir genel ağ geçidi çoğu zaman bir web uygulamasına, mobil uygulamaya ve iş ortaklarına aynı ölçüde iyi hizmet veremez; her biri farklı birleştirmeler ve yük biçimleri ister. Ön Uç için Arka Uç (BFF) kalıbı, her istemci türüne ihtiyaçlarına göre uyarlanmış, kendine ait ince bir ağ geçidi verirken ortak hizmetleri genel tutar.
Bu yaklaşım, aşırı büyümüş tek bir ağ geçidini önler ve her istemci ekibinin bağımsız ilerlemesini sağlar.
Keşif Sorunu
Dinamik bir ortamda örnekler oluşturulur ve kaldırılır, IP adresleri değişir. http://10.0.3.14:8080 adresini doğrudan koda yazmak güvenilmezdir. Hizmet keşfi, çağrıyı yapanların mantıksal bir adı çağrı sırasında gerçek bir adrese çözümleyebilmesi için "X hizmetinin şu anda hangi sağlıklı örnekleri var?" sorusunun canlı bir kayıt defterini tutar.
İstemci Taraflı ve Sunucu Taraflı Keşif
İki model vardır:
- İstemci taraflı — çağrıyı yapan, bir kayıt defterini (Consul, etcd) sorgular, bir örneği kendisi seçer ve kendi yük dengelemesini yapar.
- Sunucu taraflı — çağrıyı yapan, kendisi için çözümleme ve yük dengelemesi yapan sabit bir sanal adrese (yük dengeleyici / Kubernetes Service) gider.
Kubernetes'te genellikle sunucu taraflı keşfi hazır olarak elde edersiniz: http://customers-svc adresini çağırın; küme DNS'i ve Service geri kalanını halleder. Kubernetes dışındaki ortamlarda Consul tarzı kayıt defterleri yaygındır.
Kayıt Defterini Sorgulama
İstemci taraflı keşifte PHP çağrıyı yapanı, sağlıklı örnekleri öğrenmek için kayıt defterine sorar ve birini seçer. Kayıt defteri yalnızca sağlık denetimlerinden geçen örnekleri döndürür; böylece çalışmayan düğümler otomatik olarak dışarıda bırakılır.
<?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']}";
}Sağlık Denetimleri ve Kayıt
Keşfin kalitesi, sağlık verilerinin kalitesiyle sınırlıdır. Her hizmet, gerçek bağımlılıklarını (veritabanı, önbellek) denetleyen bir /health uç noktası sunar ve başlangıçta kendisini kaydeder (veya platform tarafından kaydedilir). Kayıt defteri bu uç noktayı denetler ve başarısız olan örnekleri çıkarır.
Sağlık denetimini anlamlı hâle getirin: veritabanı çalışmıyorken 200 döndürmek yararsız olmaktan da kötüdür; trafiği bozuk bir düğüme yönlendirir.
<?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; } }Canlılık ve Hazır Olma
Tek bir sağlık uç noktası yeterli değildir; iki soruyu birbirinden ayırın:
- Canlılık: "süreç çalışıyor mu?" Başarısız olursa düzenleyici kapsayıcıyı yeniden başlatır. Denetimi ucuz ve bağımlılıklardan bağımsız tutun; aksi hâlde kararsız bir veritabanı gereksiz yeniden başlatmaları tetikler.
- Hazır olma: "şu anda trafiğe hizmet verebilir mi?" Başarısız olursa trafik tutulur, ancak süreç çalışmaya devam eder (örneğin önbellek ısıtılırken veya veritabanına geçici olarak ulaşılamazken).
Bu ikisini birbirine karıştırmak, yeniden başlatma döngülerine veya henüz hazır olmayan düğümlere yönlendirmeye neden olur.
<?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'; }
}Hızlı Denetim
İstemcinin gidiş-dönüş sayısını azaltma.
Özet
Hizmetleri yönlendirme ve bulma:
- API ağ geçidi, yönlendirmeyi, kimlik doğrulamayı, hız sınırlamayı, TLS'i ve birleştirmeyi merkezileştirir.
- Eş zamanlı birleştirme yapın; istemcilerin ihtiyaçları ayrıştığında BFF'ler kullanın.
- Hizmet keşfi, mantıksal adları canlı ve sağlıklı örneklere çözümler.
- İstemci taraflı (kayıt defterini sorgulayan) ve sunucu taraflı (sabit LB / Kubernetes Service) keşif.
- Anlamlı sağlık denetimleri, trafiği bozuk düğümlerden uzak tutar.
Sıradaki konu: parçalar kaçınılmaz olarak başarısız olduğunda tüm bu çağrıları dayanıklı tutmak.
Sıkça Sorulan Sorular
“API Ağ Geçitleri ve Hizmet Keşfi” dersi ücretsiz mi?
Evet — “API Ağ Geçitleri ve Hizmet Keşfi” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve PHP Academy kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. PHP Academy kursu toplamda 4 dersten oluşur.
“API Ağ Geçitleri ve Hizmet Keşfi” dersinde ne öğreneceğim?
Hizmetleri dinamik olarak yönlendirin, birleştirin ve bulun. PHP Academy ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.
PHP Academy öğrenmeye başlamak için deneyim gerekli mi?
Önceden deneyim gerekmez. CoddyKit'te PHP Academy, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 3. dersidir.
“API Ağ Geçitleri ve Hizmet Keşfi” dersi ne kadar sürer?
Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.
Bu PHP Academy dersinde kod yazıp çalıştırabilir miyim?
Evet. Her PHP Academy dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.
Bu kursun tüm dersleri
- Monolitten Mikro Hizmetlere
- Hizmet İletişimi: REST ve gRPC
- API Ağ Geçitleri ve Hizmet Keşfi
- Dayanıklılık: Devre Kesiciler ve Yeniden Denemeler