Microservice’ler ile alakal\u0131 di\u011fer makalelerimde de bahsetti\u011fim gibi, bizlere katt\u0131\u011f\u0131 art\u0131lar\u0131n yan\u0131nda baz\u0131 challenge’lar\u0131\u00a0da beraberlerinde getirdiklerinden bahsetmi\u015ftik. Bu challenge’lardan belki de en \u00f6nemlileri ise,\u00a0management\u00a0<\/strong>ve monitoring\u00a0<\/strong>konular\u0131d\u0131r.<\/p>\n Monolithic yap\u0131lara bakt\u0131\u011f\u0131m\u0131zda ise her \u015fey tek bir \u00e7at\u0131 alt\u0131ndad\u0131r. Biz yaz\u0131l\u0131mc\u0131lar i\u00e7in proje git gide b\u00fcy\u00fcmeye ba\u015flad\u0131\u011f\u0131nda pek de ho\u015f olmasa da, operasyonel anlamda sistemciler i\u00e7in olduk\u00e7a rahat bir \u015fey asl\u0131nda. :) \u00a0Fakat microservice yap\u0131lar\u0131na bakt\u0131\u011f\u0131m\u0131zda ise, i\u015fler operasyonel anlamda biraz de\u011fi\u015fiyor. \u00c7\u00fcnk\u00fc hepimizin de bildi\u011fi gibi -n tane farkl\u0131 sorumluluklar\u0131 yerine getiren distributed \u00a0microservice’ler ortaya \u00e7\u0131kmaya ba\u015fl\u0131yor ve i\u015fte bu noktada microservice’lerin beraberlerinde getirdi\u011fi management ve monitoring gibi ortak challenge’lar ile, “Service Discovery<\/strong>”\u00a0kavram\u0131 ortaya \u00e7\u0131k\u0131yor.<\/p>\n \u00d6rne\u011fin<\/strong>:<\/p>\n Yukar\u0131daki yap\u0131ya bakt\u0131\u011f\u0131m\u0131zda, auto scale<\/strong> olan ve dynamic<\/strong> olarak de\u011fi\u015fen instance’lara sahip bir yap\u0131y\u0131 g\u00f6r\u00fcyoruz. Burada dikkat edersek IP adresleri de dynamic olarak assign edilmektedir. Bu gibi dynamic case’ler kar\u015f\u0131s\u0131nda, client hangi IP adresine istek ataca\u011f\u0131n\u0131 bilemeyecektir. Service discovery ise bu gibi durumlar\u0131 nas\u0131l otomatik<\/strong> olarak handle edebilirize odaklanmaktad\u0131r.<\/p>\n Service discovery \u00a0temel olarak \u00fc\u00e7 kavram \u00fczerinde durmaktad\u0131r<\/strong>:<\/p>\n Service discovery’i uygulayabilmek i\u00e7in “Client-side service discovery” ve “Server-side service discovery” olmak \u00fczere iki farkl\u0131 pattern bulunmaktad\u0131r. Dilerseniz ilk pattern olan client-side k\u0131sm\u0131na bir bakal\u0131m.<\/p>\n Bu yakla\u015f\u0131mda service instance’lar\u0131, kendi network location’lar\u0131n\u0131\u00a0Service Registery<\/strong> \u00fczerine kay\u0131t ederler. Service registery ise service discovery’nin bir par\u00e7as\u0131d\u0131r. Bu sayede buradaki service’lere, hangi IP ve port \u00fczerinden eri\u015filebilece\u011fi\u00a0bilgisi service\u00a0registery \u00fczerinde\u00a0bulunur. Client ise herhangi bir request’i g\u00f6ndermeden \u00f6nce service registery’e gelerek, request g\u00f6ndermek istedi\u011fi service’in location bilgilerini elde eder ve o bilgiler do\u011frultusunda request i\u015flemini ger\u00e7ekle\u015ftirir. Kompleks olarak g\u00f6z\u00fckebilir ama genel anlamda bak\u0131lacak olursa gayet kolay bir i\u015flemdir.<\/p>\n Bir di\u011fer yandan bu pattern load balancer<\/strong> hatalar\u0131ndan sistemi korur, fakat balancing i\u015flemini ise client’a b\u0131rak\u0131r. \u00c7\u00fcnk\u00fc client, registery \u00fczerinden istedi\u011fi service’in IP ve port bilgilerini al\u0131r ve birden \u00e7ok IP adresine sahip ise kendi belirleyece\u011fi bir IP adresine request i\u015flemini ger\u00e7ekle\u015ftirir. Bu noktada dezavantaj\u0131na bakt\u0131\u011f\u0131m\u0131zda ise art\u0131k client’lar, service registery ile konu\u015fmas\u0131 gerekti\u011fini bilmek zorundad\u0131rlar ve balancing i\u015flemlerini kendileri handle etmelidirler.<\/p>\n Bu yakla\u015f\u0131mda ise dikkatinizi \u00e7ekmek istedi\u011fim ilk nokta: client’\u0131n art\u0131k ilk olarak service registery ile konu\u015fmak yerine direkt olarak load balancer \u00fczerine geliyor olmas\u0131d\u0131r. Load balancer ise service registery \u00fczerinden ilgili servis’in location bilgilerini alarak, route i\u015flemini kendisi ger\u00e7ekle\u015ftirmektedir.<\/p>\n Bu pattern’\u0131n avantaj\u0131 ise, client ile service registery’nin decoupled<\/strong> bir\u00a0\u015fekilde olmalar\u0131 ve\u00a0client’\u0131n hangi service’in hangi node’da oldu\u011fundan bir haberi olmamas\u0131d\u0131r. Dezavantaj\u0131 ise buradaki load balancer’\u0131n,\u00a0single point of failure<\/strong> durumda olmas\u0131d\u0131r.<\/p>\n Consul, kapsaml\u0131 bir service discovery<\/strong> arac\u0131d\u0131r. \u00d6ncelikle consul’\u00fcn mimarisine biraz de\u011finecek olursak consistency i\u00e7in server node’lar\u0131nda Raft consensus<\/strong>‘u kullanmaktad\u0131r.<\/p>\n Raft consensus ise:<\/p>\n Paxos<\/strong> temelli bir consensus algoritmas\u0131d\u0131r.<\/p><\/blockquote>\n Konu konuyu a\u00e7\u0131yor fakat nedir bu Paxos da dersek e\u011fer: distributed computing’de, consensus’u sa\u011flayabilmek i\u00e7in kullan\u0131lan\u00a0bir protokol olarak tan\u0131mlayabiliriz.\u00a0Paxos hakk\u0131ndaki detayl\u0131 bilgiye ise, buradan<\/a> <\/em>ula\u015fabilirsiniz. Raft’ a geri d\u00f6necek olursak, Paxos’a g\u00f6re daha basit ve anla\u015f\u0131labilir bir algoritma olarak tasarlanm\u0131\u015ft\u0131r. Consul ise Raft’\u0131, node’lar aras\u0131ndaki consistency durumunu veya leader election’\u0131 sa\u011flayabilmek i\u00e7in kullanmaktad\u0131r.<\/p>\n \u00d6rnek vermek gerekirse: 3\u00a0adet server node’u oldu\u011funu d\u00fc\u015f\u00fcnelim. Bu node’lar aralar\u0131ndaki consistency’i sa\u011flayabilmek i\u00e7in leader node, a\u015fa\u011f\u0131daki gibi di\u011fer node’lara bir heartbeat g\u00f6ndermektedir.<\/p>\n E\u011fer bu heartbeat timeout’a u\u011frar ise, x node’undan birtanesi yeni bir election(oylama) ba\u015flatacakt\u0131r. Bu election ise node’lar aras\u0131ndan hangisinin yeni leader olaca\u011f\u0131na karar verilebilmesi i\u00e7in yap\u0131lmaktad\u0131r.\u00a0Bu i\u015flemin ger\u00e7ekle\u015febilmesi i\u00e7in ise election’\u0131 ba\u015flatan node, a\u015fa\u011f\u0131daki gibi di\u011fer node’lardan leader olabilmek i\u00e7in oy istemektedir.<\/p>\n Di\u011fer node’lardan gerekli oyu alabilirse e\u011fer, leader olarak se\u00e7ilmektedir. Bu oy isteme i\u015flemine ise “Quorum” denmektedir ve bu i\u015flem i\u00e7in (n\/2)+1 kadar \u00fcye gerekmektedir.\u00a0Raft hakk\u0131nda daha fazla bilgi edinebilmek i\u00e7in,\u00a0buray\u0131<\/a><\/em>\u00a0ziyaret edebilirsiniz.<\/p>\n Consul’\u00fcn di\u011fer baz\u0131 architectural detaylar\u0131na bakt\u0131\u011f\u0131m\u0131zda ise:<\/p>\n Bunlara ek olarak consul,\u00a0highly fault tolerant<\/strong>‘a sahiptir. T\u00fcm Consul service cluster’\u0131 down oldu\u011funda\u00a0dahi, bu durum service discovery i\u015flemini durdurmayacakt\u0131r. Bu i\u015flemi ise Consul,\u00a0Serf<\/strong><\/em> ile sa\u011flamaktad\u0131r. Serf, tamamen bir\u00a0Gossip protokol’\u00fc olup bir nevi node orchestration tool’udur. Serf membershipment’\u0131 y\u00f6netmek, failure detection ve event broadcasting yapabilme i\u015flemlerini sa\u011flayabilmektedir. Ayr\u0131ca server node’lar\u0131 i\u00e7in ise clustering sa\u011flamaktad\u0131r. Consul’\u00fc tan\u0131mlamaya \u00e7al\u0131\u015f\u0131rken bir \u00e7ok farkl\u0131 konuya de\u011findik ve Consul nedir’i art\u0131k toparlamak gerekirse e\u011fer, g\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi bir \u00e7ok bile\u015feni mevcuttur Consul’\u00fcn.<\/p>\n Fakat bir b\u00fct\u00fcn olarak bakt\u0131\u011f\u0131m\u0131zda ise altyap\u0131m\u0131zdaki service’leri discovery<\/strong>\u00a0edebilmemiz ve configuring<\/strong> i\u015flemlerini yapabilmemiz i\u00e7in geli\u015ftirilmi\u015f\u00a0bir tool’dur diyebiliriz. Consul’\u00fcn mimarisi ile ilgili son olarak da health checking konusuna da de\u011finmek gerekirse,\u00a0health checking i\u015flemini ise client agent’lar\u0131 arac\u0131l\u0131\u011f\u0131 ile yapabilmektedir. Consul mimarisi hakk\u0131nda daha detayl\u0131 bilgi edinebilmek isterseniz, buray\u0131<\/a> inceleyebilirsiniz.<\/p>\n Ger\u00e7ekle\u015ftirecek oldu\u011fumuz implementasyon da, local ortamda Consul’\u00fc\u00a0development modunda \u00e7al\u0131\u015ft\u0131raca\u011f\u0131z. Ard\u0131ndan \u00f6rnek olarak olu\u015fturacak oldu\u011fumuz bir Web API projesini, Consul’\u00fcn .NET client library’sini kullanarak iki farkl\u0131 port \u00fczerinden IIS alt\u0131nda host edip, Consul \u00fczerine registration i\u015flemini ger\u00e7ekle\u015ftirece\u011fiz. Dilerseniz \u00f6ncelikle buradan<\/a>, Consul’\u00fcn windows i\u00e7in olan versiyonunu indirelim ve istedi\u011fimiz bir dizin alt\u0131na koyal\u0131m.<\/p>\n Komut istemcisini a\u00e7al\u0131m ve a\u015fa\u011f\u0131daki komutu, Consul’\u00fc koydu\u011fumuz dizinde \u00e7al\u0131\u015ft\u0131ral\u0131m.<\/p>\n Komutu \u00e7al\u0131\u015ft\u0131rd\u0131ktan sonra Consul, agent’\u0131n\u0131\u00a0in-memory olarak development modunda yukar\u0131daki gibi \u00e7al\u0131\u015ft\u0131rmaktad\u0131r. Log’lara bakt\u0131\u011f\u0131m\u0131zda ise bir tek “GOKGOKALP” node’u oldu\u011fu i\u00e7in, leader election’da “1” oya ihtiyac\u0131 oldu\u011funu ve oylamay\u0131 yaparak\u00a0kendisini leader olarak se\u00e7ti\u011fini g\u00f6rebiliriz.<\/p>\n UI’\u0131na ise localhost \u00fczerinden “8300” port’u ile eri\u015febiliriz. “http:\/\/localhost:8500\/ui<\/em>”<\/p>\n Default olarak Consul, kendi servisi ile gelmektedir. “Serf Health Status” \u00fc ile ise “GOKGOKALP” node’u \u00fczerine bulunan consul servis’inin, “alive” ve “reachable” olup olmad\u0131\u011f\u0131na bakmaktad\u0131r.<\/p>\n Dilerseniz \u015fimdi basit bir service olu\u015ftural\u0131m ve Consul i\u00e7erisine register edelim. Bunun i\u00e7in “ConsulSampleAspNetCore” isminde bir Asp.NET Core Application Web API projesi olu\u015fturuyorum ve i\u00e7erisine a\u015fa\u011f\u0131daki gibi bir “HelpController” ekliyorum.<\/p>\n Bu endpoint’i Consul taraf\u0131nda health check i\u015flemi i\u00e7in kullan\u0131yor olaca\u011f\u0131z. Controller’\u0131 tamamlad\u0131ktan sonra, Nuget Package Manager \u00fczerinden a\u015fa\u011f\u0131daki gibi “Consul” paketini projeye dahil edelim.<\/p>\n Client library’sini ekledikten sonra ise, API projesi ile birlikte gelen “Startup.cs” i a\u00e7al\u0131m ve i\u00e7erisine a\u015fa\u011f\u0131daki gibi “RegisterServiceToConsul” isminde yeni bir method olu\u015ftural\u0131m.<\/p>\n Burada en basit hali ile bir agent registration i\u015flemi olu\u015fturuyoruz. Service’in “localhost” \u00fczerinde oldu\u011funu ve “9090” port’u ile eri\u015filebilece\u011fini belirtiyoruz. Health checking i\u015flemi i\u00e7in ise, \u00f6ncesinde olu\u015fturmu\u015f oldu\u011fumuz URL adresini veriyoruz ve bu i\u015flemi “10” saniyelik aral\u0131klar ile ger\u00e7ekle\u015ftirmesi gerekti\u011fini bildiriyoruz. Sonras\u0131nda ise bu method’u, “Startup” method’u i\u00e7erisinde call ediyoruz.<\/p>\n Art\u0131k bu service ilk aya\u011fa kalkt\u0131\u011f\u0131nda, kendisini Consul \u00fczerine register edecektir.<\/p>\n Test i\u015flemlerine haz\u0131r durumday\u0131z. Web API projesini publish ederek, IIS \u00fczerinde “9090” port’undan host edelim. Ben bu noktada host i\u015fleminin, nas\u0131l oldu\u011funun konusuna de\u011finmeyece\u011fim. Host i\u015flemini ba\u015far\u0131yla ger\u00e7ekle\u015ftirdi isek, “http:\/\/localhost:9090\/health<\/em>” URL’ine gidelim ve “OK” result’\u0131n\u0131 g\u00f6relim.<\/p>\n Bu result’\u0131 g\u00f6rmemiz ile beraber service, Consul \u00fczerine kendisinin registration i\u015flemini ger\u00e7ekle\u015ftirecektir. \u00d6ncelikle Consul’\u00fcn console \u00fczerindeki log’lar\u0131na bir bakal\u0131m.<\/p>\n Log’lara bakt\u0131\u011f\u0131m\u0131zda kendisine bir HTTP request’i geldi\u011fini ve ard\u0131ndan “consul-sample-api-9090” ismi ile sync<\/strong> etti\u011fini g\u00f6rebiliyoruz. Bunun yan\u0131nda ise “Check ‘service:consul-sample-api-9090’ is passing” sat\u0131r\u0131 ile eklemi\u015f oldu\u011fumuz service’in health check endpoint’ine giderek, up\u00a0olup olmad\u0131\u011f\u0131n\u0131 kontrol etti\u011fi log’unu da\u00a0g\u00f6rebiliyoruz.<\/p>\n \u015eimdi Consul’\u00fcn UI ekran\u0131na girelim ve bir de oradan bakal\u0131m. UI ekran\u0131na girdikten sonra “SERVICES” tab’\u0131na girelim ve buraya yeni eklenmi\u015f olan “consul-sample-api” service’ine t\u0131klayal\u0131m.<\/p>\n G\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi sa\u011f k\u0131s\u0131mda bulunan nodes tab’\u0131n\u0131n alt\u0131ndaki “Service ‘consul-sample-api’ check” bilgisini, passing<\/strong> olarak\u00a0g\u00f6stermektedir.<\/p>\n Detay\u0131na t\u0131klad\u0131\u011f\u0131m\u0131zda ise a\u015fa\u011f\u0131daki gibi bir ekran bizi kar\u015f\u0131l\u0131yor olacakt\u0131r.<\/p>\n Burada sa\u011f altta bulunan output k\u0131sm\u0131na bakt\u0131\u011f\u0131m\u0131zda ise, service’i register ederken kulland\u0131\u011f\u0131m\u0131z health check endpoint’ine bir GET request’i att\u0131\u011f\u0131n\u0131 ve ard\u0131ndan “OK” response’unu ald\u0131\u011f\u0131 bilgisini g\u00f6rebilmekteyiz.<\/p>\n Dilerseniz birde olumsuz durumlarda ne yapt\u0131\u011f\u0131na bir bakal\u0131m. Bunun i\u00e7in IIS \u00fczerinden olu\u015fturdu\u011fumuz host’u stop edelim ve mevcut UI ekran\u0131n\u0131 tekrardan geri d\u00f6nelim.<\/p>\n Art\u0131k “consul-sample-api” i\u00e7in durumun critical\u00a0<\/strong>oldu\u011funu ve output k\u0131sm\u0131nda ise ilgili health check endpoint’ine gitmeye \u00e7al\u0131\u015f\u0131l\u0131rken ald\u0131\u011f\u0131 hata message’\u0131n\u0131 da g\u00f6rebilmekteyiz. Consul,\u00a0endpoint’e tekrar eri\u015febildi\u011finde\u00a0ise, service’in status’\u00fcn\u00fc passing olarak g\u00f6sterip, aktif service’ler aras\u0131na dahil edecektir.<\/p>\n![\"\"](\"\/wp-content\/uploads\/2017\/02\/service-discovery.png\")
<\/a><\/p>\nService Discovery Nedir?<\/h4>\n
<\/a><\/p>\n<\/a><\/p>\n\n
1) Client-side Service Discovery Pattern<\/h5>\n
<\/a><\/p>\n2) Server-side Service Discovery Pattern<\/h5>\n
<\/a><\/p>\nConsul Nedir?<\/h4>\n
<\/p>\n<\/a><\/p>\n<\/a><\/p>\n\n
Basic Implementasyon<\/h4>\n
consul agent -dev<\/pre>\n
<\/a><\/p>\n<\/a><\/p>\nnamespace ConsulSampleAspNetCore.Controllers\r\n{\r\n [Route(\"[controller]\")]\r\n public class HelpController : Controller\r\n {\r\n [HttpGet(\"\")]\r\n public string Ping()\r\n {\r\n return \"OK\";\r\n }\r\n }\r\n}<\/pre>\n<\/a><\/p>\nprivate void RegisterServiceToConsul()\r\n{\r\n using (var client = new ConsulClient())\r\n {\r\n var registration = new AgentServiceRegistration()\r\n {\r\n ID = \"consul-sample-api-9090\",\r\n Name = \"consul-sample-api\",\r\n Address = \"localhost\",\r\n Port = 9090,\r\n Check = new AgentCheckRegistration()\r\n {\r\n HTTP = \"http:\/\/localhost:9090\/health\",\r\n Interval = TimeSpan.FromSeconds(10)\r\n }\r\n };\r\n\r\n client.Agent.ServiceRegister(registration).Wait();\r\n }\r\n}<\/pre>\npublic Startup(IHostingEnvironment env)\r\n{\r\n ...\r\n\r\n RegisterServiceToConsul();\r\n}<\/pre>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n