Ana içeriğe geç

Kitap 09 · Özet sayfa

Yazılım Mimarisi

Büyük kod tabanlarını düzenli ve bakımı kolay tutan tasarım ilkeleri ve mimari stiller.

01Adapter Deseni
Adapter deseni, mevcut bir sınıfı yeni bir arayüzle sararak bir arayüz bekleyen kodun uyumsuz bir arayüzü kullanabilmesini sağlayan yapısal tasarım desenidir.
  • Adapter, bir arayüzü istemci kodunun beklediği başka bir arayüze çevirir.
  • Uyumsuz sınıfların, hiçbirini değiştirmeden birlikte çalışmasını sağlar.
  • Object adapter kompozisyon kullanır; class adapter kalıtım kullanır.
02Backend for Frontend
Backend for frontend, web ya da mobil uygulama gibi her istemci türünün kendi ihtiyaçlarına göre uyarlanmış küçük bir backend aldığı bir mimari desendir.
  • BFF, web ya da mobil gibi belirli bir ön yüz için oluşturulmuş bir backend'dir.
  • Birkaç servisteki veriyi ekran başına tek yanıtta toplar ve yeniden şekillendirir.
  • Genellikle ön yüz ekibinin sahipliğindedir.
03Builder PatternKurucu Kalıbı
Builder pattern, karmaşık bir nesneyi ayrı bir builder nesnesiyle, argümanlarla dolu uzun bir constructor yerine adlandırılmış adımlarla adım adım oluşturur.
  • Builder, karmaşık nesneleri adlandırılmış ayarlarla adım adım oluşturur.
  • Teleskopik constructor sorununu çözer.
  • build(), nesneyi oluşturmadan önce varsayılanları uygular ve doğrular.
04Circuit Breaker Deseni
Circuit breaker deseni, arızalı bir bağımlılığa yapılan çağrıları bir süre durdurarak ve zaman aşımlarını beklemek yerine hızlıca hata vererek sistemi korur.
  • Circuit breaker uzak çağrıları sarar ve tekrarlanan hatalardan sonra durdurur.
  • Kapalı çağrıları geçirir, açık hızlıca hata verir, yarı açık ise servisin düzelip düzelmediğini dener.
  • Hızlı hata vermek kademeli arızaları önler ve iş parçacıklarını ile bağlantıları serbest bırakır.
05Clean ArchitectureTemiz Mimari
Clean architecture, temel iş kuralları framework'e, veritabanına ya da kullanıcı arayüzüne asla bağımlı olmasın diye yazılımı katmanlara ayırma yöntemidir.
  • Kod katmanlara ayrılır: entity'ler, use case'ler, arayüz adaptörleri ve framework'ler.
  • Bağımlılık kuralı: bağımlılıklar yalnızca içeriye, iş kurallarına doğru işaret eder.
  • İş mantığı arayüzleri tanımlar; dış katmanlar bunları uygular.
06Consistent HashingTutarlı Hashleme
Consistent hashing (tutarlı hashleme), anahtarları sunuculara, sunucu eklenip çıkarıldığında yalnızca küçük bir kısmı yer değiştirecek şekilde dağıtır.
  • Consistent hashing, anahtarları bir hash halkası üzerinde sunuculara eşler.
  • Bir sunucu eklemek ya da çıkarmak anahtarların yalnızca yaklaşık 1/n'ini taşır.
  • Düz modulo hash'leme, sunucular değiştiğinde neredeyse her anahtarı taşır.
07CQRSCommand Query Responsibility Segregation (Komut Sorgu Sorumluluğu Ayrımı)
CQRS, veriyi değiştiren kodu (komutlar) veriyi okuyan koddan (sorgular) ayırarak iki ayrı modele bölen bir mimari desendir.
  • Komutlar veriyi değiştirir; sorgular veriyi okur ve asla değiştirmez.
  • Her tarafın amacına göre optimize edilmiş kendi modeli vardır.
  • Okuma tarafı ayrı, denormalize görünümler ya da veritabanları kullanabilir.
08Dağıtık Sistem
Dağıtık sistem, bir ağ üzerinden birlikte çalışan ve kullanıcılarına tek bir sistem gibi görünen bilgisayarlar kümesidir.
  • Dağıtık sistem, tek bir sistem gibi davranan, ağa bağlı çok sayıda bilgisayardır.
  • Ölçek, hata toleransı ve kullanıcılara yakın hizmet için kurulur.
  • Kısmi arızalar, kayıp mesajlar, saat kayması ve ağ bölünmeleri olağandır.
