Aracılığıyla paylaş

API ağ geçidi deseni ile Doğrudan istemciden mikro hizmete iletişim karşılaştırması

  • Makale

İpucu

Bu içerik, .NET Docs'ta veya çevrimdışı olarak okunabilen ücretsiz indirilebilir bir PDF olarak sağlanan Kapsayıcılı .NET Uygulamaları için .NET Mikro Hizmet Mimarisi e-Kitabı'ndan bir alıntıdır.

PDF'i indirin

.NET Microservices Architecture for Containerized .NET Applications eBook cover thumbnail.

Bir mikro hizmet mimarisinde, her mikro hizmet bir dizi (genellikle) ayrıntılı uç noktaları kullanıma sunar. Bu olgu, bu bölümde açıklandığı gibi istemciden mikro hizmete iletişimi etkileyebilir.

İstemciden mikro hizmete doğrudan iletişim

Olası bir yaklaşım, doğrudan istemciden mikro hizmete iletişim mimarisi kullanmaktır. Bu yaklaşımda, şekil 4-12'de gösterildiği gibi bir istemci uygulaması bazı mikro hizmetlere doğrudan istekte bulunabilir.

Diagram showing client-to-microservice communication architecture.

Şekil 4-12. Doğrudan istemciden mikro hizmete iletişim mimarisi kullanma

Bu yaklaşımda, her mikro hizmetin genel uç noktası vardır ve bazen her mikro hizmet için farklı bir TCP bağlantı noktası vardır. Belirli bir hizmetin URL'sine örnek olarak Azure'da aşağıdaki URL gösterilebilir:

http://eshoponcontainers.westus.cloudapp.azure.com:88/

Kümeyi temel alan bir üretim ortamında, bu URL kümede kullanılan yük dengeleyiciyle eşlenecek ve bu da istekleri mikro hizmetler arasında dağıtacak. Üretim ortamlarında mikro hizmetlerinizle İnternet arasında Azure Uygulaması lication Gateway gibi bir Uygulama Teslim Denetleyicisi (ADC) olabilir. Bu katman, yalnızca yük dengeleme gerçekleştirmekle kalmaz, aynı zamanda SSL sonlandırması sunarak hizmetlerinizin güvenliğini sağlayan saydam bir katman görevi görür. Bu yaklaşım, yoğun CPU kullanan SSL sonlandırma ve diğer yönlendirme görevlerini Azure Uygulaması lication Gateway'e boşaltarak konaklarınızın yükünü geliştirir. Her durumda, yük dengeleyici ve ADC mantıksal uygulama mimarisi açısından saydamdır.

Özellikle istemci uygulaması ASP.NET MVC uygulaması gibi sunucu tarafı bir web uygulamasıysa, doğrudan istemciden mikro hizmete iletişim mimarisi küçük mikro hizmet tabanlı bir uygulama için yeterli olabilir. Ancak, büyük ve karmaşık mikro hizmet tabanlı uygulamalar (örneğin, onlarca mikro hizmet türünü işlerken) ve özellikle istemci uygulamaları uzak mobil uygulamalar veya SPA web uygulamaları olduğunda, bu yaklaşım birkaç sorunla karşı karşıyadır.

Mikro hizmetlere dayalı büyük bir uygulama geliştirirken aşağıdaki soruları göz önünde bulundurun:

  • İstemci uygulamaları arka uca yönelik istek sayısını nasıl en aza indirip birden çok mikro hizmetle sohbet eden iletişimi azaltabilir?

Tek bir kullanıcı arabirimi ekranı oluşturmak için birden çok mikro hizmetle etkileşim kurmak, İnternet genelinde gidiş dönüş sayısını artırır. Bu yaklaşım, kullanıcı arabirimi tarafındaki gecikme süresini ve karmaşıklığı artırır. İdeal olarak, yanıtların sunucu tarafında verimli bir şekilde toplanması gerekir. Birden çok veri parçası paralel olarak geri geldiğinden ve bazı kullanıcı arabirimi hazır olduğunda verileri gösterebildiğinden bu yaklaşım gecikme süresini azaltır.

  • Yetkilendirme, veri dönüşümleri ve dinamik istek gönderme gibi çapraz kesme sorunlarını nasıl ele alabilirsiniz?

