{"id":24948,"date":"2022-05-07T23:46:38","date_gmt":"2022-05-07T23:46:38","guid":{"rendered":"https:\/\/www.gencayyildiz.com\/blog\/?p=24948"},"modified":"2022-05-07T23:47:16","modified_gmt":"2022-05-07T23:47:16","slug":"netflix-eureka-server-ile-service-discovery","status":"publish","type":"post","link":"https:\/\/www.gencayyildiz.com\/blog\/netflix-eureka-server-ile-service-discovery\/","title":{"rendered":"Netflix Eureka Server \u0130le Service Discovery"},"content":{"rendered":"
<\/div>\n

Merhaba,<\/p>\n

Microservice mimarisi ile geli\u015ftirilen projelerde birbirlerinden ba\u011f\u0131ms\u0131z onlarca servis aras\u0131nda ileti\u015fim esast\u0131r. Haliyle bu ileti\u015fim s\u00fcrecini m\u00fcmk\u00fcn mertebe basit ve etkili bir \u015fekilde dizayn etmemiz gerekmektedir. Genellikle servisler aras\u0131 ileti\u015fim kompleksli\u011fine, cephe g\u00f6revi g\u00f6ren API Gateway<\/a> yaz\u0131l\u0131mlar\u0131yla \u00e7\u00f6z\u00fcm getirmeye \u00e7al\u0131\u015f\u0131r\u0131z lakin API Gateway’ler u\u00e7 d\u00fczeyde clienttan servise(client-to-service<\/em>) trafi\u011fi y\u00f6netiklerinden dolay\u0131 servisler aras\u0131 ileti\u015fim i\u00e7in yeterli bir model sunamad\u0131klar\u0131ndan dolay\u0131 yetersiz gelmektedirler. \u00c7\u00fcnk\u00fc microservice mimarilerde yo\u011fun olarak servisten servise(service-to-service<\/em>) haberle\u015fme s\u00f6z konusudur. Dolay\u0131s\u0131yla bu davran\u0131\u015f\u0131 kar\u015f\u0131layabilecek bir \u00e7\u00f6z\u00fcmsel modele ihtiyac\u0131m\u0131z olacakt\u0131r. O y\u00fczden bu i\u00e7eri\u011fimizde, API Gateway yerine bu ihtiyaca istinaden daha elveri\u015fli olan Service Discovery<\/em> tool’u olan Eureka<\/em> ile \u00e7\u00f6z\u00fcm getirmeye \u00e7al\u0131\u015facak ve servisler aras\u0131 ileti\u015fim s\u00fcrecini olabildi\u011fince y\u00f6netilebilir hale getirmeye odaklan\u0131yor olaca\u011f\u0131z.<\/p>\n

Nedir Bu Service Discovery?<\/h3>\n

Service Discovery, farkl\u0131 adreslerde host edilen servislerin(ya da API’lerin) birbirleri aras\u0131ndaki ileti\u015fim\/haberle\u015fme i\u00e7in geli\u015ftiriciler taraf\u0131ndan adres bilgilerinin bilinmesi zorunlulu\u011funu ortadan kald\u0131rarak, bu servislerin ortak bir store’a register olmas\u0131n\u0131 sa\u011flayan ve b\u00f6ylece eri\u015fim tarifini kolayla\u015ft\u0131rarak ileti\u015fimi daha sade hale getiren bir modeldir. Bu model sayesinde ilgili proje ekosisteminde bulunan t\u00fcm servisler birbirleriyle ‘service name<\/em>‘ de\u011ferleri arac\u0131l\u0131\u011f\u0131yla rahatl\u0131kla ileti\u015fim kurabilmekte ve geli\u015ftiricileri adres, port vs. gibi ufak tefek bilgilere bo\u011fmaks\u0131z\u0131n ileti\u015fimi s\u00fcrd\u00fcrebilmektedirler.<\/p>\n

Service Discovery mimarisini daha iyi anlayabilmek i\u00e7in a\u015fa\u011f\u0131daki g\u00f6rseli incelersek e\u011fer;\"Netflix<\/a>servislerin kendi aralar\u0131ndaki ileti\u015fimi herhangi bir host bilgisine gerek kalmaks\u0131z\u0131n ger\u00e7ekle\u015ftirdi\u011fini g\u00f6rmekteyiz. Misal olarak, sol taraftaki ‘A Service’, sa\u011f taraftaki ‘B Service’e istek g\u00f6nderecekse e\u011fer ilgili servisin ip’sini, hostunu, portunu vs. bilmeye gerek duymaks\u0131z\u0131n direkt olarak ‘Service Registry<\/em>‘ servisinden istek y\u00f6nlendirmede bulunabilmektedir. Bu i\u015flem nas\u0131l ger\u00e7ekle\u015fiyor?<\/strong><\/em> diye sorarsan\u0131z e\u011fer dikkat ederseniz t\u00fcm servisler service registry’e kay\u0131t olmu\u015f vaziyettedir. Haliyle istek g\u00f6nderecek servisin, hedef servisin tag(service name<\/em>) bilgisini bilmesi ve bu bilgi do\u011frultusunda ‘ben n isimli servise \u015fu iste\u011fi g\u00f6ndermek istiyorum<\/em>‘ \u015feklinde service registry \u00fczerinden hareket etmesi yeterli olacakt\u0131r \ud83d\ude42<\/p>\n

Uygulama ekosisteminde kullan\u0131lan servislerin, service registry’e kay\u0131t olmas\u0131 teoride olduk\u00e7a basittir. Bunun i\u00e7in her bir servis aya\u011fa kalkarken(ilk anda) service discovery’e request atarak kendisi hakk\u0131nda belirli tan\u0131mlamalarda bulunarak kay\u0131t i\u015flemini ger\u00e7ekle\u015ftirmektedir. B\u00f6ylece service discovery \u00fczerinde tan\u0131mlanan servis di\u011fer servislerle tag \u00fczerinden ileti\u015fim kurabilir vaziyette konumunu alm\u0131\u015f demektir.<\/p>\n

Bu arada service registry’in service discovery ile olan ili\u015fkisini k\u0131saca izah etmemiz gerekirse e\u011fer, t\u00fcm (mikro)servislerin host edildikleri network lokasyonlar\u0131n\u0131n register edilerek tutuldu\u011fu ve servisler aras\u0131 ileti\u015fimde bu lokasyonlar\u0131n tagler(service name<\/em>) e\u015fli\u011finde eri\u015filebilir k\u0131l\u0131nd\u0131\u011f\u0131 bir yap\u0131lanmad\u0131r. Ayr\u0131ca birbirleri aras\u0131ndaki ileti\u015fim s\u00fcrecini, bu yap\u0131lanma \u00fczerinden ger\u00e7ekle\u015ftirmek isteyen t\u00fcm servislere Service Registry Client<\/em> ismi verildi\u011fini s\u00f6ylemekte fayda g\u00f6rmekteyim.<\/p>\n

Service discovery, service-to-service haberle\u015fme s\u00fcre\u00e7lerinde uygulamalar\u0131n birbirlerinin network adreslerine metinsel de\u011ferler kar\u015f\u0131l\u0131\u011f\u0131nda ula\u015fmas\u0131n\u0131 sa\u011flayan basit bir model ortaya koymaktad\u0131r.<\/em><\/p><\/blockquote>\n

Service discovery ile API Gateway aras\u0131ndaki fark nedir?<\/strong>
\n\u0130\u00e7eri\u011fimize tam olarak giri\u015f yapmadan \u00f6nce belki service discovery’nin API Gateway’den fark\u0131n\u0131 \u00fcst sat\u0131rlarda ele alm\u0131\u015f olsak bile teoride pek yaratamam\u0131\u015f olabiliriz. Bundan dolay\u0131 iki kavram aras\u0131ndaki fark\u0131 a\u015fa\u011f\u0131daki tablo \u00fczerinden somutla\u015ft\u0131rarak i\u00e7eri\u011fe devam etmek daha verimli olacakt\u0131r kanaatindeyim.<\/p>\n\n\n\n\n\n\n\n\n
Service Discovery<\/th>\nAPI Gateway<\/th>\n<\/tr>\n<\/thead>\n
Servisten servise yap\u0131lacak istekleri y\u00f6netir.<\/td>\nClienttan servise yap\u0131lacak olan istekleri y\u00f6netir. Biraz daha nihaidir.<\/td>\n<\/tr>\n
Yatay d\u00fczlemde(servisler aras\u0131 – east\/west traffic) istek trafi\u011fini i\u015fler.<\/td>\nDikey d\u00fczlemde(client ile servis aras\u0131 – north\/south traffic) istek trafi\u011fini i\u015fler.<\/td>\n<\/tr>\n
\u0130\u00e7 kaynaklardaki trafiklere\/i\u015flere odaklan\u0131r.<\/td>\nHarici\/d\u0131\u015f trafikleri i\u00e7 kaynaklara y\u00f6nlendirir. Burada d\u0131\u015f trafikten kas\u0131t clientlard\u0131r. Clientlar\u0131n t\u00fcketti\u011fi i\u00e7 kaynaklardan mevzu bahis ise servislerdir.<\/td>\n<\/tr>\n
Uygulamada kullan\u0131lan servislerin ileti\u015fimini \u00f6n plana \u00e7\u0131kar\u0131r.<\/td>\nUygulamada kullan\u0131lan servislerin y\u00f6netimini ve kontrol\u00fcn\u00fc ortaya \u00e7\u0131kar\u0131r.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\u015eimdi gelin uygulamal\u0131 olarak service discovery implementasyonunu ger\u00e7ekle\u015ftirmeyi inceleyelim. Tabi \u00fczerine \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131z projede service discovery implementasyonunu ger\u00e7ekle\u015ftirebilmek i\u00e7in ZooKeeper<\/a>, Istio<\/a>, Consul by HashiCorp<\/a>, Netflix Eureka<\/a> vs. gibi t\u00fcrl\u00fc t\u00fcrl\u00fc tool’lar mevcuttur. Bizler bu i\u00e7eri\u011fimizde malumunuz giri\u015f paragraf\u0131nda da bildirildi\u011fi gibi Netflix Eureka<\/em> \u00fczerinden service discovery operasyonlar\u0131n\u0131 .NET Core e\u015fli\u011finde y\u00fcr\u00fct\u00fcyor olacak ve implementasyon a\u00e7\u0131s\u0131ndan pratikte incelemede bulunaca\u011f\u0131z.<\/p>\n

Eureka Kurulumu<\/h3>\n

\u0130lk olarak Eureka sunucusunun kurulumuyla ba\u015flayal\u0131m. Eureka’y\u0131 kullanabilmek i\u00e7in steeltoe<\/a> ekibinin sundu\u011fu docker image’inden istifade edebiliriz. Bunun i\u00e7in a\u015fa\u011f\u0131daki docker talimat\u0131n\u0131n \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131 yeterlidir.<\/p>\n

\n
\r\ndocker run --name Eureka --publish 8761:8761 steeltoeoss\/eureka-server\r\n<\/pre>\n<\/div>\n
Bu talimat neticesinde Eureka Server’\u0131 bar\u0131nd\u0131ran bir docker container http:\/\/localhost:8761<\/a> portunda aya\u011fa kald\u0131r\u0131lm\u0131\u015f olacakt\u0131r.\"Netflix<\/a>Evet, g\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere service discovery sunucumuz hali haz\u0131r ayakta. Bundan sonra bu sunucuya register olacak servisleri olu\u015fturmaya ge\u00e7ebiliriz.<\/p>\n
Eureka – Service Registry<\/h3>\n
\"Netflix<\/a>\u015eimdi \u00f6rneklendirmemizi iki API bir console uygulamas\u0131 \u00fczerinden sergiliyor olaca\u011f\u0131z. Bunun i\u00e7in blank solution a\u00e7\u0131p i\u00e7erisine yandaki g\u00f6rseldeki gibi ‘AService’ ve ‘BService’ ad\u0131nda iki Web API ve ‘CService’ isminde de bir console projesi olu\u015ftural\u0131m.<\/p>\n
Tabi bu projeler bizim farazimizi tatbik edece\u011fimiz \u00f6rnek uygulamalard\u0131r. Sizler ger\u00e7ek operasyonlarda farkl\u0131 solutionlarda bulunan projeleri bu \u00e7al\u0131\u015fmaya dahil edebilir ve hatta farkl\u0131 bir framework veya dil\/platform’da geli\u015ftirilen uygulamay\u0131 da kendi f\u0131trat\u0131na uygun sisteme implemente edebilirsiniz. Velhas\u0131l bizler \u015fimdiki ahvalde devam edelim.<\/p>\n
\u015eimdi Eureka \u00fczerinden service discovery ile call edilecek t\u00fcm uygulamalar ilgili sunucuya registry olmak mecburiyetindedirler. Bunun i\u00e7in .NET Core ortam\u0131nda Steeltoe.Discovery.Eureka<\/a> k\u00fct\u00fcphanesinden istifade etmekteyiz. Sisteme hem register olacak hem de register olmu\u015f servislere istek g\u00f6nderecek t\u00fcm uygulamalar bu k\u00fct\u00fcphaneyi entegre etmek mecburiyetindedir.<\/p>\n
T\u00fcm servislere ilgili k\u00fct\u00fcphaneyi entegre ettikten sonra \u00f6ncelikle Web API’lar \u00fczerinden gerekli konfig\u00fcrasyonlara ba\u015flayabiliriz. Bunun i\u00e7in her iki API servisindeki ‘Program.cs’ dosyas\u0131nda a\u015fa\u011f\u0131daki gibi AddDiscoveryClient<\/code> metodu e\u015fli\u011finde Eureka implementasyonunu ger\u00e7ekle\u015ftirelim.<\/p>\n
\n
\r\nusing Steeltoe.Discovery.Client;\r\n\r\nvar builder = WebApplication.CreateBuilder(args);\r\n\r\nbuilder.Services.AddControllers();\r\nbuilder.Services.AddDiscoveryClient(builder.Configuration);\r\n\r\nvar app = builder.Build();\r\n\r\napp.UseHttpsRedirection();\r\napp.UseAuthorization();\r\napp.MapControllers();\r\napp.Run();\r\n<\/pre>\n<\/div>\n
Bu AddDiscoveryClient<\/code> metodu neticesinde uygulamalar\u0131m\u0131z ilk aya\u011fa kalkt\u0131\u011f\u0131nda service discovery’e client olarak talepte bulunacak ve i\u00e7eri\u011fi a\u015fa\u011f\u0131da bildirildi\u011fi gibi appsettings.json<\/code> dosyas\u0131ndaki konfig\u00fcrasyonel de\u011ferler e\u015fli\u011finde kendilerini register edecektirler.
\n‘AService’ :<\/p>\n
\n
\r\n.\r\n.\r\n.\r\n  "spring": {\r\n    "application": {\r\n      "name": "AService"\r\n    }\r\n  },\r\n  "eureka": {\r\n    "client": {\r\n      "serviceUrl": "http:\/\/localhost:8761\/eureka\/",\r\n      "shouldFetchRegistry": "true",\r\n      "shouldRegisterWithEureka": true,\r\n      "validateCertificates": false\r\n    },\r\n    "instance": {\r\n      "port": "7175",\r\n      "ipAddress": "localhost",\r\n      "preferIpAddress": true\r\n    }\r\n  }\r\n.\r\n.\r\n.\r\n<\/pre>\n<\/div>\n
‘BService’ :<\/p>\n
\n
\r\n.\r\n.\r\n.\r\n  "spring": {\r\n    "application": {\r\n      "name": "BService"\r\n    }\r\n  },\r\n  "eureka": {\r\n    "client": {\r\n      "serviceUrl": "http:\/\/localhost:8761\/eureka\/",\r\n      "shouldFetchRegistry": "true",\r\n      "shouldRegisterWithEureka": true,\r\n      "validateCertificates": false\r\n    },\r\n    "instance": {\r\n      "port": "7253",\r\n      "ipAddress": "localhost",\r\n      "preferIpAddress": true\r\n    }\r\n  }\r\n.\r\n.\r\n.\r\n<\/pre>\n<\/div>\n
Evet, service discovery s\u00fcrecinde olacak t\u00fcm servisler bu konfig\u00fcrasyonel de\u011ferler e\u015fli\u011finde bildiride bulunmak mecburiyetindedirler. Peki bu de\u011ferler ne anlama gelmektedir?<\/strong><\/em> diye sordu\u011funuzu duyar gibiyim… Gelin k\u0131saca a\u00e7\u0131klayal\u0131m;<\/p>\n