Uygulamaları vatansız tutmak nasıl


97

Bu karmaşık bir soru olabilir, ama vatansızlığı daha iyi anlamaya çalışıyorum.

Okuduklarıma dayanarak, web uygulamaları vatansız olmalı, yani her bir istek bağımsız bir işlem olarak kabul edilir. Sonuç olarak, Oturum ve Çerezlerden kaçınılmalıdır (her ikisi de durumlu olduğu için). Daha iyi bir yaklaşım, sunucuda hiçbir şey depolanmadığı için durumsuz olan Simgeleri kullanmaktır.

Bu yüzden, anlamaya çalışıyorum, oturumum için tutulan veriler olduğunda web uygulamaları nasıl vatansız olabilir (bir alışveriş sepetindeki öğeler gibi)? Bunlar aslında bir veritabanında saklanıyor mu ve daha sonra periyodik olarak temizleniyor mu? Çerez yerine bir jeton kullanırken bu nasıl çalışır?

Ve sonra ilgili bir soru olarak, büyük web siteleri (Amazon, Google, Facebook, Twitter vb.) Vatansız mı? Jetonlar mı yoksa çerezler mi kullanıyorlar (veya her ikisi de)?


38
Son zamanlarda dikkatsizlik noktasına vatansızlık takıntısı olan geliştiricilerle görüştüm ve konuştum. Yeniden kullanılabilirlik için vatansızlık sahibi olmak güzel ancak bir amaç için ölçeklendirme gibi yapmak için bir ton kaynağınız olmadıkça, her durumda bu hedefe her durumda bu hedefe ulaşmak gerçekçi değil.
Mark Rogers,

4
@MarkRogers Neden? Vatansızlığın yeniden kullanılabilirlikle ilgisi yoktur. Ve vatansız olmak daha yüksek bir çabaya yol açmaz.
Paul Wasilewski

3
@ PaulWasilewski: Vatansız olmak daha fazla çaba sarf etmiyor. => yapar, durum bilgisi olan bir uygulama ile her şeyi bellekte oturuma bağlı tutar. Bu, oturumu sabitlemeyle çalışsa da iyi ölçeklenmez, ancak ÇOK basittir. Sunucuların birbirleri arasında bilgi alışverişine başlaması gerektiğinde, sorunlar başlar.
Matthieu M.

6
Amazon'a baktığımda, bilgisayarı değiştirseniz bile alışveriş sepetinizin kaldığını fark edeceksiniz, bu nedenle çerezde değil, veritabanında saklanır.
njzk2

20
Cevabımı okumak için bulamazsanız. İşte kısa versiyonu: Web istekleri doğal olarak vatansız. Web uygulamaları değil. (Bazı "vatansız ağ" dogmatistlerinin ne söylediği önemli değil!)
svidgen

Yanıtlar:


95

"web uygulamaları vatansız olmalı " , "devletin olması için çok iyi bir neden olmadığı sürece web uygulamaları vatansız olmalıdır" olarak anlaşılmalıdır . Bir "alışveriş sepeti", tasarım gereği oldukça belirgin bir özelliktir ve inkar etmek, bunun oldukça tersine üretken olduğudur. Alışveriş sepeti modelinin asıl amacı, başvurunun talepler arasındaki durumunu korumaktır.

Ben bir alternatif olabilir bir alışveriş sepeti tamamen istemci taraflı bir alışveriş sepeti tutan tek sayfalık uygulama olacağını uygulayan bir vatansız web sitesi olarak hayal AJAX çağrıları ile ürün bilgilerini alır ve ardından tek seferde zaman sunucuya gönderir kullanıcı bir ödeme yapar. Ancak, kullanıcının bunu yaptığını gördüğümden şüpheliyim, çünkü kullanıcının birden çok tarayıcı sekmesi kullanmasına izin vermiyor ve sekmeyi yanlışlıkla kapattıklarında durumu korumuyor. Tabii ki, localstorage kullanmak gibi geçici çözümler vardır, ancak sonra sunucuda değil sadece istemcide tekrar durumunuz olur.

Sayfa görünümleri arasında veri kalmasını gerektiren bir web uygulamanız olduğunda, genellikle bunu oturumları başlatarak yaparsınız. Bir isteğin ait olduğu oturum, bir çerez veya her bağlantıya eklediğiniz bir URL parametresi ile tanımlanabilir. Çerezler, URL’lerinizi daha kullanışlı tuttukları ve kullanıcının oturum açma kimlikleriyle URL’lerini yanlışlıkla paylaşmalarını engellediği için tercih edilmelidir. Ancak, bir çerez olarak URL belirteçlerine sahip olmak da çerezleri devre dışı bırakan kullanıcılar için hayati öneme sahiptir. Çoğu web geliştirme çerçevesi, bu kullanıma hazır olan bir oturum işleme sistemine sahiptir.

