Büyük bir Ruby on Rails uygulamasına sahibiz (aylık 25 milyon kullanıcı), yönetimimiz Node.js'de yeniden yazmaya karar verdi, deliriyor muyum?


24

Lütfen bana söyle:

  • Node.js sitemizi daha hızlı hale getirecek!
  • Node.js daha az sunucu kaynağı tüketecek, paradan tasarruf edebiliriz!
  • Node.js bizi daha üretken yapacak!
  • Node.js, istemci ve sunucu tarafı JavaScript kodunu paylaşabileceğimiz anlamına gelir.

Açıklığa kavuşturmak için, mevcut Ruby on Rails uygulamamızla API olarak konuşacak olan bir ön uç sunucuyu yeniden yazıyoruz. Bu arada, Ruby on Rails uygulamamızı hizmetlere yönlendireceğiz.

Mevcut mimari hakkında daha fazla detay:

  • HTML kısmi önbelleklemesi için Memcached
  • Oturum için Redis ve bazı yapılandırılmış veri önbelleklemesi
  • MySQL single master, çoklu bağımlılar
    • Çok sayıda yazıyı kabul eden büyük bir masa var (bir anket hayal et)
    • Aksi takdirde çoğunlukla okur.
  • Bazı meta veriler için MongoDB
  • Ruby on Rails 3.0
  • nginx ve Unicorn

33
sheesh, tüm bu yenilikçi diller. İyi yazılmış bir php uygulaması kolayca ölçeklenecek, geleneksel araçlar işe yarayacak, bu yenilikçilerin size başka türlü söylemesine izin vermeyiniz.
Darknight

5
Soru, "İyileştirmeler işletmeye değecek kadar para kazandıracak mı?" 5 yıldan fazla para biriktirebilir, ancak yeniden yazmak pahalıdır ve zaman alıcıdır - kodunuz korkunç bir karışıklık değilse, yöneticilerinizin sinirlendiğini düşünüyorum
Mikey C

4
Eğer yeniden yazma düşünülüyorsa, ön ucunuzu istemci tarafı javascript'e taşımayı da düşünebilirsiniz, yani artık dinamik bir ön uç sunucunuz olmazdı, sadece statik dosyalar.
Joeri Sebrechts

11
@Darknight, bir noktada PHP'nin yenilikçi bir dil olduğunu ve başarılı ürünlere yerleştirilebileceğini belirten insanların kabul edilmesini teşvik ettiğini, Perl web geliştiricilerin de PHP hipsters'inde snigger yaptığını unutmayın.

9
Çok kimse Joel Spolsky makale yukarı getirdi şaşırdım yapmanız asla şeyler . Tüm yeniden yazmaların kötü olduğunu söylemiyorum, ama @MikeyC ile son derece dikkatli bir şekilde ele alınması gerektiğine katılıyorum.
Dan Pichelman

Yanıtlar:


22

İstediğiniz soruların çoğu bağlam olmadan cevaplanamaz ve verilen kararlar neredeyse hiç olmazsa, yönetim zaten sizin için bir seçim yaptı ... sormadığınız sürece 'tüm bu değişiklik karşısında istifa etmeli ve bırakmalı mıyım?' ?'

Eğer zorlaşırsanız, bu yazıyı şu konuyu okumanızı tavsiye ederim: Akıl sağlığınızı kaybetmeden, bir Sıfırdan Nasıl Yeniden Yazılmalı ?

Kısa bir süre önce node.js.de bir miktar sunucu mantığı yazma yolundan başladım. Asıl sebep şu anda .NET'te yazılmış ve yolun aşağısında MS ortamlarından uzaklaşmak istiyoruz.

Şimdiye kadarki deneyimlerim olumlu oldu, tüm engellemesizlikleri ile ilk öğrenme eğrisine sahip olacaksınız, ancak bir kez geçtiğinizde kodlamanın gerçekten eğlenceli olduğunu geçtikten sonra .. Biliyorum, FUN!

Yine de karanlık bir tarafı var, her insan ve köpeği JavaScript ile bazı ön uç geliştirmeler yapmış - ve umarım her ön uç geliştirici olur - node.js'nin 'sunucu tarafı javascript' olduğundan bahsettiğinizde biraz heyecanlanıyor Ancak bu, ön uç geliştiricilerin iyi sunucu tarafı uygulamalar yazmak için gereken deneyime sahip olacağı anlamına gelmiyor.

Düşündüğünüz bir şey için, ölümcül bir hatanın, dişli olmayan doğası nedeniyle tüm uygulamayı azaltacağı, bu nedenle bahis miktarları biraz daha yüksek ve açıkça her şeyi kontrol etmeniz ve yakalamanız gerekiyor.