09Decorator PatternDekoratör Kalıbı
Decorator pattern, bir nesneyi aynı arayüze sahip başka bir nesneyle sararak orijinal kodu değiştirmeden ona loglama, önbellekleme gibi davranışlar ekler.
  • Dekoratör bir nesneyi aynı arayüzle sarar ve davranış ekler.
  • Dekoratörler istenen her kombinasyonda ve sırada üst üste konabilir.
  • Mevcut sınıfları düzenlemeden davranışı genişletir.
10Dependency InjectionBağımlılık Enjeksiyonu
Dependency injection, bir nesnenin ihtiyaç duyduğu diğer nesneleri kendisi oluşturmak yerine dışarıdan almasını sağlayan bir tasarım tekniğidir.
  • Dependency injection, bir sınıfa ihtiyaç duyduğu nesneleri kendisi oluşturtmak yerine dışarıdan verir.
  • Constructor injection en yaygın ve en açık biçimdir.
  • Gerçek bağımlılıklar sahtelerle değiştirilebildiği için kodu test etmeyi kolaylaştırır.
11Dikey Ölçekleme
Dikey ölçekleme (scale up), daha fazla makine eklemek yerine tek bir makineye daha fazla CPU, bellek ya da daha hızlı depolama vererek kapasiteyi artırır.
  • Dikey ölçekleme tek bir makineye daha fazla CPU, bellek ya da daha hızlı depolama verir.
  • Kod değişikliği gerektirmez ve büyümenin en basit yoludur.
  • İlişkisel veritabanları gibi bölünmesi zor sistemlere uyar.
12Domain-Driven DesignAlan Odaklı Tasarım
Domain-driven design, kodu iş alanına yakından modelleyen ve alan uzmanlarıyla aynı dili kullanan bir yazılım geliştirme yaklaşımıdır.
  • DDD kodu iş alanına ve uzmanlarının bilgisine göre şekillendirir.
  • Ortak dil, iş terimlerini ve kod adlarını aynı tutar.
  • Bounded context'ler büyük bir alanı kendi modeli olan bölgelere ayırır.
13DRYDon't Repeat Yourself (Kendini Tekrar Etme)
DRY, her bilgi ya da mantık parçasının çoğaltılmak yerine tek bir yetkili temsile sahip olması gerektiğini söyleyen bir yazılım tasarım ilkesidir.
  • DRY, her bilgi ya da mantık parçasının tam olarak tek bir yerde bulunması demektir.
  • Tekrarlanan mantığın birkaç yerde değiştirilmesi gerekir; bu da hataları davet eder.
  • Ortak kodu fonksiyonlara, modüllere, sabitlere veya bileşenlere çıkarın.
14Event Sourcing
Event sourcing, uygulama durumundaki her değişikliği değiştirilemez bir olay olarak saklayıp güncel durumu olayları yeniden oynatarak kuran tasarım desenidir.
  • Durum değişiklikleri, yalnızca ekleme yapılan değiştirilemez bir olay dizisi olarak saklanır.
  • Güncel durum, çoğunlukla bir anlık görüntüden başlayarak olaylar yeniden oynatılarak oluşturulur.
  • Tam bir denetim izi sağlar ve geçmiş durumları yeniden oluşturmayı mümkün kılar.
15Factory Deseni
Factory deseni, nesne oluşturmayı özel bir fonksiyona ya da sınıfa taşıyan ve çağıranların somut sınıfı hiç adlandırmadığı oluşturucu bir tasarım desenidir.
  • Factory, nesne oluşturmayı tek bir fonksiyon ya da sınıfın arkasında merkezileştirir.
  • Çağıranlar, oluşturulan somut sınıfa değil, bir arayüze bağımlıdır.
  • Çeşitleri arasında simple factory, factory method ve abstract factory bulunur.
16Gevşek Bağlılık
Gevşek bağlılık, bileşenlerin birbirine olabildiğince az bağımlı olduğu, böylece birinin diğerlerini bozmadan değişebildiği bir tasarım ilkesidir.
  • Bağlılık, bir bileşenin diğerinin ayrıntılarına ne kadar bağımlı olduğunu ölçer.
  • Gevşek bağlı parçalar daha bağımsız biçimde değiştirilebilir, test edilebilir ve dağıtılabilir.
  • Arayüzler, dependency injection, API'ler ve olaylar bağlılığı azaltır.