Sunucu tarafında, oturum bilgileri genellikle bir veritabanında saklanır. Sunucu tarafı bellek içi önbellekleme isteğe bağlıdır. Yanıt süresini büyük ölçüde artırabilir, ancak oturumları farklı sunucular arasında aktarmanıza izin vermez. Böylece bir geri dönüş olarak kalıcı bir veritabanına ihtiyacınız olacak.

büyük web siteleri (Amazon, Google, Facebook, Twitter vb.) aslında vatansız mı? Jetonlar mı yoksa çerezler mi kullanıyorlar (veya her ikisi de)?

Giriş yapmanıza izin veriyorlar mı? Sonra sekmeyi kapatıp siteyi tekrar ziyaret ettiğinizde, hala giriş yaptınız mı? Eğer öyleyse, o zaman oturumlar arasında kimliğinizi korumak için çerezleri kullanıyorlar.


46
Buradaki kafa karışıklıklarından birinin, kullanıcının bakış açısından geniş anlamda bir "web uygulaması" ile "web sunucusunda çalışan kod" dar anlamda "web uygulaması" arasındaki fark olduğunu düşünüyorum. İkincisi, genellikle eskisi değil vatansız olduğu iddia edilen. Söylediğiniz gibi, devletin genellikle iş mantığının bir parçası olduğu için, eskilerin genel olarak vatansız olmalarının bir anlamı yoktur. İkinci durumun vatansız olması için, durumun istemcide veya veritabanı sunucusunda veya web sunucusunda değil, her ikisinde de depolanması gerektiği anlamına gelir.
Derek Elkins

16
"[...] ancak o zaman sunucuda değil, yalnızca istemcide tekrar durumunuz var." Daha iyi ölçeklendirilebilirlik ve kullanılabilirlik elde etmek için sunucu tarafında durum yok. Bir müşteri tarafında saklanan bir durum önemli değil.
Paul Wasilewski

5
@ njzk2, bu saçma gelmiyorsa, biraz detaylandırabilir misiniz? Kullanıcılar daha fazla isim almak için Amazon'a gitmiyor. Ve, satın alımlarını yaptıktan sonra, sadece alışveriş yaparken var olan bir şey kaybolur. Bu bir şey "uygulamanın durumu" değilse, o zaman nedir? Başvuruların durumu yoksa, neleri vardır?

3
@nocomprende: njzk2'nin genel özü, sepetinizin içeriğinin, tam adınız gibi, bir webapp'ın sunucu tarafında devam ettiği veri olduğunu düşünüyorum. İnsanlar "webapps vatansız olmalı" derken, genellikle "webapps kullanıcı adınızla ilişkili tam adınızı içeren bir veritabanına erişmemelidir" den farklı bir şey ifade eder. Tam da onlar neyi yok o veritabanına sahip kez beri ;-) orada aşırı karmaşık Uygulama durumunu desteklemek için, orada sürebileceği saçma her türlü, ama olmamalı, belki trivially tanımlanmadı "vatansız" demek
Steve Jessop

4
@nocomprende: veritabanını geri alarak bir yumurtayı çözme: webapp bizim durumsuz olduğu için eskisi gibi devam edebilir ;-)
Steve Jessop 10:17

56

Web uygulamalarının vatansız olması gerektiği doğrudur. Ancak, oturum değişkenleri, çerezler ve simgeler, hepsi istemcide (web tarayıcısı) depolandığında bunu ihlal etmez. İstekte parametreler olabilir.

İşte basitleştirilmiş bir model:

Web Browser (has state) <-> Web Server (stateless) <-> Database (has state)

Bu, Software Engineering Stack Exchange için işe yarayabilir . Yazdığım bu cevap web tarayıcımın durumunun bir parçası. Orası olduğu tek yer olduğu sürece, benden başka kimseye erişemez. Ancak Post your Answertarayıcımı vurur vurmaz web tarayıcısına gönderir. Web sunucusu postayı kendi durumunu kullanmayan şekilde işler. Tarayıcımdan ve veritabanından kim olduğumu öğreniyor. Yayınımı kontrol edip veritabanına eklemeyi bitirdikten sonra web sunucusu derhal beni unutuyor.