Her mikro hizmette güvenlik ve yetkilendirme gibi güvenlik ve çapraz kesme endişelerinin uygulanması önemli geliştirme çalışmaları gerektirebilir. Olası bir yaklaşım, docker konağı veya iç küme içindeki hizmetlerin dışarıdan doğrudan erişimini kısıtlamak ve bu çapraz kesme sorunlarını API Gateway gibi merkezi bir yerde uygulamaktır.

  • İstemci uygulamaları İnternet'e uygun olmayan protokolleri kullanan hizmetlerle nasıl iletişim kurabilir?

Sunucu tarafında kullanılan protokoller (AMQP veya ikili protokoller gibi) istemci uygulamalarında desteklenmez. Bu nedenle isteklerin HTTP/HTTPS gibi protokoller aracılığıyla gerçekleştirilmesi ve daha sonra diğer protokollere çevrilmesi gerekir. Ortadaki adam yaklaşımı bu durumda yardımcı olabilir.

  • Özellikle mobil uygulamalar için yapılmış bir cepheyi nasıl şekillendirebilirsiniz?

Birden çok mikro hizmetin API'si farklı istemci uygulamalarının ihtiyaçları için iyi tasarlanmamış olabilir. Örneğin, bir mobil uygulamanın gereksinimleri bir web uygulamasının gereksinimlerinden farklı olabilir. Mobil uygulamalarda, veri yanıtlarının daha verimli olabilmesi için daha da iyileştirmeniz gerekebilir. Bu işlevi birden çok mikro hizmetten veri toplayarak ve tek bir veri kümesi döndürerek ve bazen yanıttaki mobil uygulama tarafından gerekli olmayan verileri ortadan kaldırarak yapabilirsiniz. Ve elbette bu verileri sıkıştırabilirsiniz. Yine, mobil uygulama ile mikro hizmetler arasındaki bir cephe veya API bu senaryo için uygun olabilir.

Neden doğrudan istemciden mikro hizmete iletişim yerine API Gateway'leri göz önünde bulundurun?

Mikro hizmetler mimarisinde istemci uygulamalarının genellikle birden fazla mikro hizmetten işlevsellik tüketmesi gerekir. Bu tüketim doğrudan gerçekleştirilirse istemcinin mikro hizmet uç noktalarına yönelik birden çok çağrıyı işlemesi gerekir. Uygulama geliştiğinde ve yeni mikro hizmetler sunulduğunda veya mevcut mikro hizmetler güncelleştirildiğinde ne olur? Uygulamanızın çok sayıda mikro hizmeti varsa, istemci uygulamalarından bu kadar çok uç noktayı işlemek bir kabus olabilir. İstemci uygulaması bu iç uç noktalarla birleştirileceğinden, gelecekte mikro hizmetleri geliştirmek istemci uygulamaları için yüksek etkiye neden olabilir.

Bu nedenle, bir ara düzeye veya dolaylı katmana (Ağ Geçidi) sahip olmak mikro hizmet tabanlı uygulamalar için kullanışlı olabilir. API Gateway'leriniz yoksa istemci uygulamalarının doğrudan mikro hizmetlere istek göndermesi gerekir ve bu da aşağıdaki sorunlar gibi sorunlara neden olur:

  • Bağlama: API Gateway düzeni olmadan, istemci uygulamaları iç mikro hizmetlere bağlanır. İstemci uygulamalarının, uygulamanın birden çok alanının mikro hizmetlerde nasıl ayrıştırıldığından haberdar olması gerekir. İç mikro hizmetler geliştirilirken ve yeniden düzenlendiğinde, bu eylemler istemci uygulamalarındaki iç mikro hizmetlere doğrudan başvuru nedeniyle istemci uygulamalarında hataya neden oldukları için bakımı etkiler. İstemci uygulamalarının sık sık güncelleştirilerek çözümün gelişmesini zorlaştırılması gerekir.

  • Çok fazla gidiş dönüş: İstemci uygulamasındaki tek bir sayfa/ekran birden çok hizmete birkaç çağrı gerektirebilir. Bu yaklaşım, istemci ile sunucu arasında birden çok ağ gidiş dönüşlerine neden olarak önemli gecikme süresine neden olabilir. Ara düzeyde işlenen toplama, istemci uygulamasının performansını ve kullanıcı deneyimini iyileştirebilir.

  • Güvenlik sorunları: Ağ geçidi olmadan tüm mikro hizmetlerin "dış dünyaya" açık olması gerekir ve saldırı yüzeyi, istemci uygulamaları tarafından doğrudan kullanılmayan iç mikro hizmetleri gizlediğinizden daha büyük hale gelir. Saldırı yüzeyi ne kadar küçük olursa, uygulamanız o kadar güvenli olabilir.

  • Çapraz kesme endişeleri: Genel olarak yayımlanan her mikro hizmet yetkilendirme ve SSL gibi endişeleri ele almalıdır. Birçok durumda, bu endişeler tek bir katmanda işlenebilir, böylece iç mikro hizmetler basitleştirilir.

