Platform mimarisi7 dk okuma

API ağ geçitleri ve olay güdümlü mimari

API ağ geçitleri ve olaylar rakip değildir; biri soruyu anında yanıtlar, diğeri az önce ne olduğunu herkese bildirir.

Onlarca sisteme sahip kurumlar genellikle noktadan noktaya bağlantılardan oluşan bir karmaşayla karşı karşıyadır: her sistem, her biri kendi protokolü ve sözleşmesine sahip birkaç başka sistemle doğrudan konuşur. Sonuç olarak bir sistemi değiştirmek birkaç başkasını bozar ve mobil uygulama gibi yeni bir kanal eklemek aylarca entegrasyon çalışması gerektirir. Bir ekip bir müşterinin son işleminin ne olduğunu öğrenmek istediğinde üç sisteme sormak ve yanıtları elle birleştirmek zorundadır. Entegrasyon katmanı, fiilen tüm sistemlere görünmez biçimde dağılmıştır ve kimseye ait değildir.

Bu önemlidir, çünkü bir kurumun dijital dönüşüm hızı doğrudan entegrasyon hızına bağlıdır. Her yeni ürün merkezi sistemlere yeniden bağlanmayı gerektiriyorsa, yeni fikirleri test etmenin maliyeti caydırıcı hâle gelir. Her doğrudan bağlantı aynı zamanda denetimsiz bir güvenlik noktasıdır: kim, hangi yetkiyle, hangi sıklıkta çağırıyor? Ortak bir katman olmadan bu sorular her bağlantı için ayrı ayrı yanıtlanır; bu da pratikte hiç kimsenin yanıtın tamamına sahip olmadığı anlamına gelir.

Tercih edilen mimari, birbirini tamamlayan iki kalıbı yan yana koyar. API ağ geçidi senkron etkileşimler için tek giriş noktasıdır: bir tüketici talep gönderir ve yanıtı aynı anda alır. Ağ geçidi kimlik doğrulama, yetkilendirme, hız sınırlama, sürümleme ve gözlemlenebilirliği tek tip biçimde uygular. Olay güdümlü mimari ise asenkron etkileşimlere hizmet eder: hesap açılışı veya adres değişikliği gibi bir şey olduğunda kaynak sistem bir olay yayımlar ve ilgilenen her sistem onu tüketir; kaynağın tüketicilerin kim olduğunu bilmesine gerek yoktur. Aradaki kalıcı bir mesaj kuyruğu hiçbir olayın kaybolmamasını garanti eder.

İlk pratik husus sözleşme tasarımıdır. API'ler ve olaylar birer sözleşmedir ve öyle ele alınmalıdır: açık bir şema, açık sürümleme ve uyumlu ile uyumsuz değişiklikler için net bir kural ile. Örneğin, bir müşteri güncellendi olayına isteğe bağlı bir alan eklemek uyumlu bir değişikliktir; ancak mevcut bir alanın tipini değiştirmek, bir geçiş dönemi boyunca eskisiyle birlikte yayımlanan yeni bir sürüm gerektirir. Merkezi bir şema kayıt defteri, ekiplerin bir kırılmayı üretimde keşfetmek yerine devreye almadan önce uyumluluğu otomatik olarak kontrol etmesini sağlar.

İkinci husus senkron ve asenkron arasında doğru seçim yapmaktır. Temel kural şudur: tüketicinin kendi işine devam etmek için yanıta hemen ihtiyacı varsa API kullanın; yalnızca bir şeyin olduğunu bilmesi gerekiyorsa olay kullanın. Bakiye sorgusu senkrondur. Bir işlemi kara para aklamayla mücadele sistemine bildirmek asenkrondur. Kurumlardaki birçok performans ve bağımlılık sorunu, senkron çağrılar olarak uygulanan asenkron etkileşimlerden kaynaklanır; bu durumda tek bir yavaş sistem tüm zinciri yavaşlatır.

Üçüncü husus uçtan uca gözlemlenebilirliktir. Bir talep ağ geçidinden girip birkaç hizmetten geçtiğinde ve birkaç olay ürettiğinde, ekip tüm yolu tek bir korelasyon tanımlayıcısıyla izleyebilmelidir. Bu tanımlayıcı hem API başlıklarında hem de olay üst verilerinde taşınmalıdır. O olmadan bir sorunu ayıklamak, birkaç sistemin kayıtlarında zaman damgalarını elle eşleştirmeye dönüşür; bu da yoğun saatlerde pratikte imkânsızdır.

Yaygın tuzaklar birkaç grupta toplanır. Birincisi, API ağ geçidini iş mantığının yuvasına dönüştürmek; ağ geçidi iş kararları vermemeli, politika uygulamalıdır. İkincisi, kaydın tamamını taşıyıp tüketicileri kaynağın iç yapısına bağlayan şişkin olaylar ya da yalnızca bir tanımlayıcı taşıyıp herkesi geri çağrı yapmaya zorlayan zayıf olaylar. Üçüncüsü, sıralamayı ve mükerrerliği göz ardı etmek; bir tüketici tekrarlanan bir olayı tanıyabilmeli ve sırası bozuk gelen bir olayı ele alabilmelidir. Dördüncüsü, entegrasyon katmanının bir sahibinin olmaması; bu, katmanı sessizce önceki durumuna döndürür.

Niadad'da bu üçlü, birbirini tamamlayan üç platform olarak uygulanır. Sepehr («سپهر») kurumsal API ağ geçididir: tüm senkron etkileşimler için kimlik doğrulama, yetkilendirme, hız sınırlama, sürümleme ve gözlemlenebilirlik. Jarian («جریان») olay platformudur: saklanan geçmişle birlikte yayımlama, abonelik ve olay şemaları. Payam («پیام») ise asenkron işler için garantili teslimat ve hata yönetimi sağlayan kalıcı mesaj kuyruğudur. Niadad'ın bankacılık programında bu üçü entegrasyonun omurgasını oluşturur ve kimlik, taraf ve veri katmanlarına bağlanır.

API ağ geçidi ve olay güdümlü mimari, iki farklı soruya verilen iki yanıttır ve olgun bir kurumda ikisi de bulunur. Onları tek bir altyapıya dönüştüren şey açık sözleşmeler, ortak kimlik ve uçtan uca gözlemlenebilirliktir. Bu üçü yerinde olduğunda yeni bir kanal veya sistem eklemek aylar süren bir projeden birkaç günlük bir işe dönüşür. Bir entegrasyon katmanının gerçek ölçüsü budur: diyagramının ne kadar zarif göründüğü değil, bir sonraki değişikliğin önünde ne kadar az engel oluşturduğu.

Birlikte inşa edelim.

Kurumunuz, bankanız veya sektörünüz veriyi karara dönüştürmeye hazırsa, görüşmeye buradan başlayın.