04 Ara 2025·8 dk
Butler Lampson ve Xerox PARC: Ölçekli Sistemler İçin Dersler
Butler Lampson’un Xerox PARC fikirlerinin (ağ, işletim sistemi yapısı, adlandırma, önbellekleme, RPC) pratik rehberi ve neden ölçekli sistemleri hâlâ şekillendirdikleri.
Butler Lampson’un Xerox PARC fikirlerinin (ağ, işletim sistemi yapısı, adlandırma, önbellekleme, RPC) pratik rehberi ve neden ölçekli sistemleri hâlâ şekillendirdikleri.
Butler Lampson son yarım yüzyılın en etkili bilgisayar sistem tasarımcılarından biriydi. 1970'ler ve 80'lerde Xerox PARC'ta, ağlı bilgisayarların nasıl davranması gerektiğini—izole makineler olarak değil, programların, dosyaların, yazıcıların ve insanların güvenilir şekilde etkileştiği paylaşılan bir ortamın parçaları olarak—şekillendirmeye yardımcı oldu.
Lampson’un çalışmasının olağanüstü dayanıklı olmasının nedeni temel meselelere odaklanmasıydı: ölçeklenen arayüzler, birleştirilebilen mekanizmalar ve gerçek dünya hatalarını istisna olarak değil varsayan sistemler.
“Ölçek” sadece devasa bir veri merkeziye sahip olmak demek değildir. Systeminizde birçok kullanıcı, birçok makine ve gerçek dünya düzensizliği olduğunda olanlardır. Düşünün: yüzlerce dizüstü ve servislerin aynı girişler ve dosyaları paylaştığı bir ofis; aynı anda binlerce müşterinin kullandığı bir ürün; ya da bir sunucu düştüğünde, ağ bağlantısı yavaşladığında veya bir güncelleme kusurlu yayıldığında bile çalışmaya devam etmesi gereken bir şirket uygulaması.
Bu noktada zor problemler değişir. Artık “Bilgisayarımda çalışıyor mu?” sorusunu sormayı bırakırsınız ve şunları sormaya başlarsınız:
Bu, trivia ya da nostalji turu değil. Lampson’un çalışması faydalı çünkü dayanan tasarım fikirleri üretti: temiz arayüzler, basit yapı taşları ve hatayı göz önünde bulundurarak inşa edilmiş sistemler.
Ağın, RPC'nin, adlandırmanın, önbelleklemenin ve pratik güvenliğin modern işletim sistemleri ve dağıtık hesaplama üzerindeki taşıyıcı kavramlarına odaklanacağız—böylece bu desenleri bugünün mimarilerinde tanıyıp kendi servislerinize uygulayabilirsiniz.
Her kişinin masasında güçlü bir kişisel bilgisayar, paylaşılan servislerle bağlı ve tüm işyerinin tek bir tutarlı sistem gibi hissettirdiği bir ofisi hayal edin. Xerox PARC'ın bahsi buydu: sadece “bir bilgisayar” değil, hesaplama, belgeler ve iletişimin insanlar ve makineler arasında kolayca aktığı ağlı bir ortam.
PARC, kişisel hesaplamayı günlük iş için pratik hale getirmeyi amaçladı—yazma, tasarlama, dosya paylaşma, taslak yazdırma ve işbirliği—bir ana bilgisayar operatörü veya özel ritüellere ihtiyaç duymadan. Amaç tek bir çığır açan cihaz değil; gün boyu içinde yaşayabileceğiniz bir çalışma düzeniydi.
Alto “kişisel” parçaydı: etkileşimli çalışma için tasarlanmış bir bilgisayar. Ethernet “işyeri” parçasıydı: Altoların birbirleriyle ve paylaşılan kaynaklarla konuşmasını sağlayan hızlı bir yerel ağ.
Bu paylaşılan kaynaklar isteğe bağlı ekstra değil, temel öğelerdi:
Bu birleşim yeni bir zihniyeti teşvik etti: bilgisayarınız kendi başına güçlüdür, ama ağ servislerini güvenilir şekilde kullanabildiğinde çok daha faydalı olur.
PARC prototiplerde veya izole gösterilerde takılmadı. Tam sistemler—donanım, işletim sistemleri, ağ ve uygulamalar—kurup insanların gerçekten nasıl çalıştığından öğrendiler.
Bu geri besleme döngüsü sadece pratikte ortaya çıkan zor problemlere ışık tuttu: nesneleri adlandırma, aşırı yükle başa çıkma, hatalarla uğraşma, performansı öngörülebilir tutma ve paylaşılan kaynakları “uzak” değil “yakın” hissettirme.
Birçok PARC sistemi tanınabilir bir yaklaşımı yansıtır: basit ilkelere güçlü mühendislik disiplini eşlik eder. Arayüzleri küçük ve anlaşılır tutun, servisleri temizce bileşenleştirin ve fikirleri gerçek dağıtımlarda test edin. Bu stil, derslerin modern takımlara aktarılmasının büyük bir sebebidir.
Xerox Alto sadece “masada bir bilgisayar” değildi. Kişisel bir makine, yüksek kaliteli grafik arayüzü ve sizi paylaşılan kaynaklara bağlayan hızlı bir yerel ağı tek bir günlük deneyimde birleştirmesiyle dönüm noktasıydı.
Bu birleşim beklentileri sessizce yeniden yapılandırdı. Bilgisayarınız size aitmiş gibi hissettiriyordu—tepkisel, etkileşimli ve her zaman kullanılabilir—ama aynı zamanda paylaşılan dosya sunucuları, yazıcılar ve işbirliği araçlarına açılan bir kapı gibi hissediliyordu. Bu, istemci/sunucu zihniyetinin tohumu.
Alto tarzı sistemlerden önce hesaplama sık sık makineye (veya bir terminale) gitmeyi gerektiriyordu. Alto bunu tersine çevirdi: “istemci” kullanıcıyla birlikte yaşadı ve ağ güçlü paylaşılan yetenekleri yakın hissettirdi.
Pratikte, “istemci/sunucu” bir diyagram değildi—bir iş akışıydı. Bazı işler anlık geri bildirim gerektirdiği için yereldeydi: metin düzenleme, çizim, pencerelerle etkileşim. Diğer işler paylaşıma doğal olduğundan veya her masada çoğaltmak pahalı olduğu için uzaktaydı: yetkili belgelerin saklanması, yazıcıların yönetimi, erişim koordinasyonu ve daha sonra paylaşılan servislerin çalıştırılması.
“Alto”yu “dizüstü” ve “dosya/yazıcı sunucusu”nu “bulut servisleri” ile değiştirirseniz, zihniyet tanıdıktır. Cihazınız hâlâ istemcidir: UI'yi render eder, verileri önbelleğe alır ve düşük gecikmeli etkileşimleri işler. Bulut hâlâ sunucu tarafıdır: paylaşılan durum, işbirliği, merkezi politika ve elastik hesaplama sağlar.
Ders şudur: iyi sistemler bu bölünmeyi kabul eder, ona karşı durmaz. Kullanıcılar yerel tepkisellik ve çevrimdışı tolerans ister; organizasyonlar ise paylaşılan gerçeği ve koordine erişimi ister.
Bu ayrım işletim sistemi ve sistem tasarımcıları için sürekli bir gerilim yaratır:
PARC dönemi çalışmaları bu gerilimi erken görünür kıldı. Ağı bilgisayarın bir parçası olarak varsaydığınızda, “yerel” ile “uzak”ın bir sistem gibi hissetmesi için arayüzleri, önbellekleme ve hata davranışını tasarlamak zorunda kalırsınız—ama aynı olmadıklarını iddia etmeden.
Ethernet “sadece ağ” gibi göründüğü için göz ardı edilmesi kolaydır. Xerox PARC'ta, kişisel makinelerle dolu bir odanın paylaşılan bir sistem gibi davranmasını sağlayan pratik kırılmaydı.
Ethernet'ten önce bilgisayarları bağlamak genellikle pahalı, özel bağlantılar gerektiriyordu. Ethernet ekonomiyi değiştirdi: birçok makinenin aynı anda bağlanabileceği nispeten ucuz, paylaşılan bir ortam.
Bu varsayılanı “bir büyük bilgisayar”dan “birbirleriyle işbirliği yapan birçok küçük bilgisayar”a kaydırdı, çünkü işbirliği artık kahramanca altyapı gerektirmiyordu.
Aynı zamanda Ethernet’in paylaşılan doğası yeni bir sistem tasarımını teşvik etti: servisler farklı makinelerde yaşayabilir, yazıcılar ve dosya sunucuları ağa eklenebilir ve ekipler bağlantı nadir olmadığından hızla yineleyebilirdi.
Bugün ağı, bir işletim sisteminin belleğe veya depolamaya davrandığı şekilde ele alıyoruz: eklenti değil, platformun bir parçası. Uygulamanızın “yerel” davranışı sık sık uzak çağrılara, uzak verilere, uzak kimliğe ve uzak yapılandırmaya bağlıdır.
Bunu kabul ettiğinizde, ağ nazikçe yolunuzdan çekilecekmiş gibi tasarlamayı bırakırsınız.
Paylaşılan bir ağ rekabet anlamına gelir. Paketler gecikebilir, düşebilir veya yeniden sıralanabilir. Eşler yeniden başlatılabilir. Anahtarlar aşırı yüklenebilir. Hiçbir şey “bozulmamış” olsa bile sistem bozuk hissedebilir.
Doğru tavır, kusurlu koşullar altında normal operasyon için inşa etmektir:
Ethernet dağıtık hesaplamayı mümkün kıldı; aynı zamanda dağıtık hesaplamanın gerektirdiği disiplini zorunlu kıldı.
Xerox PARC'ta bir “servis”, ağ üzerindeki başkaları için tek işi yapan bir bilgisayar programıydı.
Bir dosya servisi belgeleri sakladı ve geri döndürdü. Bir yazıcı servisi belge kabul edip kağıt çıktı üretti. Bir dizin (veya adlandırma) servisi doğru dosya sunucusunu, yazıcıyı veya kişiyi makine detaylarını ezberlemeden bulmanıza yardımcı oldu. Her servis açık bir amaca, tanımlı bir arayüze ve ona bağımlı kullanıcılara (insanlar veya diğer programlar) sahipti.
Büyük bir sistemi daha küçük servislere ayırmak değişimi daha güvenli ve hızlı yaptı. Yazdırma sistemi yeni özelliklere ihtiyaç duyduğunda dosya depolamayı yeniden tasarlamak zorunda kalmazdı. Sınırlar sorumlulukları da netleştirdi: “dosyalar buradadır” ile “yazdırma burada olur” ayrıldı.
Aynı derecede önemli olarak, servisler önce arayüz tasarlama alışkanlığını teşvik etti. Programınız başka bir makineyle konuşmak zorunda kaldığında, girişleri, çıktıları ve hataları belirtmek zorunda kalırsınız—tek parçalı monolit içinde çoğu zaman belirsiz kalan detaylar.
Daha fazla servis daha fazla ağ isteği demektir. Bu gecikmeyi artırabilir, yükü çoğaltabilir ve yeni hata modları yaratabilir: dosya servisi up iken yazdırma servisi down olabilir veya dizin servisi yavaşlayabilir.
Bir monolit “hepsi birden” çöker; dağıtık servisler kısmi, kafa karıştırıcı şekillerde başarısız olur. Çözüm servislerden kaçınmak değil—kısmi hatalar için açık tasarım yapmaktır.
Birçok bulut uygulaması artık iç servisler olarak çalışır: kullanıcı hesapları, faturalama, arama, bildirimler. PARC dersi hâlâ geçerli: açıklık ve bağımsız evrim için bölün—ancak ağ gecikmeleri ve kısmi arızalar için baştan plan yapın.
Pratik rehberlik için ekipler genellikle servis sınırlarını temel zaman aşımları, retry'ler ve net hata mesajları ile eşleştirir (bkz. /blog/failure-is-normal).
Remote Procedure Call (RPC) basit ama büyük kazançlı bir fikirdir: başka bir makinede bir fonksiyonu sanki yerelmiş gibi çağırmak. İsteği elle paketleyip ağı gönderip yanıtı açmak yerine, RPC bir programın “getUser(42) çalıştır” demesini sağlar ve sistem mesajlaşmayı arka planda halleder.
Bu “yerel hissettirme” hedefi Xerox PARC'ın dağıtık hesaplama çalışmalarının merkezindeydi—ve bugün ekiplerin hala istediği şey: net arayüzler, öngörülebilir davranış ve uygulama koduna daha az hareketli parça açığa çıkarmak.
Tehlike, RPC'nin normal bir fonksiyon çağrısına fazla benzemesidir. Yerel bir çağrı ya çalışır ya da sürecinizi çökertebilir; ağ çağrısı yavaş olabilir, kaybolabilir, kısmen tamamlanabilir veya başarılı olup haber alamayabilirsiniz. İyi RPC tasarımları eksik gerçekleri gömüleştirir:
Zaman aşımı ve düşen yanıtlar retry'leri kaçınılmaz kılar. Bu yüzden idempotentlik önemlidir: bir işlemi bir kez veya birden fazla kez yapmak aynı etkiye sahipse idempotenttir.
Basit bir örnek: chargeCreditCard(orderId, amount) varsayılan olarak idempotent değildir—zaman aşımından sonra yeniden denemek iki kez tahsilata yol açabilir. Daha güvenli bir tasarım, chargeCreditCard(orderId) şeklinde orderIdnin tahsili benzersiz tanımlaması ve sunucunun tekrarları “zaten yapıldı” olarak işlemesiyle olur. Yani retry güvenli hale gelir çünkü sunucu çoğaltmaları ayırt edebilir.
Modern API'ler RPC zihniyetinin doğrudan torunlarıdır. gRPC uzak yöntem çağırma modelini tipli mesajlar ve tanımlı arayüzlerle açık hale getirir. REST genellikle yöntem odaklı olmaktan ziyade kaynak odaklı görünse de amaç benzer: servislerin konuşma şeklini standardize etmek, sözleşmeleri tanımlamak ve hatayı yönetmektir.
Tarz ne olursa olsun, PARC dersi geçerlidir: ağ bir araçtır, göz ardı edilecek bir detay değil. İyi RPC dağıtımı kolaylaştırır—ücretsizmiş gibi davranmadan.
Dağıtık bir sistem sadece “dağıtık” hissedildiğinde kırılır. Çoğu gün sistem, bir şeyi bulamıyor diye bozuk hisseder.
Adlandırma zordur çünkü gerçek dünya sabit kalmaz: makineler değiştirilir, servisler yeni hostlara taşınır, ağlar yeniden numaralandırılır ve insanlar hâlâ “dosya sunucusu” veya “LaserWriter'a yazdır” gibi hatırlanabilir yollar bekler. Eğer yazdığınız isim aynı zamanda konumsa, her değişiklik kullanıcıya görünür bir kesinti olur.
PARC döneminden gelen ana fikir, istediğiniz şey ile şu anda nerede bulunduğunu ayırmaktır. Bir isim sabit ve anlamlı olmalı; bir konum ise değişebilen uygulama ayrıntısıdır.
Bu ikisi birleştiğinde kırılgan sistemler oluşur: kestirme yollar, hard-coded IP'ler ve konfigürasyon sürüklenmesi.
Dizin servisleri “X şimdi nerede?” sorusunu isimleri konumlara haritalayarak (ve genellikle tür, sahibi veya erişim kuralları gibi meta verileriyle) yanıtlar. En iyi dizinler sadece arama sonuçlarını saklamaz—bir organizasyonun nasıl çalıştığını kodlar.
İyi adlandırma ve dizin tasarımları genellikle şu pratik özellikleri paylaşır:
DNS klasik örnektir: insan dostu bir isim, TTL kontrolü ile değişen IP kümesine bağlanır. Şirket içi servis keşif sistemleri (“service-a.prod”ı destekleyenler gibi) aynı deseni tekrarlar: sabit servis isimleri, değişen örnekler ve önbellek performansı ile güncelleme hızı arasında sürekli gerilim.
Ders basittir: eğer ölçeklenen ve anlaşılır kalan sistemler istiyorsanız, adlandırmayı sonradan eklenen bir detay değil, birinci sınıf tasarım problemi olarak ele alın.
Önbellekleme basit bir fikirdir: bir şeyi bir kez alıp yakında bir kopyasını tutarsınız ki bir sonraki istek daha hızlı olsun. Her seferinde ağı dolaşmak (veya yavaş bir diske/sunucuya gitmek) yerine yerel kopyayı yeniden kullanırsınız.
Xerox PARC'ta bu önem taşıdı çünkü ağlı iş istasyonları ve paylaşılan servisler “tekrar sunucuya sor” alışkanlığını pahalı kılıyordu. Önbellekleme uzaktaki kaynakları çoğu zaman hızlıymış gibi hissettirdi.
Yakalanan sorun tazelik. Bir önbellek yanlış olabilir.
Paylaşılan bir belgeyi hayal edin: çalıştığınız istasyon belgeyi açmak için önbelleğe alır. Bir meslektaşınız aynı belgeyi düzenleyip kaydederse, önbelleğiniz habersiz kalırsa eski içeriği görmeye devam edebilirsiniz—ya da daha kötüsü, bayat bir kopyayı düzenleyip yeni çalışmayı üzerine yazabilirsiniz.
Dolayısıyla her önbellekleme tasarımı bir takas:
Ekipler genellikle bu takası birkaç geniş araçla yönetir:
Modern sistemlerde aynı desen her yerde: CDN'ler web içeriğini kullanıcılara yakın önbellekler, tarayıcılar ve mobil uygulamalar varlıkları ve API yanıtlarını önbelleğe alır, ve veritabanı önbellek katmanları (Redis veya Memcached gibi) birincil depolardaki yükü azaltır.
Ders halen geçerli: önbellekleme genellikle en ucuz performans kazancıdır—ama ürününüz için “yeterince taze”nin ne olduğunu açıkça belirlemediğiniz sürece işe yaramaz.
Ölçekli güvenlik sadece “sen kimsin?” sorusu değildir—aynı zamanda “şimdi bu belirli kaynakla ne yapmana izin var?” sorusudur. Lampson ve Xerox PARC geleneği bunun için çok pratik bir fikri öne sürdü: capabilities (yetenekler/jetonlar).
Bir capability erişim veren kırılamaz bir jetondur—bir dosya, yazıcı, posta kutusu veya servis işlemi gibi bir şeye erişim hakkı verir. Jetona sahipseniz izin verilen işlemi yapabilirsiniz; yoksa yapamazsınız.
Anahtar nokta kırılamaz olmasıdır: sistem geçerli bir jetonu tahmin ederek üretmeyi hesaplama veya yapı olarak imkansız kılar.
Bunu bir otel anahtarı kartına benzetin: sadece odanızı (ve yalnızca konaklamanız boyunca) açar, el yazısıyla yazılmış “girebilirsin” notu gibi değil.
Birçok sistem kimlik tabanlı güvenliğe dayanır: kullanıcı olarak kimliğinizi doğrularsınız ve her erişim kaynak üzerindeki bir ACL (Erişim Kontrol Listesi) ile kontrol edilir—hangi kullanıcı/grup ne yapabilir listesi.
ACL'ler sezgiseldir ama dağıtık sistemlerde hantallaşabilir:
Capabilities varsayılanı tersine çevirir. Merkezi bir otoriteye tekrar tekrar sormak yerine, zaten hakkı kodlayan bir jeton sunarsınız.
Dağıtık sistemler işi makineler arasında sürekli geçirir: bir ön uç bir arka uca çağırır; bir zamanlayıcı bir işi bir çalışana verir; bir servis başka bir servisi tetikler. Her adımda yeteri kadar izni taşımak gerekir.
Capabilities bunu doğal hale getirir: bir istekle birlikte bir jeton geçirirsiniz ve alan makine onu doğrulayabilir—her seferinde güveni yeniden icat etmek zorunda kalmaz.
İyi yapıldığında bu kazara aşırı izin vermeyi azaltır ve bir şey ters gittiğinde zarar alanı sınırlar.
Capabilities şu formlarda görünür:
Ders basittir: izinleri devretme, kapsam ve sona erme etrafında tasarlayın; sadece uzun ömürlü kimlikler etrafında değil.
Dağıtık sistemler tek, temiz bir şekilde “bozulmaz.” Dağıtık, dağınık şekilde başarısız olur: bir makine işin ortasında çöker, bir anahtar yeniden başlatılır, bir ağ bağlantısı paketleri düşürür veya bir güç olayı bir rafı etkiler ama diğerlerini etkilemez.
Kullanıcı perspektifinden hizmet “ayakta”dır, ama bir kısmı erişilemez.
Pratik bir hata modeli serttir:
Bunu kabul ettiğinizde hataları “köşe durumu” olarak değil normal kontrol akışı olarak işlemeye başlarsınız.
Çoğu sistem küçük bir hareket setine dayanır.
Zaman aşımları çağıranların sonsuza dek beklemesini engeller. Anahtar, zaman aşımlarını gerçek gecikme verilerine göre seçmektir, tahmine göre değil.
Retry'ler geçici hatalardan kurtarabilir ama bir kesinti sırasında yükü de çoğaltabilir. Bu yüzden üstel backoff (her retry arasında biraz daha uzun bekleme) ve jitter (rastgelelik) önemlidir: senkronize retry fırtınalarını önler.
Failover (yedek örneğe geçiş) bir bileşen gerçekten down olduğunda yardımcı olur, ama yalnızca sistem arızayı güvenli ve hızlı şekilde algılayabiliyorsa işe yarar.
Bir isteği yeniden denerseniz, onu birden fazla kez çalıştırabilirsiniz. Buna en az bir kere teslim denir: sistem işi bırakmamak için çok çabalar, ama çoğaltmalar olabilir.
Tam olarak bir kere işlemin yalnızca bir defa gerçekleştiği sözü verir. Ağ bölünmeleri gibi durumlarda bunu sağlamak zordur.
Birçok ekip bunun yerine işlemleri idempotent yapar (tekrar edilmesi güvenli), böylece en az bir kere teslim kabul edilebilir olur.
En güvenilir ekipler staging'de (ve bazen üretimde) hatalar enjekte eder ve ne olduğunu izler: örnekleri öldürür, ağ yollarını bloklar, bağımlılıkları yavaşlatır ve alarmları, retry'leri ve kullanıcı etkisini doğrular.
Kesintileri tasarımınızı iyileştiren deneyler olarak görün, olmaması gereken sürprizler değil.
İşletim sistemleri köpeğin yıllarında yaşar: her yeni özellik etkileşimlerin sayısını katlar ve bu da hataların saklandığı yerdir.
Lampson’ın okulu—Xerox PARC'ta şekillenen—işletim sistemi yapısını bir ölçeklendirme stratejisi olarak ele alır. Çekirdek dağınıksa, üstüne inşa edilen her şey o dağınıklığı miras alır.
Tekrarlayan PARC dersi çekirdek (veya “güvenilen çekirdek”) dar ve basit, bileşenlendirilebilir ilkelere sahip olmalıdır. Onlarca özel durumu çekirdeğe gömmek yerine, açıklaması kolay ve yanlış kullanılması zor birkaç mekanizma tanımlayın.
Sınırlar açık olduğunda—bir bileşen ne vaat ediyor, ne varsayabiliyor—implementasyonları değiştirebilir, parçaları izole test edebilir ve istemeden bağımlılığı önleyebilirsiniz.
İzolasyon zararın yayılma alanını sınırlar. Bellek koruması, süreç ayrımı veya kaynaklara en az ayrıcalıklı erişim olsun, izolasyon “her yerdeki bir hata her şeyi kırar” yerine “hata sınırlıdır” yapar.
Bu düşünce aynı zamanda capability benzeri tasarımlara yönlendirir: koda yalnızca ihtiyaç duyduğu yetkiyi verin ve erişimi zımni bırakmayın.
Pragmatizm performansta da kendini gösterir: yaygın işlemler için hızlı yollar oluşturun ve güvenlik veya açıklık getirmeyen yüklerden kaçının.
Amaç her şeyi mikro-optimize etmek değil—sık görülen durumun hızlı hissettirilmesi, doğruluğu korurken.
Aynı fikirleri bugün kernel'larda, dil çalışma zamanlarında ve konteyner platformlarında görebilirsiniz: küçük güvenilen taban, iyi tanımlanmış API'ler ve ekiplerin hızlı göndermesini sağlayıp hata modlarını paylaşmamasına izin veren izolasyon sınırları (süreçler, sandboxlar, namespace'ler).
Ayrıntılar değişti; tasarım alışkanlıkları hâlâ kazançlı.
PARC'ın büyük başarısı tek bir icat değil—insanların gerçekten kullanabileceği ağlı sistemler inşa etme konusunda tutarlı bir yoldu. İsimler değişti ama temel problemler (gecikme, hatalar, güven, sahiplik) değişmedi.
Tasarımı gözden geçirirken yardımcı olacak kısa bir “zihin sözlüğü”:
Bir sistemi ölçek açısından değerlendirirken kullanın:
Modern bir büküm, ekiplerin dağıtık mimarileri ne kadar hızlı prototipleyebildiğidir. Koder.ai gibi araçlar (sohbetten kod üreten platformlar), “ilk çalışan sistem” fazını hızlandırabilir—ön yüzde React, arka uçta Go + PostgreSQL ve mobilde Flutter—ve yine de kaynak kodunu dışa aktararak ciddi üretim kod tabanına dönüştürebilirsiniz.
Yine de Lampson döneminin dersi geçerlidir: hız kazançlıdır ama arayüzleri net tutmuyorsanız, hata davranışını (zaman aşımları, retry'ler, idempotentlik) açıkça belirtmiyorsanız ve adlandırma, önbellekleme, izinleri birinci sınıf tasarım kararları olarak ele almıyorsanız, er ya da geç sorun çıkar.
Disiplini kopyalayın: basit arayüzler, açık sözleşmeler ve kısmi arızalar için tasarım. Mekanizmaları uyarlayın: bugün yönetilen keşif, API gateway'ler ve bulut IAM kullanacaksınız—özelleştirilmiş dizinlere ve el yapımı kimlik çözümlerine gerek yok.
Kaçının: aşırı merkezileştirme (herkesin bağımlı olduğu bir “tanrı servisi”) ve belirsiz sahiplik (sahibi olmayan paylaşılan bileşenler).
Araçlar değişecek—yeni çalışma zamanları, yeni bulutlar, yeni protokoller—ama kısıtlar aynı kalır: ağlar arızalanır, gecikme vardır ve sistemler yalnızca insanlar tarafından işletilebilir hale geldiğinde ölçeklenir.
Bu bağlamda “ölçek” çok sayıda kullanıcı, çok sayıda makine ve sürekli gerçek dünya karmaşıklığı varlığında çalışmak demektir. Zor noktalar, isteklerin birden fazla servise yayıldığı ve hataların kısmi olduğu durumlarda ortaya çıkar: bazı parçalar çalışır, diğerleri zaman aşımına uğrar ve sistem yine de öngörülebilir davranmak zorundadır.
PARC, bir tam ağ bağlantılı işyeri kurdu: Alto kişisel bilgisayarları, Ethernet üzerinden dosya ve yazıcı sunucuları gibi paylaşılan servislerle bağladı. Önemli ders, uçtan uca bir sistemi insanların günlük olarak kullandığında gerçek problemleri öğrenmenizdir—adlandırma, aşırı yük, önbellekleme, hatalar ve güvenlik kaçınılmaz hale gelir.
Bu, gecikmeye duyarlı etkileşimi yerelde (UI, düzenleme, render) tutmayı ve paylaşılan/otoriter durumu servislerde saklamayı savunan pratik bir ayrımı öne çıkardı. Tasarım hedefi, yerelde hızlı tepki ve ağ yavaş veya güvenilmezken tutarlı küresel davranış sağlamaktır.
Ağ bir birinci sınıf bağımlılık haline gelir; arka planda kalan bir detay değildir. Bir ortamda birçok makine paylaşıldığında ve servisler sık konuştuğunda, şunları varsaymanız gerekir:
Pratik varsayımlar: erkenden ölçümleyin, zaman aşımlarını kullanın ve retry'leri dikkatle (backoff ile) yapın.
Servislere bölünmek açıklık ve bağımsız evrim sağlar: her servis odaklanmış bir işe ve tanımlı bir arayüze sahiptir. Bedel, ağ üzerinde daha fazla çağrı ve kısmi hata modlarıdır; bu yüzden sözleşmeler, güvenilirlik, zaman aşımları ve retry mekaniklerine disiplin gerekir.
RPC uzak bir işlemi yerelmiş gibi çağırmanızı sağlar, fakat iyi bir RPC ağ gerçeklerini açık hale getirir. Pratikte gerekenler:
Bunlar yoksa RPC, “uzakmış gibi davranmayı unutan” kırılgan tasarımlara yol açar.
Timeoutlar ve kaybolan yanıtlar retry'leri kaçınılmaz kılar; retry'ler işi tekrileyebilir. Bunu güvenli hale getirmek için:
orderId)Ödemeler, provizyon veya bildirim gönderme gibi işlemler için bu hayati önemdedir.
Bir isim aynı zamanda bir konumsa (hard-coded host/IP/path), taşınma ve arızalar kullanıcıya görünür kesintiye dönüşür. Sabit isimleri ve değişen konumları ayırın; bir dizin veya keşif sistemi kullanarak istemcilerin “X şimdi nerede?” diye sormasını sağlayın ve önbelleklere net tazelik kuralları (TTL gibi) koyun.
Önbellekleme genellikle en ucuz performans kazancıdır, ama bayatlama riski getirir. Yaygın kontroller:
Her veri için “yeterince taze”nin ne anlama geldiğini açıkça yazmak, doğruluğu tesadüfen olmaktan çıkarır.
Bir yetki belirli bir kaynağa veya işleve erişim veren kırılamaz bir jetondur. Kimlik+ACL modeline kıyasla yetenekler (capabilities):
Güncel benzerleri: OAuth erişim token'ları, kapsamlara ayrılmış bulut kimlik bilgileri, imzalı URL/JWT tipi jetonlardır (dikkatle kullanıldığında).