API Gateway düzeni nedir?

Birden çok istemci uygulamasıyla büyük veya karmaşık mikro hizmet tabanlı uygulamalar tasarlayıp oluştururken, dikkate alınması gereken iyi bir yaklaşım API Gateway olabilir. Bu düzen, belirli mikro hizmet grupları için tek giriş noktası sağlayan bir hizmettir. Nesne odaklı tasarımdaki Cephe desenine benzer, ancak bu örnekte dağıtılmış bir sistemin parçasıdır. API Gateway deseni bazen "ön uç için arka uç" (BFF) olarak da bilinir çünkü istemci uygulamasının gereksinimlerini düşünürken oluşturursunuz.

Bu nedenle, API ağ geçidi istemci uygulamaları ve mikro 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 önbellek gibi diğer çapraz kesme özelliklerini de sağlayabilir.

Şekil 4-13'te özel API Gateway'in yalnızca birkaç mikro hizmetle basitleştirilmiş mikro hizmet tabanlı mimariye nasıl sığabileceği gösterilmektedir.

Diagram showing an API Gateway implemented as a custom service.

Şekil 4-13. Özel hizmet olarak uygulanan bir API Gateway kullanma

Uygulamalar, istekleri tek tek mikro hizmetlere iletmek üzere yapılandırılmış tek bir uç noktaya(API Gateway) bağlanır. Bu örnekte API Gateway, kapsayıcı olarak çalışan özel bir ASP.NET Core WebHost hizmeti olarak uygulanacaktır.

Bu diyagramda birden çok ve farklı istemci uygulamasına yönelik tek bir özel API Gateway hizmeti kullandığınızı vurgulamak önemlidir. API Gateway hizmetiniz, istemci uygulamalarından birçok farklı gereksinime göre büyüyeceği ve gelişeceği için bu durum önemli bir risk olabilir. Sonunda, bu farklı ihtiyaçlar nedeniyle şişecek ve etkili bir şekilde monolitik bir uygulamaya veya monolitik hizmete benzer olabilir. Bu nedenle API Gateway'i birden çok hizmete veya istemci uygulama form faktörü türü başına bir tane olmak üzere birden çok daha küçük API Gateway'e bölmek çok önerilir.

API Gateway düzenini uygularken dikkatli olmanız gerekir. Genellikle uygulamanızın tüm iç mikro hizmetlerini toplayarak tek bir API Gateway kullanmak iyi bir fikir değildir. Varsa, monolitik toplayıcı veya düzenleyici görevi görür ve tüm mikro hizmetleri bir arada kullanarak mikro hizmet özerkliğini ihlal eder.

Bu nedenle, API Gateway'ler iş sınırlarına ve istemci uygulamalarına göre ayrıştırılmalıdır ve tüm iç mikro hizmetler için tek bir toplayıcı işlevi görmesi gerekmez.

API Gateway katmanını birden çok API Gateway'e bölerken, uygulamanızın birden çok istemci uygulaması varsa, bu, birden çok API Gateway türünü tanımlarken birincil bir özet olabilir, böylece her istemci uygulamasının gereksinimleri için farklı bir cepheye sahip olabilirsiniz. Bu durum, her API Gateway'in aşağıdaki görüntüde gösterildiği gibi birden çok iç mikro hizmeti çağıran belirli bir bağdaştırıcı kodu uygulayarak istemci form faktörüne göre bile her istemci uygulama türü için uyarlanmış farklı bir API sağlayabildiği "Ön Uç için Arka Uç" (BFF) adlı bir desendir:

Diagram showing multiple custom API Gateways.

Şekil 4-13.1. Birden çok özel API Ağ Geçidi kullanma

Şekil 4-13.1,istemci türüne göre ayrılmış API Ağ Geçitlerini gösterir; biri mobil istemciler, diğeri de web istemcileri için. Geleneksel bir web uygulaması, web API Gateway kullanan bir MVC mikro hizmetine bağlanır. Örnek, birden çok ayrıntılı API Ağ Geçidine sahip basitleştirilmiş bir mimariyi gösterir. Bu durumda, her API Gateway için tanımlanan sınırlar yalnızca "Ön Uç için Arka Uç" (BFF) desenini temel alır, bu nedenle yalnızca istemci uygulaması başına gereken API'yi temel alır. Ancak daha büyük uygulamalarda da daha ileri gitmeniz ve ikinci bir tasarım özeti olarak iş sınırları temelinde başka API Gateway'ler oluşturmanız gerekir.

API Gateway düzenindeki ana özellikler

API Gateway birden çok özellik sunabilir. Ürüne bağlı olarak daha zengin veya daha basit özellikler sunabilir, ancak herhangi bir API Gateway için en önemli ve temel özellikler aşağıdaki tasarım desenleridir:

Ters ara sunucu veya ağ geçidi yönlendirmesi. API Gateway, istekleri (katman 7 yönlendirme, genellikle HTTP istekleri) iç mikro hizmetlerin uç noktalarına yönlendirmek veya yönlendirmek için ters ara sunucu sunar. Ağ geçidi, istemci uygulamaları için tek bir uç nokta veya URL sağlar ve ardından istekleri bir grup iç mikro hizmetle dahili olarak eşler. Bu yönlendirme özelliği, istemci uygulamalarını mikro hizmetlerden ayırmaya yardımcı olur, ancak monolitik API'yi monolitik API ile istemci uygulamaları arasında tutarak monolitik API'yi modernleştirirken de kullanışlıdır. Daha sonra, gelecekte birçok mikro hizmete bölünene kadar eski monolitik API'yi kullanmaya devam ederken yeni API'leri yeni mikro hizmetler olarak ekleyebilirsiniz. API Gateway nedeniyle istemci uygulamaları, kullanılan API'lerin iç mikro hizmetler veya monolitik API olarak uygulanıp uygulanmadığını fark etmez ve daha da önemlisi, MONOlitik API'yi mikro hizmetlere dönüştürürken ve yeniden düzenlerken API Gateway yönlendirmesi sayesinde istemci uygulamaları herhangi bir URI değişikliğinden etkilenmez.

Daha fazla bilgi için bkz . Ağ geçidi yönlendirme düzeni.

Toplama isteğinde bulunur. Ağ geçidi deseninin bir parçası olarak, birden çok iç mikro hizmeti hedefleyen birden çok istemci isteğini (genellikle HTTP istekleri) tek bir istemci isteğinde toplayabilirsiniz. Bu düzen özellikle bir istemci sayfasının/ekranının birkaç mikro hizmetten bilgi alması gerektiğinde kullanışlıdır. Bu yaklaşımla, istemci uygulaması API Gateway'e tek bir istek gönderir ve bu istek iç mikro hizmetlere çeşitli istekler gönderir ve ardından sonuçları toplar ve her şeyi istemci uygulamasına geri gönderir. Bu tasarım düzeninin temel avantajı ve hedefi, istemci uygulamaları ve arka uç API'si arasındaki sohbeti azaltmaktır. Bu, özellikle mobil uygulamalar veya istemci uzak tarayıcılarında JavaScript'ten gelen SPA uygulamalarından gelen istekler gibi mikro hizmetlerin yaşadığı veri merkezinden uzak uygulamalar için önemlidir. İstekleri sunucu ortamında gerçekleştiren normal web uygulamaları için (ASP.NET Core MVC web uygulaması gibi), gecikme süresi uzak istemci uygulamalarına göre çok daha küçük olduğundan bu düzen çok önemli değildir.