Vatansız demek budur. Bunların hiçbirini hatırlamaktan sunucu sorumlu değildir. Bu onun işi değil.

Bunu yapmak birçok avantaja sahiptir. Web sunucusunda bellek sızıntısı varsa, bellek kapağının artmaması gerektiğinden tespit edilebilir. Web sunucusu çökerse kimliğim onunla gitmez. Birisi hizmet reddi saldırısı yapmaya çalışırsa, web sunucusu durum kaynaklarını bu amaçla kullanamaz, çünkü web sunucusu oturumlar arasında kendilerine hiçbir durum ayırmaz. Tüm bunlar web sunucusunu kararlı kılmayı amaçlamaktadır. Bu şekilde, çalışmaya başladığında, çalışmaya devam eder.

Şimdi elbette, veri tabanındaki kaynakları tüketiyorum, ancak bu kaynaklar öncelikle benim veritabanımı vahşi ve yünlü ağdan korumak için güvenebileceğimiz istikrarlı bir şey tarafından kontrol edildi: vatansız, iş kurallarını uygulayan web sunucusu.


8
Bilmiyorum ... Bu cevap biraz kulağa şöyle geliyor: " Excel e-tablonuzu saklamaz, disk sürücü yapar!" Ha ha, çoğu insanın endişesi olduğu sürece , veritabanı web sunucusunun bir parçası değil mi? Açıkçası, durum CPU'nun veya sunucunun kodunda saklanmadı ve hepsini bellekte tutmak oldukça saçma.

7
@nocomprende Hayır, veritabanı genellikle web sunucunuzun bir parçası değildir. Evet, durumu bir veritabanında saklamak muhtemelen tüm uygulamanın ölçeklenebilirliğini sınırlandırır, ancak tüm durumlarını (hatta tüm "kullanıcı başına" durumunu) istemciye aktaran nispeten az sayıda uygulama vardır . Veritabanı sunucuları, durumu ölçeklendirilebilir bir şekilde ele almak için özel olarak tasarlanmıştır ve CandiedOrange'in belirttiği gibi, genellikle web sunucularından daha iyi korunur, sağlanır ve denetlenirler. Tüm ölçeklenebilirlik sorunlarını çözmese de web sunucularını kolayca ölçeklendirmenin avantajları vardır.
Derek Elkins,

9
@nocomprende: Veritabanının web sunucusunun bir parçası olmadığını söylemenin anlamı, 1, 2, 3, .... web sunucuları için tek bir veritabanına (veya veritabanı kümesine) sahip olabileceğinizdir. Vatansız olmanın ölçeklenebilirliği arttırması budur: Veri tabanı kümesini ve web sunucusu sayısını bağımsız olarak ölçeklendirebilirsiniz.
Matthieu M.

6
“Web uygulamalarının vatansız olması gerektiği doğru.” Hayır. Bu tamamen saçmalık.
svidgen

4
Bu cevabı en çok sevdiğim cevabı çünkü web'de "vatansız" ın kullanımını en iyi açıklıyor. Sunucu, istekler arasında durumu korumuyor. Tüm devletler müşteriden (yani isteğin bir parçası) veya veritabanından (muhtemelen talebe bağlı olarak) gelmelidir. Bir yana, web uygulamasında genellikle bazı durumlar vardır (örneğin, statik durum örnekleri), ancak genel olarak, vatansız olacak şekilde tasarım yapmak istersiniz. Vatansızlık fikrini en iyi şekilde açıklamak için bu cevap kabul edilen cevaptan daha iyi görünmektedir.
Kat

30

web uygulamaları vatansız olmalı

Saçmalık. Web istekleri vatansız olmalıdır. Ya da daha doğrusu, web istekleri vardır vatansız.

Ancak, bütün bir uygulamanın vatansız olması gerektiğini söylemek saçmalıktır.

Her istek bağımsız bir işlem olarak kabul edilir.

Evet, aynen . Ya da daha doğru olarak, evet, mutlaka . HTTP üzerinden, her istek kendiliğinden diğer tüm taleplerden bağımsızdır. HTTP'ye "durum bilgisi" eklemek, her "durum bilgisi" isteği için "durum" u açıkça tanımlamanızı, saklamanızı ve almanızı gerektirir. Bu da çaba gerektirir, performansı azaltır ve karmaşıklık ekler.

Ve bu nedenlerden dolayı, vatansız olabilen her istek vatansız olmalıdır.