17Hata Toleransı
Hata toleransı, bir sistemin bazı donanım ya da yazılım bileşenleri arızalandığında, belki azalmış kapasiteyle de olsa doğru çalışmayı sürdürebilmesidir.
  • Hata toleransı, bileşenler arızalandığında bir sistemi doğru çalışır tutar.
  • Hata (fault), bir bileşendeki sorundur; arıza (failure) ise tüm hizmetin durmasıdır.
  • Temeli yedekliliktir; zaman aşımları, yeniden denemeler ve circuit breaker'lar bunu destekler.
18Hexagonal ArchitectureAltıgen Mimari
Hexagonal architecture, çekirdek iş mantığının dış dünyayla yalnızca portlar ve değiştirilebilir adaptörlerle konuştuğu bir yazılım yapılandırma yöntemidir.
  • İş mantığı merkezde durur ve framework'ler ile veritabanları hakkında hiçbir şey bilmez.
  • Portlar çekirdeğin tanımladığı arayüzlerdir; adaptörler bunları belirli teknolojiler için uygular.
  • Tüm bağımlılıklar içeriye, çekirdeğe doğru işaret eder.
19İlgilerin Ayrılması
İlgilerin ayrılması, bir programı her biri davranışının açıkça tanımlanmış tek bir yönünden sorumlu ayrı parçalara bölen bir tasarım ilkesidir.
  • Bir programın her parçası tek bir ilgiyi, yani sorumluluğu yönetmelidir.
  • Kodu anlamayı, test etmeyi, değiştirmeyi ve yeniden kullanmayı kolaylaştırır.
  • Her düzeyde geçerlidir: fonksiyonlar, modüller, katmanlar ve servisler.
20İstemci-Sunucu Mimarisi
İstemci-sunucu mimarisi bir sistemi veri ya da işlem isteyen istemcilere ve bunları sağlayan sunuculara ayırır; tarayıcının sunucudan sayfa istemesi gibi.
  • İstemciler istek gönderir; sunucular işi yapar ve yanıt verir.
  • HTTP gibi protokoller nasıl haberleşeceklerini tanımlar.
  • Merkezî sunucular veriyi yetkili tutar ve güvenliği uygulanabilir kılar.
21Katmanlı Mimari
Katmanlı mimari, uygulamayı sunum, iş mantığı ve veri erişimi gibi yatay katmanlara böler ve her katman yalnızca altındaki katmanı çağırır.
  • Kod; sunum, iş mantığı ve veri erişimi gibi yatay katmanlara bölünür.
  • Her katman yalnızca altındaki katmana bağımlıdır.
  • Katmanlar sorumlulukları netleştirir ve parçaların bağımsız değişmesini sağlar.
22KISS İlkesiKeep It Simple, Stupid (Basit Tut)
KISS ilkesi, sistemlerin olabildiğince basit tutulduğunda en iyi çalıştığını, gereksiz karmaşıklıktan kaçınılması gerektiğini söyleyen tasarım yönergesidir.
  • KISS, keep it simple, stupid ifadesinin kısaltmasıdır.
  • Gerçek gereksinimleri karşılayan en doğrudan çözümü tercih edin.
  • Okunabilir kod zekice koddan iyidir ve daha az hareketli parça daha az arıza demektir.
23Konsensüs Algoritması
Konsensüs algoritması, bir grup makinenin, bazıları çökse ya da mesajlar kaybolsa bile tek bir değerde ya da sıralı bir karar kaydında anlaşmasını sağlar.
  • Konsensüs, makinelerin arızalara rağmen değerlerde ya da sıralı bir kayıtta anlaşmasını sağlar.
  • Raft ve Paxos en bilinen algoritmalardır; Raft'ı uygulamak daha kolaydır.
  • Bir lider girişler önerir; bunlar çoğunluk sakladığında kesinleşir.
24Mikroservisler
Mikroservisler, bir uygulamanın ağ üzerinden iletişim kuran, küçük ve bağımsız olarak dağıtılabilen servislere bölündüğü bir mimari tarzdır.
  • Her mikroservis tek bir iş yeteneğini yönetir ve bağımsız olarak dağıtılır.
  • Servisler ağ üzerinden API'ler ya da mesajlarla iletişim kurar.
  • Her servis genellikle kendi verisine sahiptir.