Kullandığınız API Gateway ürününe bağlı olarak bu toplamayı gerçekleştirebilir. Ancak çoğu durumda API Gateway kapsamında toplama mikro hizmetleri oluşturmak daha esnektir, bu nedenle toplamayı kodda (yani C# kodunda) tanımlarsınız:

Daha fazla bilgi için bkz . Ağ geçidi toplama düzeni.

Çapraz kesme endişeleri veya ağ geçidi boşaltma. Her API Gateway ürünü tarafından sunulan özelliklere bağlı olarak, işlevleri tek tek mikro hizmetlerden ağ geçidine aktarabilirsiniz; bu da çapraz kesme sorunlarını tek bir katmanda birleştirerek her mikro hizmetin uygulanmasını basitleştirir. Bu yaklaşım özellikle aşağıdaki işlevler gibi her iç mikro hizmette düzgün şekilde uygulanması karmaşık olabilecek özel özellikler için kullanışlıdır:

  • Kimlik doğrulaması ve yetkilendirme
  • Hizmet bulma tümleştirmesi
  • Yanıtları Önbelleğe Alma
  • İlkeleri, devre kesiciyi ve QoS'yi yeniden deneyin
  • Hız sınırlama ve azaltma
  • Yük dengeleme
  • Günlüğe kaydetme, izleme, bağıntı
  • Üst bilgiler, sorgu dizeleri ve talep dönüştürme
  • IP izin verilenler listesi

Daha fazla bilgi için bkz . Ağ geçidi boşaltma düzeni.

API Gateway özelliklerine sahip ürünleri kullanma

Her uygulamaya bağlı olarak API Gateways ürünleri tarafından sunulan çok daha fazla çapraz kesme sorunu olabilir. Burada şunları keşfedeceğiz:

Azure API Management

Azure API Management (Şekil 4-14'te gösterildiği gibi) yalnızca API Gateway gereksinimlerinizi çözmekle kalmaz, API'lerinizden içgörü toplama gibi özellikler de sağlar. API management çözümü kullanıyorsanız, API Gateway yalnızca bu tam API management çözümünün içindeki bir bileşendir.

Diagram showing how to use Azure API Management as your API gateway.

Şekil 4-14. API Gateway'iniz için Azure API Management kullanma

Azure API Management hem API Gateway hem de Günlük, güvenlik, ölçüm gibi Yönetim gereksinimlerinizi çözer. Bu durumda, Azure API Management gibi bir ürün kullanırken tek bir API Gateway'iniz olması çok riskli değildir çünkü bu tür API Gateway'ler "daha incedir", yani monolitik bir bileşene doğru gelişebilecek özel C# kodu uygulamazsınız.

API Gateway ürünleri genellikle giriş iletişimi için ters ara sunucu gibi davranır; burada api'leri iç mikro hizmetlerden filtreleyebilir ve bu tek katmanda yayımlanan API'lere yetkilendirme uygulayabilirsiniz.

API Management sisteminde sağlanan içgörüler, API'lerinizin nasıl kullanıldığını ve nasıl performans sergilediklerini anlamanıza yardımcı olur. Bu etkinlik, gerçek zamanlıya yakın analiz raporlarını görüntülemenize ve işletmenizi etkileyebilecek eğilimleri belirlemenize izin vererek yapar. Ayrıca, daha fazla çevrimiçi ve çevrimdışı analiz için istek ve yanıt etkinliğiyle ilgili günlükleriniz olabilir.

Azure API Management ile anahtar, belirteç ve IP filtreleme kullanarak API'lerinizin güvenliğini sağlayabilirsiniz. Bu özellikler esnek ve ayrıntılı kotaları ve hız sınırlarını zorunlu kılmanıza, ilkeleri kullanarak API'lerinizin şeklini ve davranışını değiştirmenize ve yanıt önbelleğe alma ile performansı geliştirmenize olanak sağlar.

Bu kılavuzda ve başvuru örneği uygulamasında (eShopOnContainers), Azure API Management gibi PaaS ürünlerini kullanmadan düz kapsayıcılara odaklanmak için mimari daha basit ve özel hale getirilmiş kapsayıcılı mimariyle sınırlıdır. Ancak Microsoft Azure'a dağıtılan büyük mikro hizmet tabanlı uygulamalar için Azure API Management'ı üretimdeki API Ağ Geçitlerinizin temeli olarak değerlendirmenizi öneririz.

Ocelot

Ocelot , basit yaklaşımlar için önerilen basit bir API Gateway'dir. Ocelot, özellikle sistemlerine birleşik giriş noktaları gerektiren mikro hizmet mimarileri için üretilen Açık Kaynak .NET Core tabanlı bir API Gateway'dir. Basit, hızlı ve ölçeklenebilirdir ve diğer birçok özellik arasında yönlendirme ve kimlik doğrulaması sağlar.

eShopOnContainers başvuru uygulaması 2.0 için Ocelot'u seçmenin temel nedeni, Ocelot'un docker konağı, Kubernetes vb. gibi mikro hizmetlerinizi/kapsayıcılarınızı dağıttığınız aynı uygulama dağıtım ortamına dağıtabileceğiniz bir .NET Core basit API Ağ Geçidi olmasıdır. .NET Core'a dayalı olduğundan, Linux veya Windows üzerinde dağıtım yapmanızı sağlayan platformlar arasıdır.

Kapsayıcılarda çalışan özel API Gateway'leri gösteren önceki diyagramlar, Ocelot'u kapsayıcı ve mikro hizmet tabanlı bir uygulamada tam olarak nasıl çalıştırabileceğinizi gösterir.

Buna ek olarak, apigee, Kong, MuleSoft, WSO2 gibi API Gateway özellikleri sunan diğer birçok ürün ve hizmet ağı giriş denetleyicisi özellikleri için Linkerd ve Istio gibi diğer ürünler vardır.

İlk mimari ve desen açıklaması bölümlerinden sonra, sonraki bölümlerde Ocelot ile API Gateway'lerin nasıl uygulanacakları açıklanmaktadır.

API Gateway deseninin dezavantajları

  • En önemli dezavantajı, bir API Gateway uyguladığınızda bu katmanı iç mikro hizmetlerle birleştirilmiş olmasıdır. Bunun gibi bir kuplaj uygulamanız için ciddi zorluklara neden olabilir. Azure Service Bus ekibinin mimarı Clemens Vaster, GOTO 2016'daki "Mesajlaşma ve Mikro Hizmetler" oturumunda bu olası zorluğu "yeni ESB" olarak ifade ediyor.

  • Mikro hizmetler API'sinin Ağ Geçidi kullanılması, olası ek bir hata noktası oluşturur.

  • Api Gateway, ek ağ çağrısı nedeniyle daha fazla yanıt süresine neden olabilir. Ancak, bu ek çağrı genellikle iç mikro hizmetleri doğrudan çağıran çok gevendekli bir istemci arabirimine sahip olmaktan daha az etkiye sahiptir.

  • Ölçeği doğru şekilde genişletilmediyse API Gateway bir performans sorununa dönüşebilir.

  • Api Gateway, özel mantık ve veri toplama içeriyorsa ek geliştirme maliyeti ve gelecekteki bakım gerektirir. Geliştiricilerin her mikro hizmetin uç noktalarını kullanıma sunmak için API Gateway'i güncelleştirmeleri gerekir. Ayrıca, iç mikro hizmetlerdeki uygulama değişiklikleri API Gateway düzeyinde kod değişikliklerine neden olabilir. Ancak API Gateway yalnızca güvenlik, günlük ve sürüm oluşturma (Azure API Management kullanırken olduğu gibi) uyguluyorsa bu ek geliştirme maliyeti geçerli olmayabilir.

  • API Gateway tek bir ekip tarafından geliştirilen bir geliştirme performans sorunu olabilir. Bu özellik, daha iyi bir yaklaşımın farklı istemci gereksinimlerine yanıt veren birkaç ayrıntılı API Ağ Geçidine sahip olmak olmasının bir diğer nedenidir. Ayrıca API Gateway'i dahili mikro hizmetler üzerinde çalışan farklı ekiplerin sahip olduğu birden çok alana veya katmana ayırabilirsiniz.

Ek kaynaklar

Geriİleri