API ağ geçidi ve ters proxy

Mikro hizmet mimarisi ile başa çıkmak için, genellikle bir Reverse Proxy (nginx veya apache httpd gibi) ile birlikte kullanılır ve çapraz kesme endişeleri için uygulama API ağ geçidi modeli kullanılır . Bazen Reverse proxy, API ağ geçidinin işini yapar.
Bu iki yaklaşım arasında net farklılıklar görmek iyi olacaktır. Görünüşe göre API ağ geçidi kullanımının potansiyel faydası, birden çok mikro hizmeti çağırmak ve sonuçları toplamaktır. API ağ geçidinin diğer tüm sorumlulukları Reverse Proxy kullanılarak uygulanabilir.

• Kimlik doğrulama (nginx LUA betikleri kullanılarak yapılabilir);
• Nakliye güvenliği. Reverse Proxy görevinin kendisi;
• Yük dengeleme
• ....

Buna dayanarak birkaç soru var:

1. API ağ geçidini ve Reverse proxy'yi aynı anda kullanmak mantıklı mı (örneğin request-> Api gateway-> reverse proxy (nginx) -> somut mikro hizmet)? Hangi durumlarda?
2. API ağ geçidi kullanılarak uygulanabilen ve Reverse proxy tarafından uygulanamayan ve tersi diğer farklılıklar nelerdir?

Birbirlerini dışlamadıklarını fark ederseniz, onlar hakkında düşünmek daha kolaydır. Bir API ağ geçidini belirli bir ters proxy uygulaması olarak düşünün.

Sorularınızla ilgili olarak, API ağ geçidinin yük dengeleme ve durum denetimi için ters bir proxy'nin arkasında oturan bir uygulama katmanı olarak değerlendirildiği durumlarda her ikisinin birlikte kullanılması alışılmadık bir durum değildir. Bir örnek, Web Uygulama Güvenlik Duvarı / API Ağ Geçidinizin biri WAF'ın kendisi ve diğeri de konuştuğu bireysel mikro hizmetler için ters proxy katmanları tarafından sıkıştırılmış olması bakımından WAF sandviç mimarisi gibi bir şey olabilir.

Farklılıklar konusunda çok benzerler. Bu sadece isimlendirme. Temel bir ters proxy kurulumunu alıp kimlik doğrulama, hız sınırlama, dinamik yapılandırma güncellemeleri ve hizmet keşfi gibi daha fazla parçaya geçmeye başladığınızda, insanların buna API ağ geçidini çağırma olasılığı daha yüksektir.

API Ağ Geçidinin, API aracılığıyla ve potansiyel olarak UI aracılığıyla dinamik olarak yapılandırılabilen bir ters proxy olduğuna inanıyorum; geleneksel ters proxy (Nginx, HAProxy veya Apache gibi) yapılandırma dosyası aracılığıyla yapılandırılır ve yapılandırma değiştiğinde yeniden başlatılması gerekir. Bu nedenle, yönlendirme kuralları veya diğer yapılandırma sıklıkla değiştiğinde API Ağ Geçidi kullanılmalıdır. Sorularınıza:

1. Bu dizideki her bileşen amacına hizmet ettiği sürece mantıklıdır.
2. Farklılıklar özellik listesinde değil, yapılandırma değişikliklerinin uygulanma biçimindedir.

Buna ek olarak, ağ geçidi API genellikle olduğu gibi, SAAS formunda sağlanır Apigee veya tık örneğin.

Ayrıca, Node.js ile basit bir API Ağ Geçidi oluşturmayla ilgili öğreticim https://memz.co/api-gateway-microservices-docker-node-js/

Umarım yardımcı olur.

API Ağ geçitleri genellikle bir L7 yapısı olarak çalışır.

API Ağ Geçitleri, düz bir ters proxy'ye kıyasla ek işlevsellik sağlar. Bazı portalların size sağlayabileceğini düşünürseniz:

• belgeler dahil tam API Yaşam Döngüsü Yönetimi
• Çeşitli müşteri uygulamaları için doğruluk kaynağı olarak kullanılabilen ve müşteri yönetişimi, oran sınırlaması vb. sağlayabileceğiniz bir portal.
• canary / beta sürümleri dahil olmak üzere farklı API sürümlerine yönlendirme
• kullanım modellerini algılama, uygulamaları kaydetme, müşteri kimlik bilgilerini alma vb.

Bununla birlikte, Istio gibi hizmet ağlarının ortaya çıkmasıyla, Consul, API Ağ Geçitlerinin birçok işlevselliği ağlar tarafından kapsanacaktır.