Hem ön hem de arka tarafta - ve her ikisinin de keyfini çıkarmış olanlar için - zihinsel bağlamları önden arkaya uç dillere çevirmek zorunda kalmamak, sonuçta ekibimizdeki pistte verimliliği artıracağını düşündüğüm gerçek bir bonus.


“Düşündüğünüz bir şey için, ölümcül bir hatanın, parçalı olmayan doğası nedeniyle tüm uygulamayı çökerteceği, bu nedenle risklerin biraz daha yüksek olduğu ve açıkça her şeyi açıkça kontrol etmeniz ve yakalamanız gerektiği” - Bu benim endişem olur.
çadırlar

Evet, bu ifadeyle asıl noktaya göre, ön uç sadece geliştiricilerin istisnaların ele alınması konusunda genellikle telaşlı olmadıklarıydı. Hadi, neredeyse 2017 oldu!
dave.zap

8

Peki, uygulamanın yeniden yazılmasının, kötü performans göstermediği sürece iyi bir fikir olduğunu sanmıyorum. Sorularınıza cevap vermek için:

  1. Node.js sihir değil. Uygulamanızın çok fazla kullanıcısı var, bu yüzden daha hızlı hale getireceğinden emin olmanın bir yolu yok.

  2. Evet, Node.js aslında daha az sunucu kaynağı tüketiyor. Dolayısıyla sadece kaynaklardan tasarruf etmekle kalmaz, mevcut olanlarla daha fazlasını da yapabilirsiniz. Bu çoğunlukla Node.js.'nin tek iş parçacıklı doğası nedeniyledir. Fazladan ek konu yok.

  3. Yine Node.js sihir değil. Bunu söyledikten sonra, bunun içinde bazı gerçekler olabilir. Node.js, her olası görev için yüzlerce modül oluşturan çok aktif bir topluluğa sahiptir. Bu yüzden, işin çoğunun sizin için yapıldığı oldukça muhtemel. Sadece parçaları bir araya getirmen gerekiyor.

  4. Teorik olarak evet. Node.js JavaScript olduğundan, istemci ile sunucu arasında kod paylaşabilirsiniz. Ama ne paylaşılacağını tam olarak bilmiyorum. Bir müşteride tekrar kullanılabilecek bir kod parçası yazmadım. Sunucuda yaptığımız şeylerin genellikle müşteriyle ilgisi yoktur. Benim için daha önemli olan bağlam anahtarının olmaması. Hem istemcide hem de sunucuda tek bir dilde kodlamayı daha kolay buluyorum.

Node.js tek iş parçacıklı olduğundan, bunu yapmak için açıkça yapılandırılmadıkça , birden çok CPU'dan yararlanamaz .

Yorumlara da bir göz atın. Node.js.'nin işleyişiyle ilgili iyi bir fikir veriyorlar.


16
Tek bir iş parçacığı nedeniyle daha az kaynak? Sence bu fazladan iplikler ne yapardı?
Joe,

Anladığım kadarıyla @Joe ekleneceklerdir. Js düğümünde, bir isteği olabildiğince çabuk bir şekilde elemek en iyisidir. Ya bir seferinde tamamlayarak. için üretim uygulamaları yaptığım tek teknoloji. Bu yüzden diğer sunucu tarafı teknolojileri ile karşılaştırmak için en iyi insan olmayabilirim. cevabım.
Akshat Jiwan Sharma,

7
Evet, tek bir iş parçacığı kaynak kullanımını kesinlikle sınırlar, çünkü sunucu olay döngüsünde aynı anda yalnızca bir şey yapabilir. Aynı zamanda sunucu kullanımını da sınırlar, çünkü bir kerede yalnızca bir şeyi yapabilir. Sadece tek başına değil, özellikleri (tek iş parçacıklı) ve alt ve üst kısımları alıntılamak çok önemlidir. Node.js bazı kullanımlar için uygundur ancak diğerleri için kötü bir fikirdir. Tek iş parçacıklı düğüm sunucunuzda kapasite sorunları varsa, başka bir düğüm örneği eklemeniz gerekebilir. Artık çok işlemli bir sunucunuz var.
Joe,

Ne demek istediğini anlıyorum. Kısa bir süre sonra cevabı güncelleyeceğim (bazı araştırmalardan sonra okunacak)
Akshat Jiwan Sharma

10
Bu sadece CPU'larla ilgili değil. Sebebi neden her isteği size tüm taşıma işlemi bitene kadar beklemek zorunda böylece sunucu, bir kerede birden fazla isteklerine hizmet edemez çünkü (başka eşzamanlılık ile tek-dişli sisteminde) mümkün olan en kısa sürede her isteği yerine önemlidir olduğu ondan önceki istekler. Doğru yapılan eşzamanlılık, daha az beklemek anlamına gelir. Dişlerin kullanılması doğal olarak bir performans boşalması değildir ve tek diş açılışı (varsayılan olarak veya başka şekilde) performans avantajı değildir.
Peter Hosey
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.