Sonuç olarak, Oturum ve Çerezlerden kaçınılmalıdır (her ikisi de durumlu olduğu için). Tokens kullanmak daha iyi bir yaklaşımdır

Birkaç şey: Jetonlar oturum depolamaya da bağlanabilir. Çerezlerin oturum depolamasına bağlı olması gerekmez . Jetonlar genellikle çerezlerde saklanır. Ve bazen bir oturum sadece iş için doğru bir araçtır.

Bu, en azından bazen oturumların ve çerezlerin belirteçler kadar "daha iyi" olduğu anlamına gelir !

[Jetonlar] vatansız çünkü sunucuda hiçbir şey kayıtlı değil.

İşte bu. Budur "Vatansızlıkları" dogma hakkında gerçekten ne. Net olmak gerekirse, sunucuda "hiçbir şey" depolamakla ilgili değil , sunucuda oturum durumunu depolamakla ilgili değil .

Örneğin Gmail gelen kutum bir eyalette. Ve lanet olası sunucuda saklanması daha iyi ! Ancak, bu oturum durumu değil .

Bu nedenle, küçük bir tanımlayıcı alabilen ve kim olduğunuzu anlayabilen bir sunucuya sahip olmak yerine, vatansız uygulamalara kim olduğunuzu ve her kanlı istekle ne yaptığınızı hatırlatmak istersiniz . Başvuru durumu hala devam etmektedir, müşteri sadece onu tutmaktan sorumludur.

Şimdi, eğer bu durum küçükse, muhtemelen sorun değil. Bazı durumlarda çok iyi.

Ve sonra, tabii ki, sadece devletten olmasını beklediğimiz şeyler var ...

Oturumum için tutulan veriler olduğunda web alışverişleri nasıl vatansız olabilir (alışveriş sepetindeki öğeler gibi)? Bunlar aslında bir veritabanında saklanıyor mu ve daha sonra periyodik olarak temizleniyor mu?

İki seçenek. Ya bir oturumun var ya da inkar ediyorsun!

... Ama ciddice. Normal olarak bir sepeti bir çerezde saklamazsınız. Bir alışveriş sepeti gibi bir şey ya "geleneksel" bir oturumda saklanacak ya da Cartsunucunun sonraki isteklere çekebilmek için kullandığı bir tür kimliğe sahip bir nesne olarak saklanacaktır . Bir nevi ... uhh ... ... hata ... oturumu.

Gerçekten ciddiyetle: "İletişim kurucu" olarak adlandırdığımız şey, iki iletişim kurucusu bir konuşmanın mesajlarını bağlamsallaştırabildiğinde buna bizim söylediğimiz şeydir. Ve geleneksel olarak anlaşılan bir oturum, tam olarak bunun gerçekleştiği mekanizma olarak adlandırdığımız şeydir.

Sunucunuzun kullandığı her istek için belirteçleri veya "oturumları" kullanıp kullanmadığınızdan bağımsız olarak, bu isteği yerine getirmek için bağlamsallaştırmanız gerekeceğini ya da yapmamanız gerektiğini savunuyorum . Bağlam gerekli değilse, alma . Bağlam ise ise gerekli, daha iyi yakındaki o var!

Ve sonra ilgili bir soru olarak, büyük web siteleri (Amazon, Google, Facebook, Twitter vb.) Vatansız mı? Jetonlar mı yoksa çerezler mi kullanıyorlar (veya her ikisi de)?

Muhtemelen ikisi de. Ancak, genel olarak konuşursak, tam olarak ne yaparsanız yapın: "Büyük" oturum "veritabanlarındaki" durum "kayıtlarını tanımlamak için çerezler hazırladılar.

Mümkün olduğunda, merkezi depolama konusunda gereksiz çekişmelerden kaçınmak için temel kimlik iddialarını kısa ömürlü "belirteçler" e soktuklarından şüpheleniyorum. Ancak, bu hizmetlerin birçoğunun "diğer tüm konumlardan çıkmama" izin vermesi gerçeği, belirteçleri kullanıyorlarsa, en azından yarı geleneksel bir oturum modeli tarafından "desteklendiklerini" gösterdiğinin iyi bir göstergesidir. .


3
Anlaşmak. Bana "değişmez veri" fikrini hatırlatıyor. Değişmez ise, bir kayaya oyunuz, bunun için bir bilgisayarı israf etmeyiniz. Bilgisayarlar verilerle bir şeyler yapsın! Bu yüzden onları yaptık! Uygulamalar verilerle çalışır. Sabit olan veriler işe yaramaz.

