Mikro hizmetler mimarisinde bir istemci birden fazla ön uç hizmetiyle etkileşimde olabilir. Bu olgu göz önüne alındığında, bir istemci hangi uç noktaların çağrıldığını nasıl bilir? Yeni hizmetler sunulduğunda veya mevcut hizmetler yeniden düzenlendiğinde ne olur? Hizmetler SSL sonlandırma, kimlik doğrulaması ve diğer endişeleri nasıl işler? API ağ geçidi bu zorlukların giderilmesine yardımcı olabilir.
Bu mimarinin bir Visio dosyasını indirin.
API ağ geçidi nedir?
API ağ geçidi, istemciler ve hizmetler arasında yer alır. İstemcilerden gelen istekleri hizmetlere yönlendiren ters proxy işlevi görür. Ayrıca kimlik doğrulaması, SSL sonlandırma ve hız sınırlama gibi çeşitli çapraz kesme görevleri de gerçekleştirebilir. Ağ geçidi dağıtmazsanız istemcilerin doğrudan ön uç hizmetlerine istek göndermesi gerekir. Ancak, hizmetleri doğrudan istemcilere sunmayla ilgili bazı olası sorunlar vardır:
- Karmaşık istemci koduna neden olabilir. İstemcinin birden çok uç noktayı izlemesi ve hataları dayanıklı bir şekilde işlemesi gerekir.
- İstemci ile arka uç arasında bağlantı oluşturur. İstemcinin tek tek hizmetlerin nasıl ayrıştırılmış olduğunu bilmesi gerekir. Bu, istemciyi korumayı ve hizmetleri yeniden düzenlemeyi de zorlaştırır.
- Tek bir işlem için birden çok hizmete çağrı yapılması gerekebilir. Bu, istemci ile sunucu arasında birden çok ağ gidiş dönüşlerine neden olarak önemli gecikme süresine neden olabilir.
- Genel kullanıma yönelik her hizmetin kimlik doğrulaması, SSL ve istemci hızı sınırlaması gibi endişeleri işlemesi gerekir.
- Hizmetler HTTP veya WebSocket gibi istemci dostu bir protokolü kullanıma sunmalıdır. Bu, iletişim protokollerinin seçimini sınırlar.
- Genel uç noktaları olan hizmetler olası bir saldırı yüzeyidir ve sağlamlaştırılmalıdır.
Ağ geçidi, istemcileri hizmetlerden ayrıştırarak bu sorunları gidermeye yardımcı olur. Ağ geçitleri bir dizi farklı işlev gerçekleştirebilir ve bunların tümüne ihtiyacınız olmayabilir. İşlevler aşağıdaki tasarım desenleri halinde gruplandırılabilir:
Ağ Geçidi Yönlendirme. 7. katman yönlendirmesini kullanarak istekleri bir veya daha fazla arka uç hizmetine yönlendirmek için ağ geçidini ters ara sunucu olarak kullanın. Ağ geçidi, istemciler için tek bir uç nokta sağlar ve istemcileri hizmetlerden ayırmaya yardımcı olur.
Ağ Geçidi Toplama. Tek tek birden çok isteği tek bir istekte toplamak için ağ geçidini kullanın. Bu düzen, tek bir işlem birden çok arka uç hizmetine çağrı gerektirdiğinde geçerlidir. İstemci ağ geçidine bir istek gönderir. Ağ geçidi, istekleri çeşitli arka uç hizmetlerine gönderir ve ardından sonuçları toplar ve istemciye geri gönderir. Bu, istemci ile arka uç arasındaki sohbeti azaltmaya yardımcı olur.
Ağ Geçidi Boşaltma. İşlevselliği tek tek hizmetlerden ağ geçidine boşaltmak için ağ geçidini kullanın, özellikle de çapraz kesme endişeleri. Bu işlevlerin uygulanmasından sorumlu her hizmeti yapmak yerine tek bir yerde birleştirmek yararlı olabilir. Bu, özellikle kimlik doğrulaması ve yetkilendirme gibi özel becerilerin doğru şekilde uygulanması gereken özellikler için geçerlidir.
Aşağıda bir ağ geçidine yüklenecek işlevlere bazı örnekler verilmiştir:
- SSL sonlandırma
- Kimlik Doğrulaması
- IP izin verilenler listesi veya blok listesi
- İstemci hızı sınırlama (azaltma)
- Günlüğe kaydetme ve izleme
- Yanıtları Önbelleğe Alma
- Web uygulaması güvenlik duvarı
- GZIP sıkıştırması
- Statik içeriğe hizmet verme
Ağ geçidi teknolojisi seçme
Uygulamanıza API ağ geçidi uygulamak için bazı seçenekler aşağıda verilmiştır.
Ters proxy sunucusu. Nginx ve HAProxy, yük dengeleme, SSL ve katman 7 yönlendirme gibi özellikleri destekleyen popüler ters proxy sunucularıdır. Her ikisi de ek özellikler ve destek seçenekleri sağlayan ücretli sürümlere sahip ücretsiz, açık kaynak ürünlerdir. Nginx ve HAProxy hem zengin özellik kümelerine hem de yüksek performansa sahip olgun ürünlerdir. Bunları üçüncü taraf modüllerle veya Lua'da özel betikler yazarak genişletebilirsiniz. Nginx, NGINX JavaScript olarak adlandırılan JavaScript tabanlı betik modülünü de destekler. Bu modül resmi olarak nginScript olarak adlandırıldı.
Hizmet ağı giriş denetleyicisi. Linkerd veya Istio gibi bir hizmet ağı kullanıyorsanız, söz konusu hizmet ağı için giriş denetleyicisi tarafından sağlanan özellikleri göz önünde bulundurun. Örneğin, Istio giriş denetleyicisi katman 7 yönlendirmeyi, HTTP yönlendirmelerini, yeniden denemeleri ve diğer özellikleri destekler.
Azure Uygulaması Lication Gateway. Application Gateway, katman 7 yönlendirme ve SSL sonlandırma gerçekleştirebilen yönetilen bir yük dengeleme hizmetidir. Ayrıca bir web uygulaması güvenlik duvarı (WAF) sağlar.
Azure Front Door , Microsoft'un kullanıcılarınız ile uygulamalarınızın dünya genelindeki statik ve dinamik web içeriği arasında hızlı, güvenilir ve güvenli erişim sağlayan modern bulut İçerik Teslim Ağıdır (CDN). Azure Front Door, microsoft'un küresel uç ağını kullanarak içeriğinizi dünyanın dört bir yanında hem kurumsal hem de tüketici son kullanıcılarınıza yakın bir yerde dağıtılan yüzlerce küresel ve yerel varlık noktası (POP) ile sunar.
Azure API Management. API Management, API'leri dış ve iç müşterilere yayımlamak için anahtar teslimi bir çözümdür. Microsoft Entra Id veya diğer kimlik sağlayıcılarını kullanarak hız sınırlama, IP kısıtlamaları ve kimlik doğrulaması gibi genel kullanıma yönelik bir API'yi yönetmek için yararlı özellikler sağlar. API Management herhangi bir yük dengeleme gerçekleştirmez, bu nedenle Application Gateway veya ters ara sunucu gibi bir yük dengeleyici ile birlikte kullanılmalıdır. Api Management'ı Application Gateway ile kullanma hakkında bilgi için bkz . Api Management'ı Application Gateway ile iç sanal ağda tümleştirme.
Ağ geçidi teknolojisi seçerken aşağıdakileri göz önünde bulundurun:
Özellikler. Tüm yukarıda listelenen seçenekler katman 7 yönlendirmeyi destekler, ancak diğer özelliklere yönelik destek farklılık gösterir. İhtiyacınız olan özelliklere bağlı olarak birden fazla ağ geçidi dağıtabilirsiniz.
Dağıtım. Azure Uygulaması Lication Gateway ve API Management yönetilen hizmetlerdir. Nginx ve HAProxy genellikle küme içindeki kapsayıcılarda çalışır, ancak küme dışındaki ayrılmış VM'lere de dağıtılabilir. Bu, ağ geçidini iş yükünün geri kalanından yalıtır, ancak daha yüksek yönetim yüküne neden olur.
Yönetim. Hizmetler güncelleştirildiğinde veya yeni hizmetler eklendiğinde, ağ geçidi yönlendirme kurallarının güncelleştirilmiş olması gerekebilir. Bu işlemin nasıl yönetileceğini düşünün. Ssl sertifikalarını, IP izin verilenler listesini ve yapılandırmanın diğer yönlerini yönetmek için de benzer noktalar geçerlidir.
Nginx veya HAProxy'yi Kubernetes'e dağıtma
Nginx veya HAProxy'yi Kubernetes'e Nginx veya HAProxy kapsayıcı görüntüsünü belirten bir ReplicaSet veya DaemonSet olarak dağıtabilirsiniz. Ara sunucu için yapılandırma dosyasını depolamak ve ConfigMap'i birim olarak bağlamak için ConfigMap kullanın. Ağ geçidini bir Azure Load Balancer aracılığıyla kullanıma açmak için LoadBalancer türünde bir hizmet oluşturun.
Alternatif olarak giriş denetleyicisi oluşturabilirsiniz. Giriş Denetleyicisi, yük dengeleyici veya ters ara sunucu dağıtan bir Kubernetes kaynağıdır. Nginx ve HAProxy gibi çeşitli uygulamalar vardır. Giriş olarak adlandırılan ayrı bir kaynak, Giriş Denetleyicisi için yönlendirme kuralları ve TLS sertifikaları gibi ayarları tanımlar. Bu şekilde, belirli bir ara sunucu teknolojisine özgü karmaşık yapılandırma dosyalarını yönetmeniz gerekmez.
Ağ geçidi sistemde olası bir performans sorunu veya tek hata noktası olduğundan, yüksek kullanılabilirlik için her zaman en az iki çoğaltma dağıtın. Yüke bağlı olarak çoğaltmaların ölçeğini genişletmeniz gerekebilir.
Ayrıca ağ geçidini kümedeki ayrılmış bir düğüm kümesinde çalıştırmayı da göz önünde bulundurun. Bu yaklaşımın avantajları şunlardır:
Yalıtım. Tüm gelen trafik, arka uç hizmetlerinden yalıtılabilen sabit bir düğüm kümesine gider.
Kararlı yapılandırma. Ağ geçidi yanlış yapılandırılmışsa, uygulamanın tamamı kullanılamaz duruma gelebilir.
Performans. Performans nedeniyle ağ geçidi için belirli bir VM yapılandırması kullanmak isteyebilirsiniz.
Sonraki adımlar
Önceki makalelerde mikro hizmetler veya mikro hizmetler ile istemci uygulamaları arasındaki arabirimler incelenmişti. Tasarım gereği, bu arabirimler her hizmeti opak bir kutu olarak ele alır. Özellikle, mikro hizmetler hiçbir zaman verileri nasıl yöneteceklerine ilişkin uygulama ayrıntılarını göstermemelidir. Bu, sonraki makalede incelenen veri bütünlüğü ve veri tutarlılığı üzerinde etkilere sahiptir.