Ocelot Gateway Nedir? (ASP.NET Core Kurulum ve Örnek Proje)

Ocelot Gateway Nedir?

Ocelot, mikro hizmet mimarilerindeki karmaşıklığı azaltarak API yönetimini kolaylaştıran güçlü bir araçtır. Bu API gateway çözümü, farklı hizmetler arasında iletişimi düzenlerken tek bir noktadan tüm istekleri yönetme avantajı sağlar. Ocelot, gelen istekleri yönlendirirken yetkilendirme, güvenlik kontrolleri ve trafik yönetimi gibi kritik işlevleri de bünyesinde barındırır. Ayrıca, esnek yapıya sahip olması sayesinde farklı protokollerle uyumlu çalışabilir ve uygulama geliştiricilerine ölçeklenebilir, güvenli ve performansı yüksek bir API yönetimi deneyimi sunar. Özetle ufak çaplı projelerinizden tutun büyük çaplı projelerde sizlere gateway çözümü sunar.

Mikro Hizmet Mimarileri ve API Gateway Kavramı

Mikro hizmet mimarilerinin merkezindeki önemli unsurlardan biri olan API gateway, karmaşık sistemlerin iletişimini kolaylaştırmak ve merkezi bir kontrol noktası sağlamak için kritik bir rol oynar. Ocelot, bu bağlamda, farklı mikro hizmetler arasında bir köprü oluşturarak, gelen istekleri yönetmek, güvenlik önlemlerini uygulamak ve verimli bir trafik yönetimi gerçekleştirmek üzere tasarlanmış güvenilir bir çözümdür. API gateway olarak kullanıldığında Ocelot, heterojen sistemlerdeki farklılıkları gizler ve uygulama geliştiricilerine basitleştirilmiş bir iletişim ve yönetim deneyimi sunar. Böylece, mikro hizmet mimarilerinin verimli bir şekilde çalışmasına katkıda bulunur ve sistemler arası iletişimi şeffaf hale getirir.”

Ocelot’un Temel Özellikleri ve Çalışma Prensibi

Ocelot, API gateway olarak çalışırken esnek ve modüler bir yapı sunarak farklı servisler arasındaki iletişimi kolaylaştırır. Çalışma prensibi, gelen istekleri belirli yönlendirmelere göre işleyerek, önceden tanımlanmış yönlendirmeler doğrultusunda ilgili servislere iletmek üzerine kuruludur. Bu kütüphane, bir dizi özelliği içinde barındırarak istemcilerden gelen istekleri alır, yönlendirir, filtreler ve servisler arasında iletişimi sağlar. Ayrıca, istemcilerle ve servislerle arasında gerçekleşen iletişimi izleme ve günlükleme gibi ek işlevselliğiyle de dikkat çeker. Ocelot’un esnek konfigürasyon yetenekleri sayesinde, gelen istekleri yönlendirmek için basit ve anlaşılır bir yapı kurulabilir, bu da geliştiricilere geniş bir özelleştirme imkanı sunar.

Nasıl Kurulur ve Kullanılır?

Örneğimizi basit, esnek ve birden fazla servis ile iletişim kuracak şekilde yapacağız.

Öncelikle kullanacağınız ocelet ve bize configurasyonu kolaylık salaaycak ek kütüphaneleri yükleyeceğiz. Kullanacağınız .net versiyonuna göre paketlerin versiyonu değişebilir bu sebeple versiyon belirmeden devam edeceğiz.

API Gateway arkasına 3 servis ekleyerek dışarıdan gelen tüm istekleri tek bir Ocolet API projesine yönlendirip istekleri ilgili servislerine yönlendirmesini gerçekleştirecek. Örnek şemamız bu şekilde olacaktır;

4 Adet proje oluşturacağız. Bir tane Ocelot’un olacağı proje ve 3 tanede örnek projede burada 3 yerine 1,2 veya çok sayıda olabilir biz örneğimizi 3 tane ile yapacağız daha iyi anlaşılabilir olaması için

• APIGateway
• AuthService
• ProductService
• BasketService

APIGateway Projesi için Ocelot, configurasyon ve swagger entegrasyonu için 3 kütüphaneyi yükleyelim.

nuget install MMLib.Ocelot.Provider.AppConfiguration

nuget install MMLib.SwaggerForOcelot

nuget install Ocelot

builder build olmadan önce ilgili configurasyon tanımlarını eklenir. Folder özelliği aslında Ocelot ayarlarını gireceğimiz json dosyasının dizini belirtiyoruz.

builder.Configuration.AddOcelotWithSwaggerSupport(options =>
{
    options.Folder = "OcelotConfiguration";
});
builder.Services.AddOcelot(builder.Configuration).AddAppConfiguration();
builder.Services.AddSwaggerForOcelot(builder.Configuration);

