Herkese Merhaba, bu makalemde Ocelot'a değiniyorum. Ocelot'u projelelerimizde sıklıkla kullanıyorum ama bilmediğimiz veya kullanmadığımız çok fazla özelliği olduğunu düşünüyorum, ben bu makalede biraz detayına girdim.
Aşağıdaki konuları ele alalım.
Api Gateway nedir ?
Api Gateway ile neler yapılabilir ?
Api Gateway avantajları.
Ocelot nedir ?
Ocelot' u dağıtırken kullandığımızı yapılandırmalar.
Basic Implementation.
Identity Server kullanımı.
Çoklu Instance durumları.
Consul ile kullanımı.
Service Fabrik ile kullanımı.
.Net uygulamalarında Ocelot kullanımı.
Ocelot Authentication Server (JWT).
Ocelot Rate Limiting.
Ocelot Caching.
API GATEWAY NEDİR ?
Mobil veya Web uygulamalarımızın veya farklı Client uygulamalarının, Server'larımıza güvenli bir şekilde istek atmasını sağlamak istiyorsak bir Api Gateway kullanabiliriz.
Api Gateway'lerin çok fazla yetenekleri vardır ama temel anlamda, Client lardan gelen Request bilgilerini ilgili servis veya servislere yönlendirir. Bu yönlendirme işleminin güvenliğinide sağlamaktadır.
Client uygulamaları için, İş mantığına veya işlevlere erişmesini sağlayan giriş kapısıdır.
Api Gateway, yüz binlerce API çağrısının kabul edilip işlenmesi için gerekli olan trafik yönetimini sağlar.
Kısıtlama, erişim yönetimi, izleme, loglama ve API sürüm yönetimi gibi görevleri üstlenir.
API GATEWAY İLE NELER YAPILABİLİR ?
Authentication – Authorization : Api Gateway üzerinden, Authentication ve Authorization güvenlik süreçlerini yönetebiliriz. Authentication kavramı kimlik doğrulama anlamına gelmektedir. Uygulamayı kimin kullanılması gerektiği bilgisini verir. Authorization ise yetkilendirme süreçlerini yönetir. Kimin hangi servislere yetkisi var vb.
Logging : Api gateway üzerinden tüm servislerimize gelen request ve response’ları detaylı loglayabiliriz.
Response Caching : API gateway ile kalıcı ve belli aralıklarda değişmeyecek Response datasını cachleyebilirsiniz. Böylece, endpointe giden istek süresini düşürebiliriz.
Routing : API gateway ile client ve server arasındaki route’ları yönetebilirsiniz.
Rate Limiting : Api Gateway ile gelen requestlere limit koyabilir çok fazla istek var ise önleme yapabilirsiniz. Limit zaman cinsinden ne kadar sıklıkla Request atılacağı bilgisini handle edebilir.
Load Balancing : Api Gateway ile, birden fazla HOST ve PORT tanımlayabiliriz. Bu tanımlamalar Load Balancing ile yönlendirilmesi sağlanacaktır. İstersek kendi Custom Load Balancing sürecimizi yazabiliriz.
Request Aggregation :
GraphQL : GraphQL i Gateway üzerinde kullanabiliriz,
Service Discovery : Consul, Eureka vb gibi Service Discovery yapılarını kullanabiliriz.
Tracing : Api Gateway üzerinden izleme modunu çalıştırabiliriz.
API GATEWAY AVANTAJLARI
Client'lara, API lerin mikroservisler bazında nasıl ayrıldığı hakkında bilgi vermiş olur.
Yazdığımız API lerin istediğimize yönlendirmesini sağlayabiliriz.
Güvenlik, Loglama veya izleme gibi yapıları yönetebiliriz.
Request ve response sayılarında azalma sağlanabilir. Burada iki farklı API den tek request ile işlem yapılabilmesini örneklendirebiliriz.
Versiyonlama işlemlerimizi yapabiliriz.
Ağ performansı ayarlanabilir.
NOT : Yukarıdaki resimi incelediğimizde yapıyı net şekilde anlayabiliyoruz. Biz bu makalede Ocelot üzerinden gideceğiz ve şu anda Ocelot da gRPC desteği yok. ama önümüzdeki dönemde gelecektir.
Fakat bu durum canınızı sıkmasın, gRPC teknolojinini yazacağımız bir Client ile handle edip bu Client API nin Ocelot tarafından tületimini sağlayabiliriz.
OCELOT NEDİR ?
Ocelot, .Net uygulamalarında kullanabileceğimiz, mikro servisler odaklı bir api gateway kütüphanesidir.
Client lardan gelen Request Modelini, Ocelot Route lara tanımlanmış API lere HttpRequestMessage olarak yönlendiren bir teknolojidir.
Ocelot API leri belirli bir sırada çalıştıran ve yöneten ara katman yazılımıdır.
Ocelot'un Routing, GraphQL, Service Discovery, Authentication, Rate Limiting, Caching, Logging, Tracing, Load balancing gibi daha bir çok güzel özelliği vardır.
Ocelot temel anlamda bir konfigurasyon dosyasıdır. Bütün süreçlerimizi bu dosyadan yönetiriz tabiki harici Middleware ler yazılabilir ve kapsamlı işler çıkartılabilir.
{"Routes": [ {"DownstreamPathTemplate": "/api/posts/{postId}","DownstreamScheme": "https","DownstreamHostAndPorts": [{"Host": "localhost","Port": 80,}], "UpstreamPathTemplate": "/posts/{postId}","UpstreamHttpMethod": [ "Put", "Delete" ]} ]}
Örnek bir Ocelot configuration dosyası aşağıdaki gibidir.
Örnek demo video'sunda bu configurasyon üzerinden konuştuk.
OCELOT'U DAĞITIRKEN KULLANDIĞIMIZ YAPILANDIRMALAR
Basic Implementation.
Birden fazla farklı teknolojiler ile yazılan Client’dan gelen istekleri,
Ocelot tarafından daha önceden tanımlanmış servislere gönderen default olarak kullanılan implementasyondur.
Arada bir Ocelot Gateway vardır, Tanımlanan Service lere Clientlardan gelen istekleri direk yönlendirir.
IdentityServer Kullanıldığında.
Ocelot a tanımlanan servislerin güvenliğinin sağlanması adına,
Gateway tarafında IdentityServer kullanılabilir.
JWT gibi token alma süreçlerini yönetir ve güvenli şekilde servis yönlendirmesi yapar.
Middleware seviyesinde handle edilen bu süreçte istediğimiz gibi bir token yapısı kurabilir, güvenliği sağlayabiliriz.
Ocelot konfigurasyonunda tanımlanan Service API lerin yanında birde IdentityServer yönlendirmesi yapılır. bu yönlendirme işlemini Ocelot kontrol eder eğer yetkisiz veya tokensiz bir istekde durumu kontrol eder ve öncelikle Authentication işlemlerinin yapılmasını zorlar. Neticede Token almadan yönlendirme işlemleri yapmamız imkansızdır.
Ama bazı durumlarda Token almadan bazı servislere ulaşmamız gerekmektedir. Bu değişikliğide Ocelot konfigurasyonda yapabiliyoruz.
Çoklu Instance Durumlarda.
Load balancer ile, birden fazla instance oluşturulan gateway üzerinden istekleri karşılar ve daha önceden tanımlanan servislere yönlendirir.
Bir API yi iki farklı conteinerda yayınladığımızı düşünelim, Ocelot tarafında bu PORT bilgisi tanımlandığında Yönlendirme işlemleri Ocelot tarafından yapılabilir. Burada bir Load balancing işleminden den bahsediyoruz. Aynı zamanda Ocelot Gateway imizide farklı containerlarda çalıştırabilir ve Load balancing işlemlerimizi yapabiliriz.
Consul ile kullanıldığında.
Ocelot'da en güvenilir olduğu yapının Service discovery olduğunu düşünüyorum. Ocelot arka planda kendisine tanımlanan API ye istek gönderir ve gerisine karışmaz. Consul ayakta olan API yi bulur ve isteği ona yönlendirir.
Ocelot ile Eureka da kullanılabiliyor.
Service Fabric ile kullanıldığında.
Service Fabric ile yönettiğimiz mikro servislerin bir uçlarını Ocelot'a bağlayabiliriz.
Servis Fabric çok kapsamlı bir konu ama genel mantıkta, kendi yönettiğimiz ve ölçeklenebilir sistemler geliştirmemiz için sunulan bir sistemdir.
.NET UYGULAMALARINDA OCELOT KULLANIMI
Yeni bir ASP.NET Core Web Api projesi oluşturulur. Ardından NugetPackage den Ocelot paketi projeye indirilir.
Sırası ile Program.cs ardından Startup.cs de bir takım işlemler yapmamız gerekmektedir.
Program.cs
.ConfigureLogging(logging => logging.AddConsole()); //Console ekranında Gelen istek ve yönlendirilen servis loglanır ve gösterilir.
Environment : ocelot.json konfigurasyon dosyasını farklı environmentlarda farklı servislere yönlendirmesi yapılabilir.
UseUrls : Api Launchsettings değilde buradaki portdan ayağa kalsın.
OCELOT AUTHENTICATION (IDENTITY SERVER)
Ocelot Route ların kimlik doğrulamalarını yapabilir. Kullanıcı Kimlik doğrulama işlemi Client dan gelen Token vasıtası ile işlenir ve güvenli bir Route işlemi yapmış olur.
JWT Token kullanarak kullanıcı kimlik doğrulama işlemlerimizi yapabiliriz.
Ocelot Gateway API içerisinde yapılması gerekenler.
(Gateway)Startup.cs (Schema (authenticationProviderKey ) ile JWT konfigurasyon)
Startup.cs içerisinde 2 şekilde token config ayarlanması yapılabilmektedir. authenticationProviderKey ile kullanımı aşağıda gösterilmiştir. Eğer authenticationProviderKey ile kullanım olucak ise diğer tüm servislerde’de bu authenticationProviderKey in aşağıdaki startup congigurasyonun aynısı olması gerekmektedir.
Ocelot tarafından doğrulanacak isteği bu schema ile ayırt edebilecek ve Alt servisler ile ilişkilendireceğiz. Böylece APIGateway’de doğrulanan token Servislerde!de doğrulanmış olacaktır.
(Gateway)Startup.cs (Default JWT Konfigurasyon)
JWTModel.cs
ocelot.Development.json
NOT : AuthenticationProviderKey Default olarak tanımlandığında bu property değeri “Bearer” olmalıdır.
Client tarafında Token ve kullanıcı kimlik doğrulama işlemi yapılan servislerde aşağıdaki gibi JWT Token config ayarlaması yapılması gerekmektedir.
AuthenticationProviderKey ile kullanımında ise. AuthenticationProviderKey kullanıldığı durumda; tüm servislerde aşağıdaki gibi bir değişiklik yapmamız gerekecek.
Kimlik doğrulama kullanacak servisleri yukarıdaki gibi değiştirdiğimizde, yukarıda verilen hata ortadan kalkacaktır.
Ocelot Gateway çalıştığında, Routes.AuthenticationOptions.AuthenticationProvideKey’ e bakacak, Startup da tanımlanan AuthenticationProvideKey bilgisi ni kontrol edecek. Eğer yoksa veya yanlış ise Ocelot çalışmayacaktır hata verecektir.
Yukarıdaki gibi bir hata aldığımızda, Bu oluşturulan Schema nın Kullanıcı kimlik denetimi yapan servislerde tanımlanmadığı anlamına gelmektedir.
Yukarıdaki işlemler yapıldığında, JWTModel isterlerine göre oluşturulmuş bir Token ile Ocelot servis route ları kullanılabilir.
Ocelot kimliksiz isteklerde veya token süresi dolmuş ise ; 401 Unauthorized hatasını fırlatır.
Attributes | Description |
DownstreamPathTemplate | Arka tarafta yönlendirilecek Servislerin endpointlerinin tanımlandığı bölümdür. "DownstreamPathTemplate": "/weatherforecast", "DownstreamScheme": "http", "DownstreamHostAndPorts": [ { "Host": "localhost", "Port": 5001 } ] |
RouteIsCaseSensitive | UpstreamPathTemplate, yazıldığı gibi olmalı, Weather ile istek geldiğinde hata verecektir. true : Yazıldığı gibi olmalı. false : Büyük, Küçük harf duyarlı değildir. "RouteIsCaseSensitive": true |
UpstreamPathTemplate | Ocelot a yapılacak istek için oluşturulmuş yeni servis end pointidir. "UpstreamPathTemplate": "/api/weather" |
UpstreamHttpMethod | Ocelot’a gelecek olan isteğin HTTP METHOD TYPE ının belirlendiği ayardır. "UpstreamHttpMethod": [ "Get",”Post” ] |
AuthenticationOptions | Kullanıcı Kimlik denetimi için yapılan Config ayarlarıdır. "AuthenticationOptions": { "AuthenticationProviderKey": "MyOcelot", "AllowedScopes": [] } |
AuthenticationProviderKey | Startup.cs de tanımlanan authenticationProviderKey buradada verilmelidir. İlk Startup.cs resminde görüldüğü üzere “MyOcelot” şeklinde tanımlanmıştır. Bu şekilde tanımlamada, ocelot.json içerisinde’de bu propertye tanımlanmalıdır. Aynı zamanda Ocelotun alt servisleride bu tanımlamayı aynen yapmalıdır. "AuthenticationProviderKey": "MyOcelot", Eğer ikinci Startup.cs resminde olduğu gibi bir değer verilmeyip defaul schema kullanılacak ise. Bu alana Bearer yazılması gerekmektedir. "AuthenticationProviderKey": "Bearer", |
Yukarıda, JWTModel isterlerine göre oluşturulan bir Token gösterilmiştir.
JWT Konusunu anlattığım makaleme buradan erişebilirsiniz.
OCELOT RATE LIMITING
Ocelot, Upstream (aşağı akış) hizmetlerini aşırı yüklenmemesi için, İsteklere limit koyabilmektedir.
ClientWhiteList | Bu, istemcinin beyaz listesini içeren bir dizidir. Bu dizideki istemcinin hız sınırlamasından etkilenmeyeceği anlamına gelir. |
EnableRateLimiting | Bu değer, bitiş noktası hız sınırlamasını etkinleştirmeyi belirtir. |
Period | Bu değer, 1s, 5m, 1h,1d vb. gibi sınırın geçerli olduğu süreyi belirtir. Dönem içinde sınırın izin verdiğinden daha fazla istekte bulunursanız, başka bir istekte bulunmadan önce PeriodTimespan süresinin dolmasını beklemeniz gerekir. |
PeriodTimespan | Bu değer, belirli sayıda saniye sonra yeniden deneyebileceğimizi belirtir |
Limit | Bu değer, bir istemcinin belirli bir süre içinde yapabileceği maksimum istek sayısını belirtir. |
Yukarıdaki ayarları UpstreamPathTemplate içerisnde yapabiliyorken, aşağıdaki ayarları GlobalConfiguration da yapabiliriz.
DisableRateLimitHeaders | Bu değer, X-Rate-Limit ve Retry-After başlıklarının devre dışı bırakılıp bırakılmayacağını belirtir. |
QuotoExceedMessage | Bu değer aşılmış mesajı belirtir. |
HttpStatusCode | Bu değer, hız sınırlaması gerçekleştiğinde döndürülen HTTP Durum kodunu belirtir. |
ClientIdHeader | İstemcileri tanımlamak için kullanılması gereken üstbilgiyi belirtmenize olanak tanır. Varsayılan olarak “ClientId”dir |
{ "Routes": [ { "DownstreamPathTemplate": "/weatherforecast", "DownstreamScheme": "http", "DownstreamHostAndPorts": [ { "Host": "localhost", "Port": 5001 } ], "UpstreamPathTemplate": "/api/weather", "UpstreamHttpMethod": [ "Get" ], "RouteIsCaseSensitive": true, "AuthenticationOptions": { "AuthenticationProviderKey": "MyOcelot", "AllowedScopes": [] }, "RateLimitOptions": { "ClientWhitelist": [], "EnableRateLimiting": true, "Period": "1s", "PeriodTimespan": 1, "Limit": 1 } }, { "DownstreamPathTemplate": "/api/login", "DownstreamScheme": "http", "DownstreamHostAndPorts": [ { "Host": "localhost", "Port": 5002 } ], "UpstreamPathTemplate": "/api/login", "UpstreamHttpMethod": [ "Get" ], "RouteIsCaseSensitive": true } ], "GlobalConfiguration": { "RateLimitOptions": { "DisableRateLimitHeaders": true, "QuotaExceededMessage": "API çağrıları kotası aşıldı! Sistemi fazla yoramazsınız !", "HttpStatusCode": 999, "ClientIdHeader": "Test" } } }
Yukarıdaki şekilde hem Upstream hemde Globalde ayarlamalar yapılabilmektedir. bu ayarlamaların sonucunda oluşan yapı aşağıdaki gibidir.
Yukarıdaki RateLimit ayarlarına göre, Client 1 saniyede yalnızca 1 kere istekte bulunabilir. Eğer Global config ayarlaması yapılmaz aşağıdaki gibi bir ekran ile karşılaşılacaktır.
OCELOT CACHING
Ocelot da Caching işlemi, UpstreamPathTemplate de tanımlanan süreye göre response un cache lenmesi anlamına gelmektedir.
Aşağıdaki paketi Ocelot Gateway Api ye kuralım.
Startup.cs (Gateway)
{
"DownstreamPathTemplate": "/weatherforecast",
"DownstreamScheme": "http",
"DownstreamHostAndPorts": [
{
"Host": "localhost",
"Port": 5001
}
],
"UpstreamPathTemplate": "/api/weather",
"UpstreamHttpMethod": [ "Get" ],
"RouteIsCaseSensitive": true,
"AuthenticationOptions": {
"AuthenticationProviderKey": "MyOcelot",
"AllowedScopes": []
},
"RateLimitOptions": {
"ClientWhitelist": [],
"EnableRateLimiting": true,
"Period": "6s",
"PeriodTimespan": 1,
"Limit": 1
},
"FileCacheOptions": {
"TtlSeconds": 30,
"Region": "somename"
}
},
Yukarıdaki Log ları incelediğimizde Ocelot Requesti 30 saniye içerisinde Weather.Api ye sadece bir kere göndermiştir sonrasında Cache lediği response ları 30 saniye içerisinde dönmüştür.
Bu işlemi kullanırken 30 saniye dataların değişmeyeceğinide göz önünde bulundurmak gerekmektedir.
Ocelot Cache Manager ile istenir ise bizim kendi Cache mekanizmamızıda çalıştırabiliriz.
Makalenin sonuna gelmiş bulunmaktayız, umarım faydalı bir kaynak olmuştur.
Comentários