Devasa monolitik uygulamalar\u0131n\u0131z\u0131n bak\u0131m\u0131n\u0131n zorla\u015ft\u0131\u011f\u0131n\u0131, yeni \u00f6zellik eklemenin bir k\u00e2busa d\u00f6n\u00fc\u015ft\u00fc\u011f\u00fcn\u00fc ve her k\u00fc\u00e7\u00fck de\u011fi\u015fiklik i\u00e7in t\u00fcm sistemi yeniden da\u011f\u0131tmak zorunda kald\u0131\u011f\u0131n\u0131z\u0131 m\u0131 d\u00fc\u015f\u00fcn\u00fcyorsunuz? Monolitten mikroservislere ge\u00e7i\u015f yapmak kula\u011fa cazip gelse de, mevcut kod taban\u0131n\u0131z\u0131 ba\u015ftan yazma fikri sizi \u00fcrk\u00fct\u00fcyor olabilir. Peki ya size, mevcut i\u015f mant\u0131\u011f\u0131 kodunuzu tek bir sat\u0131r bile de\u011fi\u015ftirmeden<\/strong> bu d\u00f6n\u00fc\u015f\u00fcm\u00fc ba\u015farabilece\u011finizi s\u00f6ylesek? \u0130\u015fte tam bu noktada, yaz\u0131l\u0131m mimarisinin en g\u00fc\u00e7l\u00fc prensiplerinden biri olan Inversion of Control (IoC)<\/strong>, bir sihirli de\u011fnek gibi imdad\u0131n\u0131za yeti\u015fiyor.<\/p>\n Her \u015feyden \u00f6nce, i\u00e7inde bulundu\u011fumuz durumu netle\u015ftirelim. Monolitik mimari, uygulaman\u0131z\u0131n t\u00fcm bile\u015fenlerinin (veri taban\u0131 eri\u015fimi, i\u015f mant\u0131\u011f\u0131, kullan\u0131c\u0131 aray\u00fcz\u00fc vb.) tek bir b\u00fcy\u00fck, b\u00fct\u00fcnle\u015fik birim olarak geli\u015ftirildi\u011fi, da\u011f\u0131t\u0131ld\u0131\u011f\u0131 ve \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131 geleneksel bir yakla\u015f\u0131md\u0131r. Ba\u015flang\u0131\u00e7ta, k\u00fc\u00e7\u00fck ekipler ve s\u0131n\u0131rl\u0131 \u00f6zelliklerle yola \u00e7\u0131karken bu yakla\u015f\u0131m olduk\u00e7a basit ve h\u0131zl\u0131 bir ba\u015flang\u0131\u00e7 sunar. Tek bir kod taban\u0131, tek bir da\u011f\u0131t\u0131m birimi ve genellikle tek bir teknoloji y\u0131\u011f\u0131n\u0131 ile i\u015fler yolunda gider.<\/p>\n Ancak zamanla, uygulaman\u0131z b\u00fcy\u00fcd\u00fck\u00e7e, kullan\u0131c\u0131 say\u0131s\u0131 artt\u0131k\u00e7a ve yeni i\u015flevsellik talepleri geldik\u00e7e monolitik yap\u0131lar\u0131n zorluklar\u0131 ortaya \u00e7\u0131kmaya ba\u015flar. Her \u015fey birbiriyle s\u0131k\u0131ca ba\u011fl\u0131 oldu\u011fu i\u00e7in, uygulaman\u0131n bir b\u00f6l\u00fcm\u00fcndeki k\u00fc\u00e7\u00fck bir de\u011fi\u015fiklik bile beklenmedik yan etkilere yol a\u00e7abilir ve t\u00fcm sistemin yeniden test edilmesini gerektirebilir. Bu durum, geli\u015ftirme h\u0131z\u0131n\u0131 d\u00fc\u015f\u00fcr\u00fcr, hatalar\u0131 art\u0131r\u0131r ve ekiplerin ba\u011f\u0131ms\u0131z \u00e7al\u0131\u015fmas\u0131n\u0131 engeller. Bir ba\u015fka deyi\u015fle, k\u00fc\u00e7\u00fck bir gemi olarak ba\u015flayan projeniz, art\u0131k a\u011f\u0131r, hantal ve manevra yapmas\u0131 g\u00fc\u00e7 bir s\u00fcper tankere d\u00f6n\u00fc\u015fm\u00fc\u015ft\u00fcr. Yeni bir \u00f6zellik eklemek veya bir hatay\u0131 d\u00fczeltmek bile aylar s\u00fcrebilir, \u00e7\u00fcnk\u00fc t\u00fcm sistemin karma\u015f\u0131kl\u0131\u011f\u0131, h\u0131zl\u0131 ve \u00e7evik olman\u0131za izin vermez.<\/p>\n \u00d6l\u00e7eklenebilirlik de monolitler i\u00e7in ciddi bir problem te\u015fkil eder. Uygulaman\u0131z\u0131n sadece bir b\u00f6l\u00fcm\u00fc (\u00f6rne\u011fin, sipari\u015f i\u015fleme mod\u00fcl\u00fc) yo\u011fun y\u00fcke maruz kal\u0131rken, t\u00fcm uygulamay\u0131 \u00f6l\u00e7eklendirmek zorunda kal\u0131rs\u0131n\u0131z. Bu da gereksiz kaynak t\u00fcketimi ve y\u00fcksek maliyetler anlam\u0131na gelir. Farkl\u0131 ekiplerin ayn\u0131 kod taban\u0131 \u00fczerinde \u00e7al\u0131\u015fmas\u0131, kod \u00e7ak\u0131\u015fmalar\u0131na, entegrasyon problemlerine ve s\u00fcr\u00fcm kontrol kabuslar\u0131na yol a\u00e7ar. Ayr\u0131ca, teknoloji y\u0131\u011f\u0131n\u0131n\u0131 g\u00fcncellemek veya yeni bir teknolojiyi denemek neredeyse imkans\u0131zd\u0131r; \u00e7\u00fcnk\u00fc bu, t\u00fcm uygulaman\u0131n yeniden yaz\u0131lmas\u0131 anlam\u0131na gelebilir. Bu k\u0131s\u0131tlamalar, \u015firketlerin yenilik yapma yetene\u011fini ciddi \u015fekilde k\u00f6reltir ve onlar\u0131 rekabette geride b\u0131rakabilir.<\/p>\n Bu ba\u011flamda, monolitik bir yap\u0131n\u0131n temel zorluklar\u0131n\u0131 \u015fu maddelerle \u00f6zetleyebiliriz:<\/p>\n Bu zorluklar, modern yaz\u0131l\u0131m geli\u015ftirme d\u00fcnyas\u0131nda esneklik, h\u0131z ve \u00f6l\u00e7eklenebilirlik aray\u0131\u015f\u0131n\u0131 tetiklemi\u015f ve mikroservis mimarisinin pop\u00fclerle\u015fmesine zemin haz\u0131rlam\u0131\u015ft\u0131r. Ancak, bu ge\u00e7i\u015fin sanc\u0131l\u0131 olmamas\u0131 i\u00e7in do\u011fru ara\u00e7lara ihtiyac\u0131m\u0131z var.<\/p>\n Monolitlerin sundu\u011fu zorluklara bir cevap olarak ortaya \u00e7\u0131kan mikroservis mimarisi, uygulamalar\u0131 k\u00fc\u00e7\u00fck, ba\u011f\u0131ms\u0131z, gev\u015fek ba\u011fl\u0131 ve kendi ba\u015f\u0131na \u00e7al\u0131\u015fabilen servisler halinde in\u015fa etme yakla\u015f\u0131m\u0131n\u0131 benimser. Her mikroservis, belirli bir i\u015f alan\u0131na odaklan\u0131r, kendi veri taban\u0131na sahip olabilir, ba\u011f\u0131ms\u0131z olarak geli\u015ftirilebilir, test edilebilir, da\u011f\u0131t\u0131labilir ve \u00f6l\u00e7eklenebilir. Bu yakla\u015f\u0131m, geli\u015ftirme ekiplerinin otonomisini art\u0131r\u0131r, farkl\u0131 teknolojileri kullanma esnekli\u011fi sunar ve hatalar\u0131n yay\u0131lmas\u0131n\u0131 s\u0131n\u0131rlar.<\/p>\n Mikroservislerin sundu\u011fu potansiyel faydalar ger\u00e7ekten \u00e7ok \u00e7ekicidir:<\/p>\n Ancak, mikroservis d\u00fcnyas\u0131 da kendi i\u00e7inde yeni zorluklar bar\u0131nd\u0131r\u0131r. Da\u011f\u0131t\u0131k sistemlerin karma\u015f\u0131kl\u0131\u011f\u0131, servisler aras\u0131 ileti\u015fimin y\u00f6netimi, veri tutarl\u0131l\u0131\u011f\u0131, da\u011f\u0131t\u0131k izleme (distributed tracing), hata ay\u0131klama ve operasyonel karma\u015f\u0131kl\u0131k gibi konular, iyi planlanmad\u0131\u011f\u0131 takdirde monolitik bir k\u00e2bustan daha b\u00fcy\u00fck bir ba\u015f a\u011fr\u0131s\u0131na d\u00f6n\u00fc\u015febilir. Bu ge\u00e7i\u015f, dikkatli bir strateji ve do\u011fru ara\u00e7 setini gerektirir. Aksi takdirde, monolitik bir yap\u0131dan kurtulmaya \u00e7al\u0131\u015f\u0131rken kendinizi servislerin birbirine doland\u0131\u011f\u0131, y\u00f6netimi daha da zor bir “da\u011f\u0131t\u0131k monolit” i\u00e7inde bulabilirsiniz.<\/p>\n Peki, bu ge\u00e7i\u015fi mevcut i\u015f mant\u0131\u011f\u0131 kodumuza dokunmadan, adeta sihirli bir dokunu\u015fla nas\u0131l yapabiliriz? Cevap, yaz\u0131l\u0131m prensiplerinin derinliklerinde yat\u0131yor: Inversion of Control (IoC) ve onun yayg\u0131n bir uygulamas\u0131 olan Dependency Injection (DI). Bu kavramlar, uygulamalar\u0131m\u0131z\u0131n mod\u00fcllerini ve ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 y\u00f6netme \u015feklimizi k\u00f6kten de\u011fi\u015ftirerek, gelecekteki mimari d\u00f6n\u00fc\u015f\u00fcmlere kap\u0131 aralayan g\u00fc\u00e7l\u00fc bir temel olu\u015fturur. IoC, ba\u011f\u0131ml\u0131l\u0131klar\u0131 do\u011frudan olu\u015fturmak yerine d\u0131\u015far\u0131dan enjekte ederek, mod\u00fcller aras\u0131ndaki s\u0131k\u0131 ba\u011f\u0131ml\u0131l\u0131\u011f\u0131 ortadan kald\u0131r\u0131r ve esneklik, test edilebilirlik ve yeniden kullan\u0131labilirlik sa\u011flar. Bu sayede, uygulaman\u0131n \u00e7ekirdek i\u015flevselli\u011fini de\u011fi\u015ftirmeden, altta yatan servis implementasyonlar\u0131n\u0131 kolayca de\u011fi\u015ftirebiliriz. Bu, monolitik bir sistemden mikroservis mimarisine ge\u00e7i\u015fin en kritik ad\u0131mlar\u0131ndan biridir.<\/p>\n IoC, bir yaz\u0131l\u0131m bile\u015feninin ak\u0131\u015f\u0131n\u0131 kontrol eden nesneleri tersine \u00e7evirme prensibidir. Geleneksel programlamada, bir bile\u015fen ihtiya\u00e7 duydu\u011fu ba\u011f\u0131ml\u0131l\u0131klar\u0131 kendi i\u00e7inde do\u011frudan olu\u015fturur veya arar. IoC ile ise, bu ba\u011f\u0131ml\u0131l\u0131klar bile\u015fene d\u0131\u015far\u0131dan sa\u011flan\u0131r. Yani, “kontrol\u00fcn tersine \u00e7evrilmesi” durumu, bir bile\u015fenin kendi ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 y\u00f6netmek yerine, bu y\u00f6netimin d\u0131\u015f bir “konteyner” veya “\u00e7er\u00e7eve” taraf\u0131ndan ele al\u0131nmas\u0131 anlam\u0131na gelir.<\/p>\n Dependency Injection (DI)<\/strong> ise, Inversion of Control prensibinin en yayg\u0131n ve etkili uygulamalar\u0131ndan biridir. DI, bir nesnenin ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131, yani \u00e7al\u0131\u015fmas\u0131 i\u00e7in ihtiya\u00e7 duydu\u011fu di\u011fer nesneleri, do\u011frudan kendi i\u00e7inde olu\u015fturmak yerine, yap\u0131land\u0131r\u0131c\u0131 (constructor), \u00f6zellik (property) veya metod (method) arac\u0131l\u0131\u011f\u0131yla d\u0131\u015far\u0131dan almas\u0131n\u0131 sa\u011flar. Bu sayede, ba\u011f\u0131ml\u0131l\u0131klar s\u0131k\u0131ca ba\u011flanmak yerine gev\u015fek bir \u015fekilde ba\u011flan\u0131r. Gelin, bunu basit bir \u00f6rnekle a\u00e7\u0131klayal\u0131m.<\/p>\n Diyelim ki bir e-ticaret uygulaman\u0131z var ve <\/code><\/p>\n Bu \u00f6rnekte, \u015eimdi ayn\u0131 \u00f6rne\u011fi IoC ve DI prensipleriyle ele alal\u0131m. \u00d6nce bir aray\u00fcz tan\u0131mlar\u0131z:<\/p>\n <\/code><\/p>\n Bu yakla\u015f\u0131mda, IoC konteynerleri (Spring Framework'teki ApplicationContext, .NET'teki Microsoft.Extensions.DependencyInjection, Autofac, Ninject gibi) bu enjeksiyon s\u00fcrecini otomatikle\u015ftirerek, ba\u011f\u0131ml\u0131l\u0131klar\u0131 y\u00f6netme y\u00fck\u00fcn\u00fc geli\u015ftiriciden al\u0131r. Konteyner, hangi aray\u00fcze hangi somut s\u0131n\u0131f\u0131n kar\u015f\u0131l\u0131k geldi\u011fini bilir ve ihtiya\u00e7 duyuldu\u011funda do\u011fru nesneyi olu\u015fturup enjekte eder. Bu sayede, uygulaman\u0131n bile\u015fenleri aras\u0131ndaki ba\u011flant\u0131lar dinamik hale gelir ve de\u011fi\u015fime \u00e7ok daha a\u00e7\u0131k bir yap\u0131ya sahip oluruz.<\/p>\n Uzman \u0130pucu: IoC\/DI, sadece mod\u00fclerlik ve test edilebilirlik sa\u011flamakla kalmaz, ayn\u0131 zamanda kodun yeniden kullan\u0131labilirli\u011fini de art\u0131r\u0131r. Farkl\u0131 ba\u011flamlarda ayn\u0131 aray\u00fcz\u00fcn farkl\u0131 implementasyonlar\u0131n\u0131 kullanarak i\u015f mant\u0131\u011f\u0131n\u0131 tekrarlamaktan ka\u00e7\u0131nabilirsiniz. Bu, \u00f6zellikle b\u00fcy\u00fck ve karma\u015f\u0131k uygulamalarda geli\u015ftirme h\u0131z\u0131n\u0131 ve kod kalitesini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r.<\/p>\n<\/blockquote>\n \u015eimdi geldik makalemizin can al\u0131c\u0131 noktas\u0131na: IoC'nin monolitik bir uygulamay\u0131 mikroservislere d\u00f6n\u00fc\u015ft\u00fcrme s\u00fcrecindeki rol\u00fcne. Mevcut i\u015f mant\u0131\u011f\u0131 kodunuzu de\u011fi\u015ftirmeden bu d\u00f6n\u00fc\u015f\u00fcm\u00fc yapma vaadi, kula\u011fa ger\u00e7ek d\u0131\u015f\u0131 gelebilir, ancak IoC ve DI'\u0131n g\u00fcc\u00fcyle bu m\u00fcmk\u00fcnd\u00fcr.<\/p>\n Ana fikir \u015fudur: IoC, ba\u011f\u0131ml\u0131l\u0131klar\u0131 soyutlamalar (aray\u00fczler) \u00fczerinden y\u00f6netmenizi sa\u011flad\u0131\u011f\u0131 i\u00e7in, uygulaman\u0131z\u0131n temel i\u015f mant\u0131\u011f\u0131n\u0131n (\u00f6rne\u011fin, bir sipari\u015fin nas\u0131l olu\u015fturuldu\u011fu) belirli bir veri depolama mekanizmas\u0131 veya ileti\u015fim kanal\u0131 gibi alt seviye detaylara s\u0131k\u0131 s\u0131k\u0131ya ba\u011fl\u0131 olmas\u0131n\u0131 engeller. Bu sayede, i\u015f mant\u0131\u011f\u0131 katman\u0131n\u0131z\u0131, altta yatan implementasyonlardan ba\u011f\u0131ms\u0131z hale getirirsiniz.<\/p>\n Ge\u00e7i\u015f s\u00fcrecinde izlenecek yol, \"Strangler Fig Pattern\" olarak bilinen yakla\u015f\u0131ma benzer. Mevcut monolitinizi tamamen yeniden yazmak yerine, k\u00fc\u00e7\u00fck par\u00e7alar halinde yeni mikroservisler olu\u015fturarak monolitin i\u015flevselli\u011fini yava\u015f yava\u015f d\u0131\u015far\u0131 \u00e7ekersiniz. IoC, bu d\u0131\u015far\u0131 \u00e7ekme i\u015flemini inan\u0131lmaz derecede kolayla\u015ft\u0131r\u0131r.<\/p>\n Ba\u015flang\u0131\u00e7ta, monolitiniz i\u00e7indeki bir Monolitinizi mikroservislere d\u00f6n\u00fc\u015ft\u00fcrmeye ba\u015flad\u0131\u011f\u0131n\u0131zda, bu <\/code><\/p>\n Bu Bu senaryoda, monolitin IoC yap\u0131land\u0131rmas\u0131 \u015f\u00f6yle de\u011fi\u015fir (\u00f6rne\u011fin .NET Core DI):<\/p>\n <\/code><\/p>\n G\u00f6rd\u00fc\u011f\u00fcn\u00fcz gibi, i\u015f mant\u0131\u011f\u0131n\u0131 i\u00e7eren Hayali bir e-ticaret platformu olan \"TrendSepet\"in monolitik bir yap\u0131dan mikroservislere ge\u00e7i\u015f hikayesini ele alal\u0131m. TrendSepet, ba\u015flang\u0131\u00e7ta tek bir b\u00fcy\u00fck .NET uygulamas\u0131 olarak geli\u015ftirildi. Kullan\u0131c\u0131 y\u00f6netimi, \u00fcr\u00fcn katalogu, sipari\u015f i\u015fleme, \u00f6deme, kargo ve bildirimler gibi t\u00fcm mod\u00fcller ayn\u0131 projede yer al\u0131yordu. IoC (\u00f6zellikle .NET'in yerle\u015fik DI konteyneri) kullan\u0131larak tasarlanm\u0131\u015f olmas\u0131na ra\u011fmen, t\u00fcm implementasyonlar monolit i\u00e7inde bulunuyordu.<\/p>\n Zamanla, TrendSepet b\u00fcy\u00fcd\u00fc ve sipari\u015f i\u015fleme mod\u00fcl\u00fc yo\u011fun y\u00fcke maruz kal\u0131rken, \u00fcr\u00fcn katalogu daha az dinamikti. Bildirimler (e-posta, SMS) ise yava\u015f \u00e7al\u0131\u015f\u0131yor ve platformun genel performans\u0131n\u0131 etkiliyordu. Ekip, bu sorunlar\u0131 \u00e7\u00f6zmek ve daha h\u0131zl\u0131 \u00f6zellik geli\u015ftirmek i\u00e7in mikroservislere ge\u00e7meye karar verdi.<\/p>\n \u0130lk hedef, performans\u0131 en \u00e7ok etkileyen ve di\u011fer mod\u00fcllerden en ba\u011f\u0131ms\u0131z olan \"Bildirim Servisi\" oldu. TrendSepet monoliti i\u00e7inde, D\u00f6n\u00fc\u015f\u00fcm Ad\u0131mlar\u0131:<\/strong><\/p>\n Sonu\u00e7:<\/strong> Monolit i\u00e7indeki hi\u00e7bir Benzer bir yakla\u015f\u0131mla, D\u00f6n\u00fc\u015f\u00fcm Ad\u0131mlar\u0131:<\/strong><\/p>\n Bu kademeli ge\u00e7i\u015f sayesinde, TrendSepet ekibi, \u00fcretim ortam\u0131nda kesintisiz bir hizmet sunarken, ad\u0131m ad\u0131m monolitlerini daha y\u00f6netilebilir ve \u00f6l\u00e7eklenebilir mikroservislere d\u00f6n\u00fc\u015ft\u00fcrmeyi ba\u015fard\u0131. Her ad\u0131mda risk minimumda tutuldu, \u00e7\u00fcnk\u00fc mevcut i\u015f mant\u0131\u011f\u0131 kodlar\u0131 de\u011fi\u015fmedi. De\u011fi\u015fen tek \u015fey, ba\u011f\u0131ml\u0131l\u0131klar\u0131n IoC konteyneri arac\u0131l\u0131\u011f\u0131yla nas\u0131l \u00e7\u00f6z\u00fcld\u00fc\u011f\u00fc oldu.<\/p>\n Bu vaka analizi, IoC'nin sadece kod kalitesini art\u0131rmakla kalmay\u0131p, ayn\u0131 zamanda b\u00fcy\u00fck mimari d\u00f6n\u00fc\u015f\u00fcmleri nas\u0131l m\u00fcmk\u00fcn k\u0131ld\u0131\u011f\u0131n\u0131 a\u00e7\u0131k\u00e7a g\u00f6stermektedir. \u0130\u015f mant\u0131\u011f\u0131 kodunu de\u011fi\u015ftirmeden, altta yatan implementasyonlar\u0131 yerel bir s\u0131n\u0131ftan uzak bir mikroservise ge\u00e7irmek, IoC'nin sa\u011flad\u0131\u011f\u0131 en b\u00fcy\u00fck stratejik avantajlardan biridir.<\/p>\n IoC ve DI, monolitik bir uygulamay\u0131 mikroservislere d\u00f6n\u00fc\u015ft\u00fcrmek i\u00e7in g\u00fc\u00e7l\u00fc bir temel sa\u011flasa da, bu d\u00f6n\u00fc\u015f\u00fcm\u00fcn tam potansiyelini ortaya \u00e7\u0131karmak ve yeni mimarinin getirece\u011fi zorluklarla ba\u015fa \u00e7\u0131kmak i\u00e7in baz\u0131 ileri d\u00fczey teknikler ve en iyi uygulamalar mevcuttur. Unutmayal\u0131m ki mikroservisler, kendi i\u00e7inde y\u00f6netim ve operasyonel karma\u015f\u0131kl\u0131klar\u0131 bar\u0131nd\u0131r\u0131r.<\/p>\n Farkl\u0131 ortamlar (geli\u015ftirme, test, \u00fcretim) i\u00e7in farkl\u0131 ba\u011f\u0131ml\u0131l\u0131k implementasyonlar\u0131 kullanmak yayg\u0131n bir senaryodur. \u00d6rne\u011fin, geli\u015ftirme ortam\u0131nda sahte servisler (mock services) kullan\u0131rken, \u00fcretimde ger\u00e7ek implementasyonlar\u0131 kullanmak isteyebilirsiniz. IoC konteynerleri, bu t\u00fcr ortam bazl\u0131 yap\u0131land\u0131rmalar\u0131 kolayca y\u00f6netmenizi sa\u011flar. .NET Core'da Mikroservis mimarisinde servisler aras\u0131 ileti\u015fimde a\u011f gecikmeleri veya servis kesintileri ya\u015fanabilir. Monolitten ayr\u0131\u015ft\u0131r\u0131p uzak servisleri \u00e7a\u011f\u0131rmaya ba\u015flad\u0131\u011f\u0131n\u0131zda, bu sorunlarla kar\u015f\u0131la\u015fma olas\u0131l\u0131\u011f\u0131n\u0131z artar. <\/code><\/p>\n Baz\u0131 durumlarda, bir servisin ba\u015fka bir servisi \u00e7a\u011f\u0131rmas\u0131 ve hemen yan\u0131t beklemesi (senkron ileti\u015fim) ideal olmayabilir. \u00d6zellikle bildirimler, loglama veya uzun s\u00fcren i\u015fleme g\u00f6revleri i\u00e7in asenkron ileti\u015fim (mesaj kuyruklar\u0131 kullanarak) daha uygun olabilir. \u00d6rne\u011fin, bir sipari\u015f olu\u015fturuldu\u011funda, Birden fazla mikroservis ve monolitin bir arada \u00e7al\u0131\u015ft\u0131\u011f\u0131 bir ortamda, yap\u0131land\u0131rma ayarlar\u0131n\u0131 (veri taban\u0131 ba\u011flant\u0131 dizgileri, API anahtarlar\u0131, servis URL'leri) her serviste ayr\u0131 ayr\u0131 y\u00f6netmek zorla\u015f\u0131r. Spring Cloud Config (Java d\u00fcnyas\u0131nda) veya Consul gibi merkezi yap\u0131land\u0131rma sunucular\u0131, t\u00fcm servislerin yap\u0131land\u0131rma ayarlar\u0131n\u0131 tek bir yerden almas\u0131n\u0131 sa\u011flayarak y\u00f6netimi basitle\u015ftirir. Bu, \u00f6zellikle farkl\u0131 ortamlarda (dev, test, prod) farkl\u0131 yap\u0131land\u0131rmalar kullan\u0131ld\u0131\u011f\u0131nda paha bi\u00e7ilmezdir.<\/p>\n Mikroservislere ge\u00e7i\u015fle birlikte, uygulamalar\u0131n\u0131z\u0131n genel sa\u011fl\u0131\u011f\u0131n\u0131 ve performans\u0131n\u0131 izlemek daha karma\u015f\u0131k hale gelir. Her servisin ayr\u0131 ayr\u0131 sa\u011fl\u0131k durumunu kontrol eden (\u00f6rne\u011fin Bir kullan\u0131c\u0131 iste\u011fi birden fazla mikroservisten ge\u00e7ti\u011finde, bu iste\u011fin yolculu\u011funu takip etmek ve performans\u0131 veya hatalar\u0131 anlamak zorla\u015f\u0131r. Da\u011f\u0131t\u0131k izleme sistemleri (OpenTelemetry, Jaeger, Zipkin gibi) her iste\u011fe benzersiz bir izleme kimli\u011fi atar ve bu kimli\u011fi istek t\u00fcm servisler aras\u0131nda dola\u015f\u0131rken ta\u015f\u0131r. Bu sayede, bir iste\u011fin hangi servislerden ge\u00e7ti\u011fini, her serviste ne kadar zaman harcad\u0131\u011f\u0131n\u0131 ve hangi serviste hata olu\u015ftu\u011funu g\u00f6rselle\u015ftirebilirsiniz. Bu, mikroservis ortam\u0131nda hata ay\u0131klama ve performans optimizasyonu i\u00e7in vazge\u00e7ilmez bir ara\u00e7t\u0131r.<\/p>\n Monolit i\u00e7erisinde metod \u00e7a\u011fr\u0131lar\u0131 genellikle g\u00fcvenli kabul edilirken, mikroservisler aras\u0131nda ileti\u015fim genellikle a\u011f \u00fczerinden ger\u00e7ekle\u015fti\u011fi i\u00e7in g\u00fcvenlik \u00f6nemli bir endi\u015fe kayna\u011f\u0131d\u0131r. Servisler aras\u0131 ileti\u015fimi TLS\/SSL ile \u015fifrelemek, JWT (JSON Web Tokens) veya OAuth2 gibi standartlar\u0131 kullanarak kimlik do\u011frulama ve yetkilendirme sa\u011flamak gerekir. Monolitten \u00e7a\u011fr\u0131lan proxy'lerin bu g\u00fcvenlik mekanizmalar\u0131n\u0131 do\u011fru bir \u015fekilde uygulad\u0131\u011f\u0131ndan emin olmal\u0131s\u0131n\u0131z.<\/p>\n Bu ileri seviye uygulamalar, IoC'nin sa\u011flad\u0131\u011f\u0131 temel esnekli\u011fi kullanarak, monolit d\u00f6n\u00fc\u015f\u00fcm\u00fcn\u00fcz\u00fc sadece m\u00fcmk\u00fcn k\u0131lmakla kalmaz, ayn\u0131 zamanda ortaya \u00e7\u0131kan mikroservis ortam\u0131n\u0131z\u0131n sa\u011flam, g\u00fcvenilir ve y\u00f6netilebilir olmas\u0131n\u0131 sa\u011flar. Mobil uyumlu bir aray\u00fcz geli\u015ftiriyorsan\u0131z, bu t\u00fcr izleme ve hata ay\u0131klama sistemleri, mobil uygulaman\u0131z\u0131n backend servisleriyle etkile\u015fimini anlaman\u0131za ve optimize etmenize de yard\u0131mc\u0131 olacakt\u0131r. \u00d6rne\u011fin, mobil uygulaman\u0131zdan gelen bir iste\u011fin hangi mikroservislerde yava\u015flad\u0131\u011f\u0131n\u0131 h\u0131zla tespit edebilir ve performans darbo\u011fazlar\u0131n\u0131 giderebilirsiniz. Ayr\u0131ca, mobil uygulamalar\u0131n farkl\u0131 ekran boyutlar\u0131na ve cihazlara uyumlu olmas\u0131 i\u00e7in HTML i\u00e7erisinde <\/code><\/p>\n Bu gibi responsive tasar\u0131m pratikleri, mikroservislerin sundu\u011fu API'leri t\u00fcketen \u00f6n y\u00fcz uygulamalar\u0131n\u0131n da kullan\u0131c\u0131 odakl\u0131 ve eri\u015filebilir olmas\u0131n\u0131 destekler. \u00d6zellikle mobil \u00f6n y\u00fczler ve mikroservis backend'ler aras\u0131ndaki API ileti\u015fiminde, performans ve g\u00fcvenli\u011fi art\u0131rmak i\u00e7in bu t\u00fcr teknikler hayati \u00f6neme sahiptir.<\/p>\n Monolitik yap\u0131lardan mikroservislere ge\u00e7i\u015f, modern yaz\u0131l\u0131m mimarisinin en b\u00fcy\u00fck zorluklar\u0131ndan biridir. Ancak, Inversion of Control (IoC) ve onun pratik uygulamas\u0131 olan Dependency Injection (DI) prensipleri sayesinde, bu d\u00f6n\u00fc\u015f\u00fcm\u00fcn sanc\u0131l\u0131 ve riskli \"t\u00fcm kodlar\u0131 ba\u015ftan yazma\" senaryosundan kurtulmak m\u00fcmk\u00fcnd\u00fcr. IoC, yaz\u0131l\u0131m bile\u015fenleri aras\u0131ndaki s\u0131k\u0131 ba\u011f\u0131ml\u0131l\u0131klar\u0131 gev\u015feterek, i\u015f mant\u0131\u011f\u0131 kodunuzu de\u011fi\u015ftirmeden altta yatan implementasyonlar\u0131 (\u00f6rne\u011fin, yerel bir s\u0131n\u0131ftan uzaktaki bir mikroservis proxy'sine) de\u011fi\u015ftirme esnekli\u011fi sunar. Bu, \"Strangler Fig Pattern\" gibi yakla\u015f\u0131mlarla, monolitik uygulaman\u0131z\u0131n i\u015flevselli\u011fini ad\u0131m ad\u0131m d\u0131\u015far\u0131 \u00e7ekerek, kontroll\u00fc ve d\u00fc\u015f\u00fck riskli bir ge\u00e7i\u015f yapman\u0131z\u0131 sa\u011flar.<\/p>\n Bu makalede g\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi, IoC'nin temel prensiplerini uygulayarak, bir e-ticaret platformunun bildirim ve \u00fcr\u00fcn katalogu servislerini monolitinden ay\u0131r\u0131p ba\u011f\u0131ms\u0131z mikroservislere d\u00f6n\u00fc\u015ft\u00fcrmek, mevcut i\u015f koduna dokunmadan m\u00fcmk\u00fcn olmu\u015ftur. Bu d\u00f6n\u00fc\u015f\u00fcm sadece esneklik ve \u00f6l\u00e7eklenebilirlik sa\u011flamakla kalmaz, ayn\u0131 zamanda geli\u015ftirme h\u0131z\u0131n\u0131 art\u0131r\u0131r ve ekiplerin daha otonom \u00e7al\u0131\u015fmas\u0131na olanak tan\u0131r. Ancak, mikroservis d\u00fcnyas\u0131n\u0131n kendine \u00f6zg\u00fc zorluklar\u0131n\u0131 (da\u011f\u0131t\u0131k sistem y\u00f6netimi, ileti\u015fim, izleme, g\u00fcvenlik) g\u00f6z ard\u0131 etmemek ve Devre Kesici, Yeniden Deneme, mesaj kuyruklar\u0131 gibi ileri seviye desenlerle bu zorluklar\u0131 proaktif bir \u015fekilde y\u00f6netmek b\u00fcy\u00fck \u00f6nem ta\u015f\u0131r. Do\u011fru ara\u00e7lar ve stratejilerle, IoC'nin g\u00fcc\u00fcn\u00fc kullanarak, monolitik miras\u0131n\u0131z\u0131 gelece\u011fin mikroservis mimarisine ba\u015far\u0131l\u0131 bir \u015fekilde ta\u015f\u0131yabilirsiniz.<\/p>\n 1. IoC ve DI sadece monolitleri mikroservislere d\u00f6n\u00fc\u015ft\u00fcrmek i\u00e7in mi kullan\u0131l\u0131r?<\/strong><\/p>\n Hay\u0131r, kesinlikle de\u011fil. IoC ve DI, yaz\u0131l\u0131m geli\u015ftirme genelinde daha iyi kod kalitesi, test edilebilirlik, mod\u00fclerlik ve esneklik sa\u011flamak i\u00e7in kullan\u0131lan temel prensiplerdir. Monolitten mikroservislere ge\u00e7i\u015f, bu prensiplerin sa\u011flad\u0131\u011f\u0131 faydalar\u0131n en \u00e7arp\u0131c\u0131 \u00f6rneklerinden biridir, ancak IoC\/DI, herhangi bir uygulaman\u0131n tasar\u0131m\u0131n\u0131 ve s\u00fcrd\u00fcr\u00fclebilirli\u011fini geli\u015ftirmek i\u00e7in de kullan\u0131l\u0131r.<\/p>\n 2. Mevcut monolitik uygulamamda hi\u00e7 IoC\/DI kullan\u0131lm\u0131yorsa ne yapmal\u0131y\u0131m?<\/strong><\/p>\n Bu durumda, do\u011frudan mikroservislere ge\u00e7i\u015fe ba\u015flamadan \u00f6nce, monolitinizi kademeli olarak IoC\/DI'ya adapte etmeniz gerekebilir. Bu, \"refactoring\" s\u00fcreci gerektirir. Temel i\u015f mant\u0131\u011f\u0131 s\u0131n\u0131flar\u0131n\u0131z\u0131 aray\u00fczler \u00fczerinden ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 alacak \u015fekilde yeniden yap\u0131land\u0131rman\u0131z ve bir IoC konteyneri (\u00f6rne\u011fin .NET i\u00e7in AutoFac, Java i\u00e7in Spring DI) entegre etmeniz ilk ad\u0131mlar olacakt\u0131r. Bu, yine de bir miktar kod de\u011fi\u015fikli\u011fi anlam\u0131na gelir, ancak i\u015f mant\u0131\u011f\u0131na do\u011frudan m\u00fcdahale etmeden mimariyi iyile\u015ftirir.<\/p>\n 3. IoC konteynerleri performans\u0131 olumsuz etkiler mi?<\/strong><\/p>\n Modern IoC konteynerleri olduk\u00e7a optimize edilmi\u015f durumdad\u0131r ve genellikle uygulaman\u0131n ba\u015flang\u0131\u00e7 zaman\u0131 d\u0131\u015f\u0131nda \u00f6nemli bir performans y\u00fck\u00fc getirmezler. Ba\u011f\u0131ml\u0131l\u0131k \u00e7\u00f6zme i\u015flemi genellikle h\u0131zl\u0131d\u0131r ve bir kez olu\u015fturulan \u00f6rnekler (singleton ya\u015fam d\u00f6ng\u00fcs\u00fcyle) tekrar kullan\u0131labilir. Performans endi\u015feleri genellikle mikroservisler aras\u0131 a\u011f \u00e7a\u011fr\u0131lar\u0131ndan veya k\u00f6t\u00fc tasarlanm\u0131\u015f servis etkile\u015fimlerinden kaynaklan\u0131r, IoC konteynerinin kendisinden de\u011fil.<\/p>\n 4. Her ba\u011f\u0131ml\u0131l\u0131\u011f\u0131 mikroservise mi d\u00f6n\u00fc\u015ft\u00fcrmeliyim?<\/strong><\/p>\n Hay\u0131r, her ba\u011f\u0131ml\u0131l\u0131k veya her mod\u00fcl mikroservise d\u00f6n\u00fc\u015ft\u00fcr\u00fclmek zorunda de\u011fildir. Ge\u00e7i\u015fin amac\u0131, uygulaman\u0131n en kritik, en \u00e7ok de\u011fi\u015fen veya en \u00e7ok \u00f6l\u00e7eklenmesi gereken k\u0131s\u0131mlar\u0131n\u0131 ay\u0131rmakt\u0131r. Bir mod\u00fcl\u00fcn ba\u011f\u0131ms\u0131z bir mikroservis olmaya uygun olup olmad\u0131\u011f\u0131n\u0131 de\u011ferlendirmek i\u00e7in Sorumluluk, \u00d6l\u00e7eklenebilirlik \u0130htiyac\u0131, Ba\u011f\u0131ms\u0131zl\u0131k ve Ekip Sahiplenmesi gibi kriterler g\u00f6z \u00f6n\u00fcnde bulundurulmal\u0131d\u0131r. K\u00fc\u00e7\u00fck ve kararl\u0131 mod\u00fcllerin monolit i\u00e7inde kalmas\u0131 veya daha b\u00fcy\u00fck bir mikroservis grubunun par\u00e7as\u0131 olmas\u0131 tercih edilebilir.<\/p>\n <\/body><\/p>\n","protected":false},"excerpt":{"rendered":"Devasa monolitik uygulamalar\u0131n\u0131z\u0131n bak\u0131m\u0131n\u0131n zorla\u015ft\u0131\u011f\u0131n\u0131, yeni \u00f6zellik eklemenin bir k\u00e2busa d\u00f6n\u00fc\u015ft\u00fc\u011f\u00fcn\u00fc ve her k\u00fc\u00e7\u00fck de\u011fi\u015fiklik i\u00e7in t\u00fcm sistemi…","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1],"tags":[],"class_list":{"0":"post-35567","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-genel","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\n\n
Mikroservislere Ge\u00e7i\u015f: Yeni Bir Ba\u015flang\u0131\u00e7 m\u0131, Yoksa Daha B\u00fcy\u00fck Bir Karma\u015fa m\u0131?<\/h2>\n
\n
Inversion of Control (IoC) ve Dependency Injection (DI) Nedir?<\/h2>\n
Geleneksel Yakla\u015f\u0131m (S\u0131k\u0131 Ba\u011fl\u0131l\u0131k)<\/h3>\n
SiparisManager<\/code> s\u0131n\u0131f\u0131n\u0131z\u0131n MailServisi<\/code>ne ihtiyac\u0131 var:<\/p>\n\npublic class MailServisi\n{\n public void MailGonder(string alici, string konu, string icerik)\n {\n Console.WriteLine($\"{alici} adresine mail g\u00f6nderildi. Konu: {konu}\");\n }\n}\n\npublic class SiparisManager\n{\n private MailServisi _mailServisi;\n\n public SiparisManager()\n {\n _mailServisi = new MailServisi(); \/\/ Ba\u011f\u0131ml\u0131l\u0131k burada olu\u015fturuluyor\n }\n\n public void SiparisOlustur(int siparisId, string urunAdi, string aliciMail)\n {\n Console.WriteLine($\"Sipari\u015f {siparisId} olu\u015fturuldu: {urunAdi}\");\n _mailServisi.MailGonder(aliciMail, \"Sipari\u015f Onay\u0131\", $\"Sipari\u015finiz {siparisId} onaylanm\u0131\u015ft\u0131r.\");\n }\n}\n<\/pre>\nSiparisManager<\/code> do\u011frudan MailServisi<\/code>ni olu\u015fturuyor. Bu s\u0131k\u0131 ba\u011fl\u0131l\u0131k, test yazmay\u0131 zorla\u015ft\u0131r\u0131r (ger\u00e7ek bir mail servisi olmadan SiparisManager<\/code>\u0131 test edemezsiniz) ve MailServisi<\/code>ni de\u011fi\u015ftirmek istedi\u011finizde SiparisManager<\/code> s\u0131n\u0131f\u0131n\u0131 da de\u011fi\u015ftirmeniz gerekir. \u00d6rne\u011fin, mail servisini bir \u00fc\u00e7\u00fcnc\u00fc parti hizmet sa\u011flay\u0131c\u0131yla de\u011fi\u015ftirmek isterseniz veya bir SMS servisi eklemek isterseniz, SiparisManager<\/code> s\u0131n\u0131f\u0131nda de\u011fi\u015fiklik yapmak zorunda kal\u0131rs\u0131n\u0131z. Bu da \"tek bir sorumluluk prensibi\"ne ayk\u0131r\u0131d\u0131r ve karma\u015f\u0131kl\u0131\u011f\u0131 art\u0131r\u0131r.<\/p>\nIoC \/ DI Yakla\u015f\u0131m\u0131 (Gev\u015fek Ba\u011fl\u0131l\u0131k)<\/h3>\n
\npublic interface IMailServisi\n{\n void MailGonder(string alici, string konu, string icerik);\n}\n\npublic class MailServisiGercek : IMailServisi\n{\n public void MailGonder(string alici, string konu, string icerik)\n {\n Console.WriteLine($\"{alici} adresine GER\u00c7EK mail g\u00f6nderildi. Konu: {konu}\");\n }\n}\n\npublic class MailServisiSahte : IMailServisi \/\/ Test veya geli\u015ftirme ortamlar\u0131 i\u00e7in\n{\n public void MailGonder(string alici, string konu, string icerik)\n {\n Console.WriteLine($\"{alici} adresine SAHTE mail g\u00f6nderildi. Konu: {konu}\");\n }\n}\n\npublic class SiparisManager\n{\n private IMailServisi _mailServisi;\n\n public SiparisManager(IMailServisi mailServisi) \/\/ Ba\u011f\u0131ml\u0131l\u0131k d\u0131\u015far\u0131dan enjekte ediliyor\n {\n _mailServisi = mailServisi;\n }\n\n public void SiparisOlustur(int siparisId, string urunAdi, string aliciMail)\n {\n Console.WriteLine($\"Sipari\u015f {siparisId} olu\u015fturuldu: {urunAdi}\");\n _mailServisi.MailGonder(aliciMail, \"Sipari\u015f Onay\u0131\", $\"Sipari\u015finiz {siparisId} onaylanm\u0131\u015ft\u0131r.\");\n }\n}\n<\/pre>\nSiparisManager<\/code> art\u0131k IMailServisi<\/code> aray\u00fcz\u00fcne ba\u011f\u0131ml\u0131d\u0131r, somut bir implementasyona de\u011fil. IMailServisi<\/code>nin hangi implementasyonunun kullan\u0131laca\u011f\u0131na d\u0131\u015far\u0131dan karar verilir ve SiparisManager<\/code>'\u0131n yap\u0131land\u0131r\u0131c\u0131s\u0131na enjekte edilir. Bu, SiparisManager<\/code>'\u0131n kendi i\u00e7 i\u015f mant\u0131\u011f\u0131n\u0131 de\u011fi\u015ftirmeden MailServisiGercek<\/code> ile MailServisiSahte<\/code> aras\u0131nda ge\u00e7i\u015f yapmam\u0131z\u0131 sa\u011flar. Bu esneklik, \u00f6zellikle test yazarken veya farkl\u0131 ortamlar i\u00e7in farkl\u0131 implementasyonlar kullan\u0131rken paha bi\u00e7ilmezdir.<\/p>\n\n
IoC, Monolitten Mikroservise Ge\u00e7i\u015fi Nas\u0131l Kolayla\u015ft\u0131r\u0131r?<\/h2>\n
MailServisi<\/code> veya LogServisi<\/code> gibi bir bile\u015fen, IoC konteyneri taraf\u0131ndan y\u00f6netilen yerel bir implementasyon olarak yap\u0131land\u0131r\u0131lm\u0131\u015ft\u0131r. Diyelim ki, SiparisManager<\/code> s\u0131n\u0131f\u0131n\u0131z IMailServisi<\/code> aray\u00fcz\u00fcn\u00fc kullanarak mail g\u00f6nderiyor ve IoC konteyneri bu aray\u00fcz\u00fcn MailServisiGercek<\/code> s\u0131n\u0131f\u0131yla e\u015fle\u015fti\u011fini biliyor.<\/p>\nMailServisi<\/code> i\u015flevselli\u011fini ba\u011f\u0131ms\u0131z bir mikroservis olarak d\u0131\u015far\u0131 ta\u015f\u0131maya karar verebilirsiniz. Bu noktada yapman\u0131z gereken tek \u015fey, monolitin IoC yap\u0131land\u0131rmas\u0131n\u0131 de\u011fi\u015ftirmektir. IMailServisi<\/code> aray\u00fcz\u00fcne kar\u015f\u0131l\u0131k gelen implementasyonu MailServisiGercek<\/code> yerine, uzaktaki yeni mikroservisi t\u00fcketen bir MailServisiProxy<\/code> s\u0131n\u0131f\u0131na y\u00f6nlendirirsiniz.<\/p>\n\n\/\/ Yeni Mail Mikroservisi (ayr\u0131 bir uygulama)\n\/\/ Bu servis, HTTP API veya mesaj kuyru\u011fu arac\u0131l\u0131\u011f\u0131yla mail g\u00f6nderimini y\u00f6netir.\n\n\/\/ Monolit \u0130\u00e7indeki Proxy S\u0131n\u0131f\u0131\npublic class MailServisiProxy : IMailServisi\n{\n private readonly HttpClient _httpClient;\n private readonly string _mailServiceBaseUrl;\n\n public MailServisiProxy(HttpClient httpClient, string mailServiceBaseUrl)\n {\n _httpClient = httpClient;\n _mailServiceBaseUrl = mailServiceBaseUrl;\n }\n\n public async void MailGonder(string alici, string konu, string icerik)\n {\n var mailData = new { Alici = alici, Konu = konu, Icerik = icerik };\n var json = System.Text.Json.JsonSerializer.Serialize(mailData);\n var content = new StringContent(json, Encoding.UTF8, \"application\/json\");\n\n \/\/ Uzak Mail Mikroservisine HTTP iste\u011fi g\u00f6nder\n var response = await _httpClient.PostAsync($\"{_mailServiceBaseUrl}\/api\/mail\/gonder\", content);\n response.EnsureSuccessStatusCode();\n Console.WriteLine($\"Mail iste\u011fi uzak servise iletildi: {alici}\");\n }\n}\n<\/pre>\nMailServisiProxy<\/code> s\u0131n\u0131f\u0131, asl\u0131nda uzaktaki mikroservisle ileti\u015fim kurmak i\u00e7in bir adapt\u00f6r g\u00f6revi g\u00f6r\u00fcr. \u00d6rne\u011fin, HTTP istekleri veya mesaj kuyruklar\u0131 arac\u0131l\u0131\u011f\u0131yla uzaktaki servisle konu\u015fur. Monolit i\u00e7indeki SiparisManager<\/code> s\u0131n\u0131f\u0131n\u0131n veya IMailServisi<\/code> aray\u00fcz\u00fcn\u00fc kullanan herhangi ba\u015fka bir bile\u015fenin kodunu de\u011fi\u015ftirmeye gerek kalmaz. Onlar hala IMailServisi<\/code> aray\u00fcz\u00fc \u00fczerinden ileti\u015fim kurmaya devam ederler. De\u011fi\u015fen tek \u015fey, IoC konteynerinin bu aray\u00fcze hangi somut implementasyonu enjekte etti\u011fidir.<\/p>\n\n\/\/ Uygulama ba\u015flang\u0131c\u0131nda IoC konteyneri yap\u0131land\u0131rmas\u0131\npublic void ConfigureServices(IServiceCollection services)\n{\n \/\/ ... di\u011fer servisler\n\n \/\/ Eski durum (monolit i\u00e7indeki yerel implementasyon)\n \/\/ services.AddTransientSiparisManager<\/code> s\u0131n\u0131f\u0131n\u0131n i\u00e7indeki kodda *tek bir sat\u0131r bile de\u011fi\u015fiklik yapmad\u0131k*. De\u011fi\u015fen tek \u015fey, IoC konteynerine yap\u0131lan kay\u0131tt\u0131r. Bu, monolitinizi ad\u0131m ad\u0131m par\u00e7alara ay\u0131rman\u0131n ve her bir par\u00e7ay\u0131 ba\u011f\u0131ms\u0131z bir mikroservise d\u00f6n\u00fc\u015ft\u00fcrmenin yolunu a\u00e7ar. Bu s\u00fcre\u00e7, \"ayr\u0131\u015ft\u0131rma\" veya \"dekompozisyon\" olarak adland\u0131r\u0131l\u0131r ve IoC sayesinde \u00e7ok daha az riskli ve daha y\u00f6netilebilir hale gelir. Her seferinde k\u00fc\u00e7\u00fck bir fonksiyonelli\u011fi d\u0131\u015far\u0131 \u00e7ekip mikroservis olarak konumland\u0131rabilir ve monolit i\u00e7indeki eski ba\u011f\u0131ml\u0131l\u0131\u011f\u0131 bir proxy ile de\u011fi\u015ftirebilirsiniz. Bu, size d\u00f6n\u00fc\u015f\u00fcm s\u0131ras\u0131nda istikrar\u0131 koruma ve i\u015f kesintilerini minimuma indirme esnekli\u011fi sunar. B\u00f6ylece, b\u00fcy\u00fck bir operasyonel risk almak yerine, kontroll\u00fc ve kademeli bir ge\u00e7i\u015f stratejisi izleyebilirsiniz.<\/p>\nVaka Analizi: E-ticaret Platformunun Kademe Kademe D\u00f6n\u00fc\u015f\u00fcm\u00fc<\/h2>\n
Ad\u0131m 1: Bildirim Servisinin Ayr\u0131\u015ft\u0131r\u0131lmas\u0131<\/h3>\n
IBildirimServisi<\/code> aray\u00fcz\u00fc ve onun EmailBildirimServisi<\/code> ve SmsBildirimServisi<\/code> gibi implementasyonlar\u0131 mevcuttu. Monolitin her yerinde (sipari\u015f onay\u0131, kargo g\u00fcncellemeleri, \u015fifre s\u0131f\u0131rlama vb.) bu aray\u00fcz kullan\u0131l\u0131yordu.<\/p>\n\n
Bildirim.API<\/code> mikroservisi olu\u015fturuldu. Bu servis, bir HTTP POST endpoint'i (\/api\/bildirim\/gonder<\/code>) arac\u0131l\u0131\u011f\u0131yla mail ve SMS g\u00f6nderme i\u015flevselli\u011fini sa\u011flad\u0131. Kendi veri taban\u0131na (gerekirse) ve kuyruk sistemine (\u00f6rne\u011fin RabbitMQ veya Kafka) sahip olabilir.<\/li>\nBildirimServisiProxy<\/code> ad\u0131nda yeni bir s\u0131n\u0131f eklendi. Bu s\u0131n\u0131f IBildirimServisi<\/code> aray\u00fcz\u00fcn\u00fc implemente etti ve gelen istekleri yeni Bildirim.API<\/code> mikroservisine HTTP iste\u011fi olarak y\u00f6nlendirdi.<\/li>\nStartup.cs<\/code> dosyas\u0131nda (veya benzer bir yap\u0131land\u0131rma dosyas\u0131nda), IBildirimServisi<\/code> aray\u00fcz\u00fcn\u00fcn kayd\u0131, EmailBildirimServisi<\/code> veya SmsBildirimServisi<\/code> yerine BildirimServisiProxy<\/code>'yi i\u015faret edecek \u015fekilde g\u00fcncellendi.<\/li>\n<\/ol>\nSiparisManager<\/code> veya KullaniciManager<\/code> s\u0131n\u0131f\u0131n\u0131n kodu de\u011fi\u015ftirilmedi. Onlar hala IBildirimServisi.BildirimGonder()<\/code> metodunu \u00e7a\u011f\u0131r\u0131yorlard\u0131. Ancak art\u0131k bu \u00e7a\u011fr\u0131lar, arka planda uzaktaki bir mikroservise y\u00f6nlendiriliyordu. Bu sayede, bildirimlerin y\u00fck\u00fc monolit \u00fczerinden al\u0131nd\u0131, bildirim servisi ba\u011f\u0131ms\u0131z olarak \u00f6l\u00e7eklenebilir hale geldi ve farkl\u0131 bildirim sa\u011flay\u0131c\u0131lar\u0131 eklemek \u00e7ok daha kolayla\u015ft\u0131.<\/p>\nAd\u0131m 2: \u00dcr\u00fcn Katalogu Servisinin Ayr\u0131\u015ft\u0131r\u0131lmas\u0131<\/h3>\n
IUrunServisi<\/code> aray\u00fcz\u00fc ve onun UrunServisiYerel<\/code> implementasyonu da ayr\u0131\u015ft\u0131r\u0131lmaya ba\u015fland\u0131. UrunServisiYerel<\/code> ba\u015flang\u0131\u00e7ta monolitik veri taban\u0131na do\u011frudan ba\u011flan\u0131yordu.<\/p>\n\n
UrunKatalog.API<\/code> mikroservisi olu\u015fturuldu. Bu servis, kendi optimize edilmi\u015f veri taban\u0131na sahip oldu ve \u00fcr\u00fcn bilgilerini y\u00f6netmek i\u00e7in RESTful API'ler sa\u011flad\u0131.<\/li>\nUrunServisiProxy<\/code> s\u0131n\u0131f\u0131 olu\u015fturuldu, IUrunServisi<\/code> aray\u00fcz\u00fcn\u00fc implemente etti ve istekleri UrunKatalog.API<\/code>'ye y\u00f6nlendirdi.<\/li>\nIUrunServisi<\/code> kayd\u0131 UrunServisiProxy<\/code>'ye g\u00fcncellendi.<\/li>\n<\/ol>\n\u0130leri Seviye Optimizasyonlar ve En \u0130yi Uygulamalar<\/h2>\n
1. Ortam Bazl\u0131 Yap\u0131land\u0131rma Y\u00f6netimi<\/h3>\n
appsettings.json<\/code> ve appsettings.Development.json<\/code> gibi dosyalar veya ortam de\u011fi\u015fkenleri ile bu ayr\u0131m\u0131 yapabilirsiniz. IoC konteyneriniz, uygulaman\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131 ortama g\u00f6re uygun implementasyonu dinamik olarak y\u00fckleyebilir. Bu, test ve geli\u015ftirme s\u00fcre\u00e7lerinizi h\u0131zland\u0131r\u0131rken, \u00fcretimde g\u00fcvenilirli\u011fi sa\u011flar.<\/p>\n2. Devre Kesici (Circuit Breaker) ve Yeniden Deneme (Retry) Desenleri<\/h3>\n
MailServisiProxy<\/code> gibi proxy s\u0131n\u0131flar\u0131n\u0131zda Devre Kesici deseni uygulamak, bir uzak servis uzun s\u00fcre hata verdi\u011finde, o servise yap\u0131lan \u00e7a\u011fr\u0131lar\u0131 otomatik olarak keserek uygulaman\u0131z\u0131n di\u011fer k\u0131s\u0131mlar\u0131n\u0131n da \u00e7\u00f6kmesini engeller. Yeniden Deneme deseni ise ge\u00e7ici a\u011f sorunlar\u0131 veya servis me\u015fguliyeti durumlar\u0131nda ba\u015far\u0131s\u0131z olan istekleri belirli bir s\u00fcre sonra tekrar denemek i\u00e7in kullan\u0131l\u0131r. Polly gibi k\u00fct\u00fcphaneler bu desenleri kolayca implemente etmenize yard\u0131mc\u0131 olur.<\/p>\n\n\/\/ Polly k\u00fct\u00fcphanesi ile devre kesici ve yeniden deneme \u00f6rne\u011fi\npublic class MailServisiProxy : IMailServisi\n{\n private readonly HttpClient _httpClient;\n private readonly string _mailServiceBaseUrl;\n private readonly Policy _retryPolicy;\n private readonly Policy _circuitBreakerPolicy;\n\n public MailServisiProxy(HttpClient httpClient, string mailServiceBaseUrl)\n {\n _httpClient = httpClient;\n _mailServiceBaseUrl = mailServiceBaseUrl;\n\n _retryPolicy = Policy\n .Handle3. Asenkron \u0130leti\u015fim (Mesaj Kuyruklar\u0131)<\/h3>\n
SiparisManager<\/code> bir mail g\u00f6nderme iste\u011fini do\u011frudan MailServisiProxy<\/code>'ye iletmek yerine, bir mesaj kuyru\u011funa (Kafka, RabbitMQ, Azure Service Bus gibi) bir \"Mail G\u00f6nder\" mesaj\u0131 b\u0131rakabilir. MailServisiProxy<\/code> bu mesaj\u0131 kuyruktan okuyarak i\u015flemi ger\u00e7ekle\u015ftirebilir. Bu, monolitinizdeki SiparisManager<\/code>'\u0131n bir yandan i\u015fini bitirip di\u011fer yandan mail g\u00f6nderme i\u015fleminin ba\u015far\u0131s\u0131z olmas\u0131 durumunda geri d\u00f6n\u00fcp hatalar\u0131 y\u00f6netme sorumlulu\u011funu \u00fcstlenmesini engeller. Gev\u015fek ba\u011fl\u0131l\u0131\u011f\u0131 daha da art\u0131r\u0131r ve sistemin genel direncini y\u00fckseltir.<\/p>\n4. Merkezi Yap\u0131land\u0131rma Sunucular\u0131<\/h3>\n
5. Sa\u011fl\u0131k Kontrolleri (Health Checks) ve \u0130zleme (Monitoring)<\/h3>\n
\/health<\/code> endpoint'leri arac\u0131l\u0131\u011f\u0131yla) sa\u011fl\u0131k kontrolleri eklemek kritik \u00f6neme sahiptir. Prometheus, Grafana, ELK Stack (Elasticsearch, Logstash, Kibana) gibi ara\u00e7larla merkezi loglama ve metrik toplama sistemleri kurarak, da\u011f\u0131t\u0131k sisteminizin genel durumunu ger\u00e7ek zamanl\u0131 olarak izleyebilirsiniz. Bu, olas\u0131 sorunlar\u0131 h\u0131zl\u0131 bir \u015fekilde tespit etmenize ve gidermenize olanak tan\u0131r.<\/p>\n6. Da\u011f\u0131t\u0131k \u0130zleme (Distributed Tracing)<\/h3>\n
7. G\u00fcvenlik \u0130leti\u015fimi<\/h3>\n
media query<\/code>'ler kullan\u0131larak responsive tasar\u0131mlar yap\u0131lmas\u0131, kullan\u0131c\u0131 deneyimini iyile\u015ftiren \u00f6nemli bir ad\u0131md\u0131r:<\/p>\n\n\/* Mobil uyumluluk i\u00e7in CSS media query \u00f6rne\u011fi *\/\n@media screen and (max-width: 768px) {\n .ana-container {\n flex-direction: column; \/* K\u00fc\u00e7\u00fck ekranlarda dikey s\u0131ralama *\/\n }\n .yan-menu {\n display: none; \/* Yan men\u00fcy\u00fc gizle *\/\n }\n .mobil-nav-butonu {\n display: block; \/* Mobil navigasyon butonunu g\u00f6ster *\/\n }\n}\n<\/pre>\nSonu\u00e7: Gelece\u011fe Y\u00f6nelik Kodsuz Bir D\u00f6n\u00fc\u015f\u00fcm<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n