@nocomprende FYI, sonradan bir zeyilname yapacağım. Telesekreterin OP'nin altında yatan sorunun bir kısmını eksik olduğunu hissediyorum. Çünkü orada olduğunu "Vatansız uygulaması" fikrin arkasında yüzen bir yasal endişe. Ama, cevap, çizgisinde olduğunu insanlar ne, 'vatansız' derken demek demek ki 'sunucu tarafı oturumları minimal dayanır.'
svidgen

4
@nocomprende: değişmez veri yapıları farklı bir şeydir ve bellek nesnelerinin yaşam döngülerini yönetmek için kullanılan bir araçtır.
whatsisname,

1
İlk açıklama hattını sev. Bir şeyi tartıştığımızda, yaptığımız her sözlü ifade anında unutulup ölüyor. Ama her nasılsa, hala bir sohbete devam edebiliyoruz, ha? Bu sihir!

1
@nocomprende Bu ilginç bir tartışma, ama sanırım burada devam etmemeliyiz.
pabramlar

14

Durumsallık mutlaka kötü bir şey değildir, ancak durumlu ve durumsuz uygulamalar arasındaki farkı anlamanız gerekir. Kısacası, durum bilgisi olan uygulamalar o anki oturumla ilgili bilgileri korur ve durumsuz uygulamalar yok. Bir kullanıcı hesabının parçası olarak kalıcı olarak saklanan bilgiler bir oturumda saklanabilir veya saklanmayabilir, ancak bir kullanıcı hesabına ilişkin bilgilerin saklanması tek başına uygulamayı durumdan kurtarmaz. Durum bilgisi, sunucunun mevcut kullanıcının oturumu hakkındaki bilgileri istemci tarayıcısının koruduğunun ötesinde tutmasını gerektirir. Örneğin, bir müşteriye kimlik doğrulaması yapabilir ve daha sonra her istekle birlikte sunucuya gönderdiği bir JSESSIONID çerezi verilebilir. Sunucu, bu JSESSIONID değerini temel alarak uygulamanın oturum kapsamında bir şeyler depolamaya başlarsa, durum bilgisi olur.

Statelessness

Vatansız olarak, sunucu ve istemcinin kullanıcı oturumu hakkındaki güncel bilgileri korumadığı anlamına gelir. İstemci ve sunucu, istekler arasında kimlik doğrulama sağlamak için bir miktar belirteç kullanabilir, ancak başka bir güncel bilgi saklanmaz. Böyle bir çözüm için tipik bir kullanım örneği, çoğu kullanıcının (yeni tüketicilerin) bilgi tükettiği, ancak siteye geri dönen bilgiler üretmediği bir haber sitesi olabilir. Bu gibi durumlarda, sitenin mevcut kullanıcı oturumu hakkında herhangi bir bilgi tutması gerekmez. Sitenin, kullanıcıyı tanımlamak ve bu kullanıcının siteyi kullanmasıyla ilgili bilgileri depolamak için çerezleri kullanabileceğini, ancak kaydedilen her şeyin işlem yapabileceği, örneğin kullanıcının tıkladığı bağlantıyı kaydedebileceği için vatansız olarak kabul edilebileceğini unutmayın. Sunucu ancak kullanıcı oturumunda tutulmuyor.

Sunucudaki durum bilgisi

Sunucuda, durum bilgisi olan bir uygulama mevcut kullanıcılar hakkındaki durum bilgilerini kaydeder. Bu yaklaşım genellikle, kullanıcının isteklerini arasında sunucuda muhafaza edebilmesi için kullanıcının sistemini tanımlamak için çerezlerin kullanılmasını içerir. Uygulama bağlamına bağlı olarak oturumlar doğrulanabilir veya olmayabilir. Durum bilgisi olan sunucu uygulamaları, sunucudaki kullanıcı durumu bilgilerini önbelleğe alma, aramaları hızlandırma ve sayfa yanıtlama süresi avantajı sunar. Aşağı tarafta, bilgileri oturum kapsamında saklamak pahalıdır ve ölçekte çok kaynak yoğundur. Ayrıca, bilgisayar korsanlarının oturum tanımlayıcılarını denemek ve kaçırmak ve kullanıcı oturumlarını çalmak için potansiyel bir saldırı vektörü oluşturur. Durum bilgisi olan sunucu uygulamaları aynı zamanda kullanıcı oturumlarını beklenmeyen servis kesintilerine karşı, örneğin bir sunucu arızasına karşı koruma zorluğuna da sahiptir.