25Monolit
Monolit, tek parça olarak derlenip dağıtılan, tüm özelliklerin tek kod tabanını, tek süreci ve çoğunlukla tek veritabanını paylaştığı yazılım uygulamasıdır.
  • Monolit, tek parça olarak derlenir, dağıtılır ve ölçeklenir.
  • Özellikle başlangıçta geliştirmesi, test edilmesi ve dağıtılması basittir.
  • Büyük ve kötü yapılandırılmış monolitlerin değiştirilmesi zorlaşabilir.
26MVCModel–View–Controller (Model–Görünüm–Denetleyici)
MVC, uygulamayı veri ve mantık için Model, gösterim için View ve kullanıcı girdisini yöneten Controller olmak üzere üçe ayıran bir mimari desendir.
  • Model: veri ve iş mantığı.
  • View: kullanıcının gördüğü şey.
  • Controller: girdiyi işler, model ile view'u birbirine bağlar.
27MVVMModel-View-ViewModel
MVVM (Model-View-ViewModel), ekranın durumunu ve eylemlerini ViewModel'in tuttuğu, View'in ona bağlandığı arayüz kalıbıdır; durum değişince arayüz de değişir.
  • MVVM bir ekranı Model, View ve ViewModel'e ayırır.
  • ViewModel, View'in ihtiyaç duyduğu durumu ve komutları sunar.
  • Veri bağlama, durum değiştiğinde View'i otomatik günceller.
28Observer Deseni
Observer deseni, subject adlı bir nesnenin durumu değiştiğinde abone listesini otomatik olarak bilgilendirdiği davranışsal bir tasarım desenidir.
  • Subject, durumu değiştiğinde kayıtlı tüm observer'larını bilgilendirir.
  • Observer'lar çalışma zamanında abone olup ayrılabilir.
  • Bir olayı tetikleyen kod ile ona tepki veren kodu birbirinden ayırır.
29Olay Güdümlü Mimari
Olay güdümlü mimari, servislerin bir siparişin verilmesi gibi olaylar üreterek ve bunlara tepki vererek iletişim kurduğu bir yazılım tasarım tarzıdır.
  • Bileşenler olay yayınlayıp tüketerek iletişim kurar.
  • Üreticiler hangi tüketicilerin var olduğunu bilmez; bu, servisleri gevşek bağlı tutar.
  • Bir olay aracısı ya da mesaj kuyruğu olayları saklar ve iletir.
30Ölçeklenebilirlik
Ölçeklenebilirlik, bir sistemin daha fazla kullanıcı ya da veri gibi artan iş yükünü, kaynak ekleyerek performansı düşmeden karşılayabilme yeteneğidir.
  • Ölçeklenebilirlik, kaynak ekleyerek daha fazla yükü karşılayabilme yeteneğidir.
  • Dikey ölçekleme (scaling up) tek makineye güç ekler ve kesin bir sınırı vardır.
  • Yatay ölçekleme (scaling out) daha fazla makine ekler ve genellikle durumsuz servisler gerektirir.
31Peer-to-PeerEşler Arası
Peer-to-peer (P2P, eşler arası), eşlerin merkezî sunucu olmadan doğrudan bağlanıp kaynak paylaştığı, her birinin hem istemci hem sunucu olduğu ağ tasarımıdır.
  • P2P'de eşler kaynakları doğrudan paylaşır, hem istemci hem sunucu gibi davranır.
  • Tek bir merkezî sunucunun aksine, daha fazla eş katıldıkça kapasite artar.
  • Keşif tracker'lar ya da dağıtık hash tabloları kullanır; NAT özel ele alınmalıdır.
32Refactoring
Refactoring, mevcut kodun dışarıdan görünen davranışını değiştirmeden daha temiz ve bakımı kolay hâle getirmek için yeniden yapılandırılması sürecidir.
  • Refactoring kodun davranışını değil, yapısını değiştirir.
  • Küçük adımlarla ilerleyin ve her adımdan sonra testleri çalıştırın.
  • Yaygın refactoring işlemleri arasında yeniden adlandırma, fonksiyon çıkarma ve tekrarı kaldırma bulunur.
33Repository Deseni
Repository deseni, veri erişimini koleksiyon benzeri bir arayüzün arkasına gizler; iş kodu nesnelerin nerede saklandığını bilmeden yükleyip kaydedebilir.
  • Repository, iş koduna nesneleri yüklemek ve kaydetmek için koleksiyon benzeri bir arayüz verir.
  • Metotları veritabanı terimleriyle değil, findOverdueInvoices gibi alan diliyle adlandırılır.
  • Üretim kodu bir veritabanı uygulaması kullanabilir, testler ise bellek içi bir uygulama.
