Müşterimiz de dahil olmak üzere bazı şirketler, ürünü bir ortak ağı aracılığıyla geliştirir. Örneğin, büyük çevrimiçi mağazalar teslimat hizmetiyle entegredir - bir ürün sipariş edersiniz ve kısa süre sonra paket için bir takip numarası alırsınız. Başka bir örnek, uçak biletinizle birlikte sigorta veya Aeroexpress bileti satın almanızdır.
Bunun için, API Ağ Geçidi aracılığıyla ortaklara verilmesi gereken bir API kullanılır. Bu sorunu çözdük. Bu yazımızda size detayları anlatacağız.
Verilen: kullanıcıların kayıtlı olduğu, bilgi aldığı vb. bir arayüze sahip bir ekosistem ve bir API portalı. Kullanışlı ve güvenilir bir API Ağ Geçidi yapmamız gerekiyor. Bu süreçte sağlamamız gereken
- kayıt,
- API bağlantı kontrolü,
- Kullanıcıların uç sistemi nasıl kullandığını izlemek,
- iş göstergelerinin muhasebesi.
Makalede, aşağıdaki görevleri çözdüğümüz API Ağ Geçidi oluşturma deneyimimizden bahsedeceğiz:
- Kullanıcı doğrulama,
- kullanıcı yetkilendirme,
- orijinal talebin değiştirilmesi,
- proxy isteğinde bulunma,
- yanıt sonrası işleme.
İki tür API yönetimi vardır:
1. Aşağıdaki gibi çalışan standart. Kullanıcı bağlanmadan önce özellikleri test eder, ardından ödeme yapar ve sitesine yerleştirir. Çoğu zaman küçük ve orta ölçekli işletmelerde kullanılırlar.
2. Büyük B2B API Yönetimi, şirket ilk önce bağlanmak için bir iş kararı verdiğinde, sözleşmeden doğan bir yükümlülükle şirketin ortağı olur ve ardından API'ye bağlanır. Ve tüm formaliteler tamamlandıktan sonra şirket test erişimi alır, testleri geçer ve üretime geçer. Ancak bu, bağlanmak için bir yönetim kararı olmadan mümkün değildir.
Bizim çözümümüz
Bu bölümde API Gateway oluşturma hakkında konuşacağız.
Oluşturulan API ağ geçidinin son kullanıcıları, müşterimizin iş ortaklarıdır. Her biri için zaten gerekli sözleşmelerimiz var. Yalnızca ağ geçidine verilen erişimi işaretleyerek işlevselliği genişletmemiz gerekecek. Buna göre kontrollü bir bağlantı ve yönetim sürecine ihtiyaç duyulmaktadır.
Tabii ki, API Yönetimi sorununu çözmek ve özellikle bir API Ağ Geçidi oluşturmak için bazı hazır çözümler almak mümkündü. Örneğin, bu olabilir. Bize uygun değildi çünkü bizim durumumuzda zaten bir API portalımız ve onun etrafında inşa edilmiş devasa bir ekosistemimiz vardı. Tüm kullanıcılar zaten kayıtlıdır, gerekli bilgileri nereden ve nasıl alabileceklerini zaten anlamışlardır. Gerekli arayüzler zaten API portalında mevcuttu, sadece API Gateway'e ihtiyacımız vardı. Aslında, onun gelişimi ile ilgileniyoruz.
API Ağ Geçidi dediğimiz şey bir tür proxy'dir. Burada yine bir seçeneğimiz vardı - kendi proxy'nizi yazabilir veya hazır bir şey seçebilirsiniz. Bu durumda ikinci yola gittik ve nginx + Lua paketini seçtik. Neden? Ölçeklendirmeyi destekleyen güvenilir, test edilmiş bir yazılıma ihtiyacımız vardı. Uygulamadan sonra hem iş mantığının doğruluğunu hem de proxy'nin doğruluğunu kontrol etmek istemedik.
Her web sunucusunun bir istek işleme boru hattı vardır. Nginx durumunda, şöyle görünür:
(diyagramdan )
Amacımız, orijinal isteği değiştirebileceğimiz bir noktada bu ardışık düzene uymaktı.
İsteğin işlevsel olarak geldiği gibi kalması için şeffaf bir proxy oluşturmak istiyoruz. Yalnızca nihai API'ye erişimi kontrol ediyoruz, isteğin ona ulaşmasına yardımcı oluyoruz. İsteğin yanlış olması durumunda, nihai API hatayı göstermeli, bize göstermemelidir. Bir isteği reddedebilmemizin tek nedeni, istemcinin erişiminin olmamasıdır.
nginx için zaten var üzerinde . Lua bir betik dilidir, çok hafiftir ve öğrenmesi kolaydır. Böylece gerekli mantığı Lua kullanarak hayata geçirdik.
Tüm işin yapıldığı nginx konfigürasyonu (uygulamanın rotasına bir benzetme) oldukça anlaşılır. Burada dikkate değer olan son direktiftir - post_action.
location /middleware {
more_clear_input_headers Accept-Encoding;
lua_need_request_body on;
rewrite_by_lua_file 'middleware/rewrite.lua';
access_by_lua_file 'middleware/access.lua';
proxy_pass https://someurl.com;
body_filter_by_lua_file 'middleware/body_filter.lua';
post_action /process_session;
}
Bu yapılandırmada ne olduğunu düşünün:
more_clear_input_headers — direktiften sonra belirtilen başlıkların değerini siler.
lua_need_request_body - rewrite/access/access_by_lua yönergeleri yürütülmeden önce orijinal istek gövdesinin okunup okunmayacağını kontrol eder. Varsayılan olarak, nginx bir müşteri isteğinin gövdesini okumaz ve ona erişmeniz gerekirse, bu yönerge açık olarak ayarlanmalıdır.
yeniden yaz_by_lua_file - isteği değiştirme mantığını açıklayan betiğin yolu
erişim_by_lua_file — kaynağa erişimi kontrol eden mantığı açıklayan betiğin yolu.
proxy_pass — isteğin vekil olarak gönderileceği url.
body_filter_by_lua_file — isteği istemciye döndürmeden önce filtreleme mantığını açıklayan betiğin yolu.
Ve nihayet, post_action - müşteriye yanıt verildikten sonra başka eylemler gerçekleştirebileceğiniz resmi olarak belgelenmemiş bir yönerge.
Ardından, sorunlarımızı nasıl çözdüğümüzü sırayla açıklayacağız.
Yetkilendirme/doğrulama ve değişiklik isteği
Yetki
Sertifika erişimini kullanarak yetkilendirme ve kimlik doğrulama oluşturduk. Bir kök sertifikası var. Müşterinin her yeni müşterisi, API'ye erişebileceği kendi kişisel sertifikasını oluşturur. Bu sertifika, nginx ayarlarının sunucu bölümünde yapılandırılır.
ssl on;
ssl_certificate /usr/local/openresty/nginx/ssl/cert.pem;
ssl_certificate_key /usr/local/openresty/nginx/ssl/cert.pem;
ssl_client_certificate /usr/local/openresty/nginx/ssl/ca.crt;
ssl_verify_client on;Değişiklik
Adil bir soru ortaya çıkabilir: Sertifikalı bir müşteriyi aniden sistemden ayırmak istersek ne yapmalıyız? Diğer tüm istemciler için sertifikaları yeniden yayınlamayın.
Bu nedenle, bir sonraki göreve sorunsuz bir şekilde yaklaştık - orijinal isteği değiştirerek. Müşterinin ilk talebi, genel olarak nihai sistem için geçerli değildir. Görevlerden biri, talebin geçerli olması için eksik kısımları talebe eklemektir. Önemli olan, eksik verilerin her müşteri için farklı olmasıdır. Bir müşterinin bize parmak izini alabileceğimiz ve gerekli müşteri verilerini veritabanından çıkarabileceğimiz bir sertifikayla geldiğini biliyoruz.
Bir noktada müşterinin hizmetimizle bağlantısını kesmeniz gerekirse, müşterisinin verileri veritabanından kaybolacak ve müşteri hiçbir şey yapamayacak.
Müşteri verileriyle çalışma
Çözümü, özellikle müşteri verilerini nasıl elde ettiğimizi, yüksek düzeyde kullanılabilir hale getirmemiz gerekiyordu. Zorluk, bu verilerin birincil kaynağının, kesintisiz ve yeterince yüksek hızı garanti etmeyen bir üçüncü taraf hizmeti olmasıdır.
Bu nedenle, müşteri verilerinin yüksek kullanılabilirliğini sağlamamız gerekiyordu. Araç olarak seçtik bize sağlayan:
- verilere hızlı erişim
- farklı düğümlerde çoğaltılan verilerle birkaç düğümden oluşan bir küme düzenleme yeteneği.
Verileri önbelleğe teslim etmek için en basit stratejiyle gittik:
Uç sistemle çalışma oturumlar içinde gerçekleşir ve maksimum sayıda bir sınır vardır. Müşteri oturumu kapatmadıysa, bunu yapmak zorunda kalacağız.
Açık oturum verileri uç sistemden gelir ve başlangıçta Lua tarafında işlenir. Bu verileri bir .NET işiyle depolamak için Hazelcast'i kullanmaya karar verdik. Daha sonra belirli aralıklarla açık oturumların yaşam hakkını kontrol edip çürük olanları kapatıyoruz.
Hazelcast'e hem Lua'dan hem de .NET'ten erişme
Hazelcast ile çalışacak Lua istemcisi yok, ancak Hazelcast'in kullanmaya karar verdiğimiz bir REST API'si var. .NET için var üzerinden Hazelcast verilerine .NET tarafında erişmeyi planladık. Ama orada değildi.
REST yoluyla veri depolarken ve bir .NET istemcisi aracılığıyla veri alırken, farklı seri hale getiriciler ve seri hale getiriciler kullanılır. Bu nedenle, verileri REST aracılığıyla koymak, ancak .NET istemcisi aracılığıyla almak veya tersi imkansızdır.
İlgilenen varsa, size bu sorun hakkında daha fazla bilgiyi ayrı bir makalede anlatacağız. Spoiler - şemada.
Günlüğe kaydetme ve izleme
.NET üzerinden oturum açmak için kurumsal standardımız Serilog'tur, tüm günlükler Elasticsearch'te son bulur ve bunları Kibana aracılığıyla analiz ederiz. Bu durumda ben de benzer bir şey yapmak istiyorum. Tek bir Bulunan Lua üzerinde Elastic ile çalışmak, ilk ihtiyaçta bozuldu. Ve Fluentd'i kullandık.
- tek bir uygulama günlüğü katmanı sağlamak için açık kaynak çözümü. Uygulamanın farklı katmanlarından günlükleri toplamanıza ve ardından bunları tek bir kaynakta yayınlamanıza olanak tanır.
API Ağ Geçidi K8S'de çalışır, bu nedenle mevcut açık tcp bağlantı noktası fluentd'ye günlük yazmak için fluentd içeren bir kapsayıcıyı aynı bölmeye eklemeye karar verdik.
Ayrıca, Fluentd'in Elasticsearch ile bağlantısı olmasaydı nasıl davranacağını da araştırdık. İki gün boyunca ağ geçidine sürekli istekler gönderildi, fluentd'ye loglar gönderildi ancak fluentd, IP Elastic'ten yasaklandı. Bağlantı geri yüklendikten sonra fluentd, Elastic'teki tüm günlükleri mükemmel bir şekilde devraldı.
Sonuç
Uygulamaya yönelik seçilen yaklaşım, gerçekten çalışan bir ürünü savaş ortamına yalnızca 2.5 ayda teslim etmemizi sağladı.
Bir gün böyle şeyler yaparsanız, öncelikle hangi sorunu çözdüğünüzü ve hangi kaynaklara sahip olduğunuzu net bir şekilde anlamanızı tavsiye ederiz. Mevcut API yönetim sistemleriyle entegrasyonun karmaşıklığının farkında olun.
Tam olarak neyi geliştireceğinizi kendiniz anlayın - yalnızca istekleri işlemek için iş mantığı veya bizim durumumuzda olabileceği gibi, proxy'nin tamamı. Kendi yaptığınız her şeyin daha sonra kapsamlı bir şekilde test edilmesi gerektiğini unutmayın.
Kaynak: habr.com