Müşteride durumluluk

JavaScript ve sessionStorage gibi modern tarayıcı teknolojilerini kullanarak, uygulama artık bir kullanıcının oturumu hakkındaki durum bilgilerini o kullanıcının cihazında kolayca depolayabilir. Genel olarak, başvuru hâlâ durumsal olarak değerlendirilebilir, ancak durumun sürdürülmesi işi müşteriye taşındı. Bu yaklaşımın (Web uygulamasının bakımı için) sunucudaki durumunun, her kullanıcının kendi durumunu koruduğu ve sunucu altyapısı üzerinde bir yükü bulunmadığı konusunda korunması konusunda büyük bir avantajı vardır. Web ölçeğinde, bu tür bir mimari seçim, donanım ve elektrik maliyetleri için büyük tepkilere sahiptir. Sunucuda durumunu korumak, kelimenin tam anlamıyla yılda milyonlarca dolara mal olabilir. Danışan üzerinde durumu koruyan bir sisteme geçmek, yılda milyonlarca dolar tasarruf sağlayabilir.

Jetonlar v. Çerezler

Çerezler, istemci cihazlar / tarayıcılar için tanımlayıcı olarak işlev görür. Her tür şeyi saklamak için kullanılabilirler, ancak genellikle CFML uygulamalarında CFID / CFTOKEN gibi bir tür tanımlayıcı depolarlar. Çerezler, kullanıcının tarayıcısında uzun süre yaşayacak şekilde ayarlanabilir ve bu sayede tarayıcı oturumları arasında bir uygulamada kimlik doğrulamayı sürdürme gibi şeyler yapılabilir. Çerezler ayrıca yalnızca hafızaya ayarlanabilir, böylece bir kullanıcı tarayıcıyı kapattığında kullanım süresi dolar.

Belirteçler genellikle sunucuda oluşturulan kullanıcı hakkında (bilgileri karıştırmak için şifreleme kullanarak), istemciye iletilen ve ardından gelen istekle sunucuya geri gönderilen bir tür tanımlayıcı bilgilerdir. Tek sayfa uygulamalarında ortak bir kalıp olan istek ve yanıtın başlığında geçirilebilirler. İdeal olarak, her istek / yanıt yeni bir belirteç üretilmesine neden olur, böylece belirteçler daha sonra bir saldırgan tarafından yakalanamaz ve kullanılamaz.

Tek Sayfa Uygulamaları ve müşteri durumu

SPA'larda durum bilgisi istemci tarayıcısına yüklenir ve orada saklanır. Durum değiştiğinde, örneğin sosyal medya hesabınıza bir güncelleme gönderdiğinizde, müşteri bu yeni işlemi sunucuya iletir. Bu durumda, sunucu bu güncellemeyi bir veritabanı gibi kalıcı bir veri deposuna kaydeder ve güncellemeyi temel alarak sunucuyla senkronize edilmesi gereken bilgileri müşteriye geri iletir (örneğin, güncellemenin kimliği).

İstemci üzerinde bu depolama durumunun, çevrimiçi / çevrimdışı deneyimler için, biraz da kullanılabilir bir uygulamaya sahipken, sunucu ile bağlantısının kesilebileceği için avantajlar sunduğunu unutmayın. Twitter, Twitter sunucusu uygulamasından bağlantısı kesilmiş olsa bile, Twitter beslemenizdeki yüklü herhangi bir müşteri tarafını gözden geçirebileceğiniz iyi bir örnektir. Bu kalıp ayrıca sunucu ile müşteri arasındaki senkronizasyonda karmaşıklık yaratır, ki bu tamamen kendine has bir konudur. Çözümün karmaşıklığı, müşteri üzerinde devleti idare edebilmenin bir yolu.

İstemcideki durum bilgisi, web uygulamalarının geleneksel masaüstü uygulamaları gibi daha fazla hissetmesini ve davranmasını sağlar. Masaüstü uygulamalarının aksine, genellikle hesap bilgilerinizin tümünü bir tarayıcıda müşteri oturumunuza yükleyemezsiniz. Bunu yapmak birçok durumda pratik olmaz ve kötü deneyimler doğurur. Tarayıcıya Gmail kutusunun tamamını yüklemeyi denemeyi hayal edebiliyor musunuz? Bunun yerine, istemci hangi etikete / klasöre baktığınıza ve o klasördeki e-posta listesindeki nerelere baktığınıza ilişkin bilgileri tutar. Hangi durum bilgisinin korunacağını ve neye ihtiyaç duyulacağının dengelenmesi, bu örüntüdeki başka bir mühendislik zorluğudur ve yine pratiklik ile iyi kullanıcı deneyimleri sağlama arasındaki bir farkı temsil eder.