Builder build ettikten sonra gateway içinde bağlı olduğu projelerinin swagger dokümantasyonlarını içeri aktarmak için UseSwaggerForOcelotUI tanımı eklenir. UseOcelot ise standart Ocelot kütüphanesi için ekleme yapılır.

app.UseSwaggerForOcelotUI(opt =>
{
    opt.PathToSwaggerGenerator = "/swagger/docs";
});
app.UseOcelot().Wait();

Üstte belirttiğimiz sadece ocelot için yapmamız gereken değişiklerdir. Oluşturulan boş bir ASP.NET Core projesine üsttekileri eklediğimizde nihayi Program.cs artık bu şekilde olmasını bekliyoruz.

Sıra Ocelot konfigürasyonlarının okunacak JSON dosyalarının tanımını yapmaya geldi.

Her projede ayrı bir JSON konfigürasyonu girebiliriz, ancak daha okunabilir ve ileride projelerimizde bu konfigürasyonların genişleyebilme ihtimalleri olduğundan dolayı ayrı dosyalarda tanımlamayı tavsiye ediyorum. Auth servisi için tüm endpointler için tanımlama yapabiliriz, ancak basit bir gateway örneği yaptığımız için tüm uçları tek bir konfigürasyon dosyası ile yönlendirme yapacağız.

Aşağıda tanımlayacağımız parametreleri belirtiyorum:

• SwaggerKey: Bağlanacağı servisin Swagger konfigürasyonunu alacak olan anahtar. Bu ayarı aşağıda ocelot.SwaggerEndpoints.json dosyası ile ilişkilendireceğiz.
• DownstreamPathTemplate: İstek karşılandığında Auth servisine hangi formatta isteğin yönlendirileceğini belirtiyoruz.
• ServiceName: appsettings.json üzerinde Auth servisinin iç ağdaki adresini tanımlarken eşleştirme yapacağımız anahtar.
• UpstreamPathTemplate: Gateway'e gelen istekleri karşılayacağımız prefix/url tanımlaması yapılır. Tek bir konfigürasyon olduğunda eklediğimiz prefix, gateway kapsamında benzersiz olmalıdır. Örneğin, "/auth-gate/" ile başlayan tüm istekleri AuthService'e yönlendirecektir.
• UpstreamHttpMethod: İzin verilen HTTP metodları eklenir. {everything} ile bir değişken gibi kullanılır, yani herhangi bir şey yazabilirsiniz ve özel bir anahtar kelime değildir. Downstream ve Upstream tarafında da aynı değişkeni kullandık.

Diğer Product ve Basket servis için ilgili json configler bunlara göre girebiliriz.

Şimdi eklediğimiz servislerin Swagger bağlantılarını kuracağız. Bu adım zorunlu olmasa da, bu yeteneği belirtmek istiyorum.

Gateway projemizde, OcelotConfiguration klasörü içinde ocelot.SwaggerEndpoints.json adında bir JSON dosyası oluşturalım. Bu dosyanın içine projeye özgü Swagger konfigürasyonlarını ekleyelim. Genellikle bu konfigürasyonlar tüm projeler için aynı olur. Buradaki amaç, ilgili Swagger key ile ilişkilendirerek swagger.json konumunu belirtmektir. Böylelikle gateway, bağlı olduğu projelerini sanki kendi Swagger dokümantasyonu gibi göstermesini sağlar. Runtime'da ilgili swagger.json endpointinden ayarları çekip tek bir projede sunum yapmaktadır.

Şimdiye kadar 3 adet servisi oluşturduk ve bu servislerin Swagger ayarlarını yapmış bulunmaktayız. Ancak, Product, Basket ve Auth servislerini hangi adreste bulacağımızı henüz belirtmedik. Bu bilgileri ocelot.product.json, ocelot.auth.json ve ocelot.basket.json dosyalarında belirleyebilirdik, ancak bu base URL'lerin sabit kalmayacağı ve bu bilgilerin Ocelot konfigürasyonlarına bağlı olacağı varsayımıyla, bu bağımlılığı appsettings.json gibi projenin genel ayarlarına taşıyacağız. Bu bir zorunluluk değil, sadece bir alternatiftir.

Örneğin, Azure Portal’da bir web uygulamasında uygulamanızı tekrar deploy etmeden Configuration sekmesinden istediğiniz özelliği değiştirebilirsiniz.

Product, Basket ve Auth servislerinin DownstreamPath (yani ilgili servislerin BaseUrl adreslerini) burada tanımlayacağız. Ocelot'a bir istek geldiğinde, bu adreslere yönlendirerek ilgili servisleri çağıracaktır.

