Ocelot ile API Ağ Geçitlerini uygulama | Microsoft Docs
Ocelot ile API ağ geçitleri uygulamaImplement API Gateways with Ocelot
Başvuru mikro hizmet uygulaması Eshoponcontainers , tarafından kullanılan aşağıdaki ortamların herhangi birinde olduğu gibi, mikro hizmetlerinize/kapsayıcılarınızla birlikte dağıtabileceğiniz basit ve hafıf bir API ağ geçidi olan Ocelotkullanıyor. eShopOnContainers.The reference microservice application eShopOnContainers is using Ocelot, a simple and lightweight API Gateway that you can deploy anywhere along with your microservices/containers, such as in any of the following environments used by eShopOnContainers.
Docker ana bilgisayarı, yerel geliştirme bilgisayarınızda, şirket içinde veya bulutta.Docker host, in your local dev PC, on-premises or in the cloud.
Kubernetes kümesi, şirket içi veya Azure Kubernetes hizmeti (AKS) gibi yönetilen bulutta.Kubernetes cluster, on-premises or in managed cloud such as Azure Kubernetes Service (AKS).
Küme, şirket içinde veya bulutta Service Fabric.Service Fabric cluster, on-premises or in the cloud.
Azure 'da PaaS/sunucusuz olarak Service Fabric mesh.Service Fabric mesh, as PaaS/Serverless in Azure.
API ağ geçitlerini mimarinizi ve tasarlamaArchitect and design your API Gateways
Aşağıdaki mimari diyagramda, API ağ geçitlerinin eShopOnContainers 'da Ocelot ile nasıl uygulandığı gösterilmektedir.The following architecture diagram shows how API Gateways are implemented with Ocelot in eShopOnContainers.
Şekil 6-28.Figure 6-28. API ağ geçitleri ile eShopOnContainers mimarisieShopOnContainers architecture with API Gateways
Bu diyagramda tüm uygulamanın, "Docker for Windows" veya "Docker for Mac" ile tek bir Docker konağına veya geliştirme BILGISAYARıNA nasıl dağıtıldığı gösterilmektedir.That diagram shows how the whole application is deployed into a single Docker host or development PC with “Docker for Windows” or “Docker for Mac”. Ancak, herhangi bir Orchestrator 'a dağıtmak oldukça benzerdir ancak Diyagramdaki herhangi bir kapsayıcı Orchestrator 'da ölçeklendirilebilir.However, deploying into any orchestrator would be pretty similar but any container in the diagram could be scaled-out in the orchestrator.
Ayrıca, veritabanları, önbellek ve ileti aracıları gibi altyapı varlıklarının, Orchestrator 'dan boşaltılabilmesi ve Azure SQL veritabanı, Azure Cosmos DB, Azure Redu, Azure Service Bus gibi altyapıda yüksek kullanılabilir sistemlere dağıtılması gerekir. ya da herhangi bir HA kümeleme çözümünü şirket içinde.In addition, the infrastructure assets such as databases, cache, and message brokers should be offloaded from the orchestrator and deployed into high available systems for infrastructure, like Azure SQL Database, Azure Cosmos DB, Azure Redis, Azure Service Bus, or any HA clustering solution on-premises.
Diyagramda da fark edebilirsiniz. birçok API ağ geçidine sahip olmak, mikro hizmetlerinin yanı sıra kendi ilgili API ağ geçitlerinin geliştirilmesi ve dağıtılmasında birden çok geliştirme ekibinin otonom olmasına (Bu durumda pazarlama özellikleri ve alışveriş özellikleri) izin verir.As you can also notice in the diagram, having several API Gateways allows multiple development teams to be autonomous (in this case Marketing features vs. Shopping features) when developing and deploying their microservices plus their own related API Gateways.
Çeşitli geliştirme ekipleri tarafından güncelleştirilebilecek tek bir tek nokta olan tek bir tek bir API ağ geçidiniz varsa, tüm mikro hizmetlere uygulamanın tek bir bölümüyle de neden olabilir.If you had a single monolithic API Gateway that would mean a single point to be updated by several development teams, which could couple all the microservices with a single part of the application.
Tasarımda çok daha fazla şey varsa, bazen ayrıntılı bir API ağ geçidi, seçilen mimariye bağlı olarak tek bir iş mikro hizmeti ile de sınırlı olabilir.Going much further in the design, sometimes a fine-grained API Gateway can also be limited to a single business microservice depending on the chosen architecture. API ağ geçidinin iş veya etki alanı tarafından dikte edilen sınırlarının olması, daha iyi bir tasarım almanıza yardımcı olur.Having the API Gateway’s boundaries dictated by the business or domain will help you to get a better design.
Örneğin, gelişmiş bir API Gateway kavramı bir UI bileşim hizmetine benzer olduğundan, API ağ geçidi katmanında ince ayrıntı düzeyi özellikle mikro hizmetleri temel alan daha gelişmiş bileşik UI uygulamaları için yararlı olabilir.For instance, fine granularity in the API Gateway tier can be especially useful for more advanced composite UI applications that are based on microservices, because the concept of a fine-grained API Gateway is similar to a UI composition service.
Önceki bölümde, mikro hizmetlere dayalı bileşik Kullanıcı arabirimi oluşturma hakkındadaha fazla ayrıntı inceleyeceğiz.We delve into more details in the previous section Creating composite UI based on microservices.
Anahtar kullanımı, birçok orta ve büyük ölçekli uygulamalar için, özel olarak oluşturulmuş bir API ağ geçidi ürünü kullanmanın genellikle iyi bir yaklaşım vardır, ancak tek bir monoparçalı toplayıcı veya benzersiz bir merkezi özel API ağ geçidi, API ağ geçidi birden çok bağımsız izin vermez otonom mikro hizmetler oluşturan çeşitli geliştirme ekipleri için yapılandırma alanı.As key takeaway, for many medium- and large-size applications, using a custom-built API Gateway product is usually a good approach, but not as a single monolithic aggregator or unique central custom API Gateway unless that API Gateway allows multiple independent configuration areas for the several development teams creating autonomous microservices.
API ağ geçitleri aracılığıyla yeniden yönlendirme için örnek mikro hizmetler/kapsayıcılarSample microservices/containers to re-route through the API Gateways
Örnek olarak, eShopOnContainers, aşağıdaki görüntüde gösterildiği gibi, API ağ geçitleri aracılığıyla yayımlanması gereken altı adet iç mikro hizmet türü içerir.As an example, eShopOnContainers has around six internal microservice-types that have to be published through the API Gateways, as shown in the following image.
Şekil 6-29.Figure 6-29. Visual Studio 'da eShopOnContainers çözümünde mikro hizmet klasörleriMicroservice folders in eShopOnContainers solution in Visual Studio
Kimlik hizmeti hakkında, tasarımda tek bir çapraz kesme sorunu olduğundan, bu, yönetim ağ geçidi yönlendirmesinde kalmadı, ancak bu da yeniden yönlendirme listelerinin bir parçası olarak dahil olabilir.About the Identity service, in the design it's left out of the API Gateway routing because it's the only cross-cutting concern in the system, although with Ocelot it's also possible to include it as part of the rerouting lists.
Koddan bildirebilmeniz için, bu hizmetlerin tümü şu anda ASP.NET Core Web API hizmeti olarak uygulanır.All those services are currently implemented as ASP.NET Core Web API services, as you can tell from the code. Kataloğun mikro hizmet kodu gibi mikro hizmetlerden birine odaklanalım.Let’s focus on one of the microservices like the Catalog microservice code.
Şekil 6-30.Figure 6-30. Örnek Web API mikro hizmeti (Katalog mikro hizmeti)Sample Web API microservice (Catalog microservice)
Catalog mikro hizmet 'in, aşağıdaki kodda olduğu gibi çeşitli denetleyiciler ve yöntemlerle tipik bir ASP.NET Core Web API projesi olduğunu görebilirsiniz.You can see that the Catalog microservice is a typical ASP.NET Core Web API project with several controllers and methods like in the following code.
HTTP isteği, mikro hizmet veritabanına ve gerekli ek eylemlere C# erişen bu tür bir kodu çalıştırmaya sona acaktır.The HTTP request will end up running that kind of C# code accessing the microservice database and any additional required action.
Mikro hizmet URL 'SI ile ilgili olan kapsayıcılar yerel geliştirme PC 'nizde (yerel Docker ana bilgisayarı) dağıtıldığında, her mikro hizmet kapsayıcısı, aşağıdaki dockerfile içinde olduğu gibi, dockerfile 'da belirtilen her zaman bir iç bağlantı noktasına (genellikle bağlantı noktası 80) sahiptir:Regarding the microservice URL, when the containers are deployed in your local development PC (local Docker host), each microservice’s container has always an internal port (usually port 80) specified in its dockerfile, as in the following dockerfile:
Kodda gösterilen bağlantı noktası 80, Docker ana bilgisayarı dahilinde olduğundan istemci uygulamaları tarafından ulaşılamıyor.The port 80 shown in the code is internal within the Docker host, so it can't be reached by client apps.
İstemci uygulamaları, docker-compose ile dağıtım sırasında yayımlanan dış bağlantı noktalarına (varsa) erişebilir.Client apps can access only the external ports (if any) published when deploying with docker-compose.
Bu dış bağlantı noktaları, bir üretim ortamına dağıtıldığında yayımlanmamalıdır.Those external ports shouldn't be published when deploying to a production environment. Bu, istemci uygulamaları ve mikro hizmetler arasındaki doğrudan iletişimin önüne geçmek için API ağ geçidini kullanmak istediğinizden kesinlikle önemlidir.This is precisely why you want to use the API Gateway, to avoid the direct communication between the client apps and the microservices.
Ancak geliştirme sırasında, mikro hizmet/kapsayıcıya doğrudan erişmek ve Swagger aracılığıyla çalıştırmak istersiniz.However, when developing, you want to access the microservice/container directly and run it through Swagger. EShopOnContainers 'da bu nedenle, dış bağlantı noktaları API Gateway veya istemci uygulamaları tarafından kullanılmayabilse bile hala belirtilir.That’s why in eShopOnContainers, the external ports are still specified even when they won’t be used by the API Gateway or the client apps.
Katalog mikro hizmeti için docker-compose.override.yml dosyasına bir örnek aşağıda verilmiştir:Here’s an example of the docker-compose.override.yml file for the Catalog microservice:
Docker-Compose. override. yıml yapılandırmasında Katalog kapsayıcısının iç bağlantı noktası 80 olup olmadığını görebilirsiniz, ancak dış erişim bağlantı noktası 5101 ' dir.You can see how in the docker-compose.override.yml configuration the internal port for the Catalog container is port 80, but the port for external access is 5101. Ancak bu bağlantı noktası, yalnızca katalog mikro hizmetini çalıştırmak ve test etmek için bir API ağ geçidi kullanılırken uygulama tarafından kullanılmamalıdır.But this port shouldn’t be used by the application when using an API Gateway, only to debug, run and test just the Catalog microservice.
Genellikle, mikro hizmetler için doğru üretim dağıtım ortamı Kubernetes veya Service Fabric gibi bir Orchestrator olduğundan, bir üretim ortamına Docker-Compose ile dağıtım yapmanız gerekmez.Normally, you won’t be deploying with docker-compose into a production environment because the right production deployment environment for microservices is an orchestrator like Kubernetes or Service Fabric. Bu ortamlara dağıtım yaparken, mikro hizmetler için doğrudan herhangi bir harici bağlantı noktasını yayımlayamayacağınız farklı yapılandırma dosyalarını kullanırsınız, ancak her zaman ters proxy 'yi API Gateway 'den kullanacaksınız.When deploying to those environments you use different configuration files where you won’t publish directly any external port for the microservices but, you'll always use the reverse proxy from the API Gateway.
Visual Studio 'dan tam eShopOnContainers çözümünü çalıştırarak, Katalog mikro hizmetini yerel Docker ana bilgisayarınızda çalıştırın (Docker-Compose dosyalarındaki tüm hizmetleri çalıştırır) veya yalnızca aşağıdaki Docker-Compose ile katalog mikro hizmeti 'ni kullanmaya başlama CMD veya PowerShell 'de, docker-compose.yml ve Docker-Compose. override. yıml 'nin yerleştirildiği klasörde konumlandırılmış olan komut.Run the catalog microservice in your local Docker host either by running the full eShopOnContainers solution from Visual Studio (it’ll run all the services in the docker-compose files) or just starting the Catalog microservice with the following docker-compose command in CMD or PowerShell positioned at the folder where the docker-compose.yml and docker-compose.override.yml are placed.
Bu komut yalnızca Catalog. API hizmet kapsayıcısını ve Docker-Compose. yıml içinde belirtilen bağımlılıkları çalıştırır.This command only runs the catalog.api service container plus dependencies that are specified in the docker-compose.yml. Bu durumda, SQL Server Container ve Kbbitmq kapsayıcısı.In this case, the SQL Server container and RabbitMQ container.
Daha sonra, Katalog mikro hizmetine doğrudan erişebilir ve bu durumda, bu örnekte bu bağlantı noktasından doğrudan bu bağlantı noktası üzerinden erişim için Swagger Kullanıcı arabirimi aracılığıyla yöntemleri görebilirsiniz http://localhost:5101/swagger:Then, you can directly access the Catalog microservice and see its methods through the Swagger UI accessing directly through that “external” port, in this case http://localhost:5101/swagger:
Şekil 6-31.Figure 6-31. Katalog mikro hizmetini Swagger Kullanıcı arabirimiyle test etmeTesting the Catalog microservice with its Swagger UI
Bu noktada, Visual Studio 'da C# kodda bir kesme noktası ayarlayabilir, mikro hizmeti Swagger Kullanıcı arabiriminde sunulan yöntemlerle test edebilirsiniz ve son olarak docker-compose down komutuyla her şeyi temizleyebilirsiniz.At this point, you could set a breakpoint in C# code in Visual Studio, test the microservice with the methods exposed in Swagger UI, and finally clean-up everything with the docker-compose down command.
Ancak, bu durumda 5101 dış bağlantı noktası aracılığıyla mikro hizmetle doğrudan erişim iletişimi, uygulamanızda kaçınmak istediğiniz kadar kesin bir durumdur.However, direct-access communication to the microservice, in this case through the external port 5101, is precisely what you want to avoid in your application. API ağ geçidinin ek yöneltme düzeyini (Bu durumda Ocelot) ayarlayarak bundan kaçınabilirsiniz.And you can avoid that by setting the additional level of indirection of the API Gateway (Ocelot, in this case). Bu şekilde, istemci uygulaması mikro hizmete doğrudan erişemez.That way, the client app won’t directly access the microservice.
API ağ geçitlerini Ocelot ile uygulamaImplementing your API Gateways with Ocelot
Ocelot, temel olarak belirli bir sırada uygulayabileceğiniz bir middlewares kümesidir.Ocelot is basically a set of middlewares that you can apply in a specific order.
Ocelot yalnızca ASP.NET Core çalışmak üzere tasarlanmıştır.Ocelot is designed to work with ASP.NET Core only. .NET Core 2,0 çalışma zamanı ve .NET Framework 4.6.1 çalışma zamanı ve ' de dahil olmak üzere 2,0 .NET Standard her yerde kullanılabilmesi için Netstandard 2.0 'ı hedefliyordu.It targets netstandard2.0 so it can be used anywhere .NET Standard 2.0 is supported, including .NET Core 2.0 runtime and .NET Framework 4.6.1 runtime and up.
Ocelot 'yi ve onun bağımlılıklarını, Visual Studio 'dan Ocelot 'Nin NuGet paketiyleASP.NET Core projenize yüklersiniz.You install Ocelot and its dependencies in your ASP.NET Core project with Ocelot's NuGet package, from Visual Studio.
EShopOnContainers 'da, API Gateway uygulamasının basit bir ASP.NET Core WebHost projesi ve Ocelot 'nin middlewares, aşağıdaki görüntüde gösterildiği gibi tüm API Gateway özelliklerini işlemesi:In eShopOnContainers, its API Gateway implementation is a simple ASP.NET Core WebHost project, and Ocelot’s middlewares handle all the API Gateway features, as shown in the following image:
Şekil 6-32.Figure 6-32. EShopOnContainers 'da OcelotApiGw temel projesiThe OcelotApiGw base project in eShopOnContainers
Bu ASP.NET Core WebHost projesi temel olarak iki basit dosya ile oluşturulmuştur: Program.cs ve Startup.cs.This ASP.NET Core WebHost project is basically built with two simple files: Program.cs and Startup.cs.
Program.cs yalnızca, BuildWebHost ASP.NET Core oluşturmak ve yapılandırmak için gereklidir.The Program.cs just needs to create and configure the typical ASP.NET Core BuildWebHost.
Ocelot için buradaki önemli nokta, AddJsonFile() yöntemi aracılığıyla oluşturucuya sağlamanız gereken configuration.json dosyasıdır.The important point here for Ocelot is the configuration.json file that you must provide to the builder through the AddJsonFile() method. Bu configuration.json, genellikle farklı bağlantı noktaları kullanarak belirli bağlantı noktaları ve bağıntılı iç uç noktalar içeren dış uç noktalar olan tüm API ağ geçidi ReRoutes belirttiğiniz yerdir.That configuration.json is where you specify all the API Gateway ReRoutes, meaning the external endpoints with specific ports and the correlated internal endpoints, usually using different ports.
Yapılandırmanın iki bölümü vardır.There are two sections to the configuration. Bir yeniden yönlendirme dizisi ve bir GlobalConfiguration.An array of Re-Routes and a GlobalConfiguration. Yeniden yönlendirmeler, bir yukarı akış isteğini nasıl değerlendireceği hakkında daha fazla bilgi veren nesnelerdir.The Re-Routes are the objects that tell Ocelot how to treat an upstream request. Genel yapılandırma, belirli ayarların yeniden yönlendirilmesi için geçersiz kılmalara izin verir.The Global configuration allows overrides of Re-Route specific settings. Çok sayıda yeniden yönlendirme, belirli ayarları yönetmek istemiyorsanız yararlıdır.It’s useful if you don’t want to manage lots of Re-Route specific settings.
Aşağıda, eShopOnContainers 'dan API ağ geçitlerinden birinden yapılandırma dosyası yeniden yönlendirme için basitleştirilmiş bir örnek verilmiştir.Here’s a simplified example of ReRoute configuration file from one of the API Gateways from eShopOnContainers.
Bir Ocelot API ağ geçidinin ana işlevselliği, gelen HTTP isteklerini almak ve şu anda başka bir HTTP isteği olarak bir aşağı akış hizmetine iletmektir.The main functionality of an Ocelot API Gateway is to take incoming HTTP requests and forward them on to a downstream service, currently as another HTTP request. Ocelot, bir isteğin bir yeniden yönlendirme olarak diğerine yönlendirilmesini açıklar.Ocelot’s describes the routing of one request to another as a Re-Route.
Örneğin, yukarıdaki Configuration. JSON içindeki yeniden rotalardan birine, sepet mikro hizmeti yapılandırmasına odaklanalım.For instance, let’s focus on one of the Re-Routes in the configuration.json from above, the configuration for the Basket microservice.
DownstreamPathTemplate, düzen ve Downstreamhostandport, bu isteğin iletileceği iç mikro hizmet URL 'sini yapar.The DownstreamPathTemplate, Scheme, and DownstreamHostAndPorts make the internal microservice URL that this request will be forwarded to.
Bağlantı noktası, hizmet tarafından kullanılan iç bağlantı noktasıdır.The port is the internal port used by the service. Kapsayıcılar kullanılırken dockerfile 'da belirtilen bağlantı noktası.When using containers, the port specified at its dockerfile.
Host, kullanmakta olduğunuz hizmet adı çözümlemesine bağlı olan bir hizmet adıdır.The Host is a service name that depends on the service name resolution you are using. Docker-Compose kullanırken, hizmet adları Docker ana bilgisayarı tarafından sağlanır ve bu, Docker-Compose dosyalarında belirtilen hizmet adlarını kullanmaktır.When using docker-compose, the services names are provided by the Docker Host, which is using the service names provided in the docker-compose files. Kubernetes veya Service Fabric gibi bir Orchestrator kullanılıyorsa, bu ad her Orchestrator tarafından sağlanmış olan DNS veya ad çözümlemesi tarafından çözümlenmelidir.If using an orchestrator like Kubernetes or Service Fabric, that name should be resolved by the DNS or name resolution provided by each orchestrator.
Downstreamhostandport, istekleri iletmek istediğiniz herhangi bir aşağı akış hizmetinin ana bilgisayar ve bağlantı noktasını içeren bir dizidir.DownstreamHostAndPorts is an array that contains the host and port of any downstream services that you wish to forward requests to. Genellikle bu yalnızca bir giriş içerir, ancak bazen aşağı akış hizmetlerinize yük dengelemesi yapmak isteyebilirsiniz ve Ocelot, birden fazla giriş eklemenizi ve sonra bir yük dengeleyici seçmenizi sağlar.Usually this will just contain one entry but sometimes you might want to load balance requests to your downstream services and Ocelot lets you add more than one entry and then select a load balancer. Ancak Azure ve herhangi bir Orchestrator kullanılıyorsa, bulut ve Orchestrator altyapısıyla yük dengelemesi daha iyi bir fikir olabilir.But if using Azure and any orchestrator it is probably a better idea to load balance with the cloud and orchestrator infrastructure.
UpstreamPathTemplate, istemci tarafından verilen bir istek için kullanılacak olan DownstreamPathTemplate 'i tanımlamak için kullanılan URL 'dir.The UpstreamPathTemplate is the URL that Ocelot will use to identify which DownstreamPathTemplate to use for a given request from the client. Son olarak, UpstreamHttpMethod kullanılır. bu nedenle, Ocelot, farklı istekleri (GET, POST, PUT) aynı URL 'ye ayırabilirler.Finally, the UpstreamHttpMethod is used so Ocelot can distinguish between different requests (GET, POST, PUT) to the same URL.
Bu noktada, bir veya birden fazla birleştirilmiş Configuration. JSON dosyası kullanarak tek bir Ocelot API Gateway (ASP.NET Core Webhost) olabilir veya yapılandırmayı BIR tüketil kV deposundada saklayabilirsiniz.At this point, you could have a single Ocelot API Gateway (ASP.NET Core WebHost) using one or multiple merged configuration.json files or you can also store the configuration in a Consul KV store.
Ancak, mimari ve tasarım bölümlerinde tanıtıldıkça, gerçekten otonom mikro hizmetlere sahip olmak istiyorsanız, bu tek monoparçalı API ağ geçidini birden çok API ağ geçidine ve/veya BFF (ön uç için arka uç) olarak bölmek daha iyi olabilir.But as introduced in the architecture and design sections, if you really want to have autonomous microservices, it might be better to split that single monolithic API Gateway into multiple API Gateways and/or BFF (Backend for Frontend). Bu amaçla, bu yaklaşımı Docker kapsayıcılarıyla nasıl uygulayacağınızı görelim.For that purpose, let’s see how to implement that approach with Docker containers.
Birden çok farklı API Gateway/BFF kapsayıcı türü çalıştırmak için tek bir Docker kapsayıcı görüntüsü kullanmaUsing a single Docker container image to run multiple different API Gateway / BFF container types
EShopOnContainers 'da, Ocelot API ağ geçidiyle tek bir Docker kapsayıcı görüntüsü kullanıyoruz, ancak çalışma zamanında, farklı bir Configuration. JSON dosyası sağlayarak her bir API-Gateway/BFF türü için bir Docker birimi kullanarak farklı hizmetler/kapsayıcılar oluşturuyoruz Her hizmet için farklı bir BILGISAYAR klasörüne erişin.In eShopOnContainers we’re using a single Docker container image with the Ocelot API Gateway but then, at run time, we create different services/containers for each type of API-Gateway/BFF by providing a different configuration.json file, using a docker volume to access a different PC folder for each service.
Şekil 6-33.Figure 6-33. Birden çok API ağ geçidi türü genelinde tek bir Ocelot Docker görüntüsünü yeniden kullanmaRe-using a single Ocelot Docker image across multiple API Gateway types
EShopOnContainers 'da, "genel Ocelot API Gateway Docker Image", Docker-Compose. yml dosyasında belirtilen ' OcelotApiGw ' adlı projeyle ve "eShop/ocelotapigw" görüntü adına oluşturulur.In eShopOnContainers, the “Generic Ocelot API Gateway Docker Image” is created with the project named 'OcelotApiGw' and the image name “eshop/ocelotapigw” that is specified in the docker-compose.yml file. Daha sonra, Docker 'a dağıtım yaparken, Docker-Compose. yıml dosyasında aşağıdaki ayıklama bölümünde gösterildiği gibi, aynı Docker görüntüsünden oluşturulan dört API-Gateway kapsayıcısı olacaktır.Then, when deploying to Docker, there will be four API-Gateway containers created from that same Docker image, as shown in the following extract from the docker-compose.yml file.
Ayrıca, aşağıdaki Docker-Compose. override. yıml dosyasında görebileceğiniz gibi, bu API ağ geçidi kapsayıcıları arasındaki tek fark, her bir hizmet kapsayıcısı için farklı olan ve çalışma zamanında bir Docker birimi.Additionally, as you can see in the following docker-compose.override.yml file, the only difference between those API Gateway containers is the Ocelot configuration file, which is different for each service container and it's specified at runtime through a Docker volume.
Bu önceki kod nedeniyle ve aşağıdaki Visual Studio Gezgini 'nde gösterildiği gibi, her bir iş/BFF API ağ geçidini tanımlamak için gereken tek dosya yalnızca bir Configuration. JSON dosyasıdır, çünkü dört API ağ geçitleri aynı Docker görüntüsüne dayalıdır.Because of that previous code, and as shown in the Visual Studio Explorer below, the only file needed to define each specific business/BFF API Gateway is just a configuration.json file, because the four API Gateways are based on the same Docker image.
Şekil 6-34.Figure 6-34. Her API ağ geçidini/BFF 'yi Ocelot ile tanımlamak için gereken tek dosya bir yapılandırma dosyasıdırThe only file needed to define each API Gateway / BFF with Ocelot is a configuration file
API ağ geçidini birden çok API ağ geçidine bölerek, mikro hizmetlerin farklı alt kümelerine odaklanan farklı geliştirme takımları, bağımsız Ocelot yapılandırma dosyalarını kullanarak kendi API ağ geçitlerini yönetebilir.By splitting the API Gateway into multiple API Gateways, different development teams focusing on different subsets of microservices can manage their own API Gateways by using independent Ocelot configuration files. Ayrıca, aynı anda aynı Ocelot Docker görüntüsünü yeniden kullanabilir.Plus, at the same time they can reuse the same Ocelot Docker image.
Artık, API ağ geçitleri ile eShopOnContainers çalıştırırsanız (eShopOnContainers-ServicesAndWebApps. sln çözümü açılırken veya "Docker-Compose up" çalıştırıyorsanız), aşağıdaki örnek yollar gerçekleştirilir.Now, if you run eShopOnContainers with the API Gateways (included by default in VS when opening eShopOnContainers-ServicesAndWebApps.sln solution or if running “docker-compose up”), the following sample routes will be performed.
Örneğin, webshoppingapigw API Gateway tarafından sunulan yukarı akış URL 'sini ziyaret http://localhost:5202/api/v1/c/catalog/items/2/, aşağıdaki tarayıcıda olduğu gibi, Docker konağının içindeki iç aşağı akış URL 'SI http://catalog.api/api/v1/2 aynı sonucu elde edersiniz.For instance, when visiting the upstream URL http://localhost:5202/api/v1/c/catalog/items/2/ served by the webshoppingapigw API Gateway, you get the same result from the internal Downstream URL http://catalog.api/api/v1/2 within the Docker host, as in the following browser.
Şekil 6-35.Figure 6-35. API ağ geçidi tarafından sunulan bir URL aracılığıyla mikro hizmete erişmeAccessing a microservice through a URL provided by the API Gateway
Test veya hata ayıklama nedenlerinden dolayı, API Gateway 'e geçmeden doğrudan Katalog Docker kapsayıcısına (yalnızca geliştirme ortamında) erişmek isterseniz, ' Catalog. API ', Docker Konağı (hizmeti) iç bir DNS çözümünden dolayı bulma işlemi Docker-Compose hizmeti adları tarafından işlendi), kapsayıcıya doğrudan erişmenin tek yolu, yalnızca aşağıdaki tarayıcıda http://localhost:5101/api/v1/Catalog/items/1 gibi geliştirme testleri için sunulan Docker-Compose. override. yıml içinde Yayınlanan dış bağlantı noktasıdır.Because of testing or debugging reasons, if you wanted to directly access to the Catalog Docker container (only at the development environment) without passing through the API Gateway, since 'catalog.api' is a DNS resolution internal to the Docker host (service discovery handled by docker-compose service names), the only way to directly access the container is through the external port published in the docker-compose.override.yml, which is provided only for development tests, such as http://localhost:5101/api/v1/Catalog/items/1 in the following browser.
Şekil 6-36.Figure 6-36. Sınama amacıyla bir mikro hizmete doğrudan erişimDirect access to a microservice for testing purposes
Ancak uygulama, doğrudan bağlantı noktasında "kısayollar" değil, tüm mikro hizmetlere API ağ geçitleri üzerinden erişmesi için yapılandırılmıştır.But the application is configured so it accesses all the microservices through the API Gateways, not though the direct port “shortcuts”.
EShopOnContainers 'daki ağ geçidi toplama desenininThe Gateway aggregation pattern in eShopOnContainers
Daha önce sunulmuş olduğu gibi, istek toplamayı uygulamak için esnek bir yol, koda göre özel hizmetlerle aynıdır.As introduced previously, a flexible way to implement requests aggregation is with custom services, by code. Ayrıca, Ocelot Içindeki Istek toplama özelliğiile istek toplamayı da uygulayabilirsiniz, ancak ihtiyacınız olduğu kadar esnek olmayabilir.You could also implement request aggregation with the Request Aggregation feature in Ocelot, but it might not be as flexible as you need. Bu nedenle, eShopOnContainers 'da toplamayı uygulamak için seçilen yol, her toplayıcı için açık bir ASP.NET Core Web API hizmetleriyle birlikte bulunur.Therefore, the selected way to implement aggregation in eShopOnContainers is with an explicit ASP.NET Core Web API services for each aggregator.
Bu yaklaşıma göre, API ağ geçidi bileşim diyagramı, daha önce gösterilen Basitleştirilmiş küresel mimari diyagramında görünmeyen toplayıcı Hizmetleri düşünüldüğünde çok daha fazla uzatılmış bir bittir.According to that approach, the API Gateway composition diagram is in reality a bit more extended when considering the aggregator services that are not shown in the simplified global architecture diagram shown previously.
Aşağıdaki diyagramda, toplayıcı Hizmetleri 'nin ilgili API ağ geçitleriyle nasıl çalıştığını da görebilirsiniz.In the following diagram, you can also see how the aggregator services work with their related API Gateways.
Şekil 6-37.Figure 6-37. Toplayıcı Hizmetleri ile eShopOnContainers mimarisieShopOnContainers architecture with aggregator services
Daha fazla yakınlaştırma, aşağıdaki görüntüde "alışveriş" iş alanında, API ağ geçitlerinde toplayıcı Hizmetleri kullanılırken istemci uygulamaları ve mikro hizmetler arasındaki azaltmaya azaldığını görebilirsiniz.Zooming in further, on the “Shopping” business area in the following image, you can see that chattiness between the client apps and the microservices is reduced when using the aggregator services in the API Gateways.
Şekil 6-38.Figure 6-38. Toplayıcı hizmetlerini yakından yakınlaştırınZoom in vision of the Aggregator services
Diyagram, API ağ geçitlerinden gelen olası istekleri nasıl gösterdiğine, oldukça karmaşık bir şekilde sahip olduğunu fark edebilirsiniz.You can notice how when the diagram shows the possible requests coming from the API Gateways it can get pretty complex. Mavi renkli okların nasıl basitleştiğini, bir istemci uygulamalar perspektifinden, iletişim kutusunda azaltmaya ve gecikme süresini azaltarak, uzak uygulamaların kullanıcı deneyimini önemli ölçüde geliştirerek ( Mobil ve SPA uygulamaları), özellikle.Although you can see how the arrows in blue would be simplified, from a client apps perspective, when using the aggregator pattern by reducing chattiness and latency in the communication, ultimately significantly improving the user experience for the remote apps (mobile and SPA apps), especially.
"Pazarlama" iş alanı ve mikro hizmetler söz konusu olduğunda, aggregators 'ı kullanmaya gerek olmadığı için çok basit bir kullanım durumdur, ancak gerektiğinde de mümkün olabilir.In the case of the “Marketing” business area and microservices, it is a very simple use case so there was no need to use aggregators, but it could also be possible, if needed.
Ocelot API ağ geçitlerinde kimlik doğrulama ve yetkilendirmeAuthentication and authorization in Ocelot API Gateways
Bir Ocelot API ağ geçidinde, kimlik doğrulama belirtecini veya API ağ geçidinin içinden veya içinden kimlik doğrulama belirtecini sağlayan bir ASP.NET Core Web API hizmeti gibi, kimlik doğrulama hizmetine oturtyükleyebilirsiniz.In an Ocelot API Gateway you can sit the authentication service, such as an ASP.NET Core Web API service using IdentityServer providing the auth token, either out or inside the API Gateway.
EShopOnContainers, BFF ve iş alanlarını temel alan sınırların bulunduğu birden çok API ağ geçidi kullandığından, kimlik/kimlik doğrulama hizmeti, aşağıdaki diyagramda sarı renkle vurgulanmış şekilde API ağ geçitlerinden bırakılır.Since eShopOnContainers is using multiple API Gateways with boundaries based on BFF and business areas, the Identity/Auth service is left out of the API Gateways, as highlighted in yellow in the following diagram.
Şekil 6-39.Figure 6-39. EShopOnContainers 'da kimlik hizmetinin konumuPosition of the Identity service in eShopOnContainers
Ancak, Ocelot Ayrıca, bu diğer diyagramda olduğu gibi, API Gateway sınırının içinde kimlik/auth mikro hizmetini de destekler.However, Ocelot also supports sitting the Identity/Auth microservice within the API Gateway boundary, as in this other diagram.
Şekil 6-40.Figure 6-40. Ocelot 'de kimlik doğrulamasıAuthentication in Ocelot
Önceki diyagramda gösterildiği gibi, kimlik mikro hizmeti, API ağ geçidinin (AG) altında olduğunda, 1) AG, kimlik mikro hizmetinden bir kimlik doğrulama belirteci ister 2) kimlik doğrulama belirtecini kullanarak mikro hizmetlerden gelen bir kimlik doğrulaması belirteci 3-4 döndürür.As the previous diagram shows, when the Identity microservice is beneath the API gateway (AG): 1) AG requests an auth token from identity microservice, 2) The identity microservice returns token to AG, 3-4) AG requests from microservices using the auth token. EShopOnContainers uygulaması, API ağ geçidini birden çok BFF (ön uç için arka uç) ve iş alanları API ağ geçitlerine böldüğü için, çapraz kesme sorunları için ek bir API ağ geçidi oluşturulması gerekir.Because eShopOnContainers application has split the API Gateway into multiple BFF (Backend for Frontend) and business areas API Gateways, another option would had been to create an additional API Gateway for cross-cutting concerns. Bu seçenek, birden çok çapraz kesme sorunları olan mikro hizmetlere sahip daha karmaşık bir mikro hizmet tabanlı mimaride yer alan bir şekilde yapılır.That choice would be fair in a more complex microservice based architecture with multiple cross-cutting concerns microservices. EShopOnContainers 'da yalnızca bir çapraz kesme sorunu olduğundan, basitlik 'in sake 'SI için API ağ geçidi bölgesinden yalnızca güvenlik hizmetini işlemeye karar verdi.Since there's only one cross-cutting concern in eShopOnContainers, it was decided to just handle the security service out of the API Gateway realm, for simplicity’s sake.
Herhangi bir durumda, uygulama API ağ geçidi düzeyinde güvenli hale getirildiğinden, güvenli mikro hizmeti kullanmaya çalışırken Ocelot API ağ geçidinin kimlik doğrulama modülü ilk olarak ziyaret edilir.In any case, if the app is secured at the API Gateway level, the authentication module of the Ocelot API Gateway is visited at first when trying to use any secured microservice. Bu, access_token ile korunan hizmetleri ziyaret edebilmeniz için erişim belirtecini almak üzere kimlik veya auth mikro hizmetini ziyaret etmek üzere HTTP isteğini yeniden yönlendirir.That re-directs the HTTP request to visit the Identity or auth microservice to get the access token so you can visit the protected services with the access_token.
API ağ geçidi düzeyinde herhangi bir hizmette kimlik doğrulama ile güvenli hale getirmenin yolu, AuthenticationProviderKey değerini Configuration. JSON konumundaki ilgili ayarlarında ayarlamadır.The way you secure with authentication any service at the API Gateway level is by setting the AuthenticationProviderKey in its related settings at the configuration.json.
Ocelot çalıştırıldığında, AuthenticationOptions. AuthenticationProviderKey yeniden yönlendirmeler ' a bakar ve verilen anahtara kayıtlı bir kimlik doğrulama sağlayıcısı olup olmadığını kontrol eder.When Ocelot runs, it will look at the Re-Routes AuthenticationOptions.AuthenticationProviderKey and check that there is an Authentication Provider registered with the given key. Yoksa, Ocelot başlamacaktır.If there isn't, then Ocelot will not start up. Varsa, yeniden yönlendirme bu sağlayıcıyı çalıştırıldığında kullanır.If there is, then the ReRoute will use that provider when it executes.
Ocelot WebHost, authenticationProviderKey = "IdentityApiKey" ile yapılandırıldığından, bu hizmet kimlik doğrulama belirteci olmayan herhangi bir istek olduğunda kimlik doğrulaması gerektirir.Because the Ocelot WebHost is configured with the authenticationProviderKey = "IdentityApiKey", that will require authentication whenever that service has any requests without any auth token.
Daha sonra, aşağıdaki sepet mikro hizmet denetleyicisi gibi mikro hizmetler gibi erişilecek herhangi bir kaynaktaki [Yetkilendir] özniteliğiyle yetkilendirmeyi de ayarlamanız gerekir.Then, you also need to set authorization with the [Authorize] attribute on any resource to be accessed like the microservices, such as in the following Basket microservice controller.
"Sepet" gibi Validaudide, aşağıdaki kodda olduğu gibi, başlangıç sınıfının ConfigureServices () AddJwtBearer() ile her bir mikro hizmette tanımlanan hedef kitlelerle bağıntılı.The ValidAudiences such as “basket” are correlated with the audience defined in each microservice with AddJwtBearer() at the ConfigureServices() of the Startup class, such as in the code below.
http://localhost:5202/api/v1/b/basket/1gibi API ağ geçidine dayanan bir yeniden yönlendirme URL 'SI ile sepet mikro hizmeti gibi güvenli bir mikro hizmete erişmeye çalışırsanız, geçerli bir belirteç sağlamadığınız takdirde 401 Yetkisiz bir işlem alırsınız.If you try to access any secured microservice, like the Basket microservice with a Re-Route URL based on the API Gateway like http://localhost:5202/api/v1/b/basket/1, then you’ll get a 401 Unauthorized unless you provide a valid token. Öte yandan, bir yeniden yönlendirme URL 'SI doğrulandıysa, Ocelot onunla ilişkili olan bir aşağı akış şemasını (iç mikro hizmet URL 'SI) çağırır.On the other hand, if a Re-Route URL is authenticated, Ocelot will invoke whatever downstream scheme is associated with it (the internal microservice URL).
Ocelot 'nin ReRoutes katmanında yetkilendirme.Authorization at Ocelot’s ReRoutes tier. Ocelot, kimlik doğrulamasından sonra değerlendirilen talep tabanlı yetkilendirmeyi destekler.Ocelot supports claims-based authorization evaluated after the authentication. Yeniden yönlendirme yapılandırmasına aşağıdaki satırları ekleyerek bir rota düzeyinde yetkilendirme ayarlarsınız.You set the authorization at a route level by adding the following lines to the ReRoute configuration.
Bu örnekte, yetkilendirme ara yazılımı çağrıldığında, kullanıcının belirteçte ' UserType ' talep türüne sahip olup olmadığını ve bu talebin değeri ' Employee ' olup olmadığını bulur.In that example, when the authorization middleware is called, Ocelot will find if the user has the claim type 'UserType' in the token and if the value of that claim is 'employee'. Değilse, Kullanıcı yetkilendirilmez ve yanıt 403 olarak yasaklanmış olur.If it isn’t, then the user will not be authorized and the response will be 403 forbidden.
Kubernetes ınress ve Ocelot API ağ geçitlerini kullanmaUsing Kubernetes Ingress plus Ocelot API Gateways
Kubernetes (bir Azure Kubernetes hizmet kümesinde olduğu gibi) kullanılırken, genellikle tüm HTTP isteklerini NGINXtemelinde Kubernetes giriş katmanı üzerinden birleştirmişsinizdir.When using Kubernetes (like in an Azure Kubernetes Service cluster), you usually unify all the HTTP requests through the Kubernetes Ingress tier based on Nginx.
Kubernetes 'te herhangi bir giriş yaklaşımı kullanmıyorsanız, hizmetlerinizin ve klarınızın IP 'Leri yalnızca küme ağı tarafından yönlendirilebilir.In Kubernetes, if you don’t use any ingress approach, then your services and pods have IPs only routable by the cluster network.
Ancak, bir giriş yaklaşımı kullanıyorsanız Internet ve hizmetleriniz (API ağ geçitleriniz dahil) arasında bir orta katman ve ters proxy görevi gören bir orta katmanınız olacaktır.But if you use an ingress approach, you'll have a middle tier between the Internet and your services (including your API Gateways), acting as a reverse proxy.
Bir tanım olarak, giriş, gelen bağlantılara küme hizmetlerine ulaşmasına izin veren kuralların koleksiyonudur.As a definition, an Ingress is a collection of rules that allow inbound connections to reach the cluster services. Giriş genellikle hizmetlere dışarıdan erişilebilen URL 'Ler, Yük Dengeleme trafiği, SSL sonlandırma ve daha fazlası sağlamak üzere yapılandırılır.An ingress is usually configured to provide services externally reachable URLs, load balance traffic, SSL termination and more. Kullanıcılar giriş kaynağını API sunucusuna naklederek giriş isteği ister.Users request ingress by POSTing the Ingress resource to the API server.
EShopOnContainers 'da, yerel olarak geliştirilirken ve yalnızca bir geliştirme makinenizi Docker Konağı olarak kullanırken, yalnızca birden fazla API ağ geçidi kullanmayın.In eShopOnContainers, when developing locally and using just your development machine as the Docker host, you are not using any ingress but only the multiple API Gateways.
Ancak, Kubernetes tabanlı bir "üretim" ortamını hedeflerken eShopOnContainers, API ağ geçitlerinin önünde bir giriş kullanıyor.However, when targeting a “production” environment based on Kubernetes, eShopOnContainers is using an ingress in front of the API gateways. Bu şekilde, istemciler yine de aynı temel URL 'YI çağırır, ancak istekler birden fazla API ağ geçidine veya BFF 'ye yönlendirilir.That way, the clients still call the same base URL but the requests are routed to multiple API Gateways or BFF.
API ağ geçitlerinin ön uçları veya façades, genellikle kapsamlarından çıkan Web uygulamalarına değil, yalnızca hizmetlere yönelik olduğunu unutmayın.Note that API Gateways are front-ends or façades surfacing only the services but not the web applications that are usually out of their scope. Ayrıca, API ağ geçitleri bazı iç mikro hizmetleri gizleyebilir.In addition, the API Gateways might hide certain internal microservices.
Ancak giriş, HTTP isteklerini yeniden yönlendirse de herhangi bir mikro hizmeti veya Web uygulamasını gizlemeyi denememelidir.The ingress, however, is just redirecting HTTP requests but not trying to hide any microservice or web app.
Web uygulamalarının önündeki Kubernetes 'de bir giriş Nginx katmanına sahip olmak ve çeşitli Ocelot API ağ geçitleri/BFF, aşağıdaki diyagramda gösterildiği gibi ideal mimaridir.Having an ingress Nginx tier in Kubernetes in front of the web applications plus the several Ocelot API Gateways / BFF is the ideal architecture, as shown in the following diagram.
Şekil 6-41.Figure 6-41. Kubernetes 'e dağıtıldığında eShopOnContainers içindeki giriş katmanıThe ingress tier in eShopOnContainers when deployed into Kubernetes
Kubernetes girişi, genellikle API ağ geçidi kapsamından çıkan Web uygulamaları dahil olmak üzere, uygulamaya yönelik tüm trafik için ters proxy görevi görür.A Kubernetes Ingress acts as a reverse proxy for all traffic to the app, including the web applications, that are usually out of the Api gateway scope. EShopOnContainers 'ı Kubernetes 'e dağıttığınızda, temel olarak yalnızca birkaç hizmet veya uç nokta Ile URL'lerde aşağıdaki postdüzeltmelerin listesini sunar:When you deploy eShopOnContainers into Kubernetes, it exposes just a few services or endpoints via ingress, basically the following list of postfixes on the URLs:
istemci SPA Web uygulaması için // for the client SPA web application
istemci MVC web uygulaması için /webmvc/webmvc for the client MVC web application
durum/healthdenetimleri gösteren istemci Web uygulaması için /webstatus/webstatus for the client web app showing the status/healthchecks
Web BFF ve alışveriş iş işlemlerine yönelik /webshoppingapigw/webshoppingapigw for the web BFF and shopping business processes
Web BFF ve pazarlama iş işlemlerine yönelik /webmarketingapigw/webmarketingapigw for the web BFF and marketing business processes
Mobil BFF ve alışveriş iş işlemlerine yönelik /mobileshoppingapigw/mobileshoppingapigw for the mobile BFF and shopping business processes
Mobil BFF ve pazarlama iş işlemlerine yönelik /mobilemarketingapigw/mobilemarketingapigw for the mobile BFF and marketing business processes
Kubernetes 'e dağıtım yaparken, her Ocelot API ağ geçidi, API ağ geçitlerini çalıştıran her Pod için farklı bir "Configuration. JSON" dosyası kullanıyor.When deploying to Kubernetes, each Ocelot API Gateway is using a different “configuration.json” file for each pod running the API Gateways. Bu "Configuration. JSON" dosyaları, ' Ocelot ' adlı bir Kubernetes yapılandırma eşlemesi temel alınarak oluşturulan bir birimi bağlama tarafından sağlanır (başlangıçta Deploy. ps1 betiği ile).Those “configuration.json” files are provided by mounting (originally with the deploy.ps1 script) a volume created based on a Kubernetes config map named ‘ocelot’. Her kapsayıcı, /app/configuration adlı kapsayıcı klasöründe ilgili yapılandırma dosyasını takar.Each container mounts its related configuration file in the container’s folder named /app/configuration.
EShopOnContainers kaynak kodu dosyalarında, özgün "Configuration. JSON" dosyaları k8s/ocelot/ klasörü içinde bulunabilir.In the source code files of eShopOnContainers, the original “configuration.json” files can be found within the k8s/ocelot/ folder. Her BFF/APIGateway için bir dosya vardır.There’s one file for each BFF/APIGateway.
Bir Ocelot API ağ geçidinde ek çapraz kesme özellikleriAdditional cross-cutting features in an Ocelot API Gateway
Aşağıdaki bağlantılarda açıklanan bir Ocelot API ağ geçidi kullanırken araştırmak ve kullanmak için kullanabileceğiniz diğer önemli özellikler vardır.There are other important features to research and use, when using an Ocelot API Gateway, described in the following links.
İstemci tarafındaki hizmet keşfi, Cell veya Eureka ile tümleştirme Service discovery in the client side integrating Ocelot with Consul or Eureka
API ağ geçidi katmanında önbelleğe alma Caching at the API Gateway tier
API ağ geçidi katmanında günlüğe kaydetme Logging at the API Gateway tier
API ağ geçidi katmanında hizmet kalitesi (yeniden denemeler ve devre kesiciler) Quality of Service (Retries and Circuit breakers) at the API Gateway tier
Hız sınırlandırma Rate limiting
Önceki İleriPrevious Next