Alışveriş sepetlerini ve benzerlerini

Alışveriş sepeti gibi teknik özelliklere gelince, gerçekten çözüme bağlı. Bir alışveriş sepeti, sunucudaki bir veritabanında saklanabilir, yalnızca sunucudaki oturum kapsamında saklanabilir veya hatta istemcide saklanabilir. Amazon, giriş yapan kullanıcılar için kalıcı alışveriş sepetlerine ve anonim kullanıcılar için "geçici" alışveriş sepetlerine sahip olsa da, bu alışveriş sepetlerinde bir dereceye kadar kalıcı olsa da.

Aynı marka altında yaşayan bir grup farklı uygulama olan Google gibi bir şeyden bahsettiğinizde, muhtemelen ortak bir mimariyi paylaşmazlar ve her biri kullanıcılarının ihtiyaçlarını en iyi şekilde karşılayacak şekilde inşa edilir. Bir sitenin nasıl oluşturulduğunu öğrenmek istiyorsanız, geliştirici araçlarını tarayıcınızda açın ve siteye bakın. Çerezleri kontrol edin, ağ trafiğini izleyin ve nasıl çalıştığını görün.

Üzgünüm, bu cevap biraz karışık olursa, ancak durumluluk karmaşık bir konudur.


6

Seanslardan ve çerezlerden kaçınılması gerekmez. Hala durumsuz web uygulamaları ile onları olabilir.

Java ve Ruby on Rails arasında büyük bir fark var. Java uygulamaları, tanımlama bilgisinde depolanan bir oturum anahtarı kullanarak oturumu bellekte depolar. Bu, kullanıcı durumunu ve alışveriş sepetini almak için hızlıdır. Ancak, aynı sunucuyu oturumunuzla her zaman vurmanız gerekir.

Rails uygulamaları kullanıcı kimliğini imzalı ve şifreli bir çerezde saklar. Tahrif edilemez. Bir sayfa yüklediğinizde, web uygulaması durumunuzu, kullanıcınızı ve alışveriş sepetinizi bir veritabanından alır. Bu daha yavaş, ama önemli olan, herhangi bir örneğe vurabilirsin ! Bu, istediğiniz zaman yeniden başlatma, ölçekleme, kapatma örnekleri sağlar. Çok uygun. Ayrıca, Redis gibi paylaşılan hafıza içi önbellek veritabanı ile daha hızlı hale getirilebilir. Veya alışveriş sepetini çerezde, yeterince küçük olması koşuluyla saklayabilirsiniz.

Böylece zeki tekniklerle vatansızlık elde edebilir ve isteğinize göre ölçeklendirme yeteneği ekleyebilirsiniz.



5

Vatansızlıktan söz ederken - örneğin bir RESTful HTTP Hizmetinde - durumu sunucu tarafında saklamaktan kaçınmak üzere. En iyi ihtimalle, bu aynı zamanda herhangi bir durumu bir veritabanında veya arka uçtaki diğer kalıcı depolarda saklamaktan kaçının. Bunu açıklığa kavuşturmak için genel olarak veri değil bir durumdan bahsediyorum. Bazı erkekler işleri karıştırıyor gibi görünüyor.

Vatansız bir iletişimin, özellikle ölçeklenebilirlik ve kullanılabilirlik açısından çeşitli avantajları vardır.

Daha iyi bir yaklaşım, sunucuda hiçbir şey depolanmadığı için durumsuz olan Simgeleri kullanmaktır.

Bu doğru (belirli kimlik doğrulama ve yetkilendirme protokolleri için). Jetonlar, bir kullanıcının kimliğini doğrulamak veya bir eylemi onaylamak için gerekli olan istek içindeki tüm bilgileri sağlayabilir (ancak başlamaz). Örnek olarak JWT'ye bakınız .

Bu yüzden, anlamaya çalışıyorum, oturumum için tutulan veriler olduğunda web uygulamaları nasıl vatansız olabilir (bir alışveriş sepetindeki öğeler gibi)? Bunlar aslında bir veritabanında saklanıyor mu ve daha sonra periyodik olarak temizleniyor mu? Çerez yerine bir jeton kullanırken bu nasıl çalışır?

Alışveriş sepeti örneği ile ilgili olarak. Bir alışveriş sepeti veya çerez kullanmadan tüm alışveriş sepetlerini müşteri tarafında saklamak sorun değil. Bir smashingmagazine.com sitesinde bir örnek bulabilirsiniz . Ancak çerezler ile vatansız bir alışveriş sepeti gerçekleştirmek de mümkündür (en azından ürün yelpazeniz çok büyük değilse ve 4kb depolama sizin için yeterliyse).

Beni yanlış anlamayın, bu herhangi bir fiyata vatansız bir alışveriş sepeti uygulamanız gerektiği anlamına gelmez. Amazon veya diğer büyük çevrimiçi alışveriş platformları, durum bilgisi olan alışveriş sepeti uygulamalarını kullanıyor, çünkü kullanıcı deneyimi ve kullanılabilirlik, ölçeklenebilirlik gibi işlevsel olmayan teknik gereksinimlere uymaktan daha önemlidir.

Genel olarak, jetonlar, sepet eşyaları gibi bilgileri depolamak için kullanılmaz. Vatansız kimlik doğrulama ve yetkilendirme için kullanılırlar.

Ve sonra ilgili bir soru olarak, büyük web siteleri (Amazon, Google, Facebook, Twitter vb.) Vatansız mı? Jetonlar mı yoksa çerezler mi kullanıyorlar (veya her ikisi de)?

Kimlik doğrulama için çerez veya jeton kullanıp kullanmadıklarını soruyorsanız, cevap her ikisini de kullanmalarıdır. Kullanıcılar için çoğunlukla teknik müşteriler için çerezler çoğunlukla belirteçler kullanılır.


-2

Tamam, alıntı yaptığınız kural teknik olarak yanlış. Bir web uygulamasının tüm katmanları bir duruma sahiptir.

Kuralın amacı "oturum başına sunucu durumu tutma" dır.

Yani, ASP'deki oturum değişkenleri , genellikle sepet / kullanıcı adındaki öğeler gibi şeyleri yapmak için kullanılır.

Bunun nedeni, uygulamanız daha fazla kullanıcı kazandıkça sunucuda yetersiz bellek oluşmasıdır. Depolamayı bir veritabanına veya paylaşılan önbelleğe taşımak, hala bir darboğaza sahip olduğunuzdan sorunu çözmez.

Kullanıcı başına uygulama durumunu bu soruna çarpmadan sürdürmek için durumu istemci tarafına taşıyın. Örneğin, sepet öğelerini bir çerez veya daha gelişmiş istemci tarafı depolamaya yerleştirin.

Müşterilerin sayısı kullanıcı sayısına göre ölçeklendiğinden, uygulamanızın tümü bir tıkanıklığa sahip olmayacak ve iyi ölçeklenecektir.


2
Bellek sızıntısı ve hizmet reddi sorunlarının bir etken olmasına rağmen, günümüzde daha önemli bir sürücünün, tabii ki, aynı zamanda ölçeklenebilirlikle ilgili bir web sunucusunun arızalanma esnekliği ve sağlamlığı olduğunu düşünüyorum. Eğer bir sunucu aşırı yüklenirse veya hatta çökerse, gelecekteki istekleri (ve biraz daha dikkatli bir şekilde tekrar tekrar başarısız olsa bile) yeni web sunucularına koordine etmeden veya durumunu kaybetmeden (kullanıcının gördüğü gibi) yeniden yönlendirebilirim.
Derek Elkins

hmm tür. Sunucuda kullanıcı başına bilgi varsa, dağıtılmış olsa bile hala bir ölçeklenebilirlik probleminiz var.
Ewan

Diskten veri çekerken önbellekleme gibi bir tıkanıklık varsa, yapabileceğiniz çok şey var.
JeffO,

hayır, bunu oturum verileri başına tutarsanız doğal bir sorun var. ya web sunucusundan kendi yüksek kullanılabilirlik sistemine geçersiniz ya da müşteriye taşıyarak hepsinden kurtulursunuz
Ewan

1
Sıcak patatesden kaçınmaya çalışmakla ilgili tüm bu tartışmalar beni gerçekten şaşırtıyor. Eski, "kova burada durur" demesine ne oldu? Bir şey verileri yönetmek zorunda, bankam tüm finansal işlem bilgilerimi yalnızca dizüstü bilgisayarımda tutmamı istemiyor. Neden herkes kaçıyor? Bu yüzden bilgisayarlarımız var! Çılgın.
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.