Böylece, ilgili servislerimizin adresleri zaman içinde değişirse, kullandığımız bulut servislerinden appsettings.json dosyasını güncelleyerek adresleri değiştirebiliriz. DownstreamPath'in appsettings.json dosyasından alınabilmesi için, ocelot.global.json dosyamızı diğer JSON dosyaları gibi OcelotConfiguration dizinine ekleyip, provider'ı AppConfiguration olarak atayalım.

Bundan sonraki adımlarımız, bu üç servisi oluşturmak ve içlerine örnek endpointler eklemek olacak. Ancak, Ocelot için özel herhangi bir yapılandırma düzenlemesi yapmamamız gerektiği için siz örnek web API projelerini oluşturabilirsiniz. Sadece bu servisler başlatıldığında, 7001, 7002 ve 7003 portları üzerinden hizmet verecek şekilde launchSettings.json dosyanızı düzenlemeniz veya uygulamaları başlattığınızda URL'leri ayarlamanız yeterli olacaktır.

Örnek projeye bu bağlantından erişebilirsiz

GitHub - fatihgurdal/ocelot-gateway-medium

Ben Rider IDE kullanıyorum ve çoklu projeleri başlatmak için Compound özelliğini ekledim. Farklı IDE’lerde de benzer özellikler mevcut; projeleri profillerinden seçerek HTTP olanları başlatabilirsiniz. appsettings.json dosyasındaki downstreampath linkleri, HTTP profillerindeki adresleri varsayılan olarak tanımladım.

Projemizi başlatalım ve tarayıcımızda artık Gateway projemizin Swagger adresini /swagger olarak açtığımızda aşağıdaki gibi bir ekran karşımıza çıkacaktır. Ocelot ile Swagger konfigürasyonlarını entegre ettiğimiz için sağ üst köşeden bağladığımız Auth, Product ve Basket servislerinin Swagger'ları arasında geçiş yapabilir, tüm endpointleri görebilir ve kullanabilir durumda olacaksınız.

Zaten amaçlarımızdan biri olan Gateway üzerinden diğer servislere yapılan istekleri görmek için örnek yapmaktı. Bu Swagger, ocelot.SwaggerEndpoints.json dosyasında yaptığımız konfigürasyon ile belirttiğimiz path üzerinden ilgili JSON'ı çeker ve runtime'da import yapar. Eğer ilgili servisin Swagger'ı açılmıyorsa, downstreampath olarak belirttiğimiz adreste servisi bulamamışız demektir. Bu Swagger'ı görmek aslında bağlantının başarıyla kurulduğunun bir kanıtıdır.

Beklentimiz, /auth-gate/*** ile başlayan tüm isteklerin, appsettings içinde belirttiğimiz downstreampath adresine yönlendirilmesidir. Bu adres, http://localhost:7002/api/*** şeklindedir. Bu ayarları, bildiğiniz gibi ocelot.auth.json dosyasında belirttik.

auth-gate/Auth/GetUser ucuna token üretmeden istekte bulunduğumuzda beklediğimiz gibi 401 kodlu http hata kodunu alıyoruz.

Şu anda, GetToken ucu ile elde ettiğim token’u kullanarak gönderdiğim isteğe 200 OK yanıtını alıyorum. Yaptığımız basit konfigürasyon ile gateway üzerinden yönlendirilen tüm isteklerin, Authorization başlığı ile yapılan testlerle gösterildiğini görüyoruz.

ProductService

Product Service

BasketService

BasketService

1 API Gateway ile 3 servisi entegre ettik. Makalemizde, AuthService ile oturum zorunluluğu olan ve olmayan iki farklı senaryoda örnekler gerçekleştirdik. Ayrıca, bağlı 3 servisin Swagger konfigürasyonlarını detaylı bir şekilde anlattık. Diğer iki servise dummy veri dönen birer endpoint ekleyerek örnek projemizi tamamladık.

Sonuç olarak, Ocelot, mikro hizmet mimarilerinin karmaşıklığını azaltan ve API yönetimini büyük ölçüde kolaylaştıran güçlü bir araçtır. Esnek yapısı, modüler tasarımı ve sürekli geliştirilen özellikleri sayesinde, geliştiricilere geniş bir özelleştirme ve uyarlanabilirlik imkanı sunar. Farklı servisler arasında sorunsuz iletişim kurmayı sağlar ve bu da mikro hizmet tabanlı uygulamaların daha etkili ve sürdürülebilir olmasına olanak tanır. Mikro hizmetlerinizi tek bir noktadan yönetebilir ve istediğiniz şekilde yönlendirmeleri kolayca gerçekleştirebilirsiniz. Makalemizde kurulumu basit ve birden fazla servis örneği ile somut bir örnek sunmaya çalıştım. Ancak, Ocelot’un yetenekleri sadece bunlarla sınırlı değildir; farklı ihtiyaçlara çeşitli alternatifler sunmaktadır (örneğin, Load balancing, SignalR WebSocket vb.).