34Saga Deseni
Saga deseni, birkaç servise yayılan bir işlemi yerel adımlar dizisi olarak çalıştırır ve bir adım başarısız olursa tamamlananları telafi eylemleriyle geri alır.
  • Saga, servisler arası bir işlemi bağımsız commit edilen yerel adımlara böler.
  • Bir adım başarısız olursa telafi edici işlemler önceki adımları ters sırayla geri alır.
  • Orkestrasyon merkezi bir koordinatör kullanır; koreografi servisler arasındaki olayları kullanır.
35Service DiscoveryServis Keşfi
Service discovery (servis keşfi), dağıtık bir sistemde servislerin, örnekler başlayıp durdukça değişen diğer servislerin güncel adreslerini bulma yoludur.
  • Service discovery, diğer servislerin güncel adreslerini bulur.
  • Consul ya da etcd gibi bir kayıt defteri sağlıklı örnekleri adlarına göre izler.
  • İstemci tarafı keşif örneği çağıranda seçer; sunucu tarafı keşif bir yönlendirici kullanır.
36Servis Odaklı Mimari
Servis odaklı mimari, kurumsal yazılımı birbiriyle standart sözleşmelerle iletişim kuran, yeniden kullanılabilir ve ağdan erişilebilir servislerden kurar.
  • SOA, sistemleri sözleşmeler aracılığıyla ağ üzerinden iletişim kuran yeniden kullanılabilir servislerle kurar.
  • Klasik SOA, SOAP, WSDL ve merkezi bir kurumsal servis veri yolu kullandı.
  • Başlıca hedefleri kurum genelinde yeniden kullanım ve mevcut sistemlerin entegrasyonudur.
37Sidecar Deseni
Sidecar deseni, bir uygulamanın yanında yaşam döngüsünü ve ağını paylaşan yardımcı bir süreç çalıştırarak loglama, proxy ya da güvenlik gibi özellikler ekler.
  • Sidecar, bir uygulamanın yanına dağıtılan ve onun yaşam döngüsünü paylaşan yardımcı bir süreçtir.
  • Uygulamayı değiştirmeden loglama ya da proxy gibi destekleyici özellikler ekler.
  • Kubernetes'te sidecar aynı pod içindeki başka bir konteynerdir.
38Singleton Deseni
Singleton deseni, bir sınıfın yalnızca tek bir örneğinin bulunmasını sağlayan ve ona tek, küresel bir erişim noktası sunan oluşturucu bir tasarım desenidir.
  • Singleton sınıfın küresel bir erişim noktasıyla tam olarak bir örneği vardır.
  • Genellikle private bir constructor ve statik getInstance() metoduyla kurulur.
  • JavaScript'te bir modülden dışa aktarılan nesne singleton gibi davranır.
39SOLIDTek Sorumluluk, Açık–Kapalı, Liskov Yerine Geçme, Arayüz Ayrımı, Bağımlılığın Tersine Çevrilmesi
SOLID, geliştiricilerin daha anlaşılır, genişletilebilir, test edilebilir ve bakımı kolay kod yazmasına yardım eden beş nesne yönelimli tasarım ilkesidir.
  • S: Tek Sorumluluk, değişmek için tek bir neden.
  • O: Açık–Kapalı, mevcut kodu düzenlemeden davranışı genişletmek.
  • L: Liskov Yerine Geçme, alt sınıflar üst sınıflarının yerine güvenle geçebilmeli.
40Strangler Fig Deseni
Strangler fig deseni, eski bir sistemi özellikleri tek tek yeni koda yönlendirerek, eski sistem kapatılana kadar adım adım değiştirme yöntemidir.
  • Eski bir sistemi tek seferde yeniden yazmak yerine özellik özellik kademeli olarak değiştirin.
  • Bir proxy ya da API gateway gibi yönlendirme katmanı, her isteği hangi sistemin karşılayacağına karar verir.
  • Taşınan her parça değeri erken sunar ve kendi başına geri alınabilir.
41Strategy Deseni
Strategy deseni, değiştirilebilir algoritmaları tek arayüzün arkasına koyup çalışma zamanında aralarında geçiş yapılmasını sağlayan davranışsal bir desendir.
  • Strategy deseni, birbirinin yerine kullanılabilen algoritmaları ortak bir arayüzün arkasına koyar.
  • Context, hangi somut stratejiye sahip olduğunu bilmeden onu kullanır.
  • Uzun koşullu blokların yerini alır ve yeni seçenekleri eklemeyi kolaylaştırır.
42Tasarım Deseni
Tasarım deseni, yazılım tasarımında sık görülen bir soruna kanıtlanmış, yeniden kullanılabilir çözümdür; hazır kod değil, genel bir şablon olarak anlatılır.
  • Tasarım deseni, hazır kod değil, yeniden kullanılabilir bir çözüm şablonudur.
  • Klasik desenler oluşturucu, yapısal ya da davranışsal olarak gruplanır.
  • Desen adları geliştiricilere ortak bir söz dağarcığı sağlar.
43Teknik Borç
Teknik borç, daha uzun sürecek daha iyi bir yaklaşım yerine şimdi hızlı ya da sınırlı bir çözüm seçilmesiyle doğan, gelecekteki ek iş maliyetidir.
  • Teknik borç, bugün alınan kestirmelerin gelecekteki maliyetidir.
  • Faizi, gelecekteki her değişikliğin gerektirdiği ek çabadır.
  • Bilinçli ve takip edilen borç makul bir ödün olabilir.
44Twelve-Factor AppOn İki Faktörlü Uygulama
Twelve-factor app, bulutta taşınabilir, dağıtımı kolay ve ölçeklenmesi basit olması için on iki pratiğe göre geliştirilmiş bir web uygulamasıdır.
  • Twelve-factor, taşınabilir ve buluta hazır web uygulamaları geliştirmek için bir metodolojidir.
  • Yapılandırma kodda değil, ortamda bulunur.
  • Süreçler durumsuzdur; kalıcı veri veritabanı gibi backing service'lerde yaşar.
45Uyum
Uyum, bir modül, sınıf ya da servis içindeki sorumlulukların birbirine ne kadar ait olduğunun ölçüsüdür ve yüksek uyum iyi tasarımın işaretidir.
  • Uyum, bir modülün içeriğinin birbirine ne kadar ait olduğunu ölçer.
  • Yüksek uyum tek net sorumluluk demektir; düşük uyum karmakarışık bir yığındır.
  • Tek sorumluluk ilkesi yüksek uyuma ulaşmanın bir kuralıdır.
46YAGNIYou Aren't Gonna Need It (Buna İhtiyacın Olmayacak)
YAGNI, ileride gerekebilir diye değil, gerçekten ihtiyaç duyulana kadar bir özellik ya da soyutlama inşa etmemeyi söyleyen bir extreme programming ilkesidir.
  • YAGNI, you aren't gonna need it ifadesinin kısaltmasıdır.
  • Özellikleri ve soyutlamaları hayal edildiğinde değil, gerektiğinde inşa edin.
  • Spekülatif kod şimdi zaman, sonra bakım maliyeti getirir ve çoğunlukla yanlış tahmin eder.
47Yatay Ölçekleme
Yatay ölçekleme (scale out), bir sistemin kapasitesini tek bir makineyi büyütmek yerine daha fazla makine ekleyip işi onlara dağıtarak artırır.
  • Yatay ölçekleme daha fazla makine ekler ve yükü dağıtır.
  • Bir yük dengeleyici ve otomatik ölçekleme trafiği örneklere dağıtır.
  • Neredeyse sınırsız büyüme, hata toleransı ve kademeli güncellemeler getirir.
48Yüksek Erişilebilirlik
Yüksek erişilebilirlik, bir sistemin, çoğunlukla yedeklilikle tek hata noktalarını ortadan kaldırarak neredeyse her zaman çalışır durumda kalabilmesidir.
  • Yüksek erişilebilirlik, bir sistemin çok yüksek bir zaman yüzdesinde çalışır kalması demektir.
  • Erişilebilirlik çoğunlukla %99,9 ya da %99,99 gibi dokuzlarla ifade edilir.
  • Yedeklilik, yük dengeleme, çoğaltma, sağlık kontrolleri ve failover tek hata noktalarını ortadan kaldırır.
Software Dictionary'den 48 terim. Ayrıntılı açıklamalar, örnekler ve sık sorulan sorular için: softwaredictionary.org/tr/kutuphane/architecture

Kitaba dönİpucu: Bir kopyasını saklamak için yazdırma penceresinde “PDF olarak kaydet”i seçin.

Daha fazla